Anforderungen an Systeme zur Managementunterstützung von Service-orientierten Architekturen

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung und Aufbau der Arbeit

2 Anforderungen an Systeme zur Managementunterstützung
2.1 Entwicklung und Bedeutung
2.2 Begriffsbestimmung und -abgrenzung
2.3 Business Intelligence
2.3.1 Begriffsbestimmung
2.3.2 Systemarchitektur
2.3.3 Anforderungen und Defizite
2.3.4 Beispiel Vertriebsinformationssystem

3 Service-orientierte Architekturen als Lösungsansatz
3.1 Entwicklungsstufen
3.2 Konzeptionelle Betrachtung
3.3 Managementkonzeption
3.3.1 Geschäftsprozessmanagement
3.3.2 Informationstechnologische Anforderungen
3.4 IT-Architekturkonzeption
3.4.1 Begriffsbestimmung
3.4.2 Web Services
3.4.3 Enterprise Service Bus

4 Service-orientierte Business Intelligence Architektur
4.1 Unterstützende Konzepte
4.1.1 Corporate Performance Management
4.1.2 Balanced Scorecard
4.1.3 Process Performance Management
4.2 Unterstützende Technologien
4.2.1 Informationsaufbereitung und –bereitstellung
4.2.2 Datenaufbereitung und -bereitstellung
4.2.3 Serviceorientierung
4.3 Bewertung

5 Schlussbetrachtung und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1: Struktur der Arbeit

Abb. 2: Komponenten von MUS

Abb. 3: Traditionelle Abgrenzung nach Unternehmens-/Managementebenen

Abb. 4: Komponenten und Prozesse von Business Intelligence Systemen

Abb. 5: Schalenmodell der BI-Werkzeuge zur Datennutzung

Abb. 6: Echtzeit und Aktionszeit

Abb. 7: Defizite traditioneller VIS

Abb. 8: „Spaghetti“-Struktur vs. Hub&Spoke-Struktur und Bus-Struktur

Abb. 9: Entwicklungsstufen im Zeitverlauf

Abb.10: Top-down- vs. Bottom-up-Vorgehensweise

Abb.11: Prozesshierarchie mit vereinfachter EPK „Auftrag bearbeiten“

Abb.12: Begriffsverständnis „Service“

Abb.13: Rollen in einer SOA

Abb.14: Bestandteile einer SOA

Abb.15: SOA-Rollen und Web Services-Standards

Abb.16: Enterprise Service Bus

Abb.17: Operativer und strategischer CPM-Regelkreislauf

Abb.18: Balanced Scorecard

Abb.19: Operationalisierung der BSC

Abb.20: Mehrstufiger Datenaufbereitungsprozess

Abb.21: Service-Schichten

Abb.22: Orchestrierung in einer SOA

Abb.23: Einbettung von BI-Services

Tabellenverzeichnis

Tabelle 1: BI-Defizite, Umwelteinflüsse und Rahmenbedingungen

Tabelle 2: Performance Management Komponenten

Tabelle 3: Dashboards vs. Scorecards

Tabelle 4: Vergleich Traditionelles BI vs. SOA-basiertes BI

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung und Aufbau der Arbeit

Unternehmen stehen heute vor enormen Herausforderungen: sie müssen Entscheidungen bei hohem Wettbewerbs- sowie stetig steigendem Kosten- und Zeitdruck treffen. Sich ständig verändernde Markt- und Rahmenbedingungen stellen außerdem hohe Anforderungen an die Flexibilität der Unternehmen. Aufgrund dieser Entwicklungen sind Unternehmen dazu gezwungen, ihr unternehmerisches Handeln schnell und flexibel hierauf einzustellen, da strategische Fehlentscheidungen die Unternehmen existenziell bedrohen können.

Heute richten die Unternehmen ihre Strategie vermehrt an den Geschäftsprozessen entlang ihrer Wertschöpfungskette aus. Durch die Geschäftsprozessorientierung können Unternehmen schneller reagieren, auf beispielsweise verkürzte Produktlebenszyklen, internationale Konkurrenz, Änderungen gesetzlicher Vorschriften, neue informationstechnische Entwicklungen und steigenden Kostendruck.^[1] Dies erfordert ein entsprechendes Management der Geschäftsprozesse.

Daneben wird aber auch eine konsistente Informationsbasis auf allen Unternehmensebenen benötigt. Dem Top-Management müssen Anwendungen bereitstehen, um die Unternehmensstrategie planen, steuern und kontrollieren zu können. Auf der Ebene des mittleren Managements müssen die Vorgaben verfolgt und auf die unteren Ebenen heruntergebrochen werden. Der unteren Managementebene selbst müssen Informationen bereitgestellt werden, um die Geschäftsprozesse operativ zu überwachen. Zusammenfassend betrachtet benötigen erfolgreiche Unternehmen also die richtigen Informationen zum richtigen Zeitpunkt am richtigen Ort für den richtigen Zweck.

Um diese Ziele zu erreichen, brauchen Unternehmen auf der einen Seite unterstützende Konzepte mit denen die Unternehmensstrategie gestaltet und verfolgt werden kann. Auf der anderen Seite müssen diese Konzepte eng mit den entsprechenden IT-Anwendungen verzahnt sein. Die enge Verzahnung von Strategie und IT-Anwendungen erfordert aber gleichzeitig, dass diese flexibel anpassbar sind.

Neben der beschriebenen Unterstützung auf strategischer Ebene müssen jederzeit auch Informationen über den Status der operativen Geschäftsprozesse abgerufen bzw. bereitgestellt werden können.

In der Vergangenheit haben viele Unternehmen unterstützende Konzepte und Technologien entwickelt, die aber vorwiegend technologiegetrieben waren. Für diese Managementunterstützungssysteme (MUS), die in den Unternehmen zur Informationsversorgung eingesetzt werden, hat sich in der betrieblichen Praxis der Begriff „Business Intelligence“ (BI) etabliert.^[2] Die bisher bekannten IT-Werkzeuge des Business Intelligence sind allerdings nicht in der Lage, alle Anforderungen vollständig zu erfüllen. So können BI-Systeme Informationen nur mit einer gewissen Zeitverzögerung bereitstellen. Auch ist es eher ein Informations-Bereitstellungsmodell ohne Rückkopplungskomponente, das die Informationen dabei überwiegend auf strategischer und taktischer Ebene zur Verfügung stellt, also nicht dort, wo sie ebenso wichtig gebraucht werden: in den operativen Prozessen. Insgesamt können die heute bestehenden BI-Systeme die Informationen also oftmals nicht zum richtigen Zeitpunkt (da zeitverzögert), nicht am richtigen Ort (aufgrund vorwiegend taktisch / strategischer Ausrichtung), nicht mit den richtigen Informationen (da lediglich Informations-Bereitstellungsmodell) und nicht für den richtigen Zweck (fehlender Business Kontext der Informationen) verfügbar machen.

In Unternehmen werden heute Konzepte und Technologien benötigt, die diese Informationslücke schließen können. Diese Arbeit analysiert bestehende Konzepte und Technologien, um herauszufinden, ob diese in der Lage sind die genannten Informationsprobleme zu lösen. Ein viel versprechendes Konzept in diesem Zusammenhang sind Service-orientierte Architekturen. Hauptmotivation dieser Arbeit ist die Frage, ob die Informationsversorgung in den Unternehmen im Rahmen einer SOA verbessert werden kann bzw. welchen Beitrag eine SOA zu leisten imstande ist.

Im nachfolgenden Kapitel 2 werden zunächst die grundlegenden Anforderungen an heutige Systeme zu Managementunterstützung betrachtet, wobei ein Schwerpunkt auf dem heute bekannten Begriffsverständnis für BI liegt. Es werden weiterhin auch die Probleme traditioneller BI-Systeme ausgearbeitet.

Im daran anschließenden Kapitel wird das Architekturkonzept der Service-orientierten Architekturen vorgestellt, da SOA in dieser Arbeit als Ansatz zur Lösung bestehender BI-Probleme herangezogen wird. SOA ist mehr als ein rein technologisches Konzept, daher erfolgt sowohl eine Darstellung aus Managementperspektive als auch aus der Perspektive der IT. Aus Managementperspektive wird das Geschäftsprozessmanagement betrachtet, aus IT-Perspektive werden Web Services als eine Möglichkeit der technischen Realisierung gewürdigt.

Anforderungen an Systeme zur Managementunterstützung und SOA werden dann im Kapitel 4 gemeinsam betrachtet. Ziel ist die Darstellung, wie SOA zur Lösung bestehender Defizite in heutigen Systemen zur Management­unterstützung beitragen kann. In diesem Zusammenhang werden die unterstützenden Konzepte: Corporate Performance Management, Balanced Scorecard und Process Performance Management vorgestellt. Anschließend werden unterstützende Technologien zur Realisierung betrachtet. Das Kapitel schließt mit der Bewertung einer auf Basis von SOA realisierten Architektur zur Managementunterstützung ab.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Struktur der Arbeit

In allen Kapiteln werden die Ausführungen anhand von Beispielen aus dem Vertriebsprozess verdeutlicht. Kapitel 2 überträgt die bestehenden BI-Probleme auf den Vertrieb, Kapitel 3 zeigt mittels Ereignisgesteuerter Prozessketten einen Geschäftsprozess und Kapitel 4 eine Realisierung in einem Prototyp zum Cross-Selling.

Abschließend erfolgt eine Zusammenfassung der Inhalte dieser Arbeit und es wird ein Ausblick auf mögliche Entwicklungstendenzen einer SOA-basierten BI-Architektur gegeben. Abb. 1 fasst die Struktur dieser Arbeit zusammen.

2 Anforderungen an Systeme zur Managementunterstützung

In diesem Kapitel soll zunächst ein Überblick über die historische Entwicklung von Systemen zur Managementunterstützung gegeben werden. Anschließend erfolgt die Darstellung allgemeiner Anforderungen an solche Systeme. Aufgrund der hohen Bedeutung und auch weil hieran die Mängel dargestellt werden können, sollen die Grundlagen zum heute in Unternehmen verwendeten Begriff „Business Intelligence“ (BI) gesetzt werden. BI in der derzeitigen Form kann nicht alle Anforderungen an MUS erfüllen. Deshalb werden in diesem Zusammen­hang die Defizite veranschaulicht und offene Anforderungen abgeleitet.

2.1 Entwicklung und Bedeutung

Von jeher ist es das Ziel von Unternehmen, mittels IT-Unterstützung die Entscheidungsgrundlagen für das Management zu verbessern. Der Wunsch, Software einzusetzen, die dem Management Informationen zu Analyse- und Planungstätigkeiten zur Verfügung stellt, kam schon bald nach der Einführung von Datenbanken auf.^[3] Der Begriff einer „IT-basierten Management­unterstützung“ entstand mit dem Beginn der kommerziellen Nutzung der elektronischen Datenverarbeitung in den 60er Jahren des vergangenen Jahrhunderts.^[4] Ziel war es, aus den betrieblichen Daten Informationen zur Managementunterstützung zu generieren. Eine Vielzahl von Projekten beschäftigte sich mit dem Aufbau von Managementinformationssystemen (MIS). Jedoch bestand zwischen den Anforderungen an diese Systeme und den technischen Realisierungsmöglichkeiten eine große Diskrepanz. Hierfür waren insbesondere die begrenzten Speicher- und Verarbeitungskapazitäten verantwortlich.^[5] Auch fehlte den MIS der frühen Generation eine Interaktivität und Dialogfähigkeit mit den Anwendern. Der Begriff Management­informationssystem (MIS) wird in der Literatur nicht einheitlich verwendet.^[6] (Hansen/Neumann 2001) verwenden diesen Begriff z.B. gleichbedeutend mit MUS.^[7]

In einer nächsten Entwicklungswelle entstanden in den 70er Jahren sog. Entscheidungsunterstützungssysteme (EUS)^[8], die für diese Schwachpunkte Abhilfe schaffen sollten. Zwar konnten EUS die Entscheidungsträger wesentlich besser unterstützen, Ergebnis waren aber auch losgelöste monolithische Anwendungen, die nur schwer in ein unternehmensweites DV-Konzept integrierbar waren.

In der weiteren Entwicklung entstanden Führungs­informationssysteme (FIS)^[9], die neben den reinen Informations­systemen auch Kommunikations­komponenten enthielten. Dadurch sollte die Entscheidungsunterstützung weiter verbessert werden. Auch FIS sind nicht frei von Kritik. Insbesondere wird bemängelt, dass diese Systeme nur mit erheblichem Aufwand aufgebaut werden können und dann im Unternehmen nur einer begrenzten Anzahl an Nutzern bereitgestellt werden. Abb. 2 stellt die Klassifizierung der vorgestellten Systeme dar.^[10]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Komponenten von MUS

