Integrierte Informationslogistik (Business Engineering)

Business Engineering Herausgegeben von H. Österle, R. Winter, W. Brenner Business Engineering V. Bach, H. Österle (Hr...

Author: Barbara Dinter | Robert Winter

184 downloads 1233 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Business Engineering Herausgegeben von H. Österle, R. Winter, W. Brenner

Business Engineering V. Bach, H. Österle (Hrsg.) Customer Relationship Management in der Praxis 2000. ISBN 978-3-540-67309-5 H. Österle, R. Winter (Hrsg.) Business Engineering, 2. Auflage 2003. ISBN 978-3-540-00049-5 R. Jung, R. Winter (Hrsg.) Data-Warehousing-Strategie 2000. ISBN 978-3-540-67308-8 E. Fleisch Das Netzwerkunternehmen 2001. ISBN 978-3-540-41154-3 H. Österle, E. Fleisch, R. Alt Business Networking in der Praxis 2001. ISBN 978-3-540-41370-7 S. Leist, R. Winter (Hrsg.) Retail Banking im Informationszeitalter 2002. ISBN 978-3-540-42776-6 C. Reichmayr Collaboration und WebServices 2003. ISBN 978-3-540-44291-2 O. Christ Content-Management in der Praxis 2003. ISBN 978-3-540-00103-4 E. von Maur, R. Winter (Hrsg.) Data Warehouse Management 2003. ISBN 978-3-540-00585-8 L. M. Kolbe, H. Österle, W. Brenner (Hrsg.) Customer Knowledge Management 2003. ISBN 978-3-540-00541-4

T. Puschmann Prozessportale 2004. ISBN 978-3-540-20715-3 H. Österle, A. Back, R. Winter, W. Brenner (Hrsg.) Business Engineering − Die ersten 15 Jahre 2004. ISBN 978-3-540-22051-0 R. Zarnekow, W. Brenner, U. Pilgram Integriertes Informationsmanagement 2005. ISBN 978-3-540-23303-9 U. Baumöl, H. Österle, R. Winter (Hrsg.) Business Engineering in der Praxis 2005. ISBN 978-3-540-20517-3 R. Zarnekow, A. Hochstein, W. Brenner Serviceorientiertes IT-Management 2005. ISBN 978-3-540-20532-6 J. Schelp, R. Winter (Hrsg.) Integrationsmanagement 2005. ISBN 978-3-540-20506-7 R. Zarnekow, W. Brenner, U. Pilgram Integrated Information Management 2006. 978-3-540-32306-8 R. Zarnekow Produktionsmanagement von IT-Dienstleistungen 2007. ISBN 978-3-540-47457-9 R. Heutschi Serviceorientierte Architektur 2007. ISBN 978-3-540-72357-8

R. Alt, H. Österle Real-time Business 2003. ISBN 978-3-540-44099-4

W. Brenner, R. Wenger (Hrsg.) Elektronische Beschaffung 2007. ISBN 978-3-540-34017-1

G. Riempp Integrierte Wissensmanagement-Systeme 2004. ISBN 978-3-540-20495-4

B. Dinter, R. Winter (Hrsg.) Integrierte Informationslogistik 2008. ISBN 978-3-540-77577-5

Barbara Dinter · Robert Winter (Herausgeber)

Integrierte Informationslogistik

123

Dr. Barbara Dinter Prof. Dr. Robert Winter Universität St. Gallen Institut für Wirtschaftsinformatik Müller-Friedberg-Strasse 8 9000 St. Gallen Schweiz [email protected] [email protected]

ISBN 978-3-540-77577-5

e-ISBN 978-3-540-77578-2

DOI 10.1007/978-3-540-77578-2 Business Engineering ISSN 1616-0002 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. © 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 Jelonek, Schmidt & Vöckler GbR, Leipzig Einbandgestaltung: WMX Design GmbH, Heidelberg Gedruckt auf s¨ aurefreiem Papier 987654321 springer.com

Vorwort

IT-Innovationen sind im Idealfall Enabler für Geschäftsinnovationen – sie erlauben neuartige fachliche Lösungen umzusetzen oder zumindest fachliche Lösungen durch Kostensenkung, Beschleunigung, Qualitätsverbesserung o. ä. weiterzuentwickeln. Wenn 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 gefassten Innovationen wurde es beispielsweise möglich, entscheidungsrelevante Informationen systematisch in der nachgefragten Qualität und der notwendigen Geschwindigkeit bereitzustellen, ohne an die Limitationen 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 IT 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 Betrachtung von Strategie, Organisation und Systemen 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 werden aktuelle Problemfelder

VI

Vorwort

und Lösungsansätze der Informationslogistik ganzheitlich und konsistent betrachtet und Hinweise zur Gestaltung der Informationslogistik in fachlicher, organisatorischer und technischer Hinsicht gegeben. Fallstudien aus führenden Unternehmen in Deutschland und der Schweiz zeigen an praktischen Beispielen, wie Informationslogistik im Unternehmen erfolgreich gestaltet und umgesetzt werden kann. Die Ergebnisse, die in diesem Band vorgestellt werden, entstanden hauptsächlich im Rahmen des Kompetenzzentrums Enterprise Information Warehousing (CC EIW) als Teil des Forschungsprogramms Business Engineering am Institut für Wirtschaftsinformatik der Universität St. Gallen (IWI-HSG). Durch enge Zusammenarbeit von Universität und Unternehmen werden im CC EIW „Business-to-IT“-Methoden zur Gestaltung sowie zum Betrieb der Informationslogistik in der Reifephase entwickelt. In den Jahren 2005 bis 2008 nahmen bzw. nehmen folgende Partnerunternehmen am CC EIW aktiv teil: x x x x x x x

BKW FMB Energie AG Credit Suisse Deutsche Telekom E.ON AG Swiss Reinsurance Company Zürcher Kantonalbank Zurich Financial Services

Die St. Galler Anwenderforen sowie die Konferenzen DW2006 und DW2008 ermöglichen darüber hinaus einen Blick auf den State of the Art in zusätzlichen Unternehmen und fördern einen intensiven Dialog zwischen Praxis und Wissenschaft. Dieses Buch ist in drei Teile gegliedert. Im ersten Teil wird das St. Galler Konzept der integrierten Informationslogistik vorgestellt. Der zweite Teil stellt aktuelle Schwerpunktthemen aus dem Bereich der Informationslogistik vor und im dritten Teil werden anhand von Fallstudien die Kernaspekte des ersten Teils im Hinblick auf die Praxis vertieft. Im ersten Kapitel stellen Winter et al. das St. Galler Konzept der Informationslogistik als integrierten Ansatz zur übergreifenden Informationsversorgung im Unternehmen vor und grenzen das Thema zu verwandten Bereichen wie Data Warehousing und Business Intelligence ab. Im darauf folgenden Beitrag stellt Winter den St. Galler Business Engineering-Ansatz zur Konstruktion und Evolution von Informationssystemen vor. Schmaltz und Bucher zeigen im dritten Kapitel, welchen Beitrag wirt-

Vorwort

VII

schaftswissenschaftliche Theorien für die Motivation der Informationslogistik und ihre Ausgestaltung leisten können. In den folgenden vier Beiträgen wird das Konzept der integrierten Informationslogistik auf den verschiedenen Ebenen des Business Engineering-Frameworks detailliert. Dinter und Winter behandeln die Strategie der Informationslogistik. Klesse und Schmaltz erläutern die Aufbauorganisation, der Beitrag von Bucher zeigt, wie Bereitstellung analytischer Informationen und Ausführung operativer Prozesse zusammengebracht werden können. Stroh und 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. Die Fallstudien des dritten Teils schlagen die Brücke zwischen Theorie und Praxis. Dabei folgen die Beiträge der Gliederung des ersten Teils. Sommer et al. beschreiben die BI-Strategie des Volkswagen-Konzerns. Lahrmann und Meyer zeigen, wie die Aufbauorganisation der Informationslogistik bei E.ON gestaltet wird. Bucher und Lutz zeigen die Integration analytischer Informationen in operative Prozesse. Eine exemplarische Systemarchitektur bei der Credit Suisse wird im Beitrag von Binzegger Rouss et al. dargestellt. 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 auch allen Autoren, sowohl bei unseren Partnerunternehmen wie auch am IWI-HSG, die zum Inhalt dieses Buches mit großem Engagement beigetragen haben. Schließlich gebührt unser Dank auch Moritz Schmaltz, Remo Stieger, Stefan Wagner und Philipp Gubler, die für die Redaktion des Buches verantwortlich waren. Barbara Dinter, Robert Winter

St. Gallen, im Dezember 2007

Inhaltsverzeichnis

1

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

2

Business Engineering – Betriebswirtschaftliche Konstruktionslehre und ihre Anwendung in der Informationslogistik .................... 17 Robert Winter

3

Ökonomische Theorien als Erklärungs- und Gestaltungsgrundlage der Informationslogistik .................................................. 39 Moritz Schmaltz, Tobias Bucher

4

Strategie der Informationslogistik .................................................... 63 Barbara Dinter, Robert Winter

5

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

6

Interaktionseffekte zwischen prozessorientierter Organisation und Informationslogistik................................................................. 107 Tobias Bucher

7

Systemarchitekturen für die Informationslogistik .......................... 137 Gerrit Lahrmann, Florian Stroh

8

Nutzenpotenziale unternehmensweiter Informationslogistik ......... 167 Moritz Schmaltz, Jochen Töpfer

9

Metadaten, Referenzdaten, Stammdaten ........................................ 189 Hans Wegener

X

10

Inhaltsverzeichnis

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

11

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

12

Business Intelligence-Strategie bei der Volkswagen AG ............... 261 Thorsten Sommer, Birgit Wendlandt, Uwe Trost, Martin Zirkel

13

Etablierung eines Excellence Teams Information Logistics bei E.ON ......................................................................................... 285 Gerrit Lahrmann, Dirk Meyer

14

Prozessorientierte Informationslogistik bei der Hotelplan Swiss Group .............................................................................................. 299 Tobias Bucher, Peter Lutz

15

Informationslogistikarchitekturen am Beispiel der Credit Suisse .. 319 Barbara Binzegger Ruoss, Andreas Geppert, Florian Stroh

Autorenverzeichnis ......................................................................... 339 Sachverzeichnis .............................................................................. 343

1

Das St. Galler Konzept der Informationslogistik

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher Universität St. Gallen

1 2 3 4

Einleitung ........................................................................................... 1 Das St. Galler Konzept der Informationslogistik ............................... 2 Spezifika und Herausforderungen der Informationslogistik............... 9 Zusammenfassung und Ausblick ...................................................... 14 Literatur ............................................................................................ 14

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-

2

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


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


3

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 Ent-

4


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

scheidungen 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 (vgl. Kap. 14). 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.


5

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

6


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


7

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-

8


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-


9

formationen kann dabei innerhalb oder außerhalb der Unternehmung liegen. 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.

10


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: x x x x x x

Architekturmanagement Metadatenmanagement (Daten-)Qualitätsmanagement Stammdatenmanagement Management von Datenschutz und Datensicherheit Aufbau- und Ablauforganisation (inkl. Servicemanagement und Leistungsverrechnung) x Projekt- und Anforderungsmanagement 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-


11

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“ sowie „Projekt- und Anforderungsmanagement“ 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.

12


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-


13

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-

14


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


15

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.

16


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.

2

Business Engineering – Betriebswirtschaftliche Konstruktionslehre und ihre Anwendung in der Informationslogistik

Robert Winter Universität St. Gallen

1 2 3 4 5 6 7 8

1

Change the Business vs. Run the Business....................................... 17 Aufgabenstrukturierung der Veränderung ........................................ 19 Ziele und Ergebnisse der Veränderung ............................................ 22 Gegenstand der Veränderung ........................................................... 24 Grundlegende Veränderungsprozess-Szenarien ............................... 28 Modell- und Methodenunterstützung der Veränderung ................... 29 Business Engineering am Beispiel des Corporate Performance Management ..................................................................................... 32 Business Engineering für Betriebsprozesse ...................................... 35 Literatur ............................................................................................ 36

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 „An-

18

Robert Winter

liegen / Interessen“ oder der Ordnungsmomente „Strategie“, „Strukturen“ 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 angewie-

Business Engineering

19

sen, die Effizienz durch Arbeitsteilung und Standardisierung erreichen. 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

20

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-


21

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.

22

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.


23

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)

24

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.


Strategieebene

Organisationsebene

25

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,

26

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. Während die verschiedenen Modelltypen Zusammenhänge zwischen einer jeweils kleinen Zahl von Gestaltungsobjekten beschreiben, definiert das Business-Metamodell den Gesamtzusammenhang aller Gestaltungsobjekte. Abbildung 4 stellt eine stark vereinfachte Version des BusinessMetamodells dar; eine vollständige Darstellung findet sich in (Österle et al. 2007). In Abb. 4 zeigen die Ränder der Repräsentationen der Gestaltungsobjekte die Architekturebene an, zu der sie primär gehören: Mit durchgezogenen Linien werden Gestaltungsobjekte der Strategieebene, mit durchbrochenen Linien Gestaltungsobjekte der Organisationsebene und mit gepunkteten Linien Gestaltungsobjekte der Systemebene dargestellt.


Abb. 4. Business-Metamodell (stark vereinfacht)

27

28

Robert Winter

5

Grundlegende Veränderungsprozess-Szenarien

Business Engineering versteht sich als methoden- und modellbasierte Konstruktionslehre (Österle u. Winter 2003b). Die durch Methoden und (Referenz-)Modelle zu unterstützenden Veränderungen sind dabei sehr vielfältig. Um eine ausreichend zielgerichtete und konkrete Unterstützung zu liefern, sollten deshalb verschiedene Veränderungsprozess-Szenarien unterschieden werden. Auf Grundlage der Business Engineering-Architekturebenen können die folgenden generellen Veränderungsprozess-Typen unterschieden werden: 1. Fachlich getriebene Veränderungen durchlaufen die 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 „verti-


29

kal“, sondern auch „horizontal“ abzugleichen. Dies ist z. B. der Fall, wenn zwei Partner eines Wertschöpfungsnetzwerks ihre strategische Positionierung, ihre Prozesse / Organisation und ihre IT-Lösungen koordinieren müssen. Horizontale Abgleiche sind auch innerhalb von Unternehmungen (z. B. verschiedene Konzerngesellschaften, 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 Gestaltungsebenen 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. 5 illustriert. 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.

6

Modell- und Methodenunterstützung der Veränderung

Nach wie vor scheitern viele Veränderungsprojekte (Capgemini 2005). Von den vielen Gründen, die für die hohe Fehlschlagquote verantwortlich sind, adressiert das Business Engineering unmittelbar die fehlende oder mangelnde Methodenunterstützung. Mittelbar wird durch die Bereitstellung geeigneter Methoden angestrebt, die Perspektiven der verschiedenen

30

Robert Winter

Strategieebene

Organisationsebene

Integrationsebene Softwareebene

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

Infrastrukturebene

Abb. 5. Veränderungsprozess-Szenarien

Stakeholder sowie die verschiedenen Facetten des Problems systematisch zu erfassen sowie bei der Problemlösung Arbeitsteiligkeit, Qualitätssicherung, Skalierbarkeit und Transparenz zu gewährleisten. Die Methoden des Business Engineering sind bei weitem zu komplex, um ohne systematisches Entwurfsverfahren entwickelt und adaptiert werden zu können. Die Forschungsdisziplin, die sich mit der systematischen Konstruktion von Methoden beschäftigt, wird als Methoden-Engineering bezeichnet. Eine wichtige Perspektive des Methoden-Engineering ist die Konstruktion generischer Methoden für eine bestimmte Klasse von Veränderungsprozessen. Eine weitere wichtige Perspektive ist die systematische Adaption von generischen Methoden, um sie für eine spezifische Problemstellung anwendbar zu machen. Methoden können aus Produktsicht (d. h. hinsichtlich ihrer strukturellen Aspekte) und aus Prozesssicht (d. h. hinsichtlich ihrer dynamischen Aspekte) betrachtet werden. Aus Produktsicht umfasst eine Methode Aktivitätsbeschreibungen, Rollenbeschreibungen, Vorschriften für die Gestaltung von Ergebnisdokumenten, Techniken für die Unterstützung der Aktivitäten, Aussagen zur Abfolge und Struktur der Aktivitäten sowie ein Informationsmodell, das die Zusammenhänge aller erarbeiteten Festlegungen spezifiziert (Gutzwiller 1994). Aus Prozesssicht umfasst eine Methode verschiedene Phasen, die aus einzelnen Gestaltungsschritten bestehen, die wiederum selbst aus Sub-Gestaltungsschritten bestehen können usw. Zu jedem Gestaltungsschritt (oder Teil davon) können einzelne Methoden-


31

komponenten (z. B. Techniken oder Vorgehensmodelle) zugeordnet werden (Punter u. Lemmen 1996). Wenn Methoden zunächst generischen Charakter haben und erweitert bzw. angepasst werden müssen, um auf ein spezifisches Problem angewendet werden zu können, spricht man von situativen Methoden (Brinkkemper 1996). Die Konstruktion einer situativen Methode setzt standardisierte Bausteine (Methodenfragmente (Brinkkemper et al. 1998)) sowie Richtlinien für ihre Komposition voraus. In der Literatur werden dazu verschiedene Konstruktionsprozesse vorgeschlagen (Brinkkemper 1996; Punter u. Lemmen 1996; Brinkkemper et al. 1998; Karlsson u. Ågerfalk 2004). Bucher et al. schlagen auf dieser Basis vor, (Methodenanwendungs-)Situationen durch den jeweiligen Projekttyp und den jeweiligen Kontexttyp zu beschreiben (Bucher et al. 2007): x Aspekte, die einen Einfluss auf das Veränderungsprojekt haben, durch dieses aber nicht direkt beeinflusst werden, werden als Kontextfaktoren bezeichnet. Unterschiedliche Kontextfaktoren können zu „Kontexttypen“ aggregiert werden. Beispiele für Kontextfaktoren von Veränderungsvorhaben sind z. B. Unternehmensgröße, Branche oder Reifegrad in der Anwendung bestimmter Methoden. Diese Kontextfaktoren führen dazu, dass gleichartige Veränderungsvorhaben unterschiedlich konzipiert oder umgesetzt werden, bleiben aber durch die Vorhaben unverändert. x Aspekte, die einen Einfluss auf das Veränderungsprojekt haben und gleichzeitig auch durch dieses berührt werden, werden als Projektfaktoren bezeichnet. Unterschiedliche Projektfaktoren können zu „Projekttypen“ aggregiert werden. Beispiele für Projekttypen sind die fünf in (Baumöl 2005) identifizierten Klassen fachlich getriebener Veränderungsprozesse. Methodische Ansätze für die Gestaltung und Umsetzung von Veränderungsprojekten unterscheiden sich in ihrer Generizität hinsichtlich der unterstützten Projekttypen und in ihrer Generizität hinsichtlich der unterstützten Kontexttypen. Dem Extremfall einer Methode, die nur einen bestimmten Projekttyp in einem bestimmten Kontexttyp unterstützt (z. B. Prozessoptimierung in einem nationalen Großunternehmen der Prozessfertigung) steht der Extremfall einer Methode gegenüber, die verschiedene Projekttypen in verschiedenen Kontexttypen unterstützt (z. B. integrierte Prozess- und Systemumgestaltung in Dienstleistungsunternehmen). Für die Konstruktion situativer (d. h. bei ihrer Anwendung anpassbarer) Methoden schlagen (Bucher et al. 2007) ein vierstufiges Vorgehen vor:

32

Robert Winter

1. Planung der Methode und / oder Evaluation der generischen Methode. Um die Kontexttyp- und Projekttypfaktoren einer Methodenentwicklung einschätzen zu können, bedarf es zumindest einer groben Vorstellung der Methode und ihrer Ergebnisse. 2. Identifikation der Kontexttypfaktoren und Projekttypfaktoren. Dabei ist zu prüfen, ob die identifizierten Faktoren theoretisch oder empirisch fundiert einen Einfluss auf die Methodenkomponenten haben oder ob sie unabhängig von der Methodenanwendung sind. 3. Analyse der Kontexttypen und Projekttypen. Nicht alle Kontexttypen und Projekttypen existieren in der Realität in jeder beliebigen Kombination. Aus diesem Grund müssen die situativen Faktoren analysiert und jene Kombinationen identifiziert werden, die in der Praxis am häufigsten auftreten. Für diese Analyse bzw. Identifikation können statistische Verfahren, wie beispielsweise die Cluster- oder die Faktorenanalyse, eingesetzt werden (vgl. für eine solche Analyse beispielsweise (Bucher u. Winter 2006; Klesse u. Winter 2007)). 4. Konstruktion und Validierung der situativen Methode. Übertragen auf die Problematik der Unterstützung der Konzeption und Umsetzung von Veränderungsvorhaben bedeutet dies, dass eine zu erarbeitende Methode in möglichst vielen Situationen einsetzbar sein sollte, aber gleichwohl über situative Anpassungsmechanismen eine Adaption auf einen bestimmten Kontexttyp und einen bestimmten Projekttyp erlauben sollte. Für Veränderungsvorhaben mit einem größeren Umfang hat Baumöl bereits einen Konstruktionsansatz vorgeschlagen, der nicht nur beschreibt, wie die situativen Faktoren identifiziert werden können, sondern auch, wie die geeigneten Techniken ausgewählt werden können und wie aus den generischen und situativen Techniken die situationsspezifische Methode zusammengesetzt werden kann (Baumöl 2005).

7

Business Engineering am Beispiel des Corporate Performance Management

Im Folgenden wird am Beispiel des Corporate Performance Management gezeigt, wie der ganzheitliche Gestaltungansatz im Bereich der Informationslogistik angewendet werden kann. Die Ausführungen basieren auf den Darstellungen in (Melchert u. Winter 2004; Melchert et al. 2004). Im Sinne von Abschn. 5 kann es sich je nach Ausgangslage um ein „technisch getriebenes Projekt“ oder ein „fachlich getriebenes Projekt“ handeln.


33

Da mit der Kopplung von Prozessmodellierung und Business Intelligence („Process Performance Management“), der Kopplung von Business Intelligence und Applikationsintegration („Real-time Analytics“) und der Kopplung von Prozessmodellierung und Applikationsintegration („Business Process Automation“) drei Enabler für die konsistente Neugestaltung des Performance Management IT-getrieben sind, kann die Gestaltung „bottom-up“ erfolgen. In diesem Fall sind zunächst Integrations-Dienste auf Basis von Applikationsfunktionen zu konstruieren, diese über einen geeigneten Integrationsmechanismus mit Prozess-Spezifikationen zu verknüpfen, um schließlich die für eine Steuerung geeigneten (da mess- und integrierbaren) Ziele und Leistungsindikatoren zu identifizieren. Ein eher bedarfs- (statt angebots-)orientiertes Vorgehen müsste „topdown“ strukturiert sein: Zunächst müssten die Ziele und Leistungsindikatoren spezifiziert werden, nach denen aus fachlicher Sicht gesteuert werden soll. Diese müssten dann – über so genannte Führungsgrößen – auf Prozess-Spezifikationen abgebildet werden. Über einen geeigneten Integrationsmechanismus wären den Prozessaktivitäten Applikationsfunktionen zuzuordnen, um konkrete Messungen „am System“ vornehmen zu können. Je flexibler die Systemunterstützung ausfallen muss, d. h. je häufiger sich die fachlichen Strukturen ändern, desto weitgehender sollte die Systemebene in Form gekapselter, lose gekoppelter Integrationsdienste strukturiert sein. Abbildung 6 illustriert, wie das Business-Metamodell bei der Konstruktion konsistenter und flexibler Lösungen genutzt werden kann. Die Festlegung von Organisationszielen und strategischen Kennzahlen auf Strategieebene ist mit der Festlegung von Prozess-Führungsgrößen und Ablaufbeschreibungen auf Organisationsebene verknüpft. Die Funktionalitäten der verfügbaren Applikationen (z. B. CRM, ERP, SM für Service Management, DWH für Data Warehouse) werden in Form entsprechender Services verfügbar gemacht. Eine Integrations-Infrastruktur sorgt auf der Integrationsebene für die flexible Kopplung von Services und Prozessen. Das Business-Metamodell sowie entsprechende Glossare unterstützen das konsistente Verständnis und die konsistente Gestaltung auch komplexer Strukturen „Business-to-IT“. In Abb. 6 wird bewusst auf gerichtete Kanten zwischen den Gestaltungsobjekten auf Strategie-, Organisations- und Systemebene verzichtet (zumal diese das Business-Metamodell auch nicht vorschreibt). „Topdown“ können die Abhängigkeiten so interpretiert werden, dass strategische Kennzahlen aus Organisationszielen, Prozess-Führungsgrößen aus strategischen Kennzahlen, Ablaufstukturen aus Prozess-Führungsgrößen, Services aus Aktivitätsbeschreibungen und Softwarefunktionalitäten aus Services abzuleiten sind, um ein konsistentes Design zu erreichen.

34

Robert Winter

Marktführende Stellung

Strategie-Ebene

Servicequalität

Hohe Kundenzufriedenheit

Profitabilität

Garantierte Reaktionszeit

Hohe Erlöse

Geringe Kosten

Geschäftsziele Eigene Durchlaufzeit zu Marktmittel

Anteil zufriedener Kunden

Aufwand für AusfallfallMgt.

Eigene Reparaturkosten zu Marktmittel

Prozess-Ebene

Strategische KPIs

Anteil Problemlösungen

Durchschnittl. Diagnosezeit

Prozessorientierte KPIs

Durchschnittl. Reparaturzeit

Durchschn. Reparaturkosten

Durchschn. Rechnungsbetrag

Durchschnittl. Durchlaufzeit

Ausfall- und Störungsbeseitigungs-Management StörungsAufnahme

Untersuchung und Diagnose

Beseitigung des Fehlers

Abschuss des Vorgangs

Rechnungsstellung

Prozess-Ebene

System-Ebene

Integrations-Ebene

Kunden

Ausfall

Servicemitarbeiter

ServiceStörungsAnfor- Beseitigungs- Rechnung derung Bericht

Service-Ebene

CPM CRM

CRM

Applikations-Ebene

HRM

BS

ERP

SM

SM

DWH

Abb. 6. Ganzheitlicher Ansatz zur Gestaltung des Performance Management (in Anlehnung an Melchert et al. 2004)


35

„Bottom-up“ können die Abhängigkeiten dagegen so interpretiert werden, dass Softwarefunktionalitäten die verfügbaren Services determinieren, auf deren Grundlage Ablaufbeschreibungen orchestriert werden, daraus Prozess-Führungsgrößen abgeleitet werden, diese zur Ableitung von Kennzahlen dienen und damit letztlich Organisationsziele unterstützen – ein gleichermaßen konsistentes Design. Natürlich sind auch Zwischenformen denkbar wie z. B. die „top-down“-artige Gestaltung auf Strategie- und Organisationsebene, die „bottom-up“-artige Gestaltung auf ApplikationsEbene und Service-Ebene sowie die Integration dieser Teilstrukturen auf Integrationsebene.

8

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.

36

Robert Winter

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. Brinkkemper, S.: Method Engineering: Engineering of Information Systems Development Methods and Tools, in: Information and Software Technology 38 (1996) 4, S. 275-280. Brinkkemper, S.; Saeki, M.; Harmsen, F.: Assembly Techniques for Method Engineering, in: Advanced Information Systems Engineering: 10th International Conference, CAiSE'98, Pisa, Italy, June 1998, Springer, Berlin et al. 1998, S. 381-400. Bucher, T.; Klesse, M.; Kurpjuweit, S.; Winter, R.: Situational Method Engineering - On the Differentiation of "Context" and "Project Type", in: Proceedings of the IFIP WG8.1 Working Conference on Situational Method Engineering (ME07), Springer, Geneva 2007, S. 33-48. 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. Capgemini: Veränderungen erfolgreich gestalten: Change Management 2005 Bedeutung, Strategien, Trends, http://www.de.capgemini.com/presse/ pressemitteilungen/archiv_2005/change_mgt/?d=211A5124-757F-7FACD807-4A0D0C4A0267, Zugriff am 04.06.2007. 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. Gutzwiller, T.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Physica, Heidelberg 1994. 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. Karlsson, F.; Ågerfalk, P. J.: Method Configuration: Adapting to Situational Characteristics while Creating Reusable Assets, in: Information and Software Technology 46 (2004) 9, S. 619-633. Klesse, M.; Winter, R.: Organizational Forms of Data Warehousing: An Explorative Analysis, in: Proceedings of the 40th Hawaii International Conference on System Sciences (HICSS-40), IEEE Computer Society, Los Alamitos 2007.


37

Martin, J.: Information Engineering. Vol. 1: Introduction, Prentice-Hall, Englewood Cliffs 1989. Melchert, F.; Winter, R.: The Enabling Role of Information Technology for Business Performance Management, in: Meredith B. et al. (Hrsg.): Decision Support in an Uncertain and Complex World, Proceedings of the 2004 IFIP International Conference on Decision Support Systems (DSS2004), 2004, S. 535546. Melchert, F.; Winter, R.; Klesse, M.: Aligning Process Automation and Business Intelligence to Support Corporate Performance Management, in: Romano N. C. J. (Hrsg.): Proceedings of the Tenth Americas Conference on Information Systems (AMCIS 2004), 2004, S. 4053-4063. Ö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. Österle, H.; Winter, R.; Höning, F.; Kurpjuweit, S.; Osl, P.: Business Engineering - Core-Business-Metamodell, in: WISU - Das Wirtschaftsstudium 36 (2007) 2, S. 191-194. Punter, T.; Lemmen, K.: The MEMA-model: towards a new approach for Method Engineering, in: Information and Software Technology 38 (1996) 4, S. 161266. 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

Ökonomische Theorien als Erklärungs- und Gestaltungsgrundlage der Informationslogistik

Moritz Schmaltz, Tobias Bucher Universität St. Gallen

1 2 3 4 5 6 7

1

Einleitung ......................................................................................... 39 Transaktionskostentheorie: Marktliche und hierarchische Koordinationsformen für die Informationslogistik ........................... 40 Agenturtheorie .................................................................................. 45 Spieltheorie ....................................................................................... 49 Netzwerktheorie ............................................................................... 52 Theorie der Verfügungsrechte .......................................................... 57 Zusammenfassung und Ausblick ...................................................... 60 Literatur ............................................................................................ 60

Einleitung

Unternehmen stehen bei der Initiierung und Ausgestaltung der integrierten unternehmensweiten Informationslogistik vor den Herausforderungen, einerseits die Sinnhaftigkeit des Konzepts nachzuweisen und andererseits eine optimale Gestaltungsform für die Informationslogistik zu finden. Die wirtschaftswissenschaftliche Forschung hat in den letzten Jahrzehnten eine Reihe von Theorien entwickelt, die die Koordination wirtschaftlichen Handelns zu erklären versuchen und dabei von wesentlich realitätsnäheren Annahmen ausgehen als die klassische ökonomische Theorie. Dieser Beitrag stellt einige der Theorien dieser Neuen Institutionenökonomie kurz vor und zeigt, inwieweit sie Aussagen bezüglich der Vorteilhaftigkeit unternehmensweiter Informationslogistik und deren Ge-

40

Moritz Schmaltz, Tobias Bucher

staltung ermöglichen. Dem Leser soll damit ein bewusst kurz gehaltener Einblick in den Stand der ökonomischen Forschung gegeben werden und die Anwendbarkeit ausgewählter ökonomischer Theorien anhand praktischer Herausforderungen demonstriert werden. Der Beitrag gliedert sich wie folgt: In Abschn. 2 werden anhand der Transaktionskostentheorie mögliche Koordinationsformen für die Informationslogistik vorgestellt. In den folgenden Abschnitten werden dem Kontinuum ebendieser Koordinationsformen die einzelnen ökonomischen Theorien zugeordnet und ihre Implikationen für die Informationslogistik beleuchtet. Abschnitt 3 behandelt die Agenturtheorie, Abschn. 4 befasst sich mit der Spieltheorie. Die Netzwerktheorie wird in Abschn. 5 vorgestellt und Abschn. 6 diskutiert abschließend die Theorie der Verfügungsrechte.

2

Transaktionskostentheorie: Marktliche und hierarchische Koordinationsformen für die Informationslogistik

2.1 Grundlagen der Transaktionskostentheorie Die Transaktionskostentheorie beschäftigt sich mit der effizienten Allokation ökonomischer Aktivität über verschiedene Organisationsformen. Sie versucht, anhand der bei der Abwicklung von Transaktionen anfallenden Kosten die effiziente Organisation von Austauschbeziehungen zwischen den beteiligten Partnern zu erklären (Coase 1937; Alchian u. Demsetz 1972; Williamson 1989). Hinsichtlich der Transaktionspartner werden das Ziel der individuellen Nutzenmaximierung sowie beschränkte individuelle Rationalität unterstellt. Erstere Annahme bedeutet, dass die Partner unabhängig voneinander versuchen, ihre eigenen Ziele zu erreichen. Es besteht dabei auch das Risiko, dass sich Parteien über die Vereinbarungen zur Abwicklung der Transaktion hinwegsetzen (opportunistisches Verhalten). Unter letzterer Annahme ist zu verstehen, dass Transaktionspartner immer die für sie vorteilhafteste Handlungsalternative wählen, soweit sie dies mit den ihnen zur Verfügung stehenden begrenzten Informationen beurteilen können. An Organisationsformen werden klassisches Vertragsrecht (Marktmechanismen), neoklassisches Vertragsrecht (hybride Formen wie z. B. Unternehmensnetzwerke) und relationale Verträge (Hierarchien, etwa zwischen Konzerneinheiten) unterschieden (Williamson 1979, 1985, 1991). Bei marktlicher Koordination werden die Leistungen und Preise der Trans-

Ökonomische Theorien

41

aktion in Form von klassischen Verträgen festgelegt; die Transaktionspartner sind voneinander unabhängig. Der Preis ist der dominierende Koordinationsmechanismus. Bei hierarchischer Koordination erfolgt die Festlegung von Preisen und Leistungen hingegen auf Anweisung eines der Partner oder einer übergeordneten Instanz. Die vertragliche Regulierung beschränkt sich auf die Festlegung der Rahmenbedingungen und der Weisungsbefugnis („relationale Verträge“); der primäre Koordinationsmechanismus ist die Anweisung. Diese beiden Koordinationsformen bilden die Pole eines Kontinuums (vgl. Abb. 1), das von hybriden Koordinationsmechanismen ausgefüllt wird. Bei hybriden Mechanismen sind die Preise und Leistungen in unterschiedlichem Umfang vertraglich spezifiziert („neoklassische Verträge“). Beispiele für solche Mechanismen sind Rahmenverträge (marktnah) oder Joint Ventures (hierarchienah). rein marktliche Koordination

Maximierung der erwarteten Einzelnutzen Akteure bestimmen ihr Verhalten eigenständig

rein hierarchische Koordination

Maximierung des erwarteten Gesamtnutzens Übergeordnete Instanz schreibt Verhaltensregeln vor

Abb. 1. Kontinuum der Koordinationsformen

Unter Transaktionskosten (TK) versteht man die Kosten, die zur Anbahnung und Abwicklung einer ökonomischen Transaktion aufgewendet werden müssen. Dazu zählen ex ante anfallende Kosten für die Suche und den Vergleich von Anbietern bzw. für die Anbahnung und Verhandlung von Vertragsabschlüssen (Koordinationsproblem) sowie ex post anfallende Kosten für die Überwachung und Durchsetzung von Verträgen (Motivationsproblem). Diese Kosten sind zur effizienten Abwicklung von Transaktionen zu minimieren. Die Ausgestaltung der Transaktionsbedingungen ist auf Grund der unvollständigen Informationslage der beteiligten Partner per se unvollständig – Eventualitäten, die bei Vertragsschluss nicht bekannt sind, können auch nicht geregelt werden. Zudem entstehen durch die Transaktion Abhängigkeiten zwischen den Partnern, deren Umfang von den Eigenschaften der Transaktion abhängt. Diese Abhängigkeiten führen insbesondere bei marktlicher Koordination zu der Gefahr von opportunistischen Handlungen seitens der Vertragspartner („Holdup“). Von einem Holdup wird dann

42


gesprochen, wenn derjenige Partner, der am wenigsten von den anderen Beteiligten abhängig ist, den nicht vertraglich geregelten Spielraum ausnutzt und eine Änderung der Vertragsbedingungen zu seinen Gunsten erzwingt. Diese Anpassung des Vertrags führt zu hohen zusätzlichen Transaktionskosten. Hierarchische Koordinationsformen ermöglichen es über ihre Kontrollmechanismen, die Wahrscheinlichkeit opportunistischen Verhaltens zu verringern. Allerdings führen sie im Vergleich zur marktlichen Koordination zu höheren Transaktionskosten, da durch den teilweisen Wegfall des Preismechanismus mit suboptimaler Faktorallokation gerechnet werden muss und da die administrativen Strukturen der Hierarchie Kosten verursachen. Transaktionen weisen eine Anzahl von Eigenschaften auf, die die Wahl der kostenminimalen Koordinationsform beeinflussen. Die wichtigste Eigenschaft ist der Umfang an transaktionsspezifischen Investitionen, z. B. in spezialisierte Maschinen, die zur Realisierung der Transaktion erforderlich sind (Williamson 1979, S. 239ff.; 1991, S. 281). Die spezifischen Investitionen lassen sich anderweitig nicht weiterverwenden und gelten damit als versunkene Kosten („sunk costs“). Das Vorliegen von spezifischen Investitionen erhöht die Abhängigkeit und das Risiko von Holdups. Dieses Risiko erfordert zusätzliche Sicherheitsleistungen oder vertragliche Vereinbarungen, die zusammen mit den Kosten für Vertragsanpassungen die Transaktionskosten bei marktlicher Koordination schnell ansteigen lassen. Da diese Kosten bei hierarchischer Koordination auf Grund der Weisungsbefugnis einer Partei geringer sind, wird ab einem bestimmten Grad an spezifischen Investitionen die hierarchische Koordination vorteilhafter. In Abb. 2 ist dieser Verlauf der Transaktionskosten für die drei Koordinationsformen dargestellt, wobei Tm die Transaktionskosten bei marktlicher Koordination, Tx die einer hybriden Koordinationsform und Th den hierarchischen Fall beschreiben. Ab dem Grad von spezifischen Informationen k1 wird die hybride Koordination vorteilhaft, ab k2 die hierarchische Koordination. Obgleich die Spezifität von Investitionen den dominierenden Einflussfaktor auf die Transaktionskosten darstellt, ergeben sich ähnliche Kosteneffekte auch für andere Eigenschaften von Transaktionen, nämlich Unsicherheit, Häufigkeit und Messbarkeit: x Die Unsicherheit einer Transaktion beschreibt das Risiko von unvorhergesehenen Umwelteinflüssen bzw. Änderungen der Rahmenbedingungen. Da diese im Vertrag nicht spezifiziert werden können, erhöhen sie das Risiko von Holdups. Auch bei steigender Unsicherheit führen die


Tm(k)

k1

Tx(k)

43

Th(k)

k2

Transaktionsspezifische Investitionen Abb. 2. Transaktionskosten bei spezifischen Investitionen (Williamson 1991)

Kosten für die Kontrolle dieses Risikos dazu, dass hybride oder hierarchische Koordination kostenminimal wird. x Die Häufigkeit der Transaktion kann die Transaktionskosten reduzieren, wenn durch angepasste Rahmenverträge o. ä. die Vollständigkeit des Vertrags erhöht wird und damit das Risiko opportunistischen Verhaltens sinkt. x Schließlich unterscheiden sich Transaktionen in ihrer Messbarkeit, d. h. in der Zurechenbarkeit des geschaffenen Werts und in ihrer Interdependenz, d. h. in der Abhängigkeit von anderen Transaktionen (Jost 2004, S. 1450f.). In all diesen Fällen ist aber bei geringen spezifischen Investitionen davon auszugehen, dass die Marktmechanismen wirksam bleiben und eine hierarchische Koordination nicht erforderlich ist. 2.2 Koordination der Informationslogistik Die Informationslogistik umfasst „die Planung, Steuerung, Durchführung und Kontrolle der Gesamtheit der Datenflüsse (…), die über eine Betrach-

44


tungseinheit hinausgehen, sowie die Speicherung und Aufbereitung dieser Daten“ (vgl. Kap. 1). Die an der Informationslogistik beteiligten Organisationseinheiten erstellen Informationsprodukte (bspw. Analysen und Reports), wobei Teile der Produkte bei einer dezentralen Organisation nur unter erheblich höheren Kosten produziert werden können als bei zentraler Koordination. Die für die Produktion genutzten Daten stammen vorwiegend aus unternehmensinternen Quellen. Die Abnehmer der Informationsprodukte sind ebenfalls Organisationseinheiten des Unternehmens; teilweise sind sie mit den Datenlieferanten identisch. Es werden also immer mindestens zwei Akteure (Organisationseinheiten) betrachtet, die Daten austauschen. Jeder Akteur kann Datenlieferant oder Datenbezieher sein. Die Zusammenarbeit der Parteien ist dabei langfristig angelegt. Für die Informationslogistik im Unternehmen existieren verschiedene mögliche Koordinationsformen. Gemäß dem in Abb. 1 dargestellten Kontinuum der Koordinationsformen können die Beziehungen zwischen den Organisationseinheiten eher marktorientiert oder eher hierarchisch sein. Bei marktlicher Koordination handelt jeder einzelne Akteur individuell rational und ökonomisch und versucht, seinen Eigennutzen zu maximieren. Im Fall einer hierarchischen Koordination handelt der übergeordnete, koordinierende Akteur (z. B. eine Organisationseinheit, die die unternehmensweite Informationslogistik steuert) rational und ökonomisch, d. h. er maximiert den erwarteten Gesamtnutzen. Dies geht einher mit einem unterschiedlichen Grad an Handlungsautonomie der Akteure. Bei marktlicher Koordination sind sie in ihren Entscheidungen eigenständig, während anderenfalls durch den übergeordneten Akteur Verhaltensregeln vorgeschrieben werden. Jede der im Folgenden diskutierten Theorien geht von bestimmten Prämissen aus, die sich in diesem Kontinuum der Koordinationsformen einordnen lassen. Um die Einschlägigkeit der theoretischen Überlegungen für eine bestimmte Situation einzuschätzen, muss daher geprüft werden, inwieweit diese Prämissen in der konkreten Situation tatsächlich erfüllt werden. Wirtschaftswissenschaftliche Theorien geben Hinweise auf das zu erwartende Verhalten der Akteure bei verschiedenen Koordinationsmechanismen und Rahmenbedingungen: Die in Abschn. 3 diskutierte Agenturtheorie geht von hybrider bis hierarchischer Koordination mit teilweiser Handlungsautonomie aus. Während die Spieltheorie autonome Akteure mit wiederholter, längerfristiger Zusammenarbeit und damit einer zumindest in Teilen marktlichen Koordination annimmt (vgl. Abschn. 4), geht die in Abschn. 5 diskutierte Netzwerktheorie von unabhängigen Partnern und rein marktlicher Koordination aus. Gleiches gilt auch für die in Abschn. 6 dargestellte Theorie der Verfügungsrechte.


3

45

Agenturtheorie

3.1 Grundlagen der Agenturtheorie Die Agenturtheorie („Prinzipal-Agenten-Theorie“) befasst sich mit der Ausgestaltung von vertraglichen Beziehungen zwischen zwei Parteien bei asymmetrischer Informationsverteilung und unterschiedlichen Risikoneigungen der Parteien (vgl. Abb. 3, Jensen u. Meckling 1976, S. 308ff.; Kräkel 2004, S. 1174ff.). In diesen Beziehungen beauftragt ein Prinzipal einen Agenten, bestimmte Tätigkeiten auszuführen und kompensiert ihn dafür. Beide Parteien streben danach, ihren Nutzen unter der gegebenen Informationslage zu maximieren. In diesem Zusammenhang wird unterstellt, dass Prinzipal und Agent divergierende Ziele verfolgen, dass also eine kollektive Nutzenmaximierung nicht ohne Weiteres möglich ist. Dies ist z. B. dann der Fall, wenn die Erfüllung der Aufgaben durch den Agenten mit Aufwand verbunden ist („Arbeitsleid“), welchen der Agent zu minimieren versucht, oder wenn der Agent höhere Entlohnung zu erreichen trachtet, als auf Grund der Qualität seiner Arbeit gerechtfertigt wäre. Zudem wird für den Agenten eine größere Risikoaversion angenommen als für den Prinzipal. Dies wird damit begründet, dass der Agent i. d. R. seine Arbeitsleistung nicht in dem Maße diversifizieren kann wie der Prinzipal sein Portfolio an Agenten (Eisenhardt 1989, S. 58). Der Prinzipal hat nur unvollständige Informationen über das Verhalten des Agenten. Daher kann es zu verschiedenartigen Versuchen des Agenten kommen, seine Ziele auf Kosten des Prinzipals durchzusetzen (Kräkel 2004, S. 1175-1177). Agenturtheorie: Maximierung der erwarteten Einzelnutzen Prinzipal erteilt Auf träge an den Agenten Prinzipal überwacht die Auf tragserledigung durch den Agenten

rein marktliche Koordination

Abb. 3. Annahmen der Agenturtheorie


46


Im Fall von sog. „Hidden Action“ ist das Verhalten des Agenten (d. h. die Ausführung der beauftragten Tätigkeiten) durch den Prinzipal nicht zu beobachten. Zugleich ist die Zurechnung der Arbeitsergebnisse zwischen exogenen Faktoren (bspw. Marktumfeld und Zufallseinflüsse) und der Arbeit des Agenten nicht vollständig möglich (Ross 1973). Der Agent versucht in diesem Fall, einen geringeren Arbeitseinsatz zu wählen und das mindere Ergebnis mit den exogenen Faktoren zu begründen. Der Prinzipal hat in dieser Situation zwei Möglichkeiten, den ihm entgangenen Nutzen zu minimieren (Eisenhardt 1989, S. 59f.): Er kann einerseits versuchen, über die Gestaltung von Anreizsystemen seine Ziele und die des Agenten in Übereinstimmung zu bringen. Dies geschieht dadurch, dass der Vertrag weniger über das Verhalten des Agenten (d. h. für den Prinzipal zu arbeiten) geschlossen wird, sondern vielmehr über das Ergebnis dieses Verhaltens (z. B. Ablieferung eines wohldefinierten Produkts in einer genau spezifizierten Menge und Qualität). Allerdings wird durch diese Art der Vertragsgestaltung das Risiko bezüglich der exogenen Faktoren auf den Agenten verlagert. Risikoaverse Agenten verlangen hierfür eine Prämie, was zusammen mit dem Aufwand für die Messung des Outputs wiederum die Kosten für den Prinzipal erhöht. Die andere Möglichkeit ist, dass der Prinzipal durch den Einsatz von bestimmten Kontrollmechanismen das Verhalten des Agenten beobachtbar macht und damit seine eigene Informationslage verbessert. Da der Agent weiß, dass opportunistisches Verhalten entdeckt und sanktioniert werden kann, wird dieses für ihn unattraktiv. Für den Prinzipal entstehen auch in diesem Fall Kosten für die Messung des Verhaltens. Im Fall von sog. „Hidden Information“ versucht der Agent, vor oder nach Vertragsschluss den Prinzipal über seine wahren Eigenschaften (z. B. persönliche Fähigkeiten oder Qualität der Arbeit) zu täuschen. Durch das Suggerieren von Eigenschaften, die für den Prinzipal attraktiver sind als die tatsächlich gegebenen Eigenschaften, versucht der Agent, eine höhere Kompensation zu erlangen. Hier existieren vom Agenten und vom Prinzipal ausgehende Lösungsansätze. Überdurchschnittliche Agenten werden bestrebt sein, ihre Eigenschaften dem Prinzipal zu kommunizieren („Signaling“). Andererseits kann auch der Prinzipal Maßnahmen ergreifen, um die Agenten zur Kommunikation ihrer Eigenschaften zu bewegen („Screening“). Dies kann z. B. über Selbstselektionsmechanismen geschehen, die den Prinzipal zur Auswahl einer seinen Motiven entsprechenden Vertragsform bewegen. In beiden Fällen entsteht für den Prinzipal ein Trade-Off zwischen den Kosten für das Messen des Verhaltens des Agenten einerseits und für das Messen der Ergebnisse und den Risikotransfer andererseits.


47

3.2 Implikationen für die Vorteilhaftigkeit der Informationslogistik Die Übertragung und Anwendung der Agenturtheorie auf den Kontext der unternehmensweiten Informationslogistik impliziert, dass die an der Informationslogistik beteiligten Akteure (Betrachtungseinheiten wie Unternehmen, Organisationseinheiten, Stellen) verschiedene Rollen einnehmen und divergierende Ziele verfolgen. Wie bereits erwähnt, sind an unternehmensweiter Informationslogistik stets zumindest zwei Akteure direkt beteiligt, die Daten austauschen. Diese Akteure sind entweder ausschließlich Datenlieferant, ausschließlich Datenbezieher oder gleichzeitig sowohl Datenlieferant als auch Datenbezieher. Datenbezieher stehen dabei in einer Abhängigkeit zu Datenlieferanten, auf deren Kooperation bzw. Bereitschaft zum (unter Umständen einseitigen) Datenaustausch sie angewiesen sind. Dazu zählen insbesondere die Fachabteilungen eines Unternehmens, die im Zuge der Ausführung betrieblicher Prozesse Daten produzieren und/oder konsumieren. Als Beispiele hierfür seien die für Einkauf, Produktion, Vertrieb, Marketing und Service zuständigen Organisationseinheiten genannt. Analog gilt dies auch für eigenständige Unternehmen, die in einem Wertschöpfungsnetzwerk miteinander verbunden sind. Es liegt in der Natur des ein- oder beiderseitigen Datenaustauschs zwischen den direkt an der unternehmensweiten Informationslogistik beteiligten Akteuren, dass nicht alle Beteiligten in gleichem Maße profitieren können. So ist bspw. zu vermuten, dass Organisationseinheiten, die Kunden- und/oder Produktdaten von allgemeiner Relevanz und Gültigkeit besitzen (d. h. Vertriebs- und Marketing-Organisationseinheiten), a priori besser gestellt sind als andere Abteilungen. Folgerichtig haben diese Organisationseinheiten nur geringe Anreize, sich an unternehmensweiter Informationslogistik zu beteiligen. Demgegenüber haben andere Organisationseinheiten, die auf kunden- und produktbezogene Daten angewiesen sind, diese selbst jedoch nicht besitzen, einen deutlich höheren Anreiz zur Beteiligung. Insellösungen, d. h. lokale Datenhaltung und Abschottung gegenüber anderen Organisationeinheiten oder bilaterale Vereinbarungen über den Austausch relevanter Daten, führen jedoch stets zu Wohlfahrtsverlusten. Aus diesem Grund müssen die Akteure durch einen Prinzipal mittels entsprechender (neoklassischer oder relationaler) Verträge zur Beteiligung an der unternehmensweiten Informationslogistik „gezwungen“ werden. Nur so kann die Gesamtwohlfahrt im betrachtungseinheitübergreifenden Kontext gesteigert werden.

48


3.3 Implikationen für die Gestaltung der Informationslogistik In diesem Zusammenhang ist zunächst unklar, welcher der genannten Akteure die Rolle des Prinzipals und welcher die Rolle des Agenten einnimmt. Grundsätzlich beauftragt ein Prinzipal einen Agenten, gegen Kompensation bestimmte Tätigkeiten für ihn auszuführen. Folgerichtig müssten diejenigen Akteure, die überwiegend als Datenbezieher auftreten, diejenigen Akteure, die überwiegend als Datenlieferanten fungieren, beauftragen, sich an der unternehmensweiten Informationslogistik zu beteiligen und diese gleichzeitig dafür kompensieren. Dies wirft jedoch gleich mehrere Fragen auf: Haben die Datenbezieher überhaupt die Möglichkeit und / oder die Kompetenz, die Datenlieferanten mit der Herausgabe von Daten zu beauftragen, die Einhaltung einer entsprechenden Vereinbarung zu überwachen und ggf. Fehlverhalten zu sanktionieren? Wer soll mit der Koordination mehrerer Datenbezieher und mehrerer Datenlieferanten betraut werden, so dass die Entstehung von Insellösungen verhindert werden kann? Wie können Form und Höhe einer adäquaten Kompensation ermittelt werden? Auf Grund dieser Schwierigkeiten erscheint es sinnvoll, die Existenz eines dritten Akteurs vorauszusetzen, welcher nur indirekt an der Informationslogistik beteiligt ist, jedoch auf Grund der hierarchischen Koordinationsform Weisungsbefugnis gegenüber den direkt beteiligten Akteuren besitzt. Als Beispiele für einen solchen dritten Akteur sind leitende Funktionen bzw. Bereiche (Konzernzentrale, Unternehmensführung) oder zentrale IT-Organisationseinheiten mit Kompetenzen bezüglich unternehmensweiter Informationslogistik zu nennen (vgl. Kap. 5). Eine solche übergeordnete Instanz wäre in der Lage, die Rolle eines Prinzipals zu übernehmen und die Agenten – sowohl die Datenbezieher als auch die Datenlieferanten – zur Beteiligung an der unternehmensweiten Informationslogistik zu verpflichten. Damit kommt dieser übergeordneten Instanz die Aufgabe zu, mit dem Ziel der Steigerung der Gesamtwohlfahrt Synergien durch unternehmensweite Informationslogistik zu heben. In diesem Zusammenhang sind geeignete Anreizmechanismen für die Beteiligung der Agenten zu etablieren, etwa durch die zielgruppenadäquate Kommunikation der Bedeutung und der Nutzeneffekte der unternehmensweiten Informationslogistik oder durch angemessene Kompensation für die Lieferung von Daten.


4

49

Spieltheorie

4.1 Grundlagen der Spieltheorie Die Spieltheorie beschäftigt sich mit Entscheidungssituationen, in denen zwei oder mehr Akteure („Spieler“) unabhängig voneinander Entscheidungen treffen. Sie gestattet die Modellierung solcher Entscheidungssituationen und ermöglicht es, Aussagen über den zu erwartenden Ausgang zu treffen (Bester 2004, S. 1342). Dabei wird angenommen, dass die Spieler unabhängig voneinander agieren und beschränkt rational handeln. Allerdings wird von langfristiger Zusammenarbeit ausgegangen, was z. B. zu Reputationseffekten führen kann. Daher liegt hier keine rein marktliche Koordination vor (vgl. Abb. 4). Die Spieltheorie wird häufig auf die Analyse ökonomischer Interaktion angewandt. Sie ermöglicht die strategische Analyse von Entscheidungssituationen, da sie die Präferenzen und Handlungen der anderen Teilnehmer expliziert. Neben Situationen mit vollständiger Information der Akteure über Nutzen und Handeln der anderen Teilnehmer existieren auch Erweiterungen der Theorie für Situationen mit unvollständiger Information oder ohne Möglichkeit zur Absprache unter den Akteuren (Bester 2004, S. 1343). Als klassisches Problem der Spieltheorie wird an dieser Stelle das Gefangenendilemma vorgestellt (Rapoport u. Chammah 1965; Axelrod 1984). Die Beschreibung folgt der Normalform für die Darstellung von Spielsituationen. In Tabelle 1 sind jeweils die beiden Verhaltens- bzw. Wahlmöglichkeiten der Spieler und in den inneren Zellen die KonsequenSpieltheorie: Maximierung der erwarteten Einzelnutzen Akteure bestimmen ihr Verhalten eigenständig Wiederholtes Spiel, d. h. langf ristige Zusammenarbeit


Abb. 4. Annahmen der Spieltheorie


50


zen („Auszahlungsmatrix“) für die Spieler als Tupel (Auszahlung für Spieler 1, Auszahlung für Spieler 2) dargestellt. Tabelle 1. Beispielhafte Auszahlungsmatrix des Gefangenendilemmas

Spieler 1

Schweigen Gestehen

Spieler 2 Schweigen Gestehen (-1, -1) (-5, 0) (0, -5) (-4, -4)

Das Gefangenendilemma geht von zwei Gefangenen aus, die gemeinsam ein Verbrechen begangen haben und dafür belangt werden sollen. Sie werden getrennt voneinander befragt, d. h. sie haben keine Möglichkeit zur Absprache. Während dieser Befragungen haben beide Akteure die Möglichkeit, das Verbrechen zu gestehen oder zu schweigen. Falls beide Gefangene schweigen, werden sie aus Mangel an Beweisen jeweils zu einer Strafe von einem Jahr Freiheitsentzug verurteilt. Sollte nur einer der beiden Akteure gestehen, kann er als Kronzeuge straffrei ausgehen, und der nicht geständige Gefangene muss für fünf Jahre ins Gefängnis. Falls beide Akteure gestehen, beträgt die Freiheitsstrafe jeweils vier Jahre. Wenn den Spielern diese Auszahlungsmatrix bekannt ist, werden beide Akteure in dieser Situation das Verbrechen gestehen, da unabhängig von der Handlung des Anderen das Gestehen zu einer geringeren Freiheitsstrafe führt als das Schweigen (vier Jahre im Vergleich zu fünf Jahren, wenn der andere Akteur gesteht, und Straffreiheit im Vergleich zu einem Jahr, wenn der andere Akteur schweigt). Gestehen ist daher die dominante Strategie. Die Kombination (Gestehen, Gestehen) bildet zudem ein so genanntes Nash-Gleichgewicht, in dem es keinem der Spieler möglich ist, sich durch einseitiges Ändern seines Handelns besser zu stellen (Nash 1950, S. 49). Dabei wird in dieser Situation offensichtlich nicht der Gesamtnutzen maximiert; das Nash-Gleichgewicht ist Pareto-ineffizient. Die Akteure könnten sich gemeinsam besser stellen, wenn sie beide schweigen würden. Die Kombination (Schweigen, Schweigen) stellt die gesellschaftlich optimale Handlungsalternative dar („Pareto-Optimum“), ist jedoch kein Nash-Gleichgewicht. Durch einseitiges Abweichen (d. h. durch einseitiges Gestehen) kann sich jeder der beiden Akteure individuell besser stellen (Straffreiheit im Vergleich zu einem Jahr Freiheitsstrafe), wobei der andere Akteur jeweils deutlich schlechter gestellt würde (fünf Jahre Freiheitsstrafe im Vergleich zu einem Jahr). Das gesellschaftliche Optimum (Schweigen, Schweigen) ist nur bei wiederholtem Spiel zu erreichen. Beide Spieler haben in jeder Spielperiode den Anreiz, sich durch Schweigen Reputation zu erwerben, was seitens des anderen Spielers in der Folgeperiode ebenfalls durch Schweigen honoriert


51

werden wird. Weicht ein beliebiger Spieler von dieser Strategie ab, so würde dieses Fehlverhalten in der Folgeperiode durch den jeweils anderen Spieler sanktioniert werden („tit-for-tat-Strategie“). Schlussendlich würden sich so beide Spieler verschlechtern; anstelle des Pareto-Optimums würde das Pareto-ineffiziente Nash-Gleichgewicht erreicht. 4.2 Implikationen für die Vorteilhaftigkeit der Informationslogistik Um die Analyseergebnisse des Gefangenendilemmas auf den Kontext der unternehmensweiten Informationslogistik übertragen zu können, müssen zunächst Annahmen bezüglich der Auszahlungsmatrix getroffen werden. Tabelle 2 zeigt die bereits bekannte Auszahlungsmatrix in allgemeiner Form. Die Spieler haben zwei Handlungsalternativen, die als Kooperation und Defektion (d. h. Nicht-Kooperation) bezeichnet werden. Wenn beide Spieler kooperieren, erhalten sie den Auszahlungsbetrag R („reward“). Wenn ein Spieler kooperiert und der andere Spieler defektiert, erhält ersterer die Auszahlung S („sucker’s payoff“) und letzterer den Auszahlungsbetrag T („temptation“). Defektieren beide Spieler, erhalten beide die Auszahlung P („punishment“). Dabei muss folgende Ungleichung gelten: T > R > P > S (Axelrod 1984). Tabelle 2. Auszahlungsmatrix für die unternehmensweite Informationslogistik

Spieler 1

Kooperation Defektion

Spieler 2 Kooperation Defektion (R, R) (S, T) (T, S) (P, P)

Die Sicherstellung des Vorliegens einer derartigen Auszahlungsmatrix ist die Aufgabe einer übergeordneten, koordinierenden Organisationseinheit. Im Kontext der Informationslogistik wird die Handlungsalternative „Kooperation“ als Beteiligung einer Betrachtungseinheit am Datenaustausch (als Datenbezieher und / oder als Datenlieferant) interpretiert, während die Handlungsoption „Defektion“ der Abschottung bzw. dem Ausschluss einer Betrachtungseinheit von der unternehmensweiten Informationslogistik (und damit einer Verweigerung des Datenaustauschs) entspricht. Die unterstellte Auszahlungsmatrix impliziert, dass eine Kooperationsstrategie, d. h. die Beteiligung aller Betrachtungseinheiten an der unternehmensweiten Informationslogistik, die gesellschaftlich bzw. kollektiv optimale Handlungsalternative darstellt. Durch den Austausch und die ge-

52


meinsame Nutzung von Daten können Synergien gehoben werden: „Das Ganze ist mehr als die Summe seiner Teile“ (Aristoteles). 4.3 Implikationen für die Gestaltung der Informationslogistik Für die Gestaltung der unternehmensweiten Informationslogistik ergeben sich aus der Analyse des Gefangenendilemmas relevante Implikationen bezüglich der Etablierung von Kooperationsanreizen, d. h. von Mechanismen, die eine Beteiligung der einzelnen Betrachtungseinheiten am Datenaustausch fördern: x Fristigkeit: Unternehmensweite Informationslogistik ist als wiederholtes Spiel zu verstehen, d. h. es sollten der Aufbau langfristiger Kooperationsbeziehungen und wechselseitiges Vertrauen zwischen den an der Informationslogistik beteiligten Betrachtungseinheiten angestrebt werden. So wird es bspw. in einem Unternehmen, das Beteiligungen kurzfristig erwirbt und veräußert, oder in einem losen Unternehmensnetzwerk deutlich schwieriger sein, derartige Kooperationsanreize zu setzen, als dies in einem organisch wachsenden Unternehmen bzw. in einer Konzernstruktur möglich ist. x Kommunikation der Nutzeneffekte: Die Nutzeneffekte der unternehmensweiten Informationslogistik müssen klar kommuniziert und den Kosten von Insellösungen gegenübergestellt werden. Nur wenn alle Beteiligten erkennen, dass sie gemeinsam eine signifikante Verbesserung in Bezug auf die Befriedigung ihrer Informationsbedürfnisse erreichen können, ohne dass ein beliebiger beteiligter Akteur durch die Beteiligung an der unternehmensweiten Informationslogistik schlechter gestellt werden würde, ist eine langfristige Kooperation aufrecht zu erhalten. x Sanktionierung: Fehlverhalten im Sinne einseitiger Abkopplung vom Datenaustausch muss in jedem Fall sanktioniert werden. Dies gilt insbesondere, wenn eine Organisationseinheit versuchen würde, sich weiterhin als Datenbezieher an der unternehmensweiten Informationslogistik zu beteiligen, jedoch selbst keine Daten mehr liefert („free riding“).

5

Netzwerktheorie

5.1 Grundlagen der Netzwerktheorie Bei vielen Gütern steigt der Nutzen des Guts, wenn die Zahl der Nutzer ebendieses Guts steigt. Die Nutzer des Guts bilden ein Netzwerk; die zusätzlichen Nutzeneffekte werden als Netzeffekte bezeichnet. Das Netzwerk


53

wird anhand der Kompatibilität der Einheiten des Guts abgegrenzt: Das Netzwerk bilden die Nutzer aller Einheiten des Guts (u. U. auch verschiedener Hersteller), die zusammen verwendet werden können, was durch Standards sichergestellt wird. Die Netzwerktheorie geht auf Anbieter- und Nachfragerseite von unabhängigen Akteuren aus, die im Rahmen der ihnen zur Verfügung stehenden Informationen rational handeln und auf die Maximierung ihres individuellen Nutzens bedacht sind (vgl. Abb. 5). Netzwerktheorie: Maximierung der erwarteten Einzelnutzen Akteure bestimmen ihr Verhalten eigenständig



Abb. 5. Annahmen der Netzwerktheorie

Es werden direkte Netzeffekte und indirekte Netzeffekte unterschieden. Direkte Netzeffekte entstehen durch einen „direkten physischen Effekt“ (Katz u. Shapiro 1985, S. 424) der Nutzerzahl auf die Qualität des Guts, wie etwa im Fall der Anzahl der Nutzer eines Telefonnetzes. Geht man davon aus, dass die Nutzer des Netzwerkguts miteinander Kontakt aufnehmen wollen, nimmt der Nutzen bei steigender Größe des Netzwerks dadurch zu, dass dem Nutzer eine zunehmende Anzahl potenzieller Kommunikationspartner zur Verfügung steht. Diese Art von Netzeffekten entsteht in Kommunikationsnetzen, zu denen z. B. auch die Gemeinschaft der Nutzer einer bestimmten Software, die Dateien austauschen können, gehört (Katz u. Shapiro 1994, S. 96). Indirekte Netzeffekte entstehen bei komplementären Gütern, die dem Nutzer nur in Kombination mit anderen Gütern Nutzen stiften. Diese Güterkombinationen werden von Katz und Shapiro als „Hardware“ und „Software“ bezeichnet, wobei neben Computersystemen – der traditionellen Domäne dieser Begriffe – auch Kombinationen wie Anlagegüter und dazugehöriger Service oder Fernsehgeräte und die dazugehörigen Fernsehprogramme analoge Eigenschaften aufweisen (Katz u. Shapiro 1994, S. 97f.). Im Fall dieser Güter entstehen keine direkten Netzeffekte, d. h. eine

54


steigende Zahl von Computer- oder Fernseherbesitzern führt nicht zu direktem Mehrwert, da keine direkten, bilateralen Austauschbeziehungen zwischen den Nutzern bestehen. Allerdings führt eine steigende Nutzerzahl des „Hardware“-Guts zu einer höheren Verfügbarkeit bzw. Qualität und niedrigeren Preisen von komplementären Gütern oder Dienstleistungen, der „Software“. In die Entscheidung eines Kunden, der bislang noch keinem Netzwerk angehört, für ein Produkt und damit für das zugehörige Netzwerk, gehen neben den Kosten des Produkts bzw. der Standardisierung auch seine Erwartungen an den zukünftigen Nutzen durch weitere Netzwerkteilnehmer ein. Falls die Kunden schon Mitglieder verschiedener, inkompatibler Netzwerke sind, stellt sich die Frage nach einer Standardisierung, d. h. nach dem Wechsel zu einem gemeinsamen Netzwerk. Die Entscheidung der Individuen wird hierbei von der Präferenz für einen bestimmten Standard und von den Anreizen für die Standardisierung beeinflusst (Picot et al. 2001). Die Präferenz für einen Standard wird von den Eigenschaften des Standards und von bereits getätigten Investitionen (in Komplementärprodukte, Ausbildung von Mitarbeitern, etc.) beeinflusst. Die Anreize für die Standardisierung setzen sich zusammen aus den Netzeffekten und den Kosten für die Auswahl des gemeinsamen Standards und für einen eventuellen Wechsel (Arthur 1989). Je nach Standardisierungskosten und -nutzen (d. h. Höhe der Netzeffekte) können unterschiedliche Konstellationen eintreten. So können sich ein, mehrere oder gar kein Standard durchsetzen, was auch von den Beziehungen zwischen den beteiligten Individuen abhängt (Weitzel et al. 2006). Auf Seite der Anbieter der Netzwerkgüter ergeben sich unterschiedliche Anreize zur Herstellung von Kompatibilität, d. h. zur Standardisierung. Unter bestimmten Voraussetzungen ist die industrieweite Standardisierung dabei gesamtwirtschaftlich vorteilhaft, aber nicht unbedingt für die standardisierenden Unternehmen (Katz u. Shapiro 1985, S. 435). 5.2 Implikationen für die Vorteilhaftigkeit der Informationslogistik Die Befunde der Netzwerktheorie sind nicht ohne weiteres auf die Ausgestaltung der Informationslogistik übertragbar – einige der Annahmen treffen zu, andere nicht, so dass Analogieschlüsse nur mit der gebotenen Vorsicht statthaft scheinen. An unternehmensweiter Informationslogistik sind stets zumindest zwei Organisationseinheiten direkt beteiligt, die Daten austauschen. Diese Organisationseinheiten können entweder ausschließlich Datenlieferant (und


55

damit Anbieter von Informationslogistik-Leistungen), ausschließlich Datenbezieher (und damit Kunde) oder gleichzeitig sowohl Datenlieferant als auch Datenbezieher sein. Marktstruktur: Problematisch ist die Übertragung der Annahmen bezüglich der Marktstruktur aus der Literatur auf die Informationslogistik. Es wird auf der Anbieterseite davon ausgegangen, dass mehrere unabhängige, profitmaximierende Anbieter bestehen. Diese Konstellation kann in einem nach marktlichen Kriterien geführten, divisionalisierten Unternehmen durchaus in Teilen anzutreffen sein. Hier entsprechen die dezentralen Anbieter von Informationslogistikleistungen innerhalb einzelner Unternehmensbereiche den Anbietern (vgl. Abschn. 2.2). Ein zentralisierter Leistungserbringer entspräche einem Monopolisten, der nach der Einigung auf einen globalen Standard entsteht. Allerdings kann auch in divisionalisierten Unternehmen von einem gewissen Maß an übergreifender Koordination ausgegangen werden – dies würde die Annahme unabhängiger Anbieter verletzen. Zu vermuten ist, dass in diesem Fall eine Standardisierung eher zu Stande kommt als bei vollständig unabhängigen Anbietern. Auch aus der Kundenperspektive sind vorderhand Analogien sichtbar: Es werden unabhängige, nutzenmaximierende Kunden angenommen. Analog können hier die Organisationseinheiten, die die Informationslogistik bereitstellen, als Kunden verstanden werden, die sich frei für eine Standardisierung entscheiden können. Dies ist in vielen dezentral organisierten Unternehmen zu beobachten, wo die Organisationseinheiten hohe Autonomie genießen. Diese Annahme vernachlässigt allerdings die Möglichkeit einer zentralen Koordination durch die Konzernzentrale. Netzeffekte: Die Schaffung einer unternehmensweiten Informationslogistik mit einer integrierten IT-Architektur kann als Analogon zu einer Standardisierung in einem Netzwerk gesehen werden, da sie den Austausch von Daten über die lokalen Einheiten hinweg ermöglicht. Bei einer zentralen Informationslogistik können daher Netzeffekte beobachtet werden. Einerseits entstehen direkte Netzeffekte durch die Verfügbarkeit zusätzlicher Daten in einer zentralen IL. Insbesondere können bestimmte Produkte der Informationslogistik bei zentraler bzw. standardisierter Informationslogistik wesentlich günstiger verwirklicht werden. Andererseits entstehen indirekte Netzeffekte, ähnlich wie dies bei anderer Standardsoftware zu beobachten ist: Die Nutzer können von besseren Schulungsangeboten, günstigeren Einkaufskonditionen, günstigeren Betriebskosten und u. U. geteilter Infrastruktur profitieren. Zu hinterfragen ist in diesem Zusammenhang, ob der Nutzen bei zunehmender Teilnehmerzahl im Netzwerk für alle Teilnehmer gleich stark steigt – möglicherweise bieten Daten aus anderen Unternehmensteilen für dezentrale Organisationseinheiten keinen

56


besonderen Mehrwert, was eine Standardisierung weniger attraktiv erscheinen lässt. Verhalten der Marktteilnehmer: Die Literatur geht davon aus, dass die Nutzer sich auf Grund ihrer Nutzenerwartungen für genau ein bestimmtes Netzwerk entscheiden. Die Anbieter können durch Standardisierung ihre Netzwerke zusammenlegen und somit den Nutzen für die Kunden (und u. U. auch für sich selbst) steigern. In der IL liegen andere Voraussetzungen vor: Die Kunden können gemäß den obigen Annahmen nicht zwischen verschiedenen Netzen wählen. Vielmehr können entweder die Angebote eines oder mehrerer Anbieter von partikulären IL genutzt werden oder es können die Leistungen der zentralen IL in Anspruch genommen werden, wobei letztere ein deutlich anderes Leistungsangebot zur Verfügung stellen kann. Zu hinterfragen ist auch, wie hoch diese Nutzenerwartungen bei autonom agierenden Organisationseinheiten sind, die die Standardisierungsneigung beeinflussen. Aus der Perspektive einer an der Standardisierung interessierten Organisationseinheit ergibt sich die Frage, inwieweit sie die potenziellen Partner (d. h. andere Organisationseinheiten, die Daten liefern könnten) zu einer Zusammenarbeit bewegen kann. Dabei können die Präferenz für bestimmte Standards und die Anreize beeinflusst werden. Die Anreize können etwa durch Subventionen für neu zu beschaffende Software (zur Minderung der Wechselkosten) oder durch Offenlegung der Zusatznutzen (um die erwarteten Netzeffekte zu steigern) erfolgen. Weniger einfach ist es, die Präferenz für Standards zu lenken; hier könnten u. U. Subventionen für die Migration hilfreich sein. Auch in diesem Fall kann eine zentrale, koordinierende Organisationseinheit das Verhalten der anderen mit dem Ziel einer Standardisierung beeinflussen. Analog ist aus der Perspektive der Anbieter die Übertragbarkeit der Theorie unklar: Hier wird von einer Standardisierung, u. U. auf verschiedene parallele Standards (mit parallelen, getrennten Teilnetzen) ausgegangen. Insbesondere wird vorausgesetzt, dass die Standardisierung für die Anbieter grenzkostenfrei möglich ist (vgl. Katz/Shapiro 1985). Diese Annahme scheint wenig realistisch, weswegen die Standardisierungsneigung der Anbieter in der Praxis möglicherweise geringer ist als in der Literatur prognostiziert. Auf der anderen Seite kann auch auf die Anbieter eine koordinierende Einheit im Unternehmen einwirken, die sie zur Standardisierung motiviert.


57

5.3 Implikationen für die Gestaltung der Informationslogistik Die Netzwerktheorie beschäftigt sich mit der Auswahl von Standards und mit der Bildung von Marktstrukturen, hier mit der Bildung von Netzwerken. Die Ausgestaltung der Informationslogistik befasst sich im Gegensatz dazu mit Fragen der Steuerung, nachdem die Struktur der Leistungserstellung festgelegt ist. In diesem Kontext scheint die Theorie nicht anwendbar zu sein.

6

Theorie der Verfügungsrechte

6.1 Grundlagen der Theorie der Verfügungsrechte Die Theorie der Verfügungsrechte („Property-Rights-Theorie“) beschäftigt sich mit den Auswirkungen der Gestaltung und Verteilung von Verfügungsrechten auf das Verhalten von Wirtschaftssubjekten. Es wird dabei von marktlicher Koordination ausgegangen, in der unabhängige, begrenzt rationale Akteure danach streben, ihren erwarteten Einzelnutzen zu maximieren (vgl. Abb. 6). Es wird zudem davon ausgegangen, dass die Verfügungsrechte klar definiert und vollständig verteilt sind (Furubotn u. Pejovic 1972, S. 1137ff.). Verf ügungsrechtetheorie: Maximierung der erwarteten Einzelnutzen Akteure bestimmen ihr Verhalten eigenständig Verf ügungsrechte sind klar def iniert und vollständig verteilt



Abb. 6. Annahmen der Theorie der Verfügungsrechte

Unter Verfügungsrechten werden Handlungsrechte verstanden, die sich auf die Nutzung von Gütern beziehen (Furubotn u. Pejovic 1972, S. 1139; Alchian u. Demsetz 1973, S. 17). Zentral sind also nicht die Beziehungen

58


zwischen Akteuren und Gütern, sondern die „Beziehungen zwischen den Akteuren, basierend auf der Existenz der Güter und bezogen auf deren Nutzung“ (Furubotn u. Pejovic 1972, S. 1139). Diese Rechte bezüglich der Nutzung von Gütern werden in vier Klassen eingeteilt (Alchian u. Demsetz 1972, S. 783): x „Usus“ umfasst die Nutzung eines Guts und das Recht, andere von der Nutzung auszuschließen, z. B. im Falle eines Privatparkplatzes. x „Usus fructus“ umfasst das Recht auf die Gewinne bzw. Erträge aus der Nutzung eines Guts, z. B. auf die Früchte eines Baums. x „Abusus“ ist das Recht, ein Gut zu verändern, z. B. den Baum zu fällen. x „Ius abutendi“ bezeichnet schließlich das Recht, ein Gut zu veräußern und den Veräußerungserlös einzubehalten. Verfügungsrechte an einem Gut können grundsätzlich nicht nur von einzelnen Individuen gehalten werden, sondern auch von mehreren Individuen oder von der Allgemeinheit bzw. dem Staat (Alchian u. Demsetz 1973, S. 18). Verfügungsrechte beziehen sich auf positive ebenso wie negative Konsequenzen, die aus der Nutzung bzw. Ausübung eines Verfügungsrechts resultieren. Dementsprechend kann der Inhaber eines Verfügungsrechts für die positiven Folgen seines Handelns, die anderen entstehen, Kompensation verlangen, während er für negative Folgen haftbar gemacht werden kann. Diese Folgen werden als positive oder negative Externalitäten bezeichnet. Externalitäten sind „Leistungsbeziehungen zwischen Wirtschaftseinheiten, die nicht über Märkte vonstatten gehen und daher nicht durch Preise abgegolten werden“ (Schumann 1992, S. 460). Das heißt, dass der Verursacher bei positiven Effekten nicht für den bei Anderen entstehenden Nutzen kompensiert wird und bei negativen Effekten nicht für den Schaden haftet, der Anderen entsteht. Dies beeinflusst das Verhalten der Akteure, was am klassischen Beispiel der Nutzung von Allmende (Nutzfläche im Gemeineigentum) erklärt sei: Die Externalität besteht in der Nutzung des Landes; sie geht von der Gemeinschaft aus, die dafür nicht entschädigt wird. Da die Externalität für die Nutzer kostenlos ist, haben sie den Anreiz, sie so umfassend wie möglich zu nutzen, was zu Übernutzung und damit zu Nutzenverlust für die Gemeinschaft führt. Ein Preismechanismus hingegen könnte die Nutzung regulieren (Schumann 1992, S. 462). Vergleichbare Effekte entstehen bei Umweltverschmutzung: Akteure werden durch Emissionen geschädigt, haben aber keine Möglichkeit, den Verursacher dieser Emissionen dafür haftbar zu machen. Falls durch eine entsprechende Ausgestaltung und Verteilung der Verfügungsrechte eine Haftung für externe Effekte herbeigeführt wird, spricht


59

man von der Internalisierung externer Effekte. Allerdings ist zu beachten, dass diese Internalisierung Transaktionskosten für die Definition und Durchsetzung der Verfügungsrechte verursacht und daher nicht immer sinnvoll ist (Dietl u. van der Velden 2004, S. 1567). Die Internalisierung externer Effekte kann mit Hilfe von Marktmechanismen oder durch Verhandlungslösungen (Coase 1960) erreicht werden. Für die Erreichung des Ergebnisses spielt die a priori-Verteilung der Verfügungsrechte, d. h. die Zuordnung der Verfügungsrechte zu den Akteuren, keine Rolle. 6.2 Implikationen für die Vorteilhaftigkeit der Informationslogistik Aus den vorangehenden Ausführungen wird deutlich, dass auch im Kontext der unternehmensweiten Informationslogistik die Notwendigkeit besteht, Verfügungsrechte zu explizieren und zu verteilen. Diese Verfügungsrechte beziehen sich auf das Gut „Daten“. Die Notwendigkeit entsprechender Data Ownership- und Data Stewardship-Konzepte wird auch in der Data Warehousing-Literatur betont (Kimball et al. 1998, S. 70f.; Inmon 2002, S. 334). Durch die Nutzung bzw. den Austausch von Daten entstehen im Normalfall keine negativen externen Effekte. Es herrscht keine Rivalität im Konsum – ob Daten von einem oder mehreren Akteuren genutzt werden, ist für den Nutzen der beteiligten Akteure unerheblich. Dies bezieht sich jedoch nur auf die Klassen „usus“ und ggf. „usus fructus“, nicht jedoch auf „abusus“ oder gar das „ius abutendi“. Andererseits entstehen durch die gemeinsame Nutzung bzw. den Betrachtungseinheiten übergreifenden Austausch von Daten (vgl. Kap. 1) positive externe Effekte. Diese werden im vorliegenden Sammelband ausführlich im Kapitel „Nutzenpotenziale unternehmensweiter Informationslogistik“ (vgl. Kap. 8) beschrieben. 6.3 Implikationen für die Gestaltung der Informationslogistik Bezüglich der Gestaltung der unternehmensweiten Informationslogistik können sich aus der Theorie der Verfügungsrechte wichtige Implikationen für die Gestaltung von Leistungsverrechnungs- und Preismodellen ergeben: Beim Vorliegen klar definierter, vollständig verteilter Verfügungsrechte kann der Inhaber der Verfügungsrechte verlangen, für positive externe Effekte kompensiert zu werden. Daraus lässt sich für den Kontext der Informationslogistik ableiten, dass jeder Akteur, der Daten mittels einer Informationslogistik-Infrastruktur zur Verfügung stellt und seinerseits Ver-

60


fügungsrechte über diese Daten besitzt, für das „Teilen“ ebendieser Daten kompensiert werden sollte. Diese Kompensation muss nicht zwangsläufig monetärer Natur sein. Sie kann bspw. auch dadurch erfolgen, dass jeder Akteur, der Daten bereitstellt, seinerseits über die Informationslogistik-Infrastruktur auch Daten nutzen kann, deren Verfügungsrechte wiederum bei Dritten liegen. Dies entspricht der gesellschaftlich optimalen Kooperationsstrategie im Gefangenendilemma (vgl. Abschn. 4.2) und wird insbesondere bei hierarchischer Organisation relevant.

7


Die Neue Institutionenökonomie stellt Theorien zur Erklärung und Prognose wirtschaftlichen Handelns für eine Vielzahl von Situationen bereit. Dabei berücksichtigt sie verschiedene Formen der Koordination und unterschiedliche Verhaltensweisen der beteiligten Akteure. Auch für die Vorteilhaftigkeit und die Ausgestaltung der Informationslogistik können diese Theorien wertvolle Hinweise geben. Für die Praxis ergeben sich hieraus Anhaltspunkte für die Ausgestaltung von Anreizmechanismen, die die Umsetzung der Informationslogistik im Unternehmen erleichtern. Weiterer Forschungsbedarf besteht hinsichtlich der Vertiefung der hier vorgestellten Ansätze und hinsichtlich der empirischen Validierung der vorgestellten Thesen.

Literatur Alchian, A.; Demsetz, H.: Production, Information Costs, and Economic Organization, in: American Economic Association 62 (1972) 5, S. 777-795. Alchian, A.; Demsetz, H.: The Property Rights Paradigm, in: Journal of Economic History 33 (1973) 1, S. 16-27. Arthur, W.: Competing Technologies, Increasing Returns, and Lock-In by Historical Small Events, in: Economic Journal 99 (1989) 394, S. 116-131. Axelrod, R.: The Evolution of Cooperation, 1. Aufl., Basic Books, New York 1984. Bester, H.: Spieltheorie, in: Schreyögg G. et al. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation, 4. Aufl., Schäffer-Poeschel, Stuttgart 2004, S. 1342-1349. Coase, R.: The Nature of the Firm, in: Economica 4 (1937) 16, S. 386-405. Coase, R.: The Problem of Social Cost, in: Journal of Law and Economics 3 (1960), S. 1-44.


61

Dietl, H.; van der Velden, R.: Verfügungsrechtetheorie (Property Rights-Theorie), in: Schreyögg G. et al. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation, 4. Aufl., Schäffer-Poeschel, Stuttgart 2004, S. 1565-1573. Eisenhardt, K.: Agency Theory: An Assessment and Review, in: Academy of Management Review 14 (1989) 1, S. 57-74. Furubotn, E.; Pejovic, S.: Property Rights and Economic Theory: A Survey of Recent Literature, in: Journal of Economic Literature 10 (1972) 4, S. 1137-1162. Inmon, W.: Building the Data Warehouse, 3. Aufl., Wiley Computer Publishing, New York 2002. Jensen, M.; Meckling, W.: Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, in: Journal of Financial Economics 1976 (1976) 3, S. 305-360. Jost, P.-J.: Transaktionskostentheorie, in: Schreyögg G. et al. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation, 4. Aufl., Schäffer-Poeschel, Stuttgart 2004, S. 1450-1458. Katz, M.; Shapiro, C.: Network Externalities, Competition, and Compatibility, in: American Economic Review 75 (1985) 3, S. 424-440. Katz, M.; Shapiro, C.: Systems Competition and Network Effects, in: Journal of Economic Perspectives 8 (1994) 2, S. 93-115. Kimball, R.; Reeves, L.; Ross, M.; Thornthwaite, W.: The Data Warehouse Lifecycle Toolkit - Expert Methods for Designing, Developing, and Deploying Data Warehouses, Wiley, New York 1998. Kräkel, M.: Prinzipal-Agenten-Ansatz, in: Schreyögg G. et al. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation, 4. Aufl., Schäffer-Poeschel, Stuttgart 2004, S. 1174-1181. Nash, J.: Equilibrium Points in n-Person Games, in: Proceedings of the National Academy of Science USA 36 (1950) 1, S. 48-49. Picot, A.; Reichwald, R.; Wigand, R.: Die grenzenlose Unternehmung - Information, Organisation und Management, 4. Aufl., Gabler, Wiesbaden 2001. Rapoport, A.; Chammah, A.: Prisoner's Dilemma - A Study in Conflict and Cooperation, University of Michigan Press, Ann Arbor 1965. Ross, S.: The Economic Theory of Agency: The Principal's Problem, in: American Economic Review 63 (1973) 2, S. 134-139. Schumann, J.: Grundzüge der Mikroökonomik, 6. Aufl., Springer, Berlin et al. 1992. Weitzel, T.; Beimborn, D.; König, W.: A Unified Economic Model of Standard Diffusion: The Impact of Standardization Cost, Network Effects, and Network Topology, in: MIS Quarterly 30 (2006) Special Issue August, S. 489-514. Williamson, O.: Transaction-Cost Economics: The Governance of Contractual Relations, in: Journal of Law and Economics 22 (1979) 2, S. 233-261. Williamson, O.: The Economic Institutions of Capitalism, Free Press, New York 1985. Williamson, O.: Transaction Cost Economics, in: Schmalensee R. et al. (Hrsg.): Handbook of Industrial Organization, Elsevier Science Publishing, Amsterdam 1989, S. 135-182.

62


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

4

Strategie der Informationslogistik

Barbara Dinter, Robert Winter Universität St. Gallen

1 2 3 4 5

1

Strategiebegriff in der Informationslogistik ..................................... 63 Produktsicht auf die IL-Strategie: die IL-Teilstrategien ................... 69 Prozesssicht auf die IL-Strategie: der ILStrategieentwicklungsprozess ........................................................... 75 Fallstudie: BI-Strategie bei der Volkswagen AG ............................. 79 Zusammenfassung ............................................................................ 81 Literatur ............................................................................................ 81

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. Kapitel 1) 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 Anfor-

64

Barbara Dinter, Robert Winter

derungen, können aber auch aus neuen fachlichen Anforderungen erstehen (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. Abschn. 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 Strategieentwicklungspro1

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


65

zess, der die Prozesssicht repräsentiert. Der Bezug zur unternehmerischen Praxis erfolgt in Abschn. 4 mit der Kurzvorstellung des Anwendungsfalls „Business Intelligence-Strategie bei der Volkswagen AG“ (der in Kap. 12 ausführlich behandelt wird). Der Beitrag endet mit einer Zusammenfassung (Abschn. 5). 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.

66

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. 4. Service Level Alignment bezeichnet die Ausrichtung der fachlichen Prozesse und Infrastruktur an den IT-Prozessen (bzw. der IT-Infra-


67

struktur), 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: 1. Strategy Execution Alignment

3 Fachliche Strategie

3

2

1

Fachliche Prozesse und Inf rastrukturen

IT-Strategie

2

4

3. Competitive Potential Alignment 4. Service Level Alignment

1 4

2. Technology Transf ormation Alignment

IT-Prozesse und Inf rastrukturen

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 prozessbzw. 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, Projektportfoliomanagement 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 Anforderungen stellen und eine – wie oben erwähnt – langfristig wirksame, grundlegende und ganzheitliche Perspektive einnehmen.

68


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. 1, Abschn. 3) wurde bereits herausgearbeitet, dass die Informationslogistik nicht isoliert, sondern in enger Abstimmung mit den Aktivitäten der unternehmensweiten IT betrieben werden sollte.


69

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. 1, 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. 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 IT-

70


Teilstrategien (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. Im Modell des integrierten Informationsmanagements werden Teilstrategien unterschieden, sie decken alle relevanten Phasen der IT-Leistungserstellung ab (vgl. Abb. 3).

Strategie der Informationslogistik 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

71

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.

72


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


73

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-

74


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 1) 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.


75

2.8 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

76


der Informationslogistik wird im Folgenden ein Vorgehensmodell für den IL-Strategieentwicklungsprozess vorgestellt. 3.2 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.3 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 hat, so wird diese in einer ersten Konkretisierung auf ein spezielles Leitbild (in diesem Fall für die Informationslogistk) bereits verfeinert.2 Das IL-Leitbild

2

Heinrich und Bea sehen im Leitbild bereits eine Spezialisierung hinsichtlich des Zielpublikums und / oder Einsatzzwecks (Bea u. Haas 2001; Heinrich 2002),


77

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. 1) 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, vgl. für ein Umsetzungsbeispiel Kap. 12) erfasst werden.

wohingegen Müller-Stewens den unternehmensweiten Scope des Leitbilds betont (Müller-Stewens u. Lechner 2003).

78


3.4 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 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.5 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

79

Fallstudie: BI-Strategie bei der Volkswagen AG

In diesem Abschnitt werden die Kernpunkte einer IL-Strategie am Beispiel der BI-Strategie des Volkswagen Konzerns dargestellt. Eine detaillierte Darstellung des Strategieentwicklungsprozesses und der BI-Strategie bei Volkswagen findet sich in Kap. 12. Diese Strategie bezieht sich auf ein umfassendes Verständnis von Business Intelligence, das dem in Kap. 1 dargestellten Verständnis von Informationslogistik nahe kommt. Die BI-Strategie wurde im Rahmen eines strukturierten Entwicklungsprozesses erstellt und weiterentwickelt. Wichtige Rahmenbedingungen ergaben sich dabei aus der Konzernstrategie und der IT-Strategie der Volkswagen AG. Sie besteht aus einer Reihe von Bausteinen, die im Folgenden kurz vorgestellt werden. Die darin beschriebene Vision lautet: „BI – der Weg zum Wissensvorsprung des Volkswagen-Konzerns. Einsichten schaffen, Informationen integrieren, Kompetenzen vernetzen“. Die BI-Strategie verfolgt zur Umsetzung dieser Vision die nachstehenden Kernziele: x x x x

Erschließen neuer fachlicher Möglichkeiten Effizienz durch Standardisierung Qualität vor Quantität Mehr BI fürs Geld

Eine Strategy Map hilft, das Zielmodell den Dimensionen der konzernweiten Balanced Scorecard zuzuordnen. Das BI-Programm beschreibt die strategischen Initiativen zur Überführung der bestehenden BI-Landschaft in den Zielzustand einer BI-Plattform. Im Ausgangszustand verfügt die Volkswagen AG über eine gewachsene BI-Landschaft aus projektgetriebenen Initiativen und Systemen, die die Erreichung der strategischen Ziele deutlich erschwert. Die angestrebte BIPlattform sieht vor, dass die bestehenden Datenspeicher und Data Warehouses in sog. Gravitationszentren gebündelt werden, die zusammengehörende Daten integrieren. Darauf aufsetzend werden BI-Services definiert, die die fachliche Funktionalität realisieren. Die BI-Roadmap visualisiert die Kernpunkte des BI-Programms im zeitlichen Zusammenhang (vgl. Abb. 4).

80

Barbara Dinter, Robert Winter 2006-2007

2008-2011

Fachliche BI-Strategie

2012-2015

BI – der Weg zum Wissensvorsprung des Volkswagen Konzerns

2005

Abb. 4. BI-Roadmap der Volkswagen AG

Die fachliche BI-Strategie zielt darauf ab, die Kern-Geschäftsprozesse der Volkswagen AG besser durch BI zu unterstützen. Zu diesem Zweck sollen das Bewusstsein und die Kompetenz für BI in den Fachbereichen gesteigert, Anwendungsbereiche identifiziert und Weiterentwicklungen der BI in Richtung Performance Management und prozessorientierter BI gefördert werden. Um die technische Entwicklung der BI zu steuern, wurde ein BI-Master Construction Plan (MCP) entwickelt. Der BI-MCP definiert die Zielarchitektur für den BI-Bereich in Übereinstimmung mit der IT-Architektur insgesamt. Die MCPs dienen auch der Kommunikation mit den Fachbereichen und anderen Bereichen der IT. Durch Abbildung von Ist- und Sollzustand werden zudem die dazu notwendigen Transformationsprozesse unterstützt. Zur organisatorischen Unterstützung wurde das IT-Kompetenzfeld BI (ITP-KF BI) formiert. Das IKP-KF BI bündelt die Funktionen BICompetence Center und BI-Governance. Das BI-CC unterstützt BIProjekte, steuert das Alignment von BI-Projekten mit der BI-Strategie und koordiniert übergreifend. Es stellt in erster Linie in fachlicher und technischer Hinsicht Beratungs- und Unterstützungsleistungen bereit (vgl. Kap. 5). Zur Unterstützung der Strategieumsetzung wird auf das Change Management großer Wert gelegt. Ein Kommunikationskonzept definiert Maßnahmen, die die Einbindung der vier Stakeholder-Gruppen Beteiligte, Betroffene, Interessierte und Außenstehende in angemessenem Umfang


81

sicherstellt. Ein Schulungskonzept fördert zusätzlich die BI-Kompetenz bei derzeitigen und potenziellen Nutzergruppen.

5

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

82


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

Einleitung ......................................................................................... 83 Das Data Warehouse-Konzept.......................................................... 84 DWH-Leistungserbringertypen in der Praxis ................................... 88 Auswahl der geeigneten Organisationsform ................................... 101 Etablierung eines BI-Competence Centers bei der E.ON AG ........ 102 Zusammenfassung und Ausblick .................................................... 104 Literatur .......................................................................................... 105

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. 1). 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.

84

Mario Klesse, Moritz Schmaltz

Meyer 2001; Gallo 2002; Smith 2005). Für ausgewählte Aspekte des Data 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, in Abschn. 5 wird ein Fallbeispiel aus der Praxis kurz vorgestellt. Zum Abschluss werden Implikationen für die Praxis diskutiert (Abschn. 6).

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. 1). 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 Bereit-


85

stellung von Datenflüssen zur Erfüllung von Informationsbedarfen innerhalb des Unternehmens ermöglicht. Die IL hat zwar einen weiteren 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

86


2004). Für die Zwecke der nachfolgenden Analysen werden diese Hauptprozesse wie folgt detailliert (vgl. Abb. 1). 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.


87

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.

88


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-


89

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. 6%. 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.

90


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.


91

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.

92


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.


93

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.

94


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.


Externe Service Provider Dienstleister Implementierung Implementierung spezifizierter DWHSoftwaremodule

Dienstleister Plattformen Betrieb der DWHPlattform Routinebetrieb der Ladeprozesse

DWH-Plattform

95

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:

...


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

96


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.


Service Provider

DWH-Leistungserbringer

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

DWH-Plattform

97

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


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:

...


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-

98


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.


Externe Zulieferer Dienstleister Implementierung

99

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


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

...


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-

100


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 Zuord- Dienstleister nung 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 Appli- bare Formulie- fachlichen Ankationen rung von Anfor- forderungen 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


101

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

102


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. 1). 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

Etablierung eines BI-Competence Centers bei der E.ON AG

In diesem Abschnitt werden Teile der vorangegangenen Ausführungen anhand eines Praxisbeispiels illustriert. Hierzu wurde die Organisation der Informationslogistik bei der E.ON AG betrachtet. In Kap. 13 findet sich eine detaillierte Fallstudie, in der die hier vorgestellte Organisation ausführlich beschrieben wird. Auf Grund starker Akquisitionsbemühungen vereinigt der E.ONKonzern Mitarbeiter unterschiedlichster Unternehmen unter dem Dach des E.ON Konzerns. Als Folge der früheren Struktur als Mischkonzern ist eine


103

Vielzahl verschiedener IL-Systeme mit sich überschneidenden Aufgaben im Einsatz. Insbesondere in Folge sich verändernder fachlicher und organisatorischer Rahmenbedingungen sowie der damit einhergehenden Anforderungen zur Informationsversorgung wurde deutlich, dass eine strukturierte, ganzheitliche Gestaltung der Informationslogistik erforderlich ist. Um den sich verändernden Rahmenbedingungen gerecht zu werden, wurde durch den Konzern-CIO-Bereich entschieden, ein „Excellence Team Information Logistics“ (ETIL) zu etablieren. Unter der Maxime „Information Excellence“, der fortwährenden Bereitstellung aktueller Informationen für alle Beteiligten entlang der gesamten Wertschöpfungskette, ist das ETIL mit der Sicherstellung der Informationsversorgung, der besseren Aufstellung des Konzerns bei weiteren Akquisitionen und der Kosteneinsparung z. B. durch Verbreitung von Best Practices beauftragt. Durch die Aktivitäten des ETIL soll die Informationsversorgung verbessert und die Basis für weiteres Wachstum durch höhere Integrationsfähigkeit und Flexibilität geschaffen werden. Die Harmonisierung und Standardisierung der Informationslogistik soll ermöglicht werden, um die Transparenz und Effizienz derselben zu verbessern. Zwischen allen Geschäftseinheiten und E.ON IS, dem internen IT-Dienstleister, soll die Kooperation gefördert werden. Koordiniert werden diese Bemühungen durch das Corporate Center. Insgesamt wird ein „Group Optimum“ angestrebt. Das Ergebnis sämtlicher Aktivitäten bildet das „Framework Information Logistics“, kurz FIL.ON genannt. Ziele des Frameworks sind: x Eine verstärkte Ausrichtung der IL anhand der Erfordernisse des Business x Bereitstellung von Grundlagen für eine flexible IL-Architektur x Harmonisierung und Standardisierung der IL zur Erhöhung der Transparenz und Effizienz In den vorhergehenden Abschnitten wurden die vier Leistungserbringertypen DWH Business Service Provider, DWH Full Service Provider, DWH Competence Center (CC) sowie DWH Platform Provider identifiziert. Das ETIL lässt sich am ehesten dem Leistungserbringertyp DWHCC zuordnen, auch wenn sich das Leistungsspektrum nur auf Teile der Führungsprozesse, insbesondere die IL-Governance, in Zusammenarbeit mit anderen IT- und Fachabteilungen erstreckt und z. B. Implementierung und Betrieb durch einen IT-Dienstleister übernommen werden. Das ETIL erarbeitet mit dem FIL.ON ein Framework für die Informationslogistik, auf Basis dessen in Zukunft die Versorgung der Bedarfsträger mit analytischen Informationen im Sinne des Maßnahmenkataloges europe.on erfolgen wird. Zukünftig wird die konzernweite Durchsetzung der

104


erarbeiteten Standards und Vorgaben besonders hohe Bedeutung erlangen. Bei Neu- und Weiterentwicklungen, Wartung und Betrieb muss die Anwendung der Standards nachverfolgt werden, damit eine ganzheitliche, durchgängige Informationslogistik für den E.ON Konzern ermöglicht wird. Das Fallbeispiel des Excellence Team Information Logistics bei der E.ON AG zeigt einen erfolgreichen Ansatz für die Organisation einer ganzheitlichen Informationslogistik. Auch wenn sich die Etablierung einer ganzheitlichen Informationslogistik derzeit noch in einer frühen Phase befindet, deuten erste Erfolge in Pilotprojekten auf ein insgesamt hohes Potenzial hin. Eine detaillierte Darstellung der Organisation der Informationslogistik von E.ON enthält Kap. 13.

6


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 DWHLeistungserbringers 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 Implementie-


105

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

106


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/i00 8ht04.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. 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 8

1

Einleitung ....................................................................................... 107 Begriffliche Grundlagen ................................................................. 109 Grundannahmen der prozessorientierten Informationslogistik....... 115 Nutzeneffekte der prozessorientierten Informationslogistik........... 116 Ausgestaltung der prozessorientierten Informationslogistik .......... 118 Vorgehensmodell für die Einführung der prozessorientierten Informationslogistik ....................................................................... 125 Fallbeispiel: Prozessorientierte Informationslogistik bei der Hotelplan Swiss Group ................................................................... 129 Fazit und Ausblick .......................................................................... 131 Literatur .......................................................................................... 132

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

108

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. Das Fallbeispiel „Prozessorientierte Informationslogistik bei der Hotelplan Swiss Group“ schildert einen praktischen Anwendungsfall und verdeutlicht Relevanz und Nutzeneffekte des Konzepts. Eine Kurzfassung der Fallstudie, welche in ihrer Gänze in Kap. 14 abgedruckt ist, findet sich in Abschn. 7. Abschnitt 8 fasst die wesentlichen Aussagen dieses Artikels zusammen und gibt einen Ausblick

Prozessorientierte Organisation und Informationslogistik

109

auf weitere Forschungsaktivitäten im Kontext der prozessorientierten Informationslogistik.

2

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 institutio-

110

Tobias Bucher

nellen 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 Transaktionskostentheorie 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).


111

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 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):

112

Tobias Bucher

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


113

2.3 Thematische Abgrenzung In Literatur und Praxis werden derzeit zwei verschiedene Varianten bzw. Blickrichtungen auf die Integration der prozessorientierten Organisation einerseits und der Informationslogistik andererseits diskutiert. Zum einen existieren zahlreiche Beiträge, die die Unterstützung der Ausführung von betrieblichen Prozessen durch die Einbettung 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 ste-

114

Tobias Bucher

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

115

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 beschreibt 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

116

Tobias Bucher

die Nutzung analytischer Informationen im operativen Kontext werden Prozesse wie Preisermittlung, Kundenbindungsmanagement, Betrugserkennung und Risikomanagement genannt (Inmon 2000).

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 werden. 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 Ab1

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.


117

schnitt 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).

118

į1

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

0.55

Hohe Priorität des Themas bei der Unternehmensleitung

į3

0.63

0.62

0.81

0.38

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

ȗ1

Zusammenfallen von Prozessausführung und Informationszugriff 0.40

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


119

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

120

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.


121

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-

122

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


123

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 Realisierungs-

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

124

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-


125

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

126

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


127

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.

128

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.


7

129

Fallbeispiel: Prozessorientierte Informationslogistik bei der Hotelplan Swiss Group

Verfall

Das Fallbeispiel des Last-Minute-Reisegeschäfts bei der Hotelplan Swiss Group eignet sich außergewöhnlich gut, um die grundlegende Idee, die unternehmensspezifische Ausgestaltung und die Nutzeneffekte des Konzepts der prozessorientierten Informationslogistik exemplarisch darstellen. Im Folgenden wird eine Kurzzusammenfassung des Fallbeispiels dargestellt. Die komplette Fallstudie findet sich ebenfalls in diesem Sammelband (vgl. Kap. 14). In der Fallstudie wird beschrieben, auf welche Art und Weise und auf welcher informatorischen Grundlage die Hotelplan Swiss Group sog. LastMinute-Reiseangebote erstellt und diese periodisch den Kundenbedürfnissen und Marktgegebenheiten entsprechend anpasst bzw. verändert, um sie erfolgreich vermarkten zu können. Abbildung 5 stellt in vereinfachter Art und Weise den Lebenszyklus von Reiseangeboten dar. Grundsätzlich können zwei aufeinanderfolgende Phasen unterschieden werden, nämlich die reguläre Angebotsphase und die Last-Minute-Angebotsphase. Im Rahmen der Last-Minute-Angebotsphase vollzieht sich ein Wechselspiel zwischen Angebotsüberarbeitung, Vermarktung der Last-Minute-Reiseangebote und Überwachung der Kundenreaktion, welcher als iterativer Zyklus verstanden werden kann. Angebotsüberarbeitungen werden in dieser Angebotsphase erforderlich, da Last-Minute-Reiseangebote innerhalb einer kurzen, durch den Anfangstermin der Reise fest vorgegebenen Zeitspanne verkauft werden müssen. Aus diesem Grund ist es erforderlich, Last-Minute-Reiseangebote vergleichsweise kurzfristig und dynamisch an die Markterfordernisse anzupassen.

Abb. 5. Lebenszyklus von Reiseangeboten

Die Angebotsüberarbeitung, d. h. der Prozess der Last-Minute-Produktund -Preisgestaltung, bedarf offenkundig einer adäquaten informatorischen Unterstützung. Im Zusammenhang mit der Prozessausführung sind zahl-

130

Tobias Bucher

reiche Auswahl- und Gestaltungsentscheidungen zu treffen (z. B. bezüglich der Auswahl umzugestaltender regulärer Reiseangebote, der Auswahl der Produktkomponenten des Last-Minute-Reiseangebots, der Preisgestaltung des Last-Minute-Reiseangebots, der Interpretation der Kundenreaktionen, der Identifikation von Überarbeitungsbedarf bestehender LastMinute-Reiseangebote, usw.). Grundlage für diese Entscheidungen stellen Informationen dar, auf welche die Mitarbeitenden des prozessausführenden Sachbearbeitungs-Teams über verschiedene Anwendungssysteme zugreifen können. Dazu zählen das Data Warehouse des Unternehmens, das Reservations- und das Verkaufssystem sowie externe Informationsquellen. Darüber hinaus verlassen sich die Mitarbeitenden in vielen Fällen auch auf ihr implizites Erfahrungswissen in der Gestaltung und Überarbeitung von Last-Minute-Reiseangeboten. Bezüglich des ersten Gestaltungsfaktors („Entwicklungsstand der Informationsversorgung“) weist das betrachtete Unternehmen dementsprechend einen hohen Umsetzungsgrad auf. Im Gegensatz dazu ist der Status Quo der Integration von Prozessausführung und informatorischer Unterstützung insgesamt als unzureichend zu bewerten. Obgleich die verfügbaren Informationsquellen von den Mitarbeitenden des Sachbearbeitungs-Teams intensiv in Anspruch genommen werden, existieren dennoch zahlreiche Medienbrüche zwischen den einzelnen Anwendungssystemen, die sowohl der Informationsbereitstellung als auch – im Fall des Reservationssystems – der eigentlichen Prozessausführung dienen. Bezogen auf den zweiten Gestaltungsfaktor („Integrationsgrad analytischer Informationen in Prozesse“) weist das Unternehmen folglich nur einen niedrigen Umsetzungsgrad auf. Dementsprechend weist die von der Hotelplan Swiss Group verfolgte Realisierungsform der prozessorientierten Informationslogistik derzeit eine mittelhohe Reife auf und ist als informationstechnisch getriebener Ansatz zur Etablierung des Konzepts (Realisierungsform 2) zu charakterisieren. Der derzeit von der Hotelplan Swiss Group favorisierte Lösungsansatz zielt dementsprechend sowohl auf eine Verbesserung der informatorischen Unterstützung der Prozessausführung als auch auf die Integration der derzeit weitestgehend unabhängigen Prozess- und Informationssichten ab. Auf die Integration wird dabei besonderes Augenmerk gerichtet. Zur Erreichung des Ziels einer ausgereiften prozessorientierten Informationslogistik verfolgt die Hotelplan Swiss Group ein zweistufiges Vorgehen: Kurzfristig wird eine bessere Strukturierung des Prozessablaufs, dessen Teilautomatisierung und integrierte informatorische Unterstützung mit Hilfe des SAP NetWeaver Visual Composer-Werkzeugs angestrebt. Diese Zwischenlösung dient als Wegbereiter der mittel- bis langfristig verfolgten Vision einer Vollautomatisierung von Prozessausführung und Entschei-


131

dungsfindung im Zusammenhang mit der Produkt- und Preisgestaltung von Last-Minute-Reiseangeboten. Durch die Verfolgung des zweistufigen Lösungsansatzes wird die Realisierung verschiedener Nutzeneffekte der prozessorientierten Informationslogistik im Zusammenhang Produkt- und Preisgestaltung von Last-Minute-Reiseangeboten möglich. Zu diesen anwendungsfallspezifischen Nutzeneffekten zählen qualitative Verbesserungen der Prozessleistung ebenso wie Effizienzgewinne in der Ressourcennutzung sowie die Steigerung der Arbeitszufriedenheit der Mitarbeitenden.

8

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 weiteren 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 und anhand eines Fallbeispiels illustriert. Das Fallbeispiel „Prozessorientierte Informationslogistik bei der Hotelplan Swiss Group“ schildert einen praktischen Anwendungsfall der prozessorientierten Informationslogistik und verdeutlicht Relevanz und Nutzeneffekte des Konzepts. 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

132

Tobias Bucher

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 prozessorientierten 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. et al. (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. et al. (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.


133

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. et al. (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. Bucher, T.; Winter, R.: Realisierungsformen des Geschäftsprozessmanagements Eine explorative Klassifikationsanalyse, in: Oberweis A. et al. (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. et al. (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. et al. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation, Schäffer-Poeschel, Stuttgart 2004, S. 1208-1218.

134

Tobias Bucher

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. 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. et al. (Hrsg.): Business Intelligence Techniques - A Perspective from Finance and Accounting, Springer, Berlin 2004, S. 41-54. 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.


135

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.dmre view.com/issues/20061201/1069958-1.html, 04.12.2007. Williamson, O.: Transaction-Cost Economics - The Governance of Contractual Relations, in: Journal of Law and Economics 22 (1979) 2, S. 233-261. Williamson, O.: The Economics of Organization - The Transaction Cost 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

Systemarchitekturen für die Informationslogistik

Gerrit Lahrmann, Florian Stroh Universität St.Gallen

1 2 3 4 5 6

Einleitung ....................................................................................... 137 Anforderungsrahmen und Einflussfaktoren .................................... 138 Architekturtypen der Informationslogistik ..................................... 146 Bewertung von Systemarchitekturen .............................................. 156 Fallstudie: Informationslogistik-Architektur bei der Credit Suisse 161 Ausblick .......................................................................................... 163 Literatur .......................................................................................... 164

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 Informations-

138

Gerrit Lahrmann, Florian Stroh

systeme 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), 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. Mit einer Kurzdarstellung einer Fallstudie zu Systemarchitekturen bei einer Großbank wird in Abschn. 5 der Beitrag illustriert.

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


139

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 -/Periodizität

Wilhelmi 2006 -/Budgetumfang Auswertungssysteme

Horizontale In- Bedürfnis nach Geformationsinte- schäftsbereich übergration greifenden Auswertungen Granularität Managementunterstützung 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.

140


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


141

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 2006a, 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).

142 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 2006a, 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-


143

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 2006a, 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).

144 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-


145

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

146


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


147

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-

148


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)

Systemarchitekturen für die Informationslogistik 3.1.3

149

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

150


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


151

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. Durch die gemeinsame Nutzung der wichtigsten Unternehmensdaten in unterschiedlichen Systemen ermöglicht eine föderierte Architektur mittels eines gemeinsamen Metadatenmanagements zur Konsistenzsicherung eine „single version of the truth“, die flexibel unterschiedliche Datenquellen, Data Warehouses, Data Marts und Analyseapplikationen vereint. Die föderierte Architektur stellt im Gegensatz zur idealtypischen, rein zentralisierten Architektur für viele Unternehmen 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 Konnekti-

152


vität und Datendurchsatz auftreten, da Daten über unterschiedlichste Systeme ausgetauscht werden müssen. 3.1.6

Virtuelle Architektur

Die virtuelle Architektur unterscheidet sich grundlegend von anderen Architekturen, da neben den eigentlichen Quellsystemen keine weiteren Datenspeicher existieren (Bold et al. 1997, S. 11). Die virtuelle Architektur soll verbesserte Zugriffsmöglichkeiten für Endanwender auf das 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


153

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). Die Komponenten eines ADWH stellen sich nach (Thalhammer et al. 2001, S. 243) wie folgt dar: Analog zu klassischen DWHs beinhaltet ein ADWH ein (passives) Data Warehouse, aus dem über Data Marts Ad-hoc Anfragen beantwortet werden können. Das ADWH bildet hierbei die Basis zur Erstellung und Aktualisierung von Data Marts. 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 (vgl. Thalhammer et al. 2001, S. 244)

154


Abb. 9. Beispiel eines Near-Real-Time-DWH mit EAI-Infrastruktur (in Anlehnung an Schelp 2006b, S. 434) 3.2.2

Real-Time Warehousing mit EAI

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 2006a, S. 426). Oftmals wird in Architekturen, die dem Anspruch der zeitnahen Datenbereitstellung gerecht werden wollen, ein sog. Operational Data Store (ODS) verwendet, „eine Datenbank, die Daten aus verschiedenen Datenquellen aufnimmt und temporär physisch zusammenführt“ (Bauer u. Günzel 2004, S. 54). Eine Beispielarchitektur, die zum einen aus o. g. Gründen ein ODS verwendet, zum anderen auf Grund der verbesserten Integrationsmöglichkeiten auf einer Enterprise Application Integration (EAI) Infrastruktur aufsetzt, ist die in (Schelp 2006a, S. 434) vorgestellte Near-Real-Time Warehousing Architektur. Abbildung 9 verdeutlicht die Architektur mit einem CRM-System. Aus den Quellsystemen werden die Daten mittels einer EAI-Infrastruktur nach Transformation mit einem ETL-Tool in einen ODS geladen. Nach einer weiteren ETL-Stufe gelangen schließlich die Daten, die durch die vorherige Transformation bereits an Komplexität verloren haben, aus dem ODS ins Data Warehouse. Durch dieses Vorgehen können zum einen schnellere Ladezyklen ins Data Warehouse erreicht werden, zum anderen werden Quellsysteme nur einmalig belastet. Das CRM-System bezieht im Extremfall Daten aus dem ODS, dem Data Warehouse, den darauf aufsetzenden Analysetools (OLAP-Tool) und mittels EAI auch direkt aus den Quellsystemen (z. B. Stammdaten oder Detaildaten, die weder im ODS noch im DWH enthalten sind). Neben der damit erreichten ver-


155

ringerten Lade- und Analyselatenz ermöglicht die Architektur dem CRMSystem über die EAI-Infrastruktur auch Schreibzugriff auf die Quellsysteme. 3.2.3

In-Memory Analytics

Die Möglichkeit, durch Ad-hoc-Abfragen Detailinformationen aus dem Data Warehouse zu erhalten, geht einher mit einer oftmals nicht befriedigenden Antwortzeit. Zur Umgehung dieses Problems werden auf die Abfragen optimierte Data Marts erstellt, die Daten verdichtet zur Verfügung stellen. Oftmals wird eine Verbesserung des Antwortverhaltens erreicht, dafür treten jedoch andere Probleme auf (Schlegel et al. 2006, S. 2): x Die Erstellung der Data Marts ist Ressourcen intensiv, es werden Personal- und Rechnerressourcen benötigt. x Neue Daten müssen den voraggregierten Daten hinzugefügt werden, d. h. es müssen regelmäßig neue Berechnungen durchgeführt werden. x Die Wartung der Data Marts bindet Ressourcen, die z. B. für die Weiterentwicklung nicht mehr zur Verfügung stehen. Zur Vermeidung dieser Probleme kann eine Architekturkomponente, genannt In-Memory Analytics, eingesetzt werden, um die Performanz der BIApplikationen zu verbessern. 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 die Daten in den Speicher geladen und Berechnungen werden zur Abfragezeit durchgeführt. Endanwender können detaillierte Daten einfacher erkunden (mit weniger in Cubes vorhandenen Dimensionsrestriktionen) und so mehr Freiheitsgrade der Datenanalyse ausnutzen.

Abb. 10. Hub and Spoke-Architektur, erweitert um In-Memory Analytics (vgl. Schlegel et al. 2006, S. 4)

156


Schlegel et al. äussern 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 entsprechende 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.


157

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

158


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 2006b, 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-TimeArchitekturen 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). 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 denormalisierter Dimensionstabellen in den Marts (Kimball u. Ross 2002; Bauer u. Günzel 2004, S. 59). Architekturen mit Data-Mart-Komponenten werden


159

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. 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 die Anforderung einer hohen Verfügbarkeit in weniger starkem Maße. 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. Deshalb ist dieser Architekturtyp gegenüber einem zentralisierten Ansatz als vorteilhaft einzuschätzen. 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“) wird als weiterer Vorteil von Data Mart-Komponenten verstanden. Hierdurch ist der Zugriff auf eine Integrationsebene, die alle Daten enthält, eingeschränkt. Dies trägt zu einer erhöhten Sicherheit im Betrieb der Systeme bei (siehe auch Abschn. 2.2.4). Somit erhalten Architekturen, die auf Data Marts zurückgreifen, hinsichtlich ihrer Sicherheit eine bessere Bewertung im Vergleich zu zentralisierten bzw. virtuellen Ansätzen, bei denen die

160


Analysen direkt auf der Integrationsebene aufsetzen. 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. Allerdings sei in diesem Zusammenhang auf die erhöhte Flexibilität hingewiesen, die beispielsweise durch eine Schnittstellenreduzierung bei einer Hub and Spoke-Architektur entstehen kann. 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). 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 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 Archi-


161

tekturen 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

Fallstudie: Informationslogistik-Architektur bei der Credit Suisse

In diesem Abschnitt werden Teile der Ausführungen des Kapitels anhand eines Praxisbeispiels anschaulich illustriert. Hierzu wurde die Informationslogistikarchitektur der Schweizer Grossbank Credit Suisse betrachtet. In Kap. 15 findet sich eine detaillierte Fallstudie, die neben Komponenten und Richtlinien der Architektur auch die Einbettung der Architektur in operative Geschäftsprozesse zeigt, indem den Prozessen die zugehörigen Datenquellen und Applikationen gegenübergestellt werden. Der vorliegende Abschnitt konzentriert sich auf die Darstellung der Architektur der Credit Suisse und erläutert, inwiefern Anforderungen, die im Kapitel identifiziert worden sind, berücksichtigt werden. Das Zentrum der Informationslogistik der Divisionen Private Banking und Shared Services2 der Credit Suisse bildet ein Data Warehouse. Die Referenzarchitektur des Data Warehouses entspricht einer Hub and SpokeArchitektur (siehe Abschn. 3.1.4). Neben einer Integrations- und einer Analyseschicht enthält diese Architektur zusätzlich noch eine Anreicherungsschicht, die die Ergebnisse komplexer Berechnungen und wiederverwendbare Daten den Data Marts zur Verfügung stellt (vgl. Abb. 11). Als Datenquellen für das Data Warehouse dienen zum einen Applikationen zur Transaktionsverarbeitung, zum anderen externe Quellen. Mittels eines ETL-Werkzeuges (Extraktion, Transformation, Laden) werden die Daten in die Integrationsschicht geladen. In dieser Schicht werden Daten, die aus unterschiedlichen Quellen stammen können, logisch integriert und in so genannte Bereichsdatenbanken geladen, wobei je eine Bereichsdatenbank die zentralen Informationen eines bestimmten, kohärenten Geschäftsbereiches enthält (z. B. Zahlungen, Kredite, Marketing etc.). In den Data Marts der Analyseschicht, die mit den Daten der Bereichsdatenbanken geladen werden, finden die eigentlichen Analysen statt. Mittels Archi2

Zentrale Division der Credit Suisse, die andere Divisionen beispielsweise bei der Einhaltung gesetzlicher Regulierungen unterstützt.

162


tekturprinzipien wurde festgelegt, dass alle Data Marts ihre Daten aus den Bereichsdatenbanken beziehen müssen, ein direktes Laden aus den Quellsystemen ist nicht architekturkonform. Es handelt sich somit im Rahmen der Referenzarchitektur um abhängige Data Marts. Die im unteren Bereich von Abb. 11 mit Metadaten Management bezeichnete Administrationsschicht umfasst schichtenübergreifende Aufgaben wie das Metadaten Management oder die Sicherheitsadministration. Im Folgenden wird nun untersucht, inwiefern die im Kapitel identifizierten Anforderungen an eine Systemarchitektur der Informationslogistik durch die Architektur der Credit Suisse erfüllt werden. Durch regelmäßige Ladezyklen kann eine hohe Aktualität der Data Marts erzielt werden. Mit der Einführung eines integrierten und unternehmensweiten Data Warehouses ist es der Credit Suisse gelungen, eine vollständige und konsistente Datenhaltung („single source of the truth”) zur horizontalen Informationsintegration zu etablieren. Ferner bietet das Data Warehouse der Credit Suisse als Basis einer vertikalen Informationsintegration Informationen für ein breites Benutzerspektrum an, von Kennzahlen und Berichten für Sachbearbeiter oder Kundenbetreuer bis hin zu stark aggregierten Kennzahlen für das Top Management.

Abb. 11. DWH-Referenzarchitektur der Credit Suisse


163

Das in der Administrationsschicht verankerte Metadaten Management dient dazu, ein hohes Maß an Transparenz innerhalb des gesamten Systems sicherzustellen. Die Erweiterung der Referenzarchitektur um die Anreicherungsschicht hat dazu beigetragen, die Performanz des Systems zu erhöhen, da die Ergebnisse komplexer Berechnungen wieder verwendet werden können. Ebenso wird der Aspekt der Flexibilität der Architektur mittels der Architekturprinzipien adressiert. So werden beispielsweise zur Vermeidung von Abhängigkeiten explizit Data Marts gefordert, die keinerlei Daten direkt aus den Datenquellen bzw. aus anderen Data Marts beziehen dürfen. Auch durch die Verwendung von Bereichsdatenbanken konnte das Data Warehouse einfacher wachsen, was folglich zu einer verbesserten Flexibilität beigetragen hat. Das Data Warehouse wird mit sämtlichen anderen analytischen Applikationen der Credit Suisse auf einer so genannten Applikationsplattform betrieben. Eine Applikationsplattform der Credit Suisse ist ein System, das sich aus vorintegrierten technischen Komponenten zusammensetzt und für eine Familie ähnlicher Applikationen als Infrastrukturbasis dienen soll (vgl. Kap. 15). Neben den technischen Komponenten sind innerhalb der Plattformen auch spezielle Plattformprozesse definiert worden, so auch für die Data Warehouse Plattform. Zu den Plattformprozessen gehören u. a. auch die Business Continuity Planning-Prozesse, die alle Maßnahmen umfassen, die der Sicherstellung der Wiederanlauffähigkeit in einem Katastrophenfall dienen. Ziel der Einführung dieser komplexen Mechanismen ist es, eine hohe Verfügbarkeit des Systems zu gewährleisten. Die Sicherheit wird zum einen durch entsprechende Sicherheitsmechanismen in der Administrationsschicht adressiert, zum anderen wurde durch die Wahl einer Hub and Spoke Architektur mit Data Marts bereits die Basis für eine erhöhte Sicherheit geschaffen. Eine detaillierte Darstellung der Referenzarchitektur mit allen relevanten Komponenten und Architekturprinzipien sowie eine Einordnung des Data Warehouses in das Applikationsplattformkonzept der Credit Suisse enthält Kap. 15.

6

Ausblick

In diesem Beitrag wurde ein Überblick über etablierte Architekturtypen der Informationslogistik und aktuelle Entwicklungen von Erweiterungen dieser Architekturtypen gegeben sowie eine Bewertung vorgenommen. Bei der Auswahl einer Systemarchitektur ist einerseits zu berücksichtigen, dass oftmals auf eine bestehende Architektur aufgesetzt wird, andererseits sollte versucht werden, eine möglichst zukunftssichere Basis für die Informati-

164


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


165

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. 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. Kachur, R.: Data Warehouse Management Handbook, Prentice Hall, USA 2000. Kimball, R.; Ross, M.: The Data Warehouse Toolkit, 2. Aufl., Wiley, New York 2002. Krallmann, H.; Frank, H.; Gronau, N. (Hrsg.): Systemanalyse im Unternehmen – Vorgehensmodelle, Modellierungsverfahren und Gestaltungsoptionen, 4. 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. 2006a, S. 425-438. Schelp, J.: Real-Time Warehousing und EAI, in: Chamoni P. et al. (Hrsg.): Analytische Informationssysteme - Business Intelligence-Technologien und Anwendungen, Springer, Berlin et al. 2006b, 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 ....................................................................................... 167 Eigenschaften von Informationslogistik-Projekten ........................ 168 Nutzendimensionen der Informationslogistik................................. 170 Wertbeiträge der Informationslogistik............................................ 173 Kostensenkung durch Informationslogistik .................................... 178 Organisatorische Einbettung........................................................... 182 Methodenbeispiel zur Bewertung der Informationslogistik ........... 183 Literatur .......................................................................................... 186

1

Einleitung

Die Informationslogistik (IL) hat zum Ziel, betrachtungseinheitübergreifend Informationsbedarfe im Unternehmen zu befriedigen (vgl. Kap. 1). 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 so-

168

Moritz Schmaltz, Jochen Töpfer

wohl für initiale 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.


169

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

170


ä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


171

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

172


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.


173

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. 1). 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-

174


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.


175

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-

176


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.


177

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-

178


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


179

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.

180


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.


181

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ö-

182


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


183

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

184


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


185

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

186


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.


187

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

188


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. 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 ....................................................................................... 189 Modelle und der Prozess von Integration und Evolution ............... 193 Die Rolle von Meta-, Stamm- und Referenzdaten in der Entwicklung und Pflege integrativer Systeme ................................ 203 Zusammenfassung .......................................................................... 207 Literatur .......................................................................................... 208

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-

190

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


191

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

192

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


193

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:

194

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


195

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

196

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-


197

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

Referenzdaten

Metadaten 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

198

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

199

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-

200

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.


201

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

202

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-


203

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

204

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


205

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-

206

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“,


207

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.

208

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-


209

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 .................... 211 Stand der Wissenschaft und Praxis ................................................. 213 Ordnungsrahmen für Datenqualitätsmanagement .......................... 215 DQM-Gestaltungselemente ............................................................ 218 Zusammenfassung und Ausblick .................................................... 228 Literatur .......................................................................................... 229

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. 1). 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:

212

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. 1). 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

213

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ä-

214


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


215

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

216


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.


217

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.

218


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 drei Aufgaben: x Bestimmung des Beitrags des DQM zur Informationslogistik im Unternehmen x Definition der DQM-Ziele x Bestimmung des Nutzens des DQM


219

x 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

Direkte Kosten schlechter Datenqualität fallen z. B an, wenn im Berichtswesen unterschiedliche Systeme verschiedene Werte für den gleichen

220


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 Warenausgangsbuchung führt zu Fehlern in der Bestandsführung, die sich auf alle nachfolgenden Prozesse wie bspw. den Warennachschub auswirken.


221

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 den Wert aller Pseudo-Bepo ins Verhältnis zum Wert der gesamten Bestellpositionen.

222


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): x Sponsor in der Geschäftsleitung, der das Mandat zur Umsetzung der DQM-Maßnahmen erteilt

1

Stapf: Statistisches Auswertungsprogramm Filialen.


223

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 x x x

Grad der Diversifikation des Unternehmens Grad der Geschäftsprozessharmonisierung Bestehende Aufbauorganisation Branchenzugehörigkeit

224


x Wettbewerbsstrategie x 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

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

R,A

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. Die unterschiedlichen Datenmanagementprozesse werden am Beispiel der Pflege von Materialstammdaten erläutert. Grundsätzlich werden drei Prozesse unterschieden:


225

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 betrachtet, die geschäftsbereichsübergreifend verwendet werden (z. B. Lieferanten- und Materialstammdaten) x Definition der Beziehungen der Datenobjekte und Attribute untereinander

226


x Festlegung einer eindeutigen Definition für die Datenobjekte und Attribute sowie Identifikation von Synonymen und Homonymen x Festlegung der organisatorischen Gültigkeit der Datenobjekte und Attribute (z. B. unternehmensweit vs. länderspezifisch) x 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 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


227

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

228


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


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 Instituts für Wirtschaftsinformatik der Universität St. Gallen in Zusammenarbeit mit Partnerunternehmen erarbeitet.


229

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

230


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 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 ....................................... 231 Ziele einer Leistungsverrechnung .................................................. 233 Elemente einer Leistungsverrechnung............................................ 234 Information als Produkt und Informationsproduktion .................... 235 Vorgehensmodell der Methode ...................................................... 245 Zusammenfassung und Ausblick .................................................... 257 Literatur .......................................................................................... 259

1

Problemstellung und Herausforderungen

Innerbetriebliche Informationslogistik wird häufig durch Data Warehousing-Konzepte realisiert (vgl. Kap. 1). 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

232

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. 1). 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

233

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

234

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


235

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;

236

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


237

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-

238

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.


x

x

x

x

x

239

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.

240

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

Region

Kennzahlen Kennzahlen Marktpotenzialanalyse

Sicht Vertrieb Sicht Vertrieb

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

Darstellung

Tabellarisch und grafisch, Exportierbar in CSV- und PDF-Datei

Funktionalität

Standard-Funktionalität multidimensionale Analyse 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).


241

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

242

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.


243

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.

244

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 / LieferApplikation dateien 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 ETLProzesse 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.


245

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.

246

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


247

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

248

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


249

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

250

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


251

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

252

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-


253

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-

254

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


255

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)

256

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


257

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


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

258

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.


259

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.

260

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.

12 Business Intelligence-Strategie bei der Volkswagen AG

Thorsten Sommer, Birgit Wendlandt Volkswagen AG

Uwe Trost, Martin Zirkel Steria Mummert Consulting AG

1 2 3 4

Einleitung ....................................................................................... 261 BI-Strategie-Entwicklungsprozess ................................................. 263 Inhalte der BI-Strategie .................................................................. 267 Erfolgsfaktoren ............................................................................... 281 Literatur .......................................................................................... 283

1

Einleitung

Die Volkswagen Aktiengesellschaft mit Hauptsitz in Wolfsburg ist Europas größter Automobilhersteller. Über 320.000 Mitarbeiter sind weltweit für den Konzern tätig (Stand Ende 2006). Zu den Konzernmarken zählen neben Volkswagen PKW, Audi, Seat, Skoda und Nutzfahrzeuge ebenfalls Bentley, Bugatti und Lamborghini. Um die Bindung der Kunden an die Konzernmarken zu erhöhen, werden des Weiteren Finanzdienstleistungen angeboten. Mit über 5,7 Millionen ausgelieferten Fahrzeugen (9,7% Weltmarktanteil) erreichte der Konzern einen Umsatz von 104,875 Mrd. € und ein Ergebnis nach Steuern von 2,75 Mrd. € im Geschäftsjahr 2006. Die Volkswagen Aktiengesellschaft hat den verbesserten Umgang mit Information und die Optimierung von Entscheidungsprozessen als strategischen Erfolgsfaktor erkannt. Im Unternehmen werden Business Intelli-

262

Thorsten Sommer, Birgit Wendlandt, Uwe Trost, Martin Zirkel

gence (BI)-Systeme zur Entscheidungsunterstützung auf strategischer, taktischer und operativer Ebene betrieben. Alle BI-Systeme müssen unabhängig von ihrer Reichweite und ihrem Einsatzspektrum in ihrem Gültigkeitsbereich optimal mit Daten versorgt werden. Die BI-Strategie beschreibt im Sinne eines langfristigen und unternehmensweiten Master-Plans, wie das Unternehmen die Auswertung von Informationen ausgestaltet. Hierdurch schafft sie die Grundlagen für den Aufbau konzernweiter BI-Initiativen. Oberste Ziele der BI-Strategie sind die Ausweitung des Business Use und die Optimierung der Gesamtkosten für die BI-Landschaft (Volkswagen AG 2005). Die Entwicklung und Umsetzung der BI-Strategie wird proaktiv aus der IT heraus getrieben. Dazu wurde bereits 2005 mit dem IT Kompetenzfeld Business Intelligence (ITP-KF BI) eine organisatorische Einheit geschaffen, die die notwendigen fachlichen, organisatorischen und technischen Aktivitäten im Rahmen des BI-Programms koordiniert. Die Volkswagen Aktiengesellschaft wird in Zukunft allgemein hohe Anforderungen an die Verwendung und Analyse von Informationen haben. Die nachstehend genannten Faktoren motivierten die Volkswagen Aktiengesellschaft zur Entwicklung einer BI-Strategie für den Gesamt-Konzern: x Die Volkswagen Aktiengesellschaft agiert in einem internationalen, komplexen Umfeld, das von Dynamik und Wettbewerbsintensität gekennzeichnet ist, und in dem Entscheidungen durch verlässliche Informationsgrundlagen unterstützt werden müssen. Komplexität wird beherrschbar durch Anwendung von Grundprinzipien der Informationslogistik: Die richtige Information in der richtigen Qualität und Sicherheit zur richtigen Zeit für den richtigen Adressaten am richtigen Ort zur Verfügung zu stellen. x Die Volkswagen Aktiengesellschaft verändert sich zu einem prozessorientierten Unternehmen. So kann den Anforderungen der dynamischen Märkte und deren regulatorischen Vorgaben begegnet werden. Zahlreiche Entscheidungen werden zukünftig dezentral getroffen. Für die Gesamtsteuerung des Unternehmens ist es unerlässlich, zentrale integrierte Kennzahlensysteme aufzubauen und die informationstechnischen Versorgungsströme zu etablieren. x Eine integrierte Datenbasis für eine strategiekonforme Führung oder einheitliche Kundensicht sind Bestandteile der Vorstands-Agenda. So beschreibt der „Volkswagen-Weg“ ein Restrukturierungsprogramm der Marke Volkswagen. Es setzt dem Konzern und jedem einzelnen Standort verbindliche Ziele und gibt hohe Standards und Methoden vor, deren Einhaltung fortlaufend überprüft wird. Dieses „Führen über Kennzah-

Business Intelligence-Strategie bei der Volkswagen AG

263

len“ muss durch Business Intelligence auf der strategischen und operativen Ebene auch informationstechnisch unterstützt werden. x Die Volkswagen Aktiengesellschaft besitzt in ihrer Branche die Kostenführerschaft für Prozesse in der Informationstechnologie (IT). Investitionen in IT-Systeme werden sorgfältig geprüft und einer Wirksamkeitsbetrachtung unterzogen. Eine übergeordnete strategische Gesamtplanung für BI muss daher existieren, um die Investments in BI aus Unternehmenssicht effektiv und effizient zu gestalten. x Fachliche und technologische Treiber innerhalb des Marktes kennzeichnen BI als eine innovative Technologie. Ziel ist es daher, auch diese Potenziale für den Volkswagen-Konzern zu heben. x In einem ersten System-Überblick der Marken Volkswagen und Audi ergab sich ein heterogenes, komplexes Bild einer BI-Landschaft mit unterschiedlichsten Produkten, Technologien und Architekturen. Die Reduktion von Komplexität und die Hebung von Synergiepotentialen durch Konsolidierungsmaßnahmen sind erforderlich. Im folgenden Abschnitt wird der Strategieentwicklungsprozess beschrieben. Die Inhalte der BI-Strategie werden in Abschn. 3 dargestellt und in Abschn. 4 wird zusammenfassend auf die Erfolgsfaktoren für die Strategieumsetzung eingegangen.

2

BI-Strategie-Entwicklungsprozess

Vor dem Hintergrund hoher Komplexität in der unternehmerischen Umgebung, der Treiberszenarien für BI, der Erwartungshaltungen der beteiligten Menschen (Strategien werden von Menschen für Menschen entworfen) und in Zeiten von Informationsmangel und Informationsflut zugleich, entstand die BI-Strategie der Volkswagen Aktiengesellschaft in einem strukturierten Entwicklungsprozesses. Dieser Strategieentwicklungsprozess (vgl. Abb. 1) ist zunächst BIunspezifisch. Nach einer erfolgreichen Initiierung wurden die klassischen Prozessschritte Analyse, Design, Umsetzung und Controlling durchlaufen (Trost u. Zirkel 2006). Die BI-Spezifika kommen in der Ausgestaltung der einzelnen Prozessschritte zum Tragen. In der Phase Initiierung wurden die Maßnahmen umgesetzt, die im Vorfeld einer Strategieentwicklung zu erledigen sind (Stakeholder-Analyse etc.). Der strategische Rahmen definiert organisatorische Eckpfeiler des Entwicklungsprojektes (Wer, Wann, Mittel, Wie, Vorgehen). Eine Selbstverpflichtung des Managements sowie ein dem Unternehmen angemessenes Change-Management sind Grundlagen des Erfolges.

264


Initiierung

Analyse

Assessment Stakeholder

Interne Analyse

Strategischer Rahmen

Externe Analyse

Design

Bewertung

Positionierung

Umsetzung

Maßnahmen

Projekte / Roadmap

Controlling

Balanced Scorecard

Planung

Management Strategieprozess Kontinuierlicher Verbesserungs-Prozess

Abb. 1. Der BI-Strategie-Entwicklungsprozess

In der Phase Analyse ließen sich drei Abschnitte unterscheiden. Im ersten Abschnitt der internen Analyse werden der Zustand der BI-Landschaft des Unternehmens sowie die strategischen Rahmenbedingungen aufgenommen. Hier hat es sich bewährt, eine Methode einzusetzen, die speziell auf BI-Belange zugeschnitten ist. Der inhaltliche Rahmen der AnalyseBetrachtungen kann dabei durch ein Reifegradmodell für Business Intelligence aufgespannt werden. In Anlehnung an die Modellbildung können bei der Entwicklung von BI-Lösungen die drei erfolgskritischen Dimensionen Fachlichkeit, Technik und Organisation herangezogen werden. Die fachliche Dimension widmet sich der Bedeutung von BI-Lösungen im Gesamtkontext der strategischen Unternehmungsausrichtung. Hier werden die fachlichen Informationsmodelle, die Validität der angebotenen Informationsinhalte sowie der Grad der Unterstützung von Analyse- und Entscheidungsprozessen berücksichtigt. Die Dimension Technik betrachtet die Flexibilität des Systementwurfs, stellt dieser den Standardisierungsgrad der Umsetzung gegenüber und fokussiert die Qualität der BI-Lösung. In der Dimension Organisation werden die den BI-Systemen zugrunde liegenden Prozessmodelle (inkl. Rollen und Aufbauorganisation) betrachtet. Einfluss auf die Entwicklung der BI-Strategie hatten außerdem die externe Marktsicht und Benchmarks in der Peergroup (Steria Mummert Consulting AG 2006). Bei Spiegelung der Marktsicht sind branchenspezifische Ausprägungen zu berücksichtigen. In der Bewertung des Zustandes der BILandschaft wurde eine Reifegradeinstufung vorgenommen und eine SWOT-Analyse der BI-Landschaft durchgeführt. In der Phase Design wurden ebenfalls drei Abschnitte abgegrenzt. Im ersten Abschnitt der strategischen Positionierung wurde die Vision und Mission als Grundlage der BI-Strategie entworfen. Die hohe Kunst besteht darin, beide Elemente auf Ebene der Kommunikation in Einklang mit den wichtigsten strategischen Zielen zu bringen. Nach deren Entwicklung wur-


265

den diese als ein neuer Impuls innerhalb des Unternehmens publiziert und ein erster Orientierungsrahmen gesetzt (Müller-Stewens u. Lechner 2005). In der Phase der strategischen Planung geht es im Wesentlichen um eine Zielentwicklung. Dies bedeutet zunächst, dass Ziele aus übergeordneten Strategien (Unternehmensziele, Prozessziele, Ziele der IT etc.) berücksichtigt werden müssen. Zum Beispiel waren Kostenführerschaft in der Prozessabwicklung und eine Single Vendor-Strategie durch die ITOrganisation vorgegeben und so der Rahmen für die BI-Strategie abgesteckt. Ein ausgewogenes Zielsystem soll alle Anforderungen beinhalten, die an die BI aus verschiedenen Perspektiven gestellt werden. Die Ziele sollten bereits während der Formulierung um KPIs (Key Performance Indicators) angereichert werden. Ein geordneter Zielfindungsprozess gewährleistete, dass das Arbeitsergebnis dieser Phase in der geforderten Qualität erbracht wurde. Die Erfahrung zeigt, dass der Prozess iterativ ist: Die Ergebnisse verdichteten sich in mehreren Schleifen (Auflösen von Zielkonflikten, Zielpriorisierung etc.). In der Praxis der BI-Strategieentwicklung hat es sich als sehr hilfreich erwiesen, die strategischen Ziele über eine Strategy Map entlang der Ursache-Wirkungsbeziehungen zu visualisieren (Kaplan u. Norton 2004). Die Strategy Map diente der Fokussierung auf das Wichtige und war zugleich ein Kommunikationsinstrument. Im nächsten Schritt kam es darauf an, geeignete strategische Maßnahmen (Teilstrategien) zu entwickeln. Die Handlungsfelder der BI-Strategie wurden entlang der Dimensionen Fachlichkeit, Organisation und Technik aufgespannt und im Endzustand durch ausformulierte Teilstrategien beschrieben. Methodisch geschah die Entwicklung einer Teilstrategie in der Regel über Antworten auf Leitfragen nach wichtigen Attributen des Handlungsfeldes. Über diese Attribute lassen sich auch Beziehungen zwischen den Handlungsfeldern ausdrücken. So ist z. B. das Handlungsfeld Datenmanagement über das Meta-/Master-Datenmanagement mit den Handlungsfeldern Architektur (SOA) und einem fachlichen Kennzahlensystem der Business-Strategie verbunden. Sukzessive entstand ein Portfolio strategischer Optionen des jeweiligen Handlungsfeldes, das im Nachgang bewertet wurde (z. B. Aufbereiten verschiedener Architekturvarianten für die Auswahl einer konkreten Referenzarchitektur). In Version 1.0 der BIStrategie hat es sich als hilfreich erwiesen, die strategischen Maßnahmen zu inhaltlich zusammengehörenden Maßnahmenpaketen zu bündeln. Mit fortschreitender Umsetzung der BI-Strategie konnten die Maßnahmen in der Version 2.0 entsprechend ihres Wirkungsbereiches in den jeweiligen Organisationseinheiten angeordnet werden. Die Implementierung erfolgt in konkreten Teilprojekten, in denen die strategischen Maßnahmen entlang einer Roadmap umgesetzt werden. Das

266


übergeordnete BI-Programm dient als die verbindende Klammer und steuert die Teilprojekte im Sinne der BI-Strategie. Der Erfolg des BI-Programms und der strategischen Maßnahmen wird kontinuierlich über eine Balanced Scorecard gemessen. Die gesamte Strategieentwicklung wird einem kontinuierlichen Verbesserungsprozess unterzogen. Die erste Version der BI-Strategie wurde Anfang 2006 finalisiert. Gut ein Jahr später wurde die aktuelle zweite Version fertig gestellt. Dabei handelt es sich um eine Fortschreibung, Aktualisierung und Detaillierung der Vorgängerversion. Das strukturierte Vorgehen bei der Strategieentwicklung hat folgende Vorteile: x Planung - Die Erarbeitung einer BI-Strategie ist ein ambitioniertes Vorhaben, in dem zahlreiche, voneinander abhängige Handlungsfelder adressiert werden – Reduktion der Komplexität durch Strukturierung - Dezidiertes planerisches Vorgehen für alle Teilphasen x Support des Strategieentwicklers - Handhabung des Entwicklungsprozesses wie ein normales Projekt mit klar definierten Schnittstellen und Ergebnistypen sowie Zeit- und Budgetvorgaben. - Bereitstellung eines Methodenkoffers ermöglicht strukturierte Entwicklung von BI-Teilstrategien / Maßnahmenpaketen. x Qualität - Qualitätsgesichertes Gesamtvorgehen - Controlling der Strategieentwicklung über Quality-Gates - Abfolge der Aktivitäten in der richtigen Reihenfolge reduziert Fehler - Im Fall einer Revision überprüft die Analysephase auch die Gültigkeit der in Vorgängerversion getroffenen Annnahmen. - Zielformulierung angereichert durch KPIs macht den Ergebnisfortschritt in der Umsetzung der strategischen Maßnahmen kontrollierbar. x Management - Richtige Teambildung - Angemessene Kommunikation - Koordiniertes Change-Management Die konsequente Anwendung des Strategieentwicklungsprozesses hat zu einem Ordnungsrahmen geführt, der nachhaltig alle operative Maßnahmen steuert, den Mitarbeiten die Handlungsspielräume aufzeigt und über das Change-Management in die gesamte Organisation getragen wird. Dadurch


267

ist der Nutzen des Strategieentwicklungsprozesses weitaus höher als der damit verbundene Aufwand.

3

Inhalte der BI-Strategie

3.1 Rahmenbedingungen Business-IT-Alignment bezogen auf den Einsatz von Business Intelligence im Volkswagen-Konzern ist das Ergebnis einer konsequenten Ausrichtung der IT auf die Vorgaben der Unternehmensstrategie. Voraussetzung dafür ist eine stringente Zielhierarchie, innerhalb der die BI-Strategie in die ITStrategie integriert ist, die sich wiederum aus der Konzernstrategie ableitet. Aus der Konzernstrategie 2015 sind folgende Kernaussagen relevant: x x x x x x

Konzentration auf Kernkompetenzen First-Mover-Mentalität Strikte Ausrichtung auf Ertrag Kundenorientierte Fahrzeug-Produktpolitik Fortlaufende Erschließung von Effizienz- und Effektivitätspotenzialen Partnerschaftliche Zusammenarbeit mit Partnern und Mitbestimmungsorganen x Schnelle und unkomplizierte Problemlösungsfähigkeit x Geringe Kapitalbindung, Kapitalrendite > 9%, Umsatzrendite > 8% Aus der IT-Strategie ergeben sich folgende relevante Kernaussagen für die BI-Strategie: x Risikominimierung durch Gewährleistung einer angemessenen Grundsicherheit aller IT-Lösungen x Standardisierung von IT-Systemen durch Bereitstellung von Applikationsplattformen, Lösungsbausteinen und -elementen auf Grundlage des Architekturbaukastens x Steigerung der Flexibilität und Geschwindigkeit durch Reduzierung der Komplexität und Heterogenität in der IT-Architektur x Unterstützung der Vernetzung mit Partnern zur Optimierung der Wertschöpfungskette über Unternehmensgrenzen hinweg x Erhöhung der messbaren IT-Prozess-, Projekt- und Softwarequalität x Verkürzung der Entwicklungszeiten auf Basis standardisierter Applikationsplattformen x Erhöhung des IT-Budgetanteils für wertschöpfende Projekte durch Reduzierung der IT-Servicekosten

268


x Kosteneffiziente Betriebsführung, unterstützt durch IT-Architekturstandards sowie durch Nutzung am Markt verfügbarer Standardsysteme mit Vorrang vor Eigenentwicklungen. Die Vision der Volkswagen Aktiengesellschaft für Business Intelligence „BI – der Weg zum Wissensvorsprung des Volkswagen-Konzerns. Einsichten schaffen, Informationen integrieren, Kompetenzen vernetzen“ beinhaltet als einen wesentlichen Teil, die tiefere Einsicht in Daten (Unternehmenszustände) zu schaffen, auf deren Basis Entscheidungsgrundlagen für operative Prozesse entstehen. Die Integration von Informationen des gesamten Volkswagen-Konzerns und dessen Umfelds über die Kernprozesse hinweg ist ein weiterer Teil. Außerdem wird die Vernetzung von Kompetenzen durch Querschnittfunktionen sowohl prozess-, als auch marken- und regionsübergreifend vorangetrieben. Alle diese Teile zusammen bewirken den angestrebten Wissensvorsprung des Volkswagen Konzerns. Abgeleitet ergibt sich die Mission der BI-Strategie in den folgenden vier Feldern: x Erschließen neuer fachlicher Möglichkeiten: Das BI-Programm verstärkt den ITP&O (IT, Prozesse und Organisation)-Bereich als Innovator im Unternehmen. x Effizienz durch Standardisierung: Das BI-Programm überführt die BILandschaft in die BI-Plattform durch die Definition von BI-Standards und deren Implementierung in den Bereichen BI-Governance, Plan, Build und Run. x Qualität vor Quantität: Das BI-Programm steht im Unternehmen für die fachliche, organisatorische und technische Qualität der BI-Landschaft. x Mehr BI fürs Geld: Das BI-Programm schafft die Voraussetzungen, um den steigenden Anforderungen an BI mit den zur Verfügung stehenden Mitteln zu begegnen. Aus Vision und Mission wurde ein Zielbaum mit den vier Kernzielen „Kosten pro BI-System senken“, „Qualität von BI erhöhen“, „Standardisierung erhöhen“, „Innovativität von BI erhöhen“ abgeleitet. Die Elemente des Zielbaums lassen sich auf die Strategy Map übertragen (vgl. Abb. 2) Oberste Ziele der BI-Strategie sind die Ausweitung des Business Use und die Optimierung der Gesamtkosten für die BI-Landschaft. Eine verbesserte Prozessunterstützung und eine höhere Prozessabdeckung führen zusammen mit der Möglichkeit, Enterprise Reporting durchzuführen, dazu, dass der Business Use verbessert wird. Voraussetzung für die Kostenoptimierung ist die Schaffung von Transparenz im Konzern im Bezug auf alle BI-Initiativen.


Wertorientierung

Business Use ausweiten

Kunde&Markt

Prozessunterstützung verbessern

Prozessabdeckung erhöhen

Enterprise Reporting ermöglichen

Transparenz im Konzern erreichen

Produktivitäten

Agilität erhöhen

Bebauungsplanung steuern

Entwicklung standardisieren

Betrieb organisieren

Innovation

Komplexität reduzieren

Attraktiver Arbeitsplatz

269

Kosten optimieren

Konsolidierung durchführen

Qualitätsmanagement anwenden

BI-Know-How stärken

Abb. 2. Strategy Map entlang der Dimensionen der Volkswagen Balanced Scorecard

Zentrales Instrument zur Erreichung der obigen Ziele ist eine gesteuerte Bebauungsplanung. Durch sie entsteht u. a. Transparenz über den jeweils aktuellen Ist-Zustand, der wiederum die Qualität der Bebauungsplanung verbessern hilft. Eine reduzierte Komplexität, die Konsolidierung der existierenden BI-Landschaft sowie die Standardisierung und Organisation von Entwicklung und Betrieb sind Bestrebungen, die sich in der Bebauungsplanung niederschlagen. Durch die reduzierte Komplexität wird die Agilität erhöht, was zusätzliche Möglichkeiten eröffnet, den Nutzen für die Fachanwender zu steigern. Vorraussetzung für Konsolidierung, Standardisierung und Organisation ist die Anwendung von Qualitätsmanagement in allen Bereichen. Grundlage und Ausgangspunkt der gesamten BI-Strategie ist die Bündelung und Stärkung von BI Know-how – im ITP-KF Business Intelligence sowie in den BI-Projekten und -Systemen. Zielkonflikte bestehen z. B. zwischen der Ausweitung der BI-Investments und dem Ziel der Kostenoptimierung, zwischen dem Standardisierungsziel auf Entwicklungs- und Betriebsebene und einer erhöhten Agilität, sowie zwischen der Komplexitätsreduktion und der durchzuführenden Konsolidierung. Im Rahmen der übergreifenden BI-Strategie sind Verknüpfungen zu Detailstrategien definiert: In der fachlichen BI-Strategie werden Konzepte der Business Intelligence für den Fachbereich erarbeitet. In der BI-Produkt-

270


strategie werden Kriterien für strategische Lösungspartnerschaften definiert und Grundlagen geschaffen, um Handlungsfelder der BI-Services mit Standardprodukten zu hinterlegen. Die BI-Konsolidierungsstrategie beschreibt die strategischen Vorgaben, die mit dem Vorhaben der Konsolidierung verbunden sind (Planung, Steuerung, Durchführung). In der BIDatenmanagementstrategie werden die notwendigen Voraussetzungen für eine optimale Wertschöpfung durch Business Intelligence geschaffen. Die BI-AMS-Strategie (Application Management Services) beschreibt den Aufbau des BI-AMS-Clusters zum Betrieb der BI-Plattform. Die BI-ITServices-Strategie enthält alle Vorgaben für die Bereitstellung einer standardisierten, zukunftssicheren Infrastruktur für die BI-Plattform. 3.2 BI-Programm Das BI-Programm koordiniert die Weiterentwicklung der gesamten BILandschaft über strategische Maßnahmen. Es hat unter anderem zur Aufgabe, die BI-Landschaft (Ist-Zustand) in die BI-Plattform (Soll-Zustand) zu überführen. Die BI-Plattform besteht aus ausgewählten Data Warehouses (den sogenannten Gravitationszentren) und BI-Services, die den Vorgaben der BIStrategie entsprechen. Die Gravitationszentren sind als konsolidierte Datenbasis die tragenden Säulen des BI-Informationsangebotes des Volkswagen-Konzerns. BI-Services stellen die Daten aus den Gravitationszentren entsprechend der Anforderungen in einen fachlichen Kontext. Durch diese Entkopplung ist es möglich, den Zielkonflikt zwischen Flexibilität und Agilität seitens der BI-Services einerseits und Qualität und Standardisierung auf Ebene der Gravitationszentren andererseits aufzulösen. Die BIPlattform ist als verbindlicher gestalterischer Rahmen nur über einen koordinierten Integrationsprozess umsetzbar. Das BI-Programm bildet die gemeinschaftliche Klammer über Fachbereiche und IT. Der Erfolg des BI-Programms hängt maßgeblich von der aktiven Zusammenarbeit der beteiligten Bereiche ab. So ist der Fachbereich für die Definition der fachlichen Anforderungen und das Heben von Nutzenpotentialen verantwortlich, die IT-Bereiche verantworten kostenoptimale Ausgestaltung, die Neu-/Weiterentwicklung von BI-Systemen, sowie deren Betrieb. Die Zusammenarbeit im BI-Programm erfolgt im Rahmen von Projekten und wird durch eine geeignete Gremienlandschaft koordiniert. Die Umsetzung der Inhalte der BI-Strategie erfolgt u. a. im Rahmen der im Folgenden beschriebenen Maßnahmen.


271

3.3 Fachliche BI-Strategie Ziele der strategischen Maßnahme „BI-Fachbereich & Geschäftsprozesse“ sind: x x x x x x

Verdeutlichung des möglichen Einsatzspektrums von BI Analysen innerhalb des Fachbereiches Weiterentwicklung der BI in Richtung Performance Management Weiterentwicklung der BI in Richtung Operations Mögliche Organisationsformen von BI im Fachbereich Bewusstsein für neue Technologien verankern

Diese Maßnahmen schaffen die Grundlagen für die nachgelagert zu erstellende fachliche BI-Strategie. Fachliche Prozesse werden durch Business Intelligence sowohl im Rahmen der strategischen Planung als auch bei der operativen Steuerung unterstützt. Die Rückführung der Erkenntnisse aus der operativen Umsetzung von Maßnahmen führt zu einer Anpassung der Steuerungsziele im Sinne eines Closed Loops. Ein konsolidiertes, konzernweites Kennzahlensystem auf Basis gemeinschaftlich vereinbarter Kennzahlendefinitionen ermöglicht Enterprise Reporting über die Kern-Geschäftsprozesse Produktprozess (PP), Serviceprozess vor Kunde (SPK), Kundenauftragsprozess (KAP) sowie Steuernde und Unterstützende Prozesse (SUP) hinweg. Die Zusammenhänge der einzelnen Elemente der fachlichen BI-Strategie sind in Abb. 3 dargestellt. PP

SPK

KAP

Operative Steuerung

SUP

Vorgaben/Zielwerte

Ableitung von KPIs Steuerungsziele, Metriken und Prozesse

Vorgabe von Zielwerten

permanent

mittelfristig

Konsolidierung in ein konzernweites Kennzahlensystem

Bewertung und Ableitung von Maßnahmen

Analyse Reporting

Implementierung

Enterprise Reporting

Strategische Planung

Abb. 3. Fachliche Wirkbereiche der BI-Strategie

BI-Systeme

PP

SPK

KAP

SUP

272


3.4 BI-Master Construction Plan Im IT-Architektur-Management des Volkswagen-Konzerns vereint der Master Construction Plan (MCP) die Bebauungspläne und stellt dar, wie auf Grundlage der Konzernstrategie und relevanter Kernprozess- bzw. Geschäftsbereichsstrategien IT-Anwendungen die Anforderungen der einzelnen Kernprozesse erfüllen bzw. in Zukunft planmäßig erfüllen werden. Die MCPs sind somit auch ein Kommunikationsmittel zwischen IT und Fachbereich in den jeweiligen Kernprozessen. Ziele der strategischen Maßnahme „BI-Master-Construction Plan“ sind: x Ganzheitliche, sowohl die BI-Services-Schicht als auch die Gravitationszentren-Schicht umfassende, prozessübergreifende Gestaltung der BI-Landschaft mit dem Ziel der Überführung in die BI-Plattform x Klärung der wechselseitigen Abhängigkeiten zwischen den im Konzern existierenden Bebauungsplänen und Portfolios und den zugehörigen Prozessen x Visualisierung der BI-Ist-Landschaft unter Verwendung unterschiedlicher, zweckorientierter Sichten x Erarbeitung einer Soll-Vorstellung in Zusammenarbeit mit allen Stakeholdern der BI-Landschaft x Visualisierung der Soll-Landschaft (BI-Plattform) x Ableitung eines Transferprozesses vom Ist zum Soll (über Zwischenschritte, Berücksichtigung der Planungszyklen) x Ableitung, Auswahl, Priorisierung, Kombination und Steuerung der notwendigen Maßnahmen innerhalb dieses Transformationsprozesses x Integration neuer fachlicher Anforderungen in diese Gestaltungs- und Planungsprozesse Die BI-Bebauungsplanung steht im Zentrum des BI-Architektur-Managements und stellt zusammen mit dem Portfolio-Instrumentarium Werkzeuge zur Überführung der BI-Landschaft in die BI-Plattform bereit. Kernprozessübergreifende Anforderungen an BI, bestehende oder geplante BI-Systeme, die in mehreren Prozessen zum Einsatz kommen und Entscheidungen über Prozessgrenzen hinweg unterstützen oder bei der Optimierung ganzer Prozessketten wirken, sowie die durchgängige Gestaltung der gesamten BI-Plattform werden koordiniert umgesetzt, indem die bestehenden MCPs um einen BI-MCP ergänzt werden.


273

3.5 BI-Governance und BI-CC Das ITP-KF BI zentralisiert wesentliche Aufgaben über die BI-Governance und das BI-Competence Center. Im Einklang mit der CTO-Philosophie (Chief Technology Officer) wird das Leistungsspektrum des ITP-KF BI in Form eines Produktportfolios dargestellt. Dabei werden die Leistungen der Funktion „BI-Competence Center“ sowie Teile der Ergebnisse der Funktion „BI-Governance“ als Produkte verstanden. Das Produktportfolio des ITP-KF BI deckt drei zentrale Bereiche des CTO-Scopes ab: Die durchgängige Gestaltung der Geschäftsprozesse, die Beherrschbarmachung der IT sowie die Erhöhung der Projektlieferfähigkeit. Die Zuordnung der Produkte zu den Funktionen „BI-Competence Center“ und „BI-Governance“ ist nicht sinnvoll, da das ITP-KF BI ganzheitlich auf die BI-Landschaft wirkt. Die Ziele des ITP-KF BI und der BIGovernance sind im Folgenden aufgeführt. Ziele des ITP-KF BI: x Etablierung der Produkte des ITP-KF Business Intelligence, Erarbeitung und Etablierung von BI-Bausteinen und Standards x Fortführung der Operationalisierung und Professionalisierung der internen Prozesse x Weiterentwicklung des BI-Plattform-Konzepts, Vergrößerung der Kontaktfläche und des für die Fachbereiche sichtbaren BI-Potenzials durch Schärfung des BI-Service-Konzeptes x Erarbeitung von Prozessmodellen für das Management der Gravitationszentren zur Stärkung dieser Säulen der BI-Plattform x Fortführung der Konsolidierung als zentraler Transformationsprozess zur Erreichung der Soll-Vorstellung einer BI-Plattform x Aktive Zusammenarbeit mit dem Datenmanagement Ziele der BI-Governance: x Etablierung von BI-Governance-Prozessen (und -Objekten), einer abgestimmten Organisation sowie klar definierter und transparenter Entscheidungsrechte und -pflichten zur Ermöglichung einer ganzheitlichen Gestaltung und Steuerung der BI-Landschaft gemäß der BI-Strategie – konzernweit und geschäftsprozessübergreifend x Sicherstellung der Umsetzung der vorgegebenen Standards in den Projekten (BI-Lifecycle-Betrachtung, Anwendung des Volkswagen Systementwicklungsprozesses (SEP), Bausteinverwendung, Datenmanagement, Betrieb von BI-Systemen)

274


x Definition eines abgestimmten Sets von Instrumenten (Governance-Objekten) und Prozessen Die BI-Governance muss folgende Fragen beantworten: x x x x x

Welche Entscheidungen sind durch wen in welcher Rolle bezüglich was (BI-Objekt) wann (BI-Objekt innerhalb des BI-Lifecycle) wie (Prozess) zu treffen?

Die BI-Strategie bildet die Grundlage für das Handeln im BI-Governance-Prozess-Netzwerk. Insbesondere gibt sie die Orientierung für die Prozesse der Data Governance, der fachlichen Planung, des BI-PortfolioManagements sowie der ganzheitlichen und strategiekonformen Steuerung der Konsolidierung vor (siehe Abb. 4, #1). Sowohl die fachliche Planung als auch das BI-Portfolio-Management und die Konsolidierung benötigen Informationen über BI-Systeme und laufende BI-Projekte. Zu diesem Zweck wird das BI-Audit-Management mit der Informationserhebung beauftragt, deren Ergebnisse im zentralen Informationssystem zu BI-Elemente (BI-EYE) abgelegt und über dieses zur Verfügung gestellt werden (siehe Abb. 4, #2). Die Ergebnistypen der Data-Governance-Prozesse sowie die BI-Referenzarchitektur werden über das BI-Lifecycle-Management an die BI-Projekte herangeführt und stellen so eine standardkonforme Projektdurchführung sicher (siehe Abb. 4, #3). Der BI-MCP sowie das BIPortfolio geben im Zusammenspiel den Gestaltungsraum für BI-Projekte vor und steuern insbesondere die Überführung der BI-Landschaft in die BI-Plattform (siehe Abb. 4, #4). Informationen über BI-Systeme und Projekte werden nicht nur im Rahmen der Audits für die zuvor angesprochenen Gestaltungsprozesse gesammelt, sondern auch vom BI-Finanzmanagement und für das BI-Lifecycle-Management benötigt (siehe Abb. 4, #5). Über die BI-Balanced Scorecard wird das komplette Prozessnetzwerk kontrolliert und die so gewonnenen Erkenntnisse fließen in den Strategieprozess ein (siehe Abb. 4, #6). Das gesamte Prozessnetzwerk unterliegt dabei einem kontinuierlichen Verbesserungsprozess (siehe Abb. 4, #7).


275

verbrauchen Prozesse steuert

BI-DataGovernanceProzesse

BI-DataStandards

steuert

BI-PlanungsProzesse

BIReferenzArchitektur

BI-LifecycleManagmentProzesse

3

5 BI-Projekte und Systeme

Stakeholder Value steuert treibt

BI-Strategie

4

1

steuert

BI-Portfolio BIKonsolidierungsSteuerungsprozesse

Ressourcen

BI-MCP

BI-PortfolioManagmentProzesse

2 beauftragt

BI-FinanzBI-FinanzManagmentManagmentProzesse Prozesse

BI-AuditManagment und Durchführung

misst Verbrauch füllt

BI -EYE Monitoring 6 Bestätigung oder Neuausrichtung

Ergebnisse BI - BSC

Kontinuierliche Analyse verbessert Zustand BI Landschaft BI Performance Risiko Wertbeitrag BI ...

7

erzeugt

Abb. 4. BI-Governance-Prozesse

Ziele des BI-Competence Center: x Unterstützung von BI-Projekten, Eingliederung in das CTO-Leistungsangebot, Abdeckung des relevanten CTO-Scopes. x Verankerung der BI-Referenzarchitektur in der BI-Landschaft und damit Unterstützung des Transformationsprozesses der BI-Landschaft in die BI-Plattform. x Gestaltung des Zusammenwirkens von Business Intelligence mit anderen Technologien (Gestaltung der Schnittstellen zu anderen Technologien). x Unterstützung der Umsetzung der CTO-Strategie durch die BI-Produktstrategie. Abbildung 5 bietet einen detaillierten Blick auf die Prozesse innerhalb der Funktion BI-Competence Center. Sie differenzieren zwischen den eher administrativ geprägten Prozessen des Anforderungs- und Auftragsmanagements sowie den eher technologieorientierten Prozessen der eigentlichen Leistungserbringung (Consulting, Erbringung von Architekturleistungen,

276


Bausteinerstellung und BI-Baustein-Programm-Management). Unter den steuernden und unterstützenden Prozessen innerhalb des BI-CCs besonders hervorzuheben sind die Angebotsentwicklungs- und BI-Labor-Prozesse, da in ihnen in besonderem Maße die Beherrschung des Themas Business Intelligence und die Kundenorientierung des ITP-KF BI zum Ausdruck kommen. Die Prozesse des BI-Competence Centers wirken dabei mit den Prozessen aller anderen Teile des BI-Programms zusammen. BI-Governance-Prozesse

Fachbereichs-BI-Prozesse PIO-BI-Prozesse BI-CCManagement -Prozesse

ConsultingProzesse

Unterstützungsprozesse

BI-CC-SkillManagementProzesse

ArchitekturManagement

QualitätsManagementprozesse

BI-CCRessourcenAuftragsManagement- management Prozesse

BausteinProgrammManagementprozesse

Auftragsprozesse

Technologieprozesse

Steuerungsprozesse

AnforderungsManagementprozesse

AngebotsEntwicklungsprozesse

AuftragsAbwicklungsprozess

BI-CC

BI-Labor(F&E)prozesse

BI-AMS-Cluster-Prozesse BI-IT-Services-Prozesse

Abb. 5. Prozesse des BI-Competence Center

Exkurs: Datenmanagement und BI Datenmanagement ist eine notwendige Voraussetzung für die optimale Wertschöpfung durch Business Intelligence innerhalb des Volkswagen-Konzerns. Datenmanagement wirkt auf Unternehmensebene.


Data Governance

Allgemeingültige Festlegungen von Rollen und Prozessen zum Umgang mit Daten im Konzern.

Data Ownership

Verantwortung f ür die Bereitstellung einzelner Datenelemente, insbesondere im Hinblick auf Eindeutigkeit, Verf ügbarkeit, Aktualität und Qualität.

Data Steward

Rolle, die f ür einen f achlich zusammenhängenden Teil des gesamten Datenumf angs Konsistenz sicherstellt und diesen als Ansprechpartner vertritt.

Datenqualitätsmangement

Methoden und Technologien zur Sicherstellung der f achlichen und technischen Qualität der Daten.

Master-Daten-Management

Methoden und Technologien zur Verwaltung von Stammdaten im Konzern.

Meta-Daten-Management

Methoden und Technologien zur Beschreibung der Zusammenhänge, Herkunf t, Inhalte und Flüsse der Daten.

277

BIInformationslogistik Steuerung des qualitätsgesicherten und transparenten Umgangs mit dispositiver Inf ormation.

Abb. 6. BI-relevante Elemente des Datenmanagements

3.6 Betrieb von BI-Systemen Die Ist-Situation des Betriebes von BI-Systemen im Volkswagen-Konzern wurde exemplarisch in einer Vorstudie erhoben. Im Ergebnis ist für den Aufbau einer kostenoptimalen BI-Plattform eine Standardisierung des Betriebes von BI-Applikationen zwingend erforderlich. Im Rahmen der Application Management Services (AMS) ist der BI-AMS-Cluster die Organisationseinheit, die einen standardisierten Betrieb von BI-Systemen gewährleistet. Die Stärken des BI-AMS-Clusters sind nachstehend zusammengefasst. x Kompetenzbündelung durch Zentralisierung des BI Know-hows - Datenbewirtschaftungs-, Datenqualitätsprozess - Übergreifendes Tool Know-how - Ausrichtung BI-Betrieb an BI-Strategie x Zentrale Koordinierung von Betriebsvorgaben (einmaliger Erstellvorgang – für alle BI-Systeme nutzbar) - Tools (Middleware, Datenbank, ETL, Front End) - Prozesse - Standards x Planbarkeit und Schutz bestehender und zukünftiger BI-Investitionen

278 -


Ausnutzung von Synergien Klare Aufgaben und Verantwortlichkeiten für die Mitarbeiter

Der BI-AMS-Cluster empfängt über ein standardisiertes Übergabeverfahren kontinuierlich fertig entwickelte BI-Systeme, die entsprechend der Vorgaben der BI-Strategie entstanden sind. Auf Seite der Infrastrukturverantwortlichen (IT-Services) wird eine BIInfrastruktur-Referenzarchitektur mit folgenden Zielen aufgebaut: x Bereitstellung einer standardisierten, zukunftssicheren Infrastruktur für Gravitationszentren und BI-Services x Erhöhen der Leistungsfähigkeit und bessere Integration der gesamten BI-Basistechnologien x Schnelles, zuverlässiges Antwortzeitverhalten für verschiedene Benutzerklassen x Stabiler Betrieb und hohe Verfügbarkeit der Infrastruktur 3.7 Change Management Laut einer Studie schätzen Unternehmen, dass unzulänglich durchgeführte Veränderungsprozesse einen Produktivitätsrückgang von durchschnittlich 21% verursachen (CapGemini 2005). So ist die „Strategie-Performance Lücke“ die ernüchternde Antwort einer Studie auf die Frage: „Wann geht es schief?“ Fazit: Viele Unternehmen haben schöne Strategien und eine schlechte Umsetzung, nur 62% erreichten ihre strategischen Ziele (Mankins u. Steele 2005). Bei der Volkswagen Aktiengesellschaft war man sich dieses Risikos bereits zu Beginn der BI-Strategiearbeit sehr bewusst, Change Management sowie das Aufsetzen eines Kommunikationskonzeptes sind eigenständige strategische Handlungsfelder. Die Umsetzung der BI-Strategie durch das BI-Programm erfordert ein Umdenken aller Beteiligten in wesentlichen fachlichen, organisatorischen und technischen Aspekten. Der dazu notwendige Transformationsprozess wird durch das Change Management über die folgenden Wirkhebel initiiert und begleitet. x Die BI-Strategie motiviert die Notwendigkeit und Dringlichkeit der strategischen Maßnahmen und deren Auswirkungen. x Die integrierte Kommunikation arbeitet mit der in der BI-Strategie formulierten Vision und gezielten Maßnahmen an einer Organisationskultur, die die Umsetzung der BI-Strategie optimal unterstützt.


279

x Maßgeschneiderte interne und externe Kommunikationsmaßnahmen sowie aktives Marketing wirken auf alle Zielgruppen. x Frühzeitige Einbindung von Führung und Mitarbeitern in allen beteiligten Bereichen über breitgefächerte Aktionen sorgt für Identifizierung mit der BI-Strategie und steigert die Motivation. x Das konsistente Prozessnetzwerk des BI-Programms sorgt für die notwendige Nachhaltigkeit der Veränderungen. Eine der ersten Analysen in der Entwicklung der KommunikationsMaßnahmen war eine Betrachtung des Umfeldes des BI-Programms. Hierbei wurden folgende Ebenen differenziert: x Beteiligte: Alle Personen, die direkt im BI-Programm arbeiten. Sie treiben das Thema selbständig voran. x Betroffene: Sind durch die Vorgaben des BI-Programms betroffen oder geben dem BI-Programm Vorgaben, ohne direkt am Thema zu arbeiten x Interessierte: Könnten BI in ihrem Arbeitsumfeld einsetzen und besitzen ein Grundverständnis x Außenstehende: Sehen weder Anlass noch Notwendigkeit, sich mit dem Thema zu beschäftigen Auf Basis dieser Ebenen ist die Einschätzung des BI-Umfeldes Grundlage für das nachstehend beschriebene Konzept der integrierten Kommunikation. Die integrierte Kommunikation hat die Aufgabe, aus der Vielfalt der eingesetzten Instrumente und Maßnahmen der internen und externen Kommunikation und der oben genannten zusätzlichen Aufgabenfelder ein in sich geschlossenes und widerspruchsfreies Kommunikationssystem zu erstellen, um ein für die Zielgruppen der Kommunikation konsistentes Erscheinungsbild über das BI-Programm (z. B. Produkte, Dienstleistungen, aber auch Ideen oder Meinungen) zu vermitteln. Eines der wesentlichen Hemmnisse für eine weitere Verbreitung von Business Intelligence in den Unternehmen ist das Fehlen von AnwenderKnow-how. Ein BI-spezifisches Trainingskonzept bildet einen wesentlichen Hebel, das Verständnis für Business Intelligence zu erhöhen. Ein BIÜberblickskurs ist die Grundlage für alle im BI-Umfeld angebotenen Kurse, der sowohl IT-Mitarbeitern als auch Mitarbeitern in den Fachbereichen angeboten wird. Hier werden wichtige Begrifflichkeiten und Definitionen, aber auch die BI-Referenzarchitektur bei Volkswagen erklärt. Neben den bestehenden toolspezifischen Schulungen sind auch neue Kurse im methodischen Bereich und zu Fachthemen entstanden.

280


3.8 Roadmap Die Komplexität des Vorhabens – prozessübergreifendes Vorgehen in einem Großkonzern mit einer historisch gewachsenen BI-Landschaft – erfordert eine langfristige, planerische Ausgestaltung des BI-Programms bis zum Jahr 2015. Um die langfristige Wirkung sicherzustellen, sind die konsequente Ausrichtung an der BI-Strategie und ein nachhaltiges Change Management unverzichtbar. Das BI-Programm koordiniert die Weiterentwicklung der gesamten BILandschaft über strategische Maßnahmen. In der Wirkung der strategischen Maßnahmen entstehen charakteristische Zwischenzustände, die mit unterschiedlichen Kosten-/Nutzenaspekten einhergehen. Die Zustände sind abstrakte Konstrukte und lassen sich auf dem Zeitstrahl nicht scharf gegeneinander abgrenzen. Mit zunehmendem Reifegrad der Business Intelligence im Volkswagen-Konzern verändert sich auch der Charakter des BIProgramms (vgl. Abb. 7). Hebung des Synergiepotentials in der heterogenen BI-Landschaft.

Funktionierende BI-Plattform mit einer BI-Services-Schicht und einer GravitationszentrenSchicht.

Morgen

Zukunft

Effizienz der BI-Plattform

Veränderung durch BI

Gravitationszentren

BI-Services

Gestern Heute

Zusätzliche Verankerung/ Steuerung von BI aus dem Fachbereich heraus, mit BI als Innovationsmotor für Veränderungsprozesse im Unternehmen.

Heterogenität der BI-Landschaft

Abb. 7. Transformation des BI-Programms

Gestern dominierten Maßnahmen, die mit Schaffen von Transparenz, der Herbeiführung einer Entscheidungsgrundlage und der Formulierung einer BI-Strategie verbunden waren. In der ITP&O-Organisation hat über das ITP-KF BI ein BI-CC für Architekturen und Technologien erfolgreich Fuß gefasst. Ausgehend von einem geschaffenen Problembewusstsein wurden im BI-CC erste strategische Maßnahmen unterstützt. Beispielsweise wurden Bausteine im Bereich des Datenmanagements entwickelt, eine BI-Referenzarchitektur entworfen und ein Konsolidierungsprogramm konzipiert. Parallel sind handlungsfähige BI-Governance-Strukturen ent-


281

standen. Im Bereich AMS pilotiert ein BI-AMS-Cluster, IT-Services unterstützt BI durch eine speziell auf BI-Belange ausgerichtete InfrastrukturArchitektur. Heute ist das Ziel, den Transformationsprozess der BI-Landschaft in die BI-Plattform zu forcieren, um allgemein die Nutzung von BI zu erweitern oder speziell z. B. unternehmensweite Kennzahlensysteme zu ermöglichen. Morgen wird sich das BI-Programm im Rahmen der Unterstützung der Konzernstrategie bzw. zur Steuerung der Geschäftsprozesse weiterhin dafür engagieren, dass alle Nutzenpotentiale der BI-Plattform gehoben werden. In der weiteren Zukunft wird ein wesentliches Ergebnis des BI-Programms sein, dass die über innovative Anwendungsszenarien gewonnenen Erkenntnisse in der Organisation benutzen werden, um die Prozesse im Volkswagen-Konzern zu optimieren. 2006-2007

2008-2011

Fachliche BI-Strategie

2012-2015

BI – der Weg zum Wissensvorsprung des Volkswagen Konzerns

2005

Abb. 8. BI-Roadmap

Die Einträge in der Roadmap geben eine grobe Vorstellung über die Zusammenhänge der verschiedenen Aktivitäten auf hoher Abstraktionsstufe. Die einzelnen Maßnahmen sind mit Detail-Planungen hinterlegt.

4

Erfolgsfaktoren

Im Sinne eines grundlegenden Fazits bleibt zu sagen, dass man für die Entwicklung einer BI-Strategie als Organisation und als Mitwirkender be-

282


reit sein muss, kontinuierlich zu lernen – ständige Verbesserung auf allen Ebenen als Prinzip. Die Prozesse der BI-Strategie-Entwicklung sind mit Geduld realitätsnah auszugestalten und konsequent umzusetzen. Basierend auf den gemachten Erfahrungen hat sich gezeigt, dass der Weg der Veränderung begleitet wird von Einwänden der Bedenkenträger, die den Status Quo verteidigen, den eine neue Strategie in Frage stellt. Die Entwicklung einer BI-Strategie ist keine intellektuelle, eher eine mentale Herausforderung. Bilden Sie das richtige Team, kommunizieren Sie frühzeitig und angemessen – der Rest ist Change Management. Aus der Erfahrung bei der Entwicklung der BI-Strategie haben sich folgende Punkte als Erfolgsfaktoren erwiesen: x Basis sind realistische und dennoch ambitionierte Zielvorstellungen. Sie ermöglichen sinnvolle, operative Zwischenschritte und weisen langfristig die Richtung. x Selbstverpflichtung des Managements zur aktiven Beteiligung x Das richtige Team – Expertise ist aus vielen Bereichen und auf vielen Ebenen notwendig. x Notwendige Transparenz der Ist-Situation als Grundlage für die sinnvolle Ausgestaltung der strategischen Maßnahmen x Berücksichtigung übergeordneter/benachbarter Strategien Für die Umsetzung der Strategie sind folgende Faktoren entscheidend: x Treiber sind die Fachbereichsanforderungen, nicht die IT-Anforderungen. x Konzentration des verfügbaren BI Know-hows zur Bewältigung der im unternehmensweiten Kontext anstehenden Aufgaben x Starke Governance: Portfolio-Management als Gegengewicht zur projektgetriebenen Heterogenität x Ausreichende Budgetierung gerade in den frühen Phasen x Effizientes und kontinuierliches Controlling der Implementierung der BI-Strategie Change Management und ein ausgereiftes Kommunikationskonzept sind in allen Phasen unverzichtbar.


283

Literatur CapGemini: Veränderungen erfolgreich gestalten - Change Management 2005, CapGemini, 2005. Kaplan, R.; Norton, D.: Strategy Maps: Converting Intangible Assets into Tangible Outcomes, Harvard Business School Press, 2004. Mankins, M.; Steele, R.: Turning great strategy into great performance, in: Harvard Business Review (2005) July-August. Müller-Stewens, G.; Lechner, C.: Strategisches Management - Wie strategische Initiativen zum Wandel führen, 3. Aufl., Schäffer Poeschel, Stuttgart 2005. 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. Trost, U.; Zirkel, M.: Wege aus dem Informationschaos, in: BI-Spektrum 1 (2006) 3, S. 11-16. Volkswagen AG: BI-Strategie des Volkswagen-Konzerns, Volkswagen AG, Wolfsburg 2005.

13 Etablierung eines Excellence Teams Information Logistics bei E.ON

Gerrit Lahrmann Universität St.Gallen

Dirk Meyer E.ON AG

1 2 3 4 5

Unternehmensprofil der E.ON AG ................................................. 285 Ausgangssituation........................................................................... 289 Etablierung eines Excellence Teams Information Logistics........... 291 Das Excellence Team Information Logistics .................................. 293 Erkenntnisse und Ausblick ............................................................. 297 Literatur .......................................................................................... 298

1

Unternehmensprofil der E.ON AG

1.1 Überblick Die E.ON AG, eine Holding mit Hauptsitz in Düsseldorf, ist einer der weltweit größten privaten Energiedienstleister. Für derzeit rund 40 Millionen Kunden (Privat- und Geschäftskunden, Industriebetriebe sowie regionale und lokale Energieunternehmen) in über 20 Ländern stellt E.ON Lösungen für Strom und Gas zur Verfügung. Dabei konzentriert sich das Unternehmen auf die Zielmärkte Zentraleuropa, Großbritannien, Nordeuropa und den Mittleren Westen der USA.

286

Gerrit Lahrmann, Dirk Meyer Corporate Center E.ON AG Düsseldorf (DE)

Market Units Central Europe E.ON Energie AG München (DE)

Pan-European Gas E.ON Ruhrgas AG Essen (DE)

US-Midwest E.ON U.S. Louisville (US)

Energy Trading E.ON ET Düsseldorf (DE)

Nordic E.ON Nordic AB Malmö (SE)

UK E.ON UK Coventry (GB)

Zukünf tige Market Units (Russland, Italien, …)

Abb. 1. Konzernstruktur der E.ON AG

Die Konzernstruktur (siehe Abb. 1) spiegelt zum einen die Struktur dieser Zielmärkte wieder, zum anderen werden marktübergreifende Tätigkeiten gebündelt. Das Corporate Center (CC) ist für die Führung von E.ON als integriertes Energieunternehmen, die marktübergreifende Steuerung des Gesamtgeschäfts und die laufende Optimierung des Portfolios zuständig. E.ON Energy Trading bündelt ab Anfang 2008 alle europäischen Handelsaktivitäten mit Strom, Gas, Kohle, Öl und CO2-Zertifikaten unter einem Dach. Das Management der Zielmarkt-spezifischen Aktivitäten erfolgt durch die Führungsgesellschaften der Market Units Central Europe, Pan-European Gas, UK, Nordic und US-Midwest. Unterhalb der Market Units bestehen verschiedene Business Units, die das operative Geschäft führen. Unter der Market Unit Central Europe existieren beispielsweise die Business Units E.ON Wasserkraft, E.ON Kraftwerke, E.ON Kernkraft sowie regionale Units. Andere Market Units sind im Wesentlichen ähnlich aufgestellt. In naher Zukunft sind u. a. aufgrund der Expansionsbemühungen des E.ON Konzerns die Gründungen weiterer Market Units geplant. Konkrete Pläne bestehen z. B. für die Market Units E.ON Italy, E.ON Russia und E.ON Spain. Mit E.ON Renewables soll eine eigene E.ON-Einheit für erneuerbare Energien und Klimaschutz etabliert werden.

Etablierung eines Excellence Teams Information Logistics bei E.ON

287

Tabelle 1. Kurzporträt der E.ON AG

E.ON AG 2000: Gründung der E.ON AG durch Fusion der Energiekonzerne VEBA und VIAG 2003: Übernahme der Mehrheit der Ruhrgas AG (Essen), ab Juni 2004 E.ON Ruhrgas AG Seit 2004: Fokussierung des Konzerns auf das Strom- und Gasgeschäft durch gezielte Desinvestitionen in nicht strategierelevanten Geschäftsfeldern Historie und Erwerb zahlreicher Beteiligungen an privatisierten Energieversorgungsunternehmen vornehmlich in Osteuropa Oktober 2007: Übernahme der russischen Kraftwerksgesellschaft OGK-4 2008: Bündelung aller europäischen Handelsaktivitäten in der E.ON Energy Trading Firmensitz Düsseldorf (DE) Branche Energieversorgung Geschäftsfelder Strom und Gas Corporate Center E.ON AG Düsseldorf Gegliedert in die Market Units Central Europe, PanFirmenstruktur European Gas, UK, Nordic, US-Midwest und Energy Trading. Homepage http://www.eon.com Umsatz Ergebnis

Marktanteile

Mitarbeiter Kunden

2006: 67'759 Mio. € (+21%) 2006: 4'386 Mio. € (+20%) (bereinigter Konzernüberschuss) Central Europe: Nr. 2 in der Stromerzeugung und im Strom-/Gasvertrieb Pan-European Gas: Nr. 3 in der Gasversorgung UK: Nr. 2 in der Stromerzeugung sowie im Stromund Gasvertrieb Nordic: Nr. 4 in der Stromerzeugung, Nr. 3 im Strom-/Gasvertrieb US-Midwest: Nr. 1 in der Stromerzeugung und im Strom-/Gasvertrieb in Kentucky 80'612 (+1%) ca. 40 Mio.

288

Gerrit Lahrmann, Dirk Meyer

1.2 Herausforderungen im Wettbewerb Die noch junge Historie des E.ON-Konzerns lässt sich in drei Phasen aufteilen. In der ersten Phase von 2000 bis 2003 stand die Transformation des Konzerns in ein fokussiertes Energieunternehmen im Mittelpunkt. Ausgelöst durch neue Herausforderungen im Kerngeschäft und der Liberalisierung im deutschen Strommarkt entstand die E.ON1 AG aus dem Zusammenschluss der Unternehmen VEBA und VIAG. Mit dem Fokus auf das Energiegeschäft wurden Desinvestments von nicht energiebezogenen Geschäften vollzogen und ein Wachstum im Strom- und Gasgeschäft erzielt. Die zweite Phase, von 2003 bis 2005, wurde dominiert durch die Integration der getätigten Akquisitionen und eine gezielte PerformanceSteigerung durch kleine und mittelgroße Investitionen zur Marktkonsolidierung. Mit Erreichen der dritten Phase werden seit 2005 das Wachstum im Energiegeschäft sowie die Akquisitionsbemühungen fortgesetzt. Es werden unter weiterhin strengen finanziellen Investitionskriterien größere Wachstumsschritte verfolgt und ein verstärktes organisches Wachstum durch Investitionen in Erzeugung und Netze angestrebt. Als strategisches Unternehmensziel wird von E.ON die Vision des weltweit führenden Strom- und Gasunternehmen verfolgt. Die Kernpunkte der E.ON-Strategie sind ein integriertes Strom- und Gasgeschäft, ein klarer geographischer Fokus und klare strategische Prioritäten. Durch die vertikale Integration von der Stromerzeugung in Kraftwerken und der Gasproduktion über den Großhandel bis hin zum Vertrieb beim Endkunden, d. h. durch die Präsenz entlang der gesamten Wertschöpfungskette, soll einerseits das Geschäft optimiert und andererseits das Risiko gestreut werden. Durch die horizontale Integration, d. h. insbesondere durch die Stromerzeugung aus Gas sowie durch den gemeinsamen Vertrieb beider Energieträger, sollen Synergie- und Wachstumspotentiale realisiert werden. Die führende Marktposition in den existierenden Market Units soll gestärkt werden, gleichzeitig wird ein gezieltes Wachstum in neuen Märkten wie z. B. Spanien oder Russland angestrebt. Oberste strategische Priorität haben Stärkung und Ausbau der Position E.ONs in Europa, weiterhin soll das Erzeugungsportfolio erhalten und die Gasversorgungsposition durch eigene Gasproduktion und ggf. LNG2 gestärkt werden. Der US-Markt wird als langfristige Wachstumsoption angesehen. Investitionen in Erzeugung und Netze sollen anhand strenger strategischer und finanzieller Kriterien erfolgen, Akquisitionen sollen nur bei hohem Wertschöpfungspotential erfolgen. 1 2

Eon ist die englische Schreibweise des griechischen „Aeon“, übersetzt Ewigkeit. LNG für englisch liquefied natural gas, übersetzt Flüssigerdgas.


289

Wettbewerber von E.ON auf dem deutschen Energiemarkt sind insbesondere RWE, Vattenfall und EnBW. Der Wettbewerb zeichnet sich durch eine starke Verdrängungssituation aus, in der die Wettbewerber um Erhöhung der eigenen Marktanteile bemüht sind. Gesetzliche Vorgaben, z. B. in Form des Energiewirtschaftsgesetzes, wirken sich ebenfalls auf den Energiemarkt aus. Anfang 2007 hat E.ON Energie ihr Netzgeschäft vollständig ausgegliedert, um gesetzliche Vorgaben zur Trennung zwischen Netz- und Energiegeschäft zu erfüllen. Die organisatorischen Implikationen der Wachstumsstrategie für die Informationslogistik werden im Folgenden näher erläutert.

2

Ausgangssituation

Aufgrund der starken Akquisitionsbemühungen vereinigt der Konzern Mitarbeiter unterschiedlichster Unternehmen unter der Marke E.ON. Unter der Bezeichnung OneE.ON wird seit Januar 2005 ein Leitbild etabliert, das den Mitarbeitern die Mission, für den Kunden wettbewerbsfähige und verlässliche Leistungen zu erbringen, sowie gemeinsame Werte und Verhaltensrichtlinien näher bringen soll, um sich so der Vision vom weltweit führenden Strom- und Gasunternehmen zu nähern. Analog zum Leitbild OneE.ON wird seit 2005 unter der Bezeichnung OneIT eine gemeinsame IT-Landschaft geschaffen. Als Folge der früheren Struktur als Mischkonzern ist eine Vielzahl verschiedener Systeme mit gleichen Aufgaben im Einsatz, laut CIO Torsten Ecke sind „diese Parallelstrukturen […] heute in einem klar aufgestellten Strom- und Gaskonzern nicht mehr zeitgemäß“ (E.ON AG 2005). Ziel des Projekts OneIT ist die Erleichterung der konzernweiten Zusammenarbeit und die Senkung von Kosten, indem bis 2008 die IT-Landschaften der vier europäischen Market Units zusammengeführt werden, die IT-Infrastruktur damit europaweit standardisiert und harmonisiert wird. Für die zusammenzuführende IT ist seit 2005 der gemeinsame interne IT-Dienstleister E.ON IS zuständig. E.ON IS als zentraler Dienstleister von E.ON in Europa implementiert ITLösungen und verantwortet deren Betrieb und Service (Shared Services). In den Business Units, den Market Units und im Corporate Center existieren CIO-Bereiche, die die Projekte begleiten und für die Strategie verantwortlich sind. Es findet also eine Trennung zwischen Aufgaben auf technischer Ebene (IT-Dienstleister) und Aufgaben auf konzeptioneller Ebene (CIO-Bereiche) statt. In einer Pressemitteilung vom 03. Mai 2007 (E.ON AG 2007) teilte der E.ON-Konzern mit, dass das Unternehmen durch die europaweite Präsenz

290


in der Lage sei, „besser als jedes andere Energieunternehmen […] über Ländergrenzen hinweg […] Investitionen [zu] optimieren und effiziente Strukturen zu formen“. Zur Umsetzung dieser Potenziale wurde ein drei Schwerpunkte umfassendes Maßnahmenpaket, genannt europe.on, erarbeitet. Den ersten Schwerpunkt bildet die Optimierung der Geschäftssteuerung. In der bestehenden, auf Einzelmärkte oder Regionen ausgerichteten Aufstellung sind die sich neu bietenden Ertrags- und Wachstumschancen nur eingeschränkt nutzbar. Ein Denken und Planen in gesamteuropäischen Dimensionen soll gefördert werden. Zweiter Schwerpunkt ist ein Investitionsprogramm, das sowohl organisches Wachstum als auch gezielte Akquisitionen im Kernmarkt Europa und in angrenzenden Wachstumsregionen beinhaltet. Mit dem Investitions- und Wachstumsprogramm werden anspruchsvolle operative Ziele für die nächsten Jahre verbunden. Für Wachstum, Klimaschutz, Portfolio-Steuerung und Kundenzufriedenheit wurden laut E.ON-Chef Wulf H. Bernotat „klare und messbare Zielgrößen“ (E.ON AG 2007) formuliert. Diese Ziele bilden den dritten Schwerpunkt des Maßnahmenpaketes europe.on. Zusammenfassend finden also Integrationsbemühungen auf unterschiedlichsten Ebenen statt: x Auf der Strategieebene wurde die Optimierung der Geschäftssteuerung beschlossen, ein Investitionsprogramm verabschiedet sowie klare und messbare Zielgrößen zur aktiven Steuerung des Konzerns definiert (europe.on). x Auf der Organisationsebene wurde die Unternehmensstruktur hin zu einem fokussierten Energiekonzern transformiert, neue Märkte werden erschlossen und integriert, Prozesse sollen zentral gesteuert werden (europe.on). Des Weiteren wird ein einheitliches Leitbild vermittelt (OneE.ON). x Auf der Software- und auf der Systemebene wird die IT-Landschaft vereinheitlicht (OneIT). Die Informationsversorgung war bei E.ON bisher anhand einer reinen Linienorganisation strukturiert, zwischen Geschäfts- und IT-Einheit existierte ein 1:1 Mapping. So besaßen z. B. die einzelnen Vertriebsorganisationen für Strom, Gas, etc. jeweils eigene SAP-Systeme. Diese Systeme wurden unabhängig voneinander anhand der in den jeweiligen Market bzw. Business Units erarbeiteten IT-Strategien und Standards betreut. Ein Hierarchieebenen-übergreifender Datenaustausch zum Zweck der Entscheidungsunterstützung zwischen den Einheiten konnte aufgrund der unterschiedlichen Systemstrukturen nicht stattfinden. Von den Business Units wurden an die Market Units und von den Market Units an das Cor-


291

porate Center keine Daten automatisiert übermittelt, ein vollständiger Überblick über die Datenflüsse fehlte. Insbesondere anhand der sich verändernden fachlichen und organisatorischen Rahmenbedingungen, sowie der damit einhergehenden Anforderungen zur Informationsversorgung wurde deutlich, dass eine strukturierte, ganzheitliche Gestaltung der Informationslogistik erforderlich ist.

3

Etablierung eines Excellence Teams Information Logistics

3.1 Ziele Um den sich verändernden fachlichen und organisatorischen Rahmenbedingungen sowie den damit einhergehenden Anforderungen zur Informationsversorgung gerecht zu werden, wurde durch den CC-CIO-Bereich entschieden, ein „Excellence Team Information Logistics“ (ETIL) zu etablieren. Unter der Maxime „Information Excellence“, der fortwährenden Bereitstellung aktueller Informationen für alle Beteiligten entlang der gesamten Wertschöpfungskette, ist das ETIL mit der Sicherstellung der Informationsversorgung, der besseren Aufstellung des Konzerns bei weiteren Akquisitionen und der Kosteneinsparung, z. B. durch Best Practices, beauftragt. Durch die Aktivitäten des ETIL soll die Informationsversorgung verbessert und die Basis für weiteres Wachstum durch höhere Integrationsfähigkeit und Flexibilität geschaffen werden. Die Harmonisierung und Standardisierung der Informationslogistik soll ermöglicht werden, um die Transparenz und Effizienz derselben zu verbessern. Zwischen allen Market Units und E.ON IS soll die Kooperation gefördert werden. Koordiniert werden diese Bemühungen durch den CC-Bereich. Insgesamt wird ein „Group Optimum“ angestrebt. Das Ergebnis sämtlicher Aktivitäten bildet das „Framework Information Logistics“, kurz FIL.ON genannt. Ziele des Frameworks sind: x Eine verstärkte Ausrichtung der IL anhand der Erfordernisse des Business x Bereitstellung von Grundlagen für eine flexible IL-Architektur x Harmonisierung und Standardisierung der IL zur Erhöhung der Transparenz und Effizienz

292


3.2 Durchführung Die Application Manager der Market Units und des Corporate Center, die zusammen die „Steering Group Applications“ (SGA) bilden, sind verantwortlich für die Aktivitäten des ETIL. Die SGA berichtet an die CIOs (IT Steering Commitee, ITSC) des Gesamtkonzerns. Damit ist auf hoher Ebene eine Unterstützung für das ETIL vorhanden und zu erwartende Widerstände in einzelnen Market Units (Pan-European-Gas müsste beispielsweise gegebenenfalls Freiheiten aufgeben) können auf ein Minimum reduziert werden. Generell werden im E.ON-Konzern für alle Querschnittsthemen von gruppenweitem Interesse Excellence Teams geschaffen, die Experten aus unterschiedlichsten Unternehmensbereichen organisatorisch vereinen und Richtlinien, Vorgaben und Standards für den gesamten Konzern erarbeiten3. Weitere derzeit existierende Excellence Teams beschäftigen sich z. B. mit den Themen SAP XI (Bestandteil des SAP NetWeaver, MiddlewareKomponente zur Verbindung von SAP- und Nicht-SAP-Systemen) und Portalen. Steering Group Application (SGA)

Excellence Team Information Logistics E.ON CC (Chair) E.ON CC (Co-Chair)

Market Unit E.ON Central Europe Market Unit Pan-European Gas

Core Team E.ON IS

Market Unit E.ON Nordic Market Unit E.ON US-Midwest

Topic-specific specialists E.ON IS

Market Unit E.ON UK

Abb. 2. Organisatorischer Aufbau des Excellence Teams Information Logistics

3

Die Durchsetzung und Verbindlichkeit dieser Richtlinien ist derzeit nicht Aufgabe des ETIL, für die Zukunft ist dies jedoch geplant.


293

Abbildung 2 stellt den organisatorischen Aufbau des ETIL dar. Den Vorsitz des ETIL hat ein Mitarbeiter aus dem Corporate Center inne. Aus allen Market Units ist zumindest ein Mitarbeiter als dauerhaftes Mitglied vertreten (bei E.ON Central Europe z. B. drei Mitarbeiter), ebenso ist E.ON IS vertreten. Ein Core-Team von E.ON IS ist mit der Umsetzung der Ergebnisse des ETIL beauftragt. Das Core-Team stellt die operative Umsetzbarkeit der Ergebnisse sicher, begleitet größere Aufgabenstellungen bis zum Abschluss und stellt technische Experten für spezielle Projektaktivitäten zur Verfügung. Externe Vertreter, z. B. von Softwareherstellern, sind nicht beteiligt, um im Hinblick auf das strategische Ziel Information Excellence die gefundenen Ansätze nicht durch Software, sondern rein durch die Erfordernisse des Business bestimmen zu lassen. Das ETIL besitzt ein eigenes Budget, welches vom CC CIO zur Verfügung gestellt wird und mit dem z. B. Studien zur Analyse von bestehenden Praktiken im Konzern oder der Einkauf von Beratungsleistungen finanziert werden können. 3.3 Kritische Erfolgsfaktoren Als essentiell zur erfolgreichen Etablierung der im FIL.ON manifestierten Grundsätze wird die organisatorische Unterstützung durch das Corporate Center und eine frühzeitige Partizipation aller beteiligten Geschäftseinheiten angesehen. Die einzelnen Mitarbeiter des ETIL werden durch ihre jeweiligen Market Units getragen, das CC stellt weiteres Budget (s. o.). Der Erfolg eines derartig weitreichenden Vorhabens steht und fällt mit der Akzeptanz der Beteiligten, die durch frühzeitige, regelmäßige Kommunikation sichergestellt werden soll. Im ETIL sollen gruppenweit gültige Konzepte, Standards und Architekturrichtlinien für die IT und das Business entwickelt werden. Demzufolge ist also eine aktive Teilnahme von IT und Business an den Prozessen notwendig, um zu Entscheidungen zu gelangen, die von allen Seiten getragen werden. Durch diesen konsensorientierten Entscheidungsfindungsprozess und die Möglichkeit zur aktiven Mitgestaltung soll sich niemand bei Abstimmungen übergangen fühlen.

4

Das Excellence Team Information Logistics

4.1 Strategische Ausrichtung Das ETIL verfolgt einen gruppenweiten Ansatz, um die (Weiter-) Entwicklung und die Wartung der Informationslogistik bei E.ON unter Beachtung und Anerkennung spezifischer Anforderungen einzelner Organi-

294


sationseinheiten zu steuern. Die Kooperation zwischen allen Market Units und E.ON IS wird gefördert und durch das Corporate Center koordiniert. Das Excellence Team berichtet an die SGA, die aus Vertretern der Market Units und des CC besteht. Im Kapitel zur Organisation der Informationslogistik (siehe Kapitel 5) wurden die vier Leistungserbringertypen DWH Business Service Provider, DWH Full Service Provider, DWH Competence Center (CC) sowie DWH Platform Provider identifiziert. Das ETIL lässt sich am ehesten dem Leistungserbringertyp DWH-CC zuordnen, auch wenn sich das Leistungsspektrum nur auf Teile der Führungsprozesse, insbesondere die IL-Governance, in Zusammenarbeit mit anderen IT- und Fachabteilungen erstreckt und z. B. Implementierung und Betrieb durch einen IT-Dienstleister übernommen werden. Im Allgemeinen wird unter IT-Governance die Vereinigung von Grundsätzen, Verfahren und Maßnahmen verstanden, die sicherstellen, dass mit Hilfe der eingesetzten IT die Geschäftsziele abgedeckt, Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden (Meyer et al. 2003, S. 445). Analog können der IL-Governance unter anderem der Entwurf von Richtlinien, Regeln und Empfehlungen und die Definition von Rollen und Verantwortlichkeiten für IT- und Fachbereichs-Stakeholder zugeordnet werden. Die Aufnahme von Anforderungen fällt nicht in den Aufgabenbereich des ETIL und wird zentral im E.ON-Konzern geregelt. 4.2 Prozesse der Informationslogistik Die Prozesse der Informationslogistik lassen sich grob in Datenlieferung, Informationsproduktion und Informationskonsum kategorisieren (vgl. Klesse 2007, S. 142). Die Datenlieferung befasst sich mit der Bereitstellung von Rohdaten, die anschließend in der Informationsproduktion veredelt werden. Die organisatorische Führung und Planung ist gewöhnlich Teil des Leistungsspektrums eines Competence Centers, die sich wiederum in Strategie und Architekturmanagement, Controlling, Beziehungsmanagement, Qualitätsmanagement und Programmmanagement untergliedert (vgl. Klesse 2007, S. 149). Der Informationskonsum beinhaltet die analytische Nutzung der Daten. Abbildung 3 zeigt die Prozesslandschaft der Informationslogistik für den Leistungserbringertyp DWH-CC.

Etablierung eines Excellence Teams Information Logistics bei E.ON Datenlieferanten

295

Kunden

Leistungserbringer Competence Center Excellence Team Information Logistics: Führungsprozesse

Informationsproduzierende Prozesse

Informationsproduktion Informationskonsumierende Prozesse Fachliche Entwicklung

Fachlicher Betrieb

Leistungserbringer Implementierung

Fachlicher Support

Leistungserbringer Plattform

Abb. 3. Produktionszentrierte Prozesslandkarte für ein Competence Center (in Anlehnung an Klesse 2007, S. 142)

Zu den Aufgaben des ETIL zählt die Entwicklung von Konzepten, Standards und Architekturrichtlinien, insbesondere die Entwicklung von gruppenweiten Verfahren und Richtlinien. Die Analyse existierender und Evaluation neuer Anwendungen und Projektauswirkungen wird ebenfalls als eine der Kernaufgaben angesehen. Das ETIL nimmt Standardisierungsaufgaben für die IT wahr und unterstützt das Business bei Standardisierungsaufgaben durch Methoden und Verfahren. Im Bereich der IT werden Grundsätze der IL-Landschaft, Architekturrichtlinien, Verrechnungsmodelle für analytische Applikationen und Konzepte für die Evolution der IL-Architektur festgelegt. Diese Grundsätze werden auch als IT-Basics bezeichnet. Anhand von Best-Practice-Beispielen ähnlich strukturierter Unternehmen wurden beispielsweise Alternativen für zukünftige Zielarchitekturen identifiziert und aufgrund der unternehmensspezifischen Anforderungen bewertet. Aufbauend auf diesen Erkenntnissen werden Architekturrichtlinien entwickelt, durch deren gruppenweite Einhaltung die Transparenz, Wartbarkeit und Wiederverwendung von Daten und Systemkomponenten erhöht werden sollen. Für die Fachabteilungen werden die „Business-Basics“ als Teil eines umfassenden IL-Frameworks aufgebaut. Sie beinhalten u. a. eine Methode zur Informationsbedarfsanalyse und ein globales KPI-Verzeichnis zur einheitlichen Definition von Geschäftsmetriken. Im Bereich der Datenqualität werden zunächst eine eindeutige Definition von Datenqualität etabliert und Datenqualitätslevel festgelegt, die die Relevanz der Daten in sämtlichen Nutzungsprozessen beinhalten. Durch das ETIL werden verschiedene Arten von Verantwortlichkeiten, z. B. Data Stewards, Prozess- und Applikationsverantwortliche, festgelegt. Weiterhin übernimmt das ETIL die Defi-

296


nition einer Data Lifecycle Management Strategie, in der z. B. unterschiedliche rechtliche Anforderungen der Market und Business Units berücksichtigt werden, und die Definition einer Archivierungsstrategie, die die technischen Erfordernisse von Quellsystemen und die Fachanforderungen abgleicht. Abgerundet wird der Aufbau einer fachlichen IL-Methodik durch ein konzernweit einheitliches Terminologie-Management für Fachbegriffe aus dem Bereich der analytischen Applikationen, so dass insbesondere ein einheitliches Verständnis dieser Begriffe zwischen Fach- und IT-Abteilungen geschaffen werden kann. 4.3 Erste realisierte Nutzenpotenziale Erste Erfolge lassen sich im Bereich des Best Practice Sharing ausmachen. In den regelmäßig stattfindenden Workshops des ETIL wird der Austausch zwischen den Vertretern der Market Units gefördert, erste Synergieeffekte sind erkennbar, wie z. B. die Nutzung von in anderen Market Units erfolgreich angewandten Methoden für die Systemeinführung eines BI-Systems bei E.ON Nordic. Durch das FIL.ON werden mehr und mehr ein gemeinsames Begriffsverständnis und auch ein Verständnis für die Notwendigkeit eines ganzheitlichen IL-Ansatzes geschaffen. Dadurch konnte in ersten gemeinsamen Projekten zu einer einfacheren, verbesserten und zielführenderen Kommunikation beigetragen werden. Weiteres Potenzial wurde durch die gemeinsame Nutzung von Anwendungen (Application Sharing) realisiert. Direktes Feedback aus den Market Units steht noch aus, da sich viele Vorhaben in einer dafür zu frühen Phase befinden. Auch aus den Business Units sind noch keine konkreten Rückmeldungen verfügbar, wiederholt wurde jedoch die Zufriedenheit der direkt beteiligten IT-Stakeholder ausgedrückt. Gegenüber der Organisationsform eines Excellence Teams gibt es, auch aufgrund der gruppenweiten Nutzung dieses Ansatzes bei unterschiedlichsten Initiativen, keine Vorbehalte. Die Akzeptanz ist hoch und es sind bisher keine Konflikte aufgetreten. Ein weiterer (Neben-) Effekt der Standardisierungsbemühungen des ETIL und weiterer Erfolgsfaktor ist, dass für die Market Units der Investitionsschutz auch durch eine zentrale Informationslogistik sichergestellt wird. 4.4 Geplante Weiterentwicklungen Das Excellence Team Information Logistics erarbeitet aktuell die IT- und Business Basics, wie z. B. ein globales Verzeichnis von KPIs oder auch


297

Architekturvorgaben. Im Rahmen der Governance werden diese Richtlinien im Konzern etabliert. Eine aktive Diskussion soll zur Etablierung und auch zur kontinuierlichen Verbesserung der FIL.ON-Bestandteile beitragen. Hierfür wird der Aufbau einer IL-Community im E.ON-Konzern für sinnvoll erachtet. Im Allgemeinen trifft die derzeit oftmals Grundlagen schaffende Arbeit des ETIL auf keinerlei Vorbehalte. Die Akzeptanz ist hoch, da generell der Bedarf eines einheitlichen Vorgehens anerkannt wird, ein einheitliches Vorgehen gewisse Richtlinien erfordert und diese Vorgaben durch frühzeitige Partizipation der Beteiligten entwickelt und getragen werden. Durch den starken Abstimmungsbedarf erweisen sich die Standardisierungsbemühungen jedoch als sehr zeitintensiv. Eine aktivere Partizipation des Business hätte hier vielleicht Abhilfe schaffen können und wird generell in der näheren Zukunft angestrebt. Im Bereich des Business existieren erste gruppenweite Lösungen, so erfolgt die Personalplanung z. B. durch eine zentrale HR-Abteilung. Auch eine gruppenweite Trading-Plattform existiert. In Zukunft wird eine weitere Spezialisierung auf Themen von gruppenweitem Interesse wie Human Ressources oder Trading durch fokussierte Teams und fachliche Gruppierungen stattfinden. Das ETIL wird dafür die informationslogistischen Grundlagen schaffen.

5

Erkenntnisse und Ausblick

Das Fallbeispiel des Excellence Teams Information Logistics bei der E.ON AG zeigt einen erfolgreichen Ansatz für die Organisation einer ganzheitlichen Informationslogistik. Auch wenn sich die Etablierung einer ganzheitlichen Informationslogistik derzeit noch in einer frühen Phase befindet, deuten erste Erfolge in Pilotprojekten auf ein insgesamt hohes Potenzial hin. Das ETIL erarbeitet mit dem FIL.ON ein Framework für die Informationslogistik, auf Basis dessen in Zukunft die Versorgung der Bedarfsträger mit analytischen Informationen im Sinne des Maßnahmenkataloges europe.on erfolgen wird. Zukünftig wird die konzernweite Durchsetzung der erarbeiteten Standards und Vorgaben besonders hohe Bedeutung erlangen. Bei Neu- und Weiterentwicklungen, Wartung und Betrieb muss die Anwendung der Standards nachverfolgt werden, damit eine ganzheitliche, durchgängige Informationslogistik für den E.ON Konzern ermöglicht wird.

298


Literatur E.ON AG: Niemand ist eine Insel, in: E.ON World - Die Zeitung für Mitarbeiter (2005) 1, S. 4. E.ON AG: E.ON verbessert Ergebnisausblick für 2007, http://www.eon.com/de/ presse/news-show.do?id=7978, Klesse, M.: Leistungsverrechnung im Data Warehousing – Entwicklung einer Methode, Dissertation, Universität St. Gallen, St. Gallen 2007. Meyer, M.; Zarnekow, R.; Kolbe, L. M.: IT-Governance - Begriff, Status quo und Bedeutung, in: Wirtschaftsinformatik 45 (2003) 4, S. 445-448.

14 Prozessorientierte Informationslogistik bei der Hotelplan Swiss Group

Tobias Bucher Universität St. Gallen

Peter Lutz Hotelplan AG Internationale Reiseorganisation

1 2 3 4 5 6

1

Unternehmensprofil der Hotelplan Gruppe .................................... 299 Einführung in die Thematik der Fallstudie ..................................... 302 Last-Minute-Produkt- und -Preisgestaltung ................................... 304 Derzeitige informatorische Unterstützung der Prozessausführung 309 Integration von Prozessausführung und informatorischer Unterstützung als Lösungsansatz.................................................... 311 Zusammenfassung .......................................................................... 314 Literatur .......................................................................................... 316

Unternehmensprofil der Hotelplan Gruppe

Die im Jahr 1935 als 100-prozentige Tochter des Schweizer Migros-Genossenschaftsbundes gegründete Hotelplan AG Internationale Reiseorganisation („Hotelplan Gruppe“, Unternehmensprofil vgl. Tabelle 1 am Ende dieses Abschnitts) ist ein international tätiges Tourismusunternehmen mit Sitz in Glattbrugg (Kanton Zürich, Schweiz). Das Unternehmen engagiert sich sowohl in der Produktion als auch im Vertrieb von eigen- sowie fremderstellten Reisen und Tourismusdienstleistungen über ein unternehmenseigenes Filialnetz sowie über ausgesuchte Reisebüropartner.

300

Tobias Bucher, Peter Lutz

Abbildung 1 zeigt die Organisationsstruktur der Hotelplan Gruppe (Stand 01. Januar 2007, vgl. Hotelplan AG Internationale Reiseorganisation 2007). Das Unternehmen gliedert sich in vier Regionalgesellschaften, die in der Schweiz (Hotelplan Swiss Group, Travelhouse-Gruppe), in Italien (Hotelplan Italien) sowie in Großbritannien (Inghams Travel/Hotelplan UK) tätig sind. Ein bedeutender Teil der innereuropäischen wie auch der interkontinentalen Flugreisen wird über die eigene Ferienfluglinie abgewickelt (Belair Airlines). Darüber hinaus betreibt das Unternehmen vor allem im Mittelmeerraum Hotels und Ferienanlagen (Horizonte Hotels), tritt international als Vermittler von Ferienhäusern und Ferienappartements auf (Interhome Gruppe), unterhält ein Reisebüro-Filialnetz und wickelt Onlinebuchungen von Eigen- und Fremdprodukten über das Internetportal travel.ch (Travelwindow) sowie markenspezifische Websites (bspw. hotelplan.ch, esco.ch, mtravel.ch) ab. Die Querschnittsfunktionen Unternehmenskommunikation sowie Finanzen und Informationstechnologie werden durch entsprechende Stabsstellen wahrgenommen.

Abb. 1. Organigramm der Hotelplan Gruppe (in Anlehnung an Hotelplan AG Internationale Reiseorganisation 2007)

Neben Umwelteinflüssen wie bspw. Naturkatastrophen und der anhaltenden Bedrohungslage durch den internationalen Terrorismus wirken sich gegenwärtig auch vielschichtige Veränderungen der marktlichen Rahmenbedingungen auf das Buchungs- und Reiseverhalten der Kunden der Hotelplan Gruppe ebenso wie der gesamten Tourismusbranche aus. Dazu zählen unter anderem

Prozessorientierte Informationslogistik bei der Hotelplan Swiss Group

301

x die Verbreitung des Internet als Massenmedium sowie dessen Etablierung und allgemeine Akzeptanz als Absatzkanal für Güter und Dienstleistungen verschiedenster Art (Javalgi u. Ramsey 2001), x die dadurch erhöhte Markttransparenz und vereinfachte Vergleichbarkeit von Angeboten, was zu einer Senkung der kundenseitigen Suchund Transaktionskosten (Keaveney u. Parthasarathy 2001; Gupta et al. 2004) bei gleichzeitiger Erhöhung der anbieterseitigen Signalisierungskosten (Verringerung der Unsicherheit durch genauere Beschreibung der Angebote) (Liang u. Huang 1998) führt, sowie x der Siegeszug sog. Low Cost Carrier (Graham 1997; Pitt u. Brown 2001), die spürbare Preissensibilität der Kunden und die damit einhergehende Steigerung der Preiselastizität der Nachfrage. Die Hotelplan Gruppe begegnet diesen Veränderungen einerseits durch horizontale Diversifikation der angebotenen Produkte und Marken, durch welche gezielt unterschiedliche Preissegmente und Kundengruppen mit ihren jeweiligen Präferenzen hinsichtlich Destination und Art der Reise (z. B. Pauschalreise, Studien- und Erlebnisreise, Expedition usw.) angesprochen werden sollen. Andererseits reagierte das Unternehmen mit einer strategischen Partnerschaft der Ferienfluglinie mit der als Low Cost Carrier bekannten Air Berlin und der Ausrichtung des Geschäftsmodells hin zur Multikanaldistribution von Reisen bzw. Tourismusdienstleistungen. Tabelle 1. Unternehmensprofil der Hotelplan Gruppe (in Anlehnung an Hotelplan AG Internationale Reiseorganisation 2007) Hotelplan AG Internationale Reiseorganisation („Hotelplan Gruppe“) Gründung 29. April 1935 durch Gottlieb Duttweiler Firmensitz Glattbrugg, ZH, Schweiz Branche Tourismus Geschäftsfelder Produktion und Vertrieb von Reisen bzw. Tourismusdienstleistungen Organisationsstruktur Regional- und Auslandsgesellschaften (Hotelplan Swiss Group, Travelhouse-Gruppe, Hotelplan Italien, Inghams Travel/Hotelplan UK), Ferienfluglinie (Belair Airlines), Hotels und Ferienanlagen (Horizonte Hotels), Ferienhausund Appartementvermittlung (Interhome Gruppe), Vollservice-Reisebüro sowie Abwicklung von Onlinebuchungen (Travelwindow) Umsatz 1754,5 Mio. CHF (Konzernumsatz im Geschäftsjahr 2006) Gewinn 31,0 Mio. CHF (Konzerngewinn im Geschäftsjahr 2006) Mitarbeitende 2542 Mitarbeitende (Geschäftsjahr 2006) Kunden 1,691 Mio. Passagiere bzw. Kunden (Geschäftsjahr 2006) Kontakt http://www.hotelplan.ch

302

2


Einführung in die Thematik der Fallstudie

Verfall

In der vorliegenden Fallstudie wird beschrieben, auf welche Art und Weise und auf welcher informatorischen Grundlage die schweizerische Regionalgesellschaft der Hotelplan Gruppe, die Hotelplan Swiss Group, sog. LastMinute-Reiseangebote erstellt und diese periodisch den Kundenbedürfnissen und Marktgegebenheiten entsprechend anpasst, um sie erfolgreich vermarkten zu können. Dem Last-Minute-Geschäft mit Reisen (d. h. mit Einzelprodukten und Produktbündeln aus Flug und/oder Landteil, zu dem bspw. die Unterbringung in einem Hotel, Ferienhaus oder Ferienappartement, die Bereitstellung eines Mietwagens vor Ort sowie weitere Zusatzleistungen wie z. B. Transfers, Ausflüge oder zusätzliche Mahlzeiten zählen) kommt im Geschäftsmodell der Hotelplan Swiss Group entscheidende Bedeutung zu. Durch besondere Angebote in Form von Preisnachlässen und/oder attraktiven, mit Zusatzleistungen angereicherten Produktbündeln sollen die Kunden veranlasst werden, kurzfristig Reisen bzw. Tourismusdienstleistungen nachzufragen. Für gewöhnlich wird der Begriff „Last-Minute“ zur Kennzeichnung von Reiseangeboten verwendet, deren Abreisetag (der dem Verfallstermin des Reiseangebots entspricht) innerhalb einer Zeitspanne von maximal vier Wochen liegt. Abbildung 2 stellt in vereinfachter Art und Weise den Lebenszyklus von Reiseangeboten dar. Grundsätzlich können zwei aufeinanderfolgende Phasen unterschieden werden, nämlich die reguläre Angebotsphase und die Last-Minute-Angebotsphase.

Abb. 2. Lebenszyklus von Reiseangeboten

Aufbauend auf der Planung und Bereitstellung von Kapazitäten (z. B. Flug- und Übernachtungskapazitäten) werden während der ersten Phase reguläre Reiseangebote erstellt und vermarktet. Ein iterativer Prozess der Umgestaltung bzw. Anpassung von Reiseangeboten und deren Preisen findet während der regulären Angebotsphase im Normalfall nicht statt. Kataloge, die die Leistungsbeschreibungen und Preise der regulären Reisean-


303

gebote enthalten, sind gedruckt und liegen in den eigenen Reisebüros und denen der angeschlossenen Wiederverkäufer auf. Im Vergleich zur LastMinute-Vermarktung ist die Flexibilität bezüglich kurzfristiger Veränderungen der Angebote deshalb entscheidend eingeschränkt. Die zweite Phase, die Last-Minute-Angebotsphase, schließt sich ungefähr vier Wochen vor Verfall der Reiseangebote an die reguläre Angebotsphase an. Während dieser zweiten Phase werden die regulären Reiseangebote überarbeitet und zu Last-Minute-Reiseangeboten umgestaltet, welche anschließend vermarktet werden. Im Unterschied zur regulären Angebotsphase besteht hier eine erhöhte Flexibilität, da Last-Minute-Reiseangebote nicht in Gestalt von gedruckten Reisekatalogen präsentiert werden, sondern vielmehr primär auf elektronischem Weg an die Reisebüros und die unabhängigen Reisevermittler bzw. via Internet direkt an die potenziellen Kunden kommuniziert werden. Allenfalls eine Auswahl der Last-MinuteReiseangebote wird zusätzlich über Printmedien veröffentlicht. Die Kundenreaktionen auf Last-Minute-Angebote werden innerhalb vergleichsweise kurzer Zeitintervalle überwacht, um sie entsprechend den Markterfordernissen verändern zu können. Wird ein Last-Minute-Reiseangebot vom Markt nicht akzeptiert (d. h. wird das Angebot nicht oder nur in nicht ausreichendem Maße von den Kunden nachgefragt) oder muss es aus anderen Gründen umgestaltet werden, so kann das Last-Minute-Reiseangebot jederzeit überarbeitet und den Markterfordernissen entsprechend angepasst werden. Das Wechselspiel zwischen Angebotsüberarbeitung, Vermarktung der Last-Minute-Reiseangebote und Überwachung der Kundenreaktion kann als iterativer Zyklus verstanden werden. In den folgenden Abschnitten dieser Fallstudie wird nun zunächst der Prozess der Last-Minute-Produkt- und -Preisgestaltung näher beleuchtet (Abschn. 3) und die derzeitige informatorische Unterstützung der Prozessausführung bei der Hotelplan Swiss Group diskutiert (Abschn. 4). Darauf aufbauend wird die Notwendigkeit der Integration von Prozessausführung und informatorischer Unterstützung, d. h. der Ausrichtung der Informationslogistik auf den genannten operativen Prozess, erörtert und ein zweistufiger Lösungsansatz präsentiert (Abschn. 5). Abschließend werden die Ergebnisse der Fallstudie zusammengefasst und die Nutzeneffekte des derzeit verfolgten Lösungsansatzes skizziert (Abschn. 6).

304

3


Last-Minute-Produkt- und -Preisgestaltung

Das in den Abbildungen 3 und 4 dargestellte UML-Aktivitätsdiagramm1 beschreibt den Ablauf des Prozesses „Last-Minute-Produkt- und -Preisgestaltung“ aus Sicht derjenigen Mitarbeitenden der Hotelplan Swiss Group, die für die Aufbereitung der Last-Minute-Reiseangebote zuständig sind. Derzeit werden diese Aufgaben dezentral von einem nach Destinationen gegliederten Sachbearbeitungs-Team wahrgenommen. In diesem Zusammenhang ist zu bemerken, dass der dargestellte Prozessablauf in abstrahierter, idealtypischer Art und Weise die von den Mitarbeitenden ausgeführten Aktivitäten, deren Ablauffolge, wechselseitige Abhängigkeiten, prozessinhärente Entscheidungspunkte und zur Unterstützung der Prozessausführung bzw. der Entscheidungen einzubeziehenden Informationen beschreibt. Aufgrund von aktuellen Veränderungen in der Organisationsstruktur der Hotelplan Swiss Group, die zum Zeitpunkt der Fallstudienerhebung gerade vollzogen waren, existieren im Unternehmen derzeit keine standardisierten, allgemeingültigen Richtlinien oder Vorgaben bezüglich des Vorgehens für die Produkt- und Preisgestaltung von Last-Minute-Reiseangeboten. Die Mitarbeitenden agieren stattdessen individuell nach ihrer Erfahrung und nach bestem Wissen und Gewissen. Unabhängig hiervon vollzieht sich der idealtypische Prozessablauf wie folgt: Zunächst wählt der Mitarbeitende aus den im Reservationssystem angelegten regulären Reiseangeboten ein Angebot aus, dessen Verfallstermin innerhalb eines Zeitraums von maximal vier Wochen liegt. Dieses bestehende Reiseangebot wird nun in Bezug auf die enthaltenen Produktkomponenten sowie hinsichtlich des regulären Preises analysiert, wobei diese Informationen im Reservationssystem hinterlegt sind. Gleichzeitig werden Umfeld, Rahmenbedingungen und vergleichbare Reiseangebote analysiert. Informationen, die in diesem Zusammenhang zu berücksichtigen sind, umfassen bspw. x die Zeitspanne vor dem Abflug (Verfallstermin), x die Destination,

1

Für die Dokumentation von Prozessabläufen findet in der vorliegenden Fallstudie der UML 2.0 Diagrammtyp „Aktivitätsdiagramm“ Verwendung (vgl. hierzu bspw. Oestereich 2005, S. 112-126). Auf die Verwendung von Partitionen zur Kennzeichnung von Verantwortlichkeitsbereichen wird der Übersichtlichkeit wegen verzichtet. Alleinige Träger aller genannten Aktivitäten sind die Mitarbeitenden des o.g. Sachbearbeitungs-Teams. Die Aufteilung des Prozessablaufs auf zwei UML-Aktivitätsdiagramme (Abbildungen 3 und 4) dient ebenfalls ausschließlich der Übersichtlichkeit und Lesbarkeit.


305

x x x x

die Auslastung, die Anzahl der noch verfügbaren Plätze, den aktuellen Buchungstrend, die dem Angebot direkt zurechenbaren Kosten und damit auch der für einen positiven Deckungsbeitrag minimal zu erzielende Preis sowie x Informationen zu vergleichbaren und/oder konkurrierenden Reiseangeboten bezüglich Destination und/oder Reisetermin. Diese Informationen können aus verschiedenen Informationsquellen bezogen werden (vgl. hierzu Abschn. 4). Auf dieser Grundlage erfolgen sodann die Produktgestaltung, d. h. die Definition der im Last-Minute-Reiseangebot enthaltenen Produktkomponenten, und die Preisgestaltung, d. h. die Ermittlung eines Preises, der einerseits für den Kunden attraktiv ist, andererseits aber auch einen möglichst hohen positiven Deckungsbeitrag für das Unternehmen erwirtschaftet. Anschließend wird das neu erstellte Last-Minute-Reiseangebot im Reservationssystem erfasst, womit es für die Reisebüros, Wiederverkäufer und Kunden des Unternehmens unmittelbar einsehbar und buchbar wird. In der Folge analysieren die Mitarbeitenden des SachbearbeitungsTeams in bestimmten Zeitintervallen das Buchungsverhalten der Kunden in Bezug auf das neu erstellte Last-Minute-Reiseangebot. Die Buchungsdaten, die im Verkaufs- bzw. Reservationssystem entstehen, werden in Echtzeit in das Data Warehouse des Unternehmens geladen und stehen dort zur Abfrage bereit. Der Bericht, der ebendiese Informationen zur aktuellen Buchungslage enthält, wird von den Mitarbeitenden regelmäßig in Anspruch genommen und gehört mittlerweile zu den meistgenutzten Berichten, die durch die Informationslogistik-Infrastruktur des Unternehmens zur Verfügung gestellt werden. Sofern der Verfallstermin des Angebots noch nicht erreicht ist, können bestehende Last-Minute-Reiseangebote jederzeit überarbeitet werden. Gründe hierfür sind bspw., dass das Buchungsverhalten der Kunden bezüglich eines Last-Minute-Angebots nicht den Erwartungen entspricht oder dass mehrere Last-Minute-Reiseangebote in Konkurrenz zueinander stehen. In diesen Fällen ist zu vermuten, dass durch eine Überarbeitung der betroffenen Angebote deren Absatz und damit der finanzielle Ertrag für das Unternehmen insgesamt gesteigert werden kann. Dies kann im Extremfall sogar dazu führen, dass das Angebot ausgewählter Reisen eingestellt wird, um den Absatz anderer, für das Unternehmen aus den verschiedensten Gründen wichtigerer bzw. vordringlich zu verkaufender Reiseangebote zu fördern. Die zur Überarbeitung bestehender Last-Minute-Reiseangebote zu durchlaufenden Aktivitäten entsprechen im Wesentlichen denjenigen zum

306


Zweck der erstmaligen Erstellung. So sind wiederum zunächst das bestehende Angebot, Umfeld, Rahmenbedingungen und vergleichbare Angebote zu analysieren, die Produktkomponenten und der Preis zu überarbeiten sowie das bestehende Last-Minute-Reiseangebot im Reservationssystem entsprechend zu aktualisieren. Nach erfolgter Aktualisierung des Angebots wird dieses wiederum unmittelbar für die Reisebüros, Wiederverkäufer und Kunden des Unternehmens einsehbar und buchbar. Den Mitarbeitenden des SachbearbeitungsTeams kommt nun wiederum die Aufgabe zu, die Kundenreaktionen auf das veränderte Angebot zu überwachen und, sofern angezeigt, das LastMinute-Reiseangebot abermals zu überarbeiten.


307

Last Minute Produkt- und Preisgestaltung (Teil 1)

Bestehendes reguläres Reiseangebot identifizieren

Reiseangebote (Reservierungssystem)

Reguläres Reiseangebot

[Verfallstermin in mehr als 4 Wochen]

[Verfallstermin innerhalb von 4 Wochen]

Vorgang abgebrochen Reguläres Reiseangebot

Reiseangebot (Reservierungssystem)


Bestehendes reguläres Reiseangebot hinsichtlich enthaltener Produktkomponenten und Preis analysieren Reguläres Reiseangebot


Diverse Informationen (Diverse Quellen)

Umfeld, Rahmenbedingungen und vergleichbare Reiseangebote analysieren


Kontext

Kontext

Produktkomponenten des Last Minute Reiseangebots festlegen („Produktgestaltung“)

Produktkomponenten für Last Minute Reiseangebot

Produktkomponenten für Last Minute Reiseangebot


Kontext

Preis des Last Minute Reiseangebots festlegen („Preisgestaltung“) Last Minute Reiseangebot Last Minute Reiseangebot

Reiseangebot (Reservierungssystem)

Last Minute Reiseangebot im Reservierungssystem erfassen Last Minute Reiseangebot

Fortsetzung in Teil 2

Abb. 3. UML-Aktivitätsdiagramm des Prozesses „Last-Minute-Produkt- und -Preisgestaltung“ (Teil 1)

308


Abb. 4. UML-Aktivitätsdiagramm des Prozesses „Last-Minute-Produkt- und -Preisgestaltung“ (Teil 2)


4

309

Derzeitige informatorische Unterstützung der Prozessausführung

Es ist offenkundig, dass die Ausführung des Prozesses „Last-Minute-Produkt- und -Preisgestaltung“ einer adäquaten informatorischen Unterstützung bedarf. Im Zusammenhang mit der Prozessausführung sind zahlreiche Auswahl- und Gestaltungsentscheidungen zu treffen: x Welche bestehenden regulären Reiseangebote sollen zu Last-MinuteReiseangeboten umgestaltet werden? Bei welchen bestehenden regulären Reiseangeboten ist eine Umgestaltung hingegen nicht sinnvoll? x Auf welche Art und Weise sollen bestehende reguläre Reiseangebote umgestaltet werden, d. h. welche Produktkomponenten soll ein neu zu gestaltendes Last-Minute-Reiseangebot umfassen? x Welches ist ein sowohl für den Kunden attraktiver als auch für das Unternehmen ökonomisch sinnvoller Preis für ein Last-Minute-Reiseangebot? x Wie sind die Kundenreaktionen auf ein Last-Minute-Reiseangebot zu interpretieren? Wann besteht Überarbeitungsbedarf? Existieren darüber hinaus evtl. weitere Gründe, die für die Überarbeitung eines LastMinute-Reiseangebots sprechen? x Wie sollen bestehende Last-Minute-Reiseangebote sowohl hinsichtlich der Produktgestaltung als auch der Preisgestaltung verändert werden, sofern eine Überarbeitung erforderlich ist? Grundlage für diese Entscheidungen stellen Informationen dar, auf welche die Mitarbeitenden des Sachbearbeitungs-Teams über verschiedene Anwendungssysteme zugreifen können (vgl. hierzu auch Abb. 5). Zu diesen Anwendungssystemen zählen: x Data Warehouse: Im Unternehmens-DWH (SAP BW) können Informationen zu Produkten, zum Produktemix, zu Flugauslastungen, zum Buchungstrend und zu einzelnen Buchungen abgerufen werden. Die Historie der Daten reicht bis ins Jahr 2000 zurück. Zu bemerken ist in diesem Zusammenhang, dass im DWH keine Reiseangebote, sondern nur tatsächlich verkaufte Produkte (d. h. erfolgte Buchungen von Reiseangeboten) erfasst werden. Reiseangebote, die keine Buchung erhalten haben, werden im DWH nicht gespeichert. Wie bereits in Kapitel 3 erwähnt, werden die Buchungsdaten in Echtzeit in das DWH übernommen. x Reservationssystem: Im Reservationssystem des Unternehmens (Eigenentwicklung auf Basis von SAP-Lösungen) werden alle Reiseangebote

310


des Unternehmens erstellt und verwaltet. Gleichzeitig entstehen im Reservationssystem auch die Buchungen der Reiseangebote. x Verkaufssystem: Das Verkaufssystem (ebenfalls eine Eigenentwicklung auf Basis von SAP-Lösungen) dient der kundenseitigen Präsentation von Reiseangeboten sowie der Verarbeitung von Buchungen. x Externe Quellen: Über das Internet können die Mitarbeitenden auf vielfältige Informationen zugreifen, die für die Umgestaltung und Überarbeitung von Reiseangeboten relevant sind. Zu derartigen Informationen zählen bspw. Reiseangebote der Mitbewerber, aber auch aktuelle Nachrichten und Wetter- bzw. Klimadaten. Auf dieser Grundlage können die Mitarbeitenden die Attraktivität von Reisedestinationen und Reiseterminen für die potenziellen Kunden einschätzen und die Reiseangebote entsprechend ausgestalten. Darüber hinaus verlassen sich die Mitarbeitenden in vielen Fällen auch auf ihr implizites Erfahrungswissen in der Gestaltung und Überarbeitung von Last-Minute-Reiseangeboten.

Reservationssystem

Verkaufssystem

Externe Quellen

„Bauchgefühl“

Angebote Buchungen

Angebotsüberarbeitung: Last-Minute-Produktund -Preisgestaltung

Angebote Buchungen

Last-MinuteReiseangebote Fremdangebote Nachrichten Wetter

Implizites Erfahrungswissen

MANGELNDE

DWH

Produkte, Produktemix Flugauslastungen Buchungstrend Buchungen

Prozessausführung INTEGRATION

Informatorische Unterstützung

Reservationssystem

Abb. 5. Informatorische Unterstützung der Prozessausführung

Wie in Abb. 5 dargestellt, ist der Status Quo der Integration von Prozessausführung und informatorischer Unterstützung insgesamt als unzureichend zu bewerten. Obgleich die verfügbaren Informationsquellen von den Mitarbeitenden des Sachbearbeitungs-Teams intensiv in Anspruch ge-


311

nommen werden, existieren dennoch zahlreiche Medienbrüche zwischen den einzelnen Anwendungssystemen, die sowohl der Informationsbereitstellung als auch – im Fall des Reservationssystems – der eigentlichen Prozessausführung dienen. Ein dediziertes Anwendungssystem zur Steuerung des Prozessablaufs („Workflow Management“) kommt im Zusammenhang mit dem genannten Prozess nicht zum Einsatz. Offenkundig weist die gegenwärtige informatorische Unterstützung der Ausführung des Prozesses „Last-Minute-Produkt- und -Preisgestaltung“ sowohl Vor- als auch Nachteile auf. Der hauptsächliche Vorteil der gegenwärtigen Lösung besteht darin, dass der Ablauf von den Mitarbeitenden des Sachbearbeitungs-Teams außer Grundkenntnissen und einem Mindestmaß an Erfahrung in der Tourismusbranche sowie insbesondere in der Erstellung von Reiseangeboten keine weiteren spezifischen Kenntnisse erfordert. Darüber hinaus stellt die Beibehaltung des Status Quo für gewöhnlich den „Weg des geringsten Widerstands“ dar, weil zunächst keine neue Lösung erarbeitet werden muss und Veränderungen mit primär organisatorischen Konsequenzen vermieden werden können. Ein bedeutender Nachteil der gegenwärtigen Lösung besteht hingegen darin, dass der Prozess aufgrund fehlender Standardisierung, Strukturierung und mangelnder Integration von Prozessausführung und informatorischer Unterstützung zeitlich – und damit personell – sehr ressourcenintensiv ist. Des Weiteren bedingt die fehlende Standardisierung, dass Erfolgsmessung, Motivation der Mitarbeitenden, Überprüfung der Entscheidungen und dadurch Realisierung von Lerneffekten nur eingeschränkt möglich sind. Der Status Quo ist folglich als verbesserungswürdig zu charakterisieren.

5

Integration von Prozessausführung und informatorischer Unterstützung als Lösungsansatz

Der derzeit von der Hotelplan Swiss Group favorisierte Lösungsansatz zielt dementsprechend auf eine Verbesserung der informatorischen Unterstützung der Prozessausführung sowie auf die Integration der im Status Quo weitestgehend unabhängigen Prozess- und Informationssichten ab. Dabei wird ein zweistufiges Vorgehen verfolgt: x Vision: Weitestgehend automatisierte Erstellung von Last-MinuteReiseangeboten auf Grundlage von Geschäftsregeln.

312


x Zwischenlösung: Teilautomatisierter Prozessablauf mit Benutzerinteraktion durch menschliche Entscheider, integrierte Informationsbereitstellung mit Hilfe des SAP NetWeaver Visual Composer-Werkzeugs. Die im Zusammenhang mit dem Lösungsansatz verfolgte Zielsetzung der weitestgehend automatisierten Vorgangsbearbeitung auf Grundlage von Geschäftsregeln kann nur mittelbar erreicht werden. Wesentliche fachliche Voraussetzungen für die Realisierbarkeit der Vision sind die Identifikation und sorgfältige Analyse von Parametern, auf deren Grundlage automatisierte Entscheidungen bezüglich der Produkt- und Preisgestaltung von Last-Minute-Reiseangeboten getroffen werden können. Darauf aufbauend müssen Entscheidungsbäume zur Repräsentation von Entscheidungsregeln bezüglich der Produkt- und Preisgestaltung erstellt werden (vgl. hierzu bspw. Laux 2005). Den Verzweigungen der Entscheidungsbäume werden jeweils Parameter sowie zulässige Parameterwerte bzw. -wertebereiche zugeordnet. Jeder Endpunkt eines Entscheidungsbaums, welcher durch eine bestimmte Auswahl- oder Gestaltungsentscheidung wie bspw. das Hinzufügen oder Entfernen einer bestimmten Produktkomponente zu bzw. von einem Reiseangebot oder die Anpassung des Angebotspreises um einen bestimmten Geldbetrag gekennzeichnet ist, ist auf einem eindeutigen Weg durch den Entscheidungsbaum erreichbar. Nach erfolgreicher Definition der Geschäftsregeln, Umgestaltung und Automatisierung des Prozessablaufs sowie informationstechnischer Implementierung der regelbasierten Prozessausführung und -unterstützung kommen den Mitarbeitenden die Aufgaben zu, die automatisierte Prozessausführung zu überwachen, Ausreißer aus den im Entscheidungsbaum definierten Regeln zu erkennen und zu korrigieren sowie die Parameter und deren zulässige Wertebereiche (und damit die an den Verzweigungen der Entscheidungsbäume hinterlegten Entscheidungsregeln) sich verändernden Rahmenbedingungen, Vorgaben oder Erfordernissen anzupassen. Schwierigkeiten im Zusammenhang mit der Parametrisierung der Entscheidungsgrundlage sind vor allem deshalb zu erwarten, da eine Vielzahl von „weichen“, oft in hohem Maße variablen Faktoren (wie bspw. Trends, Vorlieben und Preissensibilität der Kunden) oder kurzfristige Ereignisse (wie z. B. das Vorliegen eines erhöhten Gefahrenpotenzials oder das Eintreten von Naturkatastrophen an einer Destination) zu berücksichtigen sind. Weiterhin stellt die Parameterdefinition insofern eine große Herausforderung dar, als dass detaillierte Erkenntnisse über die Zusammenhänge zwischen verschiedenen Einflussgrößen untereinander sowie ihrer letztendlichen Auswirkungen auf den Verkaufserfolg eines Last-Minute-Reiseangebots erworben und in Modellen abgebildet werden müssen. Diese Aufgaben erfordern von den Mitarbeitenden spezielle Fähigkeiten und


313

Wissen im Bereich der mathematischen Optimierung sowie dedizierte Branchenkenntnisse der Tourismusindustrie. Wie bereits erwähnt, kann die vorstehend beschriebene Vision aufgrund fachlicher und organisatorischer Restriktionen nur mittelbar realisiert werden. Als Interimslösung favorisiert die Hotelplan Swiss Group deshalb die Standardisierung und Teilautomatisierung des Prozessablaufs, die integrierte Informationsbereitstellung mit Hilfe des Visual Composer-Werkzeugs und die Beibehaltung einer Benutzerinteraktion durch menschliche Entscheider. Eine derartige Lösung, die explizit als Zwischenschritt auf dem Weg zur Realisierung der vorstehend beschriebenen Vision zu verstehen ist, weist eine Vielzahl von Vorteilen auf: x Prozessorientierte Informationslogistik verfolgt das Ziel, Prozessausführung und informatorische Unterstützung zu integrieren. Die Mitarbeitenden, die mit der Prozessausführung und mithin auch mit dem Treffen prozessinhärenter Entscheidungen auf Grundlage von analytischen Informationen betraut sind, sollen nicht zwischen verschiedenen Anwendungssystemen wechseln müssen, um ihre Aufgaben erledigen zu können. Vielmehr sollen die Mitarbeitenden auf einer einheitlichen Benutzeroberfläche sowohl die einzelnen Prozessschritte bewältigen als auch auf die unterstützenden analytischen Informationen zugreifen können. Dadurch werden Medienbrüche vermieden, die Wahrscheinlichkeit von Fehlern verringert, die Qualität und Vielfalt der prozessunterstützenden Informationen verbessert sowie die Prozessausführung vereinheitlicht, beschleunigt, und besser kontrollier- und nachvollziehbar. In Gestalt des Visual Composer-Werkzeugs steht bei der Hotelplan Swiss Group eine Lösung zur Verfügung, die sowohl als Benutzeroberfläche für die Ausführung operativer Prozesse fungieren als auch gleichzeitig relevante Informationen, welche bspw. aus dem Unternehmens-DWH bzw. einer darauf aufsetzenden BI-Anwendung stammen, visualisieren kann (Bönnen u. Herger 2007, S. 33-35). Da die Hotelplan Swiss Group vorwiegend SAP-Lösungen bzw. auf SAP-Produkten basierende eigenentwickelte Anwendungssysteme betreibt, fiel die Technologiewahl aus Kompatibilitätsgründen zugunsten des genannten Produkts aus. x Die Anforderungen, die die Zwischenlösung an die Parameterdefinition und die Datenaufbereitung stellt, sind geringer als bei der Parametrisierung der Entscheidungsgrundlage für die automatisierte Prozessausführung und Entscheidungsfindung. Menschliche Entscheider können den Handlungsempfehlungen des Anwendungssystems folgen, diese hinterfragen oder gar verwerfen. Sie sind darüber hinaus in der Lage, die bereitgestellten Informationen subjektiv zu interpretieren und können bei Bedarf auch kurzfristig zusätzliche Informationen und/oder ihr persönli-

314


ches Erfahrungswissen in die Produkt- und Preisgestaltung einfließen lassen. Die vom Anwendungssystem bereitgestellten analytischen Informationen und Handlungsempfehlungen dienen folglich der Unterstützung menschlicher Entscheider in ihrer Entscheidungsfindung, nehmen diesen die Entscheidung jedoch nicht bzw. nicht vollständig ab. x Analog zum vorgenannten Punkt können auch die Anforderungen, die die Zwischenlösung an die Qualifikation der Mitarbeitenden stellt, als Zwischenschritt im Übergang vom Status Quo zur Realisierung der Vision der Vollautomatisierung interpretiert werden. Die Tätigkeiten der Mitarbeitenden des Sachbearbeitungs-Teams werden im Vergleich zum Status Quo deutlich aufgewertet. Gleichzeitig sind die Mitarbeitenden in der Lage, ihre Aufgaben aufgrund der verbesserten informatorischen Unterstützung sowie der Integration von Prozessausführung und Bereitstellung adäquater analytischer Informationen effizienter zu erledigen. Durch die Einbindung und Beteiligung der Mitarbeitenden an der Entwicklung bzw. Anpassung des Anwendungssystems an die situativen Charakteristika der Last-Minute-Produkt- und -Preisgestaltung können sich diese darüber hinaus fortbilden und qualifizieren, um die geplante Weiterentwicklung zur vollautomatisierten Prozessausführung und Entscheidungsfindung als Spezialisten begleiten zu können. x Nicht zuletzt stellt auch die kurzfristige Realisierbarkeit der Zwischenlösung einen signifikanten Vorteil dar. Im Gegensatz zum Ziel der Vollautomatisierung, für deren Erreichung zunächst Lösungen für fachliche Fragestellungen zu erarbeiten und organisatorische Veränderungen anzustoßen sind, lässt sich die genannte Zwischenlösung auf Grundlage des Visual Composer-Werkzeugs vergleichsweise schnell, flexibel und kostengünstig realisieren. Auch in Bezug auf die Identifikation der zur Unterstützung der Prozessausführung erforderlichen analytischen Informationen sowie die fachliche Entwicklung der Mitarbeitenden des Sachbearbeitungs-Teams stellt die Zwischenlösung eine interessante und ohne größere Hindernisse zu realisierende Perspektive dar.

6

Zusammenfassung

In der vorliegenden Fallstudie wurde der Prozess für die Produkt- und Preisgestaltung von Last-Minute-Reiseangeboten bei der Hotelplan Swiss Group diskutiert. Obgleich dieser Prozess aufgrund des gewählten Branchenfokus, der Thematik und der geringen Komplexität auch für Außenstehende vergleichsweise einfach nachzuvollziehen ist, so sind dessen Ausführung und insbesondere die adäquate informatorische Unterstützung


315

dennoch alles andere als trivial. So ist von den Mitarbeitenden des Sachbearbeitungs-Teams, die für die Prozessausführung verantwortlich zeichnen, eine Vielzahl von interdependenten Entscheidungen zu treffen. Auf Grundlage der derzeitigen informatorischen Unterstützung ist eine ganzheitliche Steuerung und Optimierung des Portfolios der von der Hotelplan Swiss Group zum Verkauf angebotenen Last-Minute-Reisen jedoch nahezu unmöglich. Weiterhin wird das Potenzial der Mitarbeitenden bezüglich der Erstellung attraktiver und für das Unternehmen ökonomisch sinnvoller Reiseangebote nur bedingt ausgeschöpft. Aus diesen Gründen verfolgt die Hotelplan Swiss Group derzeit einen zweistufigen Lösungsansatz. Kurzfristig wird eine bessere Strukturierung des Prozessablaufs, dessen Teilautomatisierung und integrierte informatorische Unterstützung mit Hilfe des SAP NetWeaver Visual ComposerWerkzeugs angestrebt. Diese Zwischenlösung dient als Wegbereiter der mittel- bis langfristig verfolgten Vision einer Vollautomatisierung der Prozessausführung und der Entscheidungsfindung im Zusammenhang mit der Produkt- und Preisgestaltung von Last-Minute-Reiseangeboten. Durch die Verfolgung des vorgenannten zweistufigen Lösungsansatzes wird die Realisierung verschiedener Nutzeneffekte der prozessorientierten Informationslogistik im Zusammenhang mit der Last-Minute-Produkt- und -Preisgestaltung möglich. Zu diesen anwendungsfallspezifischen Nutzeneffekten zählen: x Qualitative Verbesserungen der Prozessleistung: Die Strukturierung und Standardisierung des Prozessablaufs sowie die Identifikation und Einbettung entscheidungsunterstützender Informationen in den Kontext der Prozessausführung führen zu einer qualitativen Verbesserung der Prozessleistung und zu einer Verringerung der Anzahl von Fehlentscheidungen. Zum einen werden Handlungen und Entscheidungen in Zusammenhang mit der Produkt- und Preisgestaltung von Last-MinuteReiseangeboten nachvollziehbar und überprüfbar, zum anderen wird eine Abstimmung bzw. Optimierung der Gesamtheit aller Last-MinuteReiseangebote des Unternehmens möglich. Auf diese Art und Weise wird die enge, lokale Sicht eines jeden einzelnen Mitarbeitenden des Sachbearbeitungs-Teams überwunden und eine effektive ganzheitliche Steuerung und Optimierung des Portfolios von Last-Minute-Reiseangeboten ermöglicht. x Effizienzgewinne in der Ressourcennutzung: Durch Strukturierung und Standardisierung des Prozessablaufs sowie durch adäquate informatorische Unterstützung und ganzheitliche Steuerung des Prozessablaufs können darüber hinaus Effizienzgewinne realisiert werden. Dies bezieht sich zum einen auf personelle Ressourcen, zum anderen auf die Aus-

316


lastung von bereitgestellten Kapazitäten. Durch Straffung und Teilbzw. Vollautomatisierung des Prozessablaufs sind die Mitarbeitenden in der Lage, eine im Vergleich zum Status Quo größere Anzahl qualitativ hochwertiger und attraktiver Last-Minute-Reiseangebote zu erstellen. Gleichzeitig wird durch die ganzheitliche Optimierung des Portfolios von Last-Minute-Reiseangeboten eine gegenüber dem Status Quo effizientere Allokation der Kunden auf Flug- und Übernachtungskapazitäten möglich. x Steigerung der Arbeitszufriedenheit der Mitarbeitenden: Nicht zuletzt kann durch die Integration von Prozessausführung und informatorischer Unterstützung die Arbeitszufriedenheit der Mitarbeitenden gesteigert werden. Die weitestgehende Standardisierung und adäquate informatorische Unterstützung der Arbeitsabläufe eröffnet den Mitarbeitenden u. a. die Möglichkeit, Erfahrungen und Wissen systematisch zu erwerben, anzuwenden, zu dokumentieren und weiterzugeben, sich sowohl in fachlicher als auch in technischer Hinsicht weiterzubilden bzw. weiterzuentwickeln sowie zusätzliche Aufgaben und Verantwortung zu übernehmen. Darüber hinaus wird es für das Unternehmen möglich, die individuelle Leistung der Mitarbeitenden zu überwachen und diese mit entsprechenden Zielsystemen und Leistungsanreizen zu motivieren. Die vorgenannten Nutzeneffekte sprechen klar für die weitere Verfolgung des durch die Hotelplan Swiss Group eingeschlagenen Wegs. Zum Zeitpunkt der Fallstudienerhebung und -dokumentation (Herbst 2007) befindet sich das Pilotprojekt der Integration von Prozessausführung und informatorischer Unterstützung am Beispiel des Prozesses der Last-MinutePreis- und -Produktgestaltung in der Planungsphase. Eine prototypische Umsetzung wird für das erste Halbjahr 2008 angestrebt.

Literatur Bönnen, C.; Herger, M.: SAP NetWeaver Visual Composer, Galileo Press, Bonn 2007. Graham, B.: Air Transport Liberalization in the European Union - An Assessment, in: Regional Studies 31 (1997) 8, S. 807-812. Gupta, A.; Su, B.-C.; Walter, Z.: An Empirical Study of Consumer Switching from Traditional to Electronic Channels - A Purchase-Decision Process Perspective, in: International Journal of Electronic Commerce 8 (2004) 3, S. 131161. Hotelplan AG Internationale Reiseorganisation: Jahresbericht Hotelplan Gruppe 2006, Glattbrugg 2007.


317

Javalgi, R.; Ramsey, R.: Strategic Issues of E-Commerce as an Alternative Global Distribution System, in: International Marketing Review 18 (2001) 4, S. 376391. Keaveney, S.; Parthasarathy, M.: Customer Switching Behavior in Online Services - An Exploratory Study of the Role of Selected Attitudinal, Behavioral, and Demographic Factors, in: Journal of the Academy of Marketing Science 29 (2001) 4, S. 374-390. Laux, H.: Entscheidungstheorie, 6. Aufl., Springer, Berlin 2005. Liang, T.-P.; Huang, J.-S.: An Empirical Study on Consumer Acceptance of Products in Electronic Markets - A Transaction Cost Model, in: Decision Support Systems 24 (1998) 1, S. 29-43. Oestereich, B.: Die UML 2.0 Kurzreferenz für die Praxis - kurz, bündig, ballastfrei, 4. Aufl., Oldenbourg Wissenschaftsverlag, München 2005. Pitt, M.; Brown, A.: Developing a Strategic Direction for Airports to Enable the Provision of Services to Both Network and Low-Fare Carriers, in: Facilities 19 (2001) 1/2, S. 52-60.

15 Informationslogistikarchitekturen am Beispiel der Credit Suisse

Barbara Binzegger Ruoss, Andreas Geppert Credit Suisse

Florian Stroh Universität St. Gallen

1 2 3 4 5 6

1

Einleitung ....................................................................................... 319 Das Applikationsplattformkonzept der Credit Suisse..................... 320 Die DWH-Referenzarchitektur der Credit Suisse........................... 322 Die DWH-Applikationsplattform ................................................... 328 Informationslogistik am Beispiel von Geschäftsprozessen der Credit Suisse ................................................................................... 330 Zusammenfassung und Ausblick .................................................... 336 Literatur .......................................................................................... 336

Einleitung

Der Informationsverarbeitung wird im Bankensektor eine enorme Bedeutung beigemessen. Sie wird bezüglich des Stellenwerts beispielsweise mit Produktionsstraßen in Industrieunternehmen verglichen. Betrachtet man den Fertigungsprozess einer Bank, lassen sich vier Subprozesse identifizieren, die in unterschiedlichem Ausmaß durch Informationssysteme unterstützt werden: Akquisition, Vereinbarung von Geschäften, Abwicklung von Geschäftsvorfällen und Bereitstellung von Informationen (Moormann 2004, S. 4). Insbesondere bei der Bereitstellung von Informationen entstehen oftmals Datenflüsse zwischen unterschiedlichen Organisationseinhei-

320

Barbara Binzegger Ruoss, Andreas Geppert, Florian Stroh

ten innerhalb des Unternehmens, deren Koordination und Steuerung zu den Aufgaben der Informationslogistik zählen. Intention des vorliegenden Beitrags ist es, dem Leser anhand eines Praxisbeispiels einen Einblick zu ermöglichen, wie die Informationslogistik in einer Großbank operationalisiert werden kann. Als Untersuchungsobjekt dient hierfür die Credit Suisse. Bei der Credit Suisse wurde die Notwendigkeit einer unternehmensweiten Informationslogistik frühzeitig erkannt. Treiber hierfür waren u. a. die Größe (Stand 2006: verwaltetes Vermögen in Höhe von 1485 Mrd. Schweizer Franken und über 45000 Mitarbeiter) sowie ihre Struktur mit drei Geschäftsdivisionen „Private Banking“, „Investment Banking“ sowie „Asset Management“. Eine zentrale Division „Shared Services“ unterstützt die anderen Divisionen hierbei beispielsweise bei der Einhaltung gesetzlicher Regulierungen (Department Legal & Compliance) (Credit Suisse 2006). Eingangs des Artikels wird das Konzept der Applikationsplattformen sowie im Anschluss daran die Referenzarchitektur der Credit Suisse für die Informationslogistik samt essentieller Architekturprinzipien im Detail vorgestellt. Darauf aufbauend findet eine detaillierte Betrachtung der Datenflüsse zwischen Applikationen und Organisationseinheiten innerhalb ausgewählter Geschäftsprozesse statt.

2

Das Applikationsplattformkonzept der Credit Suisse

Eine global operierende Bank wie die Credit Suisse mit einem breiten bankfachlichen Angebot kann nur mit adäquater IT-Unterstützung erfolgreich betrieben werden. Wie für Unternehmen dieser Größenordnung typisch, besteht auch die IT der Credit Suisse aus mehreren hundert IT-Applikationen. Die Implementierung einer Applikation erfolgt hierbei nicht auf isolierte Art und Weise sondern basiert auf einer Infrastruktur. Diese Infrastruktur besteht zum einen aus Komponenten, die die Applikation zur Erfüllung ihrer Funktionalität benötigt, wie z. B. ein Datenbanksystem oder einen Applikations-Server. Ferner zählen zur Infrastruktur so genannte „Umsysteme“, die für den Betrieb einer Applikation notwendig sind (z. B. Monitoring Tools für die Überwachung einer Applikation). In der Credit Suisse wurde vor einigen Jahren festgestellt, dass in der Applikationsentwicklung viele Infrastrukturentscheidungen und -arbeiten anfielen, die applikationsunabhängig waren. Beispiele hierfür sind die Auswahl eines Datenbankmanagementsystems (DBMS) für eine Applikation, das Aufsetzen und Anpassen ("Engineering") des DBMS für diese

Informationslogistikarchitekturen am Beispiel der Credit Suisse

321

Applikation, Entscheidungen über die Einsatzweise (z. B. welche Funktionalitäten benötigt werden) etc. Auch für den Betrieb von Applikationen mussten Fragen bzgl. der Betriebsprozesse (z. B. für die Überwachung von Applikationsprozessen) auf Applikationsebene geklärt werden, obwohl diese prinzipiell applikationsunabhängig sind. Demzufolge wurden derartige Infrastruktur- und Betriebsaspekte aus der Anwendungsentwicklung herausgelöst und in Form von so genannten Applikationsplattformen wiederverwendbar zur Verfügung gestellt. Eine Applikationsplattform ist ein System aus vorintegrierten technischen Komponenten (z. B. ein DBMS) für eine Familie von ähnlichen Applikationen. Darüber hinaus definiert jede Applikationsplattform eine Menge von Prozessen für die Entwicklung und den Betrieb von Applikationen auf dieser Applikationsplattform. Zudem stellt jede Applikationsplattform Dokumentation, insbesondere Standards und Richtlinien, zur Verfügung, die den Anwendungsentwicklern Hilfestellung bietet und dafür sorgt, dass die Applikationsplattform einheitlich verwendet wird. Schließlich werden für jede Applikationsplattform eine Strategie und eine Roadmap erstellt. Die Strategie legt u. a. fest, welcher Einsatzbereich für die fragliche Plattform strategisch adressiert wird, und welche technologischen und funktionellen Erweiterungen langfristig geplant werden. Die Roadmap ist das Bindeglied zwischen der Strategie und der Release-Planung, d. h. sie zeigt, wann welche Releases mit welchen funktionalen oder sonstigen Neuerungen eingeführt werden. In der Credit Suisse existieren derzeit fünf Applikationsplattformen, von denen jede jeweils eine Gruppe ähnlicher Applikationen unterstützt: x Mainframe Transaction Processing/Batch: Operationelle Anwendungen, d. h. Transaktionsverarbeitung (Online Transaction Processing - OLTP) x Java Application Platform (JAP): Internet/Intranet-Anwendungen x Data Warehouse Application Platform (DWH AP): Analytische Anwendungen x ERP: ERP-Anwendungen (Enterprise Ressource Planning) x Hosting light: Leichtgewichtige, in der Regel eingekaufte und nicht businesskritische Unterstützungsanwendungen. Es wurden Hilfestellungen und Standards erstellt, die festlegen, für welche Anforderungen welche Applikationsplattform verwendet werden soll. Die Einhaltung dieser Richtlinien wird mit Reviews im IT-Projektprozess überprüft. Mittlerweile wird der weitaus größte Teil von Anwendungen auf einer oder mehreren Anwendungsplattformen entwickelt und betrieben.

322

3


Die DWH-Referenzarchitektur der Credit Suisse

Die Credit Suisse unterhält als Kern der unternehmensweiten Informationslogistik ein Data Warehouse (DWH), entsprechend der klassischen Definition von Bill Inmon: "A data warehouse is a subject-oriented, integrated, time-varying, non-volatile collection of data in support of the management's decision-making process" (Inmon 2002). Dieses Data Warehouse wurde seit Ende der 1990er Jahre aufgebaut und bedient heute unterschiedlichste Analysebedürfnisse der Bank (vgl. z. B. Brändli et al. 2004). 3.1 Aufbau und Schichten der DWH-Referenzarchitektur Dieses DWH ist das Ergebnis einer Konsolidierung verschiedener spezialisierter DWHs (Tresch u. Jonscher 2001). Es handelt sich somit um ein integriertes, unternehmensweites DWH für die Bereiche Private Banking und Shared Services. Durch das integrierte DWH sollte eine "Single Source of the Truth" und somit ein bereichsübergreifendes, konsistentes Reporting ermöglicht werden. Neben der Integration war die Unterstützung aller Stufen der Organisation gefordert. Das DWH unterstützt ein breites Spektrum von Benutzern und bietet Kennzahlen und Berichte, die für Sachbearbeiter oder Kundenbetreuer relevant sind, bis hin zu stark aggregierten Kennzahlen für das Top Management. Die DWH-Applikationsplattform (DWH AP) ist die Standardplattform für die Entwicklung und den Betrieb aller analytischen Anwendungen. Wie bei anderen Applikationsplattformen auch, wird im Fall der DWH AP die Infrastruktur, inklusive der Hardware, unter den Applikationen geteilt und gemeinsam benutzt. Darüber hinaus liegt den Applikationen im Fall der DWH AP jedoch auch eine geteilte, gemeinsame Datenbank zugrunde, nämlich das zentrale, integrierte Data Warehouse selbst. Im Unterschied zu den Applikationen anderer Plattformen sind die der DWH AP folglich nicht völlig unabhängig voneinander. Um dennoch ein stabiles, konsistentes und flexibles Gesamtsystem zu gewährleisten, sind angemessene und konkrete Architekturvorgaben erforderlich, deren Einhaltung konsequent überwacht werden muss. Im Fall der DWH AP sind diese Vorgaben in Form einer Referenzarchitektur und begleitender Standards bzw. Architekturprinzipien gegeben. Der Begriff der Referenzarchitektur wird dabei gemäß der Definition von (Bass et al. 2003) gebraucht, d. h. im Sinne einer Architektur, die ein Referenzmodell implementiert, welches eine aus Erfahrung destillierte Standardlösung für ein bestimmtes Problem darstellt ("A reference model is a division of functionality together with data flow between the pieces …


323

A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem. Arising from experience, reference models are a characteristic of mature domains" … "A reference architecture is a reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them."). Die DWH-Referenzarchitektur (siehe Abb. 1) ist eine Variation der so genannten "Hub and Spoke-Architektur" (Ariyachandra u. Watson 2005) und somit anderen Referenzarchitekturen (z. B. Bauer u. Günzel 2004, S. 36) ähnlich. Diese Referenzarchitektur definiert den Bau des gesamten DWHs, wie auch den Aufbau der einzelnen DWH-Applikationen. Die Architektur besteht aus drei Schichten, der Integrationsschicht, der Anreicherungsschicht sowie der Analyseschicht. Die Anreicherungsschicht ist hierbei optional und muss nicht von allen Applikationen verwendet werden. Die Datenquellen des DWHs sind zum großen Teil Applikationen anderer Plattformen wie z. B. der OLTP-Plattform, aber auch externe Quellen. In der Regel liefern diese Quellen neue Daten auf täglicher Basis in Form von Feeder Files. Die gelieferten Daten werden im Zuge des ETL-Prozesses (Extraktion, Transformation, Laden) in das zentrale Data Warehouse, d. h. die Integrationsschicht geladen. In dieser Schicht werden Daten, die

Abb. 1. Die DWH-Referenzarchitektur der Credit Suisse

324


sich auf die gleichen Sachverhalte oder Geschäftsobjekte beziehen, zusammengeführt und logisch integriert, auch wenn sie aus unterschiedlichen Quellen stammen. Die Datenhaltung der Integrationsschicht ist dabei unterteilt in so genannte Bereichsdatenbanken (BDBs). Jede dieser Bereichsdatenbanken enthält die Daten eines bestimmten, kohärenten Geschäftsbereiches (also z. B. Zahlungen, Kredite, Marketing, etc.). Zwei Bereichsdatenbanken enthalten zentrale Informationen wie Kundendaten und Referenzdaten, die von allen anderen Bereichsdatenbanken benötigt und referenziert werden. Zu den weiteren Aufgaben der Integrationsschicht zählen die Historisierung sowie die Qualitätssicherung von Daten. Die Strukturierung der Integrationsschicht in Bereichsdatenbanken hat sich durchaus bewährt. Zum einen konnte hierdurch das DWH durch die Integration neuer Bereichsdatenbanken einfacher wachsen, ohne dass existierende Bereichsdatenbanken hiervon betroffen waren. Ferner gestaltet sich die Weiterentwicklung mit Bereichsdatenbanken als weniger komplex als mit einem amorphen DWH. Letztlich wird auch die Klärung von Verantwortlichkeiten (von Datenarchitekten, IT- und Business-Ownership) auf Ebene von Bereichsdatenbanken erleichtert. Die Bereichsdatenbanken dienen lediglich der Integration der Daten; auf dieser Schicht werden keine Analysen durchgeführt. Gründe hierfür sind zum einen, dass die Datenmodelle der Integrationsschicht nicht für Analysen geeignet sind, zum anderen soll eine Trennung der jeweiligen Lasten vollzogen werden. Analysen finden immer in der Analyseschicht statt. Die Analyseschicht enthält eigene Datenhaltungssysteme in Form von Data Marts. Diese Data Marts werden aus den Bereichsdatenbanken (und/oder aus Anreicherungsdatenbanken, s. u.) geladen; ein direktes Laden aus einer Quelle an den Bereichsdatenbanken vorbei ist nicht architekturkonform und deshalb nicht möglich. Es handelt sich somit um abhängige Data Marts (vgl. Kap. 7, Abschn. 3.1.1). Data Marts sind in der Regel tagesaktuell, d. h. ihre Daten spiegeln den Zustand des vergangenen Arbeitstages wieder. Data Marts, die nur monatliche Reports liefern müssen, werden monatlich geladen. Das täglich mehrfache Laden eines Data Marts wird nur selten gefordert und wird deshalb standardmäßig nicht unterstützt. Jeder Data Mart ist einer bestimmten Anwendung zugeordnet und ist so entworfen, dass Analyseanforderungen optimal unterstützt werden. Mögliche Analysearten umfassen derzeit mehrheitlich Reporting, aber auch Data Mining und OLAP. Sowohl die Analyseart als auch die Art der Weiterverarbeitung der Ergebnisse hängen dabei von der Applikationssemantik ab. Es ist dabei auch möglich, dass Analyseergebnisse über entsprechende Schnittstellen Eingang in operationelle Prozesse finden (vgl. Kap. 7, Abschn. 3.2.1).


325

Das physische Schema eines Data Marts ist analyseorientiert. Dies bedeutet, dass je nach Informationsbedarf der Anwendung Selektionen, Aggregationen oder sonstige Kennzahlenberechnungen im Rahmen des ETLProzesses stattfinden, der den Data Mart befüllt. In manchen Fällen sind diese Transformationen und Berechnungen extrem komplex, finden auf sehr großen Datenmengen statt und sind deshalb sehr zeitintensiv. Manche dieser Kennzahlen werden zudem von verschiedenen Applikationen benötigt, so dass sie redundant in mehreren ETL-Prozessen stattfinden müssten. Dies motivierte die Einführung der Anreicherungsschicht: Hier können komplexe, wiederverwendbare Berechnungen auf Anreicherungsdatenbanken durchgeführt und ihre Ergebnisse über wohldefinierte Schnittstellen nachgelagerten Data Marts zur Verfügung gestellt werden. Zusätzlich zu den drei "vertikalen" Schichten existiert eine übergreifende Administrationsschicht. Diese Schicht enthält insbesondere die Metadatenverwaltung. Weitere schichtenübergreifende Aufgaben wie Sicherheitsadministration sind ebenfalls in diesem "Fundament" angesiedelt. 3.2 Architekturprinzipien der DWH-Referenzarchitektur Zur Sicherstellung der Flexibilität (z. B. durch Vermeidung unnötiger Abhängigkeiten) sowie der Handhabbarkeit der Architektur wurde die Referenzarchitektur um entsprechende Architekturprinzipien erweitert, die die Ausprägung der Referenzarchitektur steuern und diese in Fällen mit Interpretationsspielraum auch näher beschreiben. Diese Architekturprinzipien (siehe Tabelle 1) sind in vier Gruppen unterteilt: Prinzipien, die für das gesamte System gelten sowie spezifische Prinzipien für die drei Schichten. Prinzip 1 schreibt die bereits erwähnte Trennung von Integration und Analyse, also einen mehrschichtigen Ansatz vor. Prinzip 2 verlangt, dass für jede Applikation (hier werden unter „Applikationen“ Integrations-, Anreicherungs- und Analyseapplikationen verstanden) je ein fachlicher als auch ein IT-„Owner“ existieren müssen. Ein IT-Owner existiert praktisch immer, ein fachlicher Owner kann vor allem in der Integrationsschicht schwer zu finden sein. Ein fachlicher Owner ist jedoch von essentieller Bedeutung, da nur er die Semantik und Qualitätsregeln von Daten festlegen kann. Prinzip 3 definiert Datenqualität als einen Prozess, in dem Datenqualität definiert, überprüft, gemessen und rapportiert wird. Ferner sind in diesem Prozess Qualitätsprobleme auf angemessene Weise zu behandeln. Prinzip 4 adressiert das im Rahmen eines DWH oft problembehaftete Thema der Änderungen. Modifikationen von Daten prinzipiell auszuschließen, hat sich im Fall des DWHs der Credit Suisse nicht als praktika-

326


bel erwiesen. Stattdessen wird zwischen Korrekturen und Anpassungen unterschieden. Korrekturen ändern Daten, die ein falsches Bild der modellierten Umwelt wiedergeben; diese Daten sind also für alle Konsumenten falsch. Korrekturen müssen in dem jeweiligen Quellsystem vorgenommen werden. Anpassungen hingegen betreffen Daten, die nur für einzelne Anwendungen inadäquat, jedoch nicht generell falsch sind. Diese Anpassungen können über Schnittstellen und unter Einhaltung der Nachvollziehbarkeit in der Anreicherungsschicht oder in Data Marts vorgenommen werden. Das 5. allgemeine Prinzip schreibt vor, dass Zugriffe innerhalb des DWH, jedoch über Schichten hinweg über wohldefinierte Schnittstellen erfolgen müssen. Die Einhaltung dieses Prinzips ist von hoher Bedeutung, um die Wartbarkeit des Gesamtsystems zu garantieren. Falls keine Schnittstellen existieren, also z. B. Direktzugriffe aus einem Data Mart in Bereichsdatenbanken stattfinden, entstehen Abhängigkeiten, deren Kontrolle sich bei einem System dieser Größe als äußerst komplex gestalten würde. Im Falle einer Modifikation an einer der Bereichsdatenbanken hätte dies wiederum entsprechende Änderungen an mehreren Data Marts zur Folge. Dies könnte bei den verantwortlichen Abteilungen zu einem hohen Widerstand gegenüber Änderungen („Resistance to Change“) führen. Das Integrationsprinzip (6) fordert eine konsequente Umsetzung der Hub and Spoke-Architektur. Daten aus den Quellen müssen in der Integrationsschicht logisch, d. h. gemäß ihrer Bedeutung, integriert werden. Ein simples Durchreichen der Datenstrukturen, die von den Quellen geladen werden, genügt dieser Forderung nicht. Eine wichtige Anforderung an die Bereichsdatenbanken ist die Möglichkeit, neue Quellen zu erschließen und neue Data Marts mit den für Analysen benötigten Daten zu versorgen, also Wiederverwendbarkeit und Redundanzfreiheit der Daten im Data Warehouse sicherzustellen. Dies bedingt eine adäquate Modellierung und die Betreuung dieser Datenmodelle durch ein zentrales Team von Datenarchitekten. Das erste Anreicherungsprinzip (7) spiegelt die Intention der Anreicherungsschicht wieder (s. o.). Das zweite Prinzip dieser Gruppe schränkt die mögliche Komplexität der Anreicherungsschicht auf ein wartbares Maß ein. Es soll verhindert werden, dass Anreicherungsdatenbanken hintereinander geschaltet werden; andernfalls entstehen Abhängigkeiten, die die Wartbarkeit verschlechtern sowie die Tagesaktualität der Data Marts gefährden. Die beiden Architekturprinzipien der Analyseschicht haben ebenfalls zum Ziel, die Wartbarkeit und Flexibilität (in diesem Fall die der Data Marts) zu garantieren. Prinzip 9 schließt aus, dass Data Marts Daten aus anderen Data Marts beziehen. Andernfalls könnte ein Data Mart nicht wei-


327

terentwickelt werden, ohne dass die von ihm belieferten Data Marts diese Änderungen nachvollziehen. Mit derselben Intention verlangt Prinzip 10, dass ein Data Mart nicht von mehreren Applikationen geteilt werden darf. Wäre dies der Fall, müssten Änderungen an einem solchen geteilten Data Mart auf Grund von neuen oder veränderten Anforderungen einer Applikation in anderen Applikationen nachvollzogen werden. Als Folge würde das Management der Data Mart-Lebenszyklen erschwert werden. Die Einhaltung der Referenzarchitektur und der Architekturprinzipien wird durch eine Kombination von Schulung, Beratung und Begutachtung gefördert. Schulung und Beratung zielen darauf ab, Standards und Prinzipien bekannt zu machen und zu erklären, so dass Entwickler und Projektleiter sowohl von der Richtigkeit der Standards als auch der Wichtigkeit ihrer Einhaltung überzeugt sind. Insbesondere wird hier der manchmal auftretende Konflikt zwischen Projektinteressen und Gesamtinteresse (Homogenität und Stabilität des Gesamtsystems) thematisiert. Schließlich werden alle IT-Projekte in verschiedenen Phasen jeweils einer Begutachtung unterzogen; Aufgabe der Plattformarchitektur ist es hierbei, die Einhaltung der Technologie- und Architekturstandards zu überprüfen. Tabelle 1. Die Architekturprinzipien der DWH-Referenzarchitektur Gruppe

Id Prinzip

Generelle Prinzipien

1 2 3 4 5

Trennung von Integration und Analyse Ownership der DWH-Applikationen Management der Datenqualität Korrekturen und Anpassungen Kapselung von Datenzugriffen über Schichten hinweg Prinzipien der 6 Logische Integration der Quelldaten in zentral verIntegrationsschicht waltete Schemata Prinzipien der 7 Wiederverwendbare komplexe Logik in ApplikatioAnreicherungsschicht nen der Anreicherungsschicht 8 Unabhängige Applikationen der Anreicherungsschicht Prinzipien der 9 Unabhängige Data Marts Analyseschicht 10 Private Data Marts

328

4


Die DWH-Applikationsplattform

4.1 Komponenten der DWH-Applikationsplattform Die DWH AP bietet eine Auswahl vorintegrierter Komponenten, die für den Einsatzzweck angepasst und zugeschnitten sind. Diese Komponenten wie auch ihr Zusammenspiel sind standardisiert. Dies bedeutet, dass es nicht ohne weiteres möglich ist, Komponenten miteinander auszutauschen. Die technische Basis der DWH AP stellen die Hardware (für Bereichsdatenbanken und Data Marts) sowie der Einsatz von Unix als Betriebssystem sicher. In allen Schichten wird das gleiche relationale Datenbankverwaltungssystem verwendet; ein zusätzliches multidimensionales DBMS für die Analyseschicht ist im Aufbau. Weitere typische DWH-Werkzeuge sind das ETL-Werkzeug und die Analysewerkzeuge. Darüber hinaus werden Standardkomponenten für das Scheduling und die Sicherheitsadministration (Benutzerverwaltung, Vergabe von Rollen und Rechten) eingesetzt. Metadatenverwaltung und Datenqualitätssicherung verwenden sowohl entsprechende Funktionen des DBMS und des ETL-Werkzeuges als auch selbstentwickelte Komponenten; beide werden derzeit (2007) einem Redesign unterzogen. 4.2 Plattformprozesse In der Prozesssicht der DWH AP sind Plattformprozesse definiert, um die systematische Weiterentwicklung der DWH AP zu gewährleisten. Hierzu gehört ein Requirements-Management-Prozess, der die Erhebung und Priorisierung von Anforderungen an die Plattform regelt. Der Release-Management-Prozess regelt die Definition, Implementierung und Einführung von neuen Plattform-Releases. Auf der Plattformebene werden zudem Betriebsprozesse implementiert, d. h. Prozesse, die den Betrieb der ganzen Plattform betreffen. Dazu gehören die folgenden Prozesse: x Monitoring-Prozesse regeln die Überwachung der Plattform und ihrer Applikationen; x Prozesse des Performance- und Kapazitäts-Managements regeln die mittel- und langfristige Verwaltung von Ressourcen sowie die (kurzfristige) Sicherstellung der geforderten Performanz; x BCP-Prozesse (Business Continuity Planning) umfassen alle Maßnahmen, die der Sicherstellung der Wiederanlauffähigkeit in einem Katas-


329

trophenfall dienen, wie auch die tatsächliche Durchführung dieser Aktivitäten. Bei diesen Prozessen ist zu beachten, dass sie auf Plattformebene definiert, implementiert und durchgeführt werden. Applikationen werden also von diesen Aufgaben befreit. Für die Implementierung von Applikationen sind Entwicklungsprozesse definiert. Beim Bau einer neuen Applikation wird ein neuer Data Mart entwickelt; die auf dem Data Mart basierende analytische Applikation wird im Anschluss daran implementiert (also z. B. Reports). Für das Laden des Data Marts wird ein ETL-Prozess festgelegt, der die benötigten Daten aus den Bereichs- und/oder Anreicherungsdatenbanken extrahiert, transformiert und in den Data Mart lädt. Sind noch nicht alle verfügbaren Daten in den Bereichsdatenbanken vorhanden, müssen diese Daten aus den jeweiligen Quellen neu erschlossen und in die entsprechende Bereichsdatenbank integriert werden. Weiterhin existiert eine Reihe von Prozessen, die regeln, wie eine Applikation in Produktion gebracht und betrieben werden kann. Diese Prozesse dienen u. a. Aufgaben aus den Bereichen Test- und Change Management, Software-Verteilung sowie Deployment- und Sicherheitsadministration. 4.3 Dokumentation und Beratung innerhalb der DWHApplikationsplattform Dokumentation und Beratung bilden neben Komponenten und Prozessen die dritte Säule der DWH AP. Zielsetzung der Dokumentation ist es, Applikationsentwicklern die Umsetzung von Applikationen auf eine möglichst standardisierte Art und Weise zu erleichtern. Die Dokumentation umfasst eine Beschreibung der DWH AP und ihrer Referenzarchitektur sowie weitergehende Standards und Richtlinien, z. B. zur Regelung der Verwendung einzelner Komponenten. Neben der Dokumentation werden Mitarbeiter in Applikationsentwicklungsprojekten beratend durch Architekten und so genannte "End-to-End Consultants" begleitet und unterstützt. Wie oben bereits beschrieben, existieren für alle Applikationsplattformen in der Credit Suisse – so auch für die DWH AP – eine Strategie als auch eine Roadmap. Die Strategie legt unter anderem fest, welche neuen Funktionen oder Technologien in standardisierter Form von der DWH AP angeboten werden sollen. In diesem Zusammenhang stellt beispielsweise OLAP eine funktionelle Erweiterung dar, die in naher Zukunft stärker und in standardisierter Form unterstützt werden wird. Mit der Einführung dieser neuen Funktionalität geht wiederum eine Konzeptualisierung (wann

330


wird diese Funktionalität eingesetzt) und Standardisierung (welches Produkt wird wie verwendet) einher. Als weitere strategische Aktivität wird die Abklärung des Bedarfs nach "Near Real Time Warehousing" betrachtet, d. h. die zeitnahe Integration von Daten aus ausgewählten Datenquellen und die Verwendung dieser Daten in Analysen.

5

Informationslogistik am Beispiel von Geschäftsprozessen der Credit Suisse

Nach Vorstellung des Konzepts der Applikationsplattformen sowie im speziellen der DWH-Referenzarchitektur als Grundlage wird in diesem Abschnitt anhand ausgewählter Geschäftsprozesse aus dem Legal & Compliance Bereich der informationslogistische Ansatz der übergreifenden Datenflüsse der Credit Suisse in Bezug auf die Architektur illustriert. Zuvor wird das hierfür verwendete Visualisierungsinstrument erläutert, in dem orthogonal zum Prozessablauf die zugehörigen Applikationen und Geschäftseinheiten dargestellt sind. 5.1 Softwarekartographie als Darstellungsinstrument von Anwendungslandschaften Die folgenden Darstellungen der Prozessabläufe basieren auf einem von (Lankes et al. 2005) vorgestellten Visualisierungskonzept. Eine Applikation wird hierbei rechteckig dargestellt, ihre Größe hängt sowohl von den durch sie unterstützten Prozessschritten als auch den Organisationseinheiten ab, die die Applikation verwenden: Im fiktiven Beispiel aus Abb. 2 greifen die Organisationseinheiten A und B bei der Ausführung der Prozessschritte A1 bis A3 auf die Applikation „CRM System A“ zurück. Für eine umfassende Darstellung aller relevanten Datenflüsse (als Pfeile symbolisiert) werden neben den zur Ausführung der einzelnen Prozessschritte benötigten Applikationen die erforderlichen Bereichsdatenbanken des Data Warehouse sowie die Data Marts in den Prozessunterstützungskarten eingetragen. Da die Bereichsdatenbanken und das Mainframe-System mit Kunden-, Konto- und Transaktionsdaten von vielen Organisationseinheiten verwendet werden, kann in diesen beiden Fällen keine eindeutige organisatorische Zuordnung erfolgen. Aus diesem Grunde bleibt eine organisatorische Zuordnung der beiden Komponenten in den nachfolgenden Abbildungen aus. Zudem werden einer übersichtlicheren Darstellung wegen die Bereichsdatenbanken und das Mainframe-System keinen einzelnen Prozessschritten sondern global dem gesamten Prozess zugehö-


331

rig dargestellt. Applikationen werden in den Abbildungen zusätzlich mit dem Kürzel der zugehörigen Applikationsplattform (s. o.) versehen.

Abb. 2. Beispiel einer Prozessunterstützungskarte mit Geschäftseinheiten (Lankes et al. 2005, S. 10)

5.2 Formalitätenkontrolle Die Formalitätenkontrolle (FoKo), die organisatorisch dem Legal & Compliance Department der Credit Suisse zugeordnet ist, überprüft die Einhaltung sämtlicher formeller Vorschriften eines Geschäftsvorfalls gemäß der „Vereinbarung über die Standesregeln zur Sorgfaltspflicht der Banken“ (VSB). Abb. 3 stellt den Prozess der Formalitätenkontrolle mit den erforderlichen Applikationen dar. Beispielsweise stellen die Eröffnung eines Kontos und die damit verbundene Eröffnung einer Kundenbeziehung einen Geschäftsvorfall dar. Dies erfolgt durch den Kundenberater (Relationship Manager – RM): Mit der Applikation „RM Portal“ wird in der Datenbank für die Verwaltung der Kundenstammdaten ein neues CIF (Customer Information File) mit den gewünschten Produkten (z. B. Konto) angelegt. In der darauf folgenden Tagesendverarbeitung werden diese Kundenstammdaten via Batchprozess an die Applikation FCC (Formality Control Centre) Portal übertragen und für jedes neue CIF automatisch ein Geschäftsvorfall erstellt. Parallel hierzu schickt der Kundenberater die vom Kunden unterzeichneten Verträge und Dokumente physisch an die Formalitätenkontrolle. Sobald

332


die Formalitätenkontrolle die Dokumente zur Prüfung erhalten hat, wird dieser Geschäftsvorfall im FCC Portal bearbeitet. Dabei wird geprüft, ob für die ausgewählten Bankprodukte alle erforderlichen Formulare und Dokumente eingereicht worden sind und ob diese korrekt und vollständig ausgefüllt worden sind. Dieser Arbeitsschritt erfolgt manuell, wobei die Ergebnisse inkl. allfälliger Mängel im FCC Portal dokumentiert werden.

Abb. 3. Prozessunterstützungskarte mit Geschäftseinheiten für FoKo

Entdeckt beispielsweise ein FoKo-Mitarbeiter, dass für eine bestimmte Kontoeröffnung noch eine Kopie des Personalausweises des Kunden erforderlich ist, wird im FCC Portal zu diesem Geschäftsvorfall ein Mangel "Dokument Personalausweiskopie fehlt" erfasst. Wenn Mängel aufgetreten sind, wird der Geschäftsvorfall an den Kundenverantwortlichen zur Bearbeitung zurückgegeben. Der Kundenberater kann in seinem gewohnten Arbeitsumfeld mittels des RM Portals in einem speziellen Bereich (View) seine offenen Geschäftsvorfälle betrachten und entsprechend nachbearbeiten. Sobald alle Mängel korrigiert bzw. die fehlenden Unterlagen beim Kunden eingefordert worden sind, werden diese wieder an die Formalitätenkontrolle zurückgesendet. Wenn nach einer erneuten Prüfung keine Mängel mehr bestehen, wird der Geschäftsvorfall geschlossen und alle dazugehörigen Dokumente archiviert. Sollte der Fall innerhalb einer bestimmten Frist nicht bearbeitet und abgeschlossen sein, wird der Vorgesetzte automatisch per E-Mail über den Vorgang informiert. Der Vorgesetzte des Kundenberaters hat zudem die Möglichkeit mittels spezieller


333

Reports den Stand offener Geschäftsvorfälle seiner Mitarbeiter zu überwachen. Hierfür stehen ihm zum einen Detailauswertungen zur Verfügung. Zum anderen kann via Management Portal ein „Summary Report“ auf beliebiger organisatorischer Stufe erstellt werden. Via Drill Down-Funktionalität können die kritischen Bereiche dann ad hoc im Detail analysiert werden. Beide Arten von Auswertungen basieren auf dem gleichen Data Mart, der wiederum die relevanten Daten aus den entsprechenden Bereichsdatenbanken des Data Warehouse bezieht. Konkret werden im vorliegenden Fall Kundendaten vom Mainframe sowie die GeschäftsvorfallDaten aus der FCC Applikation im Rahmen der Tagesendverarbeitung als Batchprozess an die Bereichsdatenbanken inkl. zugehöriger Formulare und Mängel weitergeleitet und dort entsprechend geladen. 5.3 Anti Money Laundering (AML) Neben der Erfüllung der Geldwäscherei Verordnung (GwV) der Eidgenössischen Bankenkommission (EBK) hat sich die Credit Suisse zum Ziel gesetzt, Fälle der Geldwäscherei, die dem Ansehen der Bank schaden könnten, abzuwehren (Anti Money Laundering – AML). Hierfür wird eine Standardsoftware eingesetzt, die die im Data Warehouse gesammelten Transaktionsdaten mit Hilfe von Techniken wie Text Mining oder Sequence Matching auf verdächtige Transaktionen hin untersucht (mit Applikation AML Backend – siehe Abb. 4). Als verdächtig werden Szenarien betrachtet wie z. B. Transaktionen in hochriskante Regionen, Änderungen des Kundenverhaltens (Abweichungen gegenüber früherer Verhaltensmuster) oder schnelle Finanzmittelflüsse (Ein- und Auszahlung in sehr kurzem Abstand). Die Applikation erkennt solche verdächtigen Konstellationen und erzeugt entsprechende Alerts. Diese werden vom Compliance Officer des Legal & Compliance Departments im Frontend der Applikation weiter analysiert. Hierzu werden im Frontend alle relevanten Daten zum Auslöser des Alerts (z. B. Transaktion, Kunde) angezeigt. Der Compliance Officer kann nun entscheiden, ob es sich um einen konkreten Verdachtsfall handelt und entsprechende Maßnahmen ergreifen wie z. B. den Verdachtsfall zur weiteren Abklärung an den zuständigen Kundenberater weiterzuleiten. Erhärtet sich der Verdacht, wird der Verdachtsfall an die Meldestelle für Geldwäscherei überwiesen. Zur Überwachung werden zusätzlich Reports erstellt, die über die Verweildauer offener Alerts sowie über den Status von Alerts (analysiert/bearbeitet) informieren. Diese Reports basieren direkt auf den Daten des Backend der Applikation.

334


Abb. 4. Prozessunterstützungskarte mit Geschäftseinheiten für AML

5.4 Kunden-Nachforschungen Der Kunden-Nachforschungsprozess (Customer Investigation Process – CIP) innerhalb der Credit Suisse liefert detaillierte Informationen über verdächtige Personen, gegen die z. B. durch die Staatsanwaltschaft ermittelt wird. So kann beispielsweise eine Behörde im Rahmen einer Ermittlung gegen eine Person entsprechende Auskünfte hinsichtlich ihrer Personalien, ihres Kreditverhaltens etc. bei der Credit Suisse einholen. Deswegen wird dieser teilweise äußerst recherche- und zeitintensive Prozess seit einigen Jahren innerhalb der Credit Suisse durch eine entsprechende Applikation (Investigation Tool) unterstützt, die auf einem Data Mart aufsetzt (Brändli et al. 2004). Die hierfür notwendigen Daten stammen – gemäß den Architekturprinzipien der Credit Suisse – aus den Bereichsdatenbanken (siehe Abb. 5). Die Bereichsdatenbanken werden zum einen mit intern vorliegenden Kundenstammdaten, zum anderen mit externen Daten von Partnern der Credit Suisse, die u. a. als Datenlieferanten fungieren, geladen. Externe Daten umfassen Schweizer Adress- und Unternehmensinformationen, sowie Listen von Einzelpersonen, Unternehmen und Organisationen, die als mögliche Kunden ein hohes Risikopotential für die Bank darstellen. Der Prozess selbst wird von der Abteilung Kunden-Nachforschungen (dem Legal & Compliance Department (L&C) der Credit Suisse angehö-


335

rig) durchgeführt. Interne und externe Anfragen zur Einholung von Informationen über eine bestimmte Person werden bei L&C eingereicht. Mit Hilfe der Applikation werden die für den Prozess relevanten Daten (aus zahlreichen internen und externen Quellen) in einer einzigen Suchmaske abrufbar. Durch eine mächtige Suchfunktionalität („Fuzzy Search“) wird hierbei ermöglicht, dass trotz syntaktisch inkorrekter oder ungenauer Suchanfragen (z. B. „Mueller“ – „Miller“ – „Müller“), dennoch zum jeweiligen Nachforschungsprozess passende und korrekte Suchergebnisse bzw. Informationen geliefert werden. Zur erhöhten Qualität der Suchergebnisse (Hits) trägt auch die parallele Verlinkung der zahlreichen internen und externen Datenquellen bei. Beispielsweise können bei der Suche nach einer Person mit einem geläufigeren Namen, die Hits anhand des Adressverzeichnisses von Mitarbeitern von L&C entsprechend eingeschränkt und eine genaue Zuordnung von Informationen zur angefragten Person festgestellt werden. Nach erfolgter Suche werden die Ergebnisse automatisch zusammengetragen und als Dossier dem Anfragesteller übergeben. Durch den Betrieb dieser Applikation konnten innerhalb des Kunden-Nachforschungsprozesses signifikante Zeitersparnisse sowie eine Verbesserung der Datenqualität der Suchergebnisse realisiert werden (Brändli et al. 2004). Prozess

Anfrage vorbereiten

Anfrage an L&C senden

Extern (z.B. Behörde) oder Intern (z.B. Legal & Compliance)

Namen oder Liste in Tool eingeben

Ergebnisse in Dossier festhalten

Ergebnisse & Beziehungen zueinander prüfen

Massnahmen ergreifen

Dossier

Anfrage

Kunden-Nachforschungen (Legal & Compliance – Shared Services)

Dossier an Anfragenden senden

Investigation Tool

Hosting light

Partner Produkt Portfolio

Data Mart

DWH AP

Externe Partner Ext. Daten

Legende Data Mart

Prozessschritt

Dokument

Applikation

DBMS (DWH etc.)

Ext. Daten

Externe Daten

Mainframe

Operative Kundenstammdaten

Abb. 5. Prozessunterstützungskarte mit Geschäftseinheiten für Kunden-Nachforschungsprozess

336

6



Die Koordination von Datenflüssen über verschiedene Betrachtungseinheiten innerhalb eines Unternehmens sowie über Unternehmensgrenzen hinweg stellt eine essentielle Aufgabe sowohl für technische als auch fachliche Abteilungen eines Unternehmens dar. Wie aus dem vorliegenden Artikel ersichtlich wird, greifen Unternehmen hierfür beispielsweise auf bewährte Datenintegrationslösungen, z. B. ein zentrales Data Warehouse in Form einer Hub and Spoke-Architektur zurück. Ferner zeigt der Artikel, dass die Koordination unternehmensweiter Datenflüsse einen hohen Stellenwert innerhalb der IT-Strategie der Credit Suisse eingenommen hat. Die Architekturprinzipien 6 und 9 (vgl. Abschn. 3.2), durch die der Betrieb isolierter bzw. voneinander abhängiger Data Marts unterbunden wird, machen dies deutlich. Die vorgestellten Beispielprozesse haben das Ausmaß unternehmensweiter Datenflüsse innerhalb der Credit Suisse dargelegt. So wird eine Vielzahl von Geschäftsprozessen der Division „Private Banking“ durch das Legal & Compliance Department in Form von zentralen Dienstleistungen und Analysen von Daten, die aus dem operativen Tagesgeschäft stammen (z. B. Kunden-, Konten-, Transaktionsdaten), unterstützt. Der hohe Reifegrad der Informationslogistik-Architektur der Credit Suisse wird durch moderne Erweiterungsformen wie beispielsweise eine Active Warehousing Komponente, die z. B. beim Kampagnenmangement Analyseergebnisse in operative Systeme zurückschreibt, unterstrichen. Ebenso ist eine Erhöhung der Aktualität gewisser Datenbestände durch entsprechende „Near-Real-time“ Mechanismen und Komponenten angedacht. Ein Konzept mit einer konkreten Bedarfsanalyse hierfür innerhalb der Credit Suisse ist in naher Zukunft geplant.

Literatur Ariyachandra, T. R.; Watson, H. J.: Data Warehouse Architectures: Factors in the Selection Decision and the Success of the Architectures, Athens 2005. Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice, 2. Aufl., Addison-Wesley, Boston 2003. Bauer, A.; Günzel, H.: Data Warehouse Systeme - Architektur, Entwicklung, Anwendung, 2. Aufl., dpunkt.verlag, Heidelberg 2004. 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.


337

Credit Suisse: Geschäftsbericht der Credit Suisse Group, 2006. Inmon, W. H.: Building the Data Warehouse, 3. Aufl., Wiley, New York 2002. Lankes, J.; Matthes, F.; Wittenburg, A.: Softwarekartographie: Systematische Darstellung von Anwendungslandschaften, in: Ferstl O. et al. (Hrsg.): Proceedings der 7. Internationalen Tagung Wirtschaftsinformatik, Physica, 2005, S. 1443-1462. Moormann, J.: Die Rolle der Informatik im Bankgeschäft, in: Moormann J. (Hrsg.): Handbuch Informationstechnologie in Banken, 2. Aufl., Gabler, Wiesbaden 2004, S. 1-17. Tresch, M.; Jonscher, D.: Evolution not Revolution: The Data Warehouse Strategy at Credit Suisse Financial Services, in: Dittrich K. R. et al. (Hrsg.): Proceedings of the 13th Conference on Advanced Information Systems Engineering, Springer, Interlaken 2001, S. 36-45.

Autorenverzeichnis

Barbara Binzegger Ruoss Credit Suisse, Legal & Compliance IT P.O. Box 600, CH-8070 Zürich [email protected], www.credit-suisse.com 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 Dr. Andreas Geppert Credit Suisse, Technology Infrastructure Services P.O. Box 600, CH-8070 Zürich [email protected], www.credit-suisse.com 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 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

340

Autorenverzeichnis

Peter Lutz Hotelplan AG Internationale Reiseorganisation Sägereistr. 20, CH-8152 Glattbrugg [email protected], www.hotelplan.ch Dirk Meyer E.ON AG, F/IT 1 - Application Management E.ON-Platz 1, D-40479 Düsseldorf [email protected], www.eon.com 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 Thorsten Sommer Volkswagen AG, ITP Kompetenzfeld Business Intelligence Brieffach 011/1802, D-38436 Wolfsburg [email protected], www.volkswagen.de 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 Prof. Dr. Jochen Töpfer Teradata (Schweiz) GmbH Postfach, CH-8301 Glattzentrum [email protected], www.teradata.com

Autorenverzeichnis

341

Uwe Trost Steria Mummert Consulting AG, Solution Center Business Intelligence Mainzer Landstraße 209, D-60326 Frankfurt [email protected], www.steria-mummert.de 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 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 Dr. Birgit Wendlandt Volkswagen AG, ITP Kompetenzfeld Business Intelligence Brieffach 011/1802, D-38436 Wolfsburg [email protected], www.volkswagen.de 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 Dr. Martin Zirkel Steria Mummert Consulting AG, Solution Center Business Intelligence Domagkstr. 34, D-80807 München [email protected], www.steria-mummert.de

Sachverzeichnis

A

B

Abrechnungsmodell 234 Abusus 58 Active Data Warehouse 153 Adaption 30 Agent 45, 48 Agenturtheorie 45, 47 Aggregation 177, 178 Agilität 23, 176 Akteur 49 Aktivitätsdiagramm 304, 307 Aktualität 140, 239 Alignment 13, 28, 175, 176, 177 Allokation 40 Analyse 264 Analyselatenz 180 analytische Nutzung 3 Anreizsystem 46 Anspruchsgruppe 22 Anti Money Laundering 333 Antwortzeit 239 Applikationsplattform 320, 321 Architektur 138 Architekturprinzip 325 Architekturrichtlinie 293 Architekturtyp 146 asymmetrische Informationsverteilung 45 Attribut 225 Aufgabe 222 Aufgabenstrukturierung 20 Aufgabenverteilung 88 Auszahlungsmatrix 50, 51

Balanced Scorecard 77, 266 Basel II 179 Bereichsdatenbank 324 Bereinigungswerkzeug 226 Betrachtungseinheit 2, 3 Betriebswirtschaftslehre 19 BI-Applikationen 277 BI-Balanced Scorecard 274 BI-Competence Center 273, 275 BI-Governance 273, 274 BI-Landschaft 263, 264, 270 BI-Master Construction Plan 272 BI-Plattform 270, 277 BI-Programm 270, 278, 280 BI-Service 270 BI-Strategie 69, 262, 263, 269, 271, 274, 278 – Implementierung der 265 – Ziele der 268 BI-Strategieentwicklung 265 BI-Systeme – Betrieb von 277 Bonitäts-Score 175 Business Activity Monitoring 113 Business Case 178 Business Engineering 18, 19, 21, 24, 35, 217 – Gegenstand des 24 – Modelle des 25 – Vision des 23 Business Engineering-Landkarte 21 Business Impact Assessment 183

344

Sachverzeichnis

Business Intelligence 6, 33, 262, 267 Business Performance Management 113 Business Process Automation 33 Business Service Provider 94 Business-Basics 295 Business-IT-Alignment 267 Business-Metamodell 26, 33 C Change Management 19, 183, 278 Change the Business 21 Closed Loop 271 Clusteranalyse 90 Common Warehouse Metamodel 204 Competitive Potential Alignment 66 Compliance 179 Corporate Performance Management 32 Credit Suisse 319 Cross-Selling 175 D Data Governance 217, 222, 223 Data Governance Council 215 Data Management Body of Knowledge 215 Data Mart – Busarchitektur 147 – unabhängige 147 Data Warehouse 5, 83, 84, 168, 270 – Betrieb 87 – Entwicklung 86 – Nutzung 86 – Support 88 Data Warehouse Application Platform 321 Data Warehousing 5, 83, 85, 231, 232 Data-Governance-Komitee 223 Data-Warehousing-Prozess 83 Datenarchitektur 217, 225, 226 Datenfluss 2, 3, 212, 226

Datenhaltungssystem 226 Datenintegration 189 Datenlatenz 180 Datenmanagement 214, 276 Datenmanagementprozess 224 Datenmodell 199 Datenobjekt 225 Datenqualität 138, 140, 178, 211, 212, 213 – Kosten von 219 – Messen von 220 – Nutzen der 220 – Verbesserung 226 – Ziele der 219 Datenqualitätsmanagement 214, 215, 224 – Nutzen des 219 – Systemunterstützung 226 Datenqualitätsproblem 220 Datenqualitätssicherung 85 Datenqualitätsstrategie 217, 218 Datenqualitätsziel 220 Datenquelle 85, 195 Datensteward 223 Decision Support Systems 7 Defektion 51 Delivery-Strategie 72 Design 264 detaildatenbasierte Massenkalkulationen 175 Dimensionsdaten 178 Distributionsform 238 DWH Competence Center 97, 231, 294 DWH Platform Provider 96 DWH-Applikation 85 DWH-Applikationsplattform 328, 329 DWH-CC 98, 232 DWH-FSP 92 DWH-Informationssystem 85 DWH-Integrationsinfrastruktur 85 DWH-Leistungserbringer 88 DWH-Leistungserbringertypen 92 DWH-Organisation 83 DWH-PP 96

Sachverzeichnis DWH-Referenzarchitektur 325 E E.ON AG 285 Effektivität 22 Effizienz 22 Einzelhandel 220 empirische Untersuchung 88, 116 Energiedienstleister 285 Energiemarkt 289 Enterprise Application Integration 154 Entkopplung 25 Entkopplungsmechanismus 25 Entscheidung 175 Entscheidungsfindung 314, 315 Entscheidungslatenz 180 Entscheidungsprozess 175 Entscheidungspunkte 304 Entscheidungssituation 49 Entscheidungsunterstützung 2, 3, 262 Entwicklungsmodus 18 Entwicklungsstrategie 73 Entwurfsverfahren 30 Erfolgsfaktor 172, 281 Erneuerung 18 ETIL 291 eventgesteuerte Aktivität 174 Excellence Team Information Logistics 291 Executive Information Systems 7 Externalität 58 F Fachbegriff 199 fachliches Verständnis 194 Fertigungstiefe 91, 101 Finanzierung 144 Flexibilität 23, 143, 239 Föderierte Architektur 150 Formalitätenkontrolle 331 Formalziel-Dimension 23 Framework 297

345

Framework Information Logistics 291 Führungsgröße 220 Führungsinformationssysteme 7 Führungssystem 217, 220 Full Service Provider 92 Funktion 232, 237 Funktionalität 238 G Gefangenendilemma 49 Gegenstand 237 Gemeinkostenproblematik 232 Geschäftsbegriff 203 Geschäftsbereich 2 Geschäftseinheit 19 Geschäftsnähe 91, 101 Geschäftsprozess 169, 224, 271 Geschäftsregel 199 Gestaltungselement 216 Gestaltungsfaktor 119, 130 Gestaltungsmethode 24 Gestaltungsobjekt 24, 25, 33 – Lebenszyklus des 24, 25 Gravitationszentrum 270 H Handlungsrecht 57 Hidden Action 46 Hidden Information 46 Hierarchie 40 Holdup 41 Homonym 226 Horizontale Informationsintegration 145 Hotelplan Swiss Group 129, 300, 313 Hub and Spoke-Architektur 149 I IL-Governance 294 IL-Infrastruktur 168 IL-Leitbild 77 IL-Masterplan 78

346

Sachverzeichnis

IL-Methodik 296 IL-Projekte 168 IL-Strategie 67 Information 3, 85, 213, 232, 235, 237 Information Excellence 291 Informationsbedarf 167, 185 Informationslogistik – prozessorientierte 313 Informationslogistik 2, 12, 32, 35, 63, 83, 84, 107, 108, 109, 113, 167, 231, 262 – Abgrenzung 5 – Aufgaben der 5 – Betrachtungseinheiten der 2 – Gestaltung der 48, 52, 59 – Koordination der 43 – Nutzen der 168, 170 – prozessorientierte 108, 113, 115, 116, 118, 122, 126, 129, 299 – Synergiepotenziale der 8 – Vorteilhaftigkeit der 47, 51, 54, 59 – Wertbeiträge der 173 – Ziele der 5 Informationslogistik-Projekte 168 – Bewertung von 170 – Eigenschaften von 168 Informationslogistik-Strategie 63 Informationsmanagement – integriertes 69 Informationsobjekte 236 Informationsprodukt 232, 236 Informationsproduktion 235, 236, 240 Informationsproduktionsmodell 243 Informationsproduktionsprozess 241 Informationsproduktmodell 236 Informationsqualität 138 Informationsversorgung 108, 123, 127, 291 informatorische Unterstützung 303, 309, 310, 311, 313, 315 Infrastruktur 9, 12, 181, 232

Infrastruktur- und Betriebsaspekte 321 Infrastrukturcharakter 9, 169 Infrastrukturkosten 181 In-Memory Analytics 155 Integrationsebene 25 Integrationsgrad 123 Integrationsinfrastruktur 231 integriertes Energieunternehmen 286 Internalisierung 59 Internes Leistungsmodell 234 Ist-Analyse 248 IT / Business Alignment 66 IT-Architektur-Management 272 IT-Basics 295 IT-Innovation 21 IT-Strategie 64, 267 Ius abutendi 58 K Kausalanalyse 116 Kennzahl 184, 185, 221 Kennzahlensystem 262, 271 Key Performance Indicator 265 klassisches Vertragsrecht 40 Kommunikation 279 Kommunikationskonzept 278 Konsistenz 23, 25, 141 Konstruktionslehre 19, 28 Kontextfaktor 31 Kontexttyp 31 Konzerndatenqualität 214 Kooperation 47, 51 Kooperationsanreiz 52 Koordinationsform 44 Kosten 168, 231 Kostenund Leistungsrechnungssystem 235 Kosteneffekt 178 Kosteneinsparung 171, 181 Kostenschätzung 185 Kostensenkung 169, 171, 178 Kundenbeziehung 174

Sachverzeichnis Kunden-Lieferanten-Beziehungen 93 Kundenmanagement 212 Kunden-Nachforschungen 334 Kundenorientierung 173 Kundenschnittstelle 249 L Last-Minute-Reiseangebot 129, 302, 304, 314 Latenzzeit 179 Leistung 232 Leistungs- und Kostenmodell 252 Leistungserbringer 91 – Typen 91 Leistungserbringertyp 101 Leistungsverrechnung 232, 233, 234, 235 – Elemente der 234 – Ziele der 233 Lieferfähigkeit 181 M Management Information Systems 7 Management Support Systems 7, 8 Marktsegmentierung 175 Marktstruktur 55 Merkmals-Modellierung 200 Messbarkeit 43 Metadaten 199 Meta-Programmierung 200 Methode 28, 29, 232, 245 – Konstruktion von 31 – situative 31 Methodenbasierung 19 Methoden-Engineering 30 Mission 264, 268 Modell 28, 190, 195 Modellbasierung 19 Modellevolution 190 Modellintegration 190 Modelltyp 26

347

N Nash-Gleichgewicht 50 neoklassisches Vertragsrecht 40 Netzeffekt 52, 55 – direkt 53 – indirekt 53 Netzwerk 52 Netzwerktheorie 52 Nutzen – Bewertung von 168, 183 Nutzenbetrachtung 168 Nutzeneffekt 52, 116, 118 Nutzenkategorie 171 Nutzenmaximierung 40, 45 Nutzenpotenzial 169, 182 – Bewertung von 184 – Prognose von 185 O Operational Business Intelligence 115 Operational Data Store (ODS) 154 opportunistisches Verhalten 40, 42 Optimierung 18 Ordnungsrahmen 215, 216 Organisation 17, 22, 40, 297 Organisationsebene 21 Organisationseinheit 2 Organisationsform 40, 99, 101 – Auswahl der 101 organisatorische Einbettung 182 Outsourcing-Partner 101 P Parametrisierung 200 Pareto-Optimum 50 Partikularsicht 13 Performance Management 33 Performanz 142 Personalkosten 144, 181 Planung 254 Planungssystem 64 Plattformleistungen 243 Plattformprozesse 328

348

Sachverzeichnis

Politisch-kulturelle Ebene 21 Portfoliostrategie 73, 101 Preis 232 Preismodell 234 Prinzipal 45, 48 Prinzipal-Agenten-Theorie 45 Process Performance Management 33 Produkt 232, 234, 235 Produkt- und Preisgestaltung 304, 307, 309, 312, 314, 315 Produktionsprozess 232 Produktionsstrategie 74 Projektcontrolling 184 Projektfaktor 31 Projektkennzahl 185 Projekttyp 24, 31 Property-Rights-Theorie 57 Prozess 17, 21, 85, 108, 127, 232, 236, 302, 311 Prozessausführung 303, 309, 313 Prozesscharakter 9, 11 Prozesslandschaft 127 Prozessleistungen 243 Prozessmanagement 107, 111 Prozessmodellierung 33 Prozessoptimierung 171, 172 Prozessorganisation 107, 109 prozessorientiertes Unternehmen 262 Prozessorientierung 108, 109, 113 Q Qualität 237 Qualitätsmanagement 269 R Rationalität – beschränkte individuelle 40 Realisierungsform 122, 125, 130 Real-Time Analytics 33 Real-Time Data Warehousing 154 Referenzarchitektur 320 Referenzdaten 200 Reifegradmodell 264

relationaler Vertrag 40 Reputationseffekt 49 Ressourcen 144 Richtigkeit 238 Risikofaktor 12 Risikomanagement 179 Risikoneigung 45 Roadmap 280, 281 Rolle 88, 222 S Sachziel 23 SAP NetWeaver Visual Composer 130, 312, 315 Sarbanes-Oxley-Act 179 Screening 46 Service 231 Service Level Alignment 66 Sicherheit 144 Signaling 46 Single Vendor-Strategie 265 Situationsanalyse 76 Softwarekartographie 330 Solvency II 179 Sourcing-Strategie 71, 101 Spieler 49 Spieltheorie 49 St. Galler Anwenderforum 89 St. Galler Managementmodell 17, 20 Stammdaten 201, 224 – Sicht 226 Stammdatenmanagement 227 Standard 293 Standardisierung 18, 19, 54 Standardisierungskosten 54 Standardisierungsnutzen 54 Stelle 2 Strategic Alignment Model 65 Strategie 64, 321 Strategieebene 20 Strategieentwicklung 78, 263 Strategieentwicklungsprozess 75, 263 strategische Bedeutung 144

Sachverzeichnis strategische Planung 64, 265 strategische Zielplanung 76 strategischer Charakter 9, 11 strategischer Erfolgsfaktor 261 strategischer Wettbewerbsvorteil 171, 172 Strategy Execution Alignment 66 Strategy Map 77, 268 Struktur 237 strukturelles Beschreibungsmerkmal 194 Supportprozess 236 Synonym 226 System 85 Systemarchitektur 138, 169, 226 Systemebene 21 Systemqualität 138, 142 Systems Engineering 19 T Technologiebeobachtung 19 Technology Transformation Alignment 66 Teilstrategien 265 Teradata 183 Theorie der Verfügungsrechte 57 tit-for-tat-Strategie 51 Total Data Quality Management 214 Total Information Quality Management 215 Total Quality data Management 215 Transaktionsbedingung 41 Transaktionskosten 41 Transaktionskostentheorie 40 transaktionsspezifische Investition 42 Transparenz 23, 29, 142 U Umlageverfahren 235 Unternehmen 167 Unternehmensnetzwerk 40 Unternehmenssteuerung 212 Unternehmensstrategie 218, 267

349

Unternehmung 17, 19 Usus 58 Usus fructus 58 V Veränderung 18, 19, 22 – Aufgaben der 19, 20 – Ergebnis der 22 – Gegenstand der 24 – Ziel der 22, 23 Veränderungsmethode 24 Veränderungsprojekt 20 – Scheitern von 29 Veränderungsprozess 22, 28 – Typen des 28 Veränderungsvorhaben 19, 20, 23 Verantwortlichkeit 222 Verantwortlichkeitsdiagramm 223, 224 Vereinfachung 23 Verfügbarkeit 143 Verfügungsrecht 57, 58 Vernetzungsfähigkeit 18 Vertikale Informationsintegration 145 Verwendungsform 146 Virtuelle Architektur 152 Vision 76, 264, 268 Volkswagen 261, 262, 278 Vollständigkeit 141, 238 Vorgehensmodell 125, 245 W Wertebereich 226 Wertschöpfung 9 Wertschöpfungsnetzwerk 18 Wiederverwendung 197 Wirtschaftlichkeitsbetrachtung 168 Wirtschaftlichkeitsziel 22 Z Zentralisierte Architektur 148 Zielentwicklung 265 Zielsystem 265

350

Sachverzeichnis

Zielwert 185, 220 Zugänglichkeit 239

Zuständigkeit 222 Zuverlässigkeit 239

Integrierte Informationslogistik (Business Engineering)

Integrierte Produkt- und Prozessgestaltung

Leitfaden Integrierte Kommunikation

Business Engineering in der Praxis (Business Engineering) German

Engineering, Business & Professional Ethics

Engineering business systems in Eiffel

Elektronische Beschaffung: Stand und Entwicklungstendenzen (Business Engineering)

Presentation Graphics for Engineering, Science and Business

Engineering for Business Theory and Cases

Integrierte Lean Balanced Scorecard: Methoden, Instrumente, Fallbeispiele

Integrierte Personalentwicklung: Ein systematisch mitarbeiterorientierter Ansatz

Active Enterprise Intelligence: Unternehmensweite Informationslogistik als Basis einer wertorientierten Unternehmenssteuerung

Business

Integrierte Informationsverarbeitung 1: Operative Systeme in der Industrie, 17.Auflage

Integrierte Unternehmensführung: Festschrift zum 65. Geburtstag von Professor Claus Steinle

Business to Business Marketing

Serviceorientiertes IT-Management: ITIL-Best-Practices und -Fallstudien (Business Engineering)

Business, Marketing, and Management Principles for IT and Engineering

Project Management for Engineering, Business, and Technology, 4th Edition

Project Management for Business, Engineering, and Technology, Third Edition

Integrierte Informationsarchitektur: Die erfolgreiche Konzeption professioneller Websites (X.media.press)

Organisationskommunikation in Krisen: Reputationsmanagement durch situative, integrierte und strategische Krisenkommunikation

Project Management for Business and Engineering, : Principles and Practice

Business Engineering Navigator: Gestaltung und Analyse von Geschäftslösungen >>Business-to-IT

Integrierte Raum- und Eisenbahnentwicklung am Hochrhein und Oberrhein German

Integrierte Schadenanalyse: Technikgestaltung und das System des Versagens, 2.Auflage

Leitfaden Integrierte Kommunikation - Wie Web 2.0 das Marketing revolutioniert GERMAN

Business Studies - Business Around Us

Understanding Business: Markets (Understanding Business)

Clinical Engineering Handbook (Biomedical Engineering)

Modern Control Engineering (Control Engineering)

Integrierte Informationslogistik (Business Engineering)

Integrierte Produkt- und Prozessgestaltung

Leitfaden Integrierte Kommunikation

Business Engineering in der Praxis (Business Engineering) German

Engineering, Business & Professional Ethics

Engineering business systems in Eiffel

Elektronische Beschaffung: Stand und Entwicklungstendenzen (Business Engineering)

Presentation Graphics for Engineering, Science and Business

Engineering for Business Theory and Cases

Integrierte Lean Balanced Scorecard: Methoden, Instrumente, Fallbeispiele

Integrierte Personalentwicklung: Ein systematisch mitarbeiterorientierter Ansatz

Active Enterprise Intelligence: Unternehmensweite Informationslogistik als Basis einer wertorientierten Unternehmenssteuerung

Business

Integrierte Informationsverarbeitung 1: Operative Systeme in der Industrie, 17.Auflage

Integrierte Unternehmensführung: Festschrift zum 65. Geburtstag von Professor Claus Steinle

Business to Business Marketing

Serviceorientiertes IT-Management: ITIL-Best-Practices und -Fallstudien (Business Engineering)

Business, Marketing, and Management Principles for IT and Engineering

Project Management for Engineering, Business, and Technology, 4th Edition

Project Management for Business, Engineering, and Technology, Third Edition

Integrierte Informationsarchitektur: Die erfolgreiche Konzeption professioneller Websites (X.media.press)

Organisationskommunikation in Krisen: Reputationsmanagement durch situative, integrierte und strategische Krisenkommunikation

Project Management for Business and Engineering, : Principles and Practice

Business Engineering Navigator: Gestaltung und Analyse von Geschäftslösungen &gt;&gt;Business-to-IT

Integrierte Raum- und Eisenbahnentwicklung am Hochrhein und Oberrhein German

Integrierte Schadenanalyse: Technikgestaltung und das System des Versagens, 2.Auflage

Leitfaden Integrierte Kommunikation - Wie Web 2.0 das Marketing revolutioniert GERMAN

Business Studies - Business Around Us

Understanding Business: Markets (Understanding Business)

Clinical Engineering Handbook (Biomedical Engineering)

Modern Control Engineering (Control Engineering)

Recommend Documents

Business Engineering Navigator: Gestaltung und Analyse von Geschäftslösungen >>Business-to-IT