Warenkorb
0 Artikel | US$ 0,00
Autor
Sören Stuckenbrock
Entwicklung und Anwendung eines Vorgehensmodells zur Evaluation und Auswahl von
Open Source Business Intelligence Systemen
ISBN: 978-3-8428-1395-3
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2011
Zugl. AKAD Fachhochschule Pinneberg, Pinneberg, Deutschland, Diplomarbeit, 2010
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2011
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
II
Inhaltsverzeichnis
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 In-
telligence 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
III
Inhaltsverzeichnis
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
A n h a n g
A. Einstiegspunkte für eine Marktrecherche im Open Source Business
Intelligence Segment
XIV
B. Screenshots der Feinauswahl und Verifikation
XV
IV
Abbildungsverzeichnis
1.1. Verteilung von Business Intelligence Produkten auf erfolgreiche
und weniger erfolgreiche Implementierungen . . . . . . . . . . . .
2
2.1. Ordnungshierarchie für Berichtssysteme und Berichtsarten . . . .
7
2.2. Vorgehensmodell des Knowledge Discovery in Databases
. . . . .
12
2.3. Business Intelligence Ordungsrahmen . . . . . . . . . . . . . . . .
14
2.4. Einordnung des zu entwickelnden Vorgehensmodells in den Prozess
der Systementwicklung . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5. Vergleich von Phasenmodellen der Softwareauswahl . . . . . . . .
18
2.6. Motive für den Einsatz von Open Source Software . . . . . . . . .
20
3.1. Mögliche Zeitpunkte für Auswahlprozesse innerhalb des Lebenszy-
klus einer BI-Landschaft . . . . . . . . . . . . . . . . . . . . . . .
22
3.2. Beschaffung von Open Source Software . . . . . . . . . . . . . . .
23
3.3. Phasen des entwickelten Vorgehensmodells . . . . . . . . . . . . .
24
3.4. Orientierungsrahmen zur Eignung bestimmter BI-Anwendungen
für unterschiedliche Nutzergruppen . . . . . . . . . . . . . . . . .
34
3.5. Orientierungsrahmen zur Ableitung der benötigten BI-Werkzeuge
aus den geplanten BI-Anwendungen . . . . . . . . . . . . . . . . .
35
3.6. Best-of-Breed versus End-to-End BI-Ansätze . . . . . . . . . . . .
37
3.7. Referenzarchitektur für eine modulare Open Source Business In-
telligence Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.8. Fragestellungen, Aufgaben und Methoden des Data Mining . . . .
50
3.9. Kausalität der Bewertungskriterien für die Eignung von Open Sour-
ce Software Produkten für den unternehmenskritischen Einsatz . .
58
4.1. Konkrete Architektur der geplanten BI-Lösung . . . . . . . . . . .
71
B.1. MDX-Editor von Wabit
. . . . . . . . . . . . . . . . . . . . . . . XV
B.2. MDX-Editor von Jaspersoft . . . . . . . . . . . . . . . . . . . . . XVI
B.3. Entity-Relationship-Diagramm des Star-Schemas des Prototypen . XVII
B.4. Befüllung der Dimensionstabellen mittels Talend Open Studio . . XVIII
B.5. Befüllung der Faktentabelle mittels Talend Open Studio
. . . . . XIX
B.6. Durchschn. Auftragsbearbeitungszeit nach Produktgruppe in 2009 XX
B.7. Durchschn. Auftragsbearbeitungszeit nach Radtyp in 2009 . . . . XX
B.8. Durchschn. Auftragsbearbeitungszeit bei interner und externer Be-
schaffung in 2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI
V
Tabellenverzeichnis
3.1. Beispiele für zentrale und abteilungsspezifische Komponenten einer
BI-Landschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2. Unternehmensinterne Verantwortung für OSBI-Ziele . . . . . . . .
29
3.3. Anforderungsbereiche für Reporting-Lösungen und deren Herleitung 46
3.4. Anforderungsbereiche für OLAP-Server und deren Herleitung . . .
49
3.5. Anforderungsbereiche für Data Mining Werkzeuge und deren Her-
leitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.6. Anforderungsbereiche für ETL-Werkzeuge und deren Herleitung .
54
4.1. Grobauswahl der ETL-Anwendungen . . . . . . . . . . . . . . . .
74
4.2. Grobauswahl der Reporting-Anwendungen . . . . . . . . . . . . .
75
4.3. Feinauswahl der Reporting-Anwendungen . . . . . . . . . . . . . .
76
VI
Abkürzungsverzeichnis
BI
Business Intelligence
CDWH
Core DWH
CPM
Corporate Performance Management
CRM
Customer Relashionship Management
CWM
Common Warehouse Metamodell
DBMS
Datenbankmanagementsystem
DWH
Data Warehouse
DV
Datenverarbeitung
EAI
Enterprise Application Integration
ETL
Extraktion, Transformation, Laden
FASMI
Fast Analysis of Shared and Multidimensional Information
GUI
Graphical User Interface
HOLAP
Hybrides OLAP
IT
Informationstechnologie
JDBC
Java Database Connectivity
LDAP
Lightweight Directory Access Protocol
MDX
Multidimensional Expressions
MOLAP
Multidimensionales OLAP
ODBC
Open Database Connectivity
ODBO
OLE DB for OLAP
ODS
Operational Datastore
OLAP
Online Analytical Processing
OLE DB
Object Linking and Embedding, Database
OSBI
Open Source Business Intelligence
OSS
Open Source Software
RDBMS
Relationales DBMS
ROLAP
Relationales OLAP
SCD
Slowly Changing Dimensions
SQL
Structured Query Language
XML
Extensible Markup Language
XMLA
XML for Analysis
VII
KAPITEL
1
Einleitung
1.1. Problembereich
Freie Software ist heute für den Einsatz in unterschiedlichen Unternehmensberei-
chen etabliert
1
. Historisch bedingt liegen ihre Stärken in technikorientierten Ein-
satzgebieten, wie Betriebssystemen und Netzwerkdiensten, da die meisten freien
Softwareprojekte zunächst primär von Technikern zur Lösung ihrer eigenen Pro-
blemstellungen entwickelt wurden. Doch auch in Bereichen der anwendungsbezo-
genen Software setzt sich das Open Source Prinzip mittlerweile durch
2
.
Innerhalb der Domäne der betriebswirtschaftlichen Anwendung ist besonders
im Segment der analytischen Informationssysteme eine hohe Entwicklungsdyna-
mik von Open Source Software (OSS) zu verzeichnen. Im Wachstumsmarkt [Kö08]
der Business Intelligence (BI) so der Überbegriff für aktuelle, IT-basierte Ansät-
ze zur Versorgung des Managements mit entscheidungsrelevanten Informationen
gewinnen quelloffene Softwarelösungen an Popularität [Die09b; BG09, S. v;
Kle06].
Während freie Software für die Initiatoren der Bewegung eine Ideologie dar-
stellt [Fre09], wird sie in anwendenden Unternehmen hingegen meist pragmatisch
betrachtet. Die Mehrzahl von ihnen führt die Reduzierung von Kosten als wich-
tigsten Beweggrund für den Einsatz freier Software an [Die09a]. Dieser antizipierte
Kostenvorteil lässt sich bezogen auf die reinen Lizenzierungskosten stichfest be-
legen, denn der überwiegende Teil der Open Source Produkte ist kostenlos oder
gegen geringe Lizenzgebühren zu beziehen. Bei der Einführung komplexer Softwa-
resysteme 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
1
Einer Studie der Marktforscher Gartner aus dem Jahr 2008 zufolge setzten zu dem Zeitpunkt
bereits 85 Prozent der darin befragten Unternehmen Open Source Software ein. Die rest-
lichen 15 Prozent planten, innerhalb der folgenden zwölf Monate Open Source Software in
Betrieb zu nehmen [Gar08].
2
Auch die Teilnehmer der o.g. Umfrage planten, innerhalb der folgenden zwölf Monate ver-
stärkt Projekte im Anwendungsumfeld auf Basis von Open Source Software zu realisieren.
1
1.1. Problembereich
Risiko eines vorzeitigen Projektabbruchs oder zumindest eines suboptimalen Pro-
jektergebnisses. 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 (Ab-
bildung 1.1).
Micro
strate
gy
QlikT
ech
Penta
ho
J asp
ersof
t
Inform
ation
Builde
rs
SAS
IBM/C
ogno
s
SAP/
Busin
ess O
bjects
Orac
le/Hy
perio
n
0%
10%
20%
30%
40%
50%
60%
70%
Best-in-Class
Average
Laggards
Abbildung 1.1.: Verteilung von Business Intelligence Produkten auf erfolgrei-
che, durchschnittliche und weniger erfolgreiche Implementierun-
gen
3
(modifiziert übernommen aus [Abe08])
Um von den Vorzügen zu profitieren, welche Open Source Software neben ge-
ringeren Anschaffungskosten bietet
4
, müssen Unternehmen demnach sehr genau
3
In der zugrundeliegenden Umfrage wurden Unternehmen zu ihren BI-Lösungen befragt. Als
Erfolgskriterien wurden die Projektdauer, Budget-Treue und Kosten pro Nutzer betrachtet.
Anhand dieser Kriterien wurden die Unternehmen in die Gruppen Best-in-Class, Average
und Laggards eingeteilt. Desweiteren wurde erfragt, welche BI-Produkte bei den jeweiligen
Projekten zum Einsatz gekommen sind. Hierbei waren Mehrfachnennungen möglich.
4
Auch Motive wie die Implementierung offener Standards und Herstellerunabhängigkeit spielen
für Unternehmen beim Einsatz von Open Source Software eine wichtige Rolle (vgl. Abschnitt
2.3.2 ab S. 19).
2
1.2. Ziel der Arbeit
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, verschie-
dene Produkte herunterzuladen und auszuprobieren, bis eine akzeptable Lösung
gefunden wurde. Eine solche Vorgehensweise wäre jedoch ineffizient und die Wahr-
scheinlichkeit gering, das unter strategischen Gesichtspunkten bestgeeignete Pro-
dukt zu wählen.
1.2. Ziel der Arbeit
Ziel der vorgestellten Arbeit ist die Entwicklung und Beschreibung eines Hand-
lungsrahmens zur systematischen Evaluation und Auswahl von Open Source Bu-
siness Intelligence Systemen.
Das resultierende Vorgehensmodell soll auf verschiedene Unternehmen anwend-
bar sein und muss aus diesem Grund mit Gegebenheiten des jeweilig betrachte-
ten 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 Auswahlpha-
se von BI-Projekten. Demnach stellt das Ergebnis der Arbeit kein Vorgehensmo-
dell 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 Bedeu-
tung sind.
1.3. 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 er-
forderlichen Grundlagen erörtert.
3
1.3. Vorgehensweise und Aufbau der Arbeit
Darauf aufbauend erfolgt die eigentliche Konzeption des Modells in Kapitel
3. Da der Auswahl von Software grundsätzlich eine Definition der Anforderun-
gen 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 ei-
ner 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 Anwen-
dung 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 Vorgehens-
weise, einem Fazit und einem Ausblick auf mögliche Ergänzungen des entwickelten
Modells sowie einer Zusammenfassung ab.
4
KAPITEL
2
Grundlagen
2.1. Business Intelligence
2.1.1. Definition
Seit den 1960er-Jahren wird in Unternehmen das Ziel verfolgt, Entscheidungs-
träger durch informationsverarbeitende Systeme bei der Entscheidungsfindung
und Unternehmenssteuerung zu unterstützen, wobei sich über den Zeitverlauf
unterschiedliche Begrifflichkeiten mit jeweils leicht unterschiedlichen inhaltlichen
Schwerpunkten gebildet haben [KMU06, S. 1; Eng09, S. 4]. Mitte der 1990er-
Jahre wurde durch die Gartner Group der Begriff Business Intelligence geprägt
[KMU06, S. 2], welcher mittlerweile sehr populär geworden ist.
Es existieren jedoch durchaus unterschiedliche Vorstellungen von der Auslegung
dieser Begrifflichkeit, wobei die meisten Definitionen Business Intelligence über
die verwendeten (Software-)Systeme abgrenzen [KMU06, S. 3].
GLUCHOWSKI strukturiert anhand dieser Abgrenzung das Verständnis von
BI in [Glu01, S. 7]:
· Enges BI-Verständnis
Hier wird die Bedeutung des BI-Begriffs auf wenige bestimmte Anwendungs-
systeme reduziert. Hierzu gehören OLAP
5
und Informationssysteme für be-
stimmte organisatorische Einheiten, wie Marketinginformationssysteme und
Einkäuferinformationssysteme.
· Analyseorientiertes BI-Verständnis
Das analyseorientierte BI-Verständnis schließt zusätzlich zum engen BI-
Verständnis weitere Anwendungssysteme ein. Hierzu zählen Kennzahlen-
systeme
6
, Planungs- und Konsolidierungssysteme
7
, aber auch das Data Mi-
ning
8
.
· Weites BI-Verständnis
Das weite BI-Verständnis stellt die umfassendste Auslegung des BI-Begriffs
dar. Neben weiteren Anwendungstypen wie dem Reporting
9
werden hier
auch Technologien der BI zugeordnet, welche für die Bildung der Datenbasis
5
Vgl. Abschnitt 2.1.3.4 ab S. 10.
6
Vgl. Abschnitt 2.1.2.3 ab S. 7.
7
Vgl. Abschnitt 2.1.2.7 ab S. 9.
8
Vgl. Abschnitt 2.1.3.6 ab S. 12.
9
Vgl. Abschnitt 2.1.3.5 ab S. 11.
5
2.1. Business Intelligence
für die analytischen Anwendungssysteme zum Einsatz kommen. Hier sind
im Wesentlichen ETL-Systeme
10
und Data Warehouses
11
zu nennen.
Das weite BI-Verständnis kann heute als gängigste Auffassung des Begriffs
bezeichnet werden. Definitionen wie [KMU06, S. 8]:
Unter Business Intelligence (BI) wird ein integrierter, unterneh-
mensspezifischer, IT-basierter Gesamtansatz zur betrieblichen
Entscheidungsunterstützung verstanden.
· BI-Werkzeuge dienen ausschließlich der Entwicklung von BI-An-
wendungen.
· BI-Anwendungssysteme bilden Teilaspekte des BI-Gesamtansat-
zes ab.
und [GG00, S. 19]:
Business Intelligence (BI) bezeichnet den analytischen Prozess, der
[. . . ] Unternehmens- und Wettbewerbsdaten in handlungsgerechtes
Wissen über die Fähigkeiten, Positionen, Handlungen und Ziele der
betrachteten internen oder externen Handlungsfelder [. . . ] transfor-
miert.
implizieren ein Verständnis von BI, welches über die reinen Anwendungssysteme
hinausgeht und Aspekte der Datenbeschaffung und -bereitstellung einschließt.
Diese Sichtweise auf den BI-Komplex wird auch in der vorliegenden Arbeit einge-
nommen. Insbesondere KEMPERs Definition von BI als integrierter, unterneh-
mensspezifischer, IT-basierter Gesamtansatz deckt sich mit der Sichtweise auf
den BI-Komplex, welche in der vorliegenden Arbeit eingenommen wird.
2.1.2. Anwendungsgebiete
2.1.2.1. Vorbemerkung
Der Facettenreichtum von möglichen Anwendungen, welche sich durch die Nut-
zung eines dispositiven Datenbestandes in der Praxis ergeben, ist nahezu unbe-
grenzt. In der wissenschaftlichen Diskussion hat sich jedoch eine Klassifizierung
dieser Anwendungen herausgebildet, welche die praktischen Anwendungsfälle wei-
testgehend abdeckt [Ban06, S. 97 ff. Eng09, S. 7 ff.]. Die folgenden Abschnitte ver-
schaffen einen Überblick über die identifizierten Anwendungsklassen und verdeut-
10
Vgl. Abschnitt 2.1.3.2 ab S. 9.
11
Vgl. Abschnitt 2.1.3.3 ab S. 10.
6
2.1. Business Intelligence
lichen, welche Anwendungstypen in der vorliegenden Arbeit den BI-Anwendungen
zugerechnet werden.
2.1.2.2. Berichte
Berichte sind das klassische Instrument zur Informationsversorgung von Entschei-
dern. Inhaltlich werden in Berichten Kennzahlen publiziert [Ban06, S. 101], welche
für die Steuerung des Unternehmens als relevant eingestuft werden.
Die Verteilung von Berichtsinhalten kann aktiv durch das Berichtssystem er-
folgen oder bei Bedarf durch den Nutzer initiiert werden. Aktive Berichtssys-
teme können sowohl periodische Standardberichte generieren, als auch, bei Ab-
weichung bestimmter Kennzahlen von Normvorgaben, die Verantwortungsträger
durch Abweichungsberichte alarmieren. In Abbildung 2.1 werden diese Ausprä-
gungen strukturiert dargestellt.
Abbildung 2.1.: Ordnungshierarchie für Berichtssysteme und Berichtsarten (in An-
lehnung an [Gla03, S. 255; Glu98, S. 1178])
2.1.2.3. Cockpits, Kennzahlensysteme und Scorecards
Cockpits und Kennzahlensysteme werden oft als separate Anwendungskategorien
dargestellt [Ban06, S. 98; Eng09, S. 12 ff.]. Jedoch lassen sich diese auch als
spezielle Formen von Berichten betrachten.
Cockpits stellen aggregierte Informationen in elektronischer Form dar [Ban06,
S. 98]. Oft sind sie derart gestaltet, dass auf der Startseite die höchste Aggregati-
onsstufe der Informationen dargestellt wird und durch Anklicken bestimmter In-
formationen deren Herkunft und/oder Zusammensetzung angezeigt werden kann.
7
2.1. Business Intelligence
Es handelt sich demnach um eine interaktive Form von Berichten.
Insbesondere hierarchische Kennzahlensysteme eignen sich inhaltlich für die
Darstellung via Cockpits, da diese ebenfalls auf der Hierarchie nach oben hin
verdichtet werden [Eng09, S. 12 ff.]. Ein umfassendes Kennzahlensystem, welches
nicht nur monetäre Kennzahlen berücksichtigt und deswegen auch als ganzheit-
liches Instrument zur Unternehmenssteuerung beschrieben wird, ist die Balan-
ced Scorecard [KN96]. Die informationstechnologische Umsetzung der Balanced
Scorecard wird teilweise auch als Performance Management bezeichnet [Eng09,
S. 23 ff.]. Prinzipiell handelt es sich hierbei auch um ein spezifisches Kennzah-
lensystem, welches mittels interaktiver Berichtssysteme elektronisch aufbereitet
werden kann.
2.1.2.4. Ad-Hoc-Analyse
Neben den herkömmlichen vordefinierten Berichten benötigen bestimmte Anwen-
dergruppen eine interaktive Navigation zur Zusammenstellung relevanter Daten
aus einem Datenpool. Hierfür hat sich der Begriff der Ad-Hoc-Analyse etabliert
[Ban06, S. 103]. Inhaltlich beziehen sich derartige Analysen auf Entscheidungs-
objekte, welche als für die Unternehmenssteuerung relevant identifiziert wurden,
beispielsweise Kunden, Produkte und Filialen [Tot06, S. 54]. Der Datenpool für
Ad-Hoc-Analysen ist heute meist nach einem multidimensionalen Datenmodell
gestaltet
12
, womit eine Auswertbarkeit nach einer Vielzahl von Entscheidungsob-
jekten ermöglicht wird.
2.1.2.5. Hypothesenfreie Analyse / Wissensentdeckung
Während die Untersuchungen der Ad-Hoc-Analyse auf Annahmen darüber ba-
sieren, welche Art von Informationen zu relevantem Wissen führt, findet die hy-
pothesenfreie Analyse ohne derartige Annahmen statt. Stattdessen wird automa-
tisiert nach Mustern und Zusammenhängen in großen Datenbeständen gesucht,
welche auf relevantes Wissen hinweisen. Die praktische Durchführung der hypo-
thesenfreien Analyse erfolgt mittels Data Mining Verfahren
13
.
2.1.2.6. Externes Rechnungswesen und Konsolidierung
Neben dem internen Rechnungswesen kann auch das externe Rechnungswesen mit
Daten aus dem BI-System versorgt werden [Ban06, S. 106]. Das Spektrum reicht
12
Vgl. Abschnitt 2.1.3.4 ab S. 10.
13
Vgl. Abschnitt 2.1.3.6 ab S. 12.
8
2.1. Business Intelligence
hierbei von der Erstellung von Quartalsberichten und Jahresabschlüssen einfacher
Gesellschaften bis hin zur konsolidierten konzernweiten Berichterstattung [Ban06,
S. 38 ff.].
2.1.2.7. Planung und Simulation
Während die zuvor beschriebenen Anwendungsgebiete auf vergangenheitsbasier-
ten Daten beruhen, beziehen sich Planung und Simulation auf die Zukunft. Als
konkrete Anwendungsbeispiele seien hier die Budgetierung und die Absatzpla-
nung genannt. Im Gegensatz zu den vergangenheitsbasierten Anwendungen die-
nen nicht etwa bereits vorhandene Daten / Fakten als Grundlage für Berechnun-
gen, sondern Daten, welche auf Annahmen oder Planwerten basieren und von den
Nutzern eingegeben werden [Ban06, S. 105].
2.1.3. Technologien
2.1.3.1. Vorbemerkung
Während die Betrachtung der Anwendungsgebiete die fachliche Perspektive auf
Business Intelligence darstellt, wird in den folgenden Abschnitten die technische
Perspektive eingenommen. Hierbei werden sowohl die Softwaretypen betrachtet,
welche direkt zur Implementierung der zuvor benannten Anwendungsfälle einge-
setzt werden, als auch die Softwaretypen, die zur Datenbeschaffung, -integration
und -bereitstellung Verwendung finden.
2.1.3.2. Datenintegration / ETL
Eine wichtige Vorleistung zur analytischen Auswertung von Daten im BI-Kontext
stellt deren Überführung aus den verschiedenen operativen Quellsystemen in eine
einheitliche dispositive Datenhaltung dar [KF06, S. 114]. Die Integrationsprozesse
können zwar manuell programmiert werden, es hat sich jedoch eine eigene Softwa-
rekategorie für diese Problemstellung etabliert, welche als ETL-Tools
14
bezeichnet
wird und deren Einsatz Effizienzsteigerungen bei der Datenintegration verspricht
[KC04, S. 10 ff.] Aufgrund des weiten BI-Verständnisses, welches in der vorlie-
genden Arbeit eingenommen wird, werden derartige Werkzeuge im entwickelten
Modell thematisiert.
14
ETL steht für Extraktion, Transformation, Laden [Eng09, S. 169]. Gemeint ist damit die
Extraktion der Daten aus den Quellsystemen, die Transformation im Sinne einer Fehlerbe-
reinigung, Formatangleichung und Aggregation, sowie das Laden in den dispositiven Daten-
speicher.
9
2.1. Business Intelligence
2.1.3.3. Data Warehouse
Der dispositive Datenspeicher, welcher die extrahierten und transformierten ope-
rativen Daten aufnimmt, wird als Data Warehouse (DWH) bezeichnet.
Eine relativ restriktive Definition liefert INMON [IH94, S. 25]:
A data warehouse is a subject-oriented, integrated, time-variant,
nonvolatile collection of data in support of management's decision
15
.
Eine weniger restriktive Definition liefern BAUER/GÜNZEL [BG09, S. 8]:
Ein Data-Warehouse ist eine physische Datenbank, die eine inte-
grierte Sicht auf beliebige Daten zu Analysezwecken ermöglicht [BG09,
S. 8].
Für die weiteren Ausführungen reicht das Verständnis des DWH als Datenspei-
cher zur Ausführung analytischer Auswertungen.
Größere Data Warehouse Szenarien bestehen meist aus mehreren Datenspei-
chern. Neben dem zentralen Core DWH werden hierbei abteilungsspezifische Teil-
systeme, genannt Data Marts, aufgesetzt [Ban06, S. 95; IIS01, S. 110 ff.].
Als Speichertechnik für den dispositiven Datenspeicher haben sich relationale
Datenbankmanagementsysteme etabliert
16
. Diese sollen in den weiteren Ausfüh-
rungen jedoch nicht näher betrachtet werden, da sie keine BI-spezifischen Systeme
darstellen und die detaillierte Auseinandersetzung mit dem weiten Feld der rela-
tionalen Datenbanken den Rahmen der vorliegenden Arbeit sprengen würde.
2.1.3.4. Online Analytical Processing
Online Analytical Processing (OLAP) beschreibt eine Analysemethode, bei der in
interaktiver Weise Abfragen auf Datenbestände ausgeführt werden, welche mehr-
dimensional angeordnet sind [BG09, S. 105]. Der Begriff wurde 1993 von CODD
geprägt, indem er im Rahmen einer Produktpräsentation 12 Regeln aufstell-
te, welche die Anforderungen an ein OLAP-System beschreiben [BG09, S. 105;
Eng09, S. 152]. Diese Regeln wurden teilweise wegen ihrer Ausrichtung auf ein
spezifisches Produkt kritisiert. Im Jahr 1995 wurden von PENDSE unter der
Abkürzung FASMI (Fast Analysis of Shared and Multidimensional Information)
fünf herstellerunabhängige Evaluierungsregeln für OLAP-Systeme aufgestellt. Da
15
Ein Data Warehouse ist eine themenorientierte, integrierte, chronologisierte und persistente
Sammlung von Daten, um das Management bei seinen Entscheidungsprozessen zu unter-
stützen.
16
In größeren Data Warehouse Szenarien kommen auf den stärker verdichteten Ebenen wie den
Data Marts auch mehrdimensionale Datenspeicher zum Einsatz (vgl. Abschnitt 2.1.3.4).
10
2.1. Business Intelligence
OLAP-Systeme auch einen Evaluationsgegenstand im Rahmen des zu entwicklen-
den Vorgehensmodells darstellen, sollen diese Regeln hier kurz dargestellt werden
[Eng09, S. 153; BG09, S. 108 ff.]:
· Fast
Durchschnittlich sollen Abfragen nicht länger als fünf Sekunden dauern.
Einfache Abfragen nicht länger als eine Sekunde, komplexe Abfragen nicht
länger als zwanzig Sekunden.
· Analysis
Das Werkzeug soll eine intuitive, anwenderfreundliche Analyse ermöglichen.
· Shared
Ein Mehrbenutzerbetrieb und entsprechende Rechtevergabe sollen möglich
sein.
· Multidimensional
Dem Anwender soll eine mehrdimensionale Sicht auf die Daten zur Verfü-
gung gestellt werden, mit der Möglichkeit, beliebige Dimensionen bei der
Abfrage zu kombinieren.
· Information
Dem Anwender sollen alle relevanten Daten zur Verfügung stehen. Das
OLAP-System muss entsprechend skalieren.
Bezüglich der Speichertechnik unterscheidet man zwischen relationalem und
multidimensionalem OLAP (ROLAP vs. MOLAP). Während ersteres auf rela-
tionalen Datenbanken basiert, setzt MOLAP auf speziellen multidimensionalen
Speichertechniken auf [IIS01, S. 114]. ROLAP-Engines, welche analytische Abfra-
gen in SQL umwandeln und gegen die unterliegende Datenbank absetzen sowie
MOLAP-Server sind Softwarekategorien, welche im Rahmen des zu entwickelnden
Vorgehensmodells Berücksichtigung finden.
2.1.3.5. Reporting
Reporting-Werkzeuge dienen zur aufbereiteten Darstellung von betriebswirtschaft-
lichen Sachverhalten sowie der Informationsverteilung und -bereitstellung inner-
halb einer Organisation [Ban06, S. 101; Eng09, S. 58]. Neben der zyklischen
Verteilung von Standardberichten kann auch die regelbasierte Erzeugung von
Ausnahmeberichten zum Funktionsumfang eines Reporting-Tools zählen [Eng09,
S. 58]. In Ergänzung zu statischen, flachen Berichten geht der Trend hin zu in-
teraktiven und verschachtelten Berichten, welche beispielsweise das Navigieren
durch verschiedene Ebenen eines hierarchischen Kennzahlensystems oder die un-
11
2.1. Business Intelligence
terschiedlichen Perspektiven einer Scorecard ermöglichen
17
.
Als Datenquelle interaktiver Berichte kann auch ein OLAP-Server zum Einsatz
kommen [KMU06, S. 112]. Je nach Freiheitsgrad des Anwenders kann in einem
solchen Fall von geführter Ad-Hoc-Analyse gesprochen werden. Die Grenzen zwi-
schen Reporting-Werkzeugen und OLAP-Frontends werden dadurch zunehmend
unschärfer. Um diesem Sachverhalt Rechnung zu tragen, werden OLAP-Frontends
im Rahmen des zu entwickelnden Modells den Reporting-Werkzeugen zugeordnet.
Abschnitt 3.5.3.4 bezieht sich somit ausschließlich auf OLAP-Server.
2.1.3.6. Data Mining
Data Mining oder auch Knowledge Discovery in Databases wird als Begriff
für die Mustererkennung in strukturierten Datenbeständen verwendet [KMU06,
S. 106]. Einerseits werden unter dem Begriff verschiedene mathematisch-statisti-
sche Methoden zusammengefasst
18
[GG00, S. 177 ff. GS09; KMU06, S. 107 ff.],
andererseits wird er auch für eine bestimmte Vorgehensweise, bzw. einen defi-
nierten Prozessablauf bei der Wissensschöpfung aus Datenbeständen gebraucht,
welcher in Abbildung 2.2 dargestellt ist.
Abbildung 2.2.: Vorgehensmodell des Knowledge Discovery in Databases (modifiziert
übernommen aus [Düs06, S. 246])
Der Prozess beginnt mit der Auswahl und der Aufbereitung der zu untersuchen-
den Daten. Nach der Festlegung des Analyseverfahrens und dessen Durchführung
erfolgt eine Interpretation des Analyseergebnisses [Düs06, S. 246].
Ein genaueres Verständnis der Methoden und des Prozesses des Data Mining
ist für die weiteren Ausführungen nicht relevant. Es genügt das Wissen darum,
dass unter Data Mining Anwendungen Programme verstanden werden, welche
die Anwendung derartiger Methoden unter Einhaltung besagter Prozessschritte
ermöglichen.
17
Vgl. Abschnitt 2.1.2.3 ab S. 7.
18
Vgl. Abbildung 3.8 auf S. 50.
12
2.1. Business Intelligence
2.1.4. Standards
Data Warehouses setzen üblicherweise auf relationalen Datenbanken auf. Für die
Kommunikation mit diesen hat sich die Structured Query Language (SQL) eta-
bliert [PB02, S. 29]. Unter Windows-Systemen steht mit Open Database Connec-
tivity (ODBC) eine standardisierte Schnittstelle zur Datenbankabfrage zur Ver-
fügung. In der Klassenbibliothek der Programmiersprache Java findet sich mit
Java Database Connectivity (JDBC) eine Programmierschnittstelle, welche eben-
falls einen einheitlichen Zugriff auf Datenbanksysteme unterschiedlicher Hersteller
ermöglicht[PB02, S. 107].
Für BI-Szenarien mit multidimensionaler Datenhaltung und Abfragelogik ha-
ben sich entsprechende Standards herausgebildet. Allen voran ist die von der
Firma Microsoft entwickelte mehrdimensionale Abfragesprache Multidimensional
Expressions (MDX) zu nennen, welche sich zum De-facto-Industriestandard für
OLAP-Abfragen etabliert hat [KMU06, S. 91 ff. BG09, S. 153 ff.]. Für Windows-
Systeme existiert mit OLE DB for OLAP (ODBO) ein ODBC-Pendant für mehr-
dimensionale Abfragen. Plattformunabhängiger ist jedoch das Format XML for
Analysis (XMLA) zur Kommunikation zwischen OLAP-Servern und -Clients. Es
kapselt MDX-Queries in XML und ermöglicht somit die Bereitstellung und Nut-
zung von OLAP-Diensten in Form von Webservices [BG09, S. 153].
Ein wichtiger Aspekt von BI-Systemen sind Metadaten, welche zur Beschrei-
bung der Bedeutung und Eigenschaften von Objekten eingesetzt werden, um diese
besser einordnen, verwalten und nutzen zu können [KMU06, S. 42 ff.]. Um Me-
tadaten zwischen Systemen unterschiedlicher Hersteller austauschbar zu machen,
entwickelte die Object Management Group das Common Warehouse Metamodell
(CWM) [Obj03]. Dieses hat bis heute jedoch keine nennenswerte Verbreitung ge-
funden [GTS10, S. 58] und wird deshalb in der vorliegenden Arbeit nicht näher
thematisiert.
2.1.5. Ordnungsrahmen
In der vorliegenden Arbeit werden häufiger BI-Ebenen erwähnt. Dabei wird Be-
zug genommen auf einen BI-Ordnungsrahmen von KEMPER, welcher Business
Intelligence in die drei Schichten Datenbereitstellung, Informationsgenerierung/-
speicherung und Informationszugriff unterteilt [KMU06, S. 10]. In [Stu09, S. 4 ff.]
findet eine Zuordnung der in den vorangegangenen Abschnitten dargestellten
Technologien zu diesen Ebenen statt. Abbildung 2.3 stellt diesen Ordnungsrah-
men inklusive besagter Zuordnung der BI-Technologien dar.
13
2.2. Evaluation und Auswahl von Software
Abbildung 2.3.: Business Intelligence Ordnungsrahmen (modifiziert übernommen
aus [KMU06, S. 10; Stu09, S. 5 ff.])
2.2. Evaluation und Auswahl von Software
2.2.1. Einordnung in den Prozess der Systementwicklung
Wie bereits in Abschnitt 1.2 erwähnt, soll kein Vorgehensmodell für die Durchfüh-
rung kompletter BI-Projekte entwickelt werden. Vielmehr beschränken sich die
Ausführungen auf den Projektausschnitt der Auswahl einer Softwarelösung aus
dem Open Source Umfeld. Die Auswahl einer Software setzt jedoch die systema-
tische Analyse der Anforderungen voraus, weswegen dieser Teilaspekt ebenfalls
Berücksichtigung findet.
Abbildung 2.4 stellt eine Einordnung der nachfolgenden Ausführungen in den
Prozess der Systementwicklung dar und verdeutlicht, dass die Softwareauswahl
nicht isoliert von der Anforderungsermittlung betrachtet werden kann. Gleichzei-
tig zeigt die Abbildung, dass die Alternative zur Indiviualentwicklung der Fremd-
bezug von Standardsoftware ist
19
.
2.2.2. Evaluation im Kontext der Wirtschaftsinformatik
Evaluation bezeichnet eine gezielte Bewertung von materiellen oder immateri-
ellen Gegenständen, wobei die Verwendung konkreter Verfahren und Kriterien
begründet werden sollte [Hou93, S. 1].
19
Vgl. Abschnitt 3.1 ab S. 21.
14
2.2. Evaluation und Auswahl von Software
Abbildung 2.4.: Einordnung des zu entwickelnden Vorgehensmodells in den Prozess
der Systementwicklung (modifiziert übernommen aus [SH05, S. 218])
Es lässt sich zwischen Ex-ante-Evaluation und Ex-post-Evaluation unterschie-
den. Im Kontext der Wirtschaftsinformatik dient die Ex-ante-Evaluation der In-
formationsgewinnung zur Vorbereitung von Entscheidungen über einen Techno-
logieeinsatz, während die Ex-post-Evaluation zur Überprüfung der getroffenen
Entscheidungen dient [Hei00, S. 13]. Im weiteren Verlauf werden diese beiden
Varianten als Vor- bzw. Nachevaluation bezeichnet.
Eine Vorevaluation zum Zweck der Softwareauswahl wird üblicherweise auf Ba-
sis eines Abgleichs von aufgestellten Kriterien mit ermittelten Eigenschaften der
in Frage kommenden Produkte durchgeführt [Sch03, S. 141 ff.]. Ein verbreitetes
Instrument zur mehrdimensionalen Bewertung ist die Nutzwertanalyse, welche
im folgenden Abschnitt beschrieben wird.
Für die Überprüfung der getroffenen Einsatzentscheidung im Sinne einer Nach-
evaluation bietet sich insbesondere bei Open Source Software der testweise Be-
15
Ende der Leseprobe aus 106 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2010, Entwicklung und Anwendung eines Vorgehensmodells zur Evaluation und Auswahl von Open Source Business Intelligence Systemen, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/228488
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare