Integrierte Informationslogistik — Stand und Entwicklungstendenzen

Integrierte Informationslogistik – Stand und Entwicklungstendenzen Eitel von Maur, Joachim Schelp, Robert Winter Universität St.Gallen Als Konsequenz reger Innovations- und Marketingaktivitäten von Softwareindustrie und Beratung ist die Diskussion integrierter Informationslogistik durch eine Vielzahl sehr unterschiedlicher Konzeptionen und Instrumente dominiert. Da die Besonderheiten jeder Konzeption und jedes Instruments herausgestellt werden, geht mitunter das Verständnis für die konzeptionelle Ähnlichkeit der verschiedenen Integrationsszenarien und der angewandten Lösungsansätze verloren. In diesem Beitrag wird versucht, das Data Warehousing, die Kopplung von Anwendungssystemen (Enterprise Application Integration) und die unternehmensübergreifende Integration (Business Networking) als konzeptionell verwandte Integrationsansätze darzustellen. Dazu werden zunächst die relevanten Beschreibungsebenen identifiziert und die begrifflichen Grundlagen erarbeitet. Danach werden in drei Abschnitten die jeweiligen Integrationsansätze konzeptualisiert, Entwicklungstendenzen zusammengefasst und der aktuelle Forschungsbedarf aus Sicht des Informationsmanagements wird beschrieben. Im abschliessenden Abschnitt wird ein Gesamtkonzept integrierter Informationslogistik skizziert, das die Gemeinsamkeiten der beschriebenen Integrationsansätze verdeutlicht und Hinweise auf Synergien im Informationsmanagement liefert. 1 Einleitung Integration ist ein „Urthema“ der Wirtschaftsinformatik. Bereits in den 70er Jahren des 20. Jahrhunderts wurden mit dem Kölner Integrationsmodell (Grochla 1974) sowie den Arbeiten von SCHEER („Datenbank des Fertigungsbereichs“ (Scheer 1976), später Referenzmodell des Industriebetriebs (Scheer 1995)) und MERTENS (später Referenzmodell des Industriebetriebs (Mertens 1995)) Integrationsansätze mit dem Ziel einer detaillierten, möglichst vollständigen, unternehmensweiten Modellierung von Daten bzw. Funktionen als Grundlage der Entwicklung integrierter Anwendungssysteme erarbeitet. Ende der 80er Jahre des 20. Jahrhunderts erlebte diese Diskussion in Zusammenhang mit unternehmensweiten (Daten-)Modellen (z. B. Scheer, Hars 1992) und computerintegrierter Fertigung (z. B. Scheer 1990; Becker 1991) einen ersten Höhepunkt. Neben rein daten-, datenfluss-, funktions-, prozess-, 4 E. von Maur, J. Schelp, R. Winter methoden- oder programmorientierten Integrationsansätzen (Mertens, Holzner 1992; Ferstl, Sinz 1998, S. 213-225; Mertens 1995, S. 1ff.) wurden Anfang der 90er Jahre des 20. Jahrhunderts Gesamtarchitekturen mit einer Vielzahl von Integrationssichten und -ebenen vorgeschlagen (z. B. ARIS (Scheer 1991), Zachman-Framework (Zachman 1987)). Zur gleichen Zeit standen auch erstmals (CASE-)Werkzeuge zur Verfügung, um derart komplexe Modelle erstellen und warten zu können. Der Euphorie hochintegrierter Gesamtmodelle folgte jedoch bald die Ernüchterung, dass monolithische Integrationsmodelle in komplexen Organisationen nicht mit vertretbarem Aufwand erstellt und insbesondere gewartet werden können. Einerseits fehlten für einige Modelle die dazu notwendigen Verdichtungs- und Verfeinerungsoperationen (Boßhammer, Winter 1995). Andererseits schien die Tendenz zu dezentraler Informationsverarbeitung den Sinn unternehmensweiter Modelle grundsätzlich in Frage zu stellen. Zu dem traditionellen Verständnis der Integration, das auf die Verknüpfung eng gekoppelter Komponenten zu einer – zumindest logischen – Einheit (Mertens 1995, S. 1) hinausläuft, wurde Ende der 80er Jahre des 20. Jahrhunderts eine Alternative entwickelt, die auf die Entkopplung lose gekoppelter Komponenten bei gleichzeitiger Sicherstellung konsistenter Datenversorgung zielt. Der Data-Warehouse-Ansatz (Devlin, Murphy 1988) zielt auf die Schaffung eines zentralen „Hub“ ab, der eine Vielzahl operativer Applikationen (als Datenquellen) mit einer Vielzahl analytischdispositiver Applikationen (als Datennutzer) mit Hilfe einer minimalen Zahl von Schnittstellen verbindet. Das Data Warehouse bildet im Hub-and-Spoke-Konzept ein logisch zentrales, dediziertes Integrationssystem, dass analytisch-dispositiven Applikationen konsistente, integrierte, historisierte Daten verfügbar macht. Die Auseinandersetzung mit Integrationsfragen erfolgt im Informationsmanagement aktuell in mindestens drei unterschiedlichen Bereichen: (Winter 2003a) • Die Aufarbeitung fachlicher Aspekte des Data Warehousing läuft zeitlich versetzt der Entwicklung von Werkzeugen und Technologien nach. Während erste Arbeiten grundsätzliche Aspekte wie z. B. Wirtschaftlichkeitsfragen, Organisationsgestaltung oder Datenqualitätsmanagement adressierten (ein Überblick findet sich in (Jung, Winter 2000b)), arbeiten aktuelle Beiträge (u. a. in diesem Band) Entwicklungen wie z. B. die Nutzung des Data Warehouse zu operativen Zwecken, Fragen der Datensicherheit bzw. des Datenschutzes oder Architekturaspekte auf. • Während das Data-Warehouse-System als Integrationssystem zur effizienten Kopplung operativer Applikationen und analytisch-dispositiver Applikationen dient, werden Techniken zur Kopplung operativer Applikationen untereinander unter dem Begriff „Enterprise Application Integration“ (EAI) zusammengefasst (Linthicum 2000, S. 3-17). Auch in diesem Fall wird ein logisch zentraler „Hub“ geschaffen, durch dessen Nutzung sich bilaterale Schnittstellen zwischen operativen Applikationen erübrigen und nur Schnittstellen zwischen Applikationen und Integrationssystem zu entwickeln bzw. zu unterhalten sind. Integrierte Informationslogistik – Stand und Entwicklungstendenzen 5 Während die Integration durch das Data-Warehouse-System ausschliesslich datenorientiert erfolgt, werden EAI-Systeme je nach Leistungsanforderungen und Art der zu koppelnden Applikationen als Mischform datenorientierter und nachrichten- bzw. ereignisorientierter Komponenten implementiert. • Sowohl Data Warehousing wie auch EAI haben eine explizit unternehmensinterne Ausrichtung. Als dritter Integrationsbereich wird deshalb die Schaffung von Infrastrukturen für die unternehmensübergreifende Integration von Geschäftsprozessen und Applikationen betrachtet, die sog. „Business Collaboration Infrastructure“ (BCI) (Cäsar et al. 2002). Da eine solche Infrastruktur keinem der beteiligten Unternehmen gehört, wird sie in Form von Standards und Web Services, also mit anderen Mitteln als das Data Warehouse-System oder die EAI-Infrastruktur realisiert. In diesem Beitrag werden die aktuellen Entwicklungstendenzen und Forschungsbedarfe dieser drei Integrationsbereiche aus Sicht des Informationsmanagements untersucht. Dazu wird zunächst in Abschnitt 2 ein Modell integrierter Informationslogistik aus Prozess- und Applikationssicht vorgestellt (zur Definition von Prozessund Applikationsebene siehe (Österle, Winter 2000)). In Abschnitt 3 werden der Stand der Forschung im Hinblick auf die Entkopplung operativer und analytischdispositiver Applikationen, die Integration operativer Applikationen und die unternehmensübergreifende Integration beschrieben. Für alle Bereiche wird zudem der absehbare weitere Forschungsbedarf kurz angerissen. Der Beitrag wird in Abschnitt 4 durch eine Zusammenfassung abgeschlossen. 2 Integrierte Informationslogistik aus Prozess- und Applikationssicht Die im Business Engineering zu betrachtenden Gestaltungsebenen (Geschäfts-) „Strategie“, (Geschäfts-)„Prozess“ und (Informations- und Kommunikations-)„System“ (Österle 1995) unterscheiden sich fundamental hinsichtlich der jeweils zu modellierenden Informationsobjekte und Beziehungen. Während auf Strategieebene Produkte, Märkte, Kanäle, Preismodelle, Kundensegmente etc. abzubilden sind, fokussiert die Modellierung auf Prozessebene auf Prozessschritte, Organisationseinheiten, Prozessleistungen, Führungsgrössen etc. Auf Systemebene ist es sinnvoll, zwischen einer Applikationsebene und einer Softwareebene i. e. S. zu unterscheiden. Während die Applikationsebene Informations- und Kommunikationssysteme aus betriebswirtschaftlicher Sicht, d. h. hinsichtlich Funktionalitäten, Datenflüssen, Verantwortlichkeiten etc. beschreibt, dient die Modellierung der Softwaresystemebene der effizienten Strukturierung von Modulen, Nachrichten, Datenelementen etc. (bzw. ihrer konzeptionellen Pendants) aus Sicht der Systementwicklung (Leist, Winter 2000, S. 159-160). 6 E. von Maur, J. Schelp, R. Winter Die meisten der traditionellen Unternehmensmodelle der Wirtschaftsinformatik (z. B. Scheer 1995; Mertens 1995) haben ihren Schwerpunkt auf der Applikationsebene, d. h. beschreiben – teilweise auf Grundlage eines übergeordneten, verknüpfenden Prozessmodells – hauptsächlich Daten und Funktionen von Informationsund Kommunikationssystemen aus fachlicher Sicht. Als Konsequenz wird die Integrationsproblematik traditionell hauptsächlich aus Daten-, Funktions- oder Prozesssicht interpretiert. Um der Komplexität der betrieblichen Realität und dem daraus resultierenden Zwang zu mehrstufiger Modellierung gerecht zu werden, sollten auf jeder Gestaltungsebene Modelle unterschiedlichen Detaillierungsgrades unterschieden werden. Da dieser Beitrag die Integrationsproblematik aus der (aggregierten) Sicht des Informationsmanagements untersucht, werden im Folgenden nur Architekturmodelle (sog. „Modelle der Gesamtheit“ (Winter 2003b)) betrachtet. Das Business Engineering kennt die Geschäftsarchitektur, die Prozessarchitektur und die Applikationsarchitektur. Da Informationsobjekte, der Gegenstand integrierter Informationslogistik, im allgemeinen auf der Strategieebene noch nicht betrachtet werden, erfolgt die folgende Analyse aus Prozess- und Applikationssicht. 2.1 Prozesssicht Unternehmensmodelle, die den Prozessaspekt in den Vordergrund stellen, existieren aus Sicht der Managementlehre (z. B. Rüegg-Stürm 2002) und aus Sicht der Wirtschaftsinformatik (z. B. Scheer 1995). Auf aggregierter Ebene lassen sich dabei auf Grundlage von (Porter 1986) die folgenden Prozesstypen unterscheiden (Österle 1995; Rüegg-Stürm 2002): • Leistungsprozesse (oder Geschäftsprozesse im engeren Sinne) erzeugen Leistungen für Prozesskunden. Der Kundenbegriff schliesst dabei interne Kunden (z. B. andere als die zu modellierende Geschäftseinheit) ein. • Unterstützungsprozesse unterstützen die Leistungsprozesse durch Vorleistungen, d. h. durch Leistungen innerhalb des betrachteten Unternehmens bzw. der betrachteten Geschäftseinheit. • Führungsprozesse koordinieren die Leistungserstellung, d. h. messen die Zielerfüllung von Leistungs- und Unterstützungsprozessen, intervenieren bei Zielabweichungen und entwickeln das gesamte Leistungssystem weiter. Aus Prozesssicht werden EAI und BCI als Integrationsmechanismen betrachtet, wenn verschiedene Komponenten eines Leistungsprozesses miteinander verknüpft werden. Data Warehousing stellt dagegen keine Integration dar, sondern vielmehr eine Verknüpfung von Führungsprozessen und Leistungsprozessen zur Gewährleistung effizienter Informationsflüsse. Integrierte Informationslogistik – Stand und Entwicklungstendenzen 2.2 7 Applikationssicht Unternehmensmodelle, die den Applikationsaspekt in den Vordergrund stellen, existieren aus Sicht der Wirtschaftsinformatik (z. B. Chamoni, Gluchowski 1999, S. 10-13; Winter 2000b, S. 29-36) und der Informatik bzw. Softwareentwicklung (z. B. Zachman 1987). Auf aggregierter Ebene lassen sich dabei die folgenden Applikationstypen unterscheiden: • Operative Applikationen (auch: Administrationssysteme (Mertens 1995, S. 11), operative Systeme (Scheer 1995, S. 5), operative Informationssysteme (Chamoni, Gluchowski 1999, S. 11) unterstützen Leistungs- oder Unterstützungsprozesse unmittelbar (z. B. durch Automatisierung). • Analytisch-dispositive Applikationen (auch: Dispositions-, Planungs- und Kontrollsysteme (Mertens 1995, S. 11-13), Berichts-, Kontroll-, Analyse-, Planungs- und Entscheidungssysteme (Scheer 1995, S. 5), analytische Informationssysteme (Chamoni, Gluchowski 1999, S. 11), entscheidungsunterstützende Applikationen (Winter 2000a, S. 31), Management Support Systeme (von Maur 2000, S. 33-36)) unterstützen Führungsprozesse. Die heterogene Klasse der analytisch-dispositiven Applikationen wird nicht weiter unterteilt, da in der Realität die Trennung zwischen dispositiven Applikationen, Berichts- und Kontrollapplikationen, Planungsapplikationen und analytischen Applikationen zunehmend verschwindet (Scheer 1995, S. 4f.; Chamoni, Gluchowski 1999, S. 10 f.). 2.3 Integration vs. Entkopplung Abbildung 1 stellt den Prozess- und Applikationsaspekt gegenüber. Operative Applikationen unterstützen Unterstützungsprozesse und Geschäftsprozesse, während analytisch-dispositive Applikationen hauptsächlich Managementprozesse unterstützen. Bei der Analyse von Integrationsproblemen muss zwischen folgenden Gestaltungsaufgaben unterschieden werden (Winter 2003a): • Applikationsbildung (sog. „Mikrointegration“ (Winter 2003a)): Diese kann z. B. auf Grundlage von Verantwortungsbereichen, Produkten, Kunden(prozessen), Daten oder Funktionalitäten erfolgen. Ziel ist, eng gekoppelte Bereiche in Form einer Applikation bzw. eines Applikationsclusters zusammenzufassen und schwach gekoppelte Bereiche in verschiedene Applikationen bzw. Applikationscluster zu trennen. Eine typische Methode zur applikationsbildenden Integration ist Business Systems Planning (IBM 1984). • Applikationsintegration (sog. „Makrointegration“ (Winter 2003a)): Diese erfolgt, um die bei der Applikationsbildung „durchschnittenen“, schwachen Verknüpfungen effizient zu implementieren. 8 E. von Maur, J. Schelp, R. Winter M anagem entprozesse A nalytischdispositive A pplikationen Zw ischenschicht 2 G eschäftsprozesse U nterstützungsprozesse Abb. 1: O perative A pplikationen Zw ischenschicht 1 Prozess- vs. Applikationssicht Im Bereich der Unterstützung von Geschäfts- und Unterstützungsprozessen sollte unterschieden werden, ob die Applikationsbildung (Winter 2000a, S. 27-32) • bestimmte Verantwortungsbereiche, Produktabwicklungen, Kundenprozesse etc. zusammenführt und damit „vertikale operative Applikationen“ erzeugt (z. B. Abwicklung von Hypothekarverträgen, Schadenbearbeitung in einem Versicherungsunternehmen), • bestimmte Querschnittfunktionen auf identischen Daten zusammenführt und damit Querschnittapplikationen erzeugt, die durch andere operative Applikationen wiederverwendet werden können (z. B. Produktkonfigurierung, Kunden-/ Lieferantendatenverwaltung) oder • die Funktionalitäten bestimmter Interaktions- bzw. Vertriebskanäle zusammenführt und damit „horizontale operative Applikationen“ erzeugt (z. B. Call Center Support, WWW-Portal für Kunden oder Mitarbeiter, WAP-Portal, SBAutomaten-Support) 3 State of the Art und weiterer Forschungsbedarf 3.1 Data Warehouse Zunächst erfolgt eine Darstellung des aktuellen Forschungsstandes bezogen auf die Datenintegration für die analytisch-dispositiven Applikationen. In einem zweiten Unterabschnitt wird der absehbare, zusätzliche Forschungsbedarf skizziert. Integrierte Informationslogistik – Stand und Entwicklungstendenzen 9 3.1.1 State of the Art Die vertikale Integration dient dem Zweck der für die analytisch-dispositiven Applikationen notwendigen Schaffung einer integrierten rekonziliierten Datenbasis. Dabei hat sich gezeigt, dass eine „Hub-and-Spoke-Architektur“ (siehe Abb. 2), der bis zu diesem Zeitpunkt üblichen „Spider-Web-Architektur“ (Inmon 1996, S. 7f.) in vielerlei Hinsicht überlegen ist (Devlin 1997; Inmon, Hackathorn 1994; Inmon 1996; Kelly 1996). Im Zentrum dieser Architektur steht das Data Warehouse, welches die für die analytisch-dispositiven Applikationen notwendigen Daten integriert. Externe Daten Daten aus operativen Applikationen Externe Daten Data Warehouse Data Marts OLAP Data Mining DSS EIS Marketing Vertrieb Einkauf Management Abb. 2: ... Beispiel einer Hub-and-Spoke-Architektur Neben der Reduzierung der Schnittstellenproblematik zwischen den Quellsystemen und den analytisch-dispositiven Applikationen (von ursprünglich n * m Schnittstellen zu n + m Schnittstellen) wurde damit in vielen Fällen überhaupt erst eine gemeinsame Sicht respektive integrierte Verarbeitung der Daten ermöglicht, welche die in der Spider-Web-Architektur unvermeidlichen Inkonsistenzen (Inmon 1996, S. 7-18) beseitigt, und die Voraussetzungen geschaffen, um auf organisatorischer Ebene effizientere Strukturen bzw. Konzepte realisieren zu können (von Maur 2000, S. 196 ff.). Die Inhalte des Data Warehouse unterscheiden sich von denen der operativen Applikationen nicht nur in der Art des Zugriffs (bspw. Datensatzfokus bei operativen Applikationen versus Massenzugriff bei analytisch-dispositiven Applikationen), sondern auch vor allem inhaltlich und strukturell. 10 E. von Maur, J. Schelp, R. Winter So beschränkt sich das Data Warehouse auf jene Daten der operativen Applikationen, die sinnvoll für die analytisch-dispositiven Applikationen verwendet werden können. Ausserdem werden auch zunehmend externe Datenbestände in das Data Warehouse integriert, was aufgrund ihrer Relevanz im Zusammenhang mit analytisch-dispositiven Fragestellungen einen bedeutenden Faktor darstellt (Uhr, Breuer 1998, S. 7). Mithin geht das Data-Warehouse-Konzept über eine vertikale Integration im Sinne der Anwendungssystempyramide (Mertens, Griese 2000, S. 1) hinaus. Weiterhin werden die Data-Warehouse-Daten entsprechend den Bedürfnissen der analytisch-dispositiven Applikationen historisiert und versioniert sowie über längerfristige Zeiträume (von Maur, Rieger 2000, S. 131) gespeichert. Gerade die letztgenannten Punkte bedingen eine von den Datenbeständen der operativen Applikationen abweichende Strukturierung respektive Modellierung der Data-WarehouseDaten und in dieser Folge auch erheblich differierende Daten respektive Data-Warehouse-Inhalte selbst. State of the Art bei der Data-Warehouse-Forschung ist auch die Erkenntnis, dass ein Data Warehouse allein auf den Data Warehouse-Daten i. e. S. nicht sinnvoll betrieben werden kann und auf ein bedeutendes Informations-Potenzial (etwa bei der Datenverwendung durch die Endanwender) verzichtet wird. Die Einbeziehung der Metadaten in den Data-Warehousing-Prozess stellt deshalb einen weiteren erfolgskritischen Faktor dar (Rieger et al. 2000, S. 372 f.). DEVLIN unterscheidet dabei drei Arten von Metadaten: Built-Time Metadata, Control Metadata und Usage Metadata (Devlin 1997, S. 54-57). Built-Time und Control Metadata sind dabei im Wesentlichen technischer Natur, während Usage Metadaten, oftmals auch als Geschäftsmetadaten bezeichnet (Do, Rahm 2000), mehr die Bedeutung bzw. die Verwendung der Daten beschreiben (Rieger et al. 2000). Zur Handhabung der technischen Metadaten gibt es bereits einige gebrauchsfähige Lösungen (Do, Rahm 2000). Für den Bereich der Geschäftsmetadaten ist bisher noch keine den Erfordernissen entsprechende Lösung in Sicht (Rieger et al. 2000, S. 372). Die Data-Warehouse-Architektur lässt sich in fünf Schichten unterteilen: die Quellsysteme, die ETL-Schicht (Extraktion, Transformation, Laden), das Kern-DataWarehouse, die Data-Mart-Schicht und die analytisch-dispositiven Applikationen (siehe Abb. 3). In der ETL-Schicht werden die Quelldaten aus den heterogenen Datenbasen extrahiert, bereinigt, in das Datenmodell des Kern-Data Warehouse transformiert und in die Datenbasis geladen, weshalb DEVLIN das Kern-Data Warehouse als Reconciled Data Layer bezeichnet (Devlin 97, S. 69f.). Der ETL-Prozess wird heute in der Regel durch umfangreiche Werkzeuge unterstützt. Aus dem Kern-Data-Warehouse werden unterschiedliche abteilungs-, analyseform- und/oder endbenutzerwerkzeugspezifische Ausschnitte gebildet, die je nach Zielsetzung vom Kern-Data-Warehouse abweichend semantisch modelliert werden (z. B. in mehrdimensionalen Datenmodellen (Schelp 2000, S. 158-204)). Die analytisch-dispositiven Applikationen greifen auf die Datenbestände der Data Marts zu. Integrierte Informationslogistik – Stand und Entwicklungstendenzen Operative Applikationen Extraktion, Transformation, Laden Data Warehouse Data Marts 11 Analytischdispositive Applikationen OLTP Applikation DB 2 OLTP Applikation Oracle DB OLTP Applikation Sonst.. DB Nichtrelationale Datenquellen ETL-Werkzeuge Interne Applikationen Externe Datenquellen Netzwerk Abb. 3: Data-Warehouse-Architektur 3.1.2 Forschungsbedarf aus Sicht des Informationsmanagements Der Data-Warehouse-Bereich ist nicht nur in der Forschungslandschaft ein seit Jahren intensiv behandeltes Thema, sondern gehört längst zur normalen betrieblichen Praxis (Jung, Winter 2000a; Jung, Winter 2000b). Auch wenn viele der zahlreichen Data-Warehouse-Projekte gescheitert sind, so lässt sich dies in vielen Fällen – wie bei anderen Softwareprojekten auch – u. a. mit psycho-sozialen Faktoren erklären und weniger mit einem grundsätzlichen Problem des Data-Warehouse-Ansatzes. Es stellt sich sogar die Frage, ob der Verzicht auf ein Data Warehouse in der betrieblichen IT-Landschaft heute nicht schon ähnlich unmöglich ist, wie der Verzicht auf die operativen Applikationen. Trotzdem sind bei weitem noch nicht alle wesentlichen Probleme in der Data Warehouse-Forschung gelöst. So ergab eine Umfrage unter etwa zwanzig Grossunternehmen in der Schweiz und Deutschland, dass die derzeit drängendsten Probleme in den Data-Warehouse-Abteilungen die folgenden sind: • Inwieweit ist die strikte (Ab-)Trennung der analytisch-dispositiven von der operativen „Welt“ noch aufrechtzuerhalten, nachdem Horizontalapplikationen zunehmend an Bedeutung gewinnen und insbesondere in diesem Zusammenhang eine verstärkte „Durchmischung“ von operativen mit analytisch-dispositiven Aufgaben respektive Prozessen stattfindet? Und in Verbindung damit, wie eine Gesamtarchitektur für die historisch vertikale Applikationslandschaft und der neuentstandenen horizontalen Applikationslandschaft mit der Data-Warehouse-Architektur gestaltet werden kann. 12 E. von Maur, J. Schelp, R. Winter • Wie ein umfassendes Datenqualitäts-Management gestaltet und insbesondere organisatorisch implementiert werden kann. • Wie ein Metadaten-Management gestaltet werden muss und welche Werkzeugunterstützung für ein integriertes Metadaten-Management-System benötigt wird. Dabei stehen vor allem Lösungen für die Geschäftsmetadaten im Vordergrund und wie eine solche Lösung organisatorisch umgesetzt werden kann. • Die Frage nach dem Datenschutz im Zusammenhang mit dem Data Warehousing und nach Autorisierungskonzepten respektive inwieweit es möglich ist Autorisierungsregeln zumindest teilautomatisiert aus den operativen Applikationen abzuleiten. • Inwieweit kann beim Data Warehousing eine Abgrenzung von Entwicklung und Betrieb stattfinden, da es sich nicht um klassische Projekte mit begrenzter Entwicklungszeit handelt, sondern vielmehr um einen ständigen Prozess, in den sowohl die IT-Abteilung wie auch die Business-Unit eingebunden ist? • Auf welche Weise können unabhängige Data Marts oder auch Data Warehouses gekoppelt respektive integriert werden, die aufgrund von getrennten Entwicklungen oder etwa Unternehmensfusionen entstanden sind? • Wie können die Daten im Data Warehouse historisiert bzw. Datenstrukturen versioniert werden, damit auch mittel- bis langfristig sinnvoll verwertbare Datenbestände erhalten bleiben? • Inwieweit können anstelle einer strukturierenden Integration der Daten in das Data Warehouse auch Suchfunktionen, etwa im Zusammenhang mit dem Datenbestand des WWW, in das Data Warehouse-Konzept integriert werden? • Inwieweit können bzw. müssen auch Konzepte des Dokumenten- und Knowledge Managements mit der Data-Warehouse-Konzeption gekoppelt werden, wobei insbesondere Konzepte zur Integration von semi- und schlecht-strukturierten Daten in das Data Warehouse eine Rolle spielen? 3.2 Enterprise Application Integration Auch hinsichtlich der Integration operativer Applikationen untereinander wird zunächst der Stand der Forschung skizziert, bevor in einem weiteren Unterabschnitt ein Ausblick auf den absehbaren weiteren Forschungsbedarf versucht wird. 3.2.1 State of the Art Die horizontale Integration innerhalb der Applikationspyramide (siehe Abb. 1) bezieht sich auf die Kopplung operativer Applikationen entlang der betrieblichen Wertschöpfungskette (Mertens 1991, S. 5). Die vollständige Integration über sämtliche Stufen dieser Wertschöpfungskette hinweg ist das Ziel integrierter betrieblicher Applikationen (ERP-Systeme) wie z. B. SAP R/3. Systeme dieses Typs verfü- Integrierte Informationslogistik – Stand und Entwicklungstendenzen 13 gen über eine integrierte Datenhaltung und vermeiden so die Probleme, die bei nicht-integrierten, heterogenen Systemen auftreten: Inkonsistente Daten aufgrund redundanter Datenhaltung, syntaktische und semantische Heterogenität (Müller 2000, S. 172-190) zwischen unterschiedlichen Applikationen, Medienbrüche bei dem Austausch von Daten zwischen den Systemen, abteilungs- statt prozessorientierte Bearbeitung der Vorgänge etc. Vor allem die integrierte Datenhaltung ermöglicht eine prozessorientierte Bearbeitung der Vorgänge entlang der Wertschöpfungskette sowie eine beschleunigte Bearbeitung dieser Vorgänge. Erforderlich ist dafür allerdings ein komplexer Anpassungsprozess dieser Anwendungssysteme (Customizing), der oftmals mit einer Überarbeitung der betrieblichen Prozesse verbunden ist (Keller 1999). Das Ziel einer vollständigen Integration über die gesamte Wertschöpfungskette eines Unternehmens hinweg wird in der Praxis jedoch nicht immer erreicht. So wurde bspw. im Rahmen einer Untersuchung festgestellt, dass bei Data-Warehouse-Projekten auf Basis einer ERP-Lösung durchschnittlich 38 Prozent der im Data Warehouse enthaltenen Daten aus Nicht-ERP-Systemen stammen (ohne Verfasser 2001, S. 48), die Integration der operativen Systemen miteinander ist in den betreffenden Unternehmen somit nicht vollständig. Getrieben durch die rasanten Entwicklung des Internets gesellen sich zu den bestehenden operativen Applikationen in den Unternehmungen eher neue Applikationstypen hinzu: Netzwerke von Selbstbedienungsautomaten (ATM-Netzwerke), Portal-, Call Center-, WWW- oder WAP-Applikationen greifen quer über die betriebliche Wertschöpfungskette hinweg auf operative Anwendungsdaten zu (Winter 2000a, S. 31f.). Da die bestehenden operativen Systeme nur in den seltensten Fällen über entsprechende Portalfunktionalitäten verfügen, müssen diese zusätzlichen Systeme an die bestehenden operativen Vorsysteme angebunden werden (vgl. auch Schelp, Winter 2002). Sofern im Bereich der Vorsysteme keine vollständig integrierte betriebswirtschaftliche Applikation eingesetzt wird, entsteht an dieser Stelle schnell ein Schnittstellenproblem (siehe Abb. 4). Applikation 1 Abt. A WWW-Portal Applikation 2 Abt. A WAP-Portal Applikation 1 Abt. B Call Center Applikation... System... Applikation n Abt. C ATM-Netzwerk Abb. 4: Schnittstellen zwischen vertikalen und horizontalen Applikationen 14 E. von Maur, J. Schelp, R. Winter Diese Problemstellung, die zur Zeit auch unter dem Stichwort Enterprise Application Integration diskutiert wird (Linthicum 2000; Ruh et al. 2000), ist der im DataWarehouse-Umfeld ähnlich – für eine Zusammenführung der operativen Daten ist eine logische Gesamtsicht auf die operativen Applikationen erforderlich. Daher kann an dieser Stelle überlegt werden, ob nicht die Lösungsansätze des Data Warehousing auch auf diese Situation übertragen werden können. Mit dem Konzept des Operational Data Store bietet sich eine Lösung an, die zu einer Architektur wie in Abb. 5 dargestellt führt. Metadaten-Repository Applikation 1 Abt. B Applikation... Applikation n Abt. C Abb. 5: ODSVerwaltungssystem ODSDatenbank Transformationswerkzeug Applikation 2 Abt. A Transformationswerkzeug Applikation 1 Abt. A WWW-Portal WAP-Portal Call Center Applikation... ATM-Netzwerk Architektur eines Operational Data Stores In einer solchen Architektur werden in der ODS-Datenbank die Daten vorgehalten, die sich aus der Schnittmenge der Anwendungsdaten der beteiligten operativen Applikationen ergeben. Ähnlich wie im Data Warehouse ist eine Transformationsschicht zwischen den operativen Applikationen und der zentralen Datenbank notwendig. In dieser Schicht können die syntaktische und die semantische Heterogenität der betroffenen Systeme bereinigt werden. Ein Metadaten-Repository enthält dabei alle für den Datenaustausch und die Transformationsschritte notwendigen Informationen. Es stellt sich jedoch die Frage, ob eine solche einfache Übernahme des Data-Warehouse-Konzeptes im operativen Umfeld hinreichend ist. Eine genauere Betrachtung zeigt, dass die Eigenschaftsprofile unterschiedlich gestaltet sind (siehe Abb. 6). Während im Data Warehouse komplexe und auch aggregierte Informationsobjekte im Vordergrund stehen, sind dies in den vertikalen operativen Applikationen die atomaren Transaktionsdaten, die zudem möglichst in Echtzeit zu verarbeiten sind. Darüber hinaus werden die zumeist aktuellen Daten in den operativen Vorsystemen isoliert von anderen Systemen verarbeitet, wogegen im Data Warehouse die Daten gerade integriert und auch mit einer ggf. umfangreichen Historie vorliegen müssen. Im Gegensatz zum Data Warehouse ist bei den operativen Systemen auch ein schreibender Zugriff auf die Daten notwendig. Integrierte Informationslogistik – Stand und Entwicklungstendenzen Basisorientierung: Transaktion Zeitbezüge: Aktuell Zugriffsart: Read-write Aggregationsgrad: Detailliert Integrationsgrad: Isoliert Zugänglichkeit: Real-time 15 Informationsobjekt Aktuell + historisch Read-only Aggregiert Integriert Zeitverzögert Legende: Datenhaltung in operativen Systemen Datenhaltung in Operational Data Stores Datenhaltung im Data Warehouse-System Abb. 6: Eigenschaftsprofile verschiedener operativer, ODS- und Data-Warehouse-Systeme (in Anlehung an Winter 2000a, S. 34) Der Operational Data Store kann nun hinsichtlich seines Eigenschaftsprofils weder den operativen Vorsystemen noch dem Data Warehouse eindeutig zugeordnet werden (siehe auch Abb. 6): Neben dem aktuellen Zeitbezug mit Lese- und Schreibzugriff in Echtzeit bezogen auf die detaillierten Daten wie in den Vorsystemen ist wie im Data Warehouse eine Integration notwendig. Scheint der Verzicht auf historisierte Daten und der damit einhergehenden Probleme im Data-Warehouse-Bereich eine Umsetzung der Data-Warehouse-Lösung eher leichter zu gestalten, so ergeben sich aus dem Echtzeitgedanken sowie dem Leseund Schreibzugriff massive Probleme: Das zeitnahe Update eines Data Warehouse ist in der Praxis ein grosses Problem. Nicht selten werden Updates in der Praxis nur täglich durchgeführt (z. B. Garzotto 2000, S. 147f.). Darüber hinaus führt das für Schreibzugriffe notwendige Locking der Daten zu weiteren Verzögerungen beim gleichzeitigen Zugriff auf diese. In der Praxis haben sich daher neben den datenzentrierten ODS-Konzepten sogenannte Messaging-Lösungen als weitere Alternative zur Kopplung der operativen Systeme miteinander etabliert (siehe Abb. 7). Aber auch diese Lösung ist nicht unproblematisch. Dadurch, dass die einzelnen Nachrichten in sogenannten Message-Stacks zwischengespeichert und dann sequentiell ausgeführt werden, sind Änderungen der Daten bei gleichzeitig parallelem Lesezugriff auf diese problembehaftet. Darüber hinaus kann eine hohe Kapazitätsauslastung der operativen Vorsysteme wie u. a. bei (Inmon 1996, S. 25) beschrieben, zu weiteren Problemen führen. Das Erfordernis schneller Antwortzeiten vieler WWW-Nutzer beispielweise konfliktiert mit den langsamen Reaktionszeiten älterer operativer Applikationen. In solchen Fällen kann es angezeigt sein, eine Mischform aus daten- und nachrichtenorientierter Lösung zu wählen, wie sie in der folgenden Abb. 8 skizziert ist. 16 E. von Maur, J. Schelp, R. Winter Metadaten-Repository Applikation 1 Abt. B Applikation... Applikation n Abt. C Abb. 7: Messaging-Server Transformationswerkzeug Applikation 2 Abt. A Transformationswerkzeug Applikation 1 Abt. A Portal Terminals eAppliances Messagingorientierte Kopplung operativer Systeme Metadaten-Repository Applikation 1 Applikation... Applikation n Abb. 8: Messaging-Server ODSVerwaltungssystem ODS-DB Transformationswerkzeug Applikation 2 Transformationswerkzeug Applikation 1 Portal Terminals eAppliances Mischform aus ODS- und Messaging-Lösung So können beispielsweise die sich nicht so schnell ändernden Kundenprofile im ODS zwischengespeichert werden, während die aktuellen Bestandsdaten für die Auftragsdurchführung aus den Vorsystemen extrahiert werden. Wenn nur vergleichsweise wenige Daten in Echtzeit aus den Vorsystemen benötigt werden, kann der Zugriff auf diese über ein ODS auch bei Kapazitätsengpässen der Vorsysteme leichter performant gestaltet werden. 3.2.2 Forschungsbedarf aus Sicht des Informationsmanagements Neben der zuvor angeschnittenen Frage nach der Architektur einer solchen Enterprise Application Integration lassen sich eine Reihe weiterer Fragestellungen formulieren – sie ergeben sich dabei sowohl in Analogie aus den im vorhergehenden Abschnitt zum Data Warehouse skizzierten, eher betriebswirtschaftlich geprägten Problembereichen wie aus eher informatik-bezogenen Fragestellungen, die im Zusammenhang mit Data Warehousing immer wieder angesprochen werden (Widom 1995; Dinter et al. 1999): Integrierte Informationslogistik – Stand und Entwicklungstendenzen 17 • Können die Vorgehensmodelle zur Konzeption und Realisierung einer Integrationslösung aus dem Data Warehouse übernommen werden oder bedürfen sie ggf. einer Modifikation? • Wie lassen sich die heterogenen Applikationslandschaften gestalten, die durch die Einführung weiterer Komponenten (EAI-Infrastruktur etc.) eher an Komplexität gewinnen? • Gibt es Integrationsmuster, die bei wiederkehrenden Integrationsprojekten wiederverwendet werden können? • Welche Metadaten sind bei der horizontalen Integration – auch im Unterschied zum Data Warehousing – zu berücksichtigen? • Können die Erkenntnisse hinsichtlich der Sicherstellung der Datenqualität aus dem Data-Warehouse-Bereich übernommen werden? • Welche Besonderheiten existieren in Bezug auf Sicherheits- und Zugriffskonzepte? • Welche Implikationen haben die Performance-Probleme hinsichtlich der zum Einsatz kommenden Speicher- und Kommunikationstechniken? • Welche Update-Anomalien etc. sind in heterogenen Umgebungen vorzufinden und wie kann ihnen wirkungsvoll begegnet werden? • Welche organisatorischen Massnahmen sind notwendig hinsichtlich der fortlaufend zu erwartenden Änderungen innerhalb der und zwischen den zahlreichen beteiligten Applikationen? Diese Fragen sind keineswegs abschliessend. Sie ergeben sich aber vor dem Hintergrund der im Data Warehouse-Umfeld diskutierten Fragestellungen, die ebenfalls erst teilweise gelöst sind (u. a. Dinter et al. 1999). Da die Ausgangsproblemstellung bei der Integration operativer Systeme miteinander wie ausgeführt Berührungspunkte zu den Problemfeldern im Data-Warehouse-Bereich hat, sollten die dort erarbeiteten Lösungsansätze im Einzelfall darauf geprüft werden, ob sie nicht auch im Enterprise Application Integration-Bereich sinnvoll angewandt werden können. Darüber hinaus gibt es eine Reihe von Fragestellungen, die über den Fokus der Data-Warehouse-Sicht hinausgehen: Beispielsweise wie eine Integrationsarchitektur modelliert oder eine IS-Architektur insgesamt gestaltet werden kann, wenn durch EAI-Technologien eine Flexibilisierung der Applikationslandschaft möglich wird und Applikationen in schnellerer Folge ein- und ausgewechselt werden. Neue, sich schnell verbreitende Technologien wie bspw. Web Services sollten darauf untersucht werden, ob sie als Basistechnologien zum Aufbau einer Integrationsinfrastruktur geeignet sind und wie darauf basierende IS-Architekturen zu gestalten sind. Generell ergeben sich aus der EAI-Thematik eine Reihe von Fragestellungen, die in die Architekturgestaltung und das Architekturmanagement zielen (vgl. auch Schelp 2003). 18 E. von Maur, J. Schelp, R. Winter 3.3 Unternehmensübergreifende Integration Gestaltungsaktivitäten auf Strategie-, Prozess- und Systemebene beschränken sich traditionell meist auf die Grenzen der jeweils betrachteten Unternehmung. Im Informationszeitalter tritt die Vernetzung von Unternehmungen jedoch immer mehr in den Mittelpunkt (Österle, Winter 2000, S. 8-9). Schon seit vielen Jahren hat z. B. eine steigende Zahl von Konsumenten im Finanzdienstleistungsbereich mehr als vier Bankverbindungen und baut damit individuelle „Leistungsnetzwerke“ auf (Friedman, Langlinais 1999). In letzter Zeit werden z. B. durch Aggregatoren unterschiedlichste Basis-Finanzdienstleistungen (z. B. Zahlungsverkehr, Kreditgewährung, Bargeldversorgung) zu kundenprozess-orientierten Lösungen integriert, wodurch Leistungsnetzwerke institutionalisiert werden (Leist, Winter 2000, S. 152154). Unternehmensübergreifende („zwischenbetriebliche“) Integration wurde schon früh als logische Fortsetzung innerbetrieblicher Integration erkannt (z. B. Mertens 1985, S. 81; Mertens 1995, S. 7). Allerdings litt die Umsetzung lange Zeit • an der Bottom-up-Sicht auf unternehmensübergreifende Integration, die mit der Standardisierung und Automatisierung von Systemschnittstellen beginnt (siehe die Beispiele in (Mertens 1985)) und nicht Top-down durch die Definition unternehmensübergreifender Geschäftsarchitekturen und unternehmensübergreifender Prozesse geleitet wird, sowie • an der fehlenden Verfügbarkeit nicht-proprietärer, einfacher, kostengünstiger und verbreiteter Standards. Beide Voraussetzungen wurden in den letzten Jahren geschaffen: Einerseits liegen heute ausführliche Konzeptionen für die Gestaltung unternehmensübergreifender Geschäftsmodelle und insbesondere unternehmensübergreifender Prozesse vor (z. B. Österle et al. 1999). Andererseits bilden sich in den verschiedensten Branchen Standards nicht nur in Form von Kommunikationsprotokollen und Nachrichtentypen, sondern auch in Form standardisierter Prozessschnittstellen (bzw. eingebundener Prozessschritte) oder in letzter Zeit sogar in Form standardisierter Schnittstellen (bzw. Einbindungskonzepte) auf Geschäftsebene aus. Ein Beispiel für den letztgenannten, aus Sicht einer ganzheitlichen, Top-down betriebenen Unternehmensmodellierung wichtigsten Gestaltungsbereich sind konzeptionelle Vertragsmodelle, standardisierte Service Level Agreements oder standardisierte Prozessketten der eBXML-Initiative. Die unternehmensübergreifende Integration kann koppelnd (d. h. im Sinne von EAI) oder entkoppelnd zur Sicherung der Informationsversorgung (d. h. im Sinne von Data Warehousing) erfolgen. Welches Konzept jeweils vorzuziehen ist, richtet sich danach, ob Komponenten eines übergreifenden Prozesses zu verknüpfen sind oder ob Informationsflüsse zwischen Prozessen effizient zu gestalten sind. Sowohl im Data Warehousing wie auch im noch jüngeren Gebiet des EAI werden jedoch Integrierte Informationslogistik – Stand und Entwicklungstendenzen 19 Probleme unternehmensübergreifender Integration fast überhaupt nicht adressiert, sodass hier der grösste Handlungsbedarf gesehen wird. 4 Zusammenfassung und Ausblick Die aufgeführten Problemstellungen respektive die angerissenen Forschungsbedarfe aus Sicht des Informationsmanagement ergeben ein Bild von Forschungsthemen, die im Detail zu klären sein werden und erheblichen Einsatz von Forschung und Praxis erfordern. Deutlich wird aber auch, dass die Grenzen zwischen den an der Informationslogistik beteiligten Applikationstypen nicht mehr in der bisherigen klaren Form gezogen werden können und ebenso, dass eine ausschliesslich isolierte Betrachtung von Data Warehouse bzw. analytisch-dispositiven Applikationen und EAI bzw. vertikalen und horizontalen operativen Applikationen nicht sinnvoll sein kann. Weiterhin muss die unternehmensübergreifende Integration Berücksichtigung finden, was die bisherige weitgehend isolierte Vorgehensweise zusätzlich infrage stellt. Applikationen in anderen Unternehmen BCI Analytisch-dispositive Applikationen Data Marts Core Data Applikationen Selektion und Aggregation Data Warehouse-System Externe Daten Integration und Bereinigung Vertikale operative Applikationen HorizonStaging tale operaChannelingtive Applika- Staging Channeling tionen EAI Abb. 9: Integrierte Informationslogistik (Winter 2003a) Abbildung 9 illustriert die Vision einer Referenzarchitektur integrierter Informationslogistik, wie sie in (Winter 2003a) aus qualitativen Untersuchungen zur Integrationskosten-minimalen Applikationsbildung (Mikrointegration) und Applikationsintegration (Makrointegration) abgeleitet wird. Operative Applikationen verschiedener Typen werden durch Operational Data Stores (symbolisiert durch Datenspeicher-Symbole) sowie nachrichten- bzw. ereignisorientierte Middleware (symbolisiert durch Briefumschlag-Symbole) gekoppelt. Diese Zwischenschicht 20 E. von Maur, J. Schelp, R. Winter bildet die Basis für die Bereitstellung integrierter Daten aus verschiedenen operativen Applikationen sowie externer Daten für analytisch-dispositive Applikationen durch das Data-Warehouse-System. Neben Extraktion und Transformation sind für die Informationsversorgung analytisch-dispositiver Applikationen die bekannten zusätzlichen Schritte wie Bereinigung, Selektion, Aggregation und vor allem Qualitätssicherung notwendig. Die Integrationsschicht operativer Applikationen (Zwischenschicht 1 in Abb. 1) muss von der Entkopplungsschicht zur Versorgung analytisch-dispositiver Applikationen (Zwischenschicht 2 in Abb. 1) unterschieden werden, da sich beide Schichten u. a. durch die maximal tolerierbare Dauer des Datenaustausches, den Umfang der notwendigen Qualitätssicherung, das Volumen und den Detaillierungsgrad der auszutauschenden Daten, die Volatilität der Daten und das Ausmass der Abstraktion von konkreten Geschäftsvorfällen unterscheiden. Ein weiteres Element der Referenzarchitektur bildet die BCI, die im Form von Standards (symbolisiert durch Briefumschläge) und Web Services implementiert wird. Die quantitative Validierung der Gestaltungsregeln in (Winter 2003a) und damit der Referenzarchitektur steht allerdings aus. Die Nachfolgeprojekte des Kompetenzzentrums Data Warehousing 2 werden hierzu hoffentlich einen wichtigen Beitrag leisten. Literatur Becker, Jörg: CIM-Integrationsmodell. Springer, Berlin 1991. Boßhammer, Manfred; Winter, Robert: Formale Validierung von Verdichtungsoperationen in konzeptionellen Datenmodellen. In: König, Wolfgang (Hrsg.): Wirtschaftsinformatik '95. Physica, Heidelberg 1995, S. 223-241. Cäsar, M.; Alt, R.; Grau, J.: Collaboration in the consumer product goods industry - Analysis of marketplaces. In: Proceedings of 10th European Conference on Information Systems (ECIS), Gdansk 2002. Chamoni, Peter; Gluchowski, Peter: Analytische Informationssysteme – Einordnung und Überblick. In: Chamoni, Peter; Gluchowski, Peter (Hrsg.): Analytische Informationssysteme. 2. Auflage, Springer, Berlin 1999, S. 3-25. Devlin, B., Murphy, P.: An Architecture For a Business and Information System. In: IBM Systems Journal, 27 (1988) 1, S. 60-80. Devlin, B.: Data Warehouse — From Architecture to Implementation, Addison Wesley, 1997. Dinter, Barbara; Sapia, Carsten; Blaschka, Markus; Höfling, Gabi: OLAP Market and Research: Initiating the Cooperation. In: Journal of Computer Science and Information Management, 2. Jg., Nr.3 (1999). URL: http://www.forwiss.tu-muenchen.de/~system42/ publications/jcsim.pdf (4.3.2003). Integrierte Informationslogistik – Stand und Entwicklungstendenzen 21 Do, H.H; Rahm, E.: On Metadata Interoperability in Data Warehouses. In: Technical Report 01-2000. Dept. of Computer Science, Univ. of Leipzig, March 2000. Ferstl, Otto K.; Sinz, Elmar J.: Grundlagen der Wirtschaftsinformatik. 3. Aufl., Band 1, Oldenbourg, München-Wien:1998. Friedman, J.P.; Langlinais, T.: Best intentions - A business model for the eEconomy. Outlook 11 (1999) 1, S. 34-41. Garzotto, Andreas: MASY – Ein Erfahrungsbericht zum Thema Data Warehouse. In: Jung, Reinhard; Winter, Robert: Data Warehousing Strategie – Erfahrungen – Methoden – Visionen, Springer, Berlin et al. 2000, S. 161-167. Grochla, E. und Mitarbeiter: Integrierte Gesamtmodelle der Datenverarbeitung. Hanser, München 1974. IBM Corp.: Business Systems Planning - Information Systems Planning Guide. 4th ed., IBM-Form GE20-0527-4, Atlanta 1984. Inmon, W., Hackathorn, R.: Using the Data Warehouse. Wiley, New York et al. 1994. Inmon, William H.: Building the Data Warehouse. 2. Aufl., Wiley, New York et al. 1996. Jung, Reinhard; Winter, Robert (Hrsg.): Data Warehousing 2000. Springer, Berlin et al. 2000 Jung, Reinhard; Winter, Robert (Hrsg.): Data Warehousing Strategie – Erfahrungen – Methoden – Visionen. Springer, Berlin et al. 2000. Kelly, S.: Data Warehousing — The Route to Mass Customization. New York et al. 1996. Keller, Gerhard: SAP R/3 prozessorientiert anwenden – Iteratives Prozess-Prototyping mit ereignisgesteuerten Prozessketten und knowledge maps, 3. Aufl. Addison-Wesley, Bonn et al. 1999. Leist, Susanne; Winter, Robert: Finanzdienstleistungen im Informationszeitalter – Vision, Referenzmodell und Transformation. In: Belz, Christian; Bieger, Thomas (Hrsg.): Dienstleistungskompetenz und innovative Geschäftsmodelle. Texis, St.Gallen 2000, S. 150-166. Linthicum, David S.: Enterprise Application Integration. Addison-Wesley, Reading, Massachusetts 2000. von Maur, E.; Rieger, B: Data Warehouse. In: Mertens, P. (Haupt-Hrsg.), Back, A.; Becker, J.; König, W.; Krallmann, H.; Rieger, B.; Scheer, A.; Seibt, D.; Stahlknecht, P.; Strunz, H.; Thome, R., Wedekind, H. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. Auflage. Springer, New York et al. 2001, S. 131-132. von Maur, Eitel: Object Warehouse – Konzeption der Basis objektorientierter Management Support Systems am Beispiel von Smalltalk und dem ERP Baan., Osnabrück 2000. URL: http://www.eitelvonmaur.de/owh (12.1.2003). Mertens, Peter: Zwischenbetriebliche Integration der EDV. In: Informatik-Spektrum 8 (1985) 2, S. 81-90. Mertens, Peter: Integrierte Informationsverarbeitung 1 – Administrations- und Dispositionssysteme in der Industrie. 8. Aufl. Gabler, Wiesbaden 1991. 22 E. von Maur, J. Schelp, R. Winter Mertens, P.; J. Holzner: Eine Gegenüberstellung von Integrationsansätzen der Wirtschaftsinformatik. In: Wirtschaftsinformatik 34 (1992) 2, S. 5ff. Mertens, Peter: Integrierte Informationsverarbeitung 1, 10. Aufl., Gabler, Wiesbaden 1995. Mertens, Peter; Griese, Joachim: Integrierte Informationssysteme 2 – Planungs- und Kontrollsysteme in der Industrie. 8. Aufl., Gabler, Wiesbaden 2000. Müller, Jochen: Transformation operativer Daten zur Nutzung im Data Warehouse. Gabler DUV, Wiesbaden 2000. Österle, Hubert: Business Engineering. Band 1: Entwurfstechniken. Springer, Berlin 1995. Österle, Hubert; Fleisch, Elgar; Alt, Rainer (Eds.): Business Networking - Shaping Enterprise Relationships on the Internet. Springer, New York 1999. Österle, Hubert; Winter, Robert: Business Engineering. In: Österle, Hubert; Winter, Robert (Hrsg.): Business Engineering. Springer, Berlin 2000, S. 3-20. Ohne Verfasser: User ziehen Data Warehouse ihrer ERP-Anbieter vor – Enterprise Resource-Planning und Analyse wachsen zusammen. In: Computerwoche 27 (2001) 5, 2. Februar 2001, S. 47-48. Porter, M.: Wettbewerbsvorteile. Campus, Frankfurt 1986. Rieger, Bodo; Kleber, Anja; von Maur, Eitel: Metadata-Based Integration of Qualitative and Quantitative Information Resources Approaching Knowledge Management. In: Proceedings der ECIS 2000 (European Conference on Information Systems) in Wien 2000, S. 372-378. Ruh, William A.; Maginnis, Francis X.; Brown, William J.: Enterprise Application Integration – A Wiley Tech Brief, Wiley, New York 2000. Rüegg-Stürm, Johannes: Das neue St. Galler Management-Modell, Haupt, Bern etc. 2002. Scheer, August-Wilhelm: Produktionsplanung auf der Grundlage einer Datenbank des Fertigungsbereichs. München-Wien 1976. Scheer, August-Wilhelm: CIM – Der computergestützte Industriebetrieb. 4. Aufl., Springer, Berlin 1990. Scheer, August-Wilhelm: Architektur integrierter Informationssysteme. Springer, Berlin 1991. Scheer, August-Wilhelm; Hars, Alexander: Extending Data Modeling to Cover the Whole Enterprise. In: Communications of the ACM 35 (1992) 9, S. 166-172. Scheer, August-Wilhelm: Wirtschaftsinformatik Studienausgabe. Springer, Berlin 1995. Schelp, J.: Modellierung mehrdimensionaler Datenstrukturen analyseorientierter Informationssysteme. Gaber, DUV, Wiesbaden 2000. Schelp, J.; Winter, R.: Enterprise Portals und Enterprise Application Integration – Begriffsbestimmung und Integrationskonzeptionen. In: Meinhard, S.; Popp, K. (Hrsg.): Enterprise-Portale & Enterprise Application Integration, zugl. HMD – Praxis der Wirtschaftsinformatik, 39. Jg., Nr. 225, 2002, S. 6-20. Integrierte Informationslogistik – Stand und Entwicklungstendenzen 23 Schelp, J.: Konzept und Idee des CC AIM, Universität St.Gallen, St.Gallen 2003. URL: http://aim.iwi.unisg.ch/konzept.php (01.03.2003). Uhr, W., Breuer, S. (Hrsg.): Tagungsband der Wirtschaftsinformatik Fachtagung Integration externer Informationen. In: Management Support Systems, Technische Universität Dresden 1998. Ulrich, H.; Krieg, W.: St. Galler Management-Modell. 3. Auflage, Haupt, Bern 1974. Widom, Jennifer: Research Problems in Data Warehousing. In: Proceedings of the International Conference on Information and Knowledge Management (CIKM), 28. November 1995, Balitmore USA, S. 25-30. Winter, Robert: Zur Positionierung und Weiterentwicklung des Data Warehousing in der betrieblichen Applikationsarchitektur. In: Jung, Reinhard; Winter, Robert (Hrsg.): Data Warehousing Strategie – Erfahrungen – Methoden – Visionen, Springer, Berlin et al. 2000a, S. 127-139. Winter, Robert: Zur Positionierung und Weiterentwicklung des Data Warehousing in der betrieblichen Applikationsarchitektur. In: Schmidt, Herrad (Hrsg.): Modellierung betrieblicher Informationssysteme (Proc. der MobIS-Fachtagung 2000). Rundbrief der GI-Fachgruppe 5.10 7 (2000b) 1, S. 23-38. Winter, Robert: Ein Architekturmodell zur Unterstützung von Integrationsentscheidungen auf Anwendungssystemebene. Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St.Gallen 2003a. URL: http://www.iwi.unisg.ch (25.02.2003). Winter, Robert: Modelle, Techniken und Werkzeuge im Business Engineering. Erscheint 2003 in: Österle, H.; Winter, R. (Hrsg.): Business Engineering – Auf dem Weg zum Unternehmen des Informationszeitalters, 2. Aufl., Springer, Berlin, 2003b. Zachman, John A.: A framework for information systems architecture. In: IBM Systems Journal 26 (1987), 3; reprinted in IBM Systems Journal 38 (1999), 2&3, pp. 454-470.