ein business-intelligence-reportingwerkzeug zur...
TRANSCRIPT
Universität Paderborn
Diplomarbeit
Ein Business-Intelligence-Reportingwerkzeug zur Entscheidungsunterstützung im Rahmen von
Geschäftsprozessen
Konzeption und prototypische Implementierung einer komponentenbasierten Applikation auf Basis des Composite-
Application-Frameworks
Prof. Dr. Ludwig Nastansky
Wintersemester 2008/2009
Betreuer: Dipl.-Wirt.-Inf. Bernd Hesse, GCC Paderborn
Björn Reinhold, PAVONE AG
vorgelegt von:
Florian Kröger Diplom-Wirtschaftsinformatik
Danksagung
Ich möchte mich an dieser Stelle vor allem bei Bernd Hesse und Björn Reinhold für die
Betreuung meiner Diplomarbeit bedanken.
Weiter danke ich Familie Winkelmann, meiner Familie sowie meiner Freundin für die
Reviews und die Unterstützung während der Zeit meiner Arbeit.
S e i t e | I
Inhaltsverzeichnis
1 Einleitung ....................................................................................................................... 1
1.1 Motivation ............................................................................................................... 1
1.2 Aufgabenstellung ..................................................................................................... 2
1.3 Aufbau der Arbeit .................................................................................................... 3
2 Grundlagen ..................................................................................................................... 4
2.1 Business Intelligence ............................................................................................... 4
2.1.1 Einordnung ....................................................................................................... 4
2.1.2 Geschichte der Management Support Systems ................................................ 4
2.1.3 Definition von Business Intelligence ............................................................... 8
2.1.4 Bausteine der Business Intelligence ............................................................... 11
2.1.5 Bezug zu dieser Arbeit ................................................................................... 18
2.2 Geschäftsprozesse ................................................................................................. 18
2.2.1 Einordnung ..................................................................................................... 18
2.2.2 Organisation eines Unternehmens.................................................................. 18
2.2.3 Definition von Geschäftsprozessen ................................................................ 20
2.2.4 Probleme von Geschäftsprozessen ................................................................. 23
2.2.5 Bezug zu dieser Arbeit ................................................................................... 24
2.3 Komponentenbasierte Softwareentwicklung ......................................................... 24
2.3.1 Einordnung ..................................................................................................... 24
2.3.2 Definition von Komponenten ......................................................................... 25
2.3.3 Komponentenframeworks .............................................................................. 26
2.3.4 Bezug zu dieser Arbeit ................................................................................... 27
3 Konzept für ein Reportingwerkzeug ............................................................................ 28
3.1 Erläuterungen zum Composite-Application-Framework ...................................... 28
3.1.1 Groupware ...................................................................................................... 28
3.1.2 IBM Lotus Notes / Domino ........................................................................... 29
3.1.3 Composite-Application-Framework von IBM Lotus Notes 8 ....................... 30
S e i t e | II
3.2 Anwendungsszenario ............................................................................................. 33
3.3 Anforderungen ....................................................................................................... 34
3.3.1 Komponentenbasierte Applikation ................................................................ 34
3.3.2 Kundenauswahl .............................................................................................. 35
3.3.3 Datenquellen einbinden und verknüpfen ....................................................... 35
3.3.4 Auswahl relevanter Daten eines Kunden ....................................................... 36
3.3.5 Darstellung der Daten .................................................................................... 36
3.3.6 Detailinformationen ....................................................................................... 37
3.3.7 Geschäftsprozessintegration ........................................................................... 38
3.4 Soll-Konzept .......................................................................................................... 38
3.4.1 Entwicklungsumgebung IBM Lotus Notes .................................................... 38
3.4.2 Kundenbezogene Daten ................................................................................. 40
3.4.3 Auswahl der Komponenten mit kundenbezogenen Daten ............................. 42
3.4.4 Spezifikationen der einzelnen Komponenten................................................. 45
3.4.5 Textuelle Darstellung der Komponenten ....................................................... 50
3.4.6 Grafische Darstellung der Komponenten ....................................................... 52
3.4.7 Schnittstellen der Komponenten .................................................................... 58
3.4.8 Detailinformationen ....................................................................................... 59
3.4.9 Geschäftsprozessintegration ........................................................................... 60
3.4.10 Einbindung der Komponenten in eine Composite Application ..................... 61
4 Prototypische Implementierung eines Reportingwerkzeuges ...................................... 62
4.1 Entwicklung des Prototyps .................................................................................... 62
4.1.1 Entwicklung mit Lotus Notes / Domino ........................................................ 63
4.1.2 Entwicklung mit Eclipse / BIRT .................................................................... 67
4.1.3 Schnittstellen und Zusammenführung der Komponenten .............................. 73
4.2 Kritische Betrachtung des Ergebnisses ................................................................. 76
5 Ausblick ....................................................................................................................... 78
6 Zusammenfassung ........................................................................................................ 80
S e i t e | III
Literaturverzeichnis.............................................................................................................. 82
Eidesstattliche Erklärung ..................................................................................................... 87
Anhang ................................................................................................................................. 88
S e i t e | IV
Abkürzungsverzeichnis
BI Business Intelligence
BIRT Business Intelligence and Reporting Tools
BSC Balanced-Scorecard
CA DB Datenbank der entwickelten Composite Application
CAF Composite-Application-Framework
COM Component Object Model
CSV Comma-Separated Values
DOC Microsoft Word Document
DSS Decision Support Systems
DW Data Warehouse
EDV Elektronische Datenverarbeitung
EIS Executive Information Systems
FASMI Fast Analysis of Shared Multidimensional Information
HTML Hypertext Markup Language
J2EE Java Platform Enterprise Edition
JDBC Java Database Connectivity
MDX Multidimensional Expressions
MIS Management Information Systems
MSS Management Support Systems
ODT OpenDocument-Text
OLAP Online-Analytical-Processing-System
OLTP Online-Transaction-Processing-Systems
PC Personal Computer
PDF Portable Document Format
PKI Public-Key-Infrastructure
POJO Plain Old Java Object
S e i t e | V
PPT Microsoft PowerPoint Presentation
Project DB Datenbank der PAVONE Project Management Anwendung
RADD Rapid Application Development and Deployment
RCP Rich Client Platform
RTF Rich Text Format
Sales DB Datenbank der PAVONE Sales Anwendung
SOA Serviceorientierte Architektur
SVG Scalable Vector Graphics
TXT Reine Textdatei
URL Uniform Resource Locator
WSDL Web Service Description Language
XLS Microsoft Excel Spreadsheet
XML Extensible Markup Language
XMLA XML for Analysis
S e i t e | VI
Abbildungsverzeichnis
Abbildung 1 - Entscheidungsebene im Aufgabenbereich des Managements ........................ 4
Abbildung 2 - Historie von entscheidungsunterstützenden Systemen ................................... 5
Abbildung 3 - Ebenen der Management Support Systems .................................................... 7
Abbildung 4 - Abgrenzungen von BI ................................................................................... 10
Abbildung 5 - Architekturvarianten: Zentrales und dezentrales Data Warehouse .............. 12
Abbildung 6 - Würfeldarstellung mehrdimensionaler strukturierter Daten ......................... 14
Abbildung 7 - Perspektiven der Balanced Scorecard ........................................................... 16
Abbildung 8 - Beispiel einer Aufbauorganisation ............................................................... 19
Abbildung 9 - Beispiel einer Ablauforganisation ................................................................ 20
Abbildung 10 - Einfaches Prozessprinzip ............................................................................ 20
Abbildung 11 - Aufgaben in einem Prozess ........................................................................ 21
Abbildung 12 - Beispiel einer Composite Application ........................................................ 31
Abbildung 13 - Composite Application Editor .................................................................... 32
Abbildung 14 - Wiring einer Composite Application .......................................................... 32
Abbildung 15 - PAVONE Produktübersicht ........................................................................ 41
Abbildung 16 - Komponentenbasierte Applikation in Lotus Notes..................................... 43
Abbildung 17 - Skizze der Komponentenanordnung ........................................................... 45
Abbildung 18 - Skizze der Kundenauswahl ......................................................................... 46
Abbildung 19 - Skizze der Aktivitäten................................................................................. 46
Abbildung 20 - Skizze der Angebote ................................................................................... 48
Abbildung 21 - Skizze der Projekte ..................................................................................... 49
Abbildung 22 - Skizze der Komponentenanordnung mit Daten und Darstellung ............... 49
Abbildung 23 - Ausschnitt einer View in der Project DB ................................................... 50
Abbildung 24 - BIRT Report Designer in Eclipse ............................................................... 56
Abbildung 25 - Properties der Kundenauswahl ................................................................... 58
Abbildung 26 - Einsetzen der Komponenten in eine Composite Application ..................... 61
Abbildung 27 - Übersicht Reportingwerkzeug .................................................................... 62
Abbildung 28 - Komponente der Kundenauswahl ............................................................... 64
Abbildung 29 - Komponente der Aktivitäten....................................................................... 65
Abbildung 30 - Abfolge der Informationsbeschaffung per Webservice .............................. 66
Abbildung 31 - Komponente der Angebote in der Gesamtübersicht ................................... 68
Abbildung 32 - Komponente der Angebote in der kundenbezogenen Sicht ........................ 69
Abbildung 33 - Komponente der Projekte in der Gesamtübersicht ..................................... 70
S e i t e | VII
Abbildung 34 - Komponente der Projekte in der kundenbezogenen Sicht .......................... 71
Abbildung 35 - Aufbau der Bereitstellung des BI Reporting Plugins ................................. 72
Abbildung 36 - Composite Application Editor mit dem Reportingwerkzeug ..................... 73
Abbildung 37 - Ablauf der Aktualisierung der Aktivitäten ................................................. 75
Abbildung 38 - Ablauf der Aktualisierung der Angebote und Projekte .............................. 75
S e i t e | VIII
Tabellenverzeichnis
Tabelle 1 - Vergleich von OLTP und OLAP ......................................................................... 8
Tabelle 2 - Groupware-Applikationen in der Raum-Zeit-Matrix ........................................ 29
Tabelle 3 - Vergleich von BIRT, JasperReports und Pentaho Reporting ............................ 54
Tabelle 4 - Wiring der Komponenten ausgehend von der Kundenauswahl ......................... 74
S e i t e | 1
1 Einleitung
1.1 Motivation
Unternehmen operieren, nicht nur in Zeiten einer Wirtschaftskrise, in einem Umfeld sich
ständig wandelnder Herausforderungen, wie nationaler und internationaler Konkurrenz,
gesetzlichen Regeln, neuen informationstechnischen Entwicklungen und Kostendruck
[Allweyer, 2005, S. 4]. Um ihre Existenz zu sichern, müssen sie Wege finden, diese
Herausforderungen zu bewältigen. Ein Beitrag zur Existenzsicherung kann es sein,
Schwachstellen eines Unternehmens, beispielsweise bei Arbeitsabläufen oder
Entscheidungsfindungsprozessen, zu ermitteln und Impulse zur Verbesserung zu setzen.
Dies ist für Massendaten relativ leicht, da diese Daten strukturiert sind, zumeist in
relationalen Datenbanken mit Systemen wie SAP verwaltet werden und mit vielen
Methoden der Business Intelligence analysiert werden können [vgl. Grothe/Gentsch, 2000,
S. 77]. Untersuchungen zeigen allerdings, dass nur etwa 10-20% der Daten eines
Unternehmens strukturiert sind. Die restlichen 80-90% bestehen aus unstrukturierten
Daten, wie Dokumente, Aktivitäten oder Prozesse, die meist mit dokumentenorientierten
Systemen, wie etwa der Groupwareplattform IBM Lotus Notes - welche in dieser Arbeit
Verwendung findet - in nicht-relationalen Datenbanken abgelegt werden [vgl. Riempp,
1998, S. 25 und S. 72, sowie die dort angegebene Literatur]. Das bedeutet, unstrukturierte
Daten stellen den Großteil der Informationen in einem Unternehmen dar. Diese Zahl zeigt
wie wichtig es ist, unstrukturierte Daten ebenfalls zu analysieren, damit Entscheidungen
nicht nur aufgrund quantitativer Massendaten, sondern zusätzlich mit Hilfe qualitativer
Daten getroffen werden können.
Doch für unstrukturierte Informationen stehen weitaus weniger Business Intelligence
Methoden zur Verfügung. Hinzu kommen die geringeren Fähigkeiten dieser
Anwendungen. Können bei strukturierten Daten, Analysen angewandt werden, die riesige
Datenmengen in relativ kurzer Zeit auf Zusammenhänge sowie Strukturen untersuchen, ist
dies bei unstrukturierten Daten kaum möglich [vgl. Grothe/Gentsch, 2000, S. 20f.].
In der Praxis werden Recherchen mit unstrukturierten Informationen meist manuell
durchgeführt und die Informationen müssen häufig aus mehreren Quellen
zusammengesucht werden, weil eine zentrale, einheitliche Datenbasis, wie etwa ein Data
Warehouse, bei diesen Daten nicht vorhanden ist. Folglich bereiten derartige
Durchführungen einige Probleme. So können unter Umständen relevante Daten nicht
S e i t e | 2
gefunden werden, weil zum Beispiel Datenquellen bei der Suche einfach übersehen
werden. Es müssen zudem mehrere Fenster oder Anwendungen geöffnet werden, um die
Informationen anzuzeigen. Dadurch sind nicht alle Daten auf einen Blick ersichtlich.
Hinzu kommen unterschiedliche Darstellungen der Informationen, was ein manuelles
Analysieren zusätzlich erschwert.
Eine partielle Lösung dieser Probleme liefern Groupwaresysteme wie Lotus Notes. Durch
eine semistrukturelle Speicherung in Datenbanken, können relevante Informationen
leichter gefunden werden. Die Problematik der Übersichtlichkeit, sowie der Darstellung
der Informationen können diese Anwendungen allerdings nicht direkt lösen. Aus diesem
Grund werden Applikationen benötigt, die alle relevanten Daten in einer Übersicht
zusammentragen und die Informationen derart aufbereiten, dass eine Verwendung dieser
Daten im Rahmen einer Entscheidungsfindung vereinfacht wird.
1.2 Aufgabenstellung
Um eine solche Applikation zu entwickeln, bietet IBM Lotus Notes mit der Version 8
mehrere technische Neuigkeiten an. Das neue Composite-Application-Framework
ermöglicht es, verschiedene Datenquellen zu verknüpfen und in mehreren Bereichen
innerhalb einer Applikation anzuzeigen.
Dieses Framework soll als Basis dazu dienen, ein Reportingwerkzeug zu entwickeln,
welches dem Nutzer nach Gesichtspunkten der Business Intelligence Unterstützung bei
Entscheidungen bietet und dadurch ein effizienteres Arbeiten im Rahmen von
Geschäftsprozessen ermöglicht. Dafür sollen verschiedene kundenbezogene Informationen,
wie zum Beispiel Angebote, Projekte oder auch Aktivitäten, in einer
komponentenbasierten Applikation zusammengeführt werden. Sie sollen aus mehreren
Datenbanken extrahiert und kundenspezifisch dargestellt werden. Weiter sollen wichtige
Informationen durch eine grafische Aufbereitung intuitiv verständlich und direkt in einer
Übersicht für den Anwender ersichtlich sein.
Ein Reportingwerkzeug nach Gesichtspunkten der Business Intelligence ermöglicht
entscheidungsrelevante Daten schneller einzusehen, Entscheidungen schneller zu treffen
und, aufgrund der Groupwarefunktionalitäten, weitere Maßnahmen, wie
Geschäftsprozesse, sofort anzustoßen. So können Ansätze der Business Intelligence auch
für semistrukturierte Daten eingesetzt und sinnvoll genutzt werden.
S e i t e | 3
1.3 Aufbau der Arbeit
Im zweiten Kapitel werden die Grundlagen der Themen dieser Arbeit erläutert. Dort wird
die klassische Business Intelligence gegenüber einem Business-Intelligence-
Reportingwerkzeug abgegrenzt und eine Definition von Geschäftsprozessen sowie von
komponentenbasierter Softwareentwicklung hergeleitet.
Das dritte Kapitel beinhaltet ein Konzept zur Lösung der Aufgabenstellung. Zunächst wird
das Composite-Application-Framework, das als Basis für die Softwareentwicklung
eingesetzt werden soll, näher beschrieben. Nach einem Anwendungsszenario werden
anschließend die Anforderungen aus technischer und inhaltlicher Sicht beschrieben.
Danach werden im Sollkonzept verschiedene Lösungsmöglichkeiten erläutert und auf ihre
Vor- und Nachteile hin untersucht.
Im vierten Kapitel wird die prototypische Implementierung dargestellt. Dort werden die
spezifischen, technischen Umsetzungen sowie Besonderheiten einschließlich aufgetretener
Problem des Prototyps erläutert. Dem schließt sich eine kritische Betrachtung der
Arbeitsergebnisse an.
Anschließend werden im fünften Kapitel mögliche Erweiterungen und Verbesserungen
eines Business-Intelligence-Reportingwerkzeuges erörtert.
Das sechste Kapitel enthält eine Zusammenfassung der Arbeit.
S e i t e | 4
2 Grundlagen
2.1 Business Intelligence
2.1.1 Einordnung
Die Business Intelligence ist im Bereich des Managements eines Unternehmens
einzuordnen. Dort müssen Entscheidungen getroffen, durchgesetzt, hinterfragt und
Verantwortung für getroffene Entscheidungen übernommen werden [vgl. Scherm/Pietsch,
2008, S. 431]. Durch Alternativen, unvollständige Informationen und Zufallseinflüsse
ergeben sich dabei häufig Entscheidungsprobleme. Um diese zu lösen müssen die
Problemsituationen analysiert, abstrahiert und modelliert werden [vgl. Lassmann, 2006, S.
411f.]. Dazu werden aktuelle und genaue Informationen benötigt, welche zum Beispiel von
einem Management Support System zur Verfügung gestellt werden (siehe Abb. 1). Diese
Systeme, sowie ihre Architektur und ihre Prozesse gehören zur Business Intelligence. [vgl.
Grothe/Gentsch, 2000, S. 12]
Abbildung 1 - Entscheidungsebene im Aufgabenbereich des Managements (modifiziert übernommen aus [Scherm/Pietsch, 2008, S. 431])
2.1.2 Geschichte der Management Support Systems
Die Historie von Systemen, die einem Management eine Entscheidungsunterstützung
bieten sollen, reicht bis in die 60er Jahre zurück (siehe Abb. 2). Der heute bekannte Begriff
der Business Intelligence ist dabei im Wandel der Zeit entstanden und wird heute vermehrt
angewandt.
S e i t e | 5
Abbildung 2 - Historie von entscheidungsunterstützenden Systemen (übernommen aus [Humm/Wietek, 2005, S. 4])
Die ersten Informationssysteme wurden bereits Ende der 60er Jahre, meist unter dem Titel
des Management Information Systems (MIS) eingeführt. Das Ziel dieser Systeme war es,
„Managern in ihren Unternehmen die Informationen anzubieten, die sie für ihre
Entscheidungen benötigen. Als Nebenbedingungen waren Zeit, Inhalt und Art der
Informationsdarbietung zu optimieren“ [Grothe/Gentsch, 2000, S. 65]. Damit bildeten
diese Systeme durch ihre Informationsbereitstellung die unterste Ebene der Management
Support Systems (MSS) (siehe Abb. 3). Nach Gluchowski et al. konnten aufgrund der
technischen Voraussetzungen die Ziele jedoch nur bedingt eingehalten werden. Die
Hardware- und Softwarekomponenten waren leistungsmäßig nicht in der Lage, die
Informationen mit aufwendigen Modellen oder Methoden zu verarbeiten und in einer
angemessenen Zeit zur Verfügung zu stellen [vgl. Gluchowski et al., 2008, S. 56ff.].
Zudem standen als Datenquellen nur die, als Online-Transaction-Processing-Systems
(OLTP) bezeichneten, operativen Datenbasen der Transaktionssysteme zur Verfügung, die
im allgemeinen Tagesgeschäft im Einsatz waren [vgl. Grothe/Gentsch, 2000, S. 14].
Damit, so Gluchowski et al. weiter, generierten die Anwendungen größtenteils
standardisierte Berichte, die meist unstrukturierte und unsortierte Daten ausgaben.
Letztendlich wurden dem Nutzer mehr Informationen geliefert als er benötigte. Zusätzlich
musste er selber nach Beziehungen suchen und die Daten selbstständig aufbereiten. Aus
diesen Gründen verlor der Begriff der MIS zunehmend an Bedeutung und war häufig
negativer Kritik ausgesetzt [vgl. Gluchowski et al., 2008, S. 56ff.].
S e i t e | 6
Mitte der 70er Jahre löste der Begriff der Decision Support Systems (DSS) den der MIS
ab. Diese interaktiven EDV-gestützten Systeme sollten dem Manager neben den benötigten
Informationen entsprechende Modelle, Methoden und Szenarien anbieten, welche eine
individuelle Analyse erlauben sollten [vgl. Gluchowski et al., 2008, S. 63]. Dank des
Fortschritts der Hardware, mit schnellerer und leistungsfähigerer Verarbeitung der Daten,
war die Basis für eine datenbasierte Entscheidungsunterstützung gelegt [vgl.
Grothe/Gentsch, 2000, S. 14]. Nun war es möglich, aus der Datenflut der MIS sinnvolle
Informationen herauszufiltern, zu säubern und zu verdichten [vgl. Gluchowski et al., 2008,
S. 62ff.]. Im Rahmen der MSS bildeten die DSS die mittlere Schicht, da die
bereitgestellten Daten zusätzlich analysiert wurden (siehe Abb. 3). Aber auch diese
Systeme konnten die hohen Erwartungen nicht vollständig erfüllen. Zwar konnten, dank
der technologischen Fortschritte, strukturierte Daten analysiert werden, jedoch meist nur
für Teilbereiche eines Unternehmens und immer noch auf operativen Datenbasen [vgl.
Gluchowski et al., 2008, S. 73f.; Grothe/Gentsch, 2000, S. 14]. Zudem war die Akzeptanz
der Manager für solche Systeme weiterhin sehr gering. Einem Computer trauten sie nicht
zu, sie bei ihrem kreativen Prozess des Lösens von Problemen zu unterstützen [vgl.
Hannig, 2002, S. 3f.].
Mitte der 80er Jahre hielten immer leistungsfähigere Personal Computer (PC) Einzug in
die Unternehmen. Mit dieser Entwicklung tauchte der Begriff der Executive Information
Systems (EIS) auf [vgl. Gluchowski et al., 2008, S. 74; Hannig, 2002, S. 4f.]. Ursprünglich
in den USA entstanden, zielten diese Programme auf das Topmanagement und Controlling
ab (siehe Abb. 3). Das Ziel waren individuelle Systeme, welche dem Management
entscheidungsrelevante, multidimensionale Daten noch aktueller und besser präsentieren
sollten [vgl. Gluchowski et al., 2008, S. 75]. Durch die Verbreitung der PCs in den meisten
Unternehmen waren die EIS technisch leichter umzusetzen als die vorherigen MIS oder
DSS, bei denen zumeist zentrale Rechner eingesetzt wurden. Das war aber mit einem
entscheidenden Nachteil verbunden: Die individuellen Implementierungen für einzelne
Endanwender hatten zur Folge, dass diese Lösungen nur in den Abteilungen oder
Unternehmen eingesetzt werden konnten, für die sie entwickelt wurden [vgl. Hannig, 2002,
S. 4]. Nachträgliche Änderungen erforderten demzufolge einen großen Aufwand [vgl.
Grothe/Gentsch, 2000, S. 15]. Zudem waren die meisten Nutzer immer noch nicht von
diesen Systemen überzeugt, was einen endgültigen Durchbruch der EIS verhinderte [vgl.
Hannig, 2002, S. 5].
S e i t e | 7
Abbildung 3 - Ebenen der Management Support Systems (modifiziert übernommen aus [vgl. Gluchowski et al., 2008, S. 87])
Laut Hannig fand der Durchbruch im Zuge der immer weiter fortschreitenden
Globalisierung, Anfang der 90er Jahre statt. Waren die meisten Manager in den Jahren
zuvor den Unterstützungssystemen gegenüber eher skeptisch, waren sie nun mehr denn je
auf diese angewiesen. Durch die Dezentralisierung hatte sich die Situation der
Entscheidungsfindung geändert. Sie musste nun möglichst zeitnah, vor Ort, mit aktuellen
Informationen stattfinden, und nicht in der Zentrale, womöglich am anderen Ende der
Welt. Zudem stieg mit der Internationalisierung auch die Menge an Daten, denn diese
kamen aus mehreren Unternehmenssitzen in der ganzen Welt zusammen, ein weiterer
Grund für die steigende Nachfrage nach Management-Support-Systems. Doch die
bisherigen Systeme waren nicht in der Lage, Fehler oder inkonsistente Datenbestände
mehrerer Datenquellen zu korrigieren und somit korrekt zur Verfügung zu stellen, da sie
auf operativen Systemen basierten. Speziell das Problem, dass mehrere inkonsistente
Datenquellen innerhalb eines Unternehmens existierten, gab die Richtung für ein neues
System vor: Man benötigte eine vollständige, einheitliche und konsistente Datenbasis [vgl.
Hannig, 2002, S. 5]. Folge dieser Entscheidung war die Trennung von den bis dahin meist
verwandten OLTP-Systemen, welche mit ihren operativen Datenbasen zusätzlich als
Abfragequellen zur Verfügung standen [vgl. Grothe/Gentsch, 2000, S. 15]. Es entstand
eine zentrale Datenbasis, die mehrere OLTP-Datenquellen konsistent integrieren konnte,
S e i t e | 8
das sogenannte Data Warehouse (DW) [vgl. Grothe/Gentsch, 2000, S. 15; Hannig, 2002, S.
7ff.]. Dementsprechend konnten themen- und zeitorientierte, integrierte und
unveränderliche strukturierte Daten gesammelt und für eine multidimensionale
Datenanalyse zur Verfügung gestellt werden [vgl. Humm/Wietek, 2005, S. 3]. Diese
Analysen bedingten neue Abfragesysteme, die in der Regel mit dem Begriff Online-
Analytical-Processing-System (OLAP) bezeichnet wurden. Diese Programme waren im
Vergleich zu den OLTP-Systemen nur für die Analyse und nicht für die Unterstützung des
operativen Geschäfts zuständig (siehe Tab. 1) [vgl Humm/Wietek, 2005, S. 3f.].
Operativ (OLTP) Dispositiv (OLAP)
Dienst Unterstützung des operativen Geschäfts Unterstützung von Analysen und Entscheidungen
Daten aktuell, detailliert historisch, verdichtet und aufbereitet
Operationen Anlegen, Lesen, Ändern, Löschen multidimensionale Abfragen, ad-hoc, viele Daten je Anfrage, zusätzliche Aktualisierung periodisch im Hintergrund
Tabelle 1 - Vergleich von OLTP und OLAP
(modifiziert übernommen aus [Humm/Wietek, 2005, S. 5])
Im Laufe der 90er Jahre entstanden mit der Entwicklung der Data Warehouses sowie der
OLAP-Systeme weitere Analysewerkzeuge, welche häufig mit dem Begriff der Business
Intelligence (BI) beschrieben wurden. Bereits 1993 von der Gartner Group erstmals
erwähnt [vgl. Hannig, 2002, S. 6], stand dieser Begriff für „Anwendungen und
Technologien zur entscheidungsorientierten Sammlung, Aufbereitung und Darstellung
geschäftsrelevanter Informationen“ [Humm/Wietek, 2005, S. 4]. Heute wird der Begriff
meist als Oberbegriff für weitere Stichwörter wie Data Warehouse, OLAP, Data Mining,
Balanced Scorecards oder Reporting verwendet [vgl. Grothe/Gentsch, 2000, S. 10]. Da die
Grenzen der BI häufig verschwommen sind, wird im nächsten Abschnitt eine Abgrenzung
des Begriffes für diese Arbeit vorgenommen.
2.1.3 Definition von Business Intelligence
Wie erwähnt, wird Business Intelligence häufig als Oberbegriff für Analysewerkzeuge im
Aufgabenbereich des Managements verwendet. Oft findet der Begriff ebenso als Synonym
für MIS Verwendung [vgl. Hannig, 2002, S. 6]. Einerseits kann dieser Auslegung
zugestimmt werden, insoweit MIS dem Nutzer Informationen zur Verfügung stellen, auf
der anderen Seite bieten sie aber keine Analyse, was bei BI-Systemen zumeist der Fall ist.
Das zeigt die Problematik BI klar abzugrenzen. Gluchowski et al. drücken dies aus, indem
S e i t e | 9
sie schreiben, dass „jede gewählte Definition angreifbar bleibt“ [Gluchowski et al., 2008,
S. 90]. Auch Kemper et al. weisen auf das Problem der Vielfalt von unterschiedlichen
Definitionen hin [vgl. Kemper et al., 2006, S. 2f.].
Allgemein festzuhalten bleibt, dass es sich bei BI um die Analyse der gesamten
Unternehmensdaten handelt, welche aufbereitet werden um das Management bei der
Entscheidungsfindung zu unterstützen.
Grothe und Gentsch beschreiben dies folgendermaßen:
„Business Intelligence (BI) bezeichnet den analytischen Prozess, der – fragmentierte
– Unternehmens-und Wettbewerbsdaten in handlungsgerichtetes Wissen über
Fähigkeiten, Positionen, Handlungen und Ziele der betrachteten internen und
externen Handlungsfelder (Akteure und Prozesse) transformiert.“ [Grothe/Gentsch,
2000, S. 19]
In ihrer Definition machen sie deutlich, dass es sich um die Datenanalyse handelt, aber BI
für sie den gesamten Prozess dieser Analyse darstellt.
Humm und Wietek beschreiben BI ähnlich:
„Business Intelligence (BI) ist der Prozess der Umwandlung von Daten in
Informationen und weiter in Wissen. Entscheidungen und Prognosen stützen sich auf
dieses Wissen und schaffen dadurch Mehrwert für ein Unternehmen.“
[Humm/Wietek, 2005, S. 4]
Auch hier wird der Prozess der Datenanalyse als BI definiert.
Moss und Atre definieren BI wie folgt:
„BI is neither a product nor a system. It is an architecture and a collection of
integrated operational as well as decision-support applications and databases that
provide the business community easy access to business data.“ [Moss/Atre, 2003, S.
4]
Moss und Atre gehen somit nicht direkt auf den Prozess ein, sondern beschreiben
Anwendungen der Entscheidungsunterstützung und ihre Architektur als BI.
Hannig beschreibt in seiner Definition einen noch deutlicheren Bezug der BI zu
Anwendungen statt zum Analyseprozess:
S e i t e | 10
„Unter Business Intelligence fasst man [..] Softwarewerkzeuge zur Extraktion und
Auswertung der unternehmensweit vorhandenen Daten und deren Umwandlung in
für die Entscheider relevante Information zusammen.“ [Hannig, 2002, S. 6]
Einen ähnlichen Ansatz liefern Gluchowski et al., welcher von Kemper et al. ebenfalls
aufgegriffen wurde. Sie grenzen BI in drei unterschiedliche Typen ab (siehe Abb. 4):
Abbildung 4 - Abgrenzungen von BI (übernommen aus [Gluchowski et al., 2008, S. 92])
- BI im engeren Sinn: Hierbei handelt es sich um wenige Kernapplikationen, die eine
Entscheidungsfindung unmittelbar, ohne große Methoden- und Modellkonzepte,
unterstützen. Besonders OLAP, MIS und EIS werden in diesem Zusammenhang
erwähnt.
- BI analyseorientiert: Hier umfasst die BI sämtliche Anwendungen, bei denen ein
Entscheider direkt mit dem System auf einer Benutzeroberfläche, modell- und
methodenbasiert eine zielgerichtete Analyse von vorhandenem Datenmaterial
erzeugen kann. Hierzu gehören zum Beispiel die Kernapplikationen OLAP, MIS
und EIS, sowie Text Mining, Data Mining, Ad-Hoc-Reporting, Balanced
Scorecards und Systeme zur Unterstützung der Planung und Konsolidierung.
- BI im weiteren Sinn: In diesem Fall werden alle direkt und indirekt für die
Entscheidungsunterstützung eingesetzten Anwendungen verstanden. Diese
beinhalten Auswertungs- und Präsentationsfunktionen sowie Datenaufbereitung
S e i t e | 11
und –speicherung. [vgl Kemper et al., 2006, S. 3ff.; Gluchowski et al., 2008, S.
89ff.]
Die genannten Definitionen zeigen, dass sie das Ziel der BI ähnlich beschreiben: Die BI
stellt demnach, relevante Daten zur Verfügung, um dem Nutzer beim Treffen von
Entscheidungen eine möglichst gute Unterstützung zu bieten. Die eingangs erwähnte
Problematik der klaren Abgrenzung wird dann beim näheren Betrachten der Definitionen
deutlich. Grothe und Gentsch, sowie Humm und Wietek definieren die BI als Prozess, bei
dem Unternehmensdaten bearbeitet und zur Verfügung gestellt werden. Auf der anderen
Seite beschreiben Moss und Atre, Hannig, sowie Kemper et al. und Gluchowski et al., die
BI als Sammlung von Anwendungen oder Architekturen, die Daten analysieren und dem
Nutzer bereitstellen. Es fällt die unterschiedliche Granularität der Definitionen auf.
Während Prozesse eine weitläufige und grobe Begriffsbestimmung darstellen, verfeinert
der Bezug zu Anwendungen und Architekturen die Beschreibung der BI.
Für diese Arbeit folgt daraus: Die Business Intelligence beschreibt einen Prozess sowie
dessen Werkzeuge, mit denen Unternehmensdaten zusammengeführt, umgewandelt und
analysiert werden, um anschließend durch eine intelligente Aufbereitung eine
Entscheidungsfindung zu unterstützen.
Im folgenden Abschnitt werden nun einzelne Komponenten der BI erläutert.
2.1.4 Bausteine der Business Intelligence
Data Warehouse
Nach Grothe und Gentsch ist ein Data Warehouse (DW) eine zentrale Datenbasis, welche
Informationen aus mehreren operativen Datenquellen (OLTP-Systeme) integriert. Diese
strukturierten Daten werden gegebenenfalls aufbereitet um eine konsistente und korrekte
Informationsbasis zu haben. So werden zum Beispiel Aggregationen von Produkten zu
Produktgruppen oder Kategorisierungen von Umsätzen vorgenommen. Der Vorgang des
Aufbauens einer zentralen Datenbasis sowie das Aufbereiten der Daten wird als Data
Warehousing bezeichnet [vgl. Grothe/Gentsch, 2000, S. 51ff.]. Das Ziel dieses Bausteins
ist „die Verbesserung der unternehmensweiten Informationsversorgung“ [Grothe/Gentsch,
2000, S. 52]. Es ist strikt von operativen Systemen des Tagesgeschäftes zu trennen, da es
nur zu Entscheidungs- und Analysezwecken dient [vgl. Hannig, 2002, S. 7f.].
Eine dezentrale Data Warehouse Lösung besteht, nach Kemper et al., aus isolierten Data
Marts (siehe Abb. 5). Diese zeichnen sich durch eine beschränkte Datenbasis eines
S e i t e | 12
bestimmten Unternehmensbereiches aus, für den häufig performanceoptimierte
Datenbanken aufgrund der speziellen Anwendungsbereiche existieren. Um das Ziel einer
unternehmensweiten Analyse zu erreichen, müssen somit die Daten aus verschiedenen
Data Marts abgerufen und integriert werden [vgl. Kemper et al., 2006, S. 20].
Zentrales Data Warehouse Dezentrales Data Warehouse
Analysesystem Analysesystem Analysesystem
Data Warehouse Data Mart Data Mart
Operative Daten Externe Daten Operative Daten Externe Daten
Abbildung 5 - Architekturvarianten: Zentrales und d ezentrales Data Warehouse (modifiziert übernommen aus [Kemper et al., 2006, S. 20])
Nach Grothe und Gentsch ist demnach ein Data Warehouse bzw. Data Mart letztendlich
kein fertiges zu erwerbendes Produkt, sondern eine auf die Anforderungen und
Rahmenbedingungen des Unternehmens zugeschnittene Lösung. Es wird ein individuelles
Konzept gestaltet, welches anschließend als Grundlage für Analysen zur Verfügung steht
[vgl. Grothe/Gentsch, 2000, S. 52f.].
OLAP
Der Begriff OLAP steht für Online Analytical Processing. OLAP-Systeme ermöglichen
„Managern wie auch qualifizierten Mitarbeitern aus den Fachabteilungen schnelle,
interaktive und vielfältige Zugriffe auf relevante und konsistente Informationen“
[Gluchowski et al., 2008, S. 144]. Wichtig dabei sind „dynamische und multidimensionale
Analysen auf historischen, konsolidierten Datenbeständen“ [Gluchowski et al., 2008, S.
S e i t e | 13
144]. Diese Datenbestände werden von Data Warehouses oder Data Marts zur Verfügung
gestellt [vgl. Grothe/Gentsch, 2000, S. 15].
Ursprünglich wurde der Begriff OLAP über zwölf Kriterien definiert, welche 1995 von
Pendse und Creeth auf fünf Kerninhalte reduziert wurden, die sogenannten FASMI –
Anforderungen [vgl. Kemper et al., 2006, S. 94]. FASMI steht dabei für Fast Analysis of
Shared Multidimensional Information, womit die fünf Kriterien bereits genannt sind:
- Fast: Die Antwortzeiten sollen generell unter 5 Sekunden liegen. Bei komplexen
Anfragen ist eine Antwort in maximal 20 Sekunden zu geben.
- Analysis: Es sollen einfache, intuitive Analysemöglichkeiten angeboten werden.
- Shared: Mehrere Nutzer sollen zeitgleich die Möglichkeit haben, auf die Daten
zuzugreifen. Weiterhin sind differenzierte Zugriffsrechte möglich.
- Multidimensional: Es sollen multidimensionale Betrachtungen der Daten nach
verschiedenen Kriterien möglich sein.
- Information: Die angeforderten Informationen werden ohne Einschränkungen
aufgrund der Datenmenge oder –herkunft wiedergegeben. [vgl. Grothe/Gentsch,
2000, S. 59; Kemper et al., 2006, S. 94f.]
Die Besonderheiten von OLAP sind nicht nur die schnellen Antwortzeiten, sondern
vielmehr die multidimensionalen Betrachtungsweisen der Daten. „Multidimensionale
Datenräume bestehen aus Fakten, Dimensionen und Hierarchisierungen“ [Kemper et al.,
2006, S. 95]. Da das Modell dem „natürlichen Explorationsvorgehen“ des Menschen so
weit wie möglich entsprechen soll, werden multidimensionale Datenräume als Würfel
(Cube) dargestellt [vgl. Grothe/Gentsch, 2000, S. 60]. Die Achsen des Würfels beschreiben
die Dimension der Daten und die einzelnen Elemente des Würfels die Fakten. Diese
Informationen lassen sich beliebig verdichten oder aufbrechen bis auf die unterste Ebene
der Dimension [vgl. Gluchowski et al., 2008, S. 152].
In Abbildung 6 ist dies am Beispiel einer Absatzmenge dargestellt. Dort beschreiben die
Achsen die Dimensionen Produkt, Artikel und Monat. Die jeweiligen Elemente geben die
Absatzmengen für je ein Produkt (z.B. Fußball) mit einem Artikel (z.B. qualitativ
hochwertiger Fußball in blau) in einem Monat wieder.
S e i t e | 14
Abbildung 6 - Würfeldarstellung mehrdimensionaler strukturierter Daten (übernommen aus [Gluchowski et al., 2008, S. 156])
Die Datenwürfel stehen dem Nutzer zur Verfügung um eine interaktive Analyse
durchführen zu können. Hierzu existieren zum Beispiel die folgenden Operationen:
- Drill-Down und Roll-up: Schrittweise Verfeinerung bzw. Verdichtung von
Analyseergebnissen, zum Beispiel von Jahres- über Monats- zu
Tagesauswertungen. Die Verdichtung von Analyseergebnissen nennt man auch
Aggregation.
- Slice-and-Dice: Navigation in einem multidimensionalen Datenraum durch
Fokussierung auf einzelne Aspekte, zum Beispiel Verteilung der Umsätze für ein
bestimmtes Produkt auf unterschiedliche Regionen und Zeiträume.
- Drill-Through: Direkter Zugriff aus analytischen Systemen auf operative
Basisdaten, zum Beispiel auf einzelne Verträge. [vgl. Humm/Wietek, 2005, S. 4]
Somit ist es dem Nutzer möglich, beliebig und dynamisch Analysen im Datenraum zu
starten und die Ergebnisse für seine Entscheidungen zu nutzen [vgl. Kemper et al., 2006, S.
93ff.].
S e i t e | 15
Data Mining
Der Begriff Data Mining existiert bereits seit den 60er Jahren. Dahinter verbergen sich
„Datenmustererkennungs-Verfahren“, welche eine strukturierte Datenmenge mit
leistungsfähigen Techniken auf Muster und Strukturen untersuchen, um die Daten
anschließend zu klassifizieren [vgl. Grothe/Gentsch, 2000, S. 178f.; Hannig, 2002, S. 35].
Ursprünglich aus der Statistik stammend, wurden damals Hypothesen über Datenstrukturen
aufgestellt, welche dann weitestgehend überprüft wurden [vgl. Grothe/Gentsch, 2000, S.
178]. Da zu diesem Zeitpunkt mit OLTP-Systemen gearbeitet wurde, welche für die
täglichen Transaktionen zuständig waren und leistungsmäßig keine großen zusätzlichen
Analysen erlaubten, konnten die aufgestellten Hypothesen nur an bestimmten Stellen
überprüft werden [vgl. Grothe/Gentsch, 2000, S. 178f.]. Somit waren die Fähigkeiten des
Data Minings zunächst beschränkt. Den Durchbruch dieser Verfahren ermöglichten dann
die großen Datenreservoirs, wie Data Warehouses oder Data Marts [vgl. Kemper et al.,
2006, S. 106]. Nun konnten große Datenmengen komplett überprüft und nach interessanten
Zusammenhängen durchforstet werden [vgl. Grothe/Gentsch, 2000, S. 178f.]. Grothe und
Gentsch beschreiben damit auch den entscheidenden Unterschied des heutigen Data
Minings im Vergleich zum ursprünglichen: Wurden damals Hypothesen über Strukturen
einiger Daten aufgestellt, die anschließend zu überprüfen waren, werden heute die
gesamten Daten mit Hilfe verschiedener Algorithmen und Methoden automatisch
analysiert um Strukturen sowie Muster zu erkennen [vgl. Grothe/Gentsch, 2000, S. 178f.].
Hier einige Verfahren des Data Minings:
- Clusterverfahren
- Visualisierungstechniken
- Entscheidungsbaumverfahren
- Assoziationsanalysen
- Konnektionistische Systeme (Künstlich Neuronale Netze) [vgl. Gluchowski et al.,
2008, S. 195ff.; Grothe/Gentsch, 2000, S. 177ff.]
Neben dem Data Mining existieren allerdings noch andere Mining-Typen. So sucht das
Text Mining, zum Beispiel in unstrukturierten Datenbeständen, wie Textdokumenten, nach
Strukturen und Zusammenhängen, während das Web Mining im Internet oder Intranet
sucht [vgl. Hannig, 2002, S. 35; Gluchowski et al., 2008, S. 194f.]
S e i t e | 16
Balanced Scorecard
Das Balanced-Scorecard-System (BSC-System) ist ein Kennzahlensystem, welches von
Kaplan und Norton 1992 entwickelt wurde [vgl. Kemper et al., 2006, S. 116]. Es ist ein
System, mit dem sich „eine Überwachung beschlossener Maßnahmen durch den
koordinierten Einsatz von Messgrößen und Zielvorgaben bewirken lässt“ [Gluchowski et
al., 2008, S. 223]. Diese Größen und Vorgaben werden durch Kennzahlen beschrieben,
welche somit als Informationsbasis für zukunftsgerichtete Entscheidungen zur Verfügung
stehen [vgl. Hannig, 2002, S. 162]. Die Grundidee der BSC, sind die vier unterschiedlichen
Perspektiven (siehe Abb. 7):
- Finanzen: Bewertung der Ergebnisse, die das Unternehmen den Teilhabern bietet.
- Kunden: Beachtung von Kundenanforderungen, -nähe und –zufriedenheit.
- Prozesse: Berücksichtigung der Leistung von internen Prozessen
- Lernen und Entwicklung: Lenkung der Aufmerksamkeit auf die Grundlagen
künftigen Erfolgs (Wissen, Innovation, Fähigkeitsentwicklung) [vgl.
Grothe/Gentsch, 2000, S. 137]
Abbildung 7 - Perspektiven der Balanced Scorecard
(modifiziert übernommen aus [Kemper et al., 2006, S. 117])
Kemper et al., sowie Gluchowski et al. beschreiben zudem, dass neben diesen Perspektiven
unternehmensindividuell weitere ergänzt werden können. Für jede Perspektive werden
S e i t e | 17
vom Unternehmen strategische Ziele und Visionen festgelegt. Anschließend werden je
Perspektive Kennzahlen inklusive des jeweiligen Zielwerts vergeben, um die erreichten
Ergebnisse überprüfbar zu machen. Um die vorgegebenen Ziele zu erreichen, werden
konkrete Maßnahmen mit persönlichen Zuständigkeiten und Statusangaben zugeordnet
[vgl. Kemper et al., 2006, S. 116f.; Gluchowski et al., 2008, S. 223ff.].
Reporting
Laut Kemper et al. versteht man unter dem Begriff Reporting die Erstellung von Berichten
(Reports), welche einen Überblick über betriebswirtschaftliche Sachverhalte liefern. Diese
Erstellung wird durch Reportingwerkzeuge übernommen, welche Berichte, zum Beispiel
periodisch, aperiodisch, also bei bestimmten Ereignissen, oder auch ad hoc automatisch
erstellen. [vgl. Kemper et al., 2006, S. 110ff.]
Die Besonderheit dieser Werkzeuge ist die Datenaufwertung, insbesondere durch eine
„Visualisierung von Sachzusammenhängen in Diagrammen, um die Aufnahme der
Information durch den Empfänger zu verbessern“ [Kemper et al., 2006, S. 110f.]. Weitere
Eigenschaften sind die flexible Handhabung der Werkzeuge und die unterschiedlichen
Formen der Datenquellen [vgl. Grothe/Gentsch, 2000, S. 67]. Berichte können so meist
über einen entsprechenden Editor vom Bearbeiter selbst erstellt und ausgegeben werden
[vgl. Kemper et al., 2006, S. 112f.]. Die Datenquellen sind ebenfalls sehr flexibel und
reichen vom internen Data Warehouse mit strukturierten Daten bis hin zu externen Daten,
wie dem Internet [vgl. Grothe/Gentsch, 2000, S. 67; Gluchowski et al., 2008, S. 205ff.;
Kemper et al., 2006, S. 110ff.].
Gluchowski et al. merken allerdings an, dass sich in letzter Zeit Nachteile des Reportings
stärker zeigen. Durch die immer größer werdende Informationsnachfrage im Unternehmen,
eine zunehmende grafische Aufbereitung und eine größere Masse von Informationen im
Internet, kommen die klassischen Berichte an ihre Grenzen. Neben der Frage der
Aktualität, stehen die enormen Kosten. Es werden viel mehr Berichte gedruckt und
schneller verworfen als noch in den Anfangsjahren des Reportings. Aufgrund dessen geht
der Trend hin zu Dashboards, welche die Informationen nicht in druckoptimierter Form
anbieten, sondern auf eine direkte Nutzung am Bildschirm ausgerichtet sind. Dabei werden
zentrale und relevante Fakten auf eine oder wenige Bildschirmseiten komprimiert. Auch
Dashboards verwenden intuitiv verständliche und anschauliche Gestaltungsarten, wie
Grafiken oder Diagramme, um die Aufnahme von Informationen zu unterstützen [vgl.
Gluchowski et al., 2008, S. 205ff.].
S e i t e | 18
2.1.5 Bezug zu dieser Arbeit
Im Rahmen dieser Arbeit soll ein Business-Intelligence-Reportingwerkzeug für
unstrukturierte Daten erstellt werden. Wie der Begriff Reporting aussagt, liegt der
Schwerpunkt nicht im streng analytischen Prozess, wie beispielsweise beim Data Mining,
sondern in der Erzeugung von Berichten.
Da sich der Trend im Bereich Reporting, wie im vorigen Kapitel erwähnt, weg vom
klassischen Bericht, hin zum Dashboard bewegt, fließt diese Entwicklung unmittelbar in
diese Arbeit mit ein.
Aus diesem Grund wird hier ein Reportingwerkzeug in Form eines Dashboards konzipiert
und implementiert.
2.2 Geschäftsprozesse
2.2.1 Einordnung
Kommerziell ausgerichtete Unternehmen haben vorrangig finanzielle Ziele, beispielsweise
Kostenreduktion oder Gewinnmaximierung [vgl. Fischer et al., 2006, S. 1]. Mit diesen
Zielvorgaben werden die zu leistenden Tätigkeiten, Aufgaben und Arbeitsabläufe immer
wieder auf ihre Effizienz hin untersucht [vgl. Staud, 2006, S. 5]. Aufgrund der
unterschiedlichen, meist miteinander vernetzten Aufgaben, werden in zunehmendem Maße
die Abläufe dieser Arbeiten, also die Prozesse analysiert [vgl. Staud, 2006, S. 5;
Rosenkranz, 2006, S. 1; Fischer et al., 2006, S. 1]. Geschäftsprozesse sind somit wichtige
Bestandteile eines Unternehmens, um dessen Ziele, sei es finanziell, zeitlich oder
qualitativ, zu erreichen.
2.2.2 Organisation eines Unternehmens
Klassischerweise werden Unternehmen in eine Aufbau- und Ablauforganisation unterteilt
[vgl. Werth, 2006, S. 19].
Aufbauorganisation
Bei der statischen Aufbauorganisation steht dabei „die Strukturierung des Unternehmens
mit seinen Elementen – in der Regel sind dies Abteilungen, Teams und Mitarbeiter – im
Mittelpunkt“ [Fischer et al., 2006, S. 1]. Es werden Aufgaben im Unternehmen
beschrieben und an die entsprechenden Aufgabenträger verteilt [vgl. Werth, 2006, S. 19].
Aufgabenträger sind also Personen mit entsprechenden Fähigkeiten, die die jeweilige
Stelle ausfüllen (siehe Abb. 8) [vgl. Fischer et al., 2006, S. 2].
S e i t e | 19
Abbildung 8 - Beispiel einer Aufbauorganisation (übernommen aus [Fischer et al., 2006, S. 2])
Ablauforganisation
Nach Fischer et al. und Werth beschreibt die Ablauforganisation im Gegensatz zur
statischen Aufbauorganisation, die dynamische Komponente des Unternehmens, häufig als
Unternehmensverhalten bezeichnet. Hier stehen die Beziehungen innerhalb des
Unternehmens im Mittelpunkt. Beschrieben werden die zeitlichen und räumlichen
Abfolgen von betrieblichen Aufgaben (siehe Abb. 9). Dazu werden Ressourcen auf Basis
der Aufbauorganisation den jeweiligen Aufgaben zugeordnet. Zudem werden die
Konsequenzen einer dynamischen Entscheidung spezifiziert, da die entsprechenden
Ressourcen direkt zugeordnet werden können, je nach dem, welche Alternativen einer
Abfolge von Aufgaben ausgewählt werden. Dass durch diese dynamische Struktur und die
vielfältigen Möglichkeiten der Aufgabenverteilung eine starke Vernetzung innerhalb des
Unternehmens herrscht, liegt daher nahe [vgl. Werth, 2006, S. 19f.; Fischer et al., 2006, S.
3].
Fischer et al. erläutern zudem, dass ein Ablauf verschiedener Aufgaben immer einem zu
erreichenden Ziel folgt, welches zu erreichen ist. Um diesen Ablauf zu starten, wird ein
Start bzw. Anstoß benötigt (siehe Abb. 9). Beispielsweise könnte es im Vertrieb für die
Bearbeitung einer Aufgabe notwendig sein, Informationen aus der Entwicklung einzuholen
und eine Teilaufgabe an den Kundenservice weiter zu geben. Somit kann eine Abfolge von
Aufgaben mit Start und Ziel beschrieben werden, welche man im Zusammenhang mit der
Aufbau- und Ablauforganisation auch Geschäftsprozess nennt. Der Geschäftsprozess ist
S e i t e | 20
also die reale Umsetzung der Ablauforganisation in der Aufbauorganisation [vgl. Fischer et
al., 2006, S. 3].
Abbildung 9 - Beispiel einer Ablauforganisation (übernommen aus [Fischer et al., 2006, S. 3])
2.2.3 Definition von Geschäftsprozessen
Nachdem klar geworden ist, dass ein Geschäftsprozess im Unternehmen durch das
Zusammenwirken von Aufbau- und Ablauforganisation zustande kommt, wird nun der
Prozess genauer betrachtet.
Allgemein besitzen Prozesse eine Eingabe und Ausgabe bzw. einen Anstoß und ein Ziel,
wobei dazwischen eine Bearbeitung bzw. Transformation liegt (siehe Abb. 10), welche
sich über mehrere Stufen erstrecken kann [vgl. Schmidt, 2002, S. 1, Fischer et al., 2006, S.
6].
Abbildung 10 - Einfaches Prozessprinzip (modifiziert übernommen aus [Fischer et al., 2006, S. 6])
S e i t e | 21
Innerhalb eines Prozesses, fallen Aufgaben bzw. Tätigkeiten an, welche nacheinander oder
auch parallel, von einem oder mehreren Aufgabenträgern, in einer abgeschlossenen Folge,
bearbeitet werden (siehe Abb. 11) [vgl. Rosenkranz, 2006, S. 1; Fischer et al., 2006, S.
4ff.]. Dazu werden bestimmte Faktoren, in Form von Materialien oder Informationen,
jeweils bearbeitet und weitergegeben [vgl. Werth, 2006, S. 21f.; Fischer et al., 2006, S.
57]. Da nicht jede Aufgabe von der Komplexität her, der Nächsten entspricht, erläutert
Staud, dass Aufgaben solange aufgebrochen werden können, bis eine Elementaraufgabe
vorliegt, welche die unterste Ebene darstellt. So können verschiedene Aggregationsebenen
dargestellt werden. Je nachdem ob sie aufgebrochen oder aggregiert sind [vgl. Staud, 2006,
S. 5f.].
Abbildung 11 - Aufgaben in einem Prozess (modifiziert übernommen aus [Fischer et al., 2006, S. 6])
Diese allgemeine Beschreibung für Prozesse soll als Grundlage für die weiteren
Definitionen dienen, welche zu Genüge in der Literatur zu finden sind, sich aber in ihren
Einzelheiten unterscheiden.
Staud definiert einen Geschäftsprozess folgendermaßen:
„Ein Geschäftsprozess besteht aus einer zusammenhängenden abgeschlossenen Folge
von Tätigkeiten, die zur Erfüllung einer betrieblichen Aufgabe notwendig sind. Die
Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten unter
Nutzung der benötigten Produktionsfaktoren geleistet. Unterstützt wird die
Abwicklung der Geschäftsprozesse durch das Informations- und
Kommunikationssystem [..] des Unternehmens.“ [Staud, 2006, S. 9]
S e i t e | 22
Stauds Beschreibung ähnelt stark der Grundlage, welche vorher beschrieben wurde, und
bezieht lediglich die Unterstützung eines Informationssystems mit ein.
Eine weitere Definition erläutert Allweyer:
„Geschäftsprozess (business process) Ein Geschäftsprozess (oft abgekürzt nur
‚Prozess‘ genannt) ist eine Abfolge von Funktionen (auch als Aktivitäten bezeichnet)
zur Erfüllung einer betrieblichen Aufgabe, wobei eine Leistung in Form von
Informations- und/oder Materialtransformation erbracht wird.“ [Allweyer, 2005, S.
8]
In dieser Definition bezieht sich Allweyer ebenfalls auf die Folge von Aktivitäten, aber
legt einen besonderen Wert auf die Leistungserbringung durch die Transformation.
Die Definition von Werth lautet:
„Ein Geschäftsprozess ist die in zeit- und sachlogischen Beziehungen stehende
Menge von Verrichtungen zum Zweck der Leistungserbringung für interne oder
externe Kunden.“ [Werth, 2006, S. 21]
Auch hier steht der Gedanke der Leistung, ähnlich wie bei Allweyer, im Mittelpunkt.
Zudem bezieht Werth den Begriff des Geschäftsprozess explizit auf interne und externe
Kunden.
Schmidt definiert einen Geschäftsprozess, bzw. in seinem Buch einen Prozess, wie folgt:
„Ein Prozess transformiert Input, häufig über mehrere Stufen, in Output. Je nach
Anwendungsbereich sind Transformation, Input und Output unterschiedlich zu
interpretieren. Ein betriebswirtschaftlicher Prozess bzw. ein Unternehmensprozess
repräsentiert die Organisation einer Produktion zur Wertschöpfung mit dem Ziel,
durch Einsatz von Inputfaktoren gewünschte Outputgüter zu erzeugen. Letztere
werden als Ergebnisse des Prozesses als Produkte in Form von Sach- oder
Dienstleistungen für die Nachfrage verfügbar gemacht.“ [Schmidt, 2002, S. 1]
Schmidt zielt mit seiner Definition auf die Organisation zur Wertschöpfung ab, womit
auch er einen Prozess mit dem Erzielen einer Leistung in Verbindung bringt. Zusätzlich
erwähnt er die Bereitstellung des Ergebnisses für die Nachfrage, was den Mehrwert für das
Unternehmen verdeutlicht.
Eine weitere Begriffsbestimmung liefern Fischer et al.:
S e i t e | 23
„Ein Prozess beschreibt einen betrieblichen Ablauf, das heißt den Fluss und das
Bewegen von Material und Informationen unter Anwendung von Operationen und
Entscheidungen. Er beschreibt Reihenfolgen von funktionsübergreifenden
Aktivitäten mit Anfang und Ende sowie klar definierten Eingaben und Ausgaben.
Aus Sicht des Unternehmens soll er einen Mehrwert schaffen.“ [Fischer et al., 2006,
S. 5]
Neben der allgemeinen Beschreibung des Prozesses, sehen auch Fischer et al. einen
Mehrwert für das Unternehmen als Ziel eines Geschäftsprozesses.
Zusammenfassend lässt sich festhalten, dass die allgemeine Beschreibung in allen zitierten
Definitionen größtenteils bestätigt wurde. Demnach beschreiben Geschäftsprozesse eine
klar definierte Abfolge von betrieblichen Aufgaben, wobei ein Input, eventuell über
mehrere Stufen, zielgerichtet bearbeitet und für die Nachfrage bereitgestellt wird.
Besonders hervorgehoben wurde in einigen Definitionen die Leistungserbringung durch
die Transformation in einem Prozess. Da durch die Bearbeitung, der Input in einen
veränderten Output umgewandelt wird, macht diese Betonung durchaus Sinn. Zudem
entsteht durch diese Leistung ein Mehrwert für das Unternehmen, da ein Geschäftsprozess
mit einem klaren Ziel angestoßen und das Ergebnis anschließend zur Verfügung gestellt
wird.
Folglich lässt sich für diese Arbeit festhalten, dass ein Geschäftsprozess neben dem Input
und Output bzw. dem Start und Ziel, eine klar definierte Abfolge von Aufgaben besitzt, bei
denen Informationen durch Aufgabenträger auf verschiedenen Ebenen bearbeitet werden.
Die Transformation der Informationen beschreibt eine wichtige Leistungserbringung,
welche dem Unternehmen einen Mehrwert als Output bereit stellt.
2.2.4 Probleme von Geschäftsprozessen
Aus den voran gegangenen Abschnitten lässt sich ableiten, dass Geschäftsprozesse einen
wichtigen Bestandteil eines Unternehmens bilden und für dessen Erfolg oder Misserfolg
mitbestimmend sind. Aus diesem Grund werden ihre Probleme häufig beleuchtet.
Allweyer nennt einige davon, besonders die Verwendung der Informationen bzw.
Dokumente betreffend, welche im Zuge eines Geschäftsprozesses genutzt werden.
Zunächst erwähnt er die Mehrfacherfassung von Informationen. Hier besteht das Problem
darin, dass viele der verwendeten Dokumente zum größten Teil dieselben Informationen
enthalten.
S e i t e | 24
Einen weiteren Problempunkt erkennt er in der redundanten Datenhaltung. Werden, im
Unterschied zur Mehrfacherfassung, die gleichen Dokumente in beteiligten
Organisationseinheiten verwendet, besteht die Möglichkeit, dass einige Mitarbeiter mit
einer alten und einige mit einer aktuellen Version arbeiten.
Aus diesen beiden Problemen resultieren zahlreiche Fehlerquellen, denn je mehr
Informationen erfasst oder übertragen werden, desto leichter können sich Fehler
einschleichen.
Das größte Problem bei Geschäftsprozessen ist jedoch die geringe Transparenz. Durch die
Vielfalt der verschiedenen Dokumente und die redundante Datenhaltung sind
Informationen weit verstreut. In vielen Fällen ist es dadurch kaum möglich, alle
Informationen zu einem bestimmten Thema zusammenzutragen [Allweyer, 2005, S. 11f.].
Letztendlich besteht die Problematik bei Geschäftsprozessen demnach zumeist darin, die
exakten Informationen zu finden und bereit zu stellen, um Aufgaben innerhalb der
Prozesse möglichst effizient durchzuführen.
2.2.5 Bezug zu dieser Arbeit
Da die Abfolgen von Aufgaben, sowie die zuständigen Aufgabenträger und Ebenen häufig
von Konsequenzen einer Entscheidung abhängen, müssen diese Entscheidungen auf der
Basis exakter Informationen gut begründet sein.
Aus diesem Grund soll in dieser Arbeit ein Werkzeug erstellt werden, welches einer
entscheidungsbefugten Person eine zweckmäßige Unterstützung bei ihrer
Managementaufgabe gibt und dadurch den erfolgreichen Ablauf von Geschäftsprozessen
fördert.
2.3 Komponentenbasierte Softwareentwicklung
2.3.1 Einordnung
Wie Stritzinger beschreibt, werden in vielen Bereichen der Wirtschaft vorgefertigte
Bauteile oder Bausteine wiederverwendet. Dies hat den Vorteil, dass Elemente nicht jedes
Mal neu konzipiert werden müssen, sondern als Standardkomponenten zur Verfügung
stehen. Somit werden Entwicklungskosten gespart und es ist möglich, auf bewährte stabile
Lösungen zurückzugreifen [vgl. Stritzinger, 1999, S. 104].
Diese Tatsache spiegelt sich auch in zunehmendem Maße in der Softwareentwicklung
wieder [vgl. Stritzinger, 1999, S. 104]. Die Komplexität der Entwicklung nimmt zu, was zu
S e i t e | 25
hohen Kosten und einer größeren Fehleranfälligkeit führt [vgl. Hinzen, 2005, S. 3].
„Softwaresysteme werden immer umfangreicher, müssen aber dennoch kostengünstig und
in einem vorgegebenen Zeitrahmen auf den Markt gebracht werden“ [Beydeda, 2007, S.
243]. Da in der Entwicklung unterschiedlicher Software zudem oftmals gleiche Probleme
auftreten, die jedes Mal neu gelöst werden müssen, bietet es sich an, bereits bestehende
Lösungen wiederzuverwenden und in die eigene Software einzubinden [vgl. Bischofs,
2000, S. 4, Hinzen, 2005, S. 3].
Es wird also vermehrt versucht, einzelne Softwarelösungen als Bausteine in ein großes,
komplexes Softwaresystem einzusetzen, um Kosten zu sparen, Fehler zu vermeiden und
die Qualität zu steigern [vgl. Bischofs, 2000, S. 4; Beydeda, 2007, S. 243; Hinzen, 2005, S.
3, Andresen, 2003, S. 1f.; Maydl, 2005, S. 29].
2.3.2 Definition von Komponenten
Wie zuvor beschrieben, basiert die komponentenbasierte Softwareentwicklung auf der
Integration bestehender Softwarebausteine, den Komponenten.
Hinzen und Stritzinger, sowie Hau und Mertens erläutern in ihrer Literatur das Problem,
dass jedoch für den Begriff der Softwarekomponente keine einheitliche Definition
existiert. Aus diesem Grund wird häufig der Begriff der objektorientierten
Programmierung mit dem der Komponente in Zusammenhang gebracht. Dass dies ein
Schritt in die richtige Richtung ist, wird durch die Konzepte wie Kapselung und
Polymorphismus deutlich. Damit ist es möglich, Funktionen einzelner Objekte aufzurufen
oder Implementierungen aus Klassen zu vererben. Problematisch wird diese Technik
allerdings, sobald versucht wird, eine Wiederverwendung in anderen Bereichen zu
realisieren. Durch die technische Beschränktheit der objektorientierten Programmierung
auf einzelne Anwendungen und Bereiche, ist diese Lösung zu starr bzw. unflexibel, da sie
nur soweit wiederverwendet werden kann, wie es die bisherige Implementation zulässt.
Wollte man diese Lösung weiter verwenden, müssten gegebenenfalls Änderungen im Code
vorgenommen werden, was wiederum der Grundidee einer fertigen Komponente
widerspricht [vgl. Hinzen, 2005, S. 4; Stritzinger, 1999, S. 105; Hau/Mertens, 2002, S.
332].
Da diese Beschreibung folglich nicht zu hundert Prozent zutrifft, wird hier die häufig
zitierte Definition von Szyperski et al. als Grundlage verwendet:
„A software component is a unit of composition with contractually specified
interfaces and explicit context dependencies only. A software component can be
S e i t e | 26
deployed independently and is subject to composition by third parties.” [Szyperski et
al., 2002, S. 41]
Damit entspricht eine Implementierung dieser Definition weitestgehend einer Blackbox-
Wiederverwendung, denn der Nutzer hat keinerlei Möglichkeit in den Quellcode der
Komponente zu schauen und kann eine Interaktion nur über die definierten Schnittstellen
erreichen [vgl. Hinzen, 2005, S. 4f.; Bischofs, 2000, S. 5; Nierstrasz/Lumpe, 1997, S. 3].
Im Gegensatz dazu spricht man von einer Whitebox-Wiederverwendung, wenn der
Quellcode einsehbar ist und bei der Implementierung beachtet werden muss [vgl. Hinzen,
2005, S. 5; Bischofs, 2000, S. 5]. Diese Art der Wiederverwendung wird allerdings
seltener eingesetzt, da durch die Beachtung des Quellcodes mehr Fehlerquellen auftreten
können als bei der Verwendung der vordefinierten Schnittstellen einer Blackbox-
Implementation [vgl. Hinzen, 2005, S. 5]. Weiterhin ist die Softwarekomponente
kontextabhängig, was bedeutet, dass sie nicht nur für einen speziellen Themenbereich
konzipiert wurde, sondern auch für ein spezielles technisches Umfeld, zum Beispiel
bestimmte Plattformen [vgl. Hinzen, 2005, S. 4f.; Bischofs, 2000, S. 6].
Zusammenhängend mit dem Einsatz solcher Komponenten, so Hinzen und Bischofs, sind
Änderungen in der Struktur der Software, in Form von Schnittstellen. Im einfachsten Fall
besteht eine komplette Anwendung nur aus einzelnen Komponenten, die ausschließlich
über gegebene Schnittstellen miteinander kommunizieren. Ein Nachteil dieser Art der
Programmierung ist der Zwang, vorgegebenen Schnittstellen und Normen strikt
einzuhalten. Sobald eine neue Version einer Komponente eine Schnittstelle ändert oder
diese sogar entfällt, funktioniert unter Umständen die gesamte Anwendung nicht mehr
[vgl. Hinzen, 2005, S. 5; Bischofs, 2000, S. 7].
Es lässt sich also festhalten, dass eine Komponente „im Wesentlichen ein abgeschlossener
und einzeln vermarktbarer Softwarebaustein“ [Hau/Mertens, 2002, S. 332] ist, der
unabhängig und sehr flexibel von Dritten, zur Wiederverwendung über spezielle
Schnittstellen, genutzt werden kann.
2.3.3 Komponentenframeworks
Eine Besonderheit in der Softwareentwicklung mit Komponenten, sind die sogenannten
Frameworks oder auch Komponentenframeworks. Ein Framework ist eine
wiederverwendbare, halbfertige Anwendung, welche verschiedene Komponenten mit
einem definierten Kooperationsverhalten und einzuhaltenden Formalismen einbindet [vgl.
Bischofs, 2000, S. 10; Andresen, 2003, S. 53]. Damit stellt es ein Rahmenwerk zur
S e i t e | 27
Verfügung, dass zur Entwicklung und Ausführung von Komponenten dient [vgl. Hinzen,
2005, S. 19]. Durch das Spezifizieren und Initiieren der Komponenten innerhalb des
Frameworks entsteht eine fertige, gebräuchliche Anwendung, welche Aufgaben in einem
oder mehreren Geschäftsbereichen erfüllen kann [vgl. Hinzen, 2005, S. 19;
Nierstrasz/Lumpe, 1997, S. 10; Bischofs, 2000, S. 10; Andresen, 2003, S. 53ff.].
Frameworks verleihen Komponenten somit durch die Verknüpfung mit anderen
Komponenten eine verwendbare Bedeutung [vgl. Nierstrasz/Lumpe, 1997, S. 10]. Ein
Vorteil von Frameworks, so Hinzen, ist die allgemeine Infrastruktur, die den
einzusetzenden Komponenten als Basis zur Verfügung steht. Dadurch erhöht sich „die
Möglichkeit der Wiederverwendbarkeit von Komponenten, da standardisierte
Schnittstellen und Dienste in Anspruch genommen werden können“ [Hinzen, 2005, S. 19].
Beispiele für Komponentenframeworks sind unter anderem Sun JavaBeans oder Microsoft
Component Object Model (COM) [vgl. Hinzen, 2005, S. 20; Nierstrasz/Lumpe, 1997, S.
10f.].
2.3.4 Bezug zu dieser Arbeit
Das zu implementierende Werkzeug soll als komponentenbasierte Applikation auf Basis
des Composite-Application-Frameworks realisiert werden. Somit wird sich die
Softwareentwicklung überwiegend komponentenbasiert gestalten.
S e i t e | 28
3 Konzept für ein Reportingwerkzeug
Wie in den voran gegangenen Kapiteln erwähnt, beinhaltet diese Arbeit das Konzept und
die Implementierung eines Reportingwerkzeuges. Es soll als komponentenbasierte
Applikation nach Gesichtspunkten der Business Intelligence, kundenbezogene Daten so
aufbereiten, dass dem Anwender eine klare Übersicht über relevante Informationen zur
Verfügung steht. Damit soll dem Nutzer eine Unterstützung bei der Entscheidungsfindung
im Rahmen von Geschäftsprozessen gegeben werden.
Da als Basis für die komponentenbasierte Applikation dieser Arbeit das Composite-
Application-Framework von IBM Lotus Notes 8 dienen soll, folgt erst eine Erläuterung
dazu. Danach wird ein Anwendungsszenario für den Einsatz dieses Werkzeuges
beschrieben. Anschließend werden die Anforderungen an ein Werkzeug dieser Art, sowohl
inhaltlich als auch technisch, aufgestellt, um darauf aufbauend das Soll-Konzept zu
formulieren. Abschließend werden verschiedene Möglichkeiten zur Lösung des Konzeptes
untersucht.
3.1 Erläuterungen zum Composite-Application-Framework
Das Composite-Application-Framework ist Teil der Groupwareplattform IBM Lotus Notes
/ Domino und wurde mit der Version 8 eingeführt. Zum Verständnis der grundlegenden
Eigenschaften dieser Technologien, werden in den folgenden Abschnitten die Themen
Groupware, IBM Lotus Notes / Domino und Composite-Application-Framework erläutert.
3.1.1 Groupware
Unter dem Begriff Groupware versteht man Applikationen, die eine Unterstützung des
kooperativen Arbeitens bieten [vgl. Coleman, 1997, S. 1f.; Ebel, 2006, S. 1; Johansen,
1988, S. 1]. Bekannt wurde der Begriff 1988 durch Johansen, wobei die Autoren Johnson-
Lenz den Ausdruck bereits 1982 erstmals erwähnten [vgl. Nastansky et al., 2002, S. 239].
Die Definition von Johansen lautete damals:
„Groupware is a generic term for specialized computer aids that are designed for the
use of collaborative work groups. Typically, these groups are small, projectoriented
teams that have important tasks and tight deadlines.“ [Johansen, 1988, S. 1]
Bis heute sind weitere unterschiedliche Beschreibungen hinzu gekommen, weshalb sich
keine einheitliche Begriffsbeschreibung zum Thema Groupware finden lässt [vgl. Riempp,
1998, S. 26]. Aus diesem Grund wird hier unter dem Begriff Groupware eine Applikation
verstanden, die die kooperative Arbeit eines Teams in ihrem Arbeitsfluss sowie ihren
S e i t e | 29
Kommunikations- und Arbeitsinteraktionen unterstützt [vgl. Nastansky et al., 2002, S.
239].
Nach Johansen werden Groupware-Applikationen anhand der Dimensionen Raum und
Zeit, in Bezug auf die Arbeit einer Gruppe, in einer Matrix klassifiziert (siehe Tab. 2)
[Johansen, 1988, S. 44]. Dies bedeutet, dass Systeme danach eingeordnet werden, ob
verteilte oder lokale bzw. face-to-face Szenarien unterstützt werden und ob die
Kooperationspartner zur gleichen Zeit oder zu verschiedenen Zeiten zusammenarbeiten
[vgl. Rubart, 2005, S. 52; Luczak et al., 2001, S. 84]. Nastansky et al. weisen jedoch auf
die Problematik dieser Methode hin. Da bestimmte Applikationen nicht eindeutig zu
einzelnen Kategorien zugeordnet werden können, eignet sich diese Darstellung eher zur
Klassifikation der Verwendung von Groupware-Applikationen als für die Beschreibung
der möglichen Groupware-Funktionalitäten [vgl. Nastansky et al., 2002, S. 239f.].
Zusammenarbeit der Teammitglieder
zu gleicher Zeit zu verschiedenen Zeiten
am gleichen Ort (lokal)
- Systeme zur computerunterstützten Sitzungsmoderation
- Präsentationssysteme - Group Decision Support Systeme
- Systeme zum Terminkalendermanagement für Gruppen
- Projektmanagement-Systeme
an verschiedenen Orten (verteilt)
- Audio- und Videokonferenzsysteme
- Screen-Sharing-Systeme - Mehrautorensysteme
- E-Mail-Systeme - Voice-Mail-Systeme - Systeme für Electronic
Conferencing - Elektronische Bulletin Boards - Shared Information Systems - Workflow-Systeme
Tabelle 2 - Groupware-Applikationen in der Raum-Zeit-Matrix (modifiziert übernommen aus [Nastansky et al., 2002, S. 241])
3.1.2 IBM Lotus Notes / Domino
Bei Lotus Notes / Domino handelt es sich um eine Client-Server-orientierte
Groupwareplattform der Firma IBM, welche mit dokumentenbasierten, nicht-relationalen
Datenbanken arbeitet [vgl. Riempp, 1998, S. 68f.; Ebel, 2006, S. 19]. Somit ist die
Anwendung auf unstrukturierte und semistrukturierte Daten, wie Dokumente, E-Mails oder
Prozesse, ausgerichtet und weniger auf, in relationalen Datenbanken gespeicherte,
strukturierte Massendaten [vgl. Grothe/Gentsch, 2000, S. 20f.; Nastansky et al., 2002, S.
242ff.]. Lotus Notes bildet dabei den Client, wohingegen Lotus Domino das Produkt für
den Server darstellt [vgl. Ebel, 2006, S. 19]. Mit weltweit mittlerweile mehr als 140
Millionen Lizenzen ist die Software eines der führenden Produkte im Bereich Groupware
[vgl. IBM Presseinformation, 2008].
S e i t e | 30
Lotus Notes / Domino verfügt über gängige Office-Funktionalitäten, wie E-Mail,
Kalender, Aufgabenplanung sowie Messaging [vgl. IBM Lotus Notes, 2008]. Eine
markantere Eigenschaft, so Ebel, ist jedoch die Speicherung von Daten und Design in
einem Dokument, in einer nicht-relationalen Datenbank, was einfache Zugriffe auf alle
benötigten Informationen ermöglicht [vgl. Ebel, 2006, S. 19]. Um Daten auch offline
verfügbar zu machen, stellt Lotus Notes / Domino eine Replikations-Funktionalität zur
Verfügung, die es erlaubt Datenbanken vom Server zu kopieren, lokal zu verwenden und
anschließend wieder mit dem Server zu synchronisieren [vgl. Riempp, 1998, S. 70; Ebel,
2006, S. 20]. Weitere Eigenschaften sind die Plattformunabhängigkeit von Notes und
Domino, die Portabilität der Anwendungen sowie das umfangreiche Sicherheitskonzept
mit einer integrierten Public-Key-Infrastructure (PKI) [vgl. Riempp, 1998, S. 68ff.; Ebel,
2006, S. 19ff.].
Da Lotus Notes / Domino nicht nur für Endanwender gedacht ist, besteht zusätzlich die
Möglichkeit, mit dem Lotus Domino Designer schnell eigene Anwendungen per Rapid
Application Development and Deployment (RADD) zu entwickeln. Dabei werden die
Programmiersprachen LotusScript sowie Lotus Makrosprachen (@Functions und
@Commands) eingesetzt [vgl. Ebel, 2006, S. 21; Coleman, 1997, S. 354f.]. Mit der
Version 8 wurden die bisherigen Entwicklungsmöglichkeiten von Notes Anwendungen
nochmals erweitert. Nun, da das Programm auf den offenen Standards der Eclipse Rich
Client Platform (RCP) basiert, können benutzerspezifische Rich-Client-Anwendungen, die
zum Beispiel mit anderen Systemen kommunizieren, leicht eingebunden werden. Damit
unterstützt Lotus Notes / Domino die Entwicklung einer serviceorientierten Architektur
(SOA) [IBM Weiterentwicklung, 2008].
3.1.3 Composite-Application-Framework von IBM Lotus Notes 8
Wie schon erwähnt, wurde mit der Version 8 von Lotus Notes / Domino auf die Eclipse
RCP umgestellt. Seitdem existiert das Composite-Application-Framework (CAF) unter
Lotus Notes.
Das CAF ist ein Komponentenframework, das, wie bereits im Grundlagenkapitel erwähnt,
ein Rahmenwerk für die Entwicklung und Einbindung von Komponenten zur Verfügung
stellt. Das ermöglicht unterschiedliche Anwendungen in einem gemeinsamen Kontext zu
nutzen. In diesem Fall können Lotus Notes Standard-Komponenten wie E-Mail, Kalender
oder Kontakte, eigene Notes Anwendungen, Web-Applikationen und vor allem Rich-
Client-Anwendungen als Komponenten eingebunden werden, die durch das CAF auf einer
S e i t e | 31
Oberfläche angezeigt und miteinander verknüpft werden können (siehe Abb. 12) [vgl. IBM
Composite Applications, 2008, S. 5ff.].
Abbildung 12 - Beispiel einer Composite Application (übernommen aus [IBM Redbooks, 2008, S. 81])
Über den Composite Application Editor werden verschiedenen Applikationen zu einer
Composite Application hinzugefügt und die Eigenschaften der einzelnen Komponenten
bearbeitet (siehe Abb. 13) [vgl. IBM Composite Applications, 2008, S. 45ff.].
Zur Verknüpfung der einzelnen Anwendungen dient das sogenannte Wiring, welches vom
Property Broker gesteuert wird. Komponenten können dort Werte als Property
veröffentlichen und mit einer Action Werte nachfragen. Diese Schnittstellen werden in
einer WSDL-Datei gespeichert, um eine einheitliche Definition für alle Anwendungen zu
gewährleisten. Nachdem die Schnittstellen definiert sind, können die einzelnen
Komponenten per Wire miteinander verknüpft werden (siehe Abb. 14) [vgl. IBM
Composite Applications, 2008, S. 47ff.].
S e i t e | 32
Abbildung 13 - Composite Application Editor (übernommen aus [IBM Composite Applications, 2008, S. 46])
Abbildung 14 - Wiring einer Composite Application (übernommen aus [IBM Composite Applications, 2008, S. 48])
S e i t e | 33
3.2 Anwendungsszenario
Das folgende Szenario dient dazu, das Einsatzfeld eines Reportingwerkzeuges in der Praxis
zu beschreiben und die Vorteile einer solchen Applikation zu verdeutlichen.
Hans ist der Abteilungsleiter des Vertriebs in einem Softwareunternehmen. In seiner
Abteilung arbeiten fünf weitere Mitarbeiter. Jeder Mitarbeiter betreut seine eigenen
Kunden, die ihm von Hans zugewiesen werden. Jedem der Kunden werden individuelle
Angebote unterbreitet, welche beispielsweise die Anpassung und den Kauf der Software
oder Software-Schulungen beinhalten.
Das Unternehmen arbeitet mit einer Groupwareplattform, welche neben den allgemeinen
Unternehmensdaten auch die kundenbezogenen Angebote, Projekte und Geschäftsprozesse
beinhaltet. Da Hans als Abteilungsleiter die Rechte besitzt, alle Kundenbeziehungen zu
verwalten, hat er Einblick in alle Angebote und Projekte, die für einen Kunden bestehen.
Peter ist einer der Mitarbeiter im Vertrieb. Im letzten Monat wurde von ihm eine
Auftragsanfrage bearbeitet, bei der ein langjähriger Kunde seine gesamte Organisation mit
neuer Software ausstatten und eine Vielzahl an Mitarbeitern für die neue Software schulen
lassen möchte. Aus diesem Grund hat Peter ein Angebot erstellt und dem Interessenten
zugeschickt. Nach einer Woche wurde dieses Angebot jedoch abgelehnt. Da die
Mitarbeiter der Vertriebsabteilung bei geschäftlichen Vorfällen wie diesem die
entsprechenden Informationen an den Abteilungsleiter weitergeben müssen, eskaliert er die
Ablehnung des Angebotes sofort an Hans.
Nachdem Hans die Benachrichtigung bezüglich der Ablehnung erhalten hat, macht er sich
zunächst ein Bild der Kundensituation. Dazu öffnet er innerhalb der Groupwaresoftware
ein komponentenbasiertes Reportingwerkzeug, welches ihm zunächst einen Überblick über
die gesamte Unternehmenslage bezüglich der Aufträge und Angebote liefert. Dort kann er
sehen, welchen Umsatz das Unternehmen im letzten Monat gemacht hat und wie sich dies
im Vergleich zu den Monaten zuvor verhält.
Anschließend ruft er die spezifischen Daten nur für den gemeldeten Kunden auf. Dort
werden ihm mehrere kundenbezogenen Daten, wie Aktivitäten, Projekte und Angebote,
teilweise grafisch dargestellt. Hans stellt anhand der ersten Übersicht fest, dass es sich hier
um einen der größten Kunden des Unternehmens handelt, welcher den Gesamtumsatz
entscheidend beeinflussen kann. Folglich betrachtet er die Daten des abgelehnten
Angebotes. Er bemerkt, dass die Summe des Angebotes den momentanen Umsatz deutlich
steigern würde. Infolgedessen lässt er sich die Details genauer darstellen und kann
S e i t e | 34
erkennen, welche Leistungen und Kosten dem Kunden vorgelegt wurden. Da er nun wissen
möchte, welche Anforderungen das Unternehmen gestellt hat, betrachtet er in der
Übersicht, die Aktivitäten, die seine Mitarbeiter bezüglich des Kunden unternommen
haben. Dort befindet sich ein Eintrag, der sich auf das Telefonat zwischen Peter und dem
Kunden bezüglich der Anforderungen bezieht. Hans ruft die Detailinformationen zu dieser
Aktivität auf und stellt fest, dass Peter im Angebot fälschlicherweise Leistungen berechnet
hat, die der Kunde nicht angefordert hat.
Auf Grundlage dieser Tatsache entscheidet sich Hans dafür, dass sich Peter unverzüglich
mit dem Kunden in Verbindung setzen und das Angebot überarbeiten muss. Um diese
Entscheidung in die Tat umzusetzen, ruft er die integrierte Geschäftsprozessfunktion auf
und erstellt für das weitere Vorgehen einen neuen Prozess, der direkt an Peter zur
Bearbeitung weitergeleitet wird.
3.3 Anforderungen
Nachdem im Anwendungsszenario Zweck und Vorteile aufgezeigt wurden, beschreibt der
folgende Abschnitt die Anforderungen an ein Reportingwerkzeug. Diese orientieren sich
am chronologischen Ablauf einer typischen Nutzung dieses Werkzeuges. Aus diesem
Grund werden die inhaltlichen und technischen Aspekte in den jeweiligen Punkten
zusammengefasst.
Grundsätzlich soll die zu entwickelnde Applikation auf Komponenten basieren, welche
kundenbezogene Daten aus verschiedenen Datenquellen einbeziehen. Aus diesen Quellen
sollen wirtschaftlich relevante Informationen herausgefiltert und intuitiv verständlich
dargestellt werden. Um Einzelheiten zu den jeweiligen Daten zu erfahren, soll der Nutzer
außerdem die Möglichkeit haben, Detailinformationen aufrufen zu können. Nachdem er
eine Entscheidung über die weitere Vorgehensweise getroffen hat, soll der Nutzer diese
direkt in einen Geschäftsprozess einfließen lassen können.
3.3.1 Komponentenbasierte Applikation
Dieses Reportingwerkzeug soll als komponentenbasierte Applikation mit dem Composite-
Application-Framework von IBM Lotus Notes 8 realisiert werden.
Zwar soll die Anordnung und Auswahl der Komponenten in dieser Anwendung festgelegt
sein, der Nutzer aber trotzdem die Möglichkeit haben, die Größe der einzelnen Elemente
im Fenster zu verändern.
S e i t e | 35
Zudem sollen die Komponenten so konzipiert werden, dass sie in anderen Anwendungen
wiederverwendet werden können und für abweichende Einsätze erweiterbar sind.
Um den Einstieg in das System für neue Nutzer zu erleichtern und eine generelle Arbeit
mit der Anwendung zu vereinfachen soll eine einheitliche Oberfläche für die grundlegende
Konsistenz in der Präsentation sorgen. Dies impliziert zwar nicht identische Designs der
einzelnen Komponenten, aber einheitliche Designaspekte müssen befolgt werden.
Da das Werkzeug mit vertraulichen Kundendaten arbeitet, müssen ausreichende
Sicherheitsvorkehrungen getroffen werden, um diese Daten vor unbefugten Personen zu
schützen. So dürfen Nutzer des Systems nur auf Daten zugreifen, für die sie eine
Berechtigung besitzen.
3.3.2 Kundenauswahl
Neben der Möglichkeit, Übersichten über alle Daten anzuzeigen, wie beispielsweise die
gesamten Umsätze des Unternehmens in einem bestimmten Zeitraum, soll dieses
Werkzeug die Funktionalität bieten, die gleichen Daten nur für einen ausgewählten
Kunden anzuzeigen. Somit muss eine Kundenauswahl zur Verfügung stehen, in der alle
Kunden aufgeführt werden. Eingeschränkt wird die Auswahl eventuell durch
Benutzerrechte, welche dem entsprechenden Anwender nur den Zugriff auf die ihm
zugeteilten Kunden erlauben.
3.3.3 Datenquellen einbinden und verknüpfen
Nachdem ein Kunde ausgewählt wurde, sollen in weiteren Bereichen der Anwendung
mehrere Daten zu sehen sein. Dies können Aufträge, Angebote, Projektdaten, Aktivitäten,
zugeordnete Mitarbeiter, Kontaktdaten, E-Mails oder weitere spezifische Informationen
sein.
Da kundenbezogene Daten in heterogenen Quellen verteilt sind, müssen diese in die
Anwendung einbezogen werden. Das bedeutet, dass Daten vom lokalen Rechner, aber auch
Informationen aus dem Netzwerk in die jeweiligen Komponenten eingebunden werden
müssen. Insbesondere externe Datenquellen, welche im firmeneigenen Intranet oder im
Internet vorhanden sind, sollen direkt in die Applikation einfließen.
Um Daten eines ausgewählten Kunden anzuzeigen, müssen die Komponenten verknüpft
werden. Dies soll über konsistente Schnittstellen geschehen. So soll die Information,
welcher Kunde ausgewählt wurde, einheitlich an alle Elemente der Anwendung übergeben
S e i t e | 36
werden. Anschließend sollen die jeweiligen Komponenten nur noch die gefilterten
Informationen zu dem gewählten Kunden ausgeben.
Ebenfalls beachtet werden muss die Antwortzeit. Um eine flüssige Arbeit mit dem System
zu ermöglichen, muss es die angeforderten Daten in einer angemessenen Zeit zur
Verfügung gestellt werden.
3.3.4 Auswahl relevanter Daten eines Kunden
Das zu entwickelnde Werkzeug steht unter der Prämisse der Entscheidungsunterstützung.
Das heißt, dem Nutzer dieser Anwendung soll eine, durch sinnvolles Kombinieren, Filtern,
Aufbereiten und Anzeigen von Daten gewonnene, zweckmäßige Unterstützung zur
Verfügung gestellt werden, um weitere Maßnahmen für einen bestimmten Kunden
einzuleiten. Dazu spielt neben dem Bereitstellen der kundenspezifischen Informationen,
auch die anschließende Auswahl der Daten eine große Rolle.
Dabei ist zu bedenken welche Teile der kundenbezogenen Daten, nach Gesichtspunkten
der Business Intelligence, relevant sind und für die Unterstützung einbezogen werden
müssen. Während es zum Beispiel bei Projekten meist interessant ist, welche Kosten dort
entstanden sind, sind bei Aktivitäten die inhaltlichen Sachverhalte wichtig. Somit muss der
Informationsgehalt aller Kundendaten geprüft werden und deren relevanten Teildaten zur
weiteren Aufbereitung ausgewählt werden.
Weiterhin ist zu entscheiden, welche Daten zu aggregieren und welche aufzubrechen sind.
Dies dient der Übersicht und verbessert das Verständnis der Daten. So soll der Anwender
beispielsweise auf den ersten Blick erkennen können, welche Projekte die höchsten
Gesamtkosten haben.
3.3.5 Darstellung der Daten
Mit dieser Anwendung soll ein Dashboard als Reportingwerkzeug erstellt werden, welches
Informationen nicht in druckoptimierter Form anbietet, sondern eine direkte
Bildschirmnutzung zur Verfügung stellt [vgl. Gluchowski et al., 2008, S. 205ff.].
Dem Nutzer soll eine optimale visuelle Unterstützung gegeben werden, mit der alle
relevanten Daten auf einen Blick ersichtlich sind. Dazu sollen die Kundeninformationen
als vollständige Übersicht auf möglichst einer Seite realisiert werden. Durch die Fülle an
Informationen und den beschränkten Platz auf dem Bildschirm kann es schnell
unübersichtlich werden. Es besteht die Gefahr, dass der Nutzer durch die Flut an
Informationen überfordert wird und die Orientierung verliert. Dies bedingt intuitiv
S e i t e | 37
verständliche und anschauliche Gestaltungsarten, einschließlich der Entscheidung, welche
Informationen grafisch, beispielsweise als Diagramm, textuell, zum Beispiel als Tabelle,
oder als Mischform angezeigt werden sollen.
Generell soll das Layout der einzelnen Komponenten vom System vorgegeben sein, so
dass der Nutzer keine Möglichkeit hat, die Darstellungen der einzelnen Elemente manuell
zu verändern. Allerdings ist eine Auswahl an möglichen Darstellungsformen je
Komponente vorstellbar. So könnte der Nutzer die für sich am besten geeignete
Darstellung aus einer Reihe von Vorschlägen auswählen.
Auch hier ist auf die Antwortzeit und Stabilität zu achten. Durch den Einsatz komplexer
Darstellungen darf das System nicht zu langsam oder instabil werden, sondern muss dem
Anwender weiterhin in annehmbarer Zeit zuverlässig zur Verfügung stehen.
3.3.6 Detailinformationen
Das Zusammenfassen von Informationen dämmt zwar die Datenflut ein und erhöht somit
die Übersicht, doch dem Nutzer bleiben Detailinformationen verborgen. Damit diese auf
Wunsch trotzdem zum Vorschein kommen, soll der Anwender weiterhin die Möglichkeit
haben, Details zu einer bestimmten Information abzurufen.
Hierzu sollen mehrere Wege möglich sein. Zum einen soll es durch eine Drill-Down
Funktion, welche typisch für Dashboards ist, möglich sein, weitere, aufgeschlüsselte
Informationen in derselben Komponente anzuzeigen. So soll beispielsweise mit einem
Klick auf die Darstellung der Gesamtkosten eines Projektes, eine weitere Aufschlüsselung
der Kosten innerhalb des Projektes erscheinen. Dies erfordert eine dynamische Anbindung
der Darstellung, um festzustellen welche Detaildaten angefordert werden. Zudem ist auf
die Navigation zu achten. Der Nutzer muss bei einer detaillierten Sichtweise innerhalb der
Komponente immer die Möglichkeit haben, wieder zurück zur allgemeinen Übersicht der
Komponente zu gelangen.
Um dieses Problem zu umgehen und zusätzlich noch weitere Details anzuzeigen, soll es
zum anderen die Möglichkeit geben, die jeweiligen Dokumente direkt in einem neuen
Fenster geöffnet werden können. Interessiert sich der Anwender zum Beispiel für ein
kundenspezifisches Angebot, so kann er das Angebotsdokument direkt öffnen und sieht die
entsprechenden Informationen.
Als optionale dritte Variante sollen generische Berichte erstellbar sein. Damit sollen
Details von speziellen kundenbezogene Daten in einer neuen Seite als Bericht geöffnet
S e i t e | 38
werden. Das Layout der Berichte wird vom System vorgegeben und dann mit den
entsprechenden Details der ausgewählten Informationen ausgefüllt. Diese Funktion soll die
einheitliche Oberflächendarstellung unterstützen, da das Layout der Berichte konsistent
sein und sich am einheitlichen Design der Applikation orientieren soll. Zudem sollen die
Berichte dem Nutzer, trotz der Konzentration auf eine direkte Bildschirmnutzung, die
Möglichkeit geben, Informationen in einer druckoptimierten Form auszugeben.
Wie schon in den vorangegangenen Anforderungen, ist bei den Detailinformationen
ebenfalls darauf zu achten, dass die Informationen in einer angemessenen Zeit angezeigt
werden.
3.3.7 Geschäftsprozessintegration
Nachdem der Nutzer der Anwendung eine Entscheidung über das weitere kundenbezogene
Vorgehen gefällt hat, soll er die Möglichkeit haben, diese direkt in einen Geschäftsprozess
einfließen zu lassen.
Damit soll es zeitnah möglich sein, passgenaue Maßnahmen für Kunden anzustoßen und
diese den zuständigen Aufgabenträgern direkt zuzuteilen. Dabei kann es sich um einen
bereits laufenden oder einen neuen Geschäftsprozess handeln.
Es ist speziell der Aspekt der zeitnahen und genauen Zuteilung von Aufgaben innerhalb
eines Geschäftsprozesses, der durch dieses Werkzeug sinnvoll unterstützt werden soll.
3.4 Soll-Konzept
Im folgenden Abschnitt wird das Soll-Konzept beschrieben. Mit ihm werden Lösungen zu
den Anforderungen entwickelt und auf ihre Vor- und Nachteile hin untersucht. Die
einzelnen Abschnitte werden anhand einer Abfolge beschrieben, die sich an der
Entwicklung solch eines Reportingwerkzeuges orientiert.
Ausgehend von der Entwicklungsumgebung Lotus Notes, werden danach Beispiele für
kundenbezogene Daten gesucht. Anschließend wird analysiert, welche der herangezogenen
Daten wirtschaftlich relevant sind und wie sich diese textuell und grafisch in die
Applikation einbinden lassen. Zusätzlich werden Varianten für die Anzeige von
Detailinformationen untersucht und eine Geschäftsprozessintegration erläutert.
3.4.1 Entwicklungsumgebung IBM Lotus Notes
Als Basis der weiteren Untersuchungen dieser Arbeit dient die Umgebung von IBM Lotus
Notes, da dies explizit in den Anforderungen genannt wird. Somit können neben dem
Composite-Application-Framework auch andere Bereiche von Lotus Notes genutzt
S e i t e | 39
werden. Das führt dazu, dass neben allgemeinen Lösungsmöglichkeiten zu den
Anforderungen speziell Lösungen von Lotus Notes betrachtet werden, denn diese sind
unter Umständen leichter zu implementieren als externe Lösungsansätze.
IBM Lotus Notes ist neben der Version 8.0.2 mittlerweile als 8.5 erhältlich. Damit stellt
sich die Frage, welche Version in dieser Arbeit verwendet werden soll. Beide bieten die
Technologie des Composite-Application-Frameworks sowie die generellen Eigenschaften
von Lotus Notes an.
Der Unterschied liegt in der Weiterentwicklung der Version 8.5. Diese basiert noch mehr
auf offenen Standards und der Eclipse Architektur und bietet dadurch mehr Möglichkeiten,
eine serviceorientierte Architektur aufzubauen mit der individuelle Anpassungen noch
flexibler durchgeführt werden können als mit der 8.0.2 [vgl. IBM developerWorks, 2008].
Dieser Vorteil zeigt sich besonders in der Entwicklung von Composite Applications. Der
Lotus Domino Designer basiert auf dem Eclipse Framework und mit dem Lotus Expeditor
kann eine vereinfachte Verbindung zur Eclipse Umgebung hergestellt werden. Dadurch
können selbstentwickelte Komponenten leichter in Lotus Notes eingebunden und in einer
Composite Application genutzt werden.
Aus technischer Sicht bietet die Version 8.5 somit deutlich mehr Funktionen und
Möglichkeiten zur Entwicklung als die 8.0.2. Allerdings muss auch das Einsatzszenario
dieses Werkzeuges in Betracht gezogen werden. Viele Unternehmen arbeiten mit älteren
Versionen von Lotus Notes. Es müsste daher zunächst ein Update auf die verwendete
Version durchgeführt werden, um das Werkzeug nutzen zu können. Mit der Version 8.5
wurden grundlegende Neuerungen durchgeführt, wodurch ein Update auf diese Version
schwieriger in der Praxis zu realisieren ist als ein Update auf die 8.0.2 [vgl. IBM
developerWorks, 2008].
Folglich muss entschieden werden, ob für die Umsetzung dieses Werkzeuges die Update-
Fähigkeit oder die Entwicklungsmöglichkeiten wichtiger sind. Da es sich bei dem Ergebnis
dieser Arbeit um einen Prototyp handelt, der den neuesten Stand der Technologien nutzen
soll, kommen Einsätze in der Praxis erst nach weiteren Entwicklungsphasen in Frage. Aus
diesem Grund spielen zusätzliche Möglichkeiten der Individualisierung die wichtigere
Rolle, weshalb die Entscheidung für die Version 8.5 als Basis dieses Werkzeuges fällt.
S e i t e | 40
3.4.2 Kundenbezogene Daten
Nachdem nun entschieden ist, dass die Version IBM Lotus Notes 8.5 als Grundlage dient,
wird im nächsten Schritt geklärt, welche Daten zur weiteren Bearbeitung der Aufgabe
notwendig sind.
Das zu entwickelnde Werkzeug zielt auf die Entscheidungsunterstützung im Rahmen von
Geschäftsprozessen mit Kunden. Deshalb werden Daten benötigt, die mit einzelnen
Kunden zusammenhängen. Das können Aufträge, Angebote, Projekte, Aktivitäten oder
weitere Informationen sein, um die in Kapitel 3.3.3 genannten Anforderungen zu erfüllen.
Diese Daten müssen in mehreren Datenquellen möglichst verteilt gespeichert sein,
beispielsweise lokal auf einem Rechner und im Netzwerk, um die Anforderungen zu
erfüllen.
Ein weiterer Punkt ist die Sicherheit. Weil es sich in der Praxis um vertrauliche Daten und
Dokumente von Kunden handelt, die für Unternehmen existentiell sein können, dürfen
diese keinesfalls an unbefugte Personen gelangen.
Lotus Notes bietet die Möglichkeit, Datenbanken lokal oder im Netzwerk abzulegen und
die gespeicherten Informationen von dort aus aufzurufen. Zudem werden die Daten durch
das integrierte Sicherheitssystem von Lotus Notes, welches neben Passwörtern auch
Zertifikate, ID-Dateien und Verschlüsselungen auf mehreren Ebenen verwendet, geschützt.
Die gestellten Sicherheitsanforderungen werden somit erfüllt, weshalb es sich anbietet,
auch für die kundenbezogenen Daten eine Lösung auf Basis von Lotus Notes Datenbanken
zu finden, denn diese lassen sich relativ einfach einbinden und verwenden.
Als erste triviale Möglichkeit kommt die Erstellung einer Datenbank in Betracht, welche
mit entsprechenden Beispieldaten zu füllen ist. Zusätzlich müssten weitere Funktionen,
Abhängigkeiten und Verknüpfungen konzipiert und erstellt werden. Diese Variante ist
allerdings mit einem enormen Aufwand verbunden, welcher den Rahmen dieser Arbeit
sprengen würde.
Es existieren jedoch auf Basis von Lotus Notes bereits Praxislösungen, so dass auch
bestehende Produkte als Beispiele in Frage kommen. Neben weiteren Anbietern, wie
Genius Inside oder PONTE, bietet die PAVONE AG fertige Softwarelösungen an, welche
die geforderten Daten beinhalten und Beispiele mitliefern (siehe Abb. 15).
S e i t e | 41
Abbildung 15 - PAVONE Produktübersicht (übernommen aus [PAVONE Produktseite, 2009])
Für diese Arbeit werden die Produkte PAVONE Project Management, PAVONE Sales und
PAVONE Espresso Workflow verwendet.
Mit dem PAVONE Project Management können Projekte geplant und gesteuert werden.
Ebenso werden Ressourcen wie Verbrauchsgüter oder Personal eingeplant und verwaltet.
Im Rahmen dieser Arbeit sollen damit für einzelne Kunden Projektdaten vorgelegt werden,
die für eine Entscheidungsunterstützung relevant sind. Das Produkt PAVONE Sales stellt
ein Kundenmanagement zur Verfügung, welches unter anderem Adressen, Aktivitäten und
Vertriebsinformationen über Kunden verwaltet. Diese Daten sollen ebenfalls als Basis zur
Entwicklung des Reportingwerkzeuges dienen. Um am Ende eine Integration von
Geschäftsprozessen zu realisieren, wird PAVONE Espresso Workflow eingesetzt. Mit
diesem Produkt können Prozesse gestaltet, simuliert, analysiert, animiert und natürlich
durchgeführt und gesteuert werden [vgl. PAVONE Produktseite, 2009].
Alle PAVONE Lösungen bauen auf Lotus Notes auf und liefern von sich aus einige
Beispieldaten. Allerdings müssen für die Erstellung des Prototyps, Beispiele in einem
einheitlichen Kontext erzeugt werden, damit sich die volle Wirkung des Werkzeuges
entfalten kann. Deshalb müssen im Vorfeld konsistente kundenbezogene Daten
eingetragen werden. So muss beispielsweise Kunde X in allen Datenbanken vorhanden
S e i t e | 42
sein und es müssen Projekte, Aktivitäten, Vertriebsinformationen und weitere genutzte
Informationen für ihn zusätzlich angelegt werden.
3.4.3 Auswahl der Komponenten mit kundenbezogenen Daten
Nach der Entscheidung, auf welcher Basis die kundenbezogenen Daten aufbauen, muss im
nächsten Schritt ausgewählt werden, welche dieser Daten für eine
Entscheidungsunterstützung in Frage kommen.
Um eine passende Antwort zu finden, müssen im Vorfeld einige technische
Voraussetzungen bedacht werden. Die Implementierung des zu entwickelnde
Reportingwerkzeuges als Dashboard erfordert die Informationen bildschirmoptimiert
möglichst auf einer Seite anzuzeigen. Hinzu kommt die Erstellung als
komponentenbasierte Applikation mit der Problematik, dass die Anzahl an Komponenten
auf einer Seite nicht zu groß sein darf, da andernfalls zu wenig Platz für die einzelne
Komponente zur Verfügung steht. Es besteht zudem die Gefahr, dass ein Übermaß an
Informationen den Nutzer überfordert, wodurch der Sinn des Werkzeuges aufgehoben
würde. Folglich muss geprüft werden, wie viele Komponenten eingesetzt werden können,
um diesem Problem gerecht zu werden.
Ausschlaggebende Kriterien dafür sind die Bildschirmauflösung und die Darstellung
innerhalb der einzelnen Komponenten. Zum Beispiel müssen aus Gründen der
Verständlichkeit und Übersicht einige Informationen als Diagramm dargestellt werden.
Das setzt voraus, dass diese Komponenten eine bestimmte Mindestgröße besitzen, um die
grafischen Elemente erkennbar anzuzeigen. Hinzu kommt das Kriterium der
Bildschirmauflösung. Mit einer hinreichend großen Auflösung lassen sich logischerweise
viele Komponenten einbinden, ohne Platzprobleme zu bekommen. Für die zu entwickelnde
Applikation muss allerdings berücksichtigt werden, dass die meisten Anwender eine
Bildschirmauflösung mit 1024 x 768 oder 1280 x 1024 Pixeln nutzen. Abbildung 16 zeigt
beispielhaft eine komponentenbasierte Applikation in Lotus Notes mit vier Komponenten
und einer Auflösung von 1280 x 1024 Pixeln. Hier wird deutlich, dass eine weitere
Komponente den Platz der bestehenden Elemente so sehr einschränken würde, dass die
Grafiken nicht mehr vollständig und auf einen Blick einzusehen wären. Ähnlich würde
sich eine Verkleinerung der Auflösung auf 1024 x 768 Pixel auswirken. Die bestehenden
Komponenten wären wesentlich enger beieinander und die grafischen Elemente würden
ebenfalls nicht mehr vollständig angezeigt.
S e i t e | 43
Abbildung 16 - Komponentenbasierte Applikation in Lotus Notes (Screenshot des Ergebnisses der Projektgruppe PAV64, GCC Universität Paderborn, 2008)
Das führt zur Entscheidung, für die Nutzung der zu entwickelnden Applikation eine
Bildschirmauflösung von 1280 x 1024 Pixeln vorauszusetzen. Sie liefert ausreichend Platz
zur Gestaltung des Werkzeuges und stellt trotzdem keine zu hohen Anforderungen an die
Bildschirmauflösung der späteren Nutzer. Des Weiteren werden in der Applikation wie im
obigen Beispiel vier Komponenten eingesetzt, um die Übersicht der Informationen zu
gewährleisten. So sind alle Daten auf einen Blick erkennbar, ohne dass der Nutzer mit
Informationen überflutet wird.
Die Auslegung des zu entwickelnden Reportingwerkzeuges auf ein bildschirmoptimiertes
Dashboard mit der zuvor begründeten Beschränkung auf vier Komponenten im
Zusammenhang mit seinem Anforderungsprofil, dass die Anordnung und Auswahl der
Komponenten vom Reportingwerkzeug vorgegeben sein sollen, erfordert zwingend eine
Auswahl, welche der kundenbezogenen Daten in den vier Komponenten verwendet werden
sollen. Sinnvollstes Auswahlkriterium ist deren Entscheidungsrelevanz.
Als zentrale Komponente bietet sich eine Auswahl verfügbarer Kunden an. Diese wird
benötigt, um die weiteren Informationen kundenspezifisch zu filtern und anzuzeigen. Da
S e i t e | 44
die Kunden in allen Datenbanken einheitlich eingegeben werden, reicht es aus, diese
Komponente mit einer Datenquelle zu verbinden. Als Datenquelle wird hier die Datenbank
der PAVONE Sales Anwendung (Sales DB) verwendet, welche durch ihr standardmäßiges
Kundenmanagement prädestiniert für diesen Einsatz ist.
Für die Belegung der weiteren Komponenten müssen die zur Verfügung stehenden Inhalte
der Datenbanken analysiert werden. Die Sales DB bietet neben dem Kundenstamm noch
weitere Informationen, wie Akquisitionsdaten, welche Marketingmaßnahmen für einzelne
Kunden beinhalten. Zudem werden kundenspezifische Angebote sowie Aktivitäten
gespeichert. Allein die Sales DB bietet somit eine Vielzahl an Informationen, die alle drei
verbleibenden Komponenten mit Daten füllen könnten. Aber auch die Datenbank des
PAVONE Project Management (Project DB) liefert wirtschaftlich interessante Daten.
Insbesondere werden hier Projektdaten gespeichert, welche unter anderem die
Projektaktivitäten der Mitarbeiter, komplette Projektstrukturen, -aufwände und -kosten
beinhalten. Das Produkt PAVONE Espresso Workflow wird nicht als eigenständige
Lösung eingesetzt, sondern vielmehr als zusätzliche Funktion, global zur Verfügung
gestellt. Weitere Details zur Integration des Produktes finden sich in Kapitel 3.4.10.
Nachdem die Sales DB und die Project DB untersucht wurden, stehen genügend Daten zur
Auswahl, welche für eine Entscheidungsunterstützung im Rahmen eines kundenbezogenen
Geschäftsprozesses in Frage kommen. Aus wirtschaftlicher Sicht bieten im Kontext der
Business Intelligence allerdings finanzielle Angaben und weiche Informationen zu
Kunden, wie Aktivitäten, den größten Nutzen. So kann direkt erkannt werden, auf
welchem finanziellen Niveau eine Kundenbeziehung steht und welche Maßnahmen zuletzt
für den Kunden durchgeführt wurden. Anhand dieser Einschätzung bilden die Angebote
und Aktivitäten der Sales DB, sowie die finanziellen Projektdaten der Project DB die
aussagekräftigsten Daten, welche jeweils in eine der verbliebenen Komponenten
eingebunden werden.
Um die Anforderung zu verteilten Datenquellen zu erfüllen, bietet Lotus Notes die
Möglichkeit, Datenbanken lokal und / oder im Netzwerk abzulegen und zu nutzen. Diese
Eigenschaft findet hier beispielhaft in Form der Sales DB Verwendung. Die Datenbank
wird lokal und im Netzwerk abgelegt. Durch die Replizierfähigkeit von Lotus Notes
bleiben die Daten in den beiden Varianten identisch, weshalb beide Datenbanken in die
Applikation eingebunden werden können. In diesem Fall werden die kundenbezogenen
Angebote, sowie der Kundenstamm direkt aus der lokalen Sales DB integriert. Die
Aktivitäten je Kunde werden aus der Datenbank bezogen, welche sich im Netzwerk
S e i t e | 45
befindet. Dies erfolgt jedoch nicht durch einen einfachen Datenbankaufruf, sondern per
Webservice, der die angeforderten Aktivitäten der Komponente zur Verfügung stellt.
Abbildung 17 - Skizze der Komponentenanordnung
Abbildung 17 zeigt eine erste Skizze der Applikation inklusive der Anordnung und
Auswahl der Komponenten, sowie die spezifischen Datenquellen.
3.4.4 Spezifikationen der einzelnen Komponenten
Um dem Nutzer eine optimale Entscheidungsunterstützung zu bieten, werden im nächsten
Schritt weitere Aspekte der Business Intelligence herangezogen, um genau festzulegen,
welche Daten der einzelnen Komponenten Verwendung finden und wie diese dargestellt
werden.
Komponente der Kundenauswahl
In der ersten Komponente sollen alle verfügbaren Kunden zur Auswahl angeboten werden.
Die Darstellung wird als textuelle Liste realisiert, denn diese gibt die benötigten
Informationen einfach und intuitiv verständlich wieder. Als Kunden zählen in diesem Fall
alle Organisationen, Unternehmen und Ansprechpartner die in der Datenbank gepflegt
sind. Eine unstrukturierte Auflistung aller Kundenkontakte trägt nur minimal zur Übersicht
bei. Deshalb werden alle Kontakte auf Unternehmensebene aggregiert. Somit stehen auf
der obersten Ebene nur die einzelnen Unternehmen zur Auswahl. Diese Einträge sollen,
analog zur Ordnerstruktur unter Windows, weiter aufklappbar sein, um zugehörige
S e i t e | 46
Kontaktdaten, wie Standorte, Adressen und Ansprechpartner, sichtbar zu machen.
Abbildung 18 liefert eine beispielhafte Skizze der Komponente.
Abbildung 18 - Skizze der Kundenauswahl
Komponente der Aktivitäten
Ebenfalls textuell soll die Komponente der kundenbezogenen Aktivitäten dargestellt
werden. Da sich Aktivitäten zum größten Teil aus unstrukturierten Daten zusammensetzen,
bestehen die wirtschaftlich aussagekräftigsten Informationen aus textuellen Inhalten.
Folglich müssen die wichtigsten Bestandteile extrahiert und strukturiert dargestellt werden.
Hierzu stellt eine textbasierte Liste eine leicht verständliche Lösung dar. Die jeweiligen
Einträge enthalten die wichtigsten Informationen der Aktivitäten, welche aus dem Titel,
einer kurzen Beschreibung, sowie einem Datum und der verantwortlichen Person bestehen.
Um dem Nutzer eine zusätzliche Unterstützung zu geben, werden die entsprechenden
Aktivitäten je Kunde chronologisch aufgelistet. Dementsprechend befindet sich die zuletzt
getätigte Aktion an erster Stelle der Liste. Somit ist auf den ersten Blick zu erkennen,
welcher Mitarbeiter sich zuletzt mit dem Kunden beschäftigt hat und was als letztes für den
betreffenden Kunden durchgeführt wurde. Ein Beispiel der Komponente ist in Abbildung
19 zu sehen. Weitere technische Details zur textuellen Darstellung werden im Unterkapitel
3.4.5 behandelt.
Aktivitäten
14.01.09 Angebot erstellt M. Mustermann
Angebot wie telefonisch besprochen erstellt.
12.01.09 Telefonat M. Mustermann
Telefonat mit H. Mayer bezüglich Angebotsnachfrage
nach erfolgreichem Meeting
06.01.09 Meeting A. Müller
Meeting bei Firma DEF zur Produktvorstellung
… … ... … ...
Abbildung 19 - Skizze der Aktivitäten
S e i t e | 47
Komponente der Angebote
Nachdem die textuellen Elemente beschrieben wurden, folgen nun die grafischen
Komponenten. Zunächst werden die Daten der Angebote näher betrachtet. Aus Sicht der
Business Intelligence handelt es sich hier nicht um weiche, größtenteils unstrukturierte
Daten wie etwa Aktivitäten, sondern um semistrukturierte und strukturierte Informationen.
Dadurch lassen sich die verfügbaren Daten einfacher analysieren und zur
Entscheidungsunterstützung einsetzen. Als wirtschaftlich relevante Daten stehen
insbesondere die Umsätze der Angebote im Mittelpunkt. Diese Informationen basieren auf
dem Faktor Geld. Infolgedessen lassen sich verschiedene Angebote leicht miteinander
vergleichen und bewerten. So kann der Anwender anhand der finanziellen Angaben zum
einen sehen, wie wichtig der Kunde für das eigene Unternehmen ist, und zum anderen,
welche Angebote im Bezug auf diesen Kunden finanziell am interessantesten sind.
Für die Darstellung stellt dies eine andere Situation dar als bei den bisher behandelten
Komponenten. Weil hier Informationen im Vergleich dargestellt werden müssen und dies
möglichst auf einer einheitlichen Skala, kommen einfache Listendarstellungen an ihre
Grenzen. Die reinen Daten können textuell zwar angezeigt und miteinander verglichen
werden, jedoch sind bestimmte Sachverhalte nicht sofort einsehbar. Grafische Elemente
bieten für solche Fälle prägnantere Darstellungen, denn sie veranschaulichen dem Nutzer
bestimmte Gegebenheiten. Aus diesem Grund werden die Angebote in einem Diagramm
dargestellt.
Wie bereits im Szenario erwähnt, soll dem Anwender zunächst eine Übersicht der
Gesamtumsätze des Unternehmens ohne Kundenbezug auf Basis der Angebote zur
Verfügung gestellt werden. Es werden darum die gesamten Umsätze des aktuellen Monats,
sowie der letzten Monate, im Diagramm dargestellt. Dazu wird jedem Monat eine Säule
zugeteilt, deren Höhe den Umsatz wiedergibt. Durch diese Darstellung kann der Nutzer die
aktuelle Situation des Unternehmens, sowie die Veränderungen gegenüber den
Vormonaten beurteilen.
Um neben der Gesamtübersicht auch die kundenbezogenen Angebote in der Komponente
darzustellen, muss die jeweilige Ansicht auswählbar sein. Dies wird über einen Button
oder eine Reiterfunktion realisiert. Die Darstellung der kundenbezogenen Angebote wird
ebenfalls durch Säulen übernommen. Dabei steht jede Säule für ein Angebot und die Höhe
der Säule für den jeweiligen Umsatz. Zu ihrer eindeutigen Identifizierung, wird das Datum
S e i t e | 48
des Angebotes jeder Säule als Bezeichnung zugeteilt. Somit erhält der Anwender eine
grafische Übersicht über alle Angebote des Kunden mit Datums- und Umsatzangaben.
Da aber nicht nur die gesamten Umsätze eines Angebotes, sondern auch die einzelnen
Bestandteile zur Entscheidungsunterstützung des Nutzers wichtig sind, müssen diese
ebenso zur Verfügung gestellt werden. Dies soll mit einer Drill-Down Funktion umgesetzt
werden. Mit einem Klick auf ein Angebot des Kunden, werden in derselben Komponente
die einzelnen finanziellen Positionen des Angebotes abgebildet. Für diese Darstellung wird
ein Kreisdiagramm genutzt, denn dieses zeigt die Anteile des Umsatzes intuitiv
verständlich an. Abbildung 20 stellt eine Skizze der Komponente in der Kundenübersicht
dar. Die Details zur Umsetzung einer grafischen Komponente inklusive einer Drill-Down
Funktion werden in Kapitel 3.4.6 näher erläutert.
Abbildung 20 - Skizze der Angebote
Komponente der Projekte
Die vierte Komponente beinhaltet die Projektinformationen. Auch diese Daten können
aufgrund ihrer Semistrukturiertheit leicht miteinander verglichen und beurteilt werden. In
diesem Fall gelten die einzelnen Projektkosten als wirtschaftlich relevante Daten, welche
dem Nutzer zur Entscheidungsunterstützung dienen sollen. Folglich wird eine Darstellung
als Diagramm analog zur Komponente der Angebote realisiert.
Auch hier sollen in einer Ansicht die Gesamtkosten aller Projekte des Unternehmens
aufgezeigt werden. In dieser Darstellung werden die Kosten jedoch nicht je Monat
angezeigt, da sich diese schwer einem Monat zuordnen lassen. Zudem werden die Kosten
eines Projektes in Basis-, Soll- und Ist-Kosten ausgedrückt, welche allesamt abgebildet
werden müssen. Aufgrund dieser Tatsachen wird je eine Säule pro Kostenarten dargestellt,
die in der Höhe, die zum Zeitpunkt der Abfrage bestehenden Kosten anzeigt.
Ebenso wie in der Komponente der Angebote werden hier Buttons oder Reiterfunktionen
zum Umschalten in die kundenbezogene Ansicht genutzt. Für die Projekte eines
S e i t e | 49
ausgewählten Kunden gelten ebenso die Basis-, Soll- und Ist-Kosten als aussagekräftigste
Informationen. Diese drei Eigenschaften werden in der Übersicht für jedes Projekt
ebenfalls als Säulen abgebildet. Folglich bestehen alle visualisierten Projekte aus drei
gruppierten Säulen, welche zur Identifikation die Bezeichnung des Projektes tragen. Um
weitere Kostendetails eines Projektes zu erhalten, wird auch in dieser Komponente eine
Drill-Down Funktion eingesetzt. So werden die entsprechenden Projektphasen inklusive
der jeweiligen Kosten in derselben Ansicht angezeigt. Die Darstellungsart als Diagramm
bleibt in dieser Komponente auch für die Detailinformationen bestehen. In Abbildung 21
ist eine Skizze der grafischen Darstellung in der Gesamtübersicht zu sehen. Wie bereits
erwähnt, werden weitere Details der grafischen Einbindung in Kapitel 3.4.6 behandelt.
Abbildung 21 - Skizze der Projekte
Abbildung 22 - Skizze der Komponentenanordnung mit Daten und Darstellung
S e i t e | 50
Nachdem alle vier Komponenten spezifiziert wurden, zeigt Abbildung 22 eine Skizze der
gesamten komponentenbasierten Applikation. In den folgenden Kapiteln werden nun die
textuellen und grafischen Darstellungen näher erläutert.
3.4.5 Textuelle Darstellung der Komponenten
Im vorigen Abschnitt wurde eine textuelle Liste als Darstellungsart für die Komponenten
der Kunden und Aktivitäten bereits festgelegt. Ebenso wurden die jeweiligen Inhalte
beschrieben. In diesem Kapitel werden nun die technischen Details für die Umsetzung
einer Liste geklärt.
Neben externen Lösungsmöglichkeiten, wie beispielsweise einer JList in Java, bietet Lotus
Notes selber Listendarstellungen, die sogenannten Views, an. Diese werden unter anderem
auch in den Beispielprodukten der PAVONE AG genutzt. Abbildung 23 zeigt den
Ausschnitt einer View der Project DB, welche die Projektvorgänge, nach Projekt und
Mitarbeiter sortiert, darstellt.
Abbildung 23 - Ausschnitt einer View in der Project DB
Da eine View als eine Standardansicht fest in Lotus Notes integriert ist, kann sie ohne
großartige Aufwände Informationen aus einer Datenbank darstellen. Im Gegensatz dazu
müssten bei externen Lösungsansätzen zunächst Schnittstellen definiert werden und die
jeweiligen Listen anschließend in die zu erstellende Applikation eingebunden werden.
Dieses Einbinden ist bei der Variante der View ebenfalls kein Problem, kann sie doch als
Notes Komponente leicht in die Applikation eingebunden werden. Neben diesen beiden
Vorteilen kommt hinzu, dass die verwendeten PAVONE Lösungen ihre Daten bereits mit
S e i t e | 51
Hilfe von Views darstellen. Infolgedessen können für die Komponenten der Kunden und
Aktivitäten bereits vorhandene Views modifiziert und in die zu entwickelnde Applikation
eingesetzt werden.
Problematisch wird die Nutzung einer Notes View allerdings, wenn die in den
Anforderungen erwähnte Wiederverwendbarkeit (siehe Kapitel 3.3.1) in anderen
Anwendungen in Betracht gezogen wird. Es handelt sich hier um eine Ansicht in Lotus
Notes. Daher kann diese zwar in anderen Notes Applikationen, aber nicht in anderen
Anwendungen außerhalb des Programms eingesetzt werden. In diesem Fall ist eine
plattformunabhängige Lösung mit Java besser geeignet. Dort müssten zwar neue
Schnittstellen definiert werden, die Funktionen innerhalb der Darstellung würden aber
beibehalten. Da der Prototyp dieser Arbeit explizit auf Basis von Lotus Notes erstellt
werden soll, reicht jedoch die Wiederverwendbarkeit innerhalb von Lotus Notes aus, um
diese Anforderung zu erfüllen. Deshalb werden die Komponenten der Kunden und
Aktivitäten jeweils als Notes View dargestellt. Außer den genannten Vorteilen ermöglicht
sie darüber hinaus eine einheitliche Oberflächendarstellung und erleichtert einem
Anwender den Einstieg in das System.
Zusätzlich können in Views sogenannte Actions eingebunden werden, die sich
beispielsweise als Buttons darstellen lassen und eine gewählte Aktion ausführen. In
Abbildung 23 sind diese am oberen Bildrand als Buttons zu erkennen. Diese Funktion kann
beispielsweise für die Umsetzung der Detailinformationen oder
Geschäftsprozessintegration genutzt werden. Weitere Einzelheiten dazu werden in den
jeweiligen Kapiteln behandelt. Eine weitere positive Eigenschaft der View ist ihre kurze
Antwortzeit. Die Integration dieser Darstellungsart in Lotus Notes ermöglicht ihr innerhalb
kürzester Zeit Informationen aus einer Datenbank darzustellen. Damit erfüllt sie eine
weitere der gestellten Anforderungen.
Nachdem die Vor- und Nachteile von Views abgewogen wurden und die Entscheidung für
eine View gefallen ist, müssen weitere technische Spezifikationen der jeweiligen
Komponenten geklärt werden. Wie in Kapitel 3.4.3 angesprochen, ist das Platzangebot für
die einzelnen Komponenten begrenzt. Eine kleine Darstellung greift schnell auf zwei
Scrollbalken zurück. Aus Übersichtsgründen wird an dieser Stelle die Darstellung auf
einen Scrollbalken beschränkt. Ausschlaggebende Faktoren dafür sind zum einen die
Anzahl der Einträge in der Liste, welche den vertikalen Scrollbalken beeinflussen, und
zum anderen die Anzahl und Breite der Informationen zu den jeweiligen Einträgen, welche
S e i t e | 52
den horizontalen Balken betreffen. Da sich die Anzahl an Einträgen der Liste anhand der
Anzahl an Kunden und Aktivitäten dynamisch verhält, müssen somit die Informationen je
Eintrag besonders beachtet werden.
Im Fall der Kundenauswahl stellt dies ein weniger großes Problem dar, weil neben dem
Kundennamen nur die Adresse angezeigt werden soll. Dies kann bei sehr langen
Anschriften zwar ebenfalls problematisch werden, beschreibt allerdings eher die
Ausnahme als den Regelfall. Mehrere Einschränkungen müssen hingegen bei den
kundenbezogenen Aktivitäten getroffen werden. Da dort der Titel, eine kurze
Beschreibung, das Datum und die verantwortliche Person der Aktivität angezeigt werden
sollen, werden diese so angeordnet, dass der Nutzer auf den ersten Blick alle
Informationen erhält, ohne horizontal zu scrollen. Der Anwender kann so die wichtigsten
Daten der einzelnen Aktivität erkennen und bei Bedarf Detailinformationen aufrufen.
Zusammenfassend kann zur textuellen Darstellung der Komponenten gesagt werden, dass
die Kundenauswahl alle Kunden aus der Sales DB in eine Notes View einbindet, in der die
Kundennamen, sowie die entsprechenden Adressen dargestellt werden. Die Komponente
der kundenbezogenen Aktivitäten wird ebenfalls in einer View dargestellt, wobei die
Informationen per Webservice aus der Sales DB bezogen werden, welche sich im
Netzwerk befindet. Hier werden die Titel, Beschreibungen, Daten und verantwortlichen
Personen der einzelnen Aktivitäten bereitgestellt, wobei die Darstellungsbreite, der Größe
der Komponente angepasst wird.
3.4.6 Grafische Darstellung der Komponenten
Die im folgenden Abschnitt beschriebenen grafischen Darstellungen der Angebote und
Projekte, stellen einen elementaren Punkt der Entscheidungsunterstützung dar. Grafische
Aufbereitungen machen einen Großteil von Reportings aus, denn sie dienen dazu, dem
Nutzer Sachverhalte intuitiv verständlich zu machen.
Lotus Notes besitzt keine grafischen Darstellungsmöglichkeiten, wie etwa Microsoft
Excel. Dies zwingt dazu, externe Lösungen zu suchen und zu analysieren. Dabei müssen
die möglichen Varianten kostengünstig und flexibel einsetzbar sein. Als naheliegende
Lösung bietet sich ein Plugin an, welches auf Basis der Eclipse Architektur implementiert
wird, denn Lotus Notes 8.5 baut ebenfalls auf dieser Architektur auf.
Sucht man anhand der vorgegebenen Kriterien nach vorhandenen Lösungsmöglichkeiten,
gelangen immer wieder drei Produkte in den Fokus: BIRT, JasperReports sowie Pentaho
Reporting. Alle Varianten stehen als Open Source zur Verfügung und können somit
S e i t e | 53
kostenlos in Eclipse genutzt werden. Ein Vergleich muss folglich zeigen welches der
Produkte für die grafische Komponente am geeignetsten ist.
BIRT steht für Business Intelligence and Reporting Tools und wird von der Eclipse
Foundation als Open Source System auf Eclipse Basis angeboten. Dabei handelt es sich um
ein Reporting System mit besonderer Eignung für Java und J2EE Applikationen. Das
System besteht aus einem Report Designer in Eclipse, mit dem sich eigene Berichte
erstellen lassen, einer Runtime Komponente und einer Charting Engine, mit der sich
erstellte Reports in eigene Applikationen einbinden lassen. Neben einfachen Listen können
mit BIRT verschiedene Arten von Diagrammen und Berichten erstellt werden, welche
unter anderem in den Formaten HTML, PDF, XLS, DOC, PPT, XML und SVG
ausgegeben werden. Dabei dienen verschiedene Datenbanken, Webservices, XML-
Dateien, Java Objekte und weitere Elemente als Datenquelle [vgl. BIRT Overview, 2009;
Doumack, 2008, S. 45ff.; Mimouh/Heidingsfelder, 2008; Pientka, 2008].
JasperReports ist ebenfalls ein Open Source Produkt, welches von der Firma JasperSoft auf
Basis einer Java Bibliothek zur Verfügung gestellt wird. Auch diese Reporting Anwendung
bietet eine Vielzahl an Layoutmöglichkeiten, Ausgabeformaten und Datenquellen. Berichte
können mit der Java Anwendung iReport erstellt werden, welche speziell als grafischer
Designer für JasperReports dient. Ein Einbinden in eigene Applikationen ist mit der Jasper
Report Engine möglich [vgl. JapserReports Datasheet, 2009; Doumack, 2008, S. 41ff.;
Mimouh/Heidingsfelder, 2008; Pientka, 2008].
Das dritte Werkzeug namens Pentaho Reporting wird von der Pentaho Corporation bereit
gestellt. Dieses Open Source Produkt basiert auf dem Reporting Projekt JFreeReports,
welches von Seiten Pentahos erweitert wurde. Die Erstellung von Berichten wird vom
Pentaho Report Designer übernommen, welcher zudem als Wizard zur Verfügung steht.
Auch hier steht eine Reporting Engine zur Einbindung in eigene Anwendungen zur
Verfügung. Die Arten des Layouts, der Datenquellen und Ausgabeformate orientiert sich
ebenfalls an der Vielfalt der beiden bereits vorgestellten Konkurrenzprodukte [vgl. Pentaho
Reporting Datasheet, 2009; Doumack, 2008, S. 38ff.; Mimouh/Heidingsfelder, 2008;
Pientka, 2008].
Neben diesen Reportingwerkzeugen bieten JasperSoft und Pentaho ganze Business
Intelligence Suiten an, welche neben den bereits erwähnten Anwendungen, weitere
Systeme zur Analyse und Bewertung beinhalten.
S e i t e | 54
Aufgrund des steigenden Interesses an Open Source Lösungen im Sektor der Business
Intelligence und insbesondere des Reportings, lassen sich mehrere Vergleichsberichte der
drei Produkte finden. Mimouh und Heidingsfelder, sowie Pientka befassen sich in ihren
Berichten intensiv mit den Eigenschaften der Systeme. Ebenso erwähnenswert ist der
Vergleich von Doumack, der in seiner Arbeit eine Benchmarkanalyse der drei Varianten
durchführt. Die folgende Tabelle zeigt eine Übersicht der Eigenschaften der einzelnen
Produkte.
BIRT JasperReports Pentaho Reporting
Ausgabeformate PDF HTML XLS (Excel) TXT PPT DOC (Word) RTF (Word) ODT (OpenOffice) XML CSV SVG Datenquellen JDBC POJO/Java Beans CSV XML Webservices XMLA,MDX Metadatenunterstützung Verschiedene Datenquellen innerhalb eines Reports
Diagramme Einbindung von Charts Einbindung dynamischer Inhalte (Bilder, Texte)
Reporting Drill-Down Analyse Internationalisierung (Zeichensatz, Währung)
Unterstützt Sub-Reports (Verschachtelung)
Aggregationen und Gruppierung Pixelgenaue Report-Erstellung Parametrisierte Reports
Tabelle 3 - Vergleich von BIRT, JasperReports und Pentaho Reporting
(modifiziert übernommen aus [Doumack, 2008, S. 63ff.; Mimouh/Heidingsfelder, 2008])
S e i t e | 55
Wie sich erkennen lässt, bieten alle Lösungen eine Vielzahl an Ausgabeformaten und
Datenquellen an, wobei sich einzelne Unterschiede bemerkbar machen. So bieten BIRT
und JasperReports deutlich mehr Ausgabemöglichkeiten an als das Pentaho Reporting.
Alle Systeme unterstützen die gängigsten Datenquellen. Allerdings stellt die fehlende
Einbindung von Webservices bei JasperReports einen Schwachpunkt dar. Die zur
Verfügung stehenden Diagramme werden hier nicht näher erläutert. Sie sind in allen
Produkten nahezu identisch und erfüllen die Anforderungen dieser Arbeit. Im Bereich
Reporting fällt auf, dass das Pentaho Reporting keine Drill-Down Analyse anbietet. Diese
Funktion ist jedoch zur Realisierung der zu entwickelnden Applikation notwendig,
weshalb das Pentaho Reporting vorzeitig ausscheidet und in der weiteren Lösungsfindung
nicht mehr beachtet wird.
Die Produkte BIRT und JasperReports besitzen beinahe identische Eigenschaften. Es
werden also zusätzliche Punkte analysiert, um letztendlich eine Entscheidung treffen zu
können. Beide Lösungen lassen sich in Eclipse bearbeiten und relativ einfach als Plugin in
eigene Anwendungen einbinden [vgl. Mimouh/Heidingsfelder, 2008; Pientka, 2008].
Doumack sowie Pientka machen in ihren Berichten allerdings deutlich, dass BIRT im
Bereich der Dokumentation erhebliche Vorteile besitzt, aufgrund der ausführlichen Hilfe,
sowie weiteren Elementen wie Tutorials. Im Gegensatz dazu müssen bei JasperReports der
Support sowie Handbücher finanziell erworben werden [vgl. Doumack, 2008, S. 77ff.;
Pientka, 2008]. Ein weiterer wichtiger Unterschied besteht in der Bedienbarkeit des
jeweiligen Report Designers. Dort punktet ebenfalls BIRT durch deutlichere
Rückmeldungen an den Nutzer, wie zum Beispiel die Vorschau auf angefertigte
Diagramme oder auch nur die reinen Inputdaten, zur Kontrolle ob diese auch geladen
werden [vgl. Doumack, 2008, S. 74ff.; Pientka, 2008]. Beim eigentlichen Erstellen der
Berichte macht zunächst JasperReports mit dem Angebot eines Wizards Boden gut, kann
jedoch mit der übersichtlicheren Benutzeroberfläche von BIRT nicht mithalten [vgl.
Doumack, 2008, S. 74ff.]. Im Bereich der Leistungsfähigkeit wurden die Rechenzeit sowie
die Speicherauslastung der einzelnen Produkte von Doumack getestet. Nach mehreren
Durchgängen zeigte sich, dass BIRT im Durchschnitt die geringste Antwortzeit, aber die
größte Speicherauslastung hat. Da sich die Auslastung für normale Desktopanwendungen
allerdings in Grenzen hält, überwiegt die schnelle Reaktionszeit als positiver Effekt [vgl.
Doumack, 2008, S. 79ff.].
Letztendlich fällt die Entscheidung zugunsten von BIRT, aufgrund der Vorteile in der
Bedienbarkeit, sowie Dokumentation und weil es bereits auf einer Eclipse Architektur
S e i t e | 56
basiert, welche ebenfalls als Grundlage für Lotus Notes dient. Das Produkt hat zwar eine
größere Speicherauslastung, aber es zeigt die darzustellenden Berichte schneller an als die
Konkurrenz. Aufgrund der geringen Unterschiede ist allerdings festzuhalten, dass je nach
Einsatzzweck, auch JasperReports eine durchaus gelungene Lösungsalternative darstellt.
Eingesetzt wird BIRT in der aktuellsten Version 2.3.1, welche von der Eclipse Webseite
(http://www.eclipse.org/birt/phoenix/) oder per Software Update direkt in Eclipse bezogen
werden kann. Anschließend können die komponentenabhängigen Berichte mit dem Report
Designer erstellt werden (siehe Abb. 24).
Abbildung 24 - BIRT Report Designer in Eclipse
Für die generelle Erstellung der Reports gilt insbesondere die Anforderung eine
konsistente Oberfläche zu realisieren, weshalb einheitliche Designs gewählt werden und in
allen Reports zum Einsatz kommen. Zudem müssen die Darstellungen größenmäßig an den
zur Verfügung stehenden Platz in der Komponente angepasst werden.
Im Bereich der Angebote werden Reports für die Gesamtübersicht der Umsätze des
Unternehmens und für die kundenbezogene Sicht erstellt. Wie bereits in Kapitel 3.4.4
erwähnt, werden in diesen Berichten Diagramme verwendet, die die jeweiligen Umsätze
S e i t e | 57
bzw. Angebote als Säulen darstellen. In der Gesamtübersicht werden die Daten je Monat
wiedergegeben, in der kundenbezogenen Sicht werden die spezifischen Angebote einzeln
mit Datum dargestellt. Die Drill-Down Funktion der kundenbezogenen Daten soll ebenso
per BIRT implementiert werden. Dazu wird eine interaktive Funktion genutzt, die bei
einem Klick auf ein entsprechendes Angebot den Drill-Down zu den weiteren Details
durchführt. Die Darstellung der Angebotsdetails wird allerdings nicht in einem Säulen-
sondern in einem Kuchendiagramm realisiert, um die anteilsmäßigen Umsätze eines
Angebotes zu verdeutlichen. Ein einfacher Klick auf die Detaildarstellung soll
anschließend genügen, um wieder zurück zur ursprünglichen Ansicht zurückzukehren. Zur
Umsetzung einer Umschaltung zwischen den Gesamt- und Kundenübersichten werden
jeweils einzelne Reports der Ansichten benötigt, denn der Composite Application Editor
bietet die Möglichkeit, mehrere Berichte in einer Komponente darzustellen und eine
Auswahl per Reiter zu treffen. So kann zwischen den jeweiligen Ansichten hin- und her-
geschaltet werden.
Für die Darstellung der Projekte erfolgt die Implementierung in BIRT ähnlich. Auch hier
sollen einzelne Reports für die Gesamtübersicht der Projektkosten, sowie der
kundenbezogenen Projekte erstellt werden, um die Reiterfunktion der Composite
Application zu nutzen. Die Daten werden ebenfalls in einem Diagramm dargestellt, wobei
die Basis-, Soll- und Ist-Kosten der Gesamtübersicht oder eines Projektes jeweils als
einzelne Säulen dargestellt werden. Im Gegensatz zu den Angeboten wird auch in der
Drill-Down Funktion ein Säulendiagramm verwendet, um die phasenweisen Kosten je
Projekt in Basis- Soll- und Ist-Kosten zu unterteilen.
Da es sich bei BIRT nicht um eine Notes Komponente, wie etwa der View handelt, kann
nicht einfach auf die Notes Datenbanken zugegriffen werden. Es müssen deshalb
Schnittstellen geschaffen werden, die es ermöglichen, Daten aus Lotus Notes für die
Reports zur Verfügung zu stellen. Dafür bietet BIRT mehrere Varianten an, die bereits in
der Vorstellung genannt wurden. In diesem Fall sollen die Informationen allerdings nicht
direkt aus einer Datenbank entnommen werden, sondern über die Verknüpfung der
Komponenten innerhalb der Composite Application übergeben werden. Weitere
Informationen dazu finden sich im nächsten Kapitel, welches sich explizit mit den
Schnittstellen der einzelnen Komponenten auseinandersetzt.
Nachdem die Reports erstellt und die Schnittstellen implementiert wurden, wird das
gesamte Paket als Plugin bereit gestellt. Dies hat den Vorteil, dass die Komponente nicht
S e i t e | 58
nur explizit in Lotus Notes eingesetzt werden kann, sondern, bei einer Anpassung der
Schnittstellen, in weiteren Programmen wiederverwendbar ist. Um die Funktionen jedoch
in einer Anwendung zu nutzen, müssen die benötigten BIRT Plugins, wie beispielsweise
die BIRT Engine, ebenso eingebunden werden. Dies geschieht in einem Feature. Dort
werden die notwendigen Plugins sowie das selbst entwickelte Plugin hinterlegt.
Anschließend wird dieses Feature in eine Eclipse Update Site eingebettet, um es externen
Applikationen zu ermöglichen, die Plugins zu installieren. Lotus Notes unterstützt die
Einbindung solch einer externen Site bereits, bietet aber auch die Möglichkeit, diese in
eine Notes Update Site abzulegen. So können externe Plugins, Features und Update Sites
in einer Notes Datenbank eingebettet werden und stehen innerhalb des Systems einfacher
zur Verfügung. Folglich wird auch die entwickelte Eclipse Update Site in eine Notes
Update Site eingebunden.
3.4.7 Schnittstellen der Komponenten
Zur Verknüpfung der verschiedenen Komponenten der Composite Application sind
zusätzliche Schnittstellen notwendig. Um diese möglichst konsistent zu halten, wird eine
WSDL-Datei verwendet. Diese beinhaltet die Properties und Actions von Komponenten,
mit denen Daten veröffentlicht und nachgefragt werden können.
Abbildung 25 - Properties der Kundenauswahl
S e i t e | 59
Da die Inhalte der Komponenten von der Kundenauswahl abhängig sind, werden in diesem
Fall mehrere Properties benötigt, welche von der Kundenauswahl veröffentlicht werden
(siehe Abb. 25).
Die zu versendenden Informationen bestehen aus dem Namen des ausgewählten Kunden,
den gesamten Projektkosten des Unternehmens, den kundenbezogenen Projektkosten
inklusive deren Details, den gesamten Umsätzen bzw. Angeboten des Unternehmens und
den kundenbezogenen Umsätzen bzw. Angeboten inklusive deren Details. Um diese Daten
für die entsprechenden Komponenten auch verfügbar zu machen, werden ebenso viele
Actions angelegt, welche die veröffentlichten Informationen abfragen. Die somit erzeugte
WSDL-Datei muss allen Komponenten zur Verfügung stehen. Im Fall der textuellen
Komponenten wird diese Datei in der jeweiligen Notes Datenbank hinterlegt, während sie
für die BIRT Elemente in das Plugin eingefügt wird.
Folglich können die einzelnen Komponenten miteinander verbunden werden. Zur Nutzung
der Schnittstellen sind jedoch weitere Maßnahmen notwendig. Da die Kundenauswahl alle
Properties veröffentlichen soll, wird in dieser Komponente eine Action implementiert.
Diese soll bei ihrer Ausführung die entsprechenden Werte ermitteln und per Property
versenden. Um die Informationen zu verwenden, müssen in den verbleibenden
Komponenten ebenfalls Funktionen eingesetzt werden. In der Komponente der Aktivitäten
muss eine Methode realisiert werden, die die angezeigten Daten für den ausgewählten
Kunden filtert. Die BIRT Komponenten sind mit einer Funktion auszustatten, welche die
bereitgestellten Angebots- bzw. Projektdaten verarbeitet und den entsprechenden
Diagrammen als Daten zur Verfügung stellt. Folglich können die jeweiligen Komponenten
Daten veröffentlichen, empfangen und weiterverarbeiten.
3.4.8 Detailinformationen
Um dem Nutzer neben der Drill-Down Funktion in der grafischen Komponente noch
weitere Detailinformationen zur Verfügung zu stellen, sollen zum einen die
entsprechenden Notes Dokumente aufrufbar sein, und zum anderen generische Berichte
erstellt werden können.
Notes Dokumente
Da alle angezeigten Informationen auf Daten aus Notes Dokumenten aufbauen, sollen
diese direkt aus der Applikation in einem neuen Fenster aufrufbar sein. Dies betrifft im
Kontext dieser Arbeit somit die Dokumente der Kunden, Aktivitäten, Angebote und
Projekte. In den Bereichen der Kunden und Aktivitäten stellt diese Aufgabe ein weniger
S e i t e | 60
großes Problem dar, da die genutzten Notes Views bereits die Möglichkeit bieten, per
Doppelklick auf einen Eintrag das entsprechende Dokument zu öffnen. Neben dieser
Variante soll zusätzlich ein Button erstellt werden, der das Öffnen eines zugehörigen
Dokuments veranlasst. Die grafischen Komponenten der Angebote und Projekte sollen
diese Funktion ebenfalls beinhalten. Dort soll nach dem Auswählen eines bestimmten
Angebots oder Projekts die Möglichkeit bestehen, per Klick auf einen Button das
zugehörige Notes Dokument zu öffnen. Da es sich hier jedoch um eine BIRT Darstellung
handelt, muss, analog zur Drill-Down Funktion, eine interaktive Methode eingesetzt
werden, die das gewählte Element innerhalb des Diagramms ermittelt und anschließend
das Dokument in Notes öffnet.
Bericht
Eine weitere Möglichkeit, Detailinformationen abzurufen, kann durch das Erstellen eines
generischen Berichts gegeben sein. Da BIRT neben Diagrammen über weitere
Darstellungsformen verfügt, bietet es sich auch an, einen überwiegend textuellen Bericht
mit den wichtigsten Details zu erstellen. So kann ein einheitliches Layout erzeugt werden,
welches die jeweiligen Daten per Schnittstelle lädt und in einer neuen Seite anzeigt. Bei
der Erstellung der Berichtsoberfläche muss darauf geachtet werden, dass diese in
druckoptimierter Form ausgegeben wird. Das gibt dem Nutzer, trotz der
Bildschirmoptimierung des Dashboards, eine Möglichkeit, die wichtigsten Informationen
zu drucken. Um diese Funktion zu nutzen, sollen, analog zum Aufruf der Notes
Dokumente, Buttons zur Verfügung stehen, die für ein ausgewähltes Element einen
generischen Bericht mit Detailinformationen in einem neuen Fenster anzeigen.
3.4.9 Geschäftsprozessintegration
Nachdem der Anwender durch die beschriebenen Elemente ausreichend Informationen zur
aktuellen Situation erhalten hat, muss er eine Entscheidung über die weiteren Vorgänge
fällen. Hierfür wird PAVONE Espresso Workflow verwendet. Da dieses Produkt nicht nur
in der zu entwickelnden Applikation für Geschäftsprozesse eingesetzt wird, sondern
innerhalb eines gesamten Unternehmens, auf Basis eines Groupwaresystems zum Einsatz
kommt, genügt hier eine Integration in das Reportingwerkzeug. Dementsprechend soll die
Anwendung als globale Funktion zur Verfügung stehen, um Geschäftsprozesse zu
gestalteten und zu starten. Das erlaubt, aus dem Dashboard heraus entstandene Prozesse im
gesamten Unternehmen weiter zu bearbeiten. Folglich wird für die Einbindung der
S e i t e | 61
Applikation ein Button eingerichtet, der PAVONE Espresso Workflow aufruft und dem
Nutzer die standardmäßigen Möglichkeiten des Produktes anbietet.
3.4.10 Einbindung der Komponenten in eine Composite Application
Im letzten Schritt müssen die entwickelten Komponenten in die Composite Application
eingebunden werden. Das organisiert der Composite Application Editor. Dort werden die
Komponenten anhand der festgelegten Anordnung eingesetzt (siehe Abb. 26). Nachdem
dies geschehen ist, müssen anschließend die passenden Verknüpfungen erstellt werden.
Dazu werden die definierten Schnittstellen der Komponenten per Wiring nach den
Vorgaben verbunden.
Abbildung 26 - Einsetzen der Komponenten in eine Composite Application
S e i t e | 62
4 Prototypische Implementierung eines Reportingwerkzeuges
Das folgende Kapitel beschreibt die prototypische Entwicklung des Reportingwerkzeuges.
Zunächst wird ein Überblick über das Endergebnis gegeben, um anschließend die
einzelnen Bereiche der Implementierung zu erläutern. Abschließend folgt eine kritische
Betrachtung des Ergebnisses, die das entwickelte Produkt mit den Anforderungen sowie
dem Soll-Konzept abgleicht.
4.1 Entwicklung des Prototyps
In diesem Abschnitt werden die Implementierungen der einzelnen Komponenten, sowie
deren Zusammensetzung in der Gesamtlösung beschrieben. Um die Teilbereiche der
Applikation besser einordnen zu können, zeigt Abbildung 27 das fertiggestellte
Reportingwerkzeug in der Übersicht. Dort sind die einzelnen Bereiche blau umrandet und
mit den Buchstaben A, B, C und D beschriftet. Die implementierten Schaltflächen und
Funktionen sind rot umkreist und mit den Ziffern 1 bis 7 gekennzeichnet.
Abbildung 27 - Übersicht Reportingwerkzeug
Der Bereich A beinhaltet die Kundenauswahl und die Funktionen zum Anzeigen der
kundenbezogenen Daten (1) sowie zum Erzeugen eines Geschäftsprozesses (2). Die
S e i t e | 63
Aktivitäten werden im unteren linken Teil der Anwendung (B) angezeigt und durch eine
Schaltfläche (3) können Details zu ihnen abgefragt werden. Im rechten Bereich der
Applikation werden grafische Übersichten für Angebote (C) und Projekte (D) angezeigt.
Diese Ansichten können per Reiterauswahl jeweils von einer Gesamtübersicht (4 + 6) auf
eine kundenbezogene Übersicht (5 + 7) umgeschaltet werden.
Weil die Bereiche der Kundenauswahl und Aktivitäten ausschließlich mit Lotus Notes /
Domino entwickelt wurden, wird auf diese Implementierung im folgenden Kapitel näher
eingegangen. Daran anschließend folgen Entwicklungsdetails der grafischen Komponenten
für Angebote und Projekte, welche mit BIRT und Eclipse realisiert wurden. Die
Einbindung in eine Composite Application inklusive der Schnittstellen wird im
abschließenden Teil erläutert.
4.1.1 Entwicklung mit Lotus Notes / Domino
Für die Entwicklung des Werkzeuges in Lotus Notes / Domino wurde die Version 8.5, wie
in Kapitel 3.4.1 erwähnt, als Grundlage verwendet. Die Beispieldaten der Sales DB und
der Project DB wurden konsistent mit Kunden verknüpft, um die Funktionen der
Applikation nutzen zu können.
Komponente der Kundenauswahl
Für eine kundenbezogene Ansicht von Daten ist zunächst jedoch eine Kundenauswahl von
Nöten. Diese wurde als View in der Sales DB realisiert. Abbildung 28 zeigt die
Komponente mit entsprechenden Beispieldaten. Die Informationen werden aus der Sales
DB bezogen und in der View nach Kunde kategorisiert angezeigt. So können nicht nur
einzelne Unternehmen, sondern auch Ansprechpartner identifiziert werden. Zusätzlich
wurde darauf geachtet, dass die Breite der angezeigten Daten keinen horizontalen
Scrollbalken erfordert und alle dargestellten Informationen, wie hier der Name und die
Adresse, auf den ersten Blick ersichtlich sind. Möchte der Nutzer weitere Details zu einem
bestimmten Kunden erfahren, kann er mit einem Doppelklick auf den entsprechenden
Eintrag das zugehörige Dokument in einem neuen Fenster öffnen.
Im oberen Teil der Komponente befindet sich eine Actionbar, die mehrere Funktionen
bietet. Neben standardisierten Actions, wie Create, Tool oder Help, welche von der
PAVONE Sales Anwendung übernommen wurden, wurde die Action „Show Data“
implementiert, mit der Daten für einen ausgewählten Kunden in den weiteren
Komponenten angezeigt werden können.
S e i t e | 64
Abbildung 28 - Komponente der Kundenauswahl
Sobald die Action gestartet wird, überprüft sie, ob überhaupt ein Kunde ausgewählt wurde
und gibt im Zweifelsfall eine Fehlermeldung aus. Falls doch, wird der ausgewählte Eintrag
in der View ermittelt und über das zugehörige Dokument der Kunde erfragt.
Anschließend werden die Angebotsdaten der Sales DB und die Projektdaten der Project
DB ausgelesen. Aus den Angeboten werden die wichtigsten Daten, wie beispielsweise das
Angebotsdatum, der Umsatz und die Bestandteile des Angebotes, jeweils für die gesamten
Angebote aller Kunden und die Angebote des ausgewählten Kunden extrahiert und in
Variablen gespeichert. Ebenso werden die bedeutsamsten Informationen der Projekte, wie
der Projektname, die Kosten sowie die Projektphasen ermittelt. Auch diese Daten werden
jeweils für die gesamten Projekte aller Kunden und für die Projekte des gewählten Kunden
in Variablen gesichert.
Danach werden XML-Dateien erstellt, die die Inhalte der Variablen übergeben bekommen.
Die Dateien werden im Verzeichnis „C:\Programme\IBM\Lotus\Notes\Data\BI
Reporting\“ gespeichert und stehen somit den Komponenten der Angebote und Projekte als
Datenquellen zur Verfügung. Die weitere Nutzung dieser XML-Dateien wird in Kapitel
4.1.2 beschrieben.
Um auch die Aktivitäten zu aktualisieren, wird ein Agent ausgeführt, der per Webservice
die benötigten Informationen der Komponente zukommen lässt. Details zu diesem
Vorgang werden im Bereich der Aktivitäten im weiteren Verlauf dieses Kapitels gegeben.
S e i t e | 65
Nachdem alle Komponenten mit aktuellen kundenbezogenen Daten versorgt worden sind,
müssen die Ansichten aktualisiert werden. Dazu nutzt die Action das Wiring der
Komponenten, also die Verknüpfung der einzelnen Teile der Applikation. Die ermittelten
Daten werden jeweils über eine Property veröffentlicht und von den angeschlossenen
Komponenten zur Aktualisierung empfangen. Weitere Details zur Verknüpfung der
Komponenten, sowie den Schnittstellen werden in Kapitel 4.1.3 erläutert.
Ebenfalls in der Actionbar zu finden ist die Action „Workflow“. Diese integriert das
Produkt PAVONE Espresso Workflow in die Applikation. Somit wird eine globale
Funktion zum Erstellen von Geschäftsprozessen eingebunden. Prozesse können folglich
auch außerhalb der Anwendung, im gesamten System bearbeitet werden.
Komponente der Aktivitäten
Im Bereich der Aktivitäten werden die Informationen ebenfalls von einer View angezeigt.
Abbildung 29 - Komponente der Aktivitäten
Die angezeigten Daten werden per Webservice aus der Sales DB bezogen, welche sich im
Netzwerk befindet. Aus diesem Grund werden die View sowie zusätzlich benötigte Daten
nicht in der lokalen Sales DB gespeichert, um zu zeigen, dass auch andere Datenbanken
den Webservice ohne Probleme nutzen können. Daher werden die Informationen in der
Composite Application Datenbank (CA DB) abgelegt, welche normalerweise nur für die
Speicherung der Composite Application sowie deren Daten genutzt wird.
Wie Abbildung 29 zeigt, werden die wichtigsten Daten der jeweiligen Aktivität für einen
Kunden angezeigt. Demnach stehen dem Nutzer das Datum, eine Beschreibung und die
S e i t e | 66
zuständige Person zur Verfügung, wobei darauf geachtet wurde, dass auch hier die Breite
der dargestellten Daten nicht zu einem horizontalen Scrollbalken führt.
Um die Daten zu erhalten wird, wie bereits erwähnt, ein Webservice der Sales DB genutzt
(siehe Abb. 30). Dieser verwendet eine View innerhalb der Sales DB um die Dokumente
der Aktivitäten zu lokalisieren. Anschließend werden die wichtigsten Informationen, wie
Titel, Beschreibung, Bearbeiter, Datum und URL des Dokuments, ausgelesen und als Text
verfügbar gemacht.
Abbildung 30 - Abfolge der Informationsbeschaffung per Webservice
Damit die angebotenen Informationen des Webservice genutzt werden können, wurde in
der CA DB ein Webservice Consumer erstellt, der die Daten abruft. Bei der Abfrage
werden Zugangsdaten, wie Benutzername und Passwort, für die Sales DB übermittelt, da
die Anfrage per Internet getätigt wird und unbefugte Zugriffe auf den Webservice nicht
zugelassen werden. Der Consumer kann die empfangenen Daten jedoch nicht in
darstellbare Informationen umwandeln. Diese Aufgabe übernimmt ein Agent, der den
Consumer aufruft. Der Agent erstellt aus den bereitgestellten Informationen Dokumente in
der CA DB, wobei jedes Dokument eine Aktivität beschreibt. Anschließend zeigt die View
der CA DB die erstellten Informationen an.
S e i t e | 67
Da der Webservice jedoch nur die wichtigsten Daten übergibt, kann die View auch nur
diese Informationen anzeigen. Um genaue Details der Aktivitäten zu erlangen, müssen die
originalen Dokumente in der Sales DB aufgerufen werden. Folglich bilden die Dokumente
der CA DB nur temporäre Informationen ab, welche nicht ständig mit den originalen Daten
der Sales DB abgeglichen werden. Aus diesem Grund löscht der Agent bei jedem Aufruf
alle erstellten Dokumente und legt neue an, um nur die aktuellsten Informationen bereit zu
stellen.
Ausgeführt wird der Agent beim Initialisieren der View in der Composite Application, um
bereits beim ersten Start nur die aktuellsten Aktivitäten anzuzeigen. Zusätzlich wird er, wie
bereits im Bereich der Kundenauswahl erwähnt, mit der Action „Show Data“ (siehe Abb.
28) gestartet, um bei einer kundenbezogenen Abfrage ebenfalls die neuesten Daten zu
erhalten.
Um das angesprochene Original-Dokument in der Sales DB zu öffnen, steht die Action
„Show Details“ in der Actionbar der Komponente zur Verfügung (siehe Abb. 29). Bei
einem Klick auf die Action wird die ausgewählte Aktivität ermittelt, das zugehörige
temporäre Dokument in der CA DB gesucht und die gespeicherte URL des originalen
Dokumentes aus der Sales DB in einem neuen Fenster aufgerufen. Die übliche Funktion
von Lotus Notes, per Doppelklick auf den Eintrag einer View das entsprechende
Dokument zu öffnen, wurde hier deaktiviert, da somit das temporäre Dokument geöffnet
würde, welches nur die selben Informationen beinhaltet, die schon in der View zu sehen
sind.
4.1.2 Entwicklung mit Eclipse / BIRT
Die Entwicklung der grafischen Komponenten der Applikation wurde, wie im Soll-
Konzept bereits erläutert (siehe Kapitel 3.4.6), auf Basis von BIRT durchgeführt.
Eingesetzt wurde die aktuelle Version 2.3.1. Da BIRT auf der Eclipse Architektur aufbaut,
wurde die Version 3.4.1 des Eclipse Frameworks als Entwicklungsumgebung genutzt.
Zunächst wurden für alle erforderlichen grafischen Ansichten eigene Reports mit BIRT
erstellt. Um die zugehörigen Daten aus Lotus Notes zu erhalten, dienen die
angesprochenen XML-Dateien als Datenquellen. Derartige Dateien lassen sich mit BIRT
leicht als Quellen einbinden und sind mit Lotus Notes ebenso einfach erstellbar. Allerdings
hat diese Lösung auch Nachteile, wie das Speichern dieser Dateien an einem festen Ort
oder die fehlende Interpretation von Sonderzeichen in XML-Dateien, denn Buchstaben wie
„ß“ oder „ä“ werden nicht erkannt und als Fehler ausgegeben. Jedoch sind die technischen
S e i t e | 68
Voraussetzungen für eine Verbesserung dieser Lösung bereits in Form des Wirings der
Komponenten gegeben, über welches die Daten ebenfalls übergeben werden können.
Komponente der Angebote
Im Bereich der Angebote wurden drei Reports erstellt, um die Angebotsdaten in einer
Gesamtübersicht, einer kundenbezogenen Gesamtansicht und einer kundenbezogenen
Detailansicht darzustellen. Zum Umschalten zwischen der Gesamtübersicht und der
kundenbezogenen Ansicht wurde eine Reiterfunktion in der Composite Application
implementiert, welche in Kapitel 4.1.3 näher beschrieben wird.
Abbildung 31 - Komponente der Angebote in der Gesamtübersicht
Der Report der Gesamtübersicht der Angebote wird in Abbildung 31 angezeigt und stellt
die gesamten Umsätze eines Monats für alle Kunden unter dem Reiter „Gesamtübersicht
Angebote“ dar. Dadurch kann der Nutzer sehen, in welchem Monat besonders hohe oder
niedrige Umsätze gemacht wurden. Dazu werden Säulen angezeigt, wobei die Höhe des
Umsatzes nicht nur durch die Höhe der Säule beschrieben, sondern zusätzlich als Schrift
auf ihr angezeigt wird. Als weitere Funktion zeigt ein Tooltip den entsprechenden Umsatz
bei einem Mouseover über eine Säule an, da bei mehreren Säulen die Schrift nicht mehr
vollständig erkennbar ist.
Unter dem Reiter „Übersicht kundenbezogener Angebote“ befindet sich zunächst der
Report mit der Gesamtansicht für den entsprechenden Kunden, welcher in der Überschrift
zur besseren Übersicht nochmals genannt wird (siehe Abb. 32). Jedes Angebot des Kunden
wird hier anhand des Datums als Säule angezeigt und stellt mit der Höhe den Umsatz dar.
S e i t e | 69
Zusätzlich steht auch hier die Umsatzsumme als Schrift auf jeder Säule und per Mouseover
wird diese als Tooltip dargestellt.
Abbildung 32 - Komponente der Angebote in der kundenbezogenen Sicht
Um weitere Details eines Angebotes zu erhalten, wurde eine Drill-Down-Funktion
implementiert. Mit einem Klick auf die Säule eines bestimmten Angebotes öffnet sich der
Detail Report im gleichen Bereich (siehe Abb. 32). Dabei erhält der Detail Report die
Daten des angeklickten Angebotes als Parameter. Somit werden zusätzliche Informationen
in den XML-Dateien gesucht und angezeigt. Die Darstellung der Angebotsleistungen und
den jeweiligen Umsätzen erfolgt in Form eines Kuchendiagramms, womit auf den ersten
Blick ersichtlich ist, welche Leistung beispielsweise den größten Umsatz erzielt. Die
Teilumsätze werden schriftlich außerhalb des Kuchens dargestellt. Zudem werden weitere
hilfreiche Informationen wie das Datum des Angebotes und der Kunde in der Überschrift,
sowie der Gesamtumsatz des Angebotes im unteren Bereich des Reports angezeigt.
Ebenfalls im unteren Bereich befinden sich zwei Hyperlinks. Zum einen der Link „Zurück
zur Übersicht“, welcher wieder die Gesamtansicht des Kunden im gleichen Fenster öffnet,
und zum anderen der Link „Dokument anzeigen“, der auf Wunsch des Nutzers, das
zugehörige Angebotsdokument in einem neuen Fenster in Lotus Notes öffnet.
S e i t e | 70
Komponente der Projekte
Einen ähnlichen Aufbau wie bei den Angeboten verwendet auch die Komponente der
Projekte. Auch hier wurden drei Reports erstellt. Diese setzen sich aus der
Gesamtübersicht aller Projekte, der Übersicht der kundenbezogenen Projekte und den
Details der Kundenprojekte zusammen. Zudem dient auch hier die Reiterfunktion der
Composite Application zum Umschalten zwischen der Gesamtübersicht und der
kundenbezogenen Übersicht.
Unter dem Reiter „Gesamtübersicht Projekte“ wird der Report der gesamten Projekte
angezeigt, welcher alle Kosten summiert darstellt (siehe Abb. 33). Da die Kosten im Fall
der Projekte zwischen Basis-, Soll- und Ist-Kosten unterschieden werden, steht jeweils eine
Säule für eine Kostenart. Ein Problem stellt die nicht eindeutige Zuordnung eines Projektes
zu einem Monat, wie etwa bei Angeboten, dar. Denn sie werden zumeist über einen
längeren Zeitraum geplant und durchgeführt. Somit beziehen sich die dargestellten Kosten
immer auf den aktuellen Zeitpunkt der Abfrage. Neben der Anzeige der Kosten als Schrift
auf den Säulen, öffnet auch hier ein Mouseover einen Tooltip mit den jeweiligen Kosten.
Abbildung 33 - Komponente der Projekte in der Gesamtübersicht
Wie Abbildung 34 zeigt, beinhaltet der Reiter „Übersicht kundenbezogener Projekte“ den
Report der Projektübersicht eines ausgewählten Kunden. Die Darstellung der
verschiedenen Kostenarten wird analog zur Gesamtübersicht durchgeführt, wobei hier
nicht die Gesamtkosten eines einzelnen Kunden, sondern alle Projekte die mit ihm
zusammenhängen angezeigt werden. Diese tragen den jeweiligen Projektnamen zur
S e i t e | 71
Identifikation und stellen mit der Höhe der drei Säulen die Kosten dar. Im Gegensatz zur
Gesamtübersicht werden hier die Kosten nicht schriftlich innerhalb der Säulen angezeigt,
da der Platz bei mehr als einem Projekt deutlich zu gering wird. Allerdings besteht die
Möglichkeit, über die bekannte Funktion des Mouseovers die Kosten als Tooltip
anzuzeigen.
Abbildung 34 - Komponente der Projekte in der kundenbezogenen Sicht
Ebenso wie bei der Angebotsansicht kann der Nutzer weitere Details mit einem Klick auf
ein Projekt anfordern. Per Drill-Down-Funktion wird der Detail Report im gleichen Fenster
geladen und bekommt die Parameter des ausgewählten Projektes übergeben (siehe Abb.
34). Die Darstellung findet analog zur Übersicht statt, wobei die einzelnen Phasen
innerhalb des Projektes mit den entsprechenden Basis-, Soll- und Ist-Kosten abgebildet
werden. Auch hier werden die jeweiligen Kosten aus Platzgründen nur per Mouseover in
einem Tooltip dargestellt. Die Gesamtkosten des Projektes, sowie der Projektname und der
Kunde werden als zusätzliche Informationen im unteren Bereich bzw. in der Überschrift
angegeben. Um zurück zur Kundenübersicht zu gelangen steht auch hier der Link „Zurück
zur Übersicht“ bereit, der die Übersicht der kundenbezogenen Projekte im gleichen Fenster
öffnet. Ebenso kann der Nutzer das zugehörige Projektdokument mit einem Klick auf den
Link „Dokument anzeigen“ in einem neuen Fenster anzeigen lassen.
S e i t e | 72
Eclipse Plugin
Um die entworfenen Reports in Lotus Notes einzubinden wurde ein Eclipse Plugin mit
dem Namen „BI Reporting“ erstellt. Neben den standardisierten Daten eines Eclipse
Plugins wurden vier Java Klassen entwickelt, die jeweils die Reports der Gesamt- und
Kundenübersicht der Angebote bzw. Projekte in einem BIRT Viewer aufrufen. Damit die
Reports auch in Lotus Notes zu sehen sind, mussten die entsprechenden Java Klassen als
Extensions des Plugins hinzugefügt werden. Somit können sie als Komponente gefunden
und eingebunden werden. Zusätzlich wurde ein Actionhandler implementiert, der die
Schnittstellen des Plugins nutzt und auf eingehende Verbindungen reagiert. So können die,
von den verknüpften Komponenten in Lotus Notes, veröffentlichten Properties überprüft
und die Reports je nach empfangener Property aktualisiert werden.
Die Java Klassen der Reports und der Actionhandler bilden somit den Großteil des Plugins.
Die Reports selber werden nicht in das Plugin übernommen, da sich ein Zugriff auf diese
innerhalb des Plugins als schwer erwies. Aufgrund dessen werden sie im Verzeichnis
„C:\Programme\IBM\Lotus\Notes\Data\BI Reporting\“ abgelegt, in dem bereits die XML-
Dateien gespeichert werden, und werden von den zugehörigen Java Klassen dort
aufgerufen.
Abbildung 35 - Aufbau der Bereitstellung des BI Reporting Plugins
Zum funktionstüchtigen Einsatz in der Composite Application benötigt Lotus Notes neben
dem erstellten BI Reporting Plugin zusätzlich die BIRT Plugins, wie beispielsweise den
S e i t e | 73
BIRT Viewer. Abbildung 35 zeigt den Aufbau der Bereitstellung des Plugins, welcher auf
der untersten Ebene nur die angesprochenen Plugins beinhaltet. Anschließend werden
diese in ein Feature eingebunden, um danach in einer Eclipse Update Site eingebettet zu
werden. Lotus Notes erkennt diese zwar bereits, bietet aber eine eigene Update Site zur
einfacheren Handhabung an. Demzufolge wird die entwickelte Update Site in eine Lotus
Notes Update Site eingebunden, die anschließend zur Einbindung der BIRT Komponenten
in die Composite Application zur Verfügung steht.
4.1.3 Schnittstellen und Zusammenführung der Komponenten
Nachdem die einzelnen Komponenten implementiert wurden, mussten konsistente
Schnittstellen erzeugt werden. Für deren Definition dient eine WSDL-Datei, welche die
Schnittstellen speichert und in die jeweiligen Komponenten eingebunden werden kann. Für
die Kundenauswahl wurde die Datei in der Sales DB, für die Kundenaktivitäten in der CA
DB und für die BIRT Komponenten im BI Reporting Plugin hinterlegt.
Abbildung 36 - Composite Application Editor mit dem Reportingwerkzeug
Die Zusammenführung der Komponenten wurde mit dem Composite Application Editor
realisiert. Abbildung 36 zeigt diesen mit dem erstellten Werkzeug. Die eingesetzten
S e i t e | 74
Komponenten sind in der Liste auf der linken Seite und in der Mitte als Vorschau zu sehen.
Sie bestehen aus der Kundenauswahl View aus der Sales DB, der Kundenaktivitäten View
aus der CA DB, sowie der Gesamtübersicht der Angebote, Gesamtübersicht der Projekte,
Übersicht kundenbezogener Angebote und Übersicht kundenbezogener Projekte, welche
alle aus der BI Reporting Update Site eingebunden wurden. An dieser Stelle fand zudem
die Integration der angesprochenen Reiterfunktion zum Umschalten der unterschiedlichen
Ansichten der Angebote bzw. Projekte statt. Dazu wurden jeweils die Komponenten der
Gesamtübersicht und der kundenbezogene Übersicht in den gleichen Bereich der
Applikation eingebunden, wodurch der Composite Application Editor automatisch eine
Reiterfunktion zur Auswahl erstellt.
Da die eingebundenen BIRT Komponenten nur mit dem erstellten Plugin und den
zusätzlichen BIRT Plugins funktionieren, wird beim Starten der gesamten Applikation
überprüft, ob diese vorhanden sind. Falls nicht, wird ein automatischer Installationsprozess
in Gang gesetzt, der die benötigten Plugins per Update Site installiert.
Das Verknüpfen der Komponenten wurde ebenfalls mit dem Composite Application Editor
per Wiring durchgeführt. Da die Kundenauswahl die zentrale Komponente der Applikation
darstellt und alle weiteren Bereiche auf Abruf aktualisiert, wurden alle weiteren
Komponenten mit ihr verknüpft. In Tabelle 4 werden die veröffentlichten Properties der
Kundenauswahl mit den zugehörigen Actions und Komponenten dargestellt.
Veröffentlichte Property
Verknüpfte Action Zugehörige Komponente Übergebene Daten
Kunde Filter View by Categoryf Aktivitäten Kundenname
Angebot_Kunde Get_Angebot_Kunde Übersicht kundenbezogener Angebote
Kundenbezogene Angebotsdaten
Angebot_Gesamt Get_Angebot_Gesamt Gesamtübersicht Angebote Gesamte Angebotsdaten
Projekt_Kunde Get_Projekt_Kunde Übersicht kundenbezogener Projekte
Kundenbezogene Projektdaten
Projekt_Gesamt Get_Projekt_Gesamt Gesamtübersicht Projekte Gesamte Projektdaten
Tabelle 4 - Wiring der Komponenten ausgehend von der Kundenauswahl
Die Aktualisierung der Aktivitäten wird, wie in Abbildung 37 beschrieben, durch die
Komponente der Kundenauswahl angestoßen. Dazu wird zunächst der bereits erwähnte
Agent aufgerufen, welcher die neuesten Aktivitäten per Webservice erhält und
anschließend die Dokumente aktualisiert. Danach veröffentlicht die Kundenauswahl den
gewählten Kunden über die Property „Kunde“, welche mit der Action „Filter View by
Category“ verbunden ist (siehe Tab. 4). Hierbei handelt es sich um eine Built In Action
S e i t e | 75
von Lotus Notes, welche standardmäßig zum Repertoire gehört und eine bestehende View
nach Kategorie filtert. In diesem Fall zeigt die View anschließend nur die Aktivitäten des
gewählten Kunden an.
Abbildung 37 - Ablauf der Aktualisierung der Aktivi täten
Die Auswahl eines Kunden aktualisiert ebenfalls die Komponenten der Angebote und
Projekte (siehe Abb. 38). Als erstes werden die bestehenden XML-Dateien mit den neu
ermittelten Angebots- und Projektdaten überschrieben. Anschließend werden die Daten per
Property an die jeweiligen Komponenten versendet. Sobald der Actionhandler diese erhält,
veranlasst er die Aktualisierung der Ansichten, wodurch die Informationen der erneuerten
XML-Dateien in die jeweiligen Reports geladen und die ausgewählten Kundendaten
angezeigt werden.
Abbildung 38 - Ablauf der Aktualisierung der Angebote und Projekte
S e i t e | 76
4.2 Kritische Betrachtung des Ergebnisses
In diesem Kapitel findet eine kritische Betrachtung des erstellten Reportingwerkzeuges
statt, indem die gestellten Anforderungen (siehe Kapitel 3.3) sowie das Soll-Konzept
(siehe Kapitel 3.4) mit dem Endprodukt verglichen werden.
Die erstellte Applikation basiert auf dem vorgestellten Konzept für ein Reportingwerkzeug
(siehe Kapitel 3) und erfüllt die gestellten Anforderungen mit Ausnahme der optionalen
Erstellung eines generischen Berichtes allesamt. Die ausgelassenen Berichte werden
jedoch durch die Drill-Down-Funktion und den Zugriff auf entsprechende Notes
Dokumente im Hinblick auf verfügbare Detailinformationen ausgeglichen.
Noch nicht optimal gelöst in der entwickelten Applikation ist die Verwendung von XML-
Dateien als Datenquelle für die BIRT Reports und die Nutzung des Wirings nur als
Aktualisierung der Ansichten (siehe Kapitel 4.1.2). Die Funktionalität der Reports ist
dadurch zwar gegeben, entspricht jedoch nicht exakt den Vorgaben des Konzeptes. Eine
bessere Lösung wäre es, die Daten direkt per Wiring zu übergeben und diese, ohne den
Umweg über externe Dateien, zu nutzen. Der Schritt der Übermittelung der Daten wurde
bereits umgesetzt, die Verwendung der Daten innerhalb der Reports konnte allerdings noch
nicht realisiert werden. Jedoch steht innerhalb des BI Reporting Plugins eine Java Klasse
zur Verfügung, die bereits eine Vorarbeit zur Einbindung dieser Daten leistet.
Verbesserungsmöglichkeiten bei der Darstellung der erstellten Reports sind ebenfalls
vorstellbar. Die jeweiligen Ansichten der Daten wurden zwar unter dem Gesichtspunkt der
Business Intelligence erstellt, es kann die Existenz sinnvollerer Darstellungsarten
allerdings nicht ausgeschlossen werden. Das wird begründet durch die Konzentration auf
die Einbindung heterogener Quellen und die Funktionalität dieses Werkzeuges. Günstig
bei der entwickelten Applikation ist es, dass sie erlaubt, die Darstellungen der bestehenden
Reports auch im Nachhinein mit einfachen Mitteln zu verändern.
Besser zu beurteilen sind die weiteren Bereiche des Reportingwerkzeuges. Das Ziel, eine
komponentenbasierte Applikation zur Entscheidungsunterstützung im Rahmen von
Geschäftsprozessen zu entwickeln, wurde erreicht. Durch die Einbindung heterogener
Datenquellen und die aufbereitete Darstellung der unstrukturierten und semistrukturierten
Informationen nach Gesichtspunkten der Business Intelligence wird dem Nutzer eine
intuitiv verständliche Übersicht der begründet ausgewählten relevanten Daten zur
Verfügung gestellt. Zudem können zur endgültigen Entscheidungsfindung
Detailinformationen grafisch per Drill-Down oder in einem Dokument geöffnet werden.
S e i t e | 77
Dabei wurden die Aspekte einer einheitlichen Oberfläche sowie der Antwortzeit und
Stabilität ebenfalls eingehalten. Das erstmalige Öffnen der Applikation durch das Starten
der BIRT Engine dauert zwar eine Weile, ist dessen ungeachtet im Vergleich zu den
untersuchten grafischen Lösungen am schnellsten (siehe Kapitel 3.4.6) und kann nach dem
Initialisieren ohne große Antwortzeiten genutzt werden.
Zusätzlich rundet die Integration einer globalen Funktion zum Erstellen von
Geschäftsprozessen den Einsatz dieses Werkzeuges ab (siehe Kapitel 4.1.1). So kann der
Nutzer, nach einer Unterstützung durch die Applikation, seine gefällte Entscheidung direkt
in einen Geschäftsprozess umwandeln und ins globale System des Unternehmens
einfließen lassen.
Als besonders positiv zu erwähnen sind die Wiederverwendbarkeit und Erweiterbarkeit der
einzelnen Komponenten. Das BI Reporting Plugin kann mit geringen Anpassungen der
Schnittstellen und Reports auch in andere RCP Anwendungen eingesetzt werden. Ebenso
können die Bereiche der Kundenauswahl und der Aktivitäten in weiteren Composite
Applications innerhalb von Lotus Notes mit Anpassungen wiederverwendet werden. Große
Möglichkeiten der Erweiterbarkeit bietet zudem die Komponente der Aktivitäten. Durch
die Nutzung des Webservices kann nicht nur die Sales DB abgefragt werden, sondern es
können auch weitere externe Datenquellen außerhalb von Lotus Notes angebunden werden
(siehe Kapitel 4.1.1).
Folglich ist das implementierte Reportingwerkzeug ein funktionsfähiger Prototyp. Er
erfüllt die gestellten Anforderungen und bildet einen guten Ausgangspunkt zur weiteren
Entwicklung der Applikation.
S e i t e | 78
5 Ausblick
Wie im vorigen Kapitel erläutert, stellt das Ergebnis der prototypischen Implementierung
dieser Arbeit eine lauffähige Anwendung zur Verfügung, die als Grundlage für weitere
Entwicklungen dienen kann. Auch bei weitestgehender Erfüllung der Anforderungen und
Einhaltung des Konzeptes, ist das Entwicklungspotential dieser Applikation noch nicht
ausgeschöpft. Es besteht an mehreren Stellen des Werkzeuges die Möglichkeit,
Optimierungen und Erweiterungen durchzuführen.
Potential dazu besteht beispielsweise im Bereich der Datenquellen der Reports. Die
Informationen sollten in Zukunft direkt per Wiring bezogen und verwendet werden. Die
bisherige Implementierung übergibt die Daten zwar an die Reports, genutzt werden aber
externe XML-Dateien. Zur Verwendung der übermittelten Daten können einfache Java
Klassen eingesetzt werden, die die eingehenden Informationen an die BIRT Reports
weiterleiten. BIRT kann diese Klassen als Plain Old Java Objects (POJO) als Datenquelle
einbinden. Im erstellten BI Reporting Plugin befindet sich bereits eine Klasse namens
„DataSource“ die diese Funktion beinhaltet und Daten an einen Report übergibt. Jedoch
funktioniert die Einbindung dieser Datenquelle nur innerhalb des Eclipse Frameworks und
nicht im Plugin unter Lotus Notes. Dieses Problem konnte im Rahmen dieser Arbeit nicht
gelöst werden. Für die weitere Entwicklung der Applikation steht die entworfene Klasse
aber bereits als Vorarbeit zur Verfügung.
Weiteres Entwicklungspotential bieten die BIRT Reports. Im Zuge der Arbeit wurden die
Darstellungen bereits nach Punkten der Business Intelligence erstellt, BIRT bietet aber
noch weitergehende Gestaltungsmöglichkeiten, die hier aufgrund der Fokussierung auf die
Gesamtfunktionalität des Werkzeuges nicht allesamt ausgeschöpft werden konnten. So
können weitere Ansichten und Interaktivitäten den Nutzer zusätzlich unterstützen. Ebenso
kann die Realisierung der generischen Berichte mit BIRT durchgeführt werden, da hier
konsistente Layouts erstellt und mit Daten gefüllt werden können.
Um mehrere externe Datenquellen in die Entscheidungsunterstützung einzubeziehen, bietet
die Implementierung des Webservice ein enormes Erweiterungspotential. Durch die
Vorgehensweise der Informationsbereitstellung, können Webservices jeglicher Art
angebunden werden. Änderungen sind anschließend nur im Bereich der Schnittstellen des
Webservice Consumers und der Weiterverarbeitung der Daten durch den Agenten
notwendig.
S e i t e | 79
Das steigende Bedürfnis der Unternehmen nach Informationen lässt erwarten, dass
Reportingwerkzeug, wie dem in dieser Arbeit entwickelten, zukünftig eine zunehmend
wichtigere Rolle spielen, zumal immer mehr unstrukturierte und semistrukturierte Daten in
den Fokus der Entscheidungsfindung rücken. Der Einsatz von Reportingwerkzeugen als
Basis begründeter Entscheidungsfindung wird Unternehmen helfen die ständigen
Herausforderungen des Marktes erfolgreich zu bestehen.
S e i t e | 80
6 Zusammenfassung
Das Ziel dieser Arbeit war die Konzeption und die prototypische Implementierung eines
komponentenbasierten Reportingwerkzeuges, zur Unterstützung eines Nutzers bei der
Entscheidungsfindung im Rahmen von Geschäftsprozessen. Dabei sollten kundenbezogene
Daten aus heterogenen Quellen nach Gesichtspunkten der Business Intelligence aufbereitet
und zur Verfügung gestellt werden.
Es wurde zunächst die Notwendigkeit einer solchen Applikation anhand der Problematik,
unstrukturierte und semistrukturierte Daten zu analysieren, dargelegt (siehe Kapitel 1.1).
Zur weiteren Implementierung des Reportingwerkzeuges wurden IBM Lotus Notes 8
sowie das Composite-Application-Framework als Basis festgelegt (siehe Kapitel 1.2).
Anschließend wurden darauf aufbauend die Grundlagen zu den Themen dieser Arbeit
vorgestellt (siehe Kapitel 2). Diese beinhalteten im Bereich der Business Intelligence eine
nähere Erläuterung des Einsatzes eines Reportingwerkzeuges als Dashboard (siehe Kapitel
2.1.4). Weiter folgten die Grundlagen zum Thema Geschäftsprozesse (siehe Kapitel 2.2)
und zur komponentenbasierten Softwareentwicklung (siehe Kapitel 2.3).
Danach wurde ein Konzept zur Implementierung eines Reportingwerkzeuges beschrieben
(siehe Kapitel 3), welches zunächst auf die Eigenschaften des Composite-Application-
Editors und der Entwicklungsumgebung IBM Lotus Notes einging (siehe Kapitel 3.1).
Darauf folgend stellte ein Anwendungsszenario den Einsatz und die Vorteile eines
Werkzeuges dar (siehe Kapitel 3.2), um anschließend die Anforderungen zu formulieren
(siehe Kapitel 3.3). Im folgenden Soll-Konzept wurden Lösungen für die geforderten
Eigenschaften des Reportingwerkzeuges entwickelt (siehe Kapitel 3.4). Ein besonderer
Fokus lag dabei, neben der Auswahl der darzustellenden Komponenten (siehe Kapitel
3.4.3), auf der grafischen Anzeige und Aufbereitung der kundenbezogenen Daten. Hier
wurden verschiedene Möglichkeiten verglichen und die Entscheidung zugunsten von BIRT
begründet (siehe Kapitel 3.4.6). Abschließend wurde die Einbindung der Komponenten in
eine Composite Application erläutert (siehe Kapitel 3.4.10).
Danach erfolgte die prototypische Implementierung des Werkzeuges auf Basis des
entwickelten Konzeptes (siehe Kapitel 4). Anhand der vorgegebenen Anforderungen und
Ausführungen wurde eine Composite Application mit Anbindung an mehrere
Datenquellen, wie beispielsweise einen Webservice, erstellt (siehe Kapitel 4.1). Neben
Komponenten aus Lotus Notes (siehe Kapitel 4.1.1) wurde ein Plugin mit BIRT Reports
entwickelt und eingebunden, welches Übersichten der kundenbezogenen Daten darstellen
S e i t e | 81
und mit einer Drill-Down-Funktion weitere Details anzeigen kann (siehe Kapitel 4.1.2).
Zudem wurde eine globale Geschäftsprozessfunktion integriert, die es erlaubt aus dem
Werkzeug heraus Prozesse zu erstellen und im gesamten System zu bearbeiten (siehe
Kapitel 4.1.1).
In der kritischen Betrachtung wurde dargelegt, dass die erreichten Ergebnisse dem Ziel der
Arbeit entsprechen. Weiter wurden Möglichkeiten zur Optimierung des entwickelten
Reportingwerkzeuges im Rahmen weiterer Entwicklungsarbeit aufgezeigt (siehe Kapitel
4.2). Im abschließenden Ausblick wurden weiter reichende langfristige
Entwicklungspotentiale der Applikation auf der Grundlage des Ergebnisses dieser Arbeit
angesprochen und der Stellenwert eines Reportingwerkzeuges in den Kontext eines
Unternehmens eingeordnet (siehe Kapitel 5).
S e i t e | 82
Literaturverzeichnis
Abecker, A.; Hinkelmann, K.; Maus, H.; Müller, H. J . (2002):
Geschäftsprozessorientiertes Wissensmanagement – Effektive Wissensnutzung bei der
Planung und Umsetzung von Geschäftsprozessen. Springer Verlag, Berlin usw. 2002
Allweyer, T. (2005): Geschäftsprozessmanagement – Strategie, Entwurf,
Implementierung, Controlling. W3L-Verlag, Herdecke usw. 2005
Andresen, A. (2003): Komponentenbasierte Softwareentwicklung – mit MDA, UML und
XML. Hanser Verlag, München usw. 2003
Beydeda, S. (2007): STECC: Selbsttestende Software-Komponenten. In: Informatik
Forsch. Entw. (2007), S. 243 - 253
BIRT Overview (2009): BIRT Overview. Aus: http://www.eclipse.org/birt/phoenix/intro/
am 10.02.2009
Bischofs, L. (2000): Grundlagen der komponentenbasierten Softwareentwicklung. Aus:
http://www.bischofs.net/studium/KBSE.pdf am 27.11.2008
Coleman, D. (1997): Groupware – Collaborative Strategies for Corporate LANs and
Intranets. Prentice Hall PTR, Upper Saddle River 1997
Daum, B. (2008): Rich-Client-Entwicklung mit Eclipse 3.3 - Anwendungen entwickeln
mit Eclipse RCP, SWT, Forms, GEF, BIRT, JPA u.a.m. 3. überarbeitete und erweiterte
Auflage, dpunkt Verlag, Heidelberg 2008
Dierker, M.; Sander, M. (1998): Lotus Notes 4.6 und Domino – Integration von
Groupware und Internet. Addison-Wesley, Bonn usw. 1998
Doumack, A. (2008): Evaluierung von Reporting-Frameworks am Beispiel der
ausgewählten Open-Source-Anwendungen. Aus: http://faeskorn-woyke.de/wp-
content/uploads/diplom_eval_ado.pdf am 10.02.2009
Ebel, N. (2006): Lotus Notes Domino 7 – Administration – Lotus Groupware installieren,
betreiben und verwalten. Band 1, Addison-Wesley, München 2006
Fischer, H.; Fleischmann, A.; Obermeier, S. (2006): Geschäftsprozesse realisieren - Ein
praxisorientierter Leitfaden von der Strategie bis zur Implementierung. Friedr. Vieweg &
Sohn Verlag, Wiesbaden 2006
S e i t e | 83
Gluchowski, P.; Gabriel, R.; Dittmar, C. (2008): Management Support Systeme und
Business Intelligence - Computergestützte Informationssysteme für Fach- und
Führungskräfte. 2. vollständig überarbeitete Auflage, Springer Verlag, Berlin usw. 2008
Grothe, M.; Gentsch, P. (2000): Business Intelligence – Aus Informationen
Wettbewerbsvorteile gewinnen. 1.Auflage, Addison-Wesley, München 2000
Haft, M.; Olleck, B. (2007): Komponentenbasierte Client-Architektur. In: Informatik
Spektrum, 30.03.2007, S. 143 - 158
Hannig, U. (2002): Knowledge Management und Business Intelligence. Springer Verlag,
Berlin usw. 2002
Hau, M.; Mertens, P. (2002): Computergestützte Auswahl komponentenbasierter
Anwendungssysteme. In: Informatik Spektrum, 17.10.2002, S. 331 - 340
Hinzen, M. (2005): Grundlagen Komponentenbasierte Softwareentwicklung. Aus:
http://www.wi.uni-
muenster.de/pi/lehre/ws0405/seminar/11KomponentenbasierteSoftwareentwicklung.pdf
am 27.11.2008
Humm, B.; Wietek, F. (2005): Architektur von Data Warehouses und Business
Intelligence Systemen. In: Informatik Spektrum, 23.02.2005, S. 3 - 14
IBM Composite Applications (2008): Composite Applications in Notes - Benefits and
Technical Overview. Aus:
http://www.lotus.com/ldd/compappwiki.nsf/dx/Composite%20Applications%20in%20Not
es.pdf/$file/Composite%20Applications%20in%20Notes.pdf am 11.01.2009
IBM developerWorks (2009): What’s new in IBM Lotus Notes 8.5. Aus:
http://www.ibm.com/developerworks/lotus/library/notes85-new/ am 11.01.2009
IBM Lotus Domino (2008): Lotus Domino. Aus: http://www-
142.ibm.com/software/dre/ecatalog/detail.wss?locale=de_DE&S_TACT=none&S_CMP=n
one&synkey=P105893S13390H40 am 11.01.2009
IBM Lotus Notes (2008): Lotus Notes. Aus: http://www-
142.ibm.com/software/dre/ecatalog/detail.wss?locale=de_DE&synkey=I105893X30130U8
4 am 11.01.2009
S e i t e | 84
IBM Presseinformation (2008): Wachstumsmärkte bringen IBM Lotus in Fahrt. Aus:
http://www-304.ibm.com/jct05001c/de/pressroom/presseinfos/2008/07/31_3.html am
11.01.2009
IBM Redbooks (2008): Building Composite Applications. Aus:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247367.pdf am 11.01.2009
IBM Weiterentwicklung (2008): IBM Lotus Notes and Domino: Weiterentwicklung
benutzerorientierter Anwendungen. Aus:
ftp://ftp.software.ibm.com/software/emea/de/lotus/lob10852-dede-00.pdf am 11.01.2009
JasperReports Datasheet (2009): JapserReports Datasheet. Aus:
http://www.jaspersoft.com/downloads/Datasheet/jasperreports-0206.pdf am 10.02.2009
Johansen, R. (1988): Groupware – Computer Support for Business Teams. Free Press,
New York 1988
Kemper, H.-G.; Mehanna, W.; Unger, C. (2006): Business Intelligence –Grundlagen
und praktische Anwendungen - Eine Einführung in die IT-basierte
Managementunterstützung. 2. ergänzte Auflage, Friedr. Vieweg & Sohn Verlag,
Wiesbaden 2006
Lassmann, W. (2006): Wirtschaftsinformatik - Nachschlagewerk für Studium und Praxis.
1. Auflage, Gabler Verlag, Wiesbaden 2006
Luczak, H.; Bullinger, H.-J.; Schlick, C.; Ziegler, J. (2001): Unterstützung flexibler
Kooperation durch Software – Methoden, Systeme, Beispiele. Springer Verlag, Berlin usw.
2001
Maydl, W. (2005): Komponentenbasierte Softwareentwicklung für datenflußorientierte
eingebettete Systeme. Aus: http://www.opus-bayern.de/uni-
passau/volltexte/2006/68/pdf/Dissertation_Walter_Maydl.pdf am 03.12.2008
Mimouh, S.; Heidingsfelder, R. (2008): Pentaho, BIRT und JasperReports im Vergleich.
Aus: http://it-republik.de/jaxenter/artikel/Pentaho-BIRT-und-JasperReports-im-Vergleich-
1737.html am 10.02.2009
Moss, L. T.; Atre, S. (2003): Business Intelligence Roadmap – The Complete Project
Lifecycle for Decision-Support Applications. Addison-Wesley, Boston usw. 2003
S e i t e | 85
Nastansky, L.; Bruse, T.; Haberstock, P.; Huth, C.; Smolnik, S. (2002):
Büroinformations- und Kommunikationssysteme: Groupware, Workflow Management,
Organisationsmodellierung und Messaging-Systeme. In: Fischer, J.; Herold, W.;
Dangelmaier, W.; Nastansky, L.; Suhl, L. (2002): Bausteine der Wirtschaftsinformatik –
Grundlagen, Anwendungen, PC-Praxis. 3. überarbeitete Auflage, Erich Schmidt Verlag,
Berlin 2002, S. 235 - 324
Nierstrasz, O.; Lumpe, M. (1997): Komponenten, Komponentenframeworks und Gluing.
Aus: http://www.iam.unibe.ch/~scg/Archive/Papers/Nier97aKomponentenUndGluing.pdf
am 03.12.2008
PAVONE Produktseite (2009): Schneller Return on Investment mit PAVONE Produkten.
Aus: http://www.pavone.de/pages.nsf/goto/produkte am 05.02.2009
Pentaho Reporting Datasheet (2009): Pentaho Reporting Datasheet. Aus:
http://www.pentaho.com/docs/pentaho_reporting.pdf am 10.02.2009
Philippi, J. (2005): Outsourcing und Offshoring von Business Intelligence-Lösungen –
Empirische Studien und Praxiserfahrung. In: Schelp, J.; Winter, R. (2005): Auf dem Weg
zur Integration Factory – Proceedings der DW2004 – Data Warehousing und EAI, Physica
Verlag, Heidelberg 2005, S. 73 - 106
Pientka, F. (2008): Berichtssoftware – warum nicht Open Source? Aus:
http://www.computerwoche.de/knowledge_center/business_intelligence/1871839/index.ht
ml#EL_12205278662438967749430 am 10.02.2009
Riempp, G. (1998): Wide Area Workflow Management – Creating Partnerships for the
21st Century. Springer Verlag, Berlin usw. 1998
Rosenkranz, F. (2006): Geschäftsprozesse – Modell- und computergestützte Planung. 2.
verbesserte Auflage, Springer Verlag, Berlin usw. 2006
Rubart, J. (2005): Think Shared – Modellbasierte und komponentenbasierte
Unterstützung wissensintensiver Kooperationen. dissertation.de – Verlag im Internet,
Berlin 2005
Scherm, E.; Pietsch, G. (2008): Management- und Entscheidungsunterstützung in
Organisationen: zwischen Technik und Interaktion. In: Bortfeldt, A.; Homberger, J.;
Kopfer, H.; Pankratz, G.; Strangmeier, R. (2008): Intelligent Decision Support - Current
Challenges and Approaches, Gabler Verlag, Wiesbaden 2008, S. 429 - 446
S e i t e | 86
Schmidt, G. (2002): Prozessmanagement – Modelle und Methoden. 2.Auflage, Springer
Verlag, Berlin usw. 2002
Staud, J. (2006): Geschäftsprozessanalyse - Ereignisgesteuerte Prozessketten und
objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche
Standardsoftware. 3. Auflage, Springer Verlag, Berlin usw. 2006
Stiehl, V. (2007): Composite Applications: Neue Verfahren für flexible
Geschäftsprozesse. In: Informatik Spektrum, 30.06.2007, S. 413 - 418
Stritzinger, A. (1999): Komponentenbasierte Softwareentwicklung - Konzepte und
Techniken für das Programmieren und Modellieren in Smalltalk. Aus: http://www.swe.uni-
linz.ac.at/publications/pdf/TR-SE-97.06.pdf am 27.11.2008
Szyperski, C.; Gruntz, D.; Murer, S. (2002): Component Software - Beyond Object-
Oriented Programming. 2. Auflage, Addison-Wesley, Amsterdam 2002
Werth, D. (2006): Kollaborative Geschäftsprozesse – Integrative Methoden zur
modellbasierten Deskription und Konstruktion. Logos Verlag, Berlin 2006
S e i t e | 87
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbständig und nur unter Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Paderborn, den . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Datum) (Unterschrift)
S e i t e | 88
Anhang
Eine Installationsanleitung für den entwickelten Prototyp befindet sich auf der beigelegten
CD in der Datei:
- Installationsanleitung.pdf
Die folgenden Dateien befinden sich auf der CD im Ordner „Quellen“ und beinhalten
verwendete Literatur, die aus Quellen im Internet bezogen wurde:
- BIRT Overview.pdf
- Bischofs - Grundlagen der komponentenbasierten Softwareentwicklung.pdf
- Building Composite Applications.pdf
- Composite Applications in Notes - Benefits and Technical Overview.pdf
- Doumack - Evaluierung von Reporting-Frameworks am Beispiel der ausgewählten
Open-Source-Anwendungen.pdf
- Hinzen - Grundlagen Komponentenbasierte Softwareentwicklung.pdf
- IBM Lotus Domino.pdf
- IBM Lotus Notes and Domino - Weiterentwicklung benutzerorientierter
Anwendungen.pdf
- IBM Lotus Notes.pdf
- JapserReports Datasheet.pdf
- Maydl - Komponentenbasierte Softwareentwicklung für datenflußorientierte
eingebettete Systeme.pdf
- Mimouh, Heidingsfelder - Pentaho, BIRT und JasperReports im Vergleich - Teil
1.pdf
- Mimouh, Heidingsfelder - Pentaho, BIRT und JasperReports im Vergleich - Teil
2.pdf
- Mimouh, Heidingsfelder - Pentaho, BIRT und JasperReports im Vergleich - Teil
3.pdf
- Mimouh, Heidingsfelder - Pentaho, BIRT und JasperReports im Vergleich - Teil
4.pdf
- Nierstrasz, Lumpe - Komponenten, Komponentenframeworks und Gluing.pdf
- PAVONE Produkte - Teil 1.pdf
- PAVONE Produkte - Teil 2.pdf
- PAVONE Produkte - Teil 3.pdf
- PAVONE Produkte - Teil 4.pdf
S e i t e | 89
- PAVONE Produkte - Teil 5.pdf
- Pentaho Reporting Datasheet.pdf
- Pientka - Berichtssoftware - warum nicht Open Source - Teil 1.pdf
- Pientka - Berichtssoftware - warum nicht Open Source - Teil 2.pdf
- Pientka - Berichtssoftware - warum nicht Open Source - Teil 3.pdf
- Stritzinger - Komponentenbasierte Softwareentwicklung.pdf
- Wachstumsmärkte bringen IBM Lotus in Fahrt.pdf
- What's new in IBM Lotus Notes 8.5.pdf