Konzeption, prototypische Implementierung und Evaluierung einer allgemeinen Reportinglösung für ein CRM-System

Inhaltsverzeichnis

1 Einleitung
1.1 Einführung und Motivation
1.2 Zielsetzung und Aufgabenstellung
1.3 Überblick

2 Reporting
2.1 Berichtswesen
2.2 Berichtssysteme
2.3 Berichtsgeneratoren
2.4 Portale
2.5 Dashboards

3 Reportingfunktionalitäten bei FlowFact Immobilen CRM
3.1 Firmeninterne Begrifflichkeiten
3.2 Microsoft Word-Anbindung
3.3 Microsoft Excel-Anbindung
3.4 Portalseite
3.5 Geo-Analyzer
3.6 FlowFact BI
3.7 Management Cockpits
3.8 Dashboards
3.9 Vergleich von Reporting mit dem Reportingverständnis von FlowFact

4 Anforderungen an eine allgemeine Reportinglösung und Auswahl eines Reportingtools
4.1 Architekturbeschreibung des FlowFact eCRMs und Auswahl eines Kommunikationsweg für eine allgemeine Reportinglösung
4.2 Anforderungen an die Reportinglösung
4.3 Evaluierung der Reporting Tools
4.3.1 Crystal Reports for Eclipse
4.3.2 Jasper Reports
4.3.3 BIRT
4.3.4 Pentaho BI Suite
4.4 Nutzwertanalyse

5 Lösungskonzept mit BIRT und prototypische Implementierung
5.1 Lösungskonzepte
5.1.1 Lösungskonzept 1: Integration von BIRT in das eCRM
5.1.2 Lösungskonzept 2: Verwendung eines Berichtsservices
5.1.3 Auswahl eines Lösungskonzeptes
5.2 Plug-Ins und die Eclipse-Plattform
5.3 Entwicklung eines ODA Datentreibers mit BIRT
5.4 Prototypische Implementierung
5.4.1 Prototypische BIRT ODA Datentreiber
5.4.2 Implementierung des ODA Address Treibers
5.4.3 Nutzung der ODA-Treiber bei der Berichtsvorlagenerstellung
5.4.4 Integration von BIRT in das eCRM
5.5 Prototypische Beispiele
5.5.1 Dashboards
5.5.2 Reporting (klassisch)
5.5.3 B2E Portal
5.5.4 Exposé
5.5.5 Zusammenfassende Betrachtung der prototypischen Beispiele

6 Resümee

7 Ausblick

Literaturverzeichnis

Anhang
A1) Generierter Brief
A2) Business Intelligence Beispiel 1
A3) Business Intelligence Beispiel 2
A4) FlowFact Product Cockpit
A5) Portalbeispiel
A6) Exposé

Abbildungsverzeichnis

Abbildung 1: Merkmale zur Kennzeichnung und Gestaltung von Berichten nach [CGT+ 2006]

Abbildung 2: Portalklassen aus [Davydov 2001]

Abbildung 3: Dashboard-Ausprägungen aus [GGD 2008]

Abbildung 4: Schematische Darstellung der Servicearchitektur

Abbildung 5: Funktionsweise von Jasper Reports aus [DanChi 2007]

Abbildung 6: Schematische Funktionsweise von BIRT aus [URL:BIR]

Abbildung 7: Schematische Darstellung des ersten Lösungskonzeptes

Abbildung 8: Schematische Darstellung des zweiten Lösungskonzeptes

Abbildung 9: Sequenzdiagramm: Generierung eines Reports aus dem eCRM

Abbildung 10: Die Eclipse-Plattform nach [SKF+ 2004]

Abbildung 11: ODA-Architektur aus [WBC+ 2006]

Abbildung 12: Schnittstellen des ODA Runtime Drivers

Abbildung 13: Anlegen einer FlowFact Firma Data Source

Abbildung 14: Benutzer Data Set

Abbildung 15: Datenbankschema für das Product Cockpit

Abbildung 16: Ausschnitt der Briefvorlage im Design-Modus

Abbildung 17: Schematische Funktionsweise der Portallösung

Tabellenverzeichnis

Tabelle 1: Vergleich der Reportingmöglichkeiten in FlowFact mit Reporting

Tabelle 2: Nutzwertanalyse

Tabelle 3: Übersicht der bei den Beispielen betroffenen Anforderungen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Dieses Kapitel hat das Ziel, in drei Schritten zu der Diplomarbeit hinzuführen:

Das Kapitel 1.1 „Einführung und Motivation“ soll den Kontext der Arbeit aufzeigen. Kapitel 1.2 benennt die Ziele der Arbeit und in Kapitel 1.3 wird der Aufbau des Textes beschrieben.

1.1 Einführung und Motivation

Die Firma FlowFact AG bietet seit über zwanzig Jahren Customer Relationship Management Lösungen speziell für die Immobilenbranche an. Das Unternehmen wurde 1985 unter dem Namen „IMP Klaus Kappert Computersysteme“ durch Herrn Klaus Kappert gegründet, mit dem Ziel, Vorgänge in einem Unternehmen zentral, vollständig und übersichtlich zur Verfügung zustellen.

Im Jahr 2000 wurde die FlowFact AG mit Hauptsitz in Köln ins Leben gerufen und 2003 folgte die Gründung der Vertriebsgesellschaft FlowFact Schweiz AG. Heute beschäftig das Unternehmen mehr als 80 Mitarbeiter in den Bereichen Entwicklung, Marketing, Sales, Service und Backoffice.

Die Software der FlowFact AG richtet sich an Unternehmen, welche im Immobiliensektor tätig sind. Daher ist diese speziell auf die Bedürfnisse von Wohnmaklern, Gewerbemaklern, Banken und Sparkassen, Immobilienverwaltungen, Bauträgern, Wohnungsgenossenschaften und Fertig-/Massivhausherstellern, Projektentwicklern und Fondsinitiatoren zugeschnitten.

CRM-Systeme mit einer Ausrichtung auf Zielgruppen außerhalb der Immobilenbranche werden ebenfalls entwickelt, gehören aber nicht zum Kerngeschäft.

Insbesondere entwickelt die Firma FlowFact zwei Softwareprodukte. Die Software FlowFact Immobilien CRM ist ein über viele Jahre gewachsenes Softwareprodukt, welches dem Benutzer bei der Verwaltung seiner Kontaktadressen, Termine, Aufgaben, Wiedervorlage und Immobilienobjekte unterstützt. Darüber hinaus bietet die Software dem Benutzer bei vielen Arbeitsprozessen Unterstützung. Beispielsweise können Daten von Immobilienobjekten auf über 30 Immobilienportalen oder auf eigenen Firmenhomepages ohne Mehrfacheingabe problemlos übertragen werden. Briefe und Exposés können per Mausklick in einem einheitlichen Firmenlayout erzeugt werden und Controllingwerkzeuge dienen Managern als Entscheidungshilfe.

Die Software ist sehr komplex und bietet dem Benutzer äußerst viele Funktionalitäten, welche in dieser Arbeit nicht alle beschrieben werden können. Die für die Diplomarbeit relevanten Funktionalitäten werden aufgrund dessen gesondert erläutert.

Da die Software seit 1985 besteht, über viele Jahre gewachsen ist und ständig weiterentwickelt wird, basiert diese auf den unterschiedlichsten Technologien und Programmiersprachen. Reportingmöglichkeiten sind in zahlreicher Menge vorhanden und werden durch viele unterschiedliche Technologien gelöst.

Das Programm FlowFact eCRM ist eine auf Java basierende, plattformunabhängige Neuentwicklung der Software FlowFact Immobilien CRM. Einfache Oberflächen garantieren kürzere Einarbeitungszeiten und eine höhere Effektivität der Mitarbeiter. Da das FlowFact eCRM webbasiert ist, kann der Anwender das Programm von jedem Ort aus über das Internet nutzen. Aufgrund der Tatsache, dass die Software eine komplette Neuentwicklung ist, ist der Funktionsumfang bei weitem nicht so ausgeprägt wie bei FlowFact Immobilien CRM.

Reportingfunktionalitäten sind in diesem Produkt bisher noch nicht vorhanden.

1.2 Zielsetzung und Aufgabenstellung

Im letzten Abschnitt wurde deutlich, dass die Software FlowFact eCRM, nachfolgend eCRM genannt, über keinerlei Reportingfunktionen verfügt. Es besteht daher die Notwendigkeit diese Funktionalitäten, welche in der Software FlowFact Immobilien CRM vorhanden sind, ebenfalls in das eCRM zu integrieren. Die Hauptzielsetzung dieser Arbeit ist folglich, eine adäquate technologische Lösung zu finden mit dem das Programm um diese wichtigen Funktionalitäten erweitert werden kann.

Dementsprechend lautet die konkrete Aufgabenstellung wie folgt:

Konzeption, prototypische Implementierung und Evaluierung einer allgemeinen Reportinglösung für ein CRM-System

Im Rahmen der Evaluierung muss aus einer Menge von Technologien eine geeignete ausgewählt werden. Im Vorfeld müssen zunächst als Grundlage der Evaluation Kriterien zur Auswertung der Technologien klar definiert werden. Hierzu sind folgende Schritte notwendig:

Um die in der Software FlowFact Immobilien CRM verwendeten Reportingfunktionalitäten bewerten und einordnen zu können, muss zunächst die Begrifflichkeit „Reporting“ eindeutig bestimmt werden.

Anschließend muss analysiert werden, welche Reportingfunktionalitäten genau in der Software FlowFact Immobilien CRM vorhanden sind und es muss geprüft werden, ob dort verwendeten Funktionalitäten, welche in der Software zu der Kategorie Reporting gehören, deckungsgleich mit dem Reportingverständnis der Wissenschaft sind. Dies dient dazu, die Funktionalitäten einordnen und kategorisieren zu können. Demnach kann entschieden werden, ob es sinnvoll ist, eine Funktionalität, welche nicht dem klassischen Reporting zuzuordnen ist, durch eine allgemeine Reportinglösung abzudecken.

Durch diese Untersuchung ergeben sich Anforderungen an die allgemeine Reportinglösung. Mit Hilfe dieser Anforderungen muss aus einer Menge an Reportingtools ein geeignetes evaluiert werden.

Um zu demonstrieren, dass die ausgewählte technologische Lösung tatsächlich im Rahmen der Anforderungen für die Reporterstellung geeignet ist, muss, auf einem allgemeinen Lösungskonzept aufbauend, eine prototypische Implementierung folgen. Mit Hilfe dieser Implementierung muss die Praxistauglichkeit der allgemeinen Lösung bewiesen werden.

1.3überblick

Die Diplomarbeit gliedert sich wie folgt:

Kapitel 2 bildet die theoretische Grundlage dieser Arbeit. Neben dem Reportingbegriff werden Portale und Dashboards als Bestandteile des Berichtswesens eingeführt und die Funktionsweise von Berichtsgeneratoren erläutert.

Kapitel 3 führt zunächst firmeninterne Begrifflichkeiten ein. Im Anschluss daran werden alle in dem Softwareprodukt FlowFact Immobilien CRM vorhandenen Reportingmöglichkeiten erläutert. Abschließend werden die beschriebenen Möglichkeiten mit dem in Kapitel 2 dargestellten Reporting verglichen und kategorisiert.

Kapitel 4 hat das Ziel, ein geeignetes Reportingtool auszuwählen. Dafür wird zunächst eine Methode bestimmt, um komfortabel an Daten aus der Datenbank zu gelangen. Daraufhin werden Anforderungen an eine Reportinglösung gestellt und vier Reportingtools kurz vorgestellt. Im Rahmen einer Nutzwertanalyse werden die einzelnen Tools genau evaluiert, so dass ein geeignetes Reportingtool ausgewählt werden kann.

Kapitel 5 beschreibt das Lösungskonzept und die prototypische Implementierung. Damit das Lösungskonzept nachvollzogen werden kann, erfolgt zunächst eine Betrachtung der Eclipse-Plattform und der Funktionsweise von Plug-Ins. Darauf aufbauend werden die notwendigen Schritte für die Implementierung eines ODA Datentreibers erläutert, so dass alle benötigten Datentreiber detailliert betrachtet werden können. Des Weiteren wird beschrieben, wie BIRT in das eCRM integriert werden kann und wie eine Reportvorlage, welche die selbst implementierten ODA Treiber nutzt, erstellt wird.

Im Anschluss daran werden die prototypischen Beispiele, welche im Rahmen dieser Diplomarbeit implementiert wurden, beschrieben.

Kapitel 6 fasst die Ergebnisse dieser Arbeit kurz zusammen.

Kapitel 7 gibt einen Ausblick auf Erweiterungen und beschreibt wichtige Hinweise für eine zukünftige, reale Implementierung.

2 Reporting

Dieses Kapitel dient als theoretische Grundlage für diese Arbeit. Die Begriffe Report und Reporting werden definiert und klassifiziert. Darüber hinaus werden Portale und Dashboards beschrieben.

2.1 Berichtswesen

Die Wörter Reporting und Report stammen aus dem englischen. Die deutschen Übersetzungen dafür sind Berichtswesen und Bericht. Im Folgenden gilt es diese Begriffe genau zu definieren, so dass auf dieser theoretischen Grundlage das Reportingverständnis der Firma FlowFact mit der klassischen Bedeutung des Begriffes verglichen und eingeordnet werden kann.

In der Literatur finden sich unterschiedlichste Definitionen zum Berichtswesen. [Krupinski 2005] beschreibt das Berichtswesen als eine Bündelung von Kennzahlen mit dessen Hilfe man zu Aussagen gelangt. [Jung 2007] sieht dagegen das Berichtswesen als ein bedeutsames Instrument, welches die Führungsebenen eines Unternehmens mit Informationen und Daten versorgt um so betriebwirtschaftliche Entschlüsse zu fassen.

Eine gute Begriffsbestimmung liefert [GGD 2008], welcher die Definition von [Blohm 1969] aufgreift und ergänzt:

„ Das Berichtswesen umfasst alle Personen, Organisationseinheiten, Vorschriften, Daten und Prozesse, die bei der Erzeugung und Weiterleitung von Berichten beteiligt sind. “

Seiner Meinung nach, besteht die Hauptaufgabe des Berichtswesens darin, allen Mitarbeitern mit den für sie notwendigen Informationen zu versorgen. Die Auskünfte erhalten sie entweder in bestimmten klar definierten Abständen, oder wenn ein bestimmtes Ereignis auftritt.

Berichte als Teil des Berichtswesens sind Dokumente, welche Informationen vollständig und umfassend für einen bestimmten Untersuchungszweck kombinieren und entsprechend darstellen [KHL+ 2006][KMU 2006]. Berichte mit reinem informellem Charakter sollten ebenso vermieden werden wie solche ohne eine spezielle Aussage. Berichte sollten eine Handlung des Berichtsempfängers zur Folge haben. Um dies zu erreichen, empfiehlt es sich im Vorfeld eine Informationsbedarfsanalyse durchzuführen. Diese klärt, welche Informationen in welcher Genauigkeit an einen Empfänger in einer bestimmten Aktualität geliefert werden [Külpmann 2005]. Dabei sollte nach [Jung 2007] beachtet werden, dass „ so wenig wie möglich und so viel wie nötig “ verständlich und übersichtlich dargestellt wird. Die Informationen dürfen nicht verfälscht werden und sollten durch eine hohe Aktualität gekennzeichnet sein, so dass der Empfänger die Möglichkeit hat zeitnah zu reagieren.

[Mehlan 2005] und [Jung 2007] unterscheiden drei Arten von Berichten:

Standardberichte werden in regelmäßigen Zeitintervallen einer bestimmten Zielgruppe mit standardisierten Daten zur Verfügung gestellt. Da die Abfragen nicht vor der Berichtserstellung an individuelle Fragestellungen angepasst werden müssen, ist diese Berichtsart kostengünstig. Der Berichtsempfänger erhält demnach in regelmäßigen Abständen einen vorgefertigten Bericht ohne Einfluss auf die dort präsentierten Informationen nehmen zu können.

Ein Abweichungsbericht hat die Aufgabe auf Problematiken hinzuweisen. Er wird erst dann erzeugt, wenn beispielsweise eine Abweichung von einem Vorgabewert vorliegt. Durch diesen unregelmäßig erzeugten Bericht wird eine zu häufige Berichtserstellung vermieden und der Berichtsempfänger hat somit die Möglichkeit direkt zu reagieren.

Ein Bedarfsbericht ist ein Sonderbericht zu individuellen Fragestellungen. Da sich diese Berichtsform nicht standardisieren lässt, ist diese Berichtsart äußerst kostspielig.

Ein Bericht kann nach [Koch 1994] und [Jung 2007] verschiedene Absichten verfolgen. Er kann als Entscheidungsvorbereitung, zur Kontrolle, zur Dokumentation oder als Auslöser eines betrieblichen Vorgangs dienen. Einige Beispiele sollen dies verdeutlichen:

Eine Dokumentation könnte beispielsweise ein Sitzungsprotokoll sein und der Vergleich von Soll-Ist-Werten könnte der Kontrolle dienen. Ein betrieblicher Vorgang kann ausgelöst werden, wenn finanzielle Ausgaben einen Wert überschreiten und dies zu Budgetkürzungen führt. Liquiditätsberichte könnten als Entscheidungsvorbereitung fungieren.

Berichtsempfänger können ganz unterschiedliche Zielgruppen sein. Manager benötigen Berichte ebenso wie Fachleute, Abteilungsleiter oder Sachbearbeiter. Bei der optischen und inhaltlichen Gestaltung eines Berichtes müssen die jeweiligen Bedürfnisse des Empfängers berücksichtigt werden. Während ein Manager eher ein Interesse an verdichteten Kennzahlen über das Gesamtunternehmen hat, ist für einen Abteilungsleiter von Bedeutung, wie viele Mitarbeiter er als Planungsgrundlage zur Verfügung hat [Mehlan 2005].

In einem Bericht werden Tabellen, Texte, Kennzahlen und Schaubilder als Darstellungsformen genutzt. Diese können gemischt eingesetzt werden, so dass der Empfänger das Wissen in gebündelter Form präsentiert bekommt. Da der Erfolg eines Berichtes im wesentlichem von der Präsentationsform abhängt, sind einige Aspekte bei der Gestaltung zu beachten [Sturm 2006]:

Auch wenn Kennzahlen äußerst bedeutsam sind, sollte der Schwerpunkt auf einigen wenigen aussagekräftigen liegen. Texte sollten nur verwendet werden, um weitere Anmerkungen zu machen, Grafiken und Diagramme nur dann, wenn sie gegenüber einer Tabelle das Erkennen von Informationen vereinfachen.

Abbildung 1 stellt übersichtlich alle Merkmale eines Berichtes dar, wobei die Wichtigsten bereits erläutert wurden. Vereinfacht wird die Abbildung in [Koch 1994] verwendet, doch [CGT+ 2006] stellt die Zusammenhänge wesentlich übersichtlicher dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Merkmale zur Kennzeichnung und Gestaltung von Berichten nach [CGT+ 2006]

Das Berichtswesen muss dem Berichtsempfänger durch einen Report sowohl über interne als auch externe Vorgänge informieren können. Das Berichtswesen konzentriert sich also nicht nur auf Finanzdaten, sondern auch auf andere Aspekte wie Branchentrends, Kundenwünsche, oder Personalentwicklungen [Mehlan 2005]. Die schwierigste Herausforderung an das Berichtswesen ist dabei, flexibel auf Änderungen reagieren zu können.

2.2 Berichtssysteme

Unter einem Berichtssystem versteht man die technische Lösung zur Erzeugung der Berichte. Sobald diese automatisch durch einen Computer erstellt werden, spricht man von einem Berichtssystem [GGD 2008].

Man unterscheidet zwischen aktiven und passiven Berichtssystemen. Bei aktiven Berichtssystemen werden Berichte periodisch oder a-periodisch erzeugt. Der Berichtsempfänger stößt die Generierung der Berichte nicht an, sondern erhält die fertigen Berichte, welche in bestimmten Zeitabständen (periodisch), oder bei Abweichungen von einem Grenzwert (a-periodisch), erzeugt werden. Passive Berichtssysteme haben die Aufgabe, individuelle Fragestellungen zu beantworten. Der Benutzer benötigt dafür umfangreiche IT-Kenntnisse und die Berichtserzeugung muss manuell angestoßen werden [AGW+].

2.3 Berichtsgeneratoren

Berichtsgeneratoren unterstützen den Anwender dabei, Berichtsvorlagen inhaltlich und optisch zu gestalten. Moderne Berichtsgeneratoren bieten die Möglichkeit, komplexe Berichtsvorlagen zu gestalten, um so die gewünschten Informationen übersichtlich darzustellen. Tabellen, Texte, Grafiken und Diagramme lassen vielfältige Gestaltungsmöglichkeiten zu und mathematische Funktionen, wie die Berechnung von Summen werden meist unterstützt [PerUnl 2003]. Aus den mit Hilfe eines Berichtsgenerators erzeugten Vorlagen, lassen sich Berichte in bestimmten Ausgabeformaten generieren.

Detailliertere Informationen zur Vorlagenerstellung sind an dieser Stelle nicht gegeben, da hier lediglich die Begrifflichkeit erläutert wird.

2.4 Portale

Als zentraler Zugriffspunkt stellt ein Portal eine einheitliche Möglichkeit für diverse Inhalte und Applikationen dar [KMU 2006]. Unterschiedliche Inhalte oder Anwendungen werden auf einer Bildschirmseite zusammengeführt, wobei die angezeigten Informationen nicht zum drucken, sondern für die Ausgabe auf einem Monitor bestimmt sind [GGD 2008]. Um den Portalbegriff näher erläutern zu können, ist eine Klassifizierung hilfreich, da Portale je nach Anwendungsbereich unterschiedliche Ausprägungen und Zielsetzungen haben können. [Davydov 2001] gliedert Portale in mehrere Portalklassen, welche in Abbildung 2 erkennbar sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Portalklassen aus [Davydov 2001]

Alle Portalklassen lassen sich demnach in drei Hauptkategorien einordnen:

Public Portals:

Ein Public Portal (Öffentliches Portal) ist eine Webseite welche als Zugangstor zum Internet verstanden werden kann. Ein Beispiel hierfür wäre die Webseite der Firma AOL, da dem Nutzer diverse Dienste, wie Such-, Nachrichten- und Wetterdienste angeboten werden.

Personal Portals:

Bei einem Personal Portal (Persönliches Portale) werden Informationen auf mobilen Endgeräten wie PDAs oder Handys dargestellt.

Corporate Portals:

Hauptaufgabe von Corporate Portals (Unternehmensportalen) ist es, unternehmensspezifische Informationen sowohl intern als auch extern bereitzustellen, um den Arbeitsprozess produktiv zu gestalten. Benutzer von Unternehmensportalen müssen problemlos und schnell an Informationen oder Applikationen gelangen können.

Bei Role Portals erfolgt eine Einordnung über die Aufgabe des Portals:

- B2C steht für Business To Customer. Demnach handelt es sich um ein Unternehmensportal, dass sich an den Kunden wendet.
- Die Abkürzung B2B steht für Business To Business. Unternehmensportale, welche sich an andere Unternehmen richteten, fallen in diese Kategorie.
- Wendet sich ein Unternehmensportal intern an die Mitarbeiter eines Unternehmens, so handelt es sich um ein B2E (Business To Employee) Portal.

Enterprise Information Portals verbinden interne oder externe Benutzer miteinander, um ihnen komprimierte Informationen darzustellen, so dass auf Grundlage dieser Informationen Entscheidungen getroffen werden können. Die Hauptaufgabe eines Colloboration Portal ist es, die Zusammenarbeit und demnach die Kommunikation eines Teams zu vereinfachen. Inhalte eines solchen Portals wären Beispielsweise Foren, Chats oder individuelle Applikationen.

Content Management Portale stellen den Benutzern digitale Daten wie Dokumente und Bilder zur gemeinsamen Nutzung bereit. Business Intelligence Portale werden benutzt, um tägliche Geschäftsprozesse steuern zu können.

Wie bereits zuvor erwähnt besteht ein Portal aus mehreren Elementen, welche die jeweiligen Inhalte darstellen. Diese Elemente nennt man Portlets und dienen als Container für die Inhalte. Jeder Container verfügt über Funktionalitäten wie vergrößern oder verkleinern des Portlets [KMU 2006].

Da ein Portal einen zentralen Zugang bietet, muss der Benutzer sich lediglich einmal dort anmelden, um an alle Inhalte des Portals zu gelangen. Dieses Anmeldeverfahren nennt man Single Sign On [GGD 2008].

2.5 Dashboards

Nach [Few 2006] ist ein Dahsboard eine grafische Anzeige von den wichtigsten Informationen eines oder mehrerer Sachverhalte. Diese Informationen sind auf einer Bildschirmseite so angebracht, dass man diese auf einem Blick wahrnehmen kann. Damit die dort dargstellten Informationen intuitiv verständlich sind, verwendet man als Visualisierungsform häufig alle Arten von Tachometeranzeigen wie sie aus dem täglichen Leben bekannt sind [GGD 2008].

Bereits 1980 versuchte man Informationen aus unterschiedlichen Quellen komprimiert und übersichtlich mit Hilfe von Excecutive Imformation Systems (EISs) darzustellen. Zur damaligen Zeit gab es noch keine Data Warehouse Technologie, wie sie heute aus dem Business Intelligence Umfeld bekannt ist, so dass es eine große Herausforderung war, an die benötigten Daten zu gelangen. Erst als Data Warehouse und Business Intelligence theoretisch begründet wurden, griff man die Idee alle Daten übersichtlich darzustellen erneut unter dem Konzept Dashboard auf.

Die in einem Dashboard dargestellten Informationen sind speziell auf einen Benutzer, eine Gruppe von Benutzern oder auf eine bestimmte Funktion zugeschnitten [Few 2006].

Ein Dashboard besteht aus den Elementen: Datenquelle, Granularität, Berechnung und Varianz. Die Datenquelle gibt an, aus welchen Quellen die Daten geholt werden sollen. Granularität definiert wie häufig eine Aktualisierung erfolgen soll. Das Element Berechnung spezifiziert die genaue mathematische Operation auf der Datenmenge und die Varianz besagt, dass die Informationen widerspruchsfrei sein müssen.

Um ein Dashboard sinnvoll einsetzen zu können, sollte man vorher überlegen welche Information dargestellt werden soll, für wen diese bestimmt ist und wer diese Information präsentiert [Malik 2005].

[Few 2006] teilt Dashboards in drei Kategorien mit unterschiedlichen

Merkmalsausprägungen ein. [GGD 2008] stellt diese übersichtlich dar (siehe:

Abbildung 3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Dashboard-Ausprägungen aus [GGD 2008]

Strategische Dashboards sind auf langfristige Unternehmensziele ausgerichtet. Dabei werden verdichtete Kennzahlen und eine einfache Darstellungsform ohne Interaktionsmöglichkeit genutzt.

Taktische Dashboards werden verwand, um über den Erfolg von kurzfristigen Projektzielen entscheiden zu können. Trends und Problemursachen können so schnell erkannt werden.

Operative Dashboards überwachen das Tagesgeschäft eines Unternehmens und haben die Aufgabe kurzfristige Ereignisse schnell zu erkennen, um entsprechend reagieren zu können. Informationen müssen daher zeitnah berechnet und dargestellt werden [GGD 2008].

Beim Design eines Dashboards sollte nach [Few 2006] folgendes beachtet werden:

Alle Informationen müssen direkt, ohne scrollen oder klicken zu müssen, angezeigt werden. Alle Anzeigen sollten so gestaltet sein, dass die Informationen eine Aussage erhalten. Eine Tachometeranzeige bekommt beispielsweise erst dann eine Bedeutung, wenn ein Idealwert markiert ist, da man sonst keine aussagekräftige Äußerung über die Qualität der Information machen kann. Außerdem weist [Few 2006] darauf hin, dass Balkendiagramme gegenüber Kreisdiagrammen zu bevorzugen sind, da der Mensch leichter Höhen als Flächen beurteilen kann.

Bei Dashboards wird ebenfalls das bereits beschriebene Single Sign On Verfahren verwand, so dass sich der Benutzer nicht an unterschiedlichen Informationssystemen anmelden muss.

3 Reportingfunktionalitäten bei FlowFact Immobilen CRM

Nachdem im vorherigen Kapitel beschrieben wurde, was in der Literatur unter Reporting verstanden wird, gilt es nun die Reportingfunktionalitäten der Software FlowFact Immobilien CRM zu beschreiben. Anschließend wird beurteilt, in wie fern sich beide Ansätze decken, oder wo Unterschiede bestehen. Zuvor werden firmeninterne Begrifflichkeiten erläutert, so dass die verwendeten Fachbegriffe klar definiert sind.

3.1 Firmeninterne Begrifflichkeiten

In den Softwareprodukten der Firma FlowFact werden einige Begrifflichkeiten verwendet, die für ein besseres Verständnis dieser Arbeit erläutert werden müssen.

Adressen:

Praktisch jeder Arbeitsablauf beginnt mit einer Adresse. Eine Adresse kann die eines Mieters, eines Kaufinteressenten, eines Bekannten oder eines Objektes sein. Alle weiteren Ausprägungen wie beispielsweise die Adresse eines Notars sind möglich. Von einer Adresse aus sind alle Aktivitäten verknüpft.

Aktivitäten:

Aktivitäten sind alle denkbaren Vorgänge oder Ereignisse. Unter anderem sind E- Mails, Rechnungen, Briefe, Notizen, Faxe, Termine oder auch Telefonate mögliche Aktivitäten, so dass mit Hilfe dieser Aktivitäten lückenlose Historien entstehen.

Objekte:

Vereinfacht dargestellt, sind Objekte Kauf-, oder Mietimmobilien. Es können aber auch komplexe Investmentpakete als Objekte abgebildet werden.

Feldarten:

Bei den meisten Programmen sind Eingabemasken fest vorgegeben oder können nur eingeschränkt erweitert werden. Feldarten bieten dem Benutzer die Möglichkeit frei definierbare Felder anzulegen. Eine Adresse kann beispielsweise durch die Feldart „Hobby“ erweitert werden, oder ein Objekt durch die Feldart „Garagenanzahl“. Dadurch kann der Benutzer die Software an seine jeweiligen Bedürfnisse anpassen. Eine Feldart kann von verschiedenen Datentypen sein und den Wert einer Berechnung annehmen.

3.2 Microsoft Word-Anbindung

Es besteht die Möglichkeit standardisierte Briefe im Microsoft Word Format direkt aus dem Programm zu erzeugen. Mit Hilfe von speziellen Platzhaltern können Briefvorlagen erstellt werden. Bei der Installation des Programms wird Word um einen Menüpunkt mit dem Namen FlowFact erweitert. Über dieses Menü hat der Benutzer die Möglichkeit verfügbare Platzhalter einzusehen und kann diese an entsprechender Stelle in das Dokument einfügen. Als Platzhalter sind Adressen, Objekte und Aktivitäten vorhanden, wobei auch Bilder von Objekten zur Auswahl stehen.

Grundsätzlich gilt, dass nahezu alle Informationen einer Adresse, eines Objektes, einer Aktivität, oder des jeweiligen Benutzers als Platzhalter dienen können. Das Dokument muss unter einem festgelegten Pfad gespeichert werden. Möchte man den Brief automatisch erzeugen, so wählt man im Programm die entsprechende Vorlage aus. Daraufhin werden die Platzhalter im Dokument durch die entsprechenden Werte ersetzt und dieses wird geöffnet, so dass der Anwender das Dokument um weiteren Text ergänzen kann.

Auch wenn die Erstellung eines Briefes mit Hilfe der Platzhaltertechnik unkompliziert zu sein scheint, erfordert diese äußerst gute Kenntnisse in Word. Selbst ein geübter Word-Nutzer benötigt eine Schulung, um fehlerfreie Vorlagen zu erstellen.

Die Word-Anbindung kann auch dazu verwendet werden, um Exposés zu erzeugen. Exposés werden von Immobilienmaklern benutzt, um ein Objekt einem Interessenten zu präsentieren. Die Generierung von Exposés wurde jedoch nicht als Anforderung an diese Diplomarbeit gestellt und wird deshalb hier nicht weiter behandelt.

3.3 Microsoft Excel-Anbindung

Die Möglichkeit Informationen über Adressen, Aktivitäten und Objekte mittels Platzhalter in Microsoft Excel darzustellen unterscheidet sich lediglich im Ausgabeformat von der im vorherigen Abschnitt dargestellten Word-Anbindung. Daher wird diese nicht separat erläutert.

3.4 Portalseite

Auf der in die Software integrierten Portalseite werden mit Hilfe von HTML, CSS und Javascript Unternehmensinformationen dargestellt.

Unter anderem können dies folgende Auskünfte sein:

- Abwesende Mitarbeiter
- Geburtstage
- Termine
- Offene Rechnungen
- Anzahl von Objektbesichtigungen

Die auf dem Portal angezeigten Informationen lassen sich durch den Benutzer verwalten. Dieser hat die Möglichkeit, die Position der Portlets nach seinen eigenen Wünschen und Bedürfnissen anzupassen. Darüber hinaus kann der Benutzer weitere Portlets mit individuellen Informationen hinzufügen, oder entfernen.

3.5 Geo-Analyzer

Der Geo-Analyzer stellt eine eigenständige Applikation dar, welche über das Programm selbst aufgerufen wird. Der Geo-Analyzer schafft eine Geo- Informationsbasis zur Auswertung und Visualisierung unterschiedlichster Informationsebenen mit Kartenmaterial aus ganz Europa basierend auf Microsoft Map Point.

Folgende Daten können aufbereitet und in Stadt-, Straßen- und Übersichtskarten visualisiert werden:

- Einzelne Adressen
- Einzelne Objekt-Adressen
- Routenplanung der Strecken zu der jeweiligen Adresse
- Routenplanung der Strecke zum jeweiligen Objekt
- Adressenliste
- Objektliste
- Standortanalyse

Darüber hinaus bietet der Geo-Analyzer dem Benutzer Möglichkeiten zur Individualisierung des angezeigten Kartenmaterials.

3.6 FlowFact BI

FlowFact BI hat das Ziel Vertriebs- und Arbeitsprozesse mess- und auswertbar zu machen. Das Kürzel BI steht für Business Intelligence.

Hierbei wird Crystal Reports als Berichtsgenerator zum Erstellen von Berichtsvorlagen genutzt. Als Daten für die Reports dienen primär Aktivitäten, Adressen und Objekte.

Folgende selbsterklärende Berichtsvorlagen werden bei der Standardinstallation mit ausgeliefert:

- Adressliste nach Anlagezeitraum
- Adressliste nach PLZ Gebieten
- Aktivitätenbericht für Adressen
- Kaufanfragen
- Mietanfragen
- Gesamtübersicht über FlowFact Immobilien CRM
- Weitere

Zum erstellen weiterer Berichtsvorlagen benötigt der Anwender Kenntnisse in Crystal Reports. Außerdem muss er mit der Datenbanksprache SQL vertraut sein und den Aufbau der Datenbank kennen, um Abfragen erstellen zu können.

3.7 Management Cockpits

Mit Hilfe der Management Cockpits werden zuvor spezifizierte Kennzahlen tagesaktuell visualisiert. Zur Illustration werden Tachometer- und Tankanzeigen benutzt. Die Management Cockpits richten sich an die Unternehmensleitung, Vertriebsmitarbeiter oder auch an das Service-Team und dienen zur Optimierung der Entscheidungsfindung.

Die Kennzahlen lassen sich auf den Ebenen Unternehmen, Abteilung und Benutzer definieren. Als Kennzahlen sind beispielsweise die Anzahl aller aktiven Objekte in der Vermarktung, oder die Anzahl neuer Kontakte möglich.

3.8 Dashboards

Bei Dashboards handelt es sich um eine Visualisierung von Geschäftskennzahlen der Firma FlowFact selbst. In der Abteilung Help Desk, welche Kunden Support leistet, werden offene Supportanfragen und die durchschnittliche Zeit bis zur Lösung des Problems auf einem Monitor angezeigt. Demnach handelt es sich bei Dashboards der Firma FlowFact um eine Darstellung von periodisch ermittelten Kennzahlen auf einem Monitor, um kurzfristige Entwicklungen der Geschäftsprozesse erkennen zu können, so dass eine schnelle Reaktion erfolgen kann.

3.9 Vergleich von Reporting mit dem Reportingverständnis von FlowFact

Im Folgenden wird untersucht, in wie weit sich das Reporting im Sinne der Firma FlowFact mit dem klassischen Reportingbegriff deckt und in welchen Bereichen unterschiede erkennbar sind.

Bei der Portalseite handelt es sich eindeutig um ein Unternehmensportal (B2E- Portal), da sich die dort angezeigten Informationen direkt an die Mitarbeiter des Unternehmens richten.

Wie im Abschnitt 3.4 beschrieben, ist die Portalseite in das Programm integriert und wird nicht über einen Browser aufgerufen.

Da die Dashboards der Firma FlowFact zur Überwachung des Tagesgeschäfts eingesetzt werden und der Hauptzweck dem Monitoring dient, handelt es sich hierbei um operative Dashboards. Diese operativen Dashboards existieren als eigenständige Lösung und sind nicht in dem Softwareprodukt eingebettet.

Die in das Softwareprodukt integrierten Management Cockpits visualisieren lang- und kurzfristige Unternehmensziele. Daher handelt es sich dabei um strategische und taktische Dashboards. Die dargestellten Informationen werden wie beschrieben täglich aktualisiert.

Bei FlowFact BI handelt es sich um Reporting im klassischen Sinn. Da die Berichte nicht automatisch in bestimmten Zeitabständen generiert werden, sondern der Anwender die Generierung durch einen Klick starten muss, handelt es sich um ein passives Berichtssystem. Mit Hilfe eines Berichtsgenerators, welches zum Erstellen von Berichtsvorlagen zusätzlich installiert sein muss, legt der Berichtersteller eigenständig Berichtsform, Berichtsinhalt und Berichtszweck fest.

Eine automatisierte Brieferzeugung gehört nicht zu den im Abschnitt 2 dargestellten Reportingmöglichkeiten. Aufgrund der Einfachheit der darzustellenden Informationen wäre es aber möglich, einen Brief mit Hilfe eines Reportgenerators zu erstellen, wenn dieser als Ausgabeformat das Wordformat unterstützt. Die genauen Anforderungen an einen Berichtsgenerator, welche zum Erstellen eines Briefes nötig wären, werden an späterer Stelle spezifiziert.

Für die Excel-Anbindung gilt analog gleiches, wie für die Erstellung eines Briefes mit der Word-Anbindung.

Auch der Geo-Analyzer stimmt mit keiner im Abschnitt 3 beschriebenen Reportingmöglichkeit überein. Der hohe Funktionsumfang, wie beispielsweise die Berechnung einer Route, übersteigt bei weitem die Möglichkeiten eines Berichts.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Vergleich der Reportingmöglichkeiten in FlowFact mit Reporting

Tabelle 1 stellt die Ergebnisse der Zuordnung zusammengefasst dar. Integriert bedeutet hierbei, ob die Reportingmöglichkeit in das Softwareprodukt eingebunden sind und Aktualität beschreibt wie neuartig die anzuzeigenden Daten sind.

Bereits jetzt ist es möglich eine Abstraktion vorzunehmen. Da die Dashboards lediglich unterschiedliche Ausprägungen haben, werden diese allgemein als Dashboards bezeichnet. Die Word- und Excel-Anbindungen können als Reporting abstrahiert werden, wobei dann die Ausgabeformate unbedingt zu berücksichtigen sind.

Da der Geo-Analyzer aus der Menge der Reportingmöglichkeiten bereits ausgeschlossen wurde, wird dieser nicht weiter berücksichtigt. Demnach gibt es die Reportingmöglichkeiten B2E-Portal, Dashboards und Reporting (klassisch).

4 Anforderungen an eine allgemeine Reportinglösung und Auswahl eines Reportingtools

Ziel dieses Kapitels ist es, ein geeignetes Reportingtool ausfindig zu machen, so dass dessen Anforderungserfüllung im Rahmen der prototypischen Implementierung gezeigt werden kann. Abschnitt 4.1 klärt, wie Daten im Idealfall aus der Datenbank ausgelesen werden müssen. Daraufhin beschreibt Abschnitt 4.2 alle an das Reportingtool gestellten Anforderungen.

Abschnitt 4.3 stellt vier unterschiedliche Reportingtools mit ihrer jeweiligen Funktionsweise vor.

Abschließend wird mit Hilfe einer Nutzwertanalyse ein geeignetes Reportingtool ausgewählt.

4.1 Architekturbeschreibung des FlowFact eCRMs und Auswahl eines Kommunikationsweg für eine allgemeine Reportinglösung

Bevor im nächsten Abschnitt die Anforderungen an die allgemeine Reportinglösung gestellt werden können, bedarf es vorher einer genauen Betrachtung der Architektur des Programms FlowFact eCRM. Erst wenn die Funktionsweise dieser Servicearchitektur klar ist, kann man erläutern, an welcher Stelle das im Idealfall einheitliche Reportingsystem anzusiedeln ist. Wie bereits zuvor erwähnt, sollten die drei Reportingmöglichkeiten B2E-Portal, Dashboards und Reporting durch möglichst eine einzige technische Lösung in das eCRM abgebildet werden können.

Nachfolgende Abbildung stellt die Architektur schematisch dar:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Schematische Darstellung der Servicearchitektur

Wie in Abbildung 4 ersichtlich, gibt es drei Möglichkeiten an die Daten des Datenbankservers zu gelangen.

Der primitivste und unkomfortabelste Weg ist die Benutzung einer JDBCVerbindung. Dies hat den Nachteil, dass Anfragen auf die Datenbank schnell äußerst komplex werden und der Aufbau der Datenbank bekannt sein muss.

Hibernate ist ein Objekt/Relational Mapper (Vergleiche: [BauKin 2007]). Mit Hilfe eines Objekt/Relational Mapper können Objekte einer objekorientierten Programmiersprache auf einer relationalen Datenbank abgebildet werden. Mit Hilfe der Abfragesprache HQL, welche Bestandteil von Hibernate ist, hat man die Möglichkeit direkt auf Objekte zu zugreifen. Hibernate nutzt intern JDBC um an die Daten zu gelangen. Mittels Hibernate und HQL, könnte man demnach recht einfach an die Daten des Servers gelangen. Dies hat jedoch den Nachteil, dass Rechte nicht automatisch geprüft werden. Es müsste also in jedem HQL-Query kontrolliert werden, ob der auf dem Client angemeldete Benutzer die nötigen Rechte besitzt und die Daten empfangen darf.

Das Programm FlowFact eCRM verwendet intern Springservices um an die Daten zu gelangen. Dies ist der komfortabelste Weg, da über Services direkt Rechte prüfbar sind. Spring ist ein komplexes Framework und unterstützt unter anderem auch aspektorientierte Programmierung [WalBrei 2007].

Ein Client hat mit Hilfe dieser Services die Möglichkeit, Daten, für welche er die Berechtigung besitzt, anzufragen. Dafür greift Spring auf Hibernate zu. Eine allgemeine Reportinglösung müsste demnach die Springservices ansprechen können. Damit ist klar, dass die Reportinglösung clientseitig implementiert werden muss, da die Überprüfung der Rechte sonst nicht möglich wäre.

Ein einfacher Service wäre beispielsweise ein Service, welcher dem Client alle Informationen zu Adressen sendet, für welche der angemeldete Benutzer über Rechte verfügt. Ein komplexer Service könnte beispielsweise HQL-Querys entgegennehmen, um so an Daten zu gelangen, welche nicht durch die bereits vorhandenen Services zurückgeliefert werden. Ein weiterer Vorteil bei Nutzung der Serviceschnittstelle ist es, dass Services, welche Daten von Adressen, Objekten und Aktivitäten zurückliefern, bereits vorhanden sind.

4.2 Anforderungen an die Reportinglösung

Bevor in diesem Abschnitt die Anforderungen an eine einheitliche Reportinglösung detailliert dargestellt werden können, müssen noch einige weitere Wünsche der Firma an eine Lösung berücksichtigt werden.

Ein äußerst wichtiges Kriterium für die Auswahl einer Reportinglösung ist, dass diese plattformunabhängig ist. Des Weiteren sollten möglichst viele Ausgabeformate unterstützt werden. Die Gesamttechnologie für die Umsetzung eines Dashboards oder eines Portals muss nicht unbedingt gegeben sein, wenn die Technologie Eigenentwicklungen zulässt.

Da die Lösung langfristig in das bestehende Produkt integriert werden soll, ist es wichtig, dass diese robust und stabil läuft und der Kostenaufwand für Lizenzen und Schulungen niedrig ist.

Da Benutzer, welche Berichtsvorlagen erstellen, nicht unbedingt Informatiker sein müssen, sollten keine IT-Kenntnisse notwendig sein, um eine Vorlage zu erstellen. Als Entwicklungsumgebung für das eCRM wird Eclipse benutzt, so dass Konzepte aus dem Eclipse Umfeld genutzt werden können.

Zunächst werden Realisierungsvorgaben betrachtet. Diese Vorgaben sind KOKriterien für eine allgemeine Reportinglösung. Wenn ein Reportingtool ein oder mehrere dieser Vorgaben nicht erfüllt, so ist dieses nicht geeignet.

Realisierungsvorgaben:

Abbildung in dieser Leseprobe nicht enthalten

Die Realisierungsvorgaben „ Plattformunabhängigkeit “ und „ Zuverlässigkeit “ sind Vorgaben der Firma FlowFact. Alle restlichen sind Einschränkungen, welche meiner Meinung nach ebenfalls KO-Kriterien sind und somit zu der Kategorie Realisierungsvorgaben gehören. Die Vorgabe „ Integration in das eCRM möglich “ ist bewusst allgemein gehalten. Zum jetzigen Zeitpunkt kann diese Einschränkung nicht weiter aufgegliedert werden, da die für die Integration benötigten Schritte im direkten Zusammenhang mit dem eingesetzten Reportingtool stehen. Erst nachdem die Technologie des jeweiligen Tools betrachtet wurde, kann entschieden werden, ob sich diese in das eCRM integrieren lässt und welche Schritte dafür sinnvoll sind.

Im Folgenden werden alle bisher textuell beschriebenen Anforderungen detailliert und übersichtlich aufgelistet. Dabei werden die Anforderungen zielorientiert beschrieben, da dieses Vorgehen bei der Priorisierung von Anforderungen besonders gut geeignet ist. Die Zielorientierung vereinfacht außerdem die Identifikation alternativer Lösungen, da die Ziele dadurch einfacher zu bewerten sind [Pohl 2007]. Die Ziele werden durch einen eindeutigen Identifikator, einer dazugehörigen Beschreibung und einem Namen beschrieben. Des Weiteren sind die Ziele so formuliert, dass eine Zielerfüllung durch eine Reportinglösung prüfbar ist.

Als Gewicht werden subjektive natürliche Zahlen vergeben. Je höher diese Zahl ist, desto wichtiger ist das jeweilige Ziel für den Gesamterfolg der Reportinglösung. Die Ziele sind in der nachfolgenden Auflistung Oberkategorien zugeordnet.

Oberkategorie: Ausgabeformat

Abbildung in dieser Leseprobe nicht enthalten

[...]