Ein Business-Intelligence-Reportingwerkzeug Zur EntscheidungsunterstüTzung Im Rahmen Von GeschäFtsprozessen
In:
Submitted By sbozdag Words 23185 Pages 93
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 CompositeApplication-Frameworks
Prof. Dr. Ludwig Nastansky
Wintersemester 2008/2009
Betreuer:
Dipl.-Wirt.-Inf. Bernd Hesse, GCC Paderborn
Björn Reinhold, PAVONE AG
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 | 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
Seite |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
Seite |1
1
1.1
Einleitung
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
Seite |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.
Seite |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.
Seite |4
2
Grundlagen
2.1
2.1.1
Business Intelligence
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. Seite |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.].
Seite |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].
Seite |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,
Seite |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 OnlineAnalytical-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
Daten
aktuell, detailliert
Unterstützung von Analysen und
Entscheidungen
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
Seite |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 dezentrales 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
2.2.1
Geschäftsprozesse
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-
Kommunikationssystem [..] des Unternehmens.“ [Staud, 2006, S. 9]
und
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
2.3.1
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 BlackboxWiederverwendung, 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 BlackboxImplementation [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 CompositeApplication-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 JohnsonLenz 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
am gleichen Ort
(lokal)
- Systeme zur computerunterstützten
Sitzungsmoderation
- Präsentationssysteme
- Group Decision Support Systeme
- Systeme zum
Terminkalendermanagement für
Gruppen
- Projektmanagement-Systeme
- 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
an verschiedenen Orten
(verteilt)
zu verschiedenen Zeiten
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 RichClient-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 CompositeApplication-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 UpdateFä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, XMLDateien, 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äulensondern 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 hergeschaltet 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 SollKonzept 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 XMLDateien 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 Aktivitä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 XMLDateien 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-ApplicationEditors 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/wpcontent/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.unimuenster.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://www142.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://www142.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-Vergleich1737.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.unilinz.ac.at/publications/pdf/TR-SE-97.06.pdf am 27.11.2008
Szyperski, C.; Gruntz, D.; Murer, S. (2002): Component Software - Beyond ObjectOriented 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