Die Notwendigkeit von MUS liegt ursächlich in den hohen und weiter steigenden Anforderungen an die Unternehmen, Entscheidungen bei steigender Komplexität und steigendem Konkurrenzdruck in immer kürzeren Zeiträumen zu treffen. Die zunehmende Globalisierung, die wachsenden Anforderungen der Stakeholder - wodurch sich steigende Governance-Anforderungen entwickeln – und die verbesserten technologischen Entwicklungen – wie beispielsweise die rasante Entwicklung im E-Business - zwingen MUS zu einer hohen Dynamik und Komplexität sowie noch größerer Funktionsvielfalt.^[11]

Das partielle Scheitern von MUS-Systemen in der betrieblichen Praxis ist jedoch nicht zuletzt auch darauf zurückzuführen, dass ein Informationssystem immer nur als Teil eines umfassenden Führungssystems verstanden werden kann und eine Abstimmung mit Organisationsstrukturen und Ablaufprozessen als unabdingbare Voraussetzung für die erfolgreiche Einführung zu werten ist.^[12] Durch die im Zeitverlauf oftmals gewachsenen Informationssysteme entstehen teilweise redundante Informationen oder sogar widersprüchliche Aussagen, welche die Akzeptanz der Informationssysteme bei den Anwendern senken oder die Systeme überflüssig machen. Trotz solcher gescheiterten bzw. bedingt erfolgreichen Versuche, Systeme zur Managementunterstützung einzuführen, sind diese heute weit verbreitet und nicht mehr aus der betrieblichen Unternehmenspraxis wegzudenken.

2.2 Begriffsbestimmung und -abgrenzung

Aus der Begrifflichkeit „Managementunterstützungssysteme“ gehen bereits die wesentlichen Anforderungen hervor: es sollen in den Unternehmen Systeme bereitgestellt werden, die das Management bei ihren Hauptaufgaben unterstützen. Zu den grundlegenden Managementaufgaben zählen im Wesentlichen Aufgaben des dispositiven Faktors: Ziele setzen, Planen, Entscheiden, Realisieren, Kontrollieren.^[13] Bestandteil dieser Teil-Aufgaben ist die Kommunikation, um die festgelegten Ziele, Pläne und Entscheidungen im Unternehmen bekannt zu machen. MUS müssen alle diese grundlegenden Aufgaben des Managements unterstützen und lassen sich folgendermaßen definieren:^[14]

Abbildung in dieser Leseprobe nicht enthalten

Eine weitere in der Literatur zu findende Einteilung der unter MUS klassifizierten Systeme orientiert sich an der Einteilung der Aufgaben von Top-, Middle- und Lower-Management. Je nach Entscheidungstragweite werden die Ebenen in strategisch, taktisch und operativ gegliedert, was Abb. 3 verdeutlicht.^[15]

(Kemper/Mehanna/Unger 2004) äußern Kritik an dieser Einteilung. Insbesondere wird bemängelt, dass sich heute sowohl auf Managementebene als auch auf Anwendungs- und Datenebene diese Einteilung so nicht mehr unterscheiden lässt.^[16]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Traditionelle Abgrenzung nach Unternehmens-/Managementebenen^[17]

Der Begriff MUS hat sich auch heute gehalten, er ist jedoch vorwiegend in der Wissenschaft zu finden. In der betrieblichen Praxis hat sich stattdessen der Begriff „Business Intelligence“ (BI) durchgesetzt.^[18] BI ist in den Unternehmen weit verbreitet und soll auch in Hinblick auf die Darstellung bestehender Mängel in der weiteren Arbeit - synonym für MUS - untersucht werden.

2.3 Business Intelligence

Im Folgenden soll zunächst eine Art Bestandsaufnahme des Begriffs Business Intelligence (BI) durchgeführt werden. Es wird analysiert, was unter BI zu verstehen ist und daraus wird eine Definition des Begriffs abgeleitet.

Ziel der Arbeit ist es, die Anforderungen an Systeme zur Managementunterstützung im Rahmen einer SOA zu erarbeiten. Hierzu ist es auch wichtig zu verstehen, wie bisherige BI-Architekturen aufgebaut sind und wie BI-Prozesse in einer solchen Architektur ablaufen. Daher werden Aufbau und Ablauf einer „traditionellen“ BI-Architektur dargestellt.

Aus dem bisherigen Begriffsverständnis von Business Intelligence ergeben sich eine Reihe von Defiziten. Diese BI-Defizite und Faktoren, die auf BI-Anforderungen einwirken, werden zusammengetragen und es folgt die Veranschaulichung der Defizite anhand eines Beispiels aus dem Vertrieb.

Zunächst wird jedoch im nächsten Abschnitt ein Begriffsverständnis für BI erarbeitet.

2.4 Begriffsbestimmung

BI genauer zu definieren, gestaltet sich schwerer als es vielleicht vordergründig erscheint. (Mertens 2002) konnte in einer Untersuchung folgende Abgrenzungen zum Begriff Business Intelligence identifizieren:^[19]

- BI als Fortsetzung der Daten- und Informationsverarbeitung: für die Unternehmensleitung
- BI als Filter in der Informationsflut: Informationslogistik
- BI = MIS
- BI als Frühwarnsystem
- BI = Data Warehouse
- BI als Informations- und Wissensspeicherung
- BI als Prozess: Symptomerhebung è Diagnose è Therapie è Prognose è Therapiekontrolle

Hieraus ergibt sich eine vieldeutige Verwendung des Begriffs Business Intelligence. Es muss daher zunächst ein genaues Begriffverständnis erarbeitet werden. (Kemper/Mehanna/Unger 2004) unterscheiden zunächst drei Arten von Begriffsverständnissen:^[20]

- Enges BI-Verständnis: es werden die BI-Kernapplikation zur Entscheidungsfindung betrachtet, z.B. Online Analytical Processing (OLAP), MIS/FIS.
- Analyseorientiertes BI-Verständnis: BI-Kernapplikationen und Applikationen zum Text Mining, Data Mining, Ad-hoc Reporting und auch Balanced Scorecard-Systeme. In diesem Verständnis steht der Zugriff auf die Systeme im Vordergrund.
- Weites BI-Verständnis: Applikationen zur Präsentation und zur Datenaufbereitung und –speicherung. Es werden nicht nur direkt zugreifbare Applikationen betrachtet, sondern auch indirekt unterstützende Systeme.

Das weite BI-Verständnis kommt insbesondere den Software-Anbietern entgegen, da es Anwendungen in den Vordergrund stellt. Diese Sicht behebt aber nicht die wesentlichen Fehlentwicklungen aus der Vergangenheit von MUS. Einerseits entstanden in einer Vielzahl von Projekten durch monolithische Anwendungen Informationssilos, andererseits wurden die unternehmens­spezifischen Anforderungen vernachlässigt. Ziel bei der Implementierung von Business Intelligence in den Unternehmen muss es aber sein, dass sich die IT an den individuellen organisatorischen und fachlichen Anforderungen in den Unternehmen orientiert. Damit bekommt BI einen viel weiteren, integrativen Charakter, der sich auch in folgender Definition von BI widerspiegelt:^[21]

Unter Business Intelligence wird ein integriertes IT-Gesamtkonzept verstanden, das für die unterschiedlichen Ausprägungen der Anforderungen an geeignete Systeme zur Entscheidungsunterstützung, tragfähige und miteinander verknüpfte Lösungen anbietet.

Es wird nach dieser Definition eine BI-Systemarchitektur benötigt, die sich an die unternehmensindividuellen Bedürfnisse anpassen lässt. Eine solche Architektur wird im nächsten Abschnitt dargestellt.

2.5 Systemarchitektur

Eine BI-Systemarchitektur lässt sich grob in die zwei Teilbereiche: den der Datenbereitstellung sowie den der darauf aufsetzenden Datennutzung unterteilen.^[22] Es geht auf diesen zwei Ebenen um die Verarbeitung von Daten sowie die Generierung von Informationen. Die zwei Teilbereiche lassen sich in verschiedene Ebenen unterteilen. Business Intelligence Systeme gliedern sich in die Ebenen: Datenzugriff auf operative und externe Daten, Integration der Daten für eine Datenspeicherung in ein Data Warehouse sowie anschließende Generierung von Informationen und Bereitstellung zur Nutzung mittels geeigneter Anwenderwerkzeuge. Diese Ebenen sowie deren Zusammenhänge sind in Abb. 4 der folgenden Abbildung dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Komponenten und Prozesse von Business Intelligence Systemen^[23]

Hauptaufgabe der Datenintegration ist es, die Daten aus den verschiedenen internen und externen operativen Vorsystemen in die Datenhaltungs­komponenten zu überführen. Hierzu bedarf es mächtiger Werkzeuge, die in der Lage sind, die umfangreichen Daten zu verarbeiten. Als Prozess für die Datenintegration hat sich in der Praxis der Begriff ETL etabliert. ETL umfasst das Extrahieren (Extract) der Daten aus den Vorsystemen, das Transformieren (Transform), indem die Rohdaten bereinigt und transformiert werden sowie das Laden (Load) in die Datenhaltungskomponente.

Als Datenhaltungskomponente findet in BI-Systemarchitekturen das Data Warehouse-Konzept Anwendung. Ein Data Warehouse (DWH) lässt sich wie folgt definieren:^[24]

Abbildung in dieser Leseprobe nicht enthalten

Ein DWH-System ist somit durch folgende Merkmale gekennzeichnet:^[25]

- Subjektorientierung: auch als interessierende Kerngebiete bezeichnet. Beispiele sind Kunde-, Zeit-, Region- und Produktstrukturen.
- Integration: Informationen werden aus einer inhaltlich widerspruchsfreien Sammlung von operativen und externen Daten gewonnen.
- Zeitraumbezug: Daten werden über Tage, Wochen und Monate historisch vorgehalten.
- Nicht-Volatilität: im Gegensatz zu den operativen Daten ändern sich die Daten nicht, sondern sind dauerhaft abgelegt

Während es sich bei einem Data Warehouse um eine umfassende und unternehmensweite Datenhaltung handelt, können für spezielle Anforderungen zusätzlich sog. Data Marts aufgebaut werden. Hierbei handelt es sich um funktions- oder abteilungsspezifische Daten, die aus dem Data Warehouse stammen. Es kann eine sog. Hub&Spoke-Architektur aufgebaut werden, in der das DWH als zentraler Datenlieferant für die Data Marts agiert.

Weiterhin können für Analysezwecke zusätzliche Datenaufbereitungsschritte erforderlich sein. Eine Möglichkeit besteht in der logischen Modellierung der Daten für die Anwenderwerkzeuge. Ein anderes Vorgehen ist der Aufbau einer für spezielle Analysezwecke aufbereiteten Datenbasis, mit der eine mehrdimensionale Sicht auf betriebswirtschaftlich aufbereitete Größen ermöglicht wird.^[26] Hierfür hat sich der Begriff OLAP durchgesetzt.

Die Ebene der Anwendungswerkzeuge ist aufgrund der Vielzahl an Werkzeugen unübersichtlich. Eine Klassifizierung der Werkzeuge wird in (Gluchowski/Kemper 2006) in Form eines Schalenmodells vorgenommen, wonach drei Ebenen unterschieden werden können:

- Generische Berichtssysteme,
- Konzeptorientierte Systeme,
- Präsentations- und Zugangssysteme.

Den Kern bilden die generischen Systeme, die als BI-Basis bezeichnet werden können und sich dadurch auszeichnen, dass diese Systeme anwendungsunabhängig sind. Hierdurch ergibt sich eine breite Einsatzmöglichkeit dieser Werkzeuge in den Unternehmen. Aufbauend auf den BI-Basissystemen werden konzeptorientierte Systeme entwickelt bei denen die technische Realisierung betriebswirtschaftlicher Konzepte im Vordergrund Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Schalenmodell der BI-Werkzeuge zur Datennutzung^[27]

steht. Damit sind diese Systeme im Gegensatz zu den BI-Basissystemen anwendungsspezifisch. Letztendlich müssen alle Informationen und Funktionen adäquat bereitgestellt werden. Hierfür sind geeignete Präsentations- und Zugangssysteme auszuwählen. Abb. 5 zeigt gängige Werkzeuge sowie eine Kategorisierung dieser Werkzeuge in Präsentations- und Zugangssysteme, Konzeptorientierte Systeme sowie Generische Berichtssysteme.

2.6 Anforderungen und Defizite

Obwohl Business Intelligence heute als ein Standard für Unternehmen zu betrachten ist und sich damit für die Unternehmen als erfolgskritisch erweist, gibt es eine Reihe von Anforderungen, die im Zusammenhang mit BI bis heute nicht oder nur schwer realisiert werden können. Als Ursachen hierfür sind insbesondere technologische Defizite zu nennen, die die BI-Technologie selbst betreffen. Hinzu kommen Umwelteinflüsse und Rahmenbedingungen, die sich auf die Unternehmensanforderungen auswirken. Defizite und daraus resultierende Anforderungen werden im Folgenden beschrieben.

Zeitversetzte Informationsbereitstellung: Eine Herausforderung traditioneller BI-Systeme stellt die Überwindung der zeitversetzten Informationsbereitstellung dar. Für heutige BI-Systeme entstehen sowohl für die Datenaufbereitung als auch für die Informationsbereitstellung zeitliche Aufwände, wodurch sog. Latenzen - vom Eintritt eines Ereignisses bis zur letztendlichen Umsetzung einer Aktion - entstehen. Eine zeitnahe Bereitstellung mit möglichst geringer Verzögerung – wie es insbesondere auf operativer Ebene erforderlich ist, kann mittels traditioneller BI-Systeme nicht gewährleistet werden. Allgemein kann von einem Verlust des Informationsgehalts im Zeitverlauf gesprochen werden, d.h. je später die Daten- bzw. Informationsbereitstellung erfolgt, desto geringer sind die Möglichkeiten erfolgswirksame Entscheidungen zu treffen. Neben der zeitlich versetzten Bereitstellung kommt es zu Verzögerungen durch die Entscheidungsmaßnahmen (Entscheidungslatenz) selbst und die Realisierung von Maßnahmen (Umsetzungslatenz). Ein solcher idealtypischer Verlauf, der den Zusammenhang zwischen dem Wert eines Ereignisses beim Eintreffen und die Wertentwicklung im Zeitverlauf bis zur umgesetzten Maßnahme darstellt, wird in Abb. 6: Echtzeit und Aktionszeit gezeigt.^[28]

Kein Einsatz auf operativer Ebene: Die beschriebenen Umsetzungs­latenzen führen dazu, dass das Einsatzgebiet heutiger BI-Systeme insbesondere auf strategischer und taktischer Ebene liegt. Ein Einsatz auf operativer Ebene kann häufig nicht stattfinden, da Informationen nicht in der Zeitnähe vorliegen, in denen die operativen Prozesse erfolgen und in denen sie „rechtzeitig“ anpassbar wären.^[29]

Retrospektive Betrachtungsweise: Die im Data Warehouse ge­speicherten Daten stehen für eine vergangenheitsorientierte Betrachtungsweise zur Verfügung. Beispielsweise werden Kennzahlen erzeugt, die Werte zu den Vorjahreswerten vergleichen und damit eine retrospektive Betrachtung verfolgen. Der Fokus liegt auf Analyse und Diagnose. Das Potential prädiktiver Modelle zum rechtzeitigen Erkennen und Vermeiden von Problemen und Risiken wird nicht genutzt.^[30]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Echtzeit und Aktionszeit

Fehlende Rückkopplungskomponente: Technologische Defizite sind weiterhin in fehlenden Rückkopplungskomponenten von BI-Systemen zu sehen, da auf Basis von vorliegenden Informationen keine automatisierten Entscheidungen getroffen werden können. Dieser Schritt ist in der Regel ein manueller Vorgang. Heutige BI-Systeme basieren im Wesentlichen auf einem Informations­bereitstellungs­modell. Ergebnis sind in der Praxis häufig zu viele Berichte, die nicht selten in endlosen Zahlenkolonnen enden. Hieraus resultieren zwei wesentliche Problembereiche: zum einen ergibt sich ein erhöhter Suchaufwand, da die wirklich relevanten Informationen aus der Vielzahl der Berichte herausgesucht werden müssen. Weiterhin kommt es zu Performanceproblemen.

Performanceprobleme: Auch durch die Vielzahl an Berichten gibt es erhöhte Anforderungen an die Datenbereitstellung: es müssen Daten für eine Vielzahl unterschiedlicher Berichtsanforderungen, in unterschiedlicher Detaillierung und für verschiedene Abteilungen vorgehalten werden, wodurch häufig die Performanceprobleme entstehen. Der steigenden Flut von historisierten Datenbeständen im unternehmensweiten Data Warehouse und den damit verbundenen Performanceproblemen stehen häufig keine probaten Lösungen gegenüber. Der Wettlauf gegen den stetig wachsenden Datenstrom, welcher in Realzeit zu Wissen veredelt werden soll, stellt eine große Herausforderung dar.^[31]

Funktional getriebener Einsatz von BI-Werkzeugen: Bei Betrachtung der heutigen Einsatzgebiete von BI-Systemen in den Unternehmen fällt auf, dass in den Unternehmen eine Vielzahl unterschiedlicher BI-Werkzeuge abteilungsspezifisch eingesetzt werden. BI ist heute also stark funktional getrieben. Die unternehmerische Wertschöpfung findet dagegen in Geschäftsprozessen statt. Daher ist eine Betrachtung rein statischer Ergebniskennzahlen nicht ausreichend. Erst die Bewertung der Leistungsfähigkeit der Geschäftsprozesse komplettiert das Bild der tatsächlichen Unternehmensleistung.^[32]

Pflege-, Wartungs- und Schulungsintensiv: Als Konsequenz eines abteilungspezifischen Einsatzes von BI-Systemen müssen die Mitarbeiter in den Abteilungen für die Berichtsentwicklung mittels BI-Werkzeugen geschult werden. Dieser dezentrale Einsatz von BI-Werkzeugen führt zu erhöhten Kosten im Unternehmen. Weiterhin sind die BI-Werkzeuge zumeist durch die IT-Abteilung zu administrieren, was beim Einsatz von BI-Werkzeugen verschiedener Hersteller zu einem zusätzlichen Aufwand führt.

Prozesse zur Sicherung der Datenqualität erforderlich: Im traditionellen BI wird auf die unterschiedlichsten Systeme zugegriffen, in denen die Daten in unterschiedlichster Qualität vorliegen. Dies erfordert teilweise umfangreiche Maßnahmen zur Verbesserung der Datenqualität.

Neben den hier aufgeführten technologischen Defiziten, verändern sich auch die Rahmenbedingungen, mit denen sich die Unternehmen auseinanderzusetzen haben^[33]. Heute sind nahezu sämtliche Unternehmen von einer zunehmenden Globalisierung betroffen, wodurch ein zunehmender Wettbewerb entsteht. Herausforderung für die Unternehmen ist es, möglichst flexibel auf die sich wechselnden Anforderungen zu reagieren und auch die Informationssysteme müssen diese Veränderungen flexibel adaptieren können.^[34]

[...]

---

^[1] Vgl. (Allweyer 2005), S.4ff.

^[2] (Kemper/Mehanna/Unger 2004), S.2.

^[3] (Hannig 2006), S.3.

^[4] (Kemper/Mehanna/Unger 2004), S.1.

^[5] (Hannig/Schwab/Findeisen 1998), S.1.

^[6] Vgl. (Kemper/Mehanna/Unger 2004), S.114.

^[7] (Hansen/Neumann 2001), S.453;

^[8] Im Angelsächsischen: Decision Support System (DSS).

^[9] Im Angelsächsischen:Executive Information System (EIS).

^[10] In Anlehnung an (Chamoni/Gluchowski 2006), S.9.

^[11] (Gluchowski/Kemper 2006), S.12.

^[12] (Chamoni/Gluchowski 2006), S.8.

^[13] (Wöhe 1993), S.99.

^[14] (Ehrenberg 2004).

^[15] In Anlehnung an (Kemper/Mehanna/Unger 2004), S.81.

^[16] Vgl. (Kemper/Mehann/Unger 2004), S.81.

^[17] Zu den Begriffen OLAP und Data Mining siehe Abschnitt 2.3.2.

^[18] Vgl. (Kemper/Mehann/Unger 2004), S.2.

^[19] (Mertens 2002), S. 4.

^[20] (Kemper/Mehanna/Unger 2004), S.3f.

^[21] (Gluchowski/Kemper 2006), S.12.

^[22] Vgl. (Gluchowski/Kemper 2006), S. 12.

^[23] (Bange 2006), S. 89.

^[24] Vgl. (Inmon 2002), S.31.

^[25] Vgl. auch (Kemper/Mehanna/Unger 2004), S.17f.

^[26] Vgl. (Chamoni 2001), S. 346.

^[27] (Gluchowski/Kemper 2006), S.16.

^[28] In Anlehnung an (Schelp 2006), S.427. Diese Darstellung bezieht sich auf das Eintreten eines einfachen Ereignisses. Der Verlauf einer Latenzkurve kann in komplexen Ereignissen auch wesentlich komplexer verlaufen. Vgl. hierzu auch (Schelp 2006), S.428f.

^[29] Vergl. (Martin/Nußdörfer 2006), S.11.

^[30] (Martin/Nussdörfer 2006), S.11.

^[31] Vergl. (Chamoni 2006), S.5:

^[32] Vergl. (Dinter/Bucher 2006), S. 25.

^[33] (Gluchowski/Kemper 2006),S.18.

^[34] (Kemper/Mehanna/Unger 2004), S.5f.