Freie wissenschaftliche Arbeit zur Erlangung des ... - Thomas Thiele

Fachhochschule für Technik und Wirtschaft Berlin 

Freie wissenschaftliche Arbeit zur Erlangung des akademischen Grades 

Master of Science in Wirtschaftsinformatik 

Business Intelligence im Call Center mit 

Microsoft SQL Server 2005 

Masterthesis 

im Fachbereich Wirtschaftswissenschaften II 

im Studiengang Wirtschaftsinformatik 

der Fachhochschule für Technik und Wirtschaft Berlin 

vorgelegt von: 

Diplom-Wirtschaftsinformatiker (FH) Thomas Christian Thiele 

Buchfinkweg 43a 

12351 Berlin 

Matrikel-Nr.: 0318080 

Erstbetreuer: 

Zweitbetreuer: 

Prof. Dr. Reinhard Ginnold 

Prof. Dr. Thomas Pietsch 

Abgabetermin: 30.04.2007

Abstract - II - 

Abstract 

Durch die zunehmende Integration von Computersystemen in die Prozesse in Call Centern 

steht eine große Menge Daten zur Verfügung. Diese Daten werden im Rahmen des 

computergestützten Controllings verwendet, um die effiziente Nutzung der vorhandenen 

Ressourcen und die Aufrechterhaltung der Qualität zu gewährleisten. Das Controlling 

wird dabei von den Methoden der Business Intelligence unterstützt, die ein IT-basierter 

Gesamtansatz zur betrieblichen Entscheidungsunterstützung ist. 

In dieser Thesis wird ein Business Intelligence-Konzept für die Call Center der adm 

GmbH entwickelt und die Umsetzbarkeit des Konzepts mit dem Microsoft SQL Server 

2005 prototypisch untersucht. 

Dafür werden Grundlagen des Controllings und der in Call Centern involvierten Prozesse 

und Systeme erläutert. Es folgt die Vorstellung der anwendbaren Business 

Intelligence-Methoden. Eine Analyse der Ausgangslage und der bestehenden operativen 

Systeme dient als Grundlage für das im Anschluss entwickelte Konzept. Im Rahmen der 

dimensionalen Modellierung werden die Fakten und Dimensionen des Telefonie- 

Prozesses identifiziert. 

Bei der Umsetzung werden verschiedene Komponenten des SQL Server 2005 genutzt, 

um die einzelnen Phasen des Business Intelligence-Konzepts abzubilden. Der Server 

kann dabei alle Anforderungen erfüllen. Das Data Warehouse wird mit dem relationalen 

Datenbankserver, die ETL-Prozesse mit den Integration Services, das OLAP-System 

mit den Analysis Services und das Berichtswesen über die Reporting Services realisiert. 

Das Berichtswesen ist durch das umgesetzte Konzept schneller, flexibler und mit einer 

geringeren Fehleranfälligkeit möglich als mit den alten Berichts-Systemen.

Danksagung - III - 

Danksagung 

Ich danke Herrn Prof. Dr. Reinhard Ginnold für die gewohnt freundliche und erstklassige 

Betreuung während der Erstellung dieser Thesis sowie Herrn Prof. Dr. Thomas 

Pietsch für die Übernahme der Zweitbetreuung. 

Herrn Dr. Michael König gilt mein Dank für die Unterstützung seitens der adato GmbH 

und die Aufgeschlossenheit für neue Ideen. 

Weiterhin danke ich Herrn Dipl.-Winf. (FH) Markus Schechner für fachliche Diskussionen, 

Herrn Björn Grzywatz für die Einblicke in die operativen Systeme und Herrn 

Oktay Okur für die Bereitstellung und Vorbereitung benötigter Hardware- und 

Software-Ressourcen. Frau Brigitte Hanusch danke ich für die Ermöglichung des 

Drucks dieser Arbeit. 

Mein besonderer Dank gilt meiner Frau Daniela für ihr aufgebrachtes Verständnis und 

ihre Unterstützung. 

Schließlich möchte ich mich bei allen Korrekturlesern für ihre Akribie und ihre investierte 

Zeit herzlich bedanken.

Inhaltsverzeichnis - IV - 

Inhaltsverzeichnis 

Abstract.............................................................................................................................II 

Danksagung .....................................................................................................................III 

Inhaltsverzeichnis ........................................................................................................... IV 

Abbildungsverzeichnis ................................................................................................... VI 

Tabellenverzeichnis........................................................................................................ IX 

Abkürzungsverzeichnis ....................................................................................................X 

1 Einleitung......................................................................................................................1 

2 Controlling im Call Center ...........................................................................................3 

2.1 Controlling.............................................................................................................3 

2.2 Klassifizierung von Call Centern...........................................................................4 

2.2.1 Klassifizierung nach organisatorischer Zugehörigkeit.................................4 

2.2.2 Klassifizierung nach Richtung des Kommunikationsprozesses...................6 

2.2.3 Klassifizierung nach Kampagnentypen........................................................6 

2.3 Ziele des Controllings im Call Center ...................................................................7 

2.4 Kennzahlen im Call Center....................................................................................8 

2.5 Systeme im Call Center .......................................................................................10 

2.6 Zusammenfassung ...............................................................................................14 

3 Business Intelligence ..................................................................................................15 

3.1 Datenerfassung ....................................................................................................16 

3.1.1 Extraktionsphase ........................................................................................16 

3.1.2 Transformationsphase ................................................................................17 

3.1.3 Ladephase...................................................................................................19 

3.2 Datenhaltung........................................................................................................19 

3.2.1 Data Warehouse-Systeme ..........................................................................20 

3.2.2 Dimensionale Modellierung.......................................................................20 

3.3 Datenbereitstellung..............................................................................................25 

3.3.1 Online Analytical Processing.....................................................................25 

3.3.2 Berichtswesen.............................................................................................29 

3.3.3 Weitere Elemente der Datenbereitstellung.................................................29 


4 Ausgangssituation.......................................................................................................31 

4.1 Aufbauorganisation..............................................................................................31 

4.2 Operative Systeme ...............................................................................................32 

4.2.1 Telefonie-Systeme......................................................................................33 

4.2.2 Datenbanken...............................................................................................34 

4.2.3 Benutzeroberflächen...................................................................................35 

4.2.4 Personalsysteme .........................................................................................36 

4.3 Bisheriges Berichtswesen ....................................................................................36 


5 Sollkonzeption ............................................................................................................40 

5.1 Definition der geschäftlichen Anforderungen .....................................................40 

5.1.1 Identifizierte Analyseziele..........................................................................42 

5.1.2 Beteiligte Prozesse und Geschäftsobjekte..................................................43

Inhaltsverzeichnis - V - 

5.1.3 Ergebnisse der ersten Datenanalyse ...........................................................43 

5.2 Design des dimensionalen Modells .....................................................................44 

5.2.1 Auswahl der Prozesse und der Granularität ...............................................48 

5.2.2 Fakten der Prozesse....................................................................................49 

5.2.3 Modellierung der Dimensionen..................................................................53 

5.3 Spezifikation der BI-Applikation ........................................................................57 

5.3.1 Festlegen von Standards.............................................................................59 

5.3.2 Ermittlung und Spezifikation der Zielberichte...........................................60 


6 Umsetzung mit Microsoft SQL Server 2005 ..............................................................65 

6.1 Physisches Design ...............................................................................................65 

6.2 Design und Entwicklung der ETL-Prozesse........................................................67 

6.3 OLAP-Design in Analysis Services.....................................................................72 

6.4 Entwicklung der Berichte in Reporting Services.................................................75 


7 Ergebnisse und Ausblick ............................................................................................78 

Literaturverzeichnis........................................................................................................ XI 

Anhang .........................................................................................................................XVI 

A Datenstruktur der Quellsysteme .......................................................................XVI 

B Integration Services-Pakete ..............................................................................XXI 

C Reporting Services-Berichte.................................................................... XXXVIII 

Abschließende Erklärung .......................................................................................... XLIII

Abbildungsverzeichnis - VI - 

Abbildungsverzeichnis 

Abb. 1 Controlling als Zusammenspiel von Planung, Kontrolle und Steuerung .......3 

Abb. 2 Aufteilung der Agentenarbeitszeit..................................................................9 

Abb. 3 Business Intelligence-Ordnungsrahmen .......................................................15 

Abb. 4 Dimensionale Modellierung mit einem Sternschema...................................21 

Abb. 5 Multifakten-Schema .....................................................................................22 

Abb. 6 Fact-Constellation-Schema...........................................................................23 

Abb. 7 Hierarchisierung in einer Regionen-Dimension ...........................................23 

Abb. 8 Abbildung der Hierarchie innerhalb der Dimensionstabelle ........................24 

Abb. 9 OLAP-Navigationsfunktionen Drill-down und Roll-up...............................27 

Abb. 10 OLAP-Navigationsfunktion Slicing .............................................................27 

Abb. 11 OLAP-Navigationsfunktion Dicing..............................................................28 

Abb. 12 Ausschnitt aus der Aufbauorganisation........................................................32 

Abb. 13 Architektur des Dialer-Systems....................................................................33 

Abb. 14 Beispiel einer Benutzeroberfläche für Telefonagenten ................................35 

Abb. 15 Auswertung der Agentenzeiten im Vocalcom-System.................................37 

Abb. 16 Auswertung der Agentenzeiten in adato.Reports.........................................38 

Abb. 17 Business Dimensional Lifecycle – Konzeption............................................40 

Abb. 18 Ausschnitt eines Modellierungs-Arbeitsblatts..............................................46 

Abb. 19 Grobes grafisches Modell des Prozesses Telefonie......................................48 

Abb. 20 Grobes grafisches Modell der Planung.........................................................49 

Abb. 21 Berichts-Standardvorlage .............................................................................60 

Abb. 22 Business Dimensional Lifecycle – Umsetzung ............................................65 

Abb. 23 Relationen im Data Warehouse ....................................................................66 

Abb. 24 Physisches Datenmodell ...............................................................................66 

Abb. 25 Relationen in der Konfigurationsdatenbank CONFIG .................................67 

Abb. 26 Relationen in der Historisierungsdatenbank HISTORY................................68 

Abb. 27 Relationen und Sichten in der Staging Area.................................................68 

Abb. 28 SSIS Master-Paket........................................................................................69 

Abb. 29 Dimensionsverwendung im OLAP-System..................................................72 

Abb. 30 Definition der berechneten Fakten ...............................................................73 

Abb. 31 Hierarchisierung der Standort-Dimension....................................................73 

Abb. 32 Hierarchisierung der Projekt-Dimension......................................................74 

Abb. 33 Hierarchisierung der Datums-Dimension.....................................................74 

Abb. 34 Einschränkung der Fakten auf Bedingungen................................................75 

Abb. 35 MDX-Datendefinition in den Reporting Services ........................................76 

Abb. 36 Berichtsansicht im Web-Browser.................................................................76

Abbildungsverzeichnis - VII - 

Abb. 37 

Abb. 38 

Abb. 39 

Abb. 40 

Abb. 41 

Abb. 42 

Abb. 43 

Abb. 44 

Abb. 45 

Abb. 46 

Abb. 47 

Abb. 48 

Abb. 49 

Abb. 50 

Abb. 51 

Abb. 52 

Abb. 53 

Abb. 54 

Abb. 55 

Abb. 56 

Abb. 57 

Abb. 58 

Abb. 59 

Abb. 60 

Abb. 61 

Abb. 62 

Abb. 63 

Abb. 64 

Abb. 65 

Abb. 66 

Abb. 67 

Abb. 68 

Abb. 69 

Abb. 70 

Abb. 71 

Abb. 72 

Abb. 73 

Abb. 74 

SSIS-Paket Prep_Datum – Kontrollfluss...................................................XXI 

SSIS-Paket Prep_Kosten – Kontrollfluss ..................................................XXI 

SSIS-Paket Prep_Kosten – Datenfluss ......................................................XXI 

SSIS-Paket Hist_Aktionen – Kontrollfluss ............................................. XXII 

SSIS-Paket Hist_Aktionen – Datenfluss ................................................. XXII 

SSIS-Paket Hist_Logins – Kontrollfluss ................................................. XXII 

SSIS-Paket Hist_Logins – Datenfluss 1 .................................................XXIII 

SSIS-Paket Hist_Logins – Datenfluss 2 .................................................XXIV 

SSIS-Paket Hist_Projektleiter – Kontrollfluss .......................................XXIV 

SSIS-Paket Hist_Projektleiter – Datenfluss ............................................XXV 

SSIS-Paket Hist_Toleranzen – Kontrollfluss ..........................................XXV 

SSIS-Paket Hist_Toleranzen – Datenfluss ..............................................XXV 

SSIS-Paket Staging_Logins – Kontrollfluss............................................XXV 

SSIS-Paket Staging_Logins – Datenfluss...............................................XXVI 

SSIS-Paket Staging_Projektleiter – Kontrollfluss..................................XXVI 

SSIS-Paket Staging_Projektleiter – Datenfluss......................................XXVI 

SSIS-Paket Staging_Toleranzen – Kontrollfluss....................................XXVI 

SSIS-Paket Staging_Toleranzen – Datenfluss...................................... XXVII 

SSIS-Paket Staging_Aktionen – Kontrollfluss..................................... XXVII 

SSIS-Paket Staging_Aktionen – Datenfluss 1...................................... XXVII 

SSIS-Paket Staging_Aktionen – Datenfluss 2.....................................XXVIII 

SSIS-Paket Dim_Projekt – Kontrollfluss ............................................XXVIII 

SSIS-Paket Dim_Projekt – Datenfluss ................................................XXVIII 

SSIS-Paket Dim_Standort – Kontrollfluss ..........................................XXVIII 

SSIS-Paket Dim_Standort – Datenfluss .................................................XXIX 

SSIS-Paket Dim_Projektleiter – Kontrollfluss .......................................XXIX 

SSIS-Paket Dim_Projektleiter – Datenfluss ...........................................XXIX 

SSIS-Paket Dim_Telefonagent – Kontrollfluss......................................XXIX 

SSIS-Paket Dim_Telefonagent – Datenfluss...........................................XXX 

SSIS-Paket Dim_Datum – Kontrollfluss.................................................XXX 

SSIS-Paket Dim_Datum – Datenfluss..................................................... XXX 

SSIS-Paket Facts_Telefonie – Kontrollfluss ..........................................XXXI 

SSIS-Paket Facts_Telefonie – Datenfluss 1 ......................................... XXXII 

SSIS-Paket Facts_Telefonie – Datenfluss 2 ......................................... XXXII 

SSIS-Paket Facts_Telefonie – Datenfluss 3 ........................................XXXIII 

SSIS-Paket Facts_Telefonie – Datenfluss 4 ........................................XXXIII 

SSIS-Paket Facts_Telefonie – Datenfluss 5 ........................................XXXIV 

SSIS-Paket Facts_Telefonie – Datenfluss 6 ........................................XXXIV

Abbildungsverzeichnis - VIII - 

Abb. 75 

Abb. 76 

Abb. 77 

Abb. 78 

Abb. 79 

Abb. 80 

Abb. 81 

Abb. 82 

Abb. 83 

Abb. 84 

Abb. 85 

Abb. 86 

Abb. 87 

Abb. 88 

Abb. 89 

Abb. 90 

Abb. 91 

Abb. 92 

Abb. 93 

SSIS-Paket Facts_Telefonie – Datenfluss 7 ........................................XXXIV 

SSIS-Paket Facts_Telefonie – Datenfluss 8 ......................................... XXXV 

SSIS-Paket Facts_Telefonie – Datenfluss 9 ......................................... XXXV 

SSIS-Paket Facts_Telefonie – Datenfluss 10 ......................................XXXVI 



SSIS-Paket Facts_Planung – Kontrollfluss ....................................... XXXVII 

SSIS-Paket Facts_Planung – Datenfluss ........................................... XXXVII 

SSIS-Paket AS_Processing – Kontrollfluss ...................................... XXXVII 

SSRS-Bericht Gesamtübersicht........................................................ XXXVIII 

SSRS-Bericht Projektleistung am Standort ...................................... XXXVIII 

SSRS-Bericht Agentenleistung pro Projekt.........................................XXXIX 

SSRS-Bericht Supervisions-Auswertung ............................................XXXIX 

SSRS-Bericht Arbeitszeitauswertung......................................................... XL 

SSRS-Bericht Projektübergreifende Agentendetails .................................. XL 

SSRS-Bericht Branchen- und Kunden-Übersicht......................................XLI 

SSRS-Bericht Projektleiter-Auswertung ...................................................XLI 

SSRS-Bericht CEO-Cockpit.....................................................................XLII 

SSRS-Bericht Low Performer ..................................................................XLII

Tabellenverzeichnis - IX - 

Tabellenverzeichnis 

Tab. 1 Vor- und Nachteile von internen und externen Call Centern .........................5 

Tab. 2 Mängelklassifikation im Rahmen der Bereinigung......................................17 

Tab. 3 Bus Matrix ....................................................................................................43 

Tab. 4 Mögliche Beteiligte am dimensionalen Modellierungsprozess....................45 

Tab. 5 Attribute der Datums-Dimension .................................................................54 

Tab. 6 Attribute der Standort-Dimension ................................................................55 

Tab. 7 Attribute der Projekt-Dimension ..................................................................55 

Tab. 8 Attribute der Telefonagent-Dimension.........................................................56 

Tab. 9 Attribute der Projektleiter-Dimension ..........................................................56 

Tab. 10 Liste der Berichtskandidaten ........................................................................61 

Tab. 11 Die Struktur der Call File-Relationen ..................................................... XVII 

Tab. 12 Eine typische Client File-Relation .......................................................... XVII 

Tab. 13 Die Relation ODActions.........................................................................XVIII 

Tab. 14 Die Relation ODCalls................................................................................XIX 

Tab. 15 Kosten-Relation ..........................................................................................XX

Abkürzungsverzeichnis - X - 

Abkürzungsverzeichnis 

ACD 

BI 

CTI 

EIS 

ETL 

FASMI 

HOLAP 

IIS 

IVR 

MDX 

MIS 

MOLAP 

OLAP 

OLTP 

PBX 

ROLAP 

SCD 

SOAP 

SQL 

SSAS 

SSIS 

SSRS 

VoIP 

Automatic Call Distribution 

Business Intelligence 

Computer Telephony Integration 

Executive Information Systems 

Extraktion, Transformation, Laden 

Fast Analysis of Shared Multidimensional Information 

Hybrides OLAP 

Internet Information Services 

Interactive Voice Response 

Multidimensional Expressions 

Management Information Systems 

Multidimensionales OLAP 

Online Analytical Processing 

Online Transaction Processing 

Private Branch Exchange 

Relationales OLAP 

Slowly Changing Dimension 

Simple Object Access Protocol 

Structured Query Language 

SQL Server Analysis Services 

SQL Server Integration Services 

SQL Server Reporting Services 

Voice over IP

1. Einleitung - 1 - 

1 Einleitung 

Mit fortschreitender Integration von Computersystemen in die Arbeitsvorgänge in Call 

Centern wird ein Controlling möglich, das zu Zeiten einfacher Telefonanlagen und Datenerfassung 

auf dem Papier schwer realisierbar oder nur mit Zeitverzug möglich war. 

Dieses Controlling zu verbessern wird immer notwendiger, denn die Anzahl der abgewickelten 

Gespräche nimmt ständig zu. Auch der Konkurrenzdruck durch ausländische Anbieter 

steigt stetig, da diese mit sprachgeschulten günstigen Arbeitskräften in den Markt 

drängen. 

Da die Personalkosten mit bis zu 70% den größten Anteil der Kosten eines Call Center- 

Betriebs ausmachen, fallen die höheren Lohnkosten in Deutschland besonders ins Gewicht. 

Um sich von der Konkurrenz abzuheben, bleiben nur die Fokussierung auf Qualität und 

eine effiziente Ausnutzung der vorhandenen Ressourcen. Bei beidem unterstützt das computergestützte 

Controlling. 

Die große Menge an Daten, die im Call Center-Betrieb anfällt, muss möglichst aktuell aufbereitet 

dem Controlling zur Verfügung gestellt werden. Hier bietet sich der Einsatz von 

Business Intelligence-Lösungen an. Unternehmen, die Business Intelligence-Lösungen 

einsetzen, erzielen im Durchschnitt eine höhere Umsatzrendite und weisen eine positivere 

Personalentwicklung auf, als Firmen ohne vergleichbare Lösungen. 1 

Das Ziel dieser Thesis ist die Erstellung eines Business Intelligence-Konzepts für die 

Outbound-Telefonie 2 der adm GmbH und die prototypische Umsetzung eines Teilbereichs 

dieses Konzepts. 

Zur Umsetzung wird der Microsoft SQL Server benutzt, der laut Hersteller in der 2005er- 

Version alle Komponenten beinhalten soll, die zum Aufbau einer Business Intelligence- 

Lösung benötigt werden. 3 

Da der SQL Server in vielen Unternehmen bereits als Datenbank-Server im Einsatz ist, 

bietet es sich an, zu untersuchen, ob alle Anforderungen des zu erarbeitenden Konzepts 

umsetzbar sind, ohne in weitere Software zu investieren. 

Alle benötigten Schritte des Konzepts, die Datenerfassung, die Datenhaltung und die Datenbereitstellung, 

sollen dabei mit SQL Server-Komponenten umgesetzt werden. 

1 

2 

3 

Vgl. REPP2007, S. 45 

Outbound bezeichnet Gespräche, die vom Call Center nach außen geführt werden. Vgl. Kapitel 2.2.2. 

Vgl. MCKN2006, S. 4

1. Einleitung - 2 - 

In Kapitel 2 werden Besonderheiten des Controllings im Call Center dargestellt. Dazu erfolgt 

ein Überblick über verschiedene Call Center-Typen und die unterschiedlichen Aufgaben 

und Prozesse. Die Ziele und die typischen Kennzahlen des Controllings im Call Center 

werden erläutert und die am Telefonie-Prozess beteiligten Systeme werden vorgestellt. 

Kapitel 3 gibt einen Überblick über die Grundzüge der Business Intelligence, mit besonderem 

Fokus auf die für die Durchführung der Thesis benötigten Verfahren und Technologien. 

Kapitel 4 stellt die bisherige Situation des Controllings in der adm GmbH vor und gibt 

einen Einblick in die operativen Systeme. 

In Kapitel 5 wird das neue Business Intelligence-Konzept für die Outbound-Telefonie der 

adm GmbH entwickelt. Das Konzept orientiert sich am Business Dimensional Lifecycle- 

Modell von Kimball. 

Kapitel 6 zeigt die prototypische Umsetzung des erarbeiteten Konzepts mit den Komponenten 

des Microsoft SQL Server 2005. 

Im abschließenden Kapitel 7 werden die Ergebnisse der Thesis zusammengefasst und es 

erfolgt ein Ausblick auf die zukünftige Entwicklung.

2. Controlling im Call Center - 3 - 

2 Controlling im Call Center 

Controlling ist im Call Center-Sektor ein gefragtes Thema: 67 Prozent der im Rahmen der 

jährlich durchgeführten Callcenter-Trendstudie befragten Manager wollten sich 2006 intensiv 

mit Controlling auseinandersetzen. 4 

Um die Besonderheiten des Controllings und des Berichtswesens im Call Center-Bereich 

zu verdeutlichen, wird in diesem Kapitel kurz auf den Controlling-Begriff im Allgemeinen 

eingegangen sowie eine Klassifizierung von Call Centern vorgenommen. Es wird erläutert, 

welche Ziele das Controlling im Call Center verfolgt und an welchen Kennzahlen diese 

Ziele messbar sind. Weiterhin werden die typischen Prozesse und Systeme, die die Kennzahlen 

liefern, vorgestellt. 

2.1 Controlling 

Das Controlling ist ein Instrument zur Steuerung von Unternehmen. Es werden Daten aufbereitet 

und analysiert, um Zielüberprüfungen durchzuführen und die Planung, die Kontrolle 

und die Steuerung des Unternehmens zu ermöglichen (vgl. Abb. 1). 5 

Abb. 1 Controlling als Zusammenspiel von Planung, Kontrolle und Steuerung 

(Quelle: Vgl. Schümann, F.; Tisson, H.: Call Center Controlling. – Wiesbaden (Gabler), 

2006. S. 47) 

Es kann eine Unterscheidung von operativem Controlling und strategischem Controlling 

vorgenommen werden. Beim operativen Controlling geht es um die Betrachtung der 

taktischen und operativen Planung – im Mittelpunkt stehen „Entwicklungen, die sich bereits 

in der Gegenwart durch Aufwand und Ertrag manifestieren“. 6 

4 

5 

6 

Vgl. BUSC2006, S. 40 

Vgl. SCHÜ2006, S. 47 und WEBE2004, S. 311ff 

HORV2006, S. 235f


Beim strategischen Controlling werden langfristige und grundlegende Ziele der Unternehmensführung 

betrachtet. Im Mittelpunkt stehen „Entwicklungen, die sich durch Chancen 

und Risiken als Erfolgspotentiale umschreiben lassen“. 7 

Es ist erforderlich, strategisches und operatives Controlling zu verzahnen, so dass die strategische 

Führung die operative beeinflusst und die Konsequenzen operativer Entscheidungen 

auf Strategien sichtbar werden. 8 

Ohne den Einsatz von computergestützten Informationssystemen ist die Erfüllung von 

Controllingaufgaben heute nicht mehr möglich. Die Qualität der Informationsversorgung, 

und damit der Planung und Kontrolle, wird durch moderne Informationssysteme verbessert 

und die Controllingaufgaben werden erleichtert. 9 

2.2 Klassifizierung von Call Centern 

Call Center können nach verschiedenen Kriterien klassifiziert werden. Üblich ist eine organisatorische 

Unterscheidung von internen Call Centern und externen Call Center- 

Dienstleistern. Weiterhin üblich ist eine Unterscheidung anhand der Kommunikationsrichtung 

und der Kampagnentypen. 

2.2.1 Klassifizierung nach organisatorischer Zugehörigkeit 

Ein Inhouse-Call Center ist eine eigene Organisationseinheit in einem Unternehmen, die in 

die Gesamtorganisation eingebunden ist. 10 

Im Inhouse-Call Center sind die betriebswirtschaftlichen Abläufe in den telefonischen 

Kundenkontakt integriert, so dass die Telefonagenten direkt auf die Kundenverwaltungssoftware 

oder die Warenwirtschaftssysteme zugreifen können. Die Fachabteilungen haben 

nur koordinierend mit dem Kundenkontakt zu tun bzw. agieren in schwierigen Fällen als 

Ansprechpartner. 11 

Die Gründe für den Einsatz eines Inhouse-Call Centers sind die oftmals besseren Kenntnisse 

der Telefonagenten, der vorsichtige Umgang mit sensiblen Kunden- und Produktdaten 

7 

8 

9 

10 

11 

HORV2006, S. 236 

Vgl. HORV2006, S. 236 

Vgl. HORV2006, S. 659 

Vgl. PAFF2002, S. 16 

Vgl. PAFF2002, S. 16


sowie die Möglichkeit, positive Effekte beim Produktmanagement oder der Qualitätssicherung 

zu erzielen (vgl. Tab. 1). 12 

Internes Call 

Center 

Call Center- 

Dienstleister 

Vorteil 

• Kundendaten und Wissen bleiben 

im Unternehmen 

• Komplexere Anfragen können detailliert 

und schnell beantwortet 

werden 

• Kein zusätzliches Personal notwendig 

• Keine Investition in Technik und 

Fortbildung nötig 

• Dienstleister haben meist modernste 

Technik 

• Genaue Kostenkalkulation möglich 

Nachteil 

• Investitionen in Personal und 

Technik nötig 

• Laufende Kosten für Schulungen 

und Weiterbildungen 

• Hoher Fixkostenanteil / hohe Anforderung 

an die Personaleinsatzplanung 

• Abhängigkeit von externem 

Dienstleister 

• Beantwortung und Weiterleitung 

schwieriger Fragen u.U. nicht möglich 

• Fehlende Identifikation der Mitarbeiter 

mit dem Auftraggeber 

Tab. 1 Vor- und Nachteile von internen und externen Call Centern 

(Quelle: Vgl. Paff, C.: Call Center und ihre Standortanforderungen. Eine empirische Untersuchung 

des Standortes Hannover. Diplomarbeit an der Universität Hannover, 2002. S. 

19) 

Unternehmensinterne Call Center wickeln fast ausschließlich eingehende Anrufe ab und 

sind im Service- und Kundendienstbereich angesiedelt. Aufgrund der hohen Initialkosten 

beim Aufbau eines Call Centers durch Technik und Telefonagenten, lohnt der Aufbau eines 

internen Call Centers erst ab einem gewissen Anrufvolumen. 13 

Die Anzahl der an externe Call Center-Dienstleister vergebenen Projekte nimmt stetig zu. 14 

Viele Firmen lagern ihre kompletten Call Center-Aufgaben bzw. einzelne Call Center- 

Projekte aus. Bei der kompletten Auslagerung ergeben sich für die beauftragende Firma 

vor allem Kostenvorteile. Kosten entstehen nur für tatsächlich erbrachte Leistung und nicht 

als Fixkosten für Personal und Technik. Der Dienstleister setzt sein Personal bedarfsgerecht 

und flexibel ein und kann die gleiche Technik für verschiedene Kunden verwenden. 15 

Beim Teil-Outsourcing sind verschiedene Anwendungsfälle vorstellbar. So werden beispielsweise 

klar eingrenzbare und zeitlich limitierte Projekte ausgelagert, für die kein spezielles 

Fachwissen nötig ist. Weiterhin denkbar sind kapazitätsbedingte Auslagerungen, 

um Lastspitzen zu bewältigen, oder zeitabhängige Auslagerungen, um z.B. außerhalb der 

12 

13 

14 

15 

Vgl. PAFF2002, S. 16 

Vgl. PAFF2002, S. 17 

Vgl. BUSC2006, S. 20 

Vgl. PAFF2002, S. 17f


Büroöffnungszeiten erreichbar zu sein. Einige Firmen lagern auch ihre Telefonzentrale 

aus. 16 

2.2.2 Klassifizierung nach Richtung des Kommunikationsprozesses 

Inbound-Telefonie bezeichnet eingehende Gespräche – der Kunde ruft das Call Center an. 

Eine Gruppe von Telefonagenten wartet auf Anrufe von Kunden und nimmt diese entgegen. 

Meist handelt es sich um langfristig angelegte Leistungen, wie Bestellannahmen oder 

Kundendienst. Es gibt allerdings auch kurzfristige Projekte, die z.B. im Rahmen einer Produkteinführung 

oder in Zusammenhang mit klassischer Werbung realisiert werden. 17 

Outbound-Telefonie bezeichnet ausgehende Gespräche – das Call Center kontaktiert den 

Kunden aktiv. Hierbei handelt es sich zumeist um kurzfristige Projekte, bei denen eine 

definierte Teilmenge von Kunden befragt bzw. zu einer Bestellung o.ä. bewegt werden 

soll. Eine weitere Form der Outbound-Telefonie sind vom Kunden gewünschte Rückrufe, 

die z.B. in einem Formular übermittelt wurden. 18 

Es gibt sowohl reine Inbound-Call Center, reine Outbound-Call Center als auch Call Center, 

die beides leisten. Die reinen Outbound- und Misch-Call Center sind oft Dienstleister, 

die für einen oder mehrere externe Kunden tätig sind. Reine Inbound-Call Center finden 

sich häufig in den eigentlichen Unternehmen. 

2.2.3 Klassifizierung nach Kampagnentypen 

Baumgartner und Ugris identifizieren mittels Cluster-Analysen vier unterschiedliche 

Kampagnentypen in Call Centern 19 : 

• Beratungs- und Beschwerdemanagement 

• Informationsmanagement 

• Auftragsmanagement 

• Kunden- und Kampagnenmanagement 

16 

17 

18 

19 

Vgl. PAFF2002, S. 18 

Vgl. HELB2004, S. 4f und PAFF2002, S. 19f 

Vgl. BAUM2005, S. 2 und HELB2004, S. 6f 

Vgl. BAUM2005, S. 2ff


Beim Beratungs- und Beschwerdemanagement handelt es sich fast ausschließlich um Inbound-Kampagnen. 

Projektinhalte sind z.B. Telefonberatungen, Produkt-Hotlines und das 

Reklamations- und Beschwerdemanagement. 20 

Das Informationsmanagement umfasst einfache Aufgaben, wie beispielsweise Adressänderungen, 

Übermittlung von Zählerständen und die Entgegennahme und Weiterleitung von 

Gesprächen. Auch in diesem Segment werden fast ausschließlich Inbound-Telefonate geführt. 

21 

Beim Auftragsmanagement werden Bestellungen und Buchungen entgegengenommen. 

Auch hier finden hauptsächlich Inbound-Gespräche statt. 22 

Das Kunden- und Kampagnenmanagement umfasst Projekte, die auf das aktive Kundenmanagement 

zielen. Das sind unter anderem die Kündigerrückgewinnung, die aktive Kundenbetreuung 

oder zeitlich beschränkte Kampagnen, wie z.B. der Verkauf von Zusatzprodukten. 

In diesem Segment werden fast ausschließlich Outbound-Telefonate geführt. 23 

2.3 Ziele des Controllings im Call Center 

Der Großteil der Kosten im Call Center-Betrieb entsteht im Personalbereich. Insgesamt 

sind die Personalkosten für ca. 50 - 70% der Gesamtkosten verantwortlich. 24 Daraus ergibt 

sich die besondere Bedeutung des Controllings der Personalkosten – und damit der Arbeits- 

und Produktivzeiten. 

Neben dem Controlling der Kosten und der erzielten Umsätze sind der zählbare Erfolg und 

die Qualität der durchgeführten Kampagnen besonders wichtig. Gerade externe Call Center-Dienstleister 

sind von zufriedenen Auftraggebern abhängig, um laufende Verträge zu 

behalten und neue Aufträge zu bekommen. 

In einem Call Center spielt sowohl das strategische als auch das operative Controlling eine 

Rolle. Strategisch und taktisch geht es um das Controlling von einzelnen Projekten, Branchen 

und Standorten, um Schwerpunkte für die Zukunft zu planen und eventuelle Betriebsvergrößerungen, 

Betriebsverkleinerungen oder sogar das Eröffnen von zusätzlichen 

Standorten zu evaluieren. 

20 

21 

22 

23 

24 

Vgl. BAUM2005, S. 3 




Vgl. REIN2005, S. 40, GREF2003, S. 40 und TEWS2001, S. 49


Durch das finanzielle Controlling der Projekte können lukrative Projekte identifiziert werden, 

um das Auftragsvolumen zu erhöhen. Hierbei empfiehlt sich, auch die Projektleistung 

aus Sicht des Auftraggebers zu beurteilen. Analog dazu müssen Projekte mit schlechtem 

Deckungsbeitrag frühzeitig identifiziert werden, um nach den Ursachen zu suchen bzw. um 

die Konditionen beim Auftraggeber zu verbessern. 

Eine wichtige Aufgabe des operativen Controllings im Call Center ist das Controlling der 

Leistung der einzelnen Telefonagenten. Durch die Interaktion mit den Computersystemen 

lässt sich fast jede Telefonagenten-Aktion und deren Dauer festhalten. Dadurch ist eine 

gezielte Förderung der einzelnen Mitarbeiter möglich. Leistungsträger können gelobt, motiviert 

und als Multiplikatoren für den Rest der Gruppe eingesetzt werden. Telefonagenten 

mit schlechter Leistung können geschult und gecoacht werden. Auch bei Entlassungen 

spielen die ermittelten Werte eine Rolle. Die lückenlose Erfassung der Kennzahlen und 

deren Verlauf lässt es zu, mit den Telefonagenten Zielvereinbarungen zu treffen, die für 

eventuelle Vertragsverlängerungen oder Beförderungen relevant sind. 

Das Controlling hilft ebenso bei der Personaleinsatz-Planung und der Identifikation von 

technischen Schwächen oder Adressschwächen. 25 

2.4 Kennzahlen im Call Center 

Durch den hohen Technikeinsatz im Call Center stehen viele Kennzahlen zur Verfügung. 

Diese Kennzahlen lassen sich in allgemeine Projektkennzahlen, zeitbezogene Kennzahlen, 

quantitative Kennzahlen, monetäre Kennzahlen und Qualitätskennzahlen unterscheiden. 

Allgemeine Kennzahlen der Projekte sind die Gesamtanzahl der Datensätze in einer Kampagne 

und die Anzahl der bereits angerufenen Datensätze. 

Die für eine Steuerung der Kosten besonders relevanten Kennzahlen sind jene, die die Zeit 

betreffen. Wie Abb. 2 verdeutlicht, setzt sich die Brutto-Arbeitszeit der Telefonagenten aus 

mehreren Teilen zusammen. Neben der Netto-Arbeitszeit enthält sie Zeiten für Urlaub, 

Krankheit, Erholungspausen und Fortbildungen. Die Netto-Arbeitszeit lässt sich wiederum 

zerlegen in Produktivzeit, Wartezeit und Rüstzeit. Die Wartezeit ist die Zeit, die ein Agent 

damit verbringt, auf Anrufe zu warten. Die Rüstzeit stellt die Vor- und Nachbereitungszeit 

dar, die ein Agent zum Einrichten seines Arbeitsplatzes und ähnlichen Tätigkeiten benö- 

25 

Von Adressschwächen wird geredet, wenn die Erreichbarkeit der anzurufenden Kunden deutlich unter 

dem Durchschnitt liegt. Gründe können z.B. fehlerhafte oder besonders alte Datensätze sein.


tigt. Die Produktivzeit lässt sich weiter zerteilen in die Gesprächszeit und die Nacharbeitszeit. 

26 

Abb. 2 Aufteilung der Agentenarbeitszeit 

(Quelle: Vgl. von Arx, C.; Huber, M.: Analyse eines Callcenters. Diplomarbeit an der Zürcher 

Hochschule Winterthur, 2004, S. 79) 

Ein zentraler Wert in der Outbound-Telefonie ist der Nettokontakt. Der Nettokontakt ist 

ein terminiertes Gespräch mit dem Ansprechpartner. Die Ausprägung des Gesprächs, das 

heißt ein im Sinne des Projektzieles positiver oder negativer Ausgang, ist hierbei noch 

nicht relevant. Ein Abschluss stellt hingegen immer ein positives Telefonat dar. In manchen 

Situationen können mehrere Verkäufe pro Telefonat abgeschlossen werden. Daher 

kann die Anzahl der Verkäufe ebenso erfasst sein wie die Anzahl der Positivergebnisse. 

Durch Division der Ergebnisse und der Verkäufe mit den Nettokontakten ergeben sich die 

Erfolgsquoten. 27 

Die wichtigsten Kennzahlen im monetären Bereich sind der Umsatz, die Kosten und der 

Deckungsbeitrag. Der Umsatz kann je nach Projekt unterschiedlich berechnet werden. Die 

variablen Kosten ergeben sich aus den Stundenkosten der Telefonagenten. Der Deckungsbeitrag 

I ist die Differenz zwischen Umsatz und variablen Kosten. 28 

Im Inbound-Bereich ist der Service Level eine der bedeutendsten Kennzahlen. Der Service 

Level gibt an, wie viel Prozent der Anrufe in einer vorgegebenen Zeit angenommen werden 

müssen. Der Service Level wird mit dem Auftraggeber vor dem Projektstart vereinbart 

und kann stark variieren. Ein Service Level von 80/20 gibt an, dass 80% der ankommenden 

Anrufe innerhalb von 20 Sekunden angenommen werden müssen. Für das Call Center- 

Management liegt die Herausforderung darin, diesen Service Level möglichst genau einzuhalten 

und nicht zu unterschreiten. Eine zu starke Übererfüllung empfiehlt sich jedoch 

aus Effizienzgründen ebenfalls nicht. 29 

26 

27 

28 

29 

Vgl. VARX2004, S. 78f 

Vgl. PRAC2005, S. 61 

Vgl. SCHÜ2006, S. 115ff 

Vgl. BÖSE1999, S. 211


Neben den angebotenen und den angenommenen Anrufen können auch Abbrüche vorkommen, 

wenn ein Kunde während seines Aufenthaltes in der Warteschlange auflegt. 

In vielen Projekten ist die Quote der fallabschließenden Bearbeitung sehr wichtig. Aus 

einem hohen Service Level allein lässt sich nicht feststellen, ob den anrufenden Kunden 

geholfen werden kann. Auch für diesen Wert werden häufig Vereinbarungen zwischen 

dem Auftraggeber und dem Call Center vertraglich festgehalten. 

2.5 Systeme im Call Center 

Im Mittelpunkt der Call Center-Prozesse steht neben den Telefonagenten die eingesetzte 

Telekommunikationstechnik. Die Technik dient der Kommunikation der Telefonagenten 

mit den Gesprächspartnern und der Anbindung an die übrigen Leistungsprozesse im Unternehmen. 

30 

Das Call Center ist über Telefonleitungen mit dem Telefonnetz eines oder mehrerer Anbieter 

verbunden. Die Anzahl der Telefonleitungen begrenzt die maximal mögliche Anzahl 

von Telefonverbindungen. 31 

In modernen Umgebungen ist auch eine reine Anbindung über VoIP 32 an einen entsprechenden 

Anbieter über das Internet denkbar. 

Eine PBX (Private Branch Exchange) stellt die Verbindung zwischen den internen Anlagen 

und dem Telefonnetz her. Oftmals wird die PBX auch einfach als Telefonanlage bezeichnet. 

Neben herkömmlichen Hardware-Telefonanlagen gibt es mittlerweile komplett in 

Software realisierte Telefonanlagen. 

Insbesondere in Inbound-Call Centern kommen ACD-Anlagen (Automatic Call Distribution) 

zum Einsatz. Beim Einsatz einer ACD-Anlage sollen möglichst viele Anrufe mit möglichst 

wenigen Mitarbeitern abgearbeitet werden. 33 Zu unterscheiden sind drei Varianten 

von ACD-Systemen: Stand-alone-Systeme, adaptierte Systeme und integrierte Systeme. 34 

30 

31 

32 

33 

34 

Vgl. HELB2004, S. 7 


VoIP: Voice over IP, IP-basierte Übermittlung von Telefongesprächen über Computernetze. 

Vgl. BÖSE1999, S. 145 

Vgl. BÖSE1999, S. 145f


Stand-alone-Systeme sind direkt an das Telefonnetz angebunden und besitzen keine Verbindung 

zur Telefonanlage des Unternehmens. Wenn keine Integration in die restlichen 

betrieblichen Prozesse nötig ist, kann ein Stand-alone-System eingesetzt werden. 35 

Adaptierte Systeme haben eine Verbindung zur Telefonanlage und lassen sich so in die 

restlichen Unternehmensprozesse integrieren. 36 

Bei den integrierten Lösungen ist die ACD-Anlage Bestandteil der Telefonanlage und somit 

direkt ins Unternehmen integriert. Hierbei ist zu beachten, dass eine Überlastung der 

ACD-Anlage auch Auswirkungen auf die übrige Telefonie haben kann. 37 

Die ACD-Anlage hat die Aufgabe, die Anrufer an freie Telefonagenten weiterzuleiten 

bzw. sie in eine Warteschlange umzuleiten. Bei der Vergabe der Anrufe an freie Telefonagenten 

gibt es verschiedene Verfahren. Typisch ist die Verteilung an den freien Telefonagenten 

mit der geringsten Gesamtzahl an Gesprächen bzw. der größten Wartezeit. 38 

Auch die Warteschleifenfunktionalität verfügt über mehrere Methoden. So ist es möglich, 

den Anrufer im Rufzustand warten zu lassen. Der Anrufer hört den normalen Rufton und 

es entstehen ihm keine Kosten. Häufiger ist die Vermittlung in ein Wartefeld, in dem der 

Anrufer eine Ansage oder eine Musikeinspielung hört, bis ein Agent für ihn frei wird. Es 

kann auch eine Überlaufgruppe definiert sein, zu der Anrufe umgeleitet werden, wenn das 

angerufene Projekt ausgelastet ist. Auch Umleitungen zu anderen Call Centern sind möglich. 

Eine weitere Variante ist die Besetzt-Signalisierung: der Anrufer erhält ein Besetztzeichen 

und die Verbindung wird getrennt. 39 

In der Regel stellt die ACD-Anlage auch die benötigten Statistiken zur Verfügung. Der 

Telefonagent gibt seinen Zustand an das System weiter, so dass detaillierte Informationen 

über An- und Abmeldung, Pausen, Nacharbeitszeiten usw. existieren. 40 

Viele ACD-Anlagen verfügen über IVR-Systeme (Interactive Voice Response), die eine 

Kommunikation mit dem Kunden möglich machen, ohne die Verbindung zu Telefonagenten 

herzustellen. So kann der Kunde selbst zum richtigen Ansprechpartner navigieren oder 

einfache Informationen übermitteln. Dies funktioniert mittels Tonwahl- oder Spracherkennung. 

41 

35 

36 

37 

38 

39 

40 

41 

Vgl. BÖSE1999, S. 146 

Vgl. BÖSE1999, S. 146 

Vgl. BÖSE1999, S. 146 

Vgl. MENZ1999, S. 181 

Vgl. MENZ1999, S. 182f 

Vgl. MENZ1999, S. 184 

Vgl. HELB2004, S. 95


Ein weiteres Funktionsmerkmal moderner ACD-Anlagen ist Skill-Based Routing. Hierbei 

wird davon ausgegangen, dass die Telefonagenten unterschiedliche Qualifikationen haben, 

die für die eintreffenden Anrufe unterschiedlich nützlich oder sogar zwingend erforderlich 

sind. 42 Ein Beispiel ist eine mehrsprachige Hotline eines Telekommunikationsanbieters, 

über die Vertragsangelegenheiten und technische Hilfestellungen abgewickelt werden. 

Verschiedene Agenten können unterschiedliche Fremdsprachenfähigkeiten und unterschiedliche 

technische und vertragliche Kenntnisse haben. Trifft nun ein Anruf auf der 

französichsprachigen Technikhotline an, wählt die ACD-Anlage den bestmöglichen freien 

Telefonagenten aus. Ist kein Telefonagent mit einem zwingend erforderlichen Kriterium, 

wie der Sprache, frei, wird der Kunde in die Warteschlange gestellt. 

Über ein CTI-System (Computer Telephony Integration) ist es möglich, die Informationen 

der eingehenden Anrufe mit Kundendatenbeständen abzugleichen, um dem Telefonagenten 

alle benötigten Daten zum Anrufer auf seinen Computerbildschirm zu liefern. In der Outbound-Telefonie 

stellt der Anrufer aus dem Computersystem per CTI eine Verbindung mit 

dem Kunden her. 

Eine weitergehende Wahlhilfe in der Outbound-Telefonie ist der Dialer. Ein Dialer stellt 

eine Verbindung mit dem Kunden her, ohne dass der Telefonagent wählen muss. Hierbei 

gibt es verschiedene Stufen, die sich stark unterscheiden. 43 

Beim Preview Dialing initiiert der Agent per Knopfdruck, wann der angezeigte Kundendatensatz 

angewählt wird. Das Verfahren wird z.B. bei Projekten mit schwierigen Kunden 

oder bei besonders erklärungsbedürftigen Produkten im Geschäftskunden-Bereich angewandt. 

Gegenüber dem manuellen Wählen wird Zeit gespart, die Fehleranfälligkeit durch 

Vertippen entfällt und der Agent kann sich voll auf das Gespräch konzentrieren. 

Ein Progressive Dialer stellt dem freien Telefonagenten automatisch ein Gespräch zu und 

liefert die passende Datenmaske auf den Computerbildschirm. Besetzte oder fehlerhafte 

Anschlüsse gelangen nicht zum Telefonagenten. Verschiedene Systeme verfügen auch 

über eine automatische Filterung von Fax-Geräten und Anrufbeantwortern. Durch die Verkürzung 

der Wartezeiten steigt die Produktivität der Telefonagenten. 

Ein Power Dialer steigert die Produktivität ein weiteres Mal, da er für jeden freien Agenten 

auf einer definierten Anzahl von Leitungen Kunden anwählt. Diese definierte Anzahl 

von gleichzeitig gewählten Leitungen wird als Overdial-Faktor bezeichnet. Hierbei kann es 

dazu kommen, dass mit mehr Kunden eine Verbindung hergestellt wird, als aktuell Telefonagenten 

frei sind. Diese Verbindungen werden unterbrochen. Die Verkürzung der War- 

42 

43 

Vgl. HELB2004, S. 104ff 

Vgl. MENZ1999, S. 199


tezeiten, und damit die Steigerung der Produktivität, steht hier also der Anzahl der unterbrochenen 

Gespräche und damit auch der Kundenzufriedenheit gegenüber. 

Der Predictive Dialer versucht die Unzulänglichkeiten des Power Dialers zu überwinden. 

Durch vordefinierte Algorithmen und kampagnenspezifisch erlernte Muster errechnet der 

Dialer, wann auf wie vielen Leitungen gewählt werden muss. Der maximale Anteil von 

fallengelassenen Gesprächen an der Gesamtanzahl kann meist vorgegeben werden. 

Eine besondere Behandlung verlangen mit dem Kunden vereinbarte Rückruftermine, die 

entweder persönlich für den Agenten oder für die ganze Gruppe gespeichert werden. Diese 

müssen zum vereinbarten Zeitraum angerufen werden und dürfen nicht in die normale Verteilung 

geraten. 44 

Viele Call Center bezeichnen sich mittlerweile als Contact Center oder Communication 

Center. Damit soll verdeutlicht werden, dass auch andere Kanäle der Kundenkommunikation 

abgedeckt werden, wie z.B. E-Mail, Fax und Briefpost. 45 Für die Verarbeitung von 

Faxen und E-Mails existiert Verwaltungs-Software, die eine strukturierte Bearbeitung der 

Kommunikation möglich macht. Teilweise ist diese auch in die Telefoniesysteme integriert, 

so dass während anrufschwächerer Zeiten eine Bearbeitung von Faxen oder E-Mails 

möglich ist. Auch die Integration anderer Prozesse, z.B. aus Warenwirtschaftssystemen, ist 

in modernen Systemen möglich. 46 

Ein weiteres typisches Call Center-System ist eine Anrufaufzeichnungsanlage bzw. ein 

Voice Mail Server. Dieses, meist in ACD-Anlagen integrierte, System, ermöglicht es den 

Kunden, Sprachnachrichten zu hinterlassen, wenn alle Telefonagenten belegt sind. Falls 

die Hotline nur zu begrenzten Zeiten erreichbar ist, kann der Kunde so auch außerhalb der 

Geschäftszeiten eine Nachricht hinterlassen. 47 Eine Sprachaufzeichnung ist auch von kompletten 

Gesprächen möglich. Dies wird eingesetzt zum Nachweis von Geschäftsabschlüssen, 

zur Geldtransaktion bei Banken, bei Notrufen und zum Mitarbeitertraining. Bei 

Sprachaufzeichnungen sind die besonderen gesetzlichen Vorgaben im Einsatzland zu beachten. 

48 

44 

45 

46 

47 

48 

Vgl. MENZ1999, S. 200 

Vgl. BÖSE1999, S. 238f 

Vgl. MUELL2007, S. 21 


Vgl. MENZ1999, S. 203


2.6 Zusammenfassung 

Das Controlling ist ein Steuerungsinstrument für Unternehmen, das sowohl für die operative 

als auch für die strategische Führung wichtig ist. Auch in Call Centern ist das Controlling 

ein zentrales Instrument der Unternehmensführung. 

Besonderheiten ergeben sich durch die unterschiedlichen Ausrichtungen von Call Centern. 

Neben internen Call Centern, die Organisationseinheiten innerhalb eines Unternehmens 

sind, existieren Call Center-Dienstleister, die einzelne Projekte oder komplette Prozesse für 

ihre Kunden abwickeln. 

Call Center bedienen dabei eine oder beide Kommunikationsrichtungen. Inbound- 

Telefonie bezeichnet das Anrufen von Kunden beim Call Center, Outbound bezeichnet das 

aktive Kontaktieren der Kunden durch das Call Center. 

Die durchgeführten Kampagnen lassen sich in die Kategorien Beratungs- und Beschwerdemanagement, 

Informationsmanagement, Auftragsmanagement und Kunden- und Kampagnenmanagement 

einteilen. 

Die Personalkosten sind in Call Centern mit bis zu 70% an den Gesamtkosten beteiligt. 

Darin begründet sich das Interesse des verstärkten operativen Controllings der Mitarbeiterleistungen. 

Auf strategischer Ebene stehen die Leistungen von einzelnen Branchen, Projekten 

und Standorten im Mittelpunkt der Betrachtung. 

Eine Reihe von Kennzahlen wird gebildet, um die Erfüllung der Unternehmensziele messbar 

zu machen. Die Kennzahlen lassen sich unterteilen in allgemeine Kennzahlen, zeitliche 

Kennzahlen, quantitative Kennzahlen, monetäre Kennzahlen und qualitative Kennzahlen. 

Die Kennzahlen entstehen durch die Interaktion der Telefonagenten mit den Kommunikations- 

und Computersystemen des Call Centers. Neben Telefon- und ACD-Anlagen kommen 

im Outbound-Bereich als Dialer bezeichnete Wählprogramme zum Einsatz. 

Die Daten, die Aufschluss über die Dauer und Ausprägung der verschiedenen Aktionen 

geben, werden von den Systemen gespeichert. Um diese Daten computergestützen Informationssystemen 

zur Verfügung zu stellen, werden Methoden der Business Intelligence 

verwendet. Diese Methoden werden im folgenden Kapitel vorgestellt.

3. Business Intelligence - 15 - 

3 Business Intelligence 

Business Intelligence ist ein integrierter, unternehmensspezifischer, IT-basierter Gesamtansatz 

zur betrieblichen Entscheidungsunterstützung. 49 Der Begriff wird mitunter auch für 

einzelne Teilbereiche der Entscheidungsunterstützung gebraucht. Das Begriffsverständnis 

gliedert Gluchowski in einem zweidimensionalen Ordnungsrahmen, mit dem er drei Ansätze 

definiert: das enge BI-Verständnis, das analyseorientierte BI-Verständnis und das weite 

BI-Verständnis (vgl. Abb. 3). 50 

Abb. 3 Business Intelligence-Ordnungsrahmen 

(Quelle: Kemper, H.; Mehanna, W.; Unger, C.: Business Intelligence. Grundlagen und 

praktische Anwendungen. – 2. Auflage – Wiesbaden (Vieweg), 2006. S. 4) 

Im engeren Verständnis werden nur einige Kernanwendungen zur Business Intelligence 

gezählt. Das sind insbesondere das Online Analytical Processing (OLAP) und Management 

bzw. Executive Information Systems (MIS/EIS). 

Der analyseorientierte Ansatz zählt alle Systeme, mit denen der Entscheider direkt in Kontakt 

tritt zur Business Intelligence. Dazu gehören neben OLAP und MIS/EIS auch das Data 

Mining, das Ad-hoc-Reporting, die Balanced Scorecard und weitere Analysesysteme. 

49 

50 

Vgl. KEMP2004, S. 8 und GLUC2006, S. 13 

Vgl. KEMP2004, S. 3ff


Das weite Verständnis zählt auch die indirekt in den Entscheidungsprozess involvierten 

Systeme zum BI-Begriff dazu. Neben den Elementen der zwei anderen Ansätze sind dies 

auch alle Anwendungen der Datenaufbereitung und der Datenspeicherung. 51 

Die Prozesse und Anwendungen in einem Business Intelligence-System lassen sich in die 

drei Bereiche Datenerfassung, Datenhaltung und Datenbereitstellung unterteilen. Kemper 

und Unger teilen mit leicht unterschiedlichen Bezeichnungen den BI-Ordnungsrahmen in 

die Datenbereitstellung, die Informationsgenerierung, -speicherung und -distribution sowie 

den Informationszugriff. 52 

3.1 Datenerfassung 

Die Daten aus verschiedenen operativen Systemen werden für die Verwendung in Analysesystemen 

zusammengeführt. Die operativen, transaktionalen Systeme sind auf den jeweiligen 

Geschäftsprozess oder die funktionale Einheit zugeschnitten. Die Daten sind zeitaktuell, 

nicht abgeleitet, autonom und dynamisch. Für ein Analysesystem werden konsolidierte, 

abgeleitete, historisierte, integrierte und stabile Daten benötigt. 53 

In Extraktions-, Transformations- und Ladeprozessen (ETL) wird die aufbereitete analytische 

Datenbasis geschaffen. 

3.1.1 Extraktionsphase 

In der Extraktionsphase werden die Daten aus den operativen Systemen importiert. Oftmals 

werden sie in einem Bereich zwischen den operativen Datenbanken und den Analysedatenbanken, 

der sogenannten Staging Area, gespeichert. Ebenfalls möglich ist die komplette 

Verarbeitung im Arbeitsspeicher ohne eine Zwischenspeicherung der Daten. 54 

Das Zwischenspeichern der Daten bietet allerdings einige Vorteile, die in Erwägung gezogen 

werden sollten: 55 

• Bei der Speicherung von einzelnen Zwischenschritten im Transaktionsprozess kann 

im Fehlerfall ein Arbeitsschritt erneut durchgeführt werden, ohne nochmals auf die 

operativen Daten zuzugreifen. 

51 

52 

53 

54 

55 

Vgl. KEMP2004, S. 3ff 

Vgl. THIE2004, S. 24, WEBE1999, S.18 und KEMP2004, S. 10ff 

Vgl. BAUE2004, S. 8ff 

Vgl. KIMB2004, S. 29f 

Vgl. KIMB2004, S. 30f


• Die zwischengespeicherten Daten können als Sicherung dienen. Ab einer gewissen 

Bestandszeit können Daten komprimiert im Dateisystem gespeichert und im Notfall 

erneut verarbeitet werden. 

• Prüfungen und Änderungen der ETL-Prozesse lassen sich leichter durchführen, 

wenn für die einzelnen Phasen Daten vorhanden sind. Dies ist besonders der Fall, 

wenn Daten im operativen Quellsystem mittlerweile überschrieben sind. 

3.1.2 Transformationsphase 

In der Transformations-Phase wird als erstes gewährleistet, dass die Daten den Qualitätsmerkmalen 

Konsistenz, Vollständigkeit, Redundanzfreiheit und Einheitlichkeit entsprechen. 

56 

Hierfür werden sie von syntaktischen und semantischen Mängeln bereinigt. Die Mängel 

lassen sich in drei Klassen unterscheiden: 57 

• 1. Klasse: Automatisierbare Defekterkennung mit automatisierbarer Korrektur während 

des Extraktionsvorganges. 

• 2. Klasse: Automatisierbare Defekterkennung mit manueller Korrektur nach dem 

Extraktionsvorgang. 

• 3. Klasse: Manuelle Defekterkennung mit manueller Korrektur nach dem Extraktionsvorgang 

Bereinigung 1. Klasse 2. Klasse 3. Klasse 

Syntaktische Mängel Bekannte Formatanpassungekompatibilitäten 

Erkennbare Formatin- 

– 

Semantische Mängel Fehlende Datenwerte Ausreißerwerte / unstimmige 

Wertekonstellationen 

Unerkannte semantische 

Fehler in operativen 

Quellen 

Bedingen kurz- oder mittelfristig eine Fehlerbereinigung 

in den operativen Quellsystemen 

Tab. 2 Mängelklassifikation im Rahmen der Bereinigung 

(Quelle: Vgl. Kemper, H.; Mehanna, W.; Unger, C.: Business Intelligence. Grundlagen 

und praktische Anwendungen. – Wiesbaden (Vieweg), 2004. S. 25) 

Fehler der ersten Mängelklasse werden automatisch erkannt und automatisch behoben. Das 

setzt voraus, dass sie schon vor der Implementierung der ETL-Prozesse bekannt bzw. vor- 

56 

57 

Vgl. BAUE2004, S. 91ff und KIMB2004, S. 115f 

Vgl. KEMP2004, S. 25


herzusehen sind. Die Mängel der zweiten Klasse werden automatisch erkannt, müssen aber 

manuell behoben werden. Die Mängel der dritten Klasse werden weder automatisch erkannt 

noch behoben. Die Mängel der zweiten und dritten Klasse bedingen kurz- oder mittelfristig 

eine Behebung der Fehler in den Quellsystemen (vgl. Tab. 2). 58 

Nach der gefilterten Extraktion aus den verschiedenen Quellsystemen werden die Daten in 

der nächsten Transformationsphase harmonisiert. 

Die einzelnen Harmonisierungen sind: 

• Schlüsselbehandlung 

Wenn in mehreren Quellsystemen die gleichen Geschäftsobjekte abgebildet werden, 

haben sie häufig unterschiedliche Schlüssel. Mittels Zuordnungstabellen wird die Beziehung 

zwischen den einzelnen Schlüsseln hergestellt. Die Geschäftsobjekte erhalten 

einen künstlichen, eindeutigen Schlüssel. 59 

• Konvertierung von Kodierungen 

Wenn Attribute in verschiedenen Quellsystemen die gleiche Bedeutung, aber unterschiedliche 

Domänen haben, werden diese durch Auswahl einer Domäne bereinigt. Ein 

Beispiel ist die unterschiedliche Kodierung von Geschlechtern, die in einem System 

mit Zahlen (0, 1) und in einem anderen System mit Buchstaben (M, W) abgespeichert 

sind. 60 

• Synonyme 

Wenn Attribute unterschiedliche Bezeichnungen haben, aber die gleiche Bedeutung 

und die gleiche Domäne besitzen, wird einer der Namen ausgewählt. 61 

• Homonyme 

Wenn es gleichlautende Attributsnamen gibt, die eine unterschiedliche Bedeutung oder 

eine ungleiche Domäne haben, werden sie mit unterschiedlichen Attributsnamen gespeichert. 

62 

58 

59 

60 

61 

62 

Vgl. KEMP2006b, S. 120f und KEMP2004, S. 26f 

Vgl. BAUE2004, S. 84 

Vgl. KEMP2006b, S. 122 und INMO2002, S. 33 

Vgl. KEMP2006b, S. 122 

Vgl. KEMP2006b, S. 122


• Betriebswirtschaftliche Harmonisierung 

Neben den syntaktischen Harmonisierungen werden auch betriebswirtschaftliche Gesichtspunkte 

berücksichtigt. Die zu kombinierenden Daten werden auf die gleiche Granularitätsstufe 

gebracht und es wird sichergestellt, dass Kennzahlen eindeutig definiert 

sind. 63 

In der nächsten Teilphase der Transformation werden Aggregationen gebildet. Da bei der 

Analyse häufig nicht die Detailwerte, sondern Summen gefragt sind, kann durch ein gesondertes 

Abspeichern der Summendaten ein Geschwindigkeitsvorteil erreicht werden. 64 

In der Anreicherungs-Phase werden berechnete Kennzahlen gebildet und gespeichert. Obwohl 

dies der sonst üblichen Trennung von Daten und Programmlogik widerspricht, bietet 

dieses Vorgehen Vorteile. So ist das Antwortverhalten bei späteren Abfragen kalkulierbar 

und die Werte sind aufgrund der einmaligen Berechnung konsistent. 65 

Ebenfalls üblich ist es, die Aggregationen und Anreicherungen erst in der Datenbereitstellungsebene, 

z.B. innerhalb der OLAP-Datenbank, durchzuführen (vgl. Kapitel 3.3.1). 

3.1.3 Ladephase 

Nach der Extraktion und Transformation werden die aufbereiteten Analysedaten in das 

Analysesystem geladen. Beim Laden wird zwischen dem erstmaligen Laden, bei dem die 

historischen Quelldaten übertragen werden, und den späteren regelmäßigen Aktualisierungen 

unterschieden. Die Ladephase findet zumeist zu Zeiten statt, in denen wenig auf den 

betroffenen Systemen gearbeitet wird. Die Ladevorgänge können Online oder Offline erfolgen. 

Bei Online-Ladevorgängen stehen die Daten weiterhin zur Verfügung, bei Offline- 

Vorgängen ist während des Ladens kein Zugriff möglich. 66 

3.2 Datenhaltung 

Im Mittelpunkt der Datenhaltung steht das Data Warehouse. Das Data Warehouse ist die 

von den operativen Daten getrennte analytische Datenbasis. 67 

63 

64 

65 

66 

67 

Vgl. KEMP2004, S.30f 

Vgl. KEMP2004, S. 124f und DINT2006, S. 31f 

Vgl. KEMP2004, S. 32f 

Vgl. BAUE2004, S. 94f und MUCK2000, S. 41f 

Vgl. MUCK2006, S. 131


3.2.1 Data Warehouse-Systeme 

Inmon charakterisiert ein Data Warehouse-System mit vier Merkmalen: 68 

• Themenorientierung 

Das System orientiert sich an den inhaltlichen Kernbereichen des Unternehmens. 

Dabei steht nicht die Erfüllung einer Aufgabe, sondern die Modellierung eines spezifischen 

Anwendungsziels im Mittelpunkt. 

• Vereinheitlichungen 

Die Daten sind aus mehreren Datenquellen integriert. Durch Struktur- und Formatvereinheitlichungen 

wird ein einheitliches Abbild der Unternehmensdaten geschaffen. 

• Beständigkeit 

Die Daten des Systems sind nicht volatil. Die Daten werden nach dem Einspielen in 

das System nicht mehr aktualisiert und überschrieben. Eine Ausnahme bilden Planungsdaten. 

• Zeitorientierung 

Die Daten beziehen sich auf einen Zeitraum. Operative Daten hingegen sind zeitpunktbezogen. 

Der relevante Zeithorizont im Data Warehouse ist signifikant größer 

als der im operativen System. Die Daten sind so verarbeitet, dass Vergleiche über 

die Zeit stattfinden können. 

3.2.2 Dimensionale Modellierung 

Die Daten im Data Warehouse werden häufig in einem dimensionalen Modell gespeichert. 

Dieses besteht aus Fakten- und Dimensionstabellen. In einer Faktentabelle werden die numerischen 

Leistungskennzahlen des Unternehmens gespeichert – der Begriff Fakt steht 

hier also für betriebswirtschaftliche Kennzahlen. 69 Der Fakt „ist ein aggregierbares, meist 

numerisches und kontinuierliches Attribut, das die mehrdimensionale Messung eines betrieblichen 

Erfolgskriteriums erlaubt“. 70 

68 

69 

70 

Vgl. INMO2002, S. 31ff, CHAM2006, S. 13f, BAUE2004, S. 7ff und OEHL2006, S. 19f 

Vgl. KIMB2002, S. 16f und SCHR2006, S. 27f 

LUST1999, S. 138


Die Fakten werden an der Schnittstelle der Dimensionen gemessen. Die Dimensionen definieren 

die Genauigkeit und den Bereich der Kennzahlen. 71 Die Faktentabellen haben 

Fremdschlüssel, die die Fakten mit den einzelnen Dimensionstabellen verbinden. In den 

Dimensionstabellen wird der geschäftliche Zusammenhang der Kennzahlen beschrieben. 

Eine Dimension entspricht dabei einer Klasse gleichartiger Geschäftsobjekte wie z.B. 

Kunden, Mitarbeitern oder Produkten und besitzt beschreibende Attribute. 72 

Die Fakten- und Dimensionstabellen werden im Sternschema zusammengeführt (vgl. Abb. 

4). Jede Dimensionstabelle steht in einer 1:n-Beziehung mit der Faktentabelle, die über den 

Schlüssel der Dimensionstabelle als Fremdschlüssel in der Faktentabelle abgebildet wird. 73 

Die Dimensionen sind im Sternschema, im Gegensatz zur Praxis bei der Datenmodellierung 

operativer Daten, denormalisiert. Durch die geringe Anzahl von Tabellen ergibt sich 

ein benutzerfreundliches Abbild der Geschäftslogik und eine höhere Leistung als bei normalisierten 

Schemata. 74 

Im Beispiel der Abb. 4 werden die Fakten Verkäufe und Umsatz mit den Dimensionen 

Produkte, Mitarbeiter, Zeit und Regionen dargestellt. 

Abb. 4 

Dimensionale Modellierung mit einem Sternschema 

71 

72 

73 

74 

Vgl. KIMB2002, S. 17 

Vgl. OEHL2006, S. 129 

Vgl. LUST1999, S. 177 

Vgl. KIMB2002, S. 21f


Sofern die Dimensionen ganz oder teilweise normalisiert werden, wird von einem Schneeflockenschema 

gesprochen. Hierbei werden m:n-Beziehungen durch Verbindungstabellen 

normalisiert und Unterdimensionen abgetrennt. 75 

Multifakten- oder Galaxy-Schemata sind Schemata, in denen Dimensionen mit mehreren 

Faktentabellen verknüpft sind (vgl. Abb. 5). Die Dimensionen, die mit mehreren Faktentabellen 

verknüpft sind werden Conformed Dimensions bezeichnet. 

Im Beispiel existiert neben den Ist-Werten für die Verkäufe auch eine Faktentabelle für die 

geplanten Verkäufe. Die Planung erfolgt hier nicht auf der Mitarbeiter-Detailstufe, die 

Faktentabellen besitzen also eine unterschiedliche Granularität. Die Dimensionen Zeit, 

Produkte und Regionen sind conformed. 

Abb. 5 

Multifakten-Schema 

Sind neben den detaillierten Faktentabellen auch gesonderte Tabellen für Aggregationen 

vorhanden, handelt es sich um ein Fact-Constellation-Schema (vgl. Abb. 6). 76 Im Beispiel 

75 

76 

Vgl. LUST1999, S. 185 

Vgl. KEMP2004, S. 64, BAUE2004, S. 208f und KIMB2002, S. 394


sind die summierten Fakten auf Produktgruppen-Ebene in einer eigenen Faktentabelle gespeichert. 

Abb. 6 

Fact-Constellation-Schema 

Innerhalb der Dimensionen werden die Hierarchien der Geschäftsobjekte abgebildet. Typische 

Hierarchisierungen sind z.B. in einer Produktdimension die Produktgruppe, der Hersteller, 

die Marke und das Produkt und in einer Regionendimension der Kontinent, das 

Land, die Region und die Stadt (vgl. Abb. 7). 

Abb. 7 

Hierarchisierung in einer Regionen-Dimension


In einer denormalisierten Dimensionstabelle werden die einzelnen Hierarchieebenen in 

eigenen Spalten gespeichert (vgl. Abb. 8). 

Abb. 8 

Abbildung der Hierarchie innerhalb der Dimensionstabelle 

Wenn sich Attributswerte bei den Dimensionen regelmäßig ändern, handelt es sich um 

Slowly Changing Dimensions (SCD). Es gibt drei Möglichkeiten diese abzubilden: 77 

• Bei der Typ 1-SCD wird der Attributswert bei Änderung überschrieben. Der Wert 

des Attributs entspricht somit immer dem aktuellen Wert. Dieses Vorgehen empfiehlt 

sich nur bei Korrekturen oder Änderungen, die nicht für die Analyse relevant 

sind. Jegliche Information über die Historie des Attributswertes geht dabei verloren. 

• Besser geeignet für die Beibehaltung historischer Informationen ist die Typ 2-SCD. 

Bei einer Änderung wird eine Zeile an die Dimensionstabelle angefügt und der Ablauf 

der Gültigkeit in der Originalzeile vermerkt. Dimensionstabellen haben hierfür 

zwei Datumsattribute, die den Start und das Ende der Gültigkeit kennzeichnen. 

Damit ist eine lückenlose Analyse auch mit den nicht mehr gültigen Werten möglich. 

• Bei der dritten Möglichkeit, der Typ 3-SCD, wird für den geänderten Wert eine 

Spalte zur Dimension hinzugefügt. Damit ist es möglich, einen beliebigen Zeitraum 

mit dem alten und dem neuen Wert zu bewerten. Diese Anforderung ist jedoch selten 

vorhanden und erfordert jedes Mal eine Änderung der Datenstruktur. 

Die Elemente der Dimensionstabellen werden mit künstlichen Schlüsseln, sogenannten 

Surrogate Keys, versehen. Damit wird eine Unabhängigkeit von den vorhandenen Geschäftsschlüsseln 

erreicht, die sich unter Umständen ändern könnten. Ebenso wird die Um- 

77 

Vgl. KIMB2002, S. 95ff und KNIG2006, S. 189ff


setzung der oben beschriebenen Typ2-SCD erst durch einen künstlichen Schlüssel möglich. 

78 

3.3 Datenbereitstellung 

Die Ebene der Datenbereitstellung ermöglicht für die Benutzer den Zugriff auf die Analysedaten 

des Data Warehouses. Zum Zugriff auf die Daten stehen unter anderem Online 

Analytical Processing (OLAP), das Berichtswesen, Data Mining sowie Scorecards und 

Dashboards zur Verfügung. 

3.3.1 Online Analytical Processing 

OLAP führt die bereits erläuterten Dimensions- und Faktendaten zu einem multidimensionalen 

Datenmodell zusammen und ermöglicht so einen benutzerfreundlichen und flexiblen 

Zugriff auf die Daten. 

Der Begriff OLAP wurde von Codd in Abgrenzung zum transaktionalen Online Transaction 

Processing (OLTP) geprägt und durch 12 bzw. später 18 Regeln definiert. 79 Pendse definierte 

die Anforderungen an OLAP-Anwendungen mit fünf Schlüsselwörtern: Fast Analysis 

of Shared Multidimensional Information (FASMI). 80 

• Fast 

Die Anfragen der Nutzer werden schnell beantwortet. Simple Analysen sind innerhalb 

einer Sekunde verfügbar, länger als zwanzig Sekunden dauern nur die wirklich 

anspruchsvollen Analysen. Bei längeren Antwortzeiten wird der Benutzer in seinen 

Gedankengängen unterbrochen und die Analysequalität nimmt ab. 

• Analysis 

Das System bildet die vom Anwender benötigte und relevante betriebliche Logik ab 

und ist intuitiv und anwenderfreundlich bedienbar. Neue Ad-hoc-Berichte sind ohne 

Programmierkenntnisse erstellbar. 

78 

79 

80 

Vgl. KIMB2002, S. 58ff 

Vgl. CODD1993, S. 12 

Vgl. CLAU1998, S. 14f, THIE2004, S. 30f und PEND2005


• Shared 

Das System ermöglicht einen Mehrbenutzerbetrieb. Dabei werden Sicherheitsanforderungen 

erfüllt. 

• Multidimensional 

Das System lässt eine multidimensionale Sicht auf die Daten zu. Dies beinhaltet 

auch multiple Hierarchien. 

• Information 

OLAP-Systeme erzeugen aus Daten Informationen. Die Menge der Daten spielt 

keine Rolle. 

OLAP lässt sich aus drei verschiedenen Sichten betrachten: der konzeptionellen Sicht, der 

externen Sicht und der internen Sicht. 81 

Die konzeptionelle Sicht beschreibt das multidimensionale Modell in einem OLAP- 

System. Hierbei ist zwischen quantifizierenden und identifizierenden Attributen zu unterscheiden. 

Die quantifizierenden Attribute sind die Fakten oder Kennzahlen. Ein Fakt besitzt 

ohne beschreibende Attribute keine Aussagekraft. Erst durch die Hinzunahme von 

Dimensionswerten lässt sich der Fakt betriebswirtschaftlich einordnen. Die Verknüpfung 

der Fakten mit den Dimensionen wird im multidimensionalen Modell Würfel, Cube oder 

Hypercube genannt. Es ist zu beachten, dass die Bezeichnung Würfel in diesem Modell 

nicht auf drei Dimensionen beschränkt ist. 82 Die Modellierung von Dimensionen und Fakten 

ist bereits in Kapitel 3.2.2 besprochen worden. 

Die externe Sicht beschreibt die Möglichkeiten des Anwenders zur Navigation und Analyse 

im OLAP-System. So stehen in den meisten Systemen die Navigationsfunktionen Drilldown, 

Roll-up, Slice und Dice zur Verfügung. 

Ein Drill-down bezeichnet ein Navigieren innerhalb einer Dimension auf eine detailliertere 

Verdichtungsstufe. Somit können die hochverdichteten Zahlen besser nachvollzogen werden. 

Die Navigation in die umgekehrte Richtung wird als Roll-Up bezeichnet (vgl. Abb. 

9). 83 

81 

82 

83 

Vgl. THUR2003, S. 17ff 

Vgl. THUR2003, S. 18f 

Vgl. HOLT2000, S. 155 und PIET2003, S. 115


Abb. 9 OLAP-Navigationsfunktionen Drill-down und Roll-up 

(Quelle: Vgl. Schechner, M.: Konzeptionierung und prototypische Realisierung einer Business 

Intelligence Lösung für die Tochtergesellschaften der Schering AG. Diplomarbeit an 

der FHTW Berlin, 2004. S. 29) 

Beim Slicing wird der Wert einer Dimension festgelegt und bildlich eine Scheibe aus dem 

Würfel herausgeschnitten (vgl. Abb. 10). 

Abb. 10 OLAP-Navigationsfunktion Slicing 



der FHTW Berlin, 2004. S. 30)


Beim Dicing werden Teilbereiche von Dimensionen gewählt. Es entsteht bildlich ein kleinerer 

Teilwürfel (vgl. Abb. 11). 84 

Abb. 11 OLAP-Navigationsfunktion Dicing 



der FHTW Berlin, 2004. S. 30) 

Die interne Sicht beschreibt die physische Speicherung der Daten. Dabei sind verschiedene 

Speicherformen zu unterscheiden. 

Beim relationalen OLAP (ROLAP) bleiben die Daten im Stern- oder Schneeflocken- 

Schema in der relationalen Datenbank gespeichert. Das ROLAP-System verschafft dem 

Anwender eine multidimensionale Sicht, ohne dass dieser sich mit dem relationalen Datenmodell 

auseinandersetzen muss. 85 

In multidimensionalen OLAP-Systemen (MOLAP) werden die Daten aus dem relationalen 

System in die OLAP-Datenbank geladen. Diese werden dann kalkuliert und aufbereitet und 

stehen dem Anwender zur Verfügung. 86 Der Vorteil von MOLAP-Systemen gegenüber 

ROLAP ist die vorhersagbare Antwortgeschwindigkeit, allerdings verbrauchen die aufbereiteten 

Datenwürfel mehr Speicherplatz. 87 

Hybrides OLAP (HOLAP) verbindet den relationalen und den multidimensionalen Ansatz. 

Die hochverdichteten Daten werden multidimensional abgespeichert, die detaillierteren 

84 

85 

86 

87 

Vgl. HOLT2000, S. 155ff 

Vgl. HUMM1998, S. 63 

Vgl. CLAU1998, S. 33 

Vgl. BAUE2004, S.241f und CLAU1998, S. 35


Daten verbleiben im relationalen System. Der Wechsel zwischen den Modi erfolgt dabei 

benutzertransparent. 88 

3.3.2 Berichtswesen 

Im Rahmen des Berichtswesens werden die Informationen tabellarisch und mit unterstützenden 

Grafiken dargestellt. Die Berichte werden zu festen Zeitpunkten und mit definierten 

Distributionsmethoden erstellt und verteilt. Neben der Verteilung in Papierform oder 

der Betrachtung in speziellen Anwendungen spielen heute Berichte im Intra- oder Internet 

eine immer größere Rolle. 89 

Neben den Standardberichten benötigen manche Anwender Informationen, die nicht mit 

einem bereits definierten Bericht abgedeckt sind. Hierfür bieten BI-Systeme die Ad-hoc- 

Analyse an. Der Zugriff auf die Daten erfolgt über spezielle Software oder über Integration 

in Tabellenkalkulationen. 90 

3.3.3 Weitere Elemente der Datenbereitstellung 

In Cockpits werden aggregierte Informationen einfach und übersichtlich dargestellt. Die 

Bereitstellung erfolgt z.B. über Unternehmensportale und dient als Führungs- und Managementinformationssystem. 

91 

Scorecards verfügen neben der Anzeige von Kennzahlen über weitere Eigenschaften. So 

werden in Balanced Scorecards neben den Key Performance Indicators und Kennzahlen 

auch Maßnahmen und Ziele einbezogen, die die Vision und Strategie des Unternehmens 

unterstützen. 92 

Data Mining ermöglicht die ungerichtete Analyse in den Daten, um Strukturen, Muster und 

Zusammenhänge zu erkennen oder zu validieren. Hierfür werden Verfahren der Statistik, 

des maschinellen Lernens und der künstlichen Intelligenz angewendet. 93 

88 

89 

90 

91 

92 

93 

Vgl. KEMP2004, S. 100f und BAUE2004, S. 242f 

Vgl. BANG2006, S. 101 

Vgl. BANG2006, S. 103 

Vgl. BANG2006, S. 98 

Vgl. BANG2006, S. 98 

Vgl. BANG2006, S. 107



Business Intelligence ist ein Gesamtansatz zur betrieblichen Entscheidungsunterstützung, 

der sich in die Phasen Datenerfassung, Datenhaltung und Datenbereitstellung unterteilen 

lässt. 

In der Phase der Datenerfassung werden die Daten aus den operativen Systemen extrahiert, 

transformiert und in die Analysesysteme geladen. Bei der Transformation werden die Daten 

von Mängeln befreit, harmonisiert, aggregiert und angereichert. 

Im Mittelpunkt der Datenhaltung steht das Data Warehouse, das die von den operativen 

Systemen getrennte analytische Datenbasis ist. Im Data Warehouse werden die Daten in 

einem dimensionalen Modell gespeichert, das aus Fakten und Dimensionen besteht. 

Ein Fakt ist eine betriebswirtschaftliche Kennzahl, die an der Schnittstelle der Dimensionen 

gemessen wird. Die Dimensionen beschreiben den geschäftlichen Zusammenhang der 

Kennzahlen. Eine Dimension entspricht einer Klasse gleichartiger Geschäftsobjekte. 

In der Phase der Datenbereitstellung können diese Fakten und Dimensionen im OLAP- 

System in sogenannten Cubes zusammengeführt und für die multidimensionale Analyse 

zur Verfügung gestellt werden. Das Berichtswesen greift dann auf die Daten im Data Warehouse 

sowie auf die OLAP-Daten zu. 

Zum Aufbau eines Business Intelligence-Systems werden die Analyseziele definiert und 

deren Umsetzbarkeit überprüft. Dafür erfolgt im folgenden Kapitel eine Analyse der bestehenden 

entscheidungsunterstützenden Systeme, der organisationellen Rahmenbedingungen 

sowie der operativen Systeme.

4. Ausgangssituation - 31 - 

4 Ausgangssituation 

Die adm GmbH betreibt in Deutschland Call Center an den Standorten Mannheim, Berlin 

und Rostock mit insgesamt 1100 Plätzen und 2200 Mitarbeitern. 94 Es werden sowohl Inbound-Projekte 

als auch Outbound-Projekte durchgeführt. Inbound-Projekte sind Hotlines 

von Energieversorgern, Pharmaherstellern und Versicherungen. Typische Outbound- 

Kampagnen sind Terminvereinbarungen für Banken und Versicherungen, Up- und Cross- 

Sell-Kampagnen 95 im Telekommunikationssektor und Produkteinführungskampagnen im 

Pharma- und Healthcare-Bereich. Gerade im Outbound-Sektor werden für eine Vielzahl 

von Kunden sehr heterogene Projekte telefoniert, die oft nur eine kurze Laufzeit haben. 

In diesem Kapitel wird die Ausgangslage des Berichtswesens bei der adm GmbH dargestellt. 

Ein Überblick über die Aufbauorganisation vermittelt die am Berichtsprozess beteiligten 

Personen. Weiterhin werden die relevanten operativen Systeme und die bestehenden 

Berichtssysteme vorgestellt. 

4.1 Aufbauorganisation 

Der Call Center-Betrieb der adm GmbH wird vom Leiter Finanzen & Produktion geführt, 

der an die übrigen Geschäftsführer berichtet. Jeder Standort hat einen Call Center-Leiter, 

der für die Koordination der Projekte und Mitarbeiter am Standort verantwortlich ist. An 

jedem Standort gibt es mehrere Projektleiter, die für die Durchführung der einzelnen Projekte 

zuständig sind und in Zusammenarbeit mit dem Vertrieb die Kommunikation mit den 

Auftraggebern übernehmen. Jeder Projektleiter betreut normalerweise mehr als ein Projekt. 

Den Projektleitern sind Supervisoren unterstellt, die für die operative Betreuung der Agenten 

zuständig sind. Dazu gehört die Erstellung von Dienstplänen, das Vermitteln von Projektzielen 

und die Analyse von Kennzahlen der einzelnen Agenten. Parallel existieren an 

jedem Standort Kommunikationstrainer, die auf Basis der Kennzahlen und durch das Mithören 

von Gesprächen für die Schulung der Agenten zuständig sind. Jeder Standort hat 

eine Tracking & Reporting-Abteilung, die für die Aufbereitung von internen Berichten und 

Kundenberichten zuständig ist sowie die Abrechnung der erbrachten Leistungen vorbereitet. 

Die Abteilung Tracking & Reporting bildet ebenso die Schnittstelle zwischen der Produktion 

und der IT-Abteilung. Abb. 12 zeigt einen Ausschnitt aus der Aufbauorganisation 

der adm GmbH. 

94 

95 

Stand: Ende 2006 

Up-Sell/Cross-Sell: Der Versuch, Bestands- oder Neukunden höherwertigere oder zusätzliche Produkte 

zu verkaufen.


Abb. 12 

Ausschnitt aus der Aufbauorganisation 

4.2 Operative Systeme 

Für den Untersuchungsbereich dieser Thesis sind die Telefonie-Systeme der adm GmbH 

mit ihren angeschlossenen Datenbanken und Benutzeroberflächen sowie die Personalsysteme 

aufgrund der zu berücksichtigenden Agentenkosten relevant. 

Im Inbound-Bereich kommen bisher zwei verschiedene ACD-Systeme zum Einsatz, die 

gerade durch die Einführung einer Anlage eines anderen Herstellers ersetzt werden. Da die 

Konzeption und die Einführung des neuen Systems noch nicht abgeschlossen ist, konzentriert 

sich diese Thesis auf die Outbound-Systeme. Eine spätere Integration der Inbound- 

Systeme ist zur Vereinheitlichung des Controllings sinnvoll und auch geplant.


4.2.1 Telefonie-Systeme 

Das zentrale Outbound-System in den Call Centern der adm GmbH ist die Telefonie- 

Lösung Hermes des französischen Herstellers Vocalcom. Von der Software sind momentan 

zwei Versionsgenerationen im Einsatz, die sich in der grundlegenden Architektur unterscheiden. 

Hermes ist ein als Dialer bezeichnetes Wählprogramm, das mehrere Wählmodi beherrscht 

(vgl. Kapitel 2.5). Das System unterstützt Predictive Dialing, Progressive Dialing und Preview 

Dialing. 

Das Dialer-System greift auf die Telefonnummern der Kunden zu, wählt die Kunden je 

nach Priorität, Wählmodus und erlerntem Algorithmus an und verteilt die Gespräche an die 

am System angemeldeten Agenten. Die Agenten erhalten zeitgleich das Kundentelefonat 

auf dem Headset und die dazugehörigen Daten auf dem Bildschirm. 

Das Hermes-System besteht im Wesentlichen aus den Komponenten AgentProxy, OnNet, 

OnData und VsDialer (vgl. Abb. 13). 

Abb. 13 Architektur des Dialer-Systems 

(Quelle: Volcalcom Hermes.Net. – Interne Dokumentation, 2006)


Die Teilkomponente AgentProxy übernimmt die Kommunikation mit den Agentenrechnern. 

OnNet ist für die Anbindung an das Telefonnetz und an OnData zuständig. OnData 

speichert und verwaltet die Statistiken – alle Agentenaktionen und Telefonate bzw. Anrufversuche 

werden hier erfasst. VsDialer ist die eigentliche Dialer-Komponente. Per SOAP 96 

werden die anzurufenden Telefonnummern ins System geladen. VsDialer ist ebenso für die 

Verwaltung der Rückrufwünsche verantwortlich. 

4.2.2 Datenbanken 

Die Dialer-Lösung nutzt als Datenbasis einen Microsoft SQL Server 2000. Die Telefonnummern 

der anzurufenden Kunden sind im Call File, einer Relation auf diesem Server, 

gespeichert (vgl. Tab. 11). 

Über die ID des Kunden wird eine Verknüpfung zum Client File der Kampagne hergestellt, 

das die relevanten Geschäfts- und Ergebnisdaten der Kunden enthält (vgl. Tab. 12). 

Mit diesen Daten wird die Datenmaske des Agenten auf seinem Bildschirm gefüllt. Im 

Gegensatz zum Call File kann das Client File auch auf einem anderen Datenbank-System 

liegen. Bei den meisten Kampagnen sind die Kundendaten auf einem separaten MySQL- 

Server abgelegt. 

Die Ergebnisse der Gespräche werden sowohl im Call File als auch im Client File festgehalten. 

Im Call File werden nur die zur Kampagnensteuerung relevanten Daten, wie z.B. 

das Datum und die Uhrzeit der Bearbeitung, der Status des Datensatzes und die Priorität, 

gespeichert. Die kampagnenspezifischen Daten werden im Client File festgehalten. Dies 

können erfasste Detailergebnisse, verkaufte Produkte oder erfasste Bankdaten und ähnliches 

sein. 

Die Agenten identifizieren sich gegenüber dem System mit einer pro Projekt eindeutigen 

Identifikationsnummer. Die Aktionen der Agenten werden zentral gespeichert. Hierfür 

werden die Dauer, der Zeitpunkt der Beendigung und die Identifikationsnummer für jede 

Agentenaktion protokolliert. Dazu gehören unter anderem einzelne Gespräche, die Nacharbeitszeit 

im Anschluss an ein Gespräch, Pausen und Wartezeiten. Da es technisch möglich 

ist, dass ein Agent mit einer Identifikationsnummer auch gleichzeitig in mehreren 

Kampagnen telefoniert, sind nur die unmittelbaren Gesprächs- und Nacharbeitsaktionen 

einer Kampagne zugeordnet. Bei der adm GmbH ist allerdings vorgesehen, dass jeder A- 

gent für jedes Projekt, in dem er telefoniert, eine eigene Identifikationsnummer erhält. 

96 

SOAP: Simple Object Access Protocol. Protokoll zum XML-basierten Datenaustausch.


Die Agenten-Aktionen und die Daten über Telefongespräche werden im Rahmen der On- 

Data-Komponente gespeichert. Die entscheidenden Relationen in der OnData-Datenbank 

sind ODActions und ODCalls (vgl. Tab. 13 und Tab. 14). Da das Hermes-System auch für 

Inbound-Telefonie nutzbar ist, enthalten die Relationen einige Attribute, die für die Outbound-Telefonie 

nicht relevant sind. 

4.2.3 Benutzeroberflächen 

Die Datenmasken der einzelnen Projekte sind Eigenentwicklungen, die stark an die Anforderungen 

des Auftraggebers angepasst sind (vgl. Abb. 14). In die Datenmasken sind die 

benötigten Plausibilitäsprüfungen eingebaut und die abzubildende Geschäftslogik integriert. 

Auf diese Weise können komplexe Produktauswahl-Listen und Fragebögen realisiert 

werden. 

Neben den unterschiedlichen Eigenentwicklungen kommt für einfache Projekte adato.Collections, 

eine Art elektronischer Checkbogen, zum Einsatz. Hierbei ist es den Projektverantwortlichen 

weitestgehend selbst möglich, die benötigte Logik zu implementieren 

und das Adressmanagement durchzuführen. Alle Benutzeroberflächen werden über den 

Apache-Webserver betrieben. 

Abb. 14 

Beispiel einer Benutzeroberfläche für Telefonagenten


4.2.4 Personalsysteme 

Das Personalsystem adato.Personnel wird gerade bei der adm GmbH eingeführt. Es wird 

das zentrale System für alle Personalprozesse und -daten im Unternehmen sein. Die Datenhaltung 

findet auf einem MySQL-Server statt. 

Bisher kommen Systeme zum Einsatz, die kaum Schnittstellen für andere Programme besitzen, 

wodurch Daten für das Berichtswesen von der Personalabteilung doppelt erfasst und 

gepflegt werden. 

Die Personalkosten werden daher momentan direkt im alten Berichtssystem erfasst. Hierfür 

wird jeder Agent mit seinem Kürzel und seinen Personalkosten pro Stunde hinterlegt. 

Tabelle Tab. 15 zeigt den Aufbau der verwendeten Kosten-Relation. 

4.3 Bisheriges Berichtswesen 

Das in die Hermes-Lösung integrierte Berichtssystem kann die Anforderung der adm 

GmbH nicht erfüllen. Zwar ist eine Auswertung der Agentenzeiten und eine einfache 

Auswertung der Ergebniscodes möglich, eine Einbeziehung der Daten des Client File oder 

eine Hinterlegung weiterer Geschäftslogik wie z.B. der erzielten Umsätze ist jedoch nicht 

möglich (vgl. Abb. 15). 

Das Hauptproblem der integrierten Lösung ist deren Architektur. Jeder Zugriff auf die Berichte 

erfolgt direkt auf das operative System, wodurch es mit größer werdendem Datenbestand 

zu Behinderungen der Produktion kommt.


Abb. 15 Auswertung der Agentenzeiten im Vocalcom-System 

(Quelle: Volcalcom Hermes.Net. – Interne Dokumentation, 2006) 

Um ein Controlling der Telefonie möglich zu machen, wurde unmittelbar nach der Einführung 

des Hermes-Systems eine Notlösung, adato.Reports, erstellt (vgl. Abb. 16). 

Hierzu werden die relevanten Telefonie-Daten am Ende eines Tages aus den Datenbanken 

extrahiert, aufbereitet und auf einem separaten Datenbankserver abgelegt. Diese Lösung 

wurde später durch mehrmalige Änderungen ergänzt, was kürzere Aktualisierungsabstände 

ohne Behinderung der Produktion möglich macht.


Abb. 16 

Auswertung der Agentenzeiten in adato.Reports 

Durch die Dringlichkeit bei der Erstellung der bisherigen Lösung besteht allerdings kein 

klares Konzept, so dass oftmals Veränderungen an der Struktur und Logik des Systems 

vorgenommen wurden. Das System ist mittlerweile ein Sammelwerk aus verschiedenen 

Programmen und Datenbanken, deren Wartung schwierig und fehleranfällig ist. 

Um ein finanzielles Controlling der Telefonie möglich zu machen, ist es unter anderem 

notwendig, die Personalkosten der Agenten zu berücksichtigen. Da hierfür keine Schnittstelle 

besteht, werden die Personalkosten im System von der Personalabteilung erfasst (vgl. 

Kapitel 4.2.4). Verzögerungen bei der Eingabe und dem Aktualisieren führen zu verfälschten 

Kostendaten. 

Mit zunehmender Datenmenge zeigen sich auch in der Geschwindigkeit der Auswertungen 

Schwächen.



Die adm GmbH betreibt mehrere Call Center in Deutschland und betreut Projekte für eine 

Vielzahl von Kunden. Zu den erbrachten Leistungen gehören sowohl Inbound- als auch 

Outbound-Projekte. 

Im Rahmen dieser Thesis werden speziell die Outbound-Projekte betrachtet. Die benötigten 

Daten befinden sich in den Dialer-Datenbanken sowie einigen Kunden-Tabellen. 

Das Berichtssystem des Dialer-Herstellers kann nicht alle Anforderungen der adm GmbH 

abbilden und hat die architektonische Schwäche, bei jedem Aufruf die volle operative Datenbasis 

zu benutzen. 

Die entwickelte Übergangslösung hat Schwächen bei der Verwaltung und Wartung und 

mit zunehmender Datenmenge auch bei der Leistung. Die Verknüpfung mit den Personaldaten 

geschieht im Moment mit einer Übergangslösung. In der Zukunft soll ein direkter 

Zugriff auf die Personalsysteme möglich sein. 

Um die architektonischen Schwächen der bestehenden Lösungen zu überwinden, wird im 

nächsten Kapitel ein Business Intelligence-Konzept für die Outbound-Telefonie entwickelt.

5. Sollkonzeption - 40 - 

5 Sollkonzeption 

Beim Konzipieren der Lösung orientiert sich die Arbeit am Business Dimensional Lifecycle 

von Ralph Kimball (vgl. Abb. 17). Die Arbeit deckt dabei die Module Business Requirements 

Definition (Definition der geschäftlichen Anforderungen), Dimensional Modelling 

(Design des dimensionalen Modells), Physical Design (Physisches Design) und ETL Design 

& Development (Design und Entwicklung der Extraktions-, Transformations- und 

Lade-Prozesse) sowie BI Application Specification (Spezifikation der BI-Anwendungen) 

und BI Application Development (Entwicklung der BI-Anwendungen) ab. Zum Sollkonzept 

sind die Phasen Definition der geschäftlichen Anforderungen, Design des dimensionalen 

Modells und Spezifikation der BI-Anwendungen zu zählen. 

Abb. 17 Business Dimensional Lifecycle – Konzeption 

(Quelle: Vgl. Mundy, J.; Thornthwaite, W.; Kimball, R.: The Microsoft Data Warehouse 

Toolkit. – Indianapolis (Wiley), 2006. S. 4) 

5.1 Definition der geschäftlichen Anforderungen 

Im ersten Schritt der Sollkonzeption werden die geschäftlichen Anforderungen an das System 

ermittelt und definiert. Dafür gilt es, die treibenden Unterstützer im Betrieb zu finden, 

die künftigen Anwender und Betroffenen zu befragen und involvierte Geschäftsprozesse zu 

analysieren. 97 

Der Definitionsprozess wird untergliedert in die Vorbereitung, das Durchführen der Interviews, 

die Analyse der Interviews, die Identifikation der Geschäftsprozesse und den Auf- 

97 

Vgl. MUND2006, S. 3ff


bau der Initial Data Warehouse Bus Matrix. Parallel findet eine erste Datenanalyse statt. 98 

Die Phase endet mit dem Erstellen des abschließenden Anforderungsdokuments. 99 

In der Vorbereitungsphase wird ein Grundverständnis für die Prozesse im Betrieb geschaffen, 

eine Vorauswahl der Interviewpartner festgehalten und ein Verständnis für Branchenspezifika 

erlangt. 100 

Im Rahmen von Interviews schildern die späteren Anwender einzeln oder in kleinen Gruppen 

ihre Sicht auf die Anforderungen. Der Vorteil von kleinen Interviewgruppen liegt in 

der größeren Wahrscheinlichkeit auch kritische Aussagen zu erhalten und in der geringeren 

Zeitbelastung für die einzelnen Befragten. 101 

Nach der Durchführung der Interviews werden diese zusammengefasst. Dabei werden keine 

Abschriften der Interviews angefertigt, sondern die Anforderungen des Interviewpartners 

an das System kategorisiert erfasst. Die Kategorien stellen grobe Analyse-Kategorien 

dar. 102 

Um die Interview-Ergebnisse zu validieren werden die Zusammenfassungen den Interview-Partnern 

zur Verfügung gestellt. Damit ist gewährleistet, dass es keine Missverständnisse 

gibt und Anpassungen noch in das abschließende Anforderungsmodell einfließen. 103 

In einer Data Warehouse Bus Matrix werden die ermittelten Geschäftsprozesse den potentiell 

ermittelten Dimensionen zugeordnet. Die Dimensionen ergeben sich aus den am Prozess 

beteiligten Geschäftsobjekten. 104 

In einer ersten Datenanalyse entsteht ein grobes Verständnis für die Quellsysteme und eine 

Einschätzung, ob die ermittelten Anforderungen umzusetzen sind oder ob bestimmte 

Quellsysteme bereits als wenig geeignet ausscheiden. 105 

Die ermittelten Anforderungen und Prozesse sowie deren detaillierte Beschreibungen bilden 

zusammen mit der Bus Matrix und den Interview-Zusammenfassungen das abschließende 

Anforderungsdokument. 106 

98 

99 

100 

101 

102 

103 

104 

105 

106 

Vgl. MUND2006, S. 9 

Vgl. MUND2006, S. 16 

Vgl. MUND2006, S. 10 

Vgl. MUND2006, S. 11 

Vgl. MUND2006, S. 12 

Vgl. MUND2006, S. 13 

Vgl. MUND2006, S. 15 

Vgl. MUND2006, S. 13 

Vgl. MUND2006, S. 16


5.1.1 Identifizierte Analyseziele 

Die Anforderungen an das System ergeben sich aus den Interviews, die vor der Einführung 

der Übergangslösung durchgeführt wurden, und den seitdem entstandenen Änderungswünschen. 

Die Interviews und Besprechungen fanden mit der Finanzabteilung, der Produktionsleitung, 

dem Qualitätsmanagement und mit einzelnen operativ betroffenen Personen 

aus Personalabteilung und Produktion statt. 

Neben den Interviews mit den Fachabteilungen wurden Gespräche mit IT- 

Verantwortlichen an allen Standorten geführt, um die Durchführbarkeit der Anforderungen 

zu überprüfen. 

Als Ziele für das System wurden dabei herausgearbeitet: 

• Unterstützung des Finanz-Controllings 

• Unterstützung des Berichtswesens und der Rechnungsstellung 

• Unterstützung der Mitarbeiterführung und -entwicklung 

• Unterstützung der Produktionsplanung 

• Vergleich von Plan- und Ist-Werten 

Das Finanz-Controlling soll durch das System leichter und mit geringerem Zeitverzug 

möglich sein. Die erzielten Umsätze, Kosten und Deckungsbeiträge der telefonierten Projekte 

und der Standorte müssen tagesaktuell abrufbar sein. Die finanzielle Entwicklung der 

Standorte und Projekte muss über einen größeren historischen Zeitraum bewertet werden 

können. 

Das interne und externe Berichtswesen soll durch das System unterstützt werden. Intern 

werden durch die Projektleitung unter anderem Wochenberichte erstellt, in die Produktionszahlen 

einfließen. Ebenfalls werden in einigen Projekten den Kunden regelmäßige Berichte 

zur Verfügung gestellt und teilweise auch als Grundlage für die Rechnungsstellung 

verwendet. 

Eine weitere Anforderung an das System ist die Unterstützung der Projektleitung und der 

Supervisoren bei der Mitarbeiterführung und Mitarbeiterentwicklung. Ohne Berichtssystem 

verbrachten die Projektverantwortlichen einen Großteil ihrer Arbeitszeit mit dem Zusammentragen 

von Informationen aus verschiedenen Quellsystemen. Die benötigten Zahlen 

sollen aufbereitet und schnell zur Verfügung stehen, damit die Projektverantwortlichen


sich um die Betreuung der Telefonagenten kümmern können und mehr Zeit mit der Analyse 

der Zahlen als mit dem Sammeln verbringen. 

Das System soll die Produktionsleitung bei der Planung des Personaleinsatzes unterstützen. 

Die Entwicklung der Erreichbarkeit und der Agenten-Wartezeiten in den einzelnen Projekten 

muss hierfür auswertbar sein. 

Für einige Kennzahlen soll auf Projektebene ein Vergleich von Plan- und Ist-Werten möglich 

werden. Eine spätere Version des Systems soll auch eine Auswertung des aktuellen 

Tages möglich machen. 

5.1.2 Beteiligte Prozesse und Geschäftsobjekte 

Die zu berücksichtigenden Geschäftsprozesse ergeben sich direkt aus den ermittelten Analysezielen 

des Systems. Der betroffene Geschäftsprozess ist die Telefonie der adm GmbH 

und der Vergleich der Ist-Daten mit den hinterlegten Planwerten. 

An den Prozessen sind die Geschäftsobjekte Zeit, Standort, Projekt, Telefonagent und Projektleiter 

beteiligt, die in einer Bus Matrix ins Verhältnis zu den Prozessen gesetzt werden 

(vgl. Tab. 3). 

Prozesse 

Geschäftsobjekte 

Zeit Standort Projekt Telefonagent Projektleiter 

Telefonie X X X X X 

Planung X X X 

Tab. 3 

Bus Matrix 

Die Objekte Zeit, Projekt und Standort werden sowohl vom eigentlichen Telefonie- 

Prozess, als auch von der Planung verwendet. Die Objekte Telefonagent und Projektleiter 

kommen nur beim Telefonie-Prozess zum Einsatz. Die Planung erfolgt auf aggregierter 

Ebene für das Datum, den Standort und das Projekt. 

5.1.3 Ergebnisse der ersten Datenanalyse 

Im untersuchten Fall sind die gewünschten Ziele mit Einschränkungen erreichbar. Angaben 

über Agentenarbeitszeiten, Nettokontakte und Abschlüsse stehen strukturiert zur Verfügung. 

Für die Verbindung mit den Kosten ist eine Anbindung der Personalsysteme notwendig. 

Da die Projekte unterschiedliche Methoden zur Ermittlung von Umsätzen, Verkäufen 

und Transfers verwenden, wird eine Abbildung der Logik im ETL-Prozess notwendig. 

Mit neuen Projekten sind zukünftig Änderungen zu erwarten, die immer wieder im 

ETL-Prozess abgebildet werden müssen. Die Zuordnung von Projekten zu Projektleitern


findet momentan in keinem Quellsystem statt, hierfür muss im Entwicklungsprozess eine 

Lösung gefunden werden. 

Die eindeutige Identifizierung von Telefonagenten ist bei der momentanen Struktur und 

dem noch fehlenden Personalsystem (vgl. 4.2.4) nicht ohne Fehler möglich. Pro Standort 

existiert ein Kürzel aus drei Zeichen, das zur gleichen Zeit nur einem Agenten zugeordnet 

werden kann. Das Kürzel wird als Teil des Namens im Dialer-System verwendet, da dort 

keine eigenen Felder angelegt werden können. Ein Kürzel kann beim Ausscheiden eines 

Mitarbeiters den Besitzer wechseln und ein Telefonagent kann theoretisch auch sein Kürzel 

wechseln. 

Bis zur Fertigstellung des Personalsystems werden Mitarbeiter, die an mehreren Standorten 

arbeiten, mehrfach geführt. Es muss ermöglicht werden, diese Instanzen später wieder zusammenzufügen. 

5.2 Design des dimensionalen Modells 

Der Prozess der dimensionalen Modellierung lässt sich unterteilen in die Vorbereitung, die 

erweiterte Datenanalyse, den Aufbau des dimensionalen Modells, die Detaillierung des 

Modells, das Testen des Modells und die Validierung und Revision des Modells. 

Die verschiedenen Rollen und Beteiligten werden vor dem Modellieren identifiziert. Bei 

größeren Business Intelligence-Projekten besteht das Projektteam aus mehreren Verantwortlichen 

(vgl. Tab. 4).


Teilnehmer 

Daten-Modellierer 

Analyst 

Data Steward 

Business Power User 

Quellsystem-Entwickler 

Datenbankadministrator 

ETL-Designer 

ETL-Entwickler 

Steuerungs-Komitee 

Zweck/Rolle 

Hauptverantwortlicher 

Analyse- und Quellsystem-Experte 

Abstimmung zwischen den Beteiligten über Namenskonventionen, 

Anforderungen und Geschäftslogik 

Beschreibung und Verfeinerung der Daten und Geschäftslogik 

aus Benutzer-Perspektive 

Quellsystem-Experte 

Design-Unterstützung 

ETL 

ETL 

Namenskonventionen, geschäftliche Anforderungen, 

Validierung des Modells 

Tab. 4 Mögliche Beteiligte am dimensionalen Modellierungsprozess 



Je mehr Personen teilnehmen, desto größer ist das Risiko, dass sich der Entwicklungsprozess 

verlangsamt. Allerdings erhöht eine höhere Teilnehmerzahl die Robustheit und Akzeptanz 

des Projekts. 107 

Der nächste Teil der Vorbereitung ist das Verstehen der Datenarchitektur-Strategie. An 

diesem Punkt werden grundsätzliche Fragen zur Datenarchitektur beantwortet. Welche 

Daten werden gespeichert, wie sind sie strukturiert und wo werden sie gespeichert? Mundy, 

Thornthwaite und Kimball empfehlen die Speicherung der Daten in atomarer Detailstufe 

auf der relationalen Datenbankplattform. 108 Atomare Detailstufe bedeutet hierbei nicht unbedingt 

die kleinste Detailstufe, die im Betrieb vorliegt, sondern lediglich klein genug, um 

den modellierten Geschäftsprozess abzubilden. 109 

Als nächstes werden die Anforderungen überprüft. Hierzu geht das Projektteam das Anforderungsdokument 

Schritt für Schritt durch, um die geschäftlichen Anforderungen zu verstehen 

und so die Anforderungen in ein flexibles dimensionales Modell zu übersetzen. 110 

Anschließend wird die Modellierungsumgebung eingerichtet. Dazu reichen bereits einfache 

Arbeitsblätter in einer Tabellenkalkulation, wie sie in Abb. 18 dargestellt sind. In diesen 

Arbeitsblättern werden die Kernelemente des logischen Modells sowie physische Attribute 

festgehalten. 111 

107 

108 

109 

110 

111 

Vgl. MUND2006, S. 75 

Vgl. MUND2006, S. 76 

Vgl. KIMB2002, S. 220 

Vgl. MUND2006, S. 76f 



Abb. 18 Ausschnitt eines Modellierungs-Arbeitsblatts 



Der Daten-Modellierer übernimmt die Analyse der Daten und der Quellsysteme. Dafür 

werden alle verfügbaren Quellsystem-Dokumentationen zusammengetragen und analysiert. 

Ebenso werden die Daten der Quellsysteme selbst betrachtet, da die Realität oftmals von 

den Dokumentationen abweicht. 112 

Häufig auftretende Probleme der Datenqualität sind: 113 

• Die Fremdverwendung von Feldern: 

Als ein neues Feld benötigt wurde, wurde die Datenbank nicht reorganisiert, sondern 

ein bestehendes Feld für den neuen Zweck benutzt. 

• Die Überladung einzelner Felder 

Als ein neues Feld benötigt wurde, wurde es nicht an die Datenbankstruktur angehängt, 

sondern in ein bestehendes Feld geschrieben und durch ein Trennzeichen 

von der bereits dort vorhandenen Information getrennt. 

• Variable Definitionen der Felder 

Ein Feld beherbergt unter verschiedenen Voraussetzungen, meist abhängig von der 

Ausprägung eines anderen Felds, unterschiedliche Daten. 

112 

113 

Vgl. MUND2006, S. 81 



• Freitext-Eingabefelder 

Teile der Daten wurden unstrukturiert in Freitextfeldern eingepflegt. 

Für die Datenanalyse gibt es auch Software, die die Analyse vereinfacht und verbessert. 

Die Software gibt Aufschluss über den Wertebereich und die Verteilung eines Attributs, 

Beziehungen zwischen Attributen, Beziehungen zwischen Tabellen, wiederholt auftretende 

Muster und Qualitätsprobleme. 114 

Ziel der Datenanalyse ist es, sicherzustellen, dass die Daten, die für das dimensionale Modell 

benötigt werden, vorhanden sind und die relevanten Geschäftslogiken und Beziehungen 

identifiziert werden. 115 

Weit größeren Aufschluss über die Quellsysteme bietet die Zusammenarbeit mit den 

Quellsystem-Experten. Dies sind z.B. Datenbankadministratoren, Entwickler und Personen, 

die für die Dateneingabe verantwortlich sind. 116 

Idealerweise existieren auch Kernanwender, die zur Informationsgenerierung bereits auf 

das System zugreifen. Diese haben die geschäftliche Perspektive auf die Daten und trotzdem 

genug Wissen über die Quellsysteme, um die vorhandenen Daten in die gewünschte 

Information zu transferieren. 117 

Bestehende Berichtssysteme sind oft ein idealer Ort, um die Geschäftslogik, die Quellsysteme 

und die Generierung von Informationen zu verstehen. Die Informationen sind allerdings 

oft im Quellcode verborgen, weshalb es nützlich sein kann, die Entwickler der Alt- 

Systeme zu involvieren. 118 

114 

115 

116 

117 

118 

Vgl. MUND2006, S. 82 

Vgl. MUND2006, S. 82 

Vgl. MUND2006, S. 83 

Vgl. MUND2006, S.84 



5.2.1 Auswahl der Prozesse und der Granularität 

Beim Aufbau des dimensionalen Modells erfolgt zuerst ein grober Modell-Entwurf, hierfür 

werden die Geschäftsprozesse ausgewählt, die Granularität festgelegt, die Dimensionen 

ausgewählt und die Fakten identifiziert. 119 

Als Geschäftsprozess wurde der bereits in Kapitel 5.1.2 vorgestellte Telefonie-Prozess und 

seine Planung ausgewählt. 

Als kleinste atomare Einheit ergibt sich für die Telefonie ein Eintrag pro Telefonagent, 

Projekt, Standort, Projektleiter und Arbeitstag. Auch wenn z.B. die Telefoniedaten detaillierter 

vorliegen, sollen diese bereits im ETL-Prozess aggregiert werden. Für die Planung 

gibt es einen Eintrag pro Projekt, Standort und Arbeitstag. Es findet im System keine Planung 

für einzelne Telefonagenten oder Projektleiter statt. 

Im Anschluss wird das grobe Modell grafisch dargestellt (vgl. Abb. 19 und Abb. 20). 

Abb. 19 

Grobes grafisches Modell des Prozesses Telefonie 

119 



Abb. 20 

Grobes grafisches Modell der Planung 

5.2.2 Fakten der Prozesse 

Als nächstes werden die Fakten identifiziert, die von den Prozessen erzeugt werden. Die 

Fakten werden geprägt von der gewählten Detailstufe und stellen lediglich die fundamentalen 

Fakten dar. Berechnete Fakten sind an dieser Stelle noch nicht zu berücksichtigen. 120 

Die Benennung der Fakten orientiert sich an der Benennung in den Altsystemen. 

Die fundamentalen Fakten des Telefonie-Prozesses sind: 

• Telefonzeit 

Die Zeit, die der Agent in Kundengesprächen verbringt. 

• Nacharbeitszeit 

Die Zeit, die der Agent nach Telefonaten mit der Erfassung von Daten verbringt. 

120 

Vgl. MUND2006, S. 87f


• Wartezeit 

Die Zeit, die ein Agent auf einen neuen Anruf wartet. 

• Erholungspausen-Zeit 

Die Zeit, die ein Agent in der Erholungspause verbringt. 

• WC-Pausen-Zeit 

Die Zeit, die ein Agent in der WC-Pause verbringt. 

• Coaching-Zeit 

Die Zeit, in der ein Agent geschult wird. 

• Teammeeting-Zeit 

Die Zeit, die ein Agent im Team-Meeting verbringt. 

• Administrations-Zeit 

Die Zeit, die ein Agent mit administrativen Projektaufgaben verbringt. 

• Systemfehler-Zeit 

Die Zeit, in der der Agent aufgrund von Fehlern am Telekommunikationssytem 

nicht arbeiten kann. 

• Sonderaufgaben-Zeit 

Die Zeit, in der ein Agent spezielle Aufgaben, wie die Zuarbeit für den Supervisor 

oder Projektleiter, durchführt. 

• EDV-Zeit 

Die Zeit, die ein Agent mit der Dateneingabe in Fremdsysteme verbringt. 

• Fax- und E-Mail-Zeit 

Die Zeit, die ein Agent mit der Abwicklung von Faxen, Briefen oder E-Mails verbringt.


• Alerting-Zeit 

Die Zeit, die für Systemaktionen des Dialers verbraucht wird und sich keiner anderen 

Zeit zuordnen lässt. 

• Pause ohne Code 

Zeit, in der der Agent in keinem definierten Zustand war. 

• Vorschau-Zeit 

Zeit, die der Agent in entsprechenden Kampagnen mit der Betrachtung der Datensätze 

vor dem Gespräch verbracht hat. 

• Supervisions-Zeit 

Zeit, in der Supervisionsaufgaben wahrgenommen wurden. 

• Anzahl Gespräche 

Die Anzahl der geführten Gespräche des Agenten. 

• Nettokontakte 

Die Anzahl der durch Kontakt mit der Zielperson terminierten Gespräche. 

• Abschlüsse 

Die Anzahl der erfolgreich durchgeführten Gespräche. 

• Verkäufe 

Die Anzahl der erfolgten Verkäufe. 

• Leads 1 

Die Anzahl der in zweiter Stufe erfolgreichen Gespräche nach erfolgtem Transfer 

in Multi-Level-Projekten. 121 

121 

In Multi-Level-Projekten werden die Kunden im Falle eines Verkaufes an einen weiteren Telefonagenten 

verbunden, der den Abschluss und die relevanten Daten mit dem Kunden verifiziert. Im Rahmen der 

Qualitätssicherung kann auch eine nachträgliche Weiterleitung an eine dritte Stufe erfolgen.


• Leads 2 

Die Anzahl der in dritter Stufe erfolgreichen Gespräche nach erfolgtem Transfer in 

Multi-Level-Projekten. 

• Transfers 

Die Anzahl der durchgeführten Transfers in Multi-Level-Projekten. 

• Umsatz 

Der erwirtschaftete Umsatz. 

• Kosten 

Die verursachten Lohnkosten. 

Die Fakten der Planung sind: 

• Geplante Menge eingespielter Daten 

• Geplante Anzahl von Nettokontakten 

• Geplante Anzahl von Abschlüssen 

• Geplanter Umsatz 

• Geplanter Deckungsbeitrag 

• Ziel- und Toleranzwerte für folgende Kennzahlen: 

o Nettokontakte pro Stunde 

o Abschlüsse pro Stunde 

o Erfolgsquote 

o Anteil der Telefonzeit an der Gesamtarbeitszeit 

o Anteil der Nacharbeitszeit an der Gesamtarbeitszeit 

o Anteil der Produktivzeit an der Gesamtarbeitszeit 

o Zum Erfolg führende Weiterleitungen pro Stunde


o Anteil der erfolgreichen Weiterleitungen pro Stunde an der Gesamtzahl von 

Nettokontakten 

Hierbei können ein Zielwert und insgesamt vier Schwellenwerte – zwei für Abweichungen 

nach oben und zwei für Abweichungen nach unten – definiert werden. 

5.2.3 Modellierung der Dimensionen 

Die benötigten Dimensionen, die sich aus den beteiligten Geschäftsobjekten ergeben, sind: 

• Datum 

• Standort 

• Projekt 

• Telefonagent 

• Projektleiter 

Die benötigten Dimensionen wurden während des Design-Prozesses mehrmals verändert. 

Das erste Modell bestand nur aus den Dimensionen Datum, Telefonagent und Projekt. Die 

Telefonagenten waren hierbei den Standorten untergeordnet. 

Wie sich herausstellte war das Hinzufügen einer eigenen Standort-Dimension notwendig, 

da einige Telefonagenten tatsächlich an mehreren Standorten eingesetzt werden. Selbst bei 

größerer räumlicher Trennung ist die Hinzunahme einer Standort-Dimension sinnvoll, da 

ein Standortwechsel eines Telefonagenten oder die kurzzeitige Aushilfe an einem anderen 

Standort denkbar ist. 

Die Projektleiter-Dimension soll es möglich machen, die Leistungen der Projektleiter besser 

zu vergleichen. Da sich die Zuordnung von Projektleitern zu Projekten ändern kann und 

auch ein Einsatz einer Person an mehreren Standorten möglich ist, wurde die Entscheidung 

für eine eigene Dimension getroffen.


Die Datums-Dimension erhält für viele denkbare Analysen ein passendes Attribut (vgl. 

Tab. 5). Neben dem Datum existiert z.B. die Kalenderwoche, der Monat, das Quartal und 

der Wochentag als Attribut. 

Attribut 

DatumKey 

VollesDatum 

DatumISO 

TagDerWoche 

NameDesTags 

TagDesMonats 

TagDesJahres 

TagesTyp 

WocheDesJahresID 

WocheDesJahres 

NameDesMonats 

MonatDesJahresID 

MonatDesJahres 

LetzterTagDesMonats 

QuartalID 

QuartalDesJahres 

Jahr 

JahrMonat 

JahrQuartal 

Tab. 5 

Attribute der Datums-Dimension 

Beschreibung 

Datum als Schlüssel (JJJJMMTT) 

Bsp.: 20070101, 20070430 

Volles Datum in deutscher Schreibweise 

(TT.MM.JJJJ) 

Bsp.: 01.01.2007, 30.04.2007 

Datum im ISO-Format (JJJJ-MM-TT) 

Bsp.: 2007-01-01 

Tagesnummer innerhalb einer Woche 

(1-7) 

Name des Tags 

Bsp.: Montag, Dienstag 

Nummer des Tages im Monat 

Bsp.: 1, 2, 31 

Nummer des Tages im Jahr 

Bsp.: 1, 2, 365 

Unterscheidung zwischen Werktag und Wochenende 

Bsp.: WT, WE 

Die ID der Kalenderwoche, bestehend aus Jahr und 

Wochennummer 

Bsp.: 2007001, 2007015 

Die Nummer der Kalenderwoche 

Bsp.: 1,2,52 

Der Name des Monats 

Bsp.: Januar, Februar, Dezember 

Die ID des Monats, bestehend aus Jahr und Monatsnummer 

Bsp.: 200701, 200712 

Die Nummer des Monats im Jahr 

Bsp.: 1, 2, 12 

Information, ob der Tag der letzte des Monats ist 

Bsp.: Y, N 

Die ID des Quartals, bestehend aus Jahr und Nummer 

Bsp.: 20071,20084 

Das Quartal des Jahres 

Bsp.: 1, 2, 4 

Das Kalenderjahr 

Bsp.: 2007, 2008 

Das Jahr und der Monat 

Bsp.: 2007-01, 2007-02 

Das Jahr und das Quartal 

Bsp.: 2007 I, 2007 II


Die Standort-Dimension wird aus einem Konfigurationssystem gespeist oder statisch angelegt. 

Die Standorte werden hierfür geografisch aufgegliedert (vgl. Tab. 6). 

Attribut 

DimStandortKey 

StandortKuerzel 

Kontinent 

Land 

Region 

Stadt 

StandortName 

Tab. 6 

Attribute der Standort-Dimension 

Beschreibung 

Künstlicher Schlüssel des Projektleiters 

Kürzel des Standorts 

Kontinent auf dem sich der Standort befindet 

Land in dem sich der Standort befindet 

Region bzw. Bundesland in dem sich der Standort 

befindet 

Stadt in der sich der Standort befindet 

Name des Standorts 

Auch die Projekt-Dimension erhält die Daten nicht direkt aus den operativen Systemen, 

sondern aus einer Konfigurationsdatenbank, in der alle relevanten Daten zu den Projekten 

gespeichert sind. Die verschiedenen Projekte lassen sich bestimmten Kunden und diese 

wiederum bestimmten Branchen zuordnen (vgl. Tab. 7). 

Attribut 

DimProjekteKey 

ProjektNummer 

ProjektBranche 

ProjektKunde 

ProjektName 

Tab. 7 

Attribute der Projekt-Dimension 

Beschreibung 

Künstlicher Schlüssel des Projekts 

Eigentlicher Geschäftsschlüssel aus dem Konfigurationssystem 

Die Branche des Kunden 

Bsp.: Versicherungen, Telekommunikation, Banken 

Der Name des Kunden 

Bsp.: Firma 1, Firma 2, Firma 3 

Der Name des Projekts 

Bsp.: Terminvereinbarung, Tarifwechsel


Die Telefonagenten-Dimension wird im ETL-Prozess aus den Produktivsystemen gebildet. 

Hierfür erfolgt ein Abgleich der im Dialer-System hinterlegten Benutzerkonten mit den 

Personalsystemen. 

Da sich das Vertragsverhältnis des Telefonagenten ändern kann, wird die Telefonagenten- 

Dimension als Slowly Changing Dimension 122 definiert. Da die vergangenen Daten von 

Änderungen nicht betroffen sein dürfen, wird die Dimension als Typ 2 – Slowly Changing 

Dimension mit Start- und Enddatum eingerichtet (vgl. Tab. 8). 

Attribut 

Beschreibung 

DimTelefonagentKey 

Künstlicher Schlüssel des Telefonagenten 

PersonalNummer 

Eigentlicher Geschäftsschlüssel aus dem Personalsystem 

Kuerzel 

Kürzel des Agenten 

Vorname 

Vorname des Agenten 

Nachname 

Nachname des Agenten 

VollerName 

Vor- und Nachname 

Vertragsverhaeltnis 

Information über den Anstellungsstatus des Agenten 

(Angestellter oder Leiharbeiter) 

validStart 

Beginn der Gültigkeit des Datensatzes 

validEnd 

Ende der Gültigkeit des Datensatzes 

Tab. 8 Attribute der Telefonagent-Dimension 

Die Projektleiter-Dimension wird aus einer Konfigurationsdatenbank gefüllt. Vorstellbar 

ist ein späterer Zugriff auf die Personaldatenbanken. Da sich die Position des Projektleiters 

ändern kann, wird auch diese Dimension als Typ 2-SCD definiert (vgl. Tab. 9). 

Attribut 

Beschreibung 

DimProjektleiterKey 

Künstlicher Schlüssel des Projektleiters 

PersonalNummer 

Eigentlicher Geschäftsschlüssel aus dem Personalsystem 

Vorname 

Vorname des Projektleiters 

Nachname 

Nachname des Projektleiters 

VollerName 

Vor- und Nachname 

Position 

Genaue Position des Projektleiters (Junior- 

Projektleiter, Projektleiter oder Senior-Projektleiter) 

validStart 

Beginn der Gültigkeit des Datensatzes 

validEnd 

Ende der Gültigkeit des Datensatzes 

Tab. 9 Attribute der Projektleiter-Dimension 

Die Fakten-Tabellen bestehen aus den entsprechenden Dimensionsschlüsseln, den am Anfang 

dieses Abschnitts festgehaltenen Fakten der Prozesse und einem Zählfakt, der das 

Zählen der Anzahl von Datensätzen vereinfachen soll. 

122 

Vgl. Kapitel 3.2.2


Die berechneten Fakten, die Summen, Differenzen oder Divisionen aus den elementaren 

Fakten sind, werden erst im OLAP-System gebildet. 

Bei der anschließenden Entwicklung des detaillierten dimensionalen Modells geht es um 

die Vervollständigung der fehlenden Informationen. Offene Punkte und Probleme werden 

behoben bzw. durch Alternativen gelöst. Ziel ist es, alle relevanten Attribute zu ermitteln 

und zu detaillieren, wo und wie diese Attribute gefüllt werden. 123 

Nachdem ein stabiles Modell entwickelt wurde, wird dieses anhand der geschäftlichen Anforderungen 

erprobt. Dabei wird mit der Fragestellung „Wie bekomme ich diese Information 

aus dem Modell?“ herangegangen. Das Anforderungsdokument kann bereits formulierte 

Tests enthalten. 124 

Nachdem das Modell die Tests erfüllt hat, geht es in die Phase der Revision und Validierung. 

In dieser Phase wird das Modell mit mehreren Benutzergruppen mit unterschiedlichem 

geschäftlichen und technischen Verständnis betrachtet. Abschließend wird das Modell 

einem breiteren Publikum präsentiert. Rückmeldungen können dann in das finale Modell 

eingearbeitet werden. 125 

5.3 Spezifikation der BI-Applikation 

Nachdem die geschäftlichen Anforderungen im dimensionalen Modell abgebildet wurden, 

wird spezifiziert, wie die Business Intelligence-Anwendungen, die auf das Modell zugreifen, 

umgesetzt werden sollen. 126 

Zur Spezifikation gehören fünf Aufgaben: 127 

• Festlegen einer einheitlichen Standardvorlage 

• Erstellen einer Liste der Zielberichte 

• Erstellen einer Beschreibung und Dokumentation für jeden Zielbericht 

• Design des Navigationssystems 

• Durchführen von Tests mit Benutzern 

123 

124 

125 

126 

127 

Vgl. MUND2006, S. 90 

Vgl. MUND2006, S. 91 

Vgl. MUND2006, S. 91 

Vgl. MUND2006, S. 362 

Vgl. MUND2006, S. 362


Eine einheitliche Standardvorlage ermöglicht es den Anwendern konsistent auf Informationen 

zuzugreifen. In der Vorlage wird die Anordnung der wiederkehrenden Standardelemente 

angegeben. 128 

Die wiederkehrenden Elemente eines Berichts sind der Berichtsname, der Berichtstitel, der 

Berichtskörper und der Kopf- und Fußbereich. Für den Berichtskörper wird festgelegt, 

welche Ausrichtungen, Präzisionen und Formate die einzelnen Elemente erhalten. 129 

Weitere zu definierende Elemente, die nicht auf dem Bericht auftauchen, sind: 130 

• Benutzer-Variablen und weitere Interaktionen wie Drill-Downs und Links 

• Metadaten (Beschreibung, Berechnungen, Erstellungsdatum, Autor) 

• Sicherheitsanforderungen 

• Ausführungs-Rhythmus 

• Auslösendes Ereignis 

• Auslieferungsmethoden (E-Mail, Website, Dateisystem, Drucker) 

• Auslieferungsliste (z.B. E-Mail-Verteiler) 

• Ausgabeformat (Text, HTML, PDF, Excel, Word) 

Um die Liste der Zielberichte zu erstellen, werden die Interview-Dokumente nochmals 

verarbeitet und Anforderungen, Wünsche, Fantasien und Hoffnungen der Anwender gesammelt. 

131 

Die Kandidaten werden in einer Kandidatenliste festgehalten und erhalten einen Berichtsnamen 

sowie eine numerische Einschätzung bezüglich ihrer Wichtigkeit für das Geschäft 

und des notwendigen Erstellungsaufwands. Weiterhin werden die Namen der anfordernden 

Personen sowie weitere vermutete Nutzer des Berichts notiert. 132 Für die Kandidatenliste 

eignet sich ein einfaches Arbeitsblatt einer Tabellenkalkulation. 

128 

129 

130 

131 

132 

Vgl. MUND2006, S. 362 

Vgl. MUND2006, S. 363 

Vgl. MUND2006, S. 364 

Vgl. MUND2006, S. 365 

Vgl. MUND2006, S. 365


Die Berichte werden dann priorisiert und gruppiert. Die Liste wird mit einer kleineren 

Gruppe kompetenter Anwender überprüft. 133 

Jeder einzelne Bericht wird nun spezifiziert. Dazu gehören eine Beschreibung der verwendeten 

Vorlage, ein Muster, eine Benutzer-Interaktions-Liste und eine detaillierte Dokumentation. 

Das Muster ist eine Vorlage, deren Struktur gefüllt ist. In der Benutzer- 

Interaktionsliste werden alle Interaktionsmöglichkeiten, die ein Benutzer in einem Bericht 

hat, aufgeführt. In einer detaillierten Dokumentation werden die bisher nicht erfassten Informationen 

notiert. Dazu gehören z.B. die Kategorie und die verwendeten Datenquellen. 

134 

Die Berichte werden kategorisiert und in das Navigationssystem einsortiert. Die dabei entstandene 

Hierarchie orientiert sich an den Geschäftsprozessen, so dass sich Benutzer mit 

Prozesswissen leicht zurechtfinden. 135 

Nachdem die Spezifikationen geschrieben sind, werden sie nochmals mit einer größeren 

Anwendergruppe besprochen, um zu gewährleisten, dass die Spezifikationen verständlich 

und die Prioritäten richtig gewählt sind. 136 

5.3.1 Festlegen von Standards 

Die Standardvorlage ist in Abb. 21 dargestellt. Neben dem Firmenlogo befinden sich im 

Kopf des Berichts die Navigationskategorie, der Berichtstitel und, sofern vorhanden, der 

Berichts-Untertitel. Ebenso sind die Ausführungszeit, die benutzten Parameter und der 

gewählte Berichtszeitraum im Kopf zu finden. Im Fußbereich sind die aktuelle Seitennummer, 

der Berichtsname und die verwendete Datenquelle angegeben. 

133 

134 

135 

136 

Vgl. MUND2006, S. 365 

Vgl. MUND2006, S. 368-370 

Vgl. MUND2006, S.370 

Vgl. MUND2006, S.370


Abb. 21 

Berichts-Standardvorlage 

Die Ausrichtung von Tabellenzellen im Berichtsinhalt ist bei Zahlenwerten rechts- und bei 

sonstigen Werten linksbündig. Zahlen- und Prozentwerte werden kaufmännisch auf zwei 

Stellen nach dem Komma gerundet. Die Titel- und Summenzeilen der Tabellen werden fett 

dargestellt. Der Bericht hat als Hintergrundfarbe Weiß, in Tabellendarstellungen können 

blaue Farbtöne benutzt werden. 

5.3.2 Ermittlung und Spezifikation der Zielberichte 

Insgesamt werden für die erste Phase des Systems zehn Zielberichte definiert (vgl. Tab. 

10). Diese sind in zwei Kategorien eingeordnet: 

• das Finanz- und Projektcontrolling und 

• die Mitarbeiterführung und –entwicklung


Nr. Berichtsname Kategorie Besitzer Nutzen Aufwand 

1 Gesamtübersicht 1 LFP 7 3 

2 Projektleistung am Standort 1 CCL 9 3 

3 Branchen und Kunden-Übersicht 1 LFP 6 4 

4 CEO-Cockpit 1 GF 6 4 

5 Agentenleistung pro Projekt 2 CCL 9 3 

6 Supervisions-Auswertung 2 CCL 8 3 

7 Arbeitszeitauswertung 2 CCL 8 3 

8 Projektübergreifende Agentendetails 2 CCL 8 4 

9 Projektleiter-Auswertung 2 CCL 5 3 

10 Low Performer 2 CCL 6 5 

Tab. 10 

Liste der Berichtskandidaten 

Die Berichte der Kategorie Finanz- und Projektcontrolling sind: 

• Gesamtübersicht 

Die Gesamtübersicht listet für den gewählten Zeitraum die summierten Kennzahlen 

der einzelnen Standorte und die Gesamtsumme auf. 

Der anzuzeigende Zeitraum kann durch den Benutzer gewählt werden. Der Standortname 

ist verlinkt mit dem Bericht Projektleistung am Standort. Der Bericht ist 

sichtbar für die Geschäftsführung und die Call Center-Leiter. 

• Projektleistung am Standort 

In diesem Bericht werden alle Projekte für den gewählten Zeitraum und den gewählten 

Standort aufgelistet. 

Der anzuzeigende Zeitraum und der Standort können durch den Benutzer gewählt 

werden. Der Projektname ist verlinkt mit dem Bericht Agentenleistung pro Projekt. 

Der Bericht ist sichtbar für die Geschäftsführung, die Call Center-Leiter und die 

Projektleiter des gewählten Standorts. 

• Branchen- und Kundenübersicht 

In diesem Bericht erfolgt eine Gruppierung nach Branchen und Kunden. 

Der anzuzeigende Zeitraum kann durch den Benutzer gewählt werden. Der Benutzer 

kann durch einen Klick auf die Branche einen Drill-Down auf die Kunden- und 

Projektebene machen. Der Bericht ist sichtbar für die Geschäftsführung und die 

Call Center-Leiter.


• CEO-Cockpit 

Das CEO-Cockpit enthält einen hochaggregierten Überblick über die finanziellen 

Kennzahlen für festgelegte Zeiträume. Umsätze, Kosten und Deckungsbeiträge 

werden grafisch im Verlauf dargestellt. 

Der Bericht ist sichtbar für die Geschäftsführung. 

Die Berichte der Kategorie Mitarbeiterführung und -entwicklung sind: 

• Agentenleistung pro Projekt 

In diesem Bericht werden alle Telefonagenten für den gewählten Zeitraum und das 

gewählte Projekt aufgelistet. 

Der anzuzeigende Zeitraum und das Projekt können durch den Benutzer gewählt 

werden. Der Name des Telefonagenten ist verlinkt mit dem Bericht Projektübergreifende 

Agentendetails. Der Bericht ist sichtbar für die Geschäftsführung, die Call 

Center-Leiter und die Projektleiter des gewählten Standorts. 

• Supervisions-Auswertung 

Der Bericht entspricht dem Bericht Agentenleistung pro Projekt, enthält jedoch keine 

finanziellen Kennzahlen. 




Center-Leiter, die Personalabteilung, die Projektleiter, die Trainer und die Supervisoren 

des gewählten Standorts. 

• Arbeitszeitauswertung 

In diesem Bericht wird die Arbeitszeit der Telefonagenten detailliert aufgegliedert. 





des gewählten Standorts.


• Projektübergreifende Agentendetails 

In diesem Bericht wird für den gewählten Zeitraum die projektübergreifende Leistung 

des Telefonagenten angezeigt. 

Der anzuzeigende Zeitraum und der Telefonagent können durch den Benutzer gewählt 

werden. Die einzelnen Projektnamen sind mit dem Bericht Agentenleistung 

pro Projekt verlinkt. Der Bericht ist sichtbar für die Geschäftsführung, die Call 


des gewählten Standorts. 

• Projektleiter-Auswertung 

In diesem Projekt lässt sich die Leistung der Projekte der einzelnen Projektleiter 

auswerten. 

Der anzuzeigende Zeitraum kann durch den Benutzer gewählt werden. Der Bericht 

ist sichtbar für die Geschäftsführung und die Call Center-Leiter. 

• Low Performer 

Dieser Bericht gibt einen Überblick über die Telefonagenten mit der schlechtesten 

Leistung. Hierfür werden die Agenten aufsteigend nach dem erzielten Deckungsbeitrag 

sortiert. 

Der anzuzeigende Zeitraum kann durch den Benutzer gewählt werden. Der Name 

des Telefonagenten ist verlinkt mit dem Bericht Projektübergreifende Agentendetails. 

Der Bericht ist sichtbar für die Geschäftsführung, die Call Center-Leiter und 

die Projektleiter des gewählten Standorts. 

Die Berichte werden in der Pilotphase einmal täglich im Anschluss an den ETL-Prozess 

ausgeführt und über einen internen Webserver zum Abruf bereitgestellt. 


In Anlehnung an das Business Dimensional Lifecycle-Modell von Kimball gliedert sich die 

Konzeption in die Definition der geschäftlichen Anforderungen, das Design des dimensionalen 

Modells und die Spezifikation der BI-Applikationen. 

Als Analyseziele werden die Unterstützung des Finanzcontrollings, die Unterstützung des 

Berichtswesens und der Rechnungsstellung, die Unterstützung der Mitarbeiterführung und


-entwicklung, die Unterstützung der Produktionsplanung und der Vergleich von Plan- und 

Ist-Werten definiert. 

Der zu analysierende Prozess ist die Outbound-Telefonie der adm GmbH und seine Planung. 

Die Geschäftsobjekte, die für den Prozess eine Rolle spielen, sind die Telefonagenten, 

die Projekte, die Standorte, die Projektleiter und die Zeit. 

Eine erste Datenanalyse ergab, dass die Analyseziele abbildbar sind, es aber gerade im 

Bereich der eindeutigen Identifikation der Telefonagenten und der Ermittlung der Personalkosten 

Nacharbeit bedarf, sobald die neuen Personalsysteme im Einsatz sind. 

Aus den ermittelten Prozessen und Objekten ergeben sich die Granularität und die Dimensionen 

für das Modell. Ein Fakt des Telefonie-Prozesses wird an den Schnittpunkten der 

Dimensionen Datum, Standort, Telefonagent, Projekt und Projektleiter betrachtet. Die 

Planung erfolgt verdichtet mit den Dimensionen Datum, Standort und Projekt. 

Für die zu entwickelnde Anwendung werden Standards definiert und eine Liste der benötigten 

Zielberichte angefertigt. Diese Berichte werden beschrieben, kategorisiert und priorisiert. 

Als Kategorien werden das Finanz- und Projektcontrolling und die Mitarbeiterführung 

und -entwicklung definiert. Die Berichte sollen einmal täglich generiert werden und 

über eine Web-Oberfläche im Intranet zur Verfügung stehen. 

Die Konzeptentwicklung erfolgt unabhängig von einem bestimmten Software-Produkt. So 

bleibt die Auswahl flexibel und das Konzept mit verschiedenen Lösungen umsetzbar. Im 

folgenden Kapitel dieser Thesis wird das Konzept prototypisch mit dem Microsoft SQL 

Server 2005 umgesetzt.

6. Umsetzung mit Microsoft SQL Server 2005 - 65 - 

6 Umsetzung mit Microsoft SQL Server 2005 

Das in Kapitel 5 erarbeitete Konzept wird in diesem Kapitel mit den Komponenten des 

Microsoft SQL Server 2005 prototypisch umgesetzt. Die Phase des physischen Designs 

wird hierbei mit der relationalen Datenbank, die ETL-Entwicklung mit den Integration 

Services und die BI-Applikations-Entwicklung mit den Reporting Services umgesetzt. Die 

Entwicklung der OLAP-Datenbank in den Analysis Services findet parallel dazu statt (vgl. 

Abb. 22). 

Abb. 22 Business Dimensional Lifecycle – Umsetzung 



6.1 Physisches Design 

Durch die Modellierung des logischen dimensionalen Modells in den in Kapitel 5.2 vorgestellten 

Arbeitsblättern, ist für die Überführung in das physische Modell kaum noch Anpassungsarbeit 

nötig. 137 

Die Relationen des Modells werden im der Datenbank DWH angelegt, die das relationale 

Data Warehouse bildet (vgl. Abb. 23 und Abb. 24). 

137 

Vgl. MUND2006, S. 157


Abb. 23 

Relationen im Data Warehouse 

Abb. 24 

Physisches Datenmodell


6.2 Design und Entwicklung der ETL-Prozesse 

Die Daten werden einmal täglich nach dem Ende der Telefonie aktualisiert. So ist gewährleistet, 

dass die Daten des Tages nicht mehr von Änderungen betroffen sind. Es werden nur 

Daten verarbeitet, die seit der letzten Aktualisierung hinzugekommen sind, ein Neueinlesen 

bereits erfasster Daten ist nicht nötig. 

Es ist nicht geplant, Daten nach einem bestimmten Alter zu löschen. In das System werden 

initial historische Daten, die seit dem 01.01.2005 entstanden sind, eingespielt. Diese werden 

aus dem alten Berichts-System extrahiert und transformiert. 

Neben der eigentlichen Data Warehouse-Datenbank aus Kapitel 6.1 werden drei weitere 

Datenbanken definiert, die während des ETL-Prozesses benötigt werden. 

Eine Datenbank enthält Konfigurationsdaten und Daten, die zwar anwachsen, aber keinen 

oder nur seltenen Änderungen unterliegen (vgl. Abb. 25). 

Abb. 25 

Relationen in der Konfigurationsdatenbank CONFIG 

Die zweite Datenbank enthält die Daten, die historisiert gespeichert werden (vgl. Abb. 26). 

So ist es möglich, beim Nachimport eines bestimmten Datums auf ein Abbild des Datenbestandes 

des betroffenen Tages zuzugreifen, obwohl sich der operative Datenbestand mittlerweile 

verändert hat.


Abb. 26 

Relationen in der Historisierungsdatenbank HISTORY 

Die dritte Datenbank ist die Staging Area, in der beim ETL-Prozess Zwischenschritte der 

Verarbeitung gespeichert werden (vgl. Abb. 27). 

Abb. 27 

Relationen und Sichten in der Staging Area 

Die Extraktion, Transformation und das Laden der Daten wird mit SQL Server Integration 

Services (SSIS) umgesetzt. Dabei sind die einzelnen Arbeitsschritte in Pakete unterteilt, 

die über ein Master-Paket gesteuert werden (vgl. Abb. 28).


Durch die Modularisierung einzelner Arbeitsschritte wird die Behandlung von Fehlern 

vereinfacht. Ebenso können die Pakete in verschiedenen Prozessen wiederverwendet werden. 

Abb. 28 

SSIS Master-Paket 

Als Vorbereitung wird das zu bearbeitende Datum festgelegt. Dies geschieht bei der planmäßigen 

Tagesextraktion durch das Paket Prep_Datum (vgl. Abb. 37). Das aktuelle Datum 

wird hier per Skript ermittelt und zum Abruf durch die folgenden Pakete in der Konfigurationsdatenbank 

gespeichert. Das Paket Prep_Kosten überträgt die Stundenlöhne der Telefonagenten 

aus dem alten Berichtssystem (vgl. Abb. 38 und Abb. 39). 

In der nächsten Phase werden die operativen Daten, deren historischer Verlauf festgehalten 

wird, in die HISTORY-Datenbank transferiert. 

Das Paket Hist_Aktionen holt die relevanten Agentenaktionen des gewählten Tages von 

den verschiedenen Dialer-Datenbanken und führt sie zusammen (vgl. Abb. 40 und Abb. 

41). Die Daten werden mit dem zugehörigen Datum in der HISTORY-Datenbank abgespeichert. 

Zu beachten sind hierbei die unterschiedlichen Datentypen der Dialer-Generationen 

und die unterschiedliche Genauigkeit der erfassten Agentenaktionen. 

Im Paket Hist_Logins werden die Agenten-Tabellen der Dialer-Systeme ausgelesen und 

die eindeutigen Personen ermittelt sowie die tagesaktuelle Login-Zuordnung zu Personen, 

Projekten und dem Mitarbeiterstatus vorgenommen (vgl. Abb. 42, Abb. 43 und Abb. 44). 

Neu gefundene Personen werden in der Konfigurations-Datenbank gespeichert. Die Login-


Informationen werden mit dem aktuellen Datum in der HISTORY-Datenbank gespeichert. 

Solange keine Anbindung an die neuen Personalsysteme möglich ist, wird in diesem Paket 

auch eine künstliche Personalnummer vergeben und verwaltet. Die Agenten-Daten werden 

von überflüssigen Leerzeichen bereinigt und die im operativen System in einem einzelnen 

Feld gespeicherten Kürzel und Vornamen werden getrennt. 

Im Paket Hist_Projektleiter werden die Projektleiter-Daten und die Zuordnung von Projektleitern 

zu Projekten mit dem Datum in die HISTORY-Datenbank übertragen (vgl. Abb. 

45 und Abb. 46). 

Das Paket Hist_Toleranzen überträgt die hinterlegten Toleranz- und Zielwerte der Projekte 

und speichert sie mit Datum in der HISTORY-Datenbank ab (vgl. Abb. 47 und Abb. 48). 

Die Standort- und Projektkonfigurationen werden nicht historisiert, da Änderungen hier 

nur Korrekturen sein können, die dann auch für die Vergangenheit gelten. 

Die nächsten Pakete selektieren Daten in der HISTORY-Datenbank und übertragen sie in 

die Staging Area. 

Die Pakete Staging_Logins, Staging_Projektleiter, Staging_Toleranzen übertragen die Telefonagenten-Daten, 

die Projektleiter und Projektzuordnungen sowie die Toleranzen des 

gewählten Datums ohne weitere Transformationen von der HISTORY-Datenbank in die 

Staging Area (vgl. Abb. 49 bis Abb. 54). 

Im Paket Staging_Aktionen werden die Agenten-Aktionen noch weiter aufbereitet (vgl. 

Abb. 55, Abb. 56 und Abb. 57). Mittels Datenbanksichten werden die einzelnen Aktionen 

pivotisiert, so dass für jeden Telefonagenten-Login eine Zeile mit allen möglichen Zeitwerten 

entsteht. Diese Zeiten werden anschließend in Stundenwerte umgerechnet. 

In der nächsten Phase werden die Dimensionen verarbeitet. Die erforderlichen Arbeitsschritte 

sind unterschiedlich komplex. Bei der Projekt-Dimension und der Standortdimension 

handelt es sich um Slowly Changing Dimensions vom Typ 1. Daher werden bei Änderungen 

die Attributswerte überschrieben. Die Pakete Dim_Projekt und Dim_Standort fügen 

bei neuen Projekten oder Standorten lediglich neue Zeilen hinzu und bearbeiten die vorhandenen 

Einträge bei Änderungen (vgl. Abb. 58, Abb. 59, Abb. 60 und Abb. 61). 

Die Telefonagent- und die Projektleiter-Dimension hingegen sind Slowly Changing Dimensions 

vom Typ 2, der Verlauf von Änderungen einiger Attribute wird also festgehalten. 

Das Verlaufsattribut bei den Telefonagenten ist das Vertragsverhältnis. Es muss auch bei 

einem Wechsel vom Leiharbeitnehmer zum festangestellten Telefonagenten die Vergangenheit 

korrekt ausgewertet werden können. Genauso ist beim Projektleiter das Attribut


Position zu behandeln. Die Pakete Dim_Projektleiter und Dim_Telefonagent fügen neue 

Zeilen zu den Dimensionstabellen hinzu, bearbeiten die Zeilen mit änderbaren Attributen 

und deaktivieren nicht mehr gültige Zeilen (vgl. Abb. 62 bis Abb. 65). 

Die Datums-Dimension wird im Paket Dim_Datum verarbeitet (vgl. Abb. 66 und Abb. 67). 

Einträge werden per VB.Net-Skript für den bisher vorhandenen Datenbestand, für die 

nächsten drei vollständigen Jahre und für den Rest des aktuellen Jahres erstellt, sofern sie 

noch nicht vorhanden sind. So ist gewährleistet, dass die Datums-Dimension ausreichend 

für die Erfassung von Plandaten gefüllt ist. Die Berechnung der einzelnen Datumsattribute 

– wie z.B. Quartal, Kalenderwoche und Wochentag wird ebenfalls im Skript durchgeführt. 

Wenn die Dimensionen auf dem aktuellen Stand sind und die weiteren Daten sich in der 

Staging Area befinden, werden die Faktentabellen verarbeitet. 

Das Paket Facts_Telefonie durchläuft für alle aktiven Projekte mehrere Arbeitsschritte 

(vgl. Abb. 68 bis Abb. 80). So werden für jedes Projekt auf Telefonagenten-Ebene die Nettokontakte, 

die Abschlüsse, die Umsätze, die Transfers und Leads und die Verkäufe berechnet. 

Je nach Projekttyp müssen hier die verschiedenen Methoden abgebildet werden. 

Teilweise erfolgt ein Zugriff auf die Client-Datenbanken auf den verschiedenen MySQL- 

Servern. 

Im Paket Facts_Planung werden die Planungs-, Toleranz- und Zielwerte verarbeitet und in 

die Faktentabelle geschrieben (vgl. Abb. 81 und Abb. 82). 

Nachdem das relationale Data Warehouse gefüllt ist, wird mit dem Paket AS_Processing 

eine Aktualisierung der Analysis Services-OLAP-Daten veranlasst (vgl. Abb. 83). Diese 

sind im folgenden Abschnitt beschrieben. 

Die besonderen Herausforderungen im Verlauf der ETL-Entwicklung waren: 

• Der Zugriff auf MySQL-Datenbanken 

Der Zugriff auf die MySQL-Datenquellen ist komplizierter als der Zugriff auf die 

MSSQL-Datenquellen. Während die verschiedenen MS-SQL-Server als verknüpfte 

Server auf dem lokalen Server problemlos dynamisch abzufragen sind, müssen die 

Verbindungen zu den MySQL-Servern statisch hergestellt werden. 

• Die unterschiedliche Projektstruktur an den Standorten 

Die Struktur der Client Files ist an den verschiedenen Standort nicht einheitlich. 

Dies führt zu einer Erschwerung der Umsatz-, Transfer- und Verkaufsermittlung.


• Telefonagenten mit unterschiedlichen Logins an einem Tag in einem Projekt 

Aufgrund von technischen Schwierigkeiten kam es während der Entwicklung vor, 

dass Agenten an einem Tag mit mehreren Logins in einem Projekt telefonierten. Da 

die Zuordnung der Agenten lediglich über das Kürzel vorgenommen wurde, kam es 

zu Fehlern beim Verarbeiten der Fakten. Als Lösung werden nun vor dem Einspielen 

noch die Agentenaktionen pro Projekt summiert. 

6.3 OLAP-Design in Analysis Services 

Das OLAP-Design findet in den Analysis Services (SSAS) statt. Basis für die Measure- 

Gruppen in den Analysis Services sind die Faktentabellen FactsTelefonie und FactsPlanung. 

Die Grundlage für die Dimensionen bilden die Dimensionstabellen DimProjekt, 

DimProjektleiter, DimTelefonagent, DimStandort und DimDatum (vgl. Abb. 29). 

Abb. 29 

Dimensionsverwendung im OLAP-System 

Aus den fundamentalen Fakten werden im OLAP-Modell berechnete und abgeleitete Fakten 

gebildet (vgl. Abb. 30). Dies sind zum einen die Summierungen der relevanten Zeiten 

zu Arbeitszeiten und Produktivzeiten, zum anderen die Verhältnisse der einzelnen Zeiten 

an der Gesamtarbeitszeit. Weiterhin werden Abschlussquoten und Leistungsdaten pro Zeiteinheit 

errechnet und der Deckungsbeitrag 1 aus dem Umsatz und den Kosten gebildet.


Abb. 30 

Definition der berechneten Fakten 

In den Dimensionen werden Hierarchien gebildet. Für die Telefonagenten-Dimension und 

die Projektleiter-Dimension werden vorerst keine Hierarchien erstellt. Die Standorte sind 

gegliedert nach Kontinent, Land, Region, Stadt und Standortname (vgl. Abb. 31). 

Abb. 31 

Hierarchisierung der Standort-Dimension 

Die Projekte sind gegliedert in Branche, Kunde, Projektname und Projektnummer (vgl. 

Abb. 32).


Abb. 32 

Hierarchisierung der Projekt-Dimension 

Das Datum wird gegliedert nach Jahr, Quartal, Monat und Tag (vgl. Abb. 33). 

Abb. 33 

Hierarchisierung der Datums-Dimension 

Die Analysis Services ermöglichen eine Datenhaltung in relationaler, multidimensionaler 

und hybrider Form. 138 Als Modus für das Modell wird multidimensionales OLAP gewählt. 

Ein späterer Wechsel auf die hybride Form wird erst mit vergrößertem Datenbestand evaluiert. 

138 

Vgl. AZEV2006, S. 234f


Da die beiden Faktentabellen unterschiedliche Dimensionen verwenden, werden noch einige 

Anpassungen vorgenommen, damit nur die gewünschten Informationen im Cube angezeigt 

werden. Ein Zusammenführen von Fakten aus beiden Measure Groups hat zur Folge, 

dass Telefonagenten eines Projektes angezeigt werden, obwohl sie im gewählten Zeitraum 

nicht telefoniert haben. Da aber für die Projekte Toleranz- und Zielwerte hinterlegt sind, 

würden die Agenten mit den potentiellen Werten angezeigt werden. Ebenso muss erreicht 

werden, dass die Toleranzwerte nicht über die Projekte hinaus summiert werden. 

Dieses Verhalten wird durch MDX-Bedingungen 139 umgangen, die sich auf eine definierte 

Dimensionsumgebung, den Scope, beziehen. 

Abb. 34 

Einschränkung der Fakten auf Bedingungen 

Im Beispiel von Abb. 34 wird für die Zielkennzahl Nettokontakte pro Stunde definiert, dass 

sie nur angezeigt wird, wenn ein Zeiteintrag für den Agenten bzw. das Projekt existiert. 

Weiterhin wird eingeschränkt, dass die Kennzahl nicht angezeigt wird, wenn sie auf der 

Hierarchieebene Kunde betrachtet wird. 

6.4 Entwicklung der Berichte in Reporting Services 

Die unter 5.3.2 definierten Berichte werden mit den SQL Server Reporting Services 

(SSRS) umgesetzt (vgl. Anhang C). 

Die Standardelemente der Berichtsvorlage werden in die Kopf- und Fußbereiche integriert. 

Für die Berichte Gesamtübersicht, Projektleistung am Standort, Agentenleistung pro Projekt, 

Supervisions-Auswertung, Arbeitszeitauswertung, Projektübergreifende Agentendetails, 

Branchen- und Kundenübersicht und Projektleiterauswertung wird die Datenanbindung 

an die Analysis Services per Assistent durchgeführt. Eine Anpassung der MDX- 

Statements ist nur bei den Berichten Low Performer und CEO-Cockpit notwendig. Da der 

vom Assistenten generierte Aufruf allerdings nicht optimiert ist, kann eine Anpassung auch 

139 

MDX: Multidimensional Expressions. Eine SQL-verwandte Abfragesprache für OLAP-Datenbanken.


bei den restlichen Berichten sinnvoll sein. Für den Low Performer-Bericht werden die Daten 

des gewählten Zeitraums aufsteigend nach Deckungsbeitrag pro Stunde sortiert (vgl. 

Abb. 35). 

Abb. 35 

MDX-Datendefinition in den Reporting Services 

Die Farbcodierung der Kennzahlen in Bezug auf ihre Toleranz- und Zielwerte kann in Reporting 

Services mit bedingter Formatierung umgesetzt werden. 140 Die Kennzahlen werden 

dementsprechend in den zulässigen Granularitätsstufen je nach Zielerreichung grün, 

schwarz, gelb oder rot formatiert. Die Berichte werden per IIS-Webserver 141 auf dem Berichts-Server 

bereitgestellt und sind für die Anwender per Intranet-Zugriff mit einem 

Browser abrufbar (vgl. Abb. 36). 

Abb. 36 

Berichtsansicht im Web-Browser 

140 

141 

Vgl. SCHU2006, S. 133f und DRÖG2006, S. 252f 

IIS: Internet Information Services. Webserver von Microsoft.


Die Zuweisung von Berechtigungen und Bereitstellungsoptionen wird über das SQL Server 

Management Studio definiert. 

Die Benutzer haben über das Intranet die Möglichkeit, die angezeigten Berichte in andere 

Dateiformate, unter anderem Excel und PDF, umzuwandeln. Fortgeschrittene Benutzer 

haben die Möglichkeit, eigene Berichte über die Web-Oberfläche anzufertigen. 


Der Microsoft SQL Server 2005 wird in der prototypischen Konzeptumsetzung als relationales 

Data Warehouse, als ETL-Werkzeug, als OLAP-Server und zur Generierung und 

Bereitstellung von Berichten verwendet. 

Insgesamt werden vier Datenbanken angelegt: das eigentliche Data Warehouse, eine Konfigurationsdatenbank, 

eine Datenbank um eine Historie von operativen Daten zu speichern 

und eine Staging Area, die während des ETL-Prozesses benutzt wird. 

Der ETL-Prozess wird mit den SQL Server Integration Services umgesetzt. Die angelegten 

Pakete sind dabei modular aufgebaut, um sie leichter warten und wiederverwenden zu 

können. 

Die meisten Arbeitsschritte sind in den Integration Services von Assistenten und intuitiven 

Bedienoberflächen unterstützt, für manche Transformationen sind jedoch komplexere Anpassungen 

bzw. die Programmierung in VB.Net nötig. 

Als OLAP-Server werden die Analysis Services benutzt. Auch hier gilt, dass die wesentlichen 

Funktionen von der Benutzeroberfläche unterstützt werden, für komplexere Arbeitsschritte 

aber fortgeschrittenes Werkzeug-Wissen und MDX-Sprachkenntnisse erforderlich 

sind. 

Zur Erstellung von Berichten werden die Reporting Services benutzt. Wie bei den Analysis 

Services sind für fortgeschrittene Anforderungen auch bei den Reporting Services MDX- 

Kenntnisse nötig.

7. Ergebnisse und Ausblick - 78 - 

7 Ergebnisse und Ausblick 

Ziel der Thesis war die Entwicklung eines Business Intelligence-Konzepts für die Outbound-Telefonie 

der adm GmbH und die prototypische Umsetzung mit den Werkzeugen 

des SQL Server 2005 von Microsoft. Da Microsoft verspricht, dass der SQL Server 2005 

alle Werkzeuge mitbringt, um Business Intelligence-Systeme zu managen, zu entwickeln 

und bereitzustellen, galt es zu untersuchen, ob das Konzept vollständig umsetzbar ist. 142 

Dafür wurden die Besonderheiten des Controllings im Call Center herausgearbeitet und ein 

Überblick über involvierte Systeme und Kennzahlen gegeben. Danach wurden die verwendeten 

Business Intelligence-Methoden vorgestellt und die Ausgangslage bei der adm 

GmbH erläutert. Es folgte die Entwicklung des Business Intelligence-Konzepts für die Call 

Center der adm GmbH und die prototypische Umsetzung mit den Werkzeugen des Microsoft 

SQL Servers 2005. 

Durch die mit der Entwicklung des Prototyps gewonnenen Erfahrungen lässt sich feststellen, 

dass die Umsetzung von Business Intelligence-Konzepten mit den Werkzeugen des 

Microsoft SQL Servers 2005 möglich ist. Die relationale Datenbank dient als Data Warehouse, 

die Integration Services als ETL-Werkzeug, die Analysis Services als OLAP-Server 

und die Reporting Services als Berichtsserver. Damit verfügt das Produkt über Komponenten, 

die alle drei Ebenen der Business Intelligence unterstützen. 

Die Anforderungen aus dem entwickelten Konzept für die adm GmbH sind zum Großteil 

ohne Programmierkenntnisse umsetzbar, speziellere Anforderungen bei den Analysis Services 

und den Reporting Services können durch Anpassungen der MDX-Abfragen realisiert 

werden. In den Integration Services können komplexere Transformationen durch Programmierung 

in VB.Net durchgeführt werden. 

Falls der SQL Server 2005 bereits als Datenbankserver im Unternehmen vorhanden ist, 

muss demnach nicht in weitere Business Intelligence-Produkte investiert werden. 

Die weitere Entwicklung des noch jungen Produkts ist aufmerksam zu verfolgen. Bei einem 

Marktanteil von über 30% und einem klaren Bekenntnis von Microsoft zum Engagement 

auf dem Gebiet der Business Intelligence, ist durchaus mit zukünftigen Produktverbesserungen 

zu rechnen. 143 Zu untersuchen sind weiterhin die verbesserte BI-Integration in 

Microsoft Office 2007 und die kommende Business Performance Management-Lösung 

von Microsoft. 

142 

143 

Vgl. MCKN2006, S. 4 

Stand: Ende 2006. Vgl. PEND2007

7. Ergebnisse und Ausblick - 79 - 

Verglichen mit der alten Berichtslösung der adm GmbH lässt sich eine gesteigerte Leistung 

beim Einlesen der Produktionsdaten feststellen. Insbesondere die Kommunikation mit den 

verschiedenen Dialer-Datenbanken ist mit der entwickelten Lösung spürbar schneller. 

Wichtiger als die Geschwindigkeit sind jedoch die vereinfachte Wartung und die geringere 

Fehleranfälligkeit des Systems. 

Für die Anwender ergeben sich neue Zugriffsmöglichkeiten auf die Berichte. So steht ein 

einfacher Excel-, PDF- und CSV-Export direkt aus der Anwendung zur Verfügung. Fortgeschrittene 

Anwender können mit dem Report Manager eigene Berichte erstellen. 

In der Zukunft verschiebt sich die BI-Ausrichtung weiter vom strategischen ins operative: 

die Benutzeranzahl, die Detailliertheit der Tagesberichte, die größeren Datenmengen und 

die Abrufgeschwindigkeiten werden näher an operative Systeme heranrücken. 144 Es ist zu 

untersuchen, ob die verwendeten Werkzeuge auch diese Anforderungen erfüllen. 

Sobald das neue Personalsystem der adm GmbH fertig gestellt und im Einsatz ist, müssen 

die bisherigen Behelfslösungen für die Ermittlung eindeutiger Personen und ihrer Kosten 

abgelöst werden. 

In den nächsten Projektphasen müssen die bisherigen Berichte validiert und Veränderungsund 

Erweiterungswünsche ermittelt werden. Insbesondere ist zu prüfen, bei welchen Berichten 

der Einsatz von grafischen Elementen zu höherem Nutzen führen kann. Danach 

kann eine Integration der Inbound-Telefonie stattfinden, was eine ganzheitliche Controlling-Sicht 

auf das Unternehmen ermöglichen wird. 

144 

Vgl. IMHO2006, S. 17f

Literaturverzeichnis - XI - 

Literaturverzeichnis 

AZEV2006 

BANG2006 

Azevedo, P.; Brosius, G. et al: Business Intelligence und Reporting 

mit Microsoft SQL Server 2005. – Unterschleißheim (Microsoft 

Press), 2006 

Bange, C.: Werkzeuge für analytische Informationssysteme. In: 

Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. 

– 3. Auflage – Berlin (Springer), 2006 

BAUE2004 Bauer, A.; Günzel, H.: Data Warehouse Systeme. – 2. Auflage – 

Heidelberg (dpunkt), 2004 

BAUM2005 

Baumgartner, M.; Udris, I.: Call Center ist nicht gleich Call Center. 

– ETH Zürich, 2006 

http://www.call.ifap.ethz.ch/ 

Abrufdatum: 05.01.2007 

BÖSE1999 

BUSC2006 

Böse, B.; Flieger, E.: Call Center - Mittelpunkt der Kundenkommunikation. 

– Braunschweig (Vieweg), 1999 

Busch, C.: Ergebnisbericht Callcenter-Trendstudie 2006 für Studienteilnehmer. 

– Frankfurt/Main, 2006 

CHAM2006 Chamoni, P.; Gluchowski, P.: Analytische Informationssysteme – 

Einordnung und Überblick. In: Chamoni, P.; Gluchowski, P. (Hrsg.): 

Analytische Informationssysteme. – 3. Auflage – Berlin (Springer), 

2006 

CLAU1998 

CODD1993 

DINT2006 

Clausen, N.: OLAP - Multidimensionale Datenbanken. – Bonn (Addison 

Wesley Longman), 1998 

Codd, E.; Codd, S.; Salley, C.: Providing OLAP to User Analysts: 

An IT Mandate. 1993 

http://dev.hyperion.com/resource_library/white_papers/ 

providing_olap_to_user_analysts.pdf 

Abrufdatum 28.02.2007 

Dinter, B.; Bucher, T.: Business Performance Management. In: 

Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. 

– 3. Auflage – Berlin (Springer), 2006

Literaturverzeichnis - XII - 

DRÖG2006 

GLUC2006 

Dröge, R.; Raatz, M.: Microsoft SQL Server 2005 – Konfigurierung, 

Administration, Programmierung. – 2. Auflage – Unterschleißheim 

(Microsoft Press), 2006 

Gluchowski, P.; Kemper, H.: Quo Vadis Business Intelligence? – In: 

BI-Spektrum 01-2006, S. 12 - 19. 2006 

GREF2003 Greff, G.; Fojut, S.: Das ABC des Call Center Management. – 2. 

Auflage – Wiesbaden (Gabler), 2003 

HELB2004 Helber, S.; Stolletz, R.: Call Center Management in der Praxis. – 

Berlin (Springer), 2004 

HOLT2000 

Holthuis, J.: Grundüberlegungen für die Modellierung einer Data 

Warehouse-Datenbasis. In: Mucksch, H.; Behme, W. (Hrsg.): Das 

Data Warehouse-Konzept. – 4. Auflage – Wiesbaden (Gabler), 2000 

HORV2006 Horváth, P.: Controlling. – 10. Auflage – München (Vahlen), 2006 

HUMM1998 

IMHO2006 

Hummeltenberg, W.: Data Warehousing: Management des Produktionsfaktors 

Information – eine Idee und ihr Weg zum Kunden. In: 

Martin, W. (Hrsg.): Data Warehousing. – Bonn (International Thomson 

Publishing), 1998 

Imhoff, C.: Operational business intelligence. In: Teradata Magazine. 

September 2006, S. 16 – 18. 2006 

http://www.intelsols.com/documents/ 


INMO2002 

KEMP2004 

KEMP2006a 

Inmon, W.: Building the Data Warehouse. – 3. Auflage – Indianapolis 

(Wiley), 2002 

Kemper, H.; Mehanna, W.; Unger, C.: Business Intelligence. Grundlagen 

und praktische Anwendungen. – Wiesbaden (Vieweg), 2004 

Kemper, H.; Mehanna, W.; Unger, C.: Business Intelligence. Grundlagen 

und praktische Anwendungen. – 2. Auflage – Wiesbaden (Vieweg), 

2006

Literaturverzeichnis - XIII - 

KEMP2006b 

Kemper, H.; Finger, R.: Transformation operativer Daten – Konzeptionelle 

Überlegungen zur Filterung, Harmonisierung, Aggregation 

und Anreicherung im Data Warehouse. In: Chamoni, P.; Gluchowski, 

P. (Hrsg.): Analytische Informationssysteme. – 3. Auflage 

– Berlin (Springer), 2006 

KIMB2002 Kimball, R.; Ross, M.: The data warehouse toolkit. – 2. Auflage – 

Indianapolis (Wiley), 2002 

KIMB2004 

KNIG2006 

LUST1999 

MCKN2006 

Kimball, R.; Caserta, J.: The data warehouse ETL toolkit. – Indianapolis 

(Wiley), 2004 

Knight, B.; Mitchell, A. et al: Professional SQL Server 2005 Integration 

Services. – Indianapolis (Wiley), 2006 

Lusti, M.: Data Warehousing und Data Mining. – Berlin (Springer), 

1999 

McKnight, W.: Choosing Microsoft SQL Server 2005 for Data 

Warehousing. Microsoft Whitepaper. 2006 

http://www.microsoft.com/sql/techinfo/whitepapers/ 

Abrufdatum: 26.01.2007 

MENZ1999 

MUCK2000 

MUCK2006 

Menzler-Trott, E. (Hrsg.): Call Center-Management. – München 

(Beck), 1999 

Mucksch, H.; Behme, W.: Das Data Warehouse-Konzept als Basis 

einer unternehmensweiten Informationslogistik. In: Mucksch, H.; 

Behme, W. (Hrsg.): Das Data Warehouse-Konzept. – 4. Auflage – 

Wiesbaden (Gabler), 2000 

Mucksch, H.: Das Data Warehouse als Datenbasis analytischer Informationssysteme 

– Architektur und Komponenten. In: Chamoni, 

P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. – 3. 

Auflage – Berlin (Springer), 2006 

MUELL2007 Müller, W.: Automatisierung im Call Center. Software- 

Unterstützung verbessert den Kundenservice. In: is report. Ausgabe 

1+2/2007. S. 16 – 23. 2007 

MUND2006 

Mundy, J.; Thornthwaite, W.; Kimball, R.: The Microsoft Data 

Warehouse Toolkit. – Indianapolis (Wiley), 2006

Literaturverzeichnis - XIV - 

OEHL2006 

PAFF2002 

Oehler, K.: Corporate Performance Management mit Business Intelligence 

Werkzeugen. – München (Hanser), 2006 

Paff, C.: Call Center und ihre Standortanforderungen. Eine empirische 

Untersuchung des Standortes Hannover. Diplomarbeit an der 

Universität Hannover, 2002 

PEND2005 Pendse, N.: The OLAP Report: What is OLAP? 2005 

http://www.olapreport.com/fasmi.htm 


PEND2007 Pendse, N.: OLAP Market share analysis. 2007 

http://olapreport.com/market.htm 


PIET2003 

PRAC2005 

Pietsch, T.; Memmler, T.: Balanced Scorecard erstellen. – Berlin 

(Erich Schmidt), 2003 

Pracht, S.: Outbound kennt keine Routine. In: Aquisa. Ausgabe 

11/2005. S. 60 – 63. 2005 

REIN2005 

REPP2007 

SCHE2004 

Reiner, M.: Web Customer Contact Centre in virtuellen Organisationen. 

Diplomarbeit an der Fachhochschule Furtwangen, 2005 

Reppesgaard, L.: In die Krise geschlittert. Business Intelligence 

soll’s richten. In: Computerwoche Mittelstand. Ausgabe 1/07. S. 44 

– 45. 2007 

Schechner, M.: Konzeptionierung und prototypische Realisierung 

einer Business Intelligence Lösung für die Tochtergesellschaften der 

Schering AG. Diplomarbeit an der FHTW Berlin, 2004 

SCHR2006 Schrödl, H.: Business Intelligence mit Microsoft SQL Server 2005. – 

München (Hanser), 2006 

SCHU2006 

SCHÜ2006 

Schulz, M.; Knuth, J.; Pruß, V.: Microsoft SQL Server 2005 Reporting 

Services - Das Praxisbuch – Unterschleißheim (Microsoft 

Press), 2006 

Schümann, F.; Tisson, H.: Call Center Controlling. – Wiesbaden 

(Gabler), 2006

Literaturverzeichnis - XV - 

TEWS2001 

THIE2004 

THUR2003 

VARX2004 

Tews, M.: Entwicklung und Implementierung einer Prozesskostenrechnung 

im Call-Center. Diplomarbeit an der FHTW Berlin, 2001 

Thiele, T.: Markenbewertung innerhalb des strategischen Controllings 

mit Business Intelligence-Werkzeugen. Diplomarbeit an der 

FHTW Berlin, 2004 

Thurnheer, A.: Temporale Auswertungsformen in OLAP. Dissertation 

an der Universität Basel, 2003 

von Arx, C.; Huber, M.: Analyse eines Callcenters. Diplomarbeit an 

der Zürcher Hochschule Winterthur, 2004 

VOCA2006 Volcalcom Hermes.Net. – Interne Dokumentation, 2006 

WEBE1999 Weber, J.; Grothe, M.; Schäffer, U.: Advanced Controlling, Band 13: 

Business Intelligence. Schriftenreihe an der WHU Koblenz, 1999 

WEBE2004 

Weber, J.: Einführung in das Controlling – 10. Auflage – Stuttgart 

(Schäffer-Poeschel), 2004

Anhang - XVI - 

Anhang 

A 

Datenstruktur der Quellsysteme 

Attribut Datentyp Beschreibung 

INDICE Int(4) Die ID des Datensatzes 

PRIORITE Int(4) Die Priorität des Datensatzes. 0 bei noch offenen Datensätzen 

DATE Varchar(8) Das Datum des letzten Anwahlversuchs 

HEURE Varchar(4) Die Uhrzeit des letzten Anwahlversuchs 

VERSOP Int(4) Der nächste zugewiesene Agent (Nur bei persönlichen Wiedervorlagen) 

RAPPEL Varchar(13) Enthält bei Wiederanrufen das gewünschte Datum und die Uhrzeit 

sowie die Information, ob es sich um einen allgemeinen oder einen 

persönlichen Wiederanruf handelt 

TV Varchar(62) Der Name des zuletzt involvierten Agenten 

ID_TV Int(4) Die ID des zuletzt involvierten Agenten 

STATUS Int(4) Der Status des Datensatzes als Nummer 

LIB_STATUS Varchar(50) Der Status des Datensatzes als Klartext 

LIB_DETAIL Varchar(50) Detailstatus als Klartext 

HISTORIQUE Varchar(254) Nicht verwendet 

TEL1 Varchar(20) Die Telefonnummer des Kunden 

ERRN1 Int(4) Eventuelle ISDN-Protokollfehler, die beim Anruf der Nummer auftraten 

TEL2 Varchar(20) Eventuelle weitere Telefonnummer des Kunden 


















TEL Varchar(20) Nicht verwendet 

NBAPPELS Int(4) Anzahl der stattgefundenen Gespäche 

DUREE Int(4) Dauer der stattgefundenen Gespräche

Anhang - XVII - 

NIVABS Int(4) Anzahl der Anwahlversuche 

MEMORAPPEL Varchar(13) Nicht verwendet 

MEMOVERSOP Int(4) Nicht verwendet 

TZBEGIN Varchar(4) Nicht verwendet 

TZEND Varchar(4) Nicht verwendet 

DATAMEMO Nvarchar(100) Informationen, die dem Agenten direkt in der Dialer-Applikation angezeigt 

werden sollen (z.B. Vorname und Nachname des Kunden) 

INTERNAL Int(4) Interner Status. Bestimmt, wie mit dem Datensatz weiter verfahren 

wird. Wird vom Dialer vergeben 

RETRYLATER Int(4) Interner Status. Bestimmt, wie mit dem Datensatz weiter verfahren 

wird. Wird vom Dialer vergeben 

Tab. 11 Die Struktur der Call File-Relationen 


Id Int(11) ID des Datensatzes 

Anrede Varchar(255) Anrede des Kunden 

Vorname Varchar(255) Vorname des Kunden 

Nachname Varchar(255) Nachname des Kunden 

Firma Varchar(255) Firma des Kunden 

Strasse Varchar(255) Straße des Kunden 

Hausnummer Varchar(255) Hausnummer des Kunden 

PLZ Varchar(255) Postleitzahl des Kunden 

Ort Varchar(255) Wohnort des Kunden 

Vorwahl Varchar(10) Vorwahl des Kunden 

Telefon Varchar(255) Telefonnummer des Kunden 

Aktionsnummer Varchar(50) Projektabhängige Daten 

Anzahl_Vertraege Varchar(10) Projektabhängige Daten 

Sonderfall Varchar(255) Projektabhängige Daten 

Neu_Strasse Varchar(255) Bei Adressänderung 

Neu_Hausnummer Varchar(255) Bei Adressänderung 

Neu_PLZ Varchar(255) Bei Adressänderung 

Neu_Ort Varchar(255) Bei Adressänderung 

Neu_Vorwahl Varchar(10) Bei Telefonnummeränderung 

Neu_Telefon Varchar(255) Bei Telefonnummeränderung 

Dialertelefon Varchar(50) An den Dialer übermittelte Rufnummer 

Internstatus Varchar(4) Bearbeitungsstatus 

Ma Varchar(4) ID des Mitarbeiters, der den Datensatz zuletzt bearbeitet hat 

Code Varchar(4) Ergebniscode des Datensatzes 

Subcode Varchar(3) Detail-Ergebniscode des Datensatzes 

Eintrag Varchar(20) ISO-Datum des letzen Speicherns 

Datum Varchar(10) Datum in deutscher Schreibweise 

Uhrzeit Varchar(5) Uhrzeit des letzten Speicherns 

Export Int(1) Export-Flag 

NewNr Varchar(30) Alternative ermittelte Rufnummer 

ImportDate Datetime Datum des Imports 

ImportFilename Varchar(100) Dateiname der Import-Datei 

ExportDate Datetime Datum des Exports 

Sperre Int(1) Sperr-Flag 

Tab. 12 Eine typische Client File-Relation

Anhang - XVIII - 


ID Char(32) ID des Datensatzes 

ActionUniversalTime datetime Die Uhrzeit der Aktion in GMT 

ActionLocalTime datetime Die Uhrzeit der Aktion in lokaler Zeit 

ActionUniversalTimeString Varchar(14) Die GMT-Uhrzeit als Zeichenkette 

ActionLocalTimeString Varchar(14) Die lokale Uhrzeit als Zeichenkette 

OriginatorID Varchar(250) Die ID des Agenten 

CustomerID Int(4) Bei Systemen, die für mehrere Call Center-Betreiber unterhalten 

werden, erfolgt hier die Unterscheidung der einzelnen 

Anbieter 

OriginatorType Char(1) Hier wird angegeben, ob die Aktion von einem Agenten oder 

vom System durchgeführt wurde 

State Int(4) Bezeichnet die ausgeführte Aktion 

Duration Int(4) Die Dauer der Aktion 

EndReason Int(4) Bei manchen Aktionen wird ein Grund für das Aktionsende 

angegeben 

CallID Char(32) Wenn zu der Aktion ein Telefonat gehört, befindet sich hier 

die ID des Telefonats 

Tab. 13 

Die Relation ODActions

Anhang - XIX - 


ID Char(32) ID des Datensatzes 

CtiID Varchar(50) Unbenutzt 

CustomerID Int(4) Bei Systemen, die für mehrere Call Center-Betreiber unterhalten 

werden, erfolgt hier die Unterscheidung der einzelnen Anbieter 

Indice Numeric(9) ID des Kundendatensatzes 

CallType Int(4) Unterscheidung zwischen Inbound- und Outbound-Telefonaten 

CallUniversalTime datetime Die Uhrzeit des Telefonats in GMT 

CallLocalTime datetime Die Uhrzeit des Telefonats in lokaler Zeit 

CallUniversalTimeString Varchar(14) Die GMT-Uhrzeit als Zeichenkette 

CallLocalTimeString Varchar(14) Die lokale Uhrzeit als Zeichenkette 

Duration Int(4) Die Gesamtdauer des Gesprächs 

AcceptDuration Int(4) Nicht verwendet 

IvrDuration Int(4) Die Dauer, die im IVR verbracht wird 

WaitDuration Int(4) Die Wartezeit 

ConvDuration Int(4) Die Gesprächszeit 

RerouteDuration Int(4) Rerouting-Zeit 

OverflowDuration Int(4) Overflow-Zeit 

ANI Varchar(50) Die Nummer des Anrufers 

DNIS Varchar(50) Die gewählte Nummer 

FirstCampaign Varchar(50) Die erste Kampagne, in der der Anruf stattfindet 

LastCampaign Varchar(50) Die letzte Kampagne, in der der Anruf stattfindet (Wenn er in 

eine andere Kampagne transferiert wurde) 

UUI Varchar(250) User-To-User-Information. Kann benutzt werden, um beim 

Transfer von Gesprächen Informationen an die nachfolgenden 

Agenten zu übergeben 

Memo Varchar(250) Informationen zum Kunden, die an den Agenten übermittelt 

werden können 

AssociatedData Varchar(250) Nicht verwendet 

OutTel Varchar(50) Nummer, die angerufen werden sollte 

OutDialed Varchar(50) Nummer, die angerufen wurde 

Closed Int(4) Nur Inbound. Information, ob das Projekt zur Zeit des Anrufs 

inaktiv war 

NoAgent Int(4) Information, ob zur Zeit des Anrufs kein Agent frei war 

Overflow Int(4) Nur Inbound. Information, ob zur Zeit des Anrufs ein Overflow 

stattfand 

Abandon Int(4) Information, ob das Gespräch abgebrochen wurde 

FirstIVR Varchar(250) Nur Inbound. Erste IVR-Komponente, die mit dem Anruf in 

Verbindung war 

LastIVR Varchar(250) Nur Inbound. Letzte IVR-Komponente, die mit dem Anruf in 

Verbindung war 

FirstQueue Int(4) Die erste Kampagne, in der der Anruf stattfindet 

LastQueue Int(4) Die letzte Kampagne, in der der Anruf stattfindet (Wenn er in 

eine andere Kampagne transferiert wurde) 

InitPriority Int(4) Priorität des Anrufs. 

FirstAgent Int(4) Der erste Agent, der den Anruf entgegennahm 

LastAgent Int(4) Der letzte Agent, der den Anruf entgegennahm 

LastTransfer Varchar(50) Das letzte Transferziel 

CallStatusGroup Int(4) Die Statuscode-Gruppe 

CallStatusNum Int(4) Der Status des Gesprächs als Nummer 

CallStatusDetail Int(4) Der Status des Gesprächs im Klartext 

Comments Varchar(250) Nicht verwendet 

ContactID Varchar(50) Nicht verwendet 

Tab. 14 Die Relation ODCalls

Anhang - XX - 


Kuerzel Char(3) Pro Standort eindeutiges Agentenkürzel, bestehend aus drei Zeichen 

Standort Char(1) Der Standort des Agenten 

Kosten Double Die Kosten, die der Agent pro Arbeitsstunde verursacht 

Vorname Varchar(50) Der Vorname des Agenten 

Nachname Varchar(50) Der Nachname des Agenten 

Tab. 15 Kosten-Relation

Anhang - XXI - 

B 

Integration Services-Pakete 

Abb. 37 

SSIS-Paket Prep_Datum – Kontrollfluss 

Abb. 38 

SSIS-Paket Prep_Kosten – Kontrollfluss 

Abb. 39 

SSIS-Paket Prep_Kosten – Datenfluss

Anhang - XXII - 

Abb. 40 

SSIS-Paket Hist_Aktionen – Kontrollfluss 

Abb. 41 

SSIS-Paket Hist_Aktionen – Datenfluss 

Abb. 42 

SSIS-Paket Hist_Logins – Kontrollfluss

Anhang - XXIII - 

Abb. 43 SSIS-Paket Hist_Logins – Datenfluss 1

Anhang - XXIV - 

Abb. 44 SSIS-Paket Hist_Logins – Datenfluss 2 

Abb. 45 

SSIS-Paket Hist_Projektleiter – Kontrollfluss

Anhang - XXV - 

Abb. 46 

SSIS-Paket Hist_Projektleiter – Datenfluss 

Abb. 47 

SSIS-Paket Hist_Toleranzen – Kontrollfluss 

Abb. 48 

SSIS-Paket Hist_Toleranzen – Datenfluss 

Abb. 49 

SSIS-Paket Staging_Logins – Kontrollfluss

Anhang - XXVI - 

Abb. 50 

SSIS-Paket Staging_Logins – Datenfluss 

Abb. 51 

SSIS-Paket Staging_Projektleiter – Kontrollfluss 

Abb. 52 

SSIS-Paket Staging_Projektleiter – Datenfluss 

Abb. 53 

SSIS-Paket Staging_Toleranzen – Kontrollfluss

Anhang - XXVII - 

Abb. 54 

SSIS-Paket Staging_Toleranzen – Datenfluss 

Abb. 55 

SSIS-Paket Staging_Aktionen – Kontrollfluss 

Abb. 56 SSIS-Paket Staging_Aktionen – Datenfluss 1

Anhang - XXVIII - 

Abb. 57 SSIS-Paket Staging_Aktionen – Datenfluss 2 

Abb. 58 

SSIS-Paket Dim_Projekt – Kontrollfluss 

Abb. 59 

SSIS-Paket Dim_Projekt – Datenfluss 

Abb. 60 

SSIS-Paket Dim_Standort – Kontrollfluss

Anhang - XXIX - 

Abb. 61 

SSIS-Paket Dim_Standort – Datenfluss 

Abb. 62 

SSIS-Paket Dim_Projektleiter – Kontrollfluss 

Abb. 63 

SSIS-Paket Dim_Projektleiter – Datenfluss 

Abb. 64 

SSIS-Paket Dim_Telefonagent – Kontrollfluss

Anhang - XXX - 

Abb. 65 

SSIS-Paket Dim_Telefonagent – Datenfluss 

Abb. 66 

SSIS-Paket Dim_Datum – Kontrollfluss 

Abb. 67 

SSIS-Paket Dim_Datum – Datenfluss

Anhang - XXXI - 

Abb. 68 

SSIS-Paket Facts_Telefonie – Kontrollfluss

Anhang - XXXII - 

Abb. 69 SSIS-Paket Facts_Telefonie – Datenfluss 1 

Abb. 70 SSIS-Paket Facts_Telefonie – Datenfluss 2

Anhang - XXXIII - 



Anhang - XXXIV - 




Anhang - XXXV - 



Anhang - XXXVI - 




Anhang - XXXVII - 

Abb. 81 

SSIS-Paket Facts_Planung – Kontrollfluss 

Abb. 82 

SSIS-Paket Facts_Planung – Datenfluss 

Abb. 83 

SSIS-Paket AS_Processing – Kontrollfluss

Anhang - XXXVIII - 

C 

Reporting Services-Berichte 

Abb. 84 

SSRS-Bericht Gesamtübersicht 

Abb. 85 

SSRS-Bericht Projektleistung am Standort

Anhang - XXXIX - 

Abb. 86 

SSRS-Bericht Agentenleistung pro Projekt 

Abb. 87 

SSRS-Bericht Supervisions-Auswertung

Anhang - XL - 

Abb. 88 

SSRS-Bericht Arbeitszeitauswertung 

Abb. 89 

SSRS-Bericht Projektübergreifende Agentendetails

Anhang - XLI - 

Abb. 90 

SSRS-Bericht Branchen- und Kunden-Übersicht 

Abb. 91 

SSRS-Bericht Projektleiter-Auswertung

Anhang - XLII - 

Abb. 92 

SSRS-Bericht CEO-Cockpit 

Abb. 93 

SSRS-Bericht Low Performer

Abschließende Erklärung - XLIII - 

Abschließende Erklärung 

Ich versichere hiermit, dass ich meine Masterthesis Business Intelligence im Call Center 

mit Microsoft SQL Server 2005 selbstständig und ohne fremde Hilfe angefertigt habe, und 

dass ich alle von anderen Autoren wörtlich übernommenen Stellen wie auch die sich an die 

Gedankengänge anderer Autoren eng anlehnenden Ausführungen meiner Arbeit besonders 

gekennzeichnet und die Quellen angegeben habe. Die Thesis hat keiner anderen Prüfungsbehörde 

vorgelegen und ist noch nicht veröffentlicht. 

Berlin, den 30. April 2007 

Thomas Christian Thiele

Freie wissenschaftliche Arbeit zur Erlangung des ... - Thomas Thiele

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?