Entwicklung und Anwendung eines Vorgehensmodells zur Evaluation und Auswahl von Open Source Business Intelligence Systemen

Diplomarbeit von Sören Stuckenbrock

Einleitung:

Freie Software ist heute für den Einsatz in unterschiedlichen Unternehmensbereichen etabliert. Historisch bedingt liegen ihre Stärken in technikorientierten Einsatzgebieten, wie Betriebssystemen und Netzwerkdiensten, da die meisten freien Softwareprojekte zunächst primär von Technikern zur Lösung ihrer eigenen Problemstellungen entwickelt wurden. Doch auch in Bereichen der anwendungsbezogenen Software setzt sich das Open Source Prinzip mittlerweile durch.

Innerhalb der Domäne der betriebswirtschaftlichen Anwendung ist besonders im Segment der analytischen Informationssysteme eine hohe Entwicklungsdynamik von Open Source Software (OSS) zu verzeichnen. Im Wachstumsmarkt der Business Intelligence (BI) – so der Überbegriff für aktuelle, IT-basierte Ansätze zur Versorgung des Managements mit entscheidungsrelevanten Informationen – gewinnen quelloffene Softwarelösungen an Popularität.

Während freie Software für die Initiatoren der Bewegung eine Ideologie darstellt, wird sie in anwendenden Unternehmen hingegen meist pragmatisch betrachtet. Die Mehrzahl von ihnen führt die Reduzierung von Kosten als wichtigsten Beweggrund für den Einsatz freier Software an. Dieser antizipierte Kostenvorteil lässt sich bezogen auf die reinen Lizenzierungskosten stichfest belegen, denn der überwiegende Teil der Open Source Produkte ist kostenlos oder gegen geringe Lizenzgebühren zu beziehen. Bei der Einführung komplexer Softwaresysteme im Unternehmensumfeld fallen jedoch zusätzlich zu den Lizenzkosten weitere Kosten an, welche bisweilen weit höher ausfallen können. Diese Tatsache trifft auch auf Business Intelligence Systeme zu, deren Einführung üblicherweise Projektcharakter besitzt.

Kosten und Risiken entstehen bereits bei der Evaluation und der Auswahl einer für den jeweiligen unternehmensindividuellen Einsatzzweck geeigneten Lösung.Werden diese Tätigkeiten nicht strukturiert und fundiert durchgeführt, steigt das Risiko eines vorzeitigen Projektabbruchs oder zumindest eines suboptimalen Projektergebnisses. Für Open Source Lösungen gilt dies insbesondere, da bei deren Einführung oft kein Anbieter oder Dienstleister seine Projekterfahrung in das Einführungsprojekt einbringt.

Somit verwundert es nicht, dass in einer Untersuchung des amerikanischen Marktforschungsunternehmens Aberdeen die Open Source Business Intelligence Lösungen von Pentaho und Jaspersoft einerseits zwar sehr häufig in erfolgreichen BI-Projekten eingesetzt werden, diese auf der anderen Seite jedoch auch zu den Spitzenreitern bei den weniger erfolgreichen BI-Implementierungen zählen.

Um von den Vorzügen zu profitieren, welche Open Source Software neben geringeren Anschaffungskosten bietet, müssen Unternehmen demnach sehr genau prüfen, ob der Einsatz quelloffener Lösungen für ihr Vorhaben in Frage kommt, und welches Produkt – beziehungsweise welche Kombination von Produkten – eine optimale Zielerreichung verspricht. Da Open Source Software meist frei aus dem Internet bezogen werden kann, besteht prinzipiell die Möglichkeit, verschiedene Produkte herunterzuladen und auszuprobieren, bis eine akzeptable Lösung gefunden wurde. Eine solche Vorgehensweise wäre jedoch ineffizient und die Wahrscheinlichkeit gering, das unter strategischen Gesichtspunkten bestgeeignete Produkt zu wählen.

Ziel der vorgestellten Arbeit ist die Entwicklung und Beschreibung eines Handlungsrahmens zur systematischen Evaluation und Auswahl von Open Source Business Intelligence Systemen.

Das resultierende Vorgehensmodell soll auf verschiedene Unternehmen anwendbar sein und muss aus diesem Grund mit Gegebenheiten des jeweilig betrachteten Unternehmens parametrierbar sein. Eine in ökonomischer Hinsicht optimierte Vorgehensweise in der Evaluations- und Auswahlphase ist ein weiterer Anspruch, den das zu entwickelnde Vorgehensmodell erfüllen soll. Darüber hinaus soll die Praxistauglichkeit des entwickelten Modells demonstriert werden.

Die Ausführungen beziehen sich explizit auf die Evaluations- und Auswahlphase von BI-Projekten. Demnach stellt das Ergebnis der Arbeit kein Vorgehensmodell für die Abwicklung kompletter BI-Projekte dar. Insofern wird auf Aspekte nachfolgender Projektphasen nur in dem Rahmen eingegangen, in dem sie für Entscheidungen oder Handlungen in der thematisierten Projektphase von Bedeutung sind. Vorgehensweise und Aufbau der Arbeit:

Die Entwicklung des Vorgehensmodells erfolgt auf Basis des Transfers und der Kombination gesicherter Erkenntnisse aus den Bereichen:

• Business Intelligence.

• Softwaretechnik / Softwareauswahl / Open Source Software.

• Evaluation / Evaluationsforschung.

Hierzu werden in Kapitel 2 die zum Verständnis der weiteren Ausführungen erforderlichen Grundlagen erörtert.

Darauf aufbauend erfolgt die eigentliche Konzeption des Modells in Kapitel 3. Da der Auswahl von Software grundsätzlich eine Definition der Anforderungen vorausgehen muss, beginnt die Ausarbeitung des Modells mit eben dieser Problematik, unter Berücksichtigung unternehmensindividueller Parameter. Im weiteren Verlauf der Konzeption wird die Ermittlung der zur Erfüllung der zuvor definierten Anforderungen erforderlichen BI-Werkzeuge und deren notwendiger Leistungsumfang beschrieben. Abgeschlossen wird das Vorgehensmodell durch eine Handlungsempfehlung zur Abbildung der bis dorthin ermittelten Ergebnisse auf den vorhandenen Markt der Open Source Business Intelligence Lösungen. Bei allen genannten Schritten wird – sofern erforderlich – auf die Besonderheiten von Open Source Software eingegangen.

Um die Praxistauglichkeit des entwickelten Vorgehensmodells zu verifizieren, wird dieses in Kapitel 4 beispielhaft auf ein Unternehmen angewendet. Nach einer kurzen allgemeinen Vorstellung des Unternehmens wird die Ist-Situation im BI-Umfeld innerhalb des Unternehmens betrachtet, die Anforderungen an den Ausbau der vorhandenen BI-Lösung beschrieben und anschließend, unter Anwendung des zuvor erarbeiteten Konzepts, die Evaluation und Auswahl der geeigneten Open Source BI Applikationen vorgenommen.

Die Arbeit schließt in Kapitel 5 mit einer kritischen Würdigung der Vorgehensweise, einem Fazit und einem Ausblick auf mögliche Ergänzungen des entwickelten Modells sowie einer Zusammenfassung ab.

Inhaltsverzeichnis:

	Abbildungsverzeichnis	V
	Tabellenverzeichnis	VI
	Abkürzungsverzeichnis	VII
1.	Einleitung	1
1.1	Problembereich	1
1.2	Ziel der Arbeit	3
1.3	Vorgehensweise und Aufbau der Arbeit	3
2.	Grundlagen	5
2.1	Business Intelligence	5
2.1.1	Definition	5
2.1.2	Anwendungsgebiete	6
2.1.2.1	Vorbemerkung	6
2.1.2.2	Berichte	7
2.1.2.3	Cockpits, Kennzahlensysteme und Scorecards	7
2.1.2.4	Ad-Hoc-Analyse	8
2.1.2.5	Hypothesenfreie Analyse / Wissensentdeckung	8
2.1.2.6	Externes Rechnungswesen und Konsolidierung	8
2.1.2.7	Planung und Simulation	9
2.1.3	Technologien	9
2.1.3.1	Vorbemerkung	9
2.1.3.2	Datenintegration / ETL	9
2.1.3.3	Data Warehouse	10
2.1.3.4	Online Analytical Processing	10
2.1.3.5	Reporting	11
2.1.3.6	Data Mining	12
2.1.4	Standards	13
2.1.5	Ordnungsrahmen	13
2.2	Evaluation und Auswahl von Software	14
2.2.1	Einordnung in den Prozess der Systementwicklung	14
2.2.2	Evaluation im Kontext der Wirtschaftsinformatik	14
2.2.3	Nutzwertanalyse	16
2.2.4	Prototyping	16
2.2.5	Vergleich vorhandener Vorgehensmodelle	17
2.3	Open Source Software	18
2.3.1	Historie und Definition	18
2.3.2	Motive für den Einsatz	19
3.	Konzeption eines Vorgehensmodells	21
3.1	Betrachtung von Open Source Business Intelligence Systemen als Standardsoftware	21
3.2	Einordnung in den Lebenszyklus von BI-Systemen	21
3.3	Überblick über die Phasen des Auswahlprozesses	22
3.4	Ziele von BI-Projekten	25
3.5	Anforderungen	29
3.5.1	Vorbemerkung	29
3.5.2	Ist-Analyse	30
3.5.3	Soll-Konzept	32
3.5.3.1	Anwendungsportfolio	32
3.5.3.2	Gesamtarchitektur	36
3.5.3.3	Reporting	41
3.5.3.4	Online Analytical Processing	45
3.5.3.5	Data Mining	48
3.5.3.6	Datenintegration / ETL	51
3.6	Marktübersicht	55
3.7	Produktvergleich und Entscheidung	56
3.7.1	Vorbemerkung	56
3.7.2	Grobauswahl	57
3.7.2.1	Allgemeine Ausschlusskriterien für Open Source Software	57
3.7.2.2	Ausschlusskriterien für Open Source Business Intelligence Produkte	59
3.7.3	Feinauswahl	62
3.7.3.1	Allgemeine Gewichtungskriterien für Open Source Software	62
3.7.3.2	Gewichtungskriterien für Open Source Business Intelligence Produkte	63
3.7.4	Entscheidung	64
3.8	Verifikation	64
4.	Anwendung des Vorgehensmodells auf ein Beispielunternehmen	66
4.1	Beispielunternehmen und Ausgangssituation	66
4.2	Ziele	67
4.3	Anforderungen	68
4.3.1	Ist-Analyse	68
4.3.2	Soll-Konzept	69
4.3.2.1	Anwendungsportfolio	69
4.3.2.2	Gesamtarchitektur	70
4.3.2.3	Reporting	70
4.3.2.4	Datenintegration / ETL	72
4.4	Marktübersicht	72
4.5	Produktvergleich und Entscheidung	73
4.5.1	Grobauswahl	73
4.5.2	Feinauswahl	76
4.5.3	Entscheidung	77
4.6	Verifikation	77
5.	Schluss 79
5.1	Erfolgsfaktoren und kritische Würdigung der Vorgehensweise	79
5.2	Fazit und Ausblick	80
5.3	Zusammenfassung	81
	Literaturverzeichnis	VIII
	Anhang
A	Einstiegspunkte für eine Marktrecherche im Open Source Business Intelligence Segment	XIV
B	Screenshots der Feinauswahl und Verifikation	XV

Textprobe:

Kapitel 4, Anwendung des Vorgehensmodells auf ein Beispielunternehmen:

4.1, Beispielunternehmen und Ausgangssituation:

Die XXXXXXXX AG ist gemessen am Umsatz, welcher im Geschäftsjahr 2009 rund 310 Mio. Euro betrug, nach eigener Aussage Marktführer im europäischen Online- Reifenhandel. Das Unternehmen ist sowohl im Endkundengeschäft als auch im Großhandel aktiv. Die Preiskalkulation, Auftragsabwicklung und Lagerverwaltung wird über eigens hierfür entwickelte Software abgewickelt, welche seit der Unternehmensgründung im Jahr 1999 kontinuierlich weiterentwickelt wurde. Aufgrund der Neuartigkeit des Geschäftsmodells hat sich die Entscheidung für die Individualentwicklung der operativen Anwendungssysteme im Falle der XXXXXXXX AG als zielführend herausgestellt.

Die analytische Informationsverarbeitung ist bisher direkt in diese operativen Systeme integriert, was nach aktuellen Erkenntnissen der Wirtschaftsinformatik als nicht mehr zeitgemäß beschrieben werden kann und bereits mehrfach zu Problemen im Betriebsablauf geführt hat. Beispielsweise musste im Saisongeschäft schon mehrmals die Verkaufsstatistik deaktiviert werden, da die aufwändigen Berechnungen die Systemressourcen auslasteten, was zu negativen Beeinträchtigungen des operativen Geschäfts führte, da die Internetshops auf denselben Systemen betrieben werden. Desweiteren soll die Agilität der analytischen Datenverarbeitung gesteigert werden. Durch den Einsatz spezifischer Software verspricht man sich eine leichtere Anpassbarkeit der Analysesysteme an die oft wechselnden Informationsbedürfnisse innerhalb der Entscheidungsprozesse als durch Individualentwicklung zu erreichen wäre. Darüber hinaus steigen mit dem Wachstum des Unternehmens auch die qualitativen Anforderungen an die analytische Datenverarbeitung. Was bisher überwiegend in Tabellenform dargestellt wurde, soll künftig auch grafisch visualisiert werden, um Entscheidern die Informationsaufnahme zu erleichtern.

Aufgrund dieser Erkenntnisse wurde entschieden, eine dispositive Datenverarbeitung einzuführen, welche weitgehend von den operativen Systemen entkoppelt ist. Erste Tests mit einem multidimensionalen Datenmodell in einer relationalen Datenbank wurden bereits unternommen und auf dieser Basis eine Absatzstatistik realisiert. Der hierfür erforderliche ETL-Prozess wurde eigens in C# programmiert. Um die zuvor bereits erwähnte Agilität zu erreichen, soll jedoch auch eine ETL-spezifische Software eingeführt werden. Da das Unternehmen im Bereich der operativen Systeme bereits stark auf Open Source Software setzt und gute Ergebnisse damit erzielt hat, ist man hierfür auch im Business Intelligence Segment generell aufgeschlossen.

4.2, Ziele:

Fachliche Ziele:

Im zurückliegenden Saisongeschäft wurde eine Häufung von Kundenbeschwerden bezüglich der Lieferzeit festgestellt. Um den Ursachen hierfür nachgehen zu können, regt die Logistikabteilung die Erstellung eines Logistikcockpits an, welches die durchschnittliche Dauer einzelner Prozessschritte des Kundenauftragsbearbeitungsprozesses bezogen auf Zeiträume, Lieferanten/ Lager, Produktgruppen und Paketdienste darstellt.

Architektonische Ziele:

Das dispositive Datenmodell muss zunächst den Informationsbedarf der Logistikabteilung decken. Zu einem späteren Zeitpunkt soll auch die bereits erwähnte Absatzstatistik in dieses Modell integriert werden. Das Modell ist somit fachbereichsübergreifend auszulegen. Die DV-Architektur soll den Aufbau und die Schnittstellen der Referenzarchitektur aus Abschnitt 3.5.3.2 ab Seite 36 besitzen, um die Nachhaltigkeit der Lösung zu fördern. Ein anwendungsübergreifender Verzeichnisdienst ist im Unternehmen bisher nicht verfügbar, weswegen diesbezüglich keine Anforderungen bestehen. Abhängigkeiten bezüglich der Kompatibilität bestehen somit lediglich zu:

Den operativen Datenquellen.

Den Systemplattformen, unter welchen die Arbeitsplätze der ETLEntwickler und Report-Designer laufen sowie den Serverbetriebsystemen der als ETL-Server und Report-Server vorgesehenen Systeme.

Der dispositiven Datensenke, denn an dieser Stelle soll keine Open Source Software zum Einsatz kommen. Für die bereits vorhandene Absatzstatistik wird der Microsoft SQL Server verwendet, welcher insbesondere im OLAP-Bereich sehr weit entwickelt ist und als Datenbanksystem für das komplette Data Warehouse Verwendung finden soll.

Technologische Ziele:

Um die Effizienz der ETL-Entwicklung zu steigern, soll diese auf die Verwendung dedizierter ETL-Software umgestellt werden. Es werden jedoch keine technologischen Leistungsparameter gefordert, welche erst bei zukünftigen Anwendungsszenarien ins Gewicht fallen.

Organisatorische Ziele:

Die BI-Entwicklungen sind in der Finanzabteilung des Unternehmens angesiedelt. Es sollen jedoch auch andere Unternehmensbereiche vom dort entwickelten BI-Know-How profitieren, indem für diese dienstleistungsmäßig BI-Anwendungen entwickelt werden. Die Reichweite der geplanten BILösung umfasst demnach das komplette Unternehmen.

Politische Ziele:

Politische Ziele stellen im vorliegenden Fall keine Motivation für den Einsatz von Open Source Software dar. Die Evaluation von Open Source Lösungen wird im Interesse der Kostensenkung durchgeführt.

4.3, Anforderungen:

4.3.1, Ist-Analyse:

Fachlicher Ist-Zustand:

Die absehbaren Anwendungen für die geplante BI-Lösung betreffen zwei Unternehmensbereiche: die Logistik (Logistik-Cockpit) und den Vertrieb (Absatzstatistik). Folgende Entscheidungsobjekte wurden für diese Bereiche identifiziert: – Logistik Zeiträume, Produkte/Produktgruppen, Paketdienste, Lieferanten/Lager – Vertrieb Zeiträume, Produkte/Produktgruppen, Absatzregionen, Kunden/Kundengruppen, Webshops Die vorhandenen Überschneidungen sprechen für eine integrierte Datenhaltung über beide Anwendungen.

Architektonischer Ist-Zustand:

Für das Vertriebscontrolling besteht bereits ein etabliertes mehrdimensionales Datenmodell. Das Datenmodell für das neu zu schaffende Logistik- Cockpit soll bestehende Dimensionen mitnutzen, sofern diese benötigt werden.