Volker Uminski
Immatrikulationsnummer 562510
Presseweg 1
38170 Kneitligen
Diplomarbeit
Mobile Business-Intelligence Dashboard (M-BID)
Konzeption und Entwicklung eines webbasierten Business-Intelligence-Systems
zur Analyse und Darstellung betriebswirtschaftlicher Kennzahlen einer
Softwareentwicklung
Diplomarbeit vorgelegt zur Erlangung des Zeugnisses über die Diplomprüfung im
Studiengang Wirtschaftsinformatik an der AKAD-Fachhochschule Pinneberg.
Betreuender Fachhochschullehrer:
Prof. Dr. Roland Schwesig
Kneitlingen (Eilum), den 20.09.2013
II
Inhaltsverzeichnis
Abkürzungsverzeichnis ......................................................................................... IV
Abbildungsverzeichnis .......................................................................................... VI
Verzeichnis sonstiger Elemente .......................................................................... VIII
1 Einleitung .......................................................................................................... 1
1.1 Relevanz ................................................................................................. 1
1.2 Zielsetzung .............................................................................................. 1
1.3 Abgrenzung ............................................................................................. 3
1.4 Vorgehensweise ...................................................................................... 4
2 Grundlagen von BI-Systemen ........................................................................... 6
2.1 Business Intelligence - Einführung .......................................................... 6
2.1.1 Historie, Einordnung und Definition................................................... 6
2.1.2 Einsatz, Probleme, Strategien und Grenzen ..................................... 8
2.1.3 BI-Systemschichten ........................................................................ 15
2.2 Bereitstellung der Daten ........................................................................ 16
2.2.1 Data Warehouse Systemkomponenten .......................................... 16
2.2.2 Transformationsprozess - ETL ........................................................ 20
2.2.3 Modellierung und Speicherung der Daten ....................................... 22
2.3 Analyse und Darstellung der Daten ....................................................... 27
2.3.1 Kategorien von Analysesystemen ................................................... 27
2.3.2 OLAP - Online Analytical Processing .............................................. 28
2.3.3 Reporting, Kennzahlen und Dashboards ........................................ 34
3 IST-Analyse .................................................................................................... 45
3.1 Kriterien für die Untersuchung ............................................................... 45
3.2 Untersuchung der aktuellen Situation .................................................... 47
3.2.1 Betriebsumgebung - Organisatorischer Rahmen ............................ 47
3.2.2 Systemlandschaft - Struktureller Rahmen ....................................... 48
3.2.3 Tätigkeiten - Prozessualer Rahmen ................................................ 50
3.2.4 Kennzahlenbedarf .......................................................................... 51
3.3 Auswertung der Untersuchung .............................................................. 55
III
4 Konzeption des M-BID-Systems ...................................................................... 56
4.1 Konzeptionsziele ................................................................................... 56
4.2 Konzeption und Lösungsansätze ........................................................... 57
4.2.1 Prozesslandkarte ............................................................................ 57
4.2.2 Ablauf der Prozesse ....................................................................... 58
4.2.3 Informationsfluss und Zuständigkeiten ............................................ 60
4.2.4 Anwendungsfälle - Use-Cases ....................................................... 61
4.2.5 Oberflächenskizze - GUI-Mockup ................................................... 63
4.2.6 Systemaufbau und Systemkomponenten........................................ 65
4.2.7 Reporting der Kennzahlen mit Dashboardelementen ...................... 69
4.2.8 Datenmodellierung und OLAP-Cubes ............................................. 73
4.2.9 ETL-Prozesse - Transformationen .................................................. 78
4.2.10 Programmablauf im M-BID-System ................................................ 81
4.2.11 Oberflächenentwurf mit Dashboards .............................................. 83
4.3 Ergebnis der Konzeption ....................................................................... 85
5 Realisierung des M-BID-Systems .................................................................... 86
5.1 Einleitung ............................................................................................... 86
5.2 Technischer Prototyp ............................................................................. 86
5.2.1 Erster Testlauf ................................................................................ 86
5.2.2 Weiteres Vorgehen ......................................................................... 87
5.3 Fachlicher Prototyp ................................................................................ 88
5.3.1 Systemspezifikation mit Hard- und Software ................................... 88
5.3.2 Klassenstruktur im Programmcode ................................................. 88
5.3.3 Prototyp-Version des M-BID ........................................................... 90
6 Zusammenfassung .......................................................................................... 93
6.1 Ergebnisse und Schlussbewertung ........................................................ 93
6.2 Kritische Würdigung............................................................................... 94
6.3 Aussichten ............................................................................................. 95
Literaturverzeichnis ................................................................................................. I
Anhang ................................................................................................................. IV
Anhang 1: Systemzoo und seine Folgen ........................................................ IV
Anhang 2: Notwenige Abgrenzungen für ein BI-System .................................. V
Anhang 3: Datenschema Fact-Constellation und Galaxy ............................... VI
Anhang 4: Balanced Scorecard und Wertetreiber im Unternehmen .............. VII
Anhang 5: Anforderungsliste für das M-BID-System .................................... VIII
Anhang 6: Dimension Produkt für M-BID-Erweiterung ................................... XI
IV
Abkürzungsverzeichnis
ADAPT Application Design for Analytical Processing Technologies AE Auftragseingang
AG Aktiengesellschaft
AG Auftraggeber
API Application Programming Interface
ARIS Architektur integrierter Informationssysteme
ASP Active Server Pages
AutoCAD CAD-System der Firma AutoDesk
BI Business Intelligence
BICC Business Intelligence Competency Centers
BSC Balanced Scorecard
bzw. beziehungsweise
CAD Computer Aided Design
C-DWH Core Data Warehouse
CRM Customer Relationship Management
CSS Cascading Style Sheets
div division, ein HTML-Tag
DM Data Mart
DSS Decision Support System
DV Datenverarbeitung DWH Data Warehouse
EAI Enterprise Applikation Integration E-DWH Enterprise Data Warehouse
EIS Executive Information System
ERM Entity Relation Model
ERP Enterprise Resource Planning
ETL Extraction-Tranformation-Load
FIS Führungsinformationssystem
FK Foreign Key (Fremdschlüssel)
GUI Graphical User Interface
HK Herstellungskosten
H-OLAP Hybrides OLAP
HTML Hypertext Markup Language
i.d.R. in der Regel
IE MS-Internet Explorer
IMS Informationsmanagementsystem
IuK Informations- und Kommunikationssysteme IV Informationsverarbeitung IVV Ingenieurgesellschaft für Verkehrsplanung und Verkehrssicherung GmbH
KPI Key Performance Indicator
LST Leit-und Sicherungstechnik, hier im Bahnbetrieb
M-BID Mobile Business Intelligence Dashboard
MDX Multidimensional Expressions
MIS Management Information System
MIS Management Informationssysteme
M-OLAP Multidimensionales OLAP
MS Microsoft
V
MS IIS Microsoft Internet Information Services
MSS Management Support Systeme o.g. oben genannte
ODS Operational Data Store
OLAP Online Analytical Processing
OLPT Online Transaction Processing
OO object oriented /objektorientiert
PB Parsons Brinckerhoff Comany
PPS Produktionsplanungs- und Steuerungssystem
PRJ Projekt
ProSig Planungssoftware für Bahnanlagen der IVV, ® registrierte Marke
PRS Projekt Ressource System
RAID Redundant Array of Independent Disks
RDBMS Relationales Datenbankmanagementsystemen
R-OLAP Relationales OLAP
SAP Softwarefirma die v.a. ERP-Systmem herstellt
SCM Supply Chain Management
SQL Structured Query Language
SVN Subversion - Filemanagementsystem der Firma Apache, Shareware
SWE Softwareentwicklung
u.a. unter anderem
UM Umsatz
UML Unified Modeling Language
v.a. vor allem
VBM Value Based Management XLS Dateiformat von MS-Excel
z.B. zum Beispiel
z.T. zum Teil
VI
Abbildungsverzeichnis
Abbildung 1: Vorgehensweise in der Bearbeitung der Diplomarbeit .............................. 5
Abbildung 2: Einsatzfeld von BI-Anwendungssystemen ................................................ 9
Abbildung 3: Integrierte Informationssysteme ............................................................. 10
Abbildung 4: Vorgehensmodell für BI-Lösungen ......................................................... 13
Abbildung 5: Closed Loop Quality ............................................................................... 14
Abbildung 6: Schichtenmodell von BI-Systemen ......................................................... 16
Abbildung 7: Systemkomponenten eines DWH-Systems ............................................ 17
Abbildung 8: ELT - Transformationsprozess im BI-System ......................................... 22
Abbildung 9: Star-Schema .......................................................................................... 25
Abbildung 10: Snowflake-Schema .............................................................................. 26
Abbildung 11: Analysesysteme für das Management .................................................. 27
Abbildung 12: Cube mit den Dimensionen Produkt, Zeit und Ort ................................ 30
Abbildung 13: UML-Diagramm der Cube-Komponenten mit Beispielbefüllung ............ 31
Abbildung 14: Funktion Rotate oder Pivot ................................................................... 32
Abbildung 15: Funktion Drill-down und Roll-up ........................................................... 32
Abbildung 16: Funktion Drill-across............................................................................. 33
Abbildung 17: Funktionen Slice und Dice .................................................................... 33
Abbildung 18: Funktion Split ....................................................................................... 34
Abbildung 19: Beispiel-Layout einer Cockpitlösung ..................................................... 37
Abbildung 20: „Wissenschaftstrichter“ vs. „Informationspyramide“ .............................. 37
Abbildung 21: Beispiel für eine Top-Down-Struktur von Botschaft .............................. 38
Abbildung 22: Beispielaufbau für ein BI-Portal ............................................................ 42
Abbildung 23: Unternehmensstruktur IVV ................................................................... 47
Abbildung 24: System und Dokumente im Betrachtungsbereich ................................. 48
Abbildung 25: Quelle SAP - Ausschnitt MS-Excel-Tabelle des SAP-Exports .............. 53
Abbildung 26: Quelle PRS - Ausschnitt MS-Access-Formular für Projektfortschritt ..... 53
Abbildung 27: Ausschnitt aus Prozesslandkarte der SWE-Abteilung........................... 58
Abbildung 28: Legende der Diagramme nach BPMN-Standard .................................. 59
Abbildung 29: Prozessablaufdiagramm „Projektreview“ .............................................. 60
Abbildung 30: Swimlane "Projektsteuerung und Entwicklungscontrolling" ................... 61
Abbildung 31: Use-Cases "M-BID-Portal - Profitcenter" .............................................. 62
Abbildung 32: GUI-Mockup "M-BID-Portal" ................................................................. 64
Abbildung 33: M-BID-System mit Komponenten und Datenströmen ........................... 68
Abbildung 34: Tachometer für Anzeige der Herstellkosten .......................................... 71
Abbildung 35: Tachometer für Anzeige der Projektstunden ........................................ 72
VII
Abbildung 36: ODS-Tabellen für die Quellsysteme PRS und SAP .............................. 73
Abbildung 37: Legende ADAPT-Notation .................................................................... 74
Abbildung 38: Cube Herstellungskosten mit den vier Dimensionen ............................ 75
Abbildung 39: Klassenmodel des Cubes Herstellungskosten ...................................... 76
Abbildung 40: Aggregation über die Dimension Zeit im DWH_CUBE_HK .................. 80
Abbildung 41: Anreicherungen für das HK-Dashboard im DM_DASH_HK .................. 80
Abbildung 42: Sequenz zum Use-Case „ProjektXY anzeigen“ .................................... 82
Abbildung 43: Sequenz zum Use-Case „Dashboard-Botschaft senden“ ..................... 83
Abbildung 44: Oberflächenentwurf M-BID-Portal mit Projekte-Cockpit ........................ 84
Abbildung 45: Versuchsablauf für den technischen Prototyp ...................................... 87
Abbildung 46: Ausgabe des technischen Prototyps .................................................... 87
Abbildung 47: Zusammenhang der Quelldateien im ASP.NET-Kontext ...................... 88
Abbildung 48: Anzeige des ersten Test-Tachometers ................................................. 90
Abbildung 49: HK-Dashboard für eine guten und einen kritischen Projektstand .......... 91
Abbildung 50: Screenshot vom fachlichen Prototyp des M-BID-Portals ...................... 92
Abbildung 51: Fact-Constellation-Schema ................................................................... VI
Abbildung 52: Galaxy-Schema ..................................................................................... VI
Abbildung 53: Balanced Scorecard ............................................................................. VII
Abbildung 54: Wertetreiber im Unternehmen .............................................................. VII
Abbildung 55: Künftige Dimension „Produkt“ ................................................................ XI
VIII
Verzeichnis sonstiger Elemente
Tabelle 1: Erfassung der Kennzahlen mit Eigenschaften ............................................ 54
Tabelle 2: Auszug aus der Anforderungsliste für das M-BID ....................................... 55
Tabelle 3: Zusammenfassende Bewertung der Ergebnisse ........................................ 94
Tabelle 4: Vollständige Anforderungsliste für das M-BID-System ................................. X
Formel 1: Herstellungskosten im IST .......................................................................... 70
Formel 2: Formeln für das Herstellungskosten-Dashboard ........................................ 71
Formel 3: Mapping SAP2ODS .................................................................................... 78
Formel 4: HTML-Seite für das M-BID-Frontend .......................................................... 89
Formel 5: WebForm für das M-BID-Frontend .............................................................. 89
Formel 6: C# Klassen für das M-BID-Frontend ........................................................... 90
1.1 Relevanz
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 1
1 Einleitung
1.1 Relevanz
„Daten müssen immer in Rücksprache mit dem Nutzer zur Verfügung gestellt werden,
da nur er entscheiden kann, welche der vielen verfügbaren Daten für ihn tatsächlich
Informationen darstellen, wie er diese Informationen organisieren muss und was er
aufgrund der Informationen in die Wege leiten muss, damit Resultate folgen.“1
Diese zentrale Erkenntnis von P.J. Reuter (1816-1899), einer der Pioniere der
Informationsdienstleistung, zeigt schon das Wesen von Daten und die Bedeutung von
Informationen für einen potentiellen Nutzer.
Für ein Unternehmen der freien Wirtschaft sind relevante, zuverlässige und
kostengünstige Informationen wichtig, um auf allen Ebenen zu optimalen
Entscheidungen zu kommen und somit seine Existenz dauerhaft zu sichern. Im Zuge
der heutzutage geforderten Mobilität im Kontext E-Business bzw. Mobile-Business
sollen diese Informationen zudem auch universell und jederzeit verfügbar sein.2
Zur Erfüllung dieser komplexen Ansprüche an ein Informationssystem bildet sich seit
Mitte der 1990er Jahre das Konzept „Business Intelligence“ (BI) mit den
entsprechenden Systemen heraus, die es schaffen, die von den Entscheidungsträgern
benötigten Informationen in geeigneter Weise zu ermitteln und darzustellen.3
Wie leisten die BI-Systeme das? Und wie kann ein solches BI-System für eine kleinere
Entwicklungsabteilung einer Spezialsoftware individuell aufgebaut werden, um dessen
Vorteile im alltäglichen Geschäft zu nutzen?
Diese Fragen stellte sich auch der Autor der vorliegenden Arbeit, der als Leiter der
o.g. Entwicklungsabteilung schon länger auf der Suche nach einer geeigneten
Erweiterung des abteilungseigenen Ressourcenplanungssystem „PRS“ war. Er initiierte
ein entsprechendes Vorhaben und wählte als Namen des künftigen Systems „Mobile
Business Intelligence Dashboard“, kurz M-BID. „Mobile“ um die geforderte Mobilität des
Systems auszudrücken, „Business Intelligence“ als Kerntechnologie und „Dashboard“
um den interaktiven Web-Ansatz herauszustellen.
1.2 Zielsetzung
Das Thema “Business Intelligence” (BI) ist schon von vielen Seiten beleuchtet worden
und hat bereits viele funktionsfähige Anwendungssysteme hervorgebracht. Ziel dieser
1 aus [Arnold, 2010 S. 87 f.]
2 vgl. [Klein, 2012 S. 26 f.]
3 vgl. [Kemper, et al., 2010 S. 1 f.]
1.2 Zielsetzung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 2
Arbeit ist es, die grundlegenden Erkenntnisse aus der umfangreichen und komplexen
Literatur zu extrahieren, um sie für ein spezielles Anwendungssystem einzusetzen.
Das Anwendungssystem „M-BID“ soll mithilfe dieser Arbeit nach den neusten
technologischen Maßstäben im Bereich BI konzipiert und schließlich realisiert werden.
Die primären Ziele der vorliegenden Arbeit sind daher mit der Frage verbunden, was
das M-BID leisten soll und was dafür getan werden muss. Während vornehmlich
diesen Zielen nachgegangen wird, „schwingen“ aber auch sekundäre Ziele mit, die
über das System M-BID hinausgehen und die möglichen Synergieeffekte betreffen.
Die primären Ziele in Top-Down-Anordnung sind:
Entwicklung eines lauffähigen M-BID-System als „Kontrollmonitor“ für die
Kennzahlen der Abteilung „Softwareentwicklung“ (SWE) der IVV GmbH.
Das M-BID soll v.a. die erweiterten Anforderungen an das Controlling der SWE
unterstützen, seit die Abteilung ein eigenes Profitcenter geworden ist und die Anzahl
der Mitarbeiter deutlich anstieg.
Der Controlling- und Abstimmungsbedarf in finanzieller und organisatorischer
Hinsicht ist in der SWE-Abteilung sehr hoch, da die IVV eine Spezialsoftware mit
dem Namen ProSig® entwickelt, die als Expertensystem für die Planung von
Bahnanlagen technisch und „menschlich“ hohen Anforderungen genügen muss.
Das M-BID soll dazu beitragen, den finanziellen und organisatorischen Überblick bei
der SWE zu behalten.
Die Entwicklung von ProSig erfordert einen sehr hohen Anteil an „Pionierarbeit“,
weshalb das M-BID strukturierte und unstrukturierte Probleme und Prozesse
erfassen und darstellen muss.
Das gilt insbesondere für neue und z.T. komplexe SWE-Projekte, die finanziell und
organisatorisch nicht aus „dem Ruder“ laufen dürfen. Das M-BID muss hierfür die
notwendigen Kennzahlen liefern, sie geeignet darstellen und aufzeigen, wo es
kritische Abweichungen gibt.
Das M-BID soll bei den monatlichen Projektreviews und den täglichen Team-
Meetings eingesetzt werden und auf die wichtigsten operativen und taktischen
Fragen schnelle und zuverlässige Antworten bereithalten.
Ferner soll das M-BID für die Quartalsreviews mit der Geschäftsführung die
notwendigen verdichteten Kennzahlen liefern, die auch bei der Abschätzung bzw.
Prognose für das laufende Jahr (Forecast) und das kommende Jahr (Budget)
betrachtet werden. M-BID soll somit auch bei strategischen Entscheidungen
mithelfen, da es künftige Trends erkennen lässt, aus denen sich Chancen und
Risiken ergeben könnten.
1.3 Abgrenzung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 3
Die dazu notwendigen Daten sind derzeit in mehreren Anwendungen verteilt, die
manuell zusammengeführt werden müssen. Hier soll das M-BID im Sinne eines BI-
Systems alle zur Auswertung benötigten Daten aus diesen operativen Systemen
sammeln und zusammenführen.
Das M-BID soll im Rahmen dieser Arbeit (und auch künftig) nicht als „fix-und-
fertiges“ System umgesetzt werden, sondern als Arbeitsrahmen (Framework), der
die Voraussetzung schafft, die relevanten Anforderungen schrittweise und flexibel
(agil) umzusetzen.
Dazu werden im M-BID-Framework die notwendigen technologischen Grundlagen
gelegt und anhand von ersten Anwendungsbeispielen „ausprobiert“.
Diese Anwendungsbeispiele, wie eine Tachometeranzeige für die Darstellung der
Herstellungskosten, sollen die Hauptprinzipien eines BI-Systems nutzen und deren
Umsetzung im M-BID validieren und dokumentieren.
Dazu wird das Thema BI genau beleuchtet und Beiträge aus der Wissenschaft und
der Praxis ausgewertet. Mit der Gegenüberstellung von IST und SOLL wird dann ein
Konzept für die Umsetzung gefunden (siehe Vorgehensweise, Kapitel 1.4).
Die sekundären Ziele sind:
Das erworbene Wissen und der technologische Rahmen ist auch für die ProSig-
Entwicklung von Bedeutung. ProSig ist ein datenintensives Expertensystemen mit
einer zentralen Datenbank, die mit den neusten Entwicklungen bald „aus allen
Nähten platzt“. Hier soll der Blick auf die Prinzipien und Techniken einer verwandten
Systemklasse zu anwendbarem Wissen für die anstehende Umstellung des ProSig-
Datenbanksystems führen. Insbesondere die Methoden beim Realisieren eines
Data-Warehouse (DWH) scheinen hierfür geeignet zu sein.
Für die Umsetzung des M-BID werden eine IST-Analyse und eine SOLL-Konzeption
benötigt, die auch zur Optimierung der Strukturen und Prozesse in der SWE führen
können.
Schließlich kann man sich das M-BID auch als BI-System der IVV vorstellen, was
aber im Rahmen dieser Arbeit nur als Ausblick formuliert werden kann.
1.3 Abgrenzung
Wie schon bei den Zielen erwähnt, ist das Thema BI sehr komplex und umfangreich.
Allein Google liefert zum Stichwort „Business Intelligence“ 380.000.0004
Suchergebnisse. Das ist zwar noch kein Beweis für anspruchsvolle Komplexität,
veranschaulicht aber, dass BI ein durchaus aktives Thema ist.
4 www.google.de - Suchergebnis zu „Business Intelligence“ am 26.07.2013, 16.20 Uhr.
1.4 Vorgehensweise
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 4
Für das M-BID bedarf es aber nicht nur einer oberflächlichen Betrachtung des Themas,
sondern einer detaillierten Untersuchung bis zu dem Grad, der die Konzeption und die
erste Umsetzungsstufe ermöglicht. Das heißt im Umkehrschluss, dass viele Details
nicht betrachtet werden, die zwar BI-relevant sind, aber nicht (oder noch nicht) im
Fokus von M-BID stehen. Das ist insbesondere Folgendes:
BI-Systeme sind letztlich dazu geeignet ein ganzes Unternehmen oder gar einen
großen Konzern mit Kennzahlen zu allen unternehmerischen Bereichen und allen
betrieblichen Fragestellungen zu versorgen. In der hier vorliegenden Arbeit ist der
Blick auf eine Unternehmensabteilung, der Softwareentwicklung, gerichtet und bleibt
auch im Kern bei deren Sachverhalten und Fragestellungen. Die Fokussierung hilft
die Komplexität der Aufgabe im Griff zu behalten und somit nicht in die
„Komplexitätsfalle“ zu geraten. Die gefundenen Prinzipien lassen sich dann auch auf
größere „Umlaufbahnen“ anwenden.
Im vorgenannten Sinne wird beim M-BID zunächst auf ein Framework mit einigen
ausgewählten Anwendungsbeispielen (siehe Kapitel 1.2) fokussiert. Was im
Rahmen dieser Arbeit eine Einschränkung darstellt, soll im praktischen Einsatz
einen Vorteil erzeugen. Die Entwicklungskapazitäten der IVV in der SWE-Abteilung
sind nicht dafür ausgelegt „noch nebenbei“ ein komplettes BI-System zeitnah
umzusetzen. Der Ansatz als Framework soll hier eine schrittweise Realisierung über
die nächsten Jahre und je nach Notwendigkeit erlauben.
Es gibt eine Reihe von Aspekten, die die Mächtigkeit von BI-Systemen unterstreicht.
Das sind v.a. die Themen „Data-Mining“ und „Realtime-Analyse“, die in dieser Arbeit
jedoch nicht betrachtet werden.
Auch der mit BI oft verbundene Begriff „Enterprise Applikation Integration“ (EAI) wird
erwähnt aber nicht weiter ausgeführt.
Ferner wird der zentrale Aspekt „Online Analytical Processing“ (OLAP) zwar
ausführlich dargestellt, aber bei der Umsetzung zunächst nicht vollständig
„ausgereizt“.
Natürlich gibt es für jeden in dieser Arbeit erwähnten Aspekt eine Vielzahl von
kommerziellen Produkten und Open-Source-Produkten, die spezielle oder
allgemeine Lösungen anbieten. Da es aber in dieser Arbeit nicht darum geht ein
fertiges BI-System auszuwählen oder zu modifizieren, werden sie nicht explizit
betrachtet.
1.4 Vorgehensweise
Die vorliegende Arbeit gliedert sich in sechs Hauptkapitel, die auch der üblichen
Abfolge entsprechen, wenn etwas im Sinne eines Projektes bzw. Softwareprojektes
erarbeitet und entwickelt werden soll. Die Abbildung 1 zeigt die gesamte
Vorgehensweise in dieser Arbeit, die insbesondere an den entscheidenden Stellen
1.4 Vorgehensweise
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 5
einen Abgleich von formulierten Absichten und tatsächlichen Umsetzungen vorsieht,
auch um die o.g. Komplexitätsfalle zu umgehen.
2. Grundlagen BI 3. IST-Analyse 4. Konzeption 5. Realsierung 6. Zusammenfassung
2.1 Einführung
2.2 Daten-
bereitstellung
2.3 Analyse
und
Darstellung
der Daten
4.1
Konzeptions-
ziele
1. Einleitung
6.1
Ergebnisse
und Schluss-
bewertung
6.2 Kritische
Würdigung
6.3 Aussicht
4.2 Konzeption
und Lösungs-
ansätze
5.2
Technischer
Prototyp
5.2 Fachlicher
Prototyp
1.1 Relevanz
1.2
Zielsetzung
1.3
Abgrenzung
1.4
Vorgehens-
weise
3.3
Auswertung
3.2
Untersuchung
der Situation
3.1 Kriterien
für die
Untersuchung
5.1 Einleitung
4.3 Ergebnis
Abbildung 1: Vorgehensweise in der Bearbeitung der Diplomarbeit5
Im Einzelnen werden gemäß Abbildung 1 folgende Schritte durchgeführt:
In Kapitel 1 wurden die Ziele der Arbeit formuliert. Sie wurden zudem gegen
Aspekte abgegrenzt, die nicht oder nur teilweise in die Betrachtung kommen.
Kapitel 2 beschreibt die theoretischen und pragmatischen Grundlagen aus den
Literaturquellen. Dabei hat der Autor stets eine Auswahl relevanter Quellen
miteinander verglichen, Bezüge hergestellt und in eigenen Worten wiedergegeben.
Beispiele und praktische Erläuterungen, die oft mit „z.B.“ eingeleitet werden, sind
zumeist Eigenentwürfe, die aus der praktischen Erfahrung des Autors in seiner
Tätigkeit als Softwareentwicklungsleiter stammen. Dabei wird beachtet, dass der
inhaltliche Rahmen der Literaturvorlagen nicht überstiegen wird.
Um die Relevanz der Grundlagen für die IST-Analyse und die SOLL-Konzeption
aufzuzeigen, werden sie am Ende eines jeden Unterabschnittes nochmals in
separaten Textbereichen „M-BID-Relevanz“ zusammengefasst.
Mit dem Kapitel 3 beginnt der fachlich-konzeptuelle Teil der Arbeit. Zunächst werden
aus den Zielen und den Grundlagen die Kriterien für die IST-Analyse definiert. Sie
dienen als Richtschnur und Maßband für die Untersuchung der tatsächlichen
Situation in der SWE-Abteilung und ihrem spezifischen Umfeld.
Kapitel 4 umfasst die Erstellung des Umsetzungskonzeptes und beginnt mit der
Formulierung der Konzeptionsziele aus den Ergebnissen der IST-Analyse. Die
Konzeptionsziele dienen wiederum der Konzepterstellung als Leitfaden, sodass
relevante bzw. passende Lösungsansätze formuliert werden können.
Kapitel 5 beschreibt die Realisierung des Konzeptes zunächst anhand eines
„technischen Prototyps“, der die grundsätzliche Machbarkeit nachweisen soll.
5 eigener Entwurf
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 6
Danach wird anhand eines „fachlichen Prototyps“ gezeigt, welche Ergebnisse die
umgesetzten Anwendungsfälle tatsächlich erzeugen.
Schließlich werden in Kapitel 6 die Ergebnisse der Umsetzung gegen die
Konzeptionsziele bewertet. Die Bewertung führt zu einer kritischen Betrachtung der
Arbeit und zu den Aussichten auf künftige Aktivitäten.
2 Grundlagen von BI-Systemen
2.1 Business Intelligence - Einführung
2.1.1 Historie, Einordnung und Definition
Historie
Seit die elektronische Datenverarbeitung in den 1960er Jahren auch für kommerzielle
Zwecke genutzt wurde, begann auch die Suche nach möglichen Unterstützungen der
betrieblichen Prozesse und der damit verbundenen Managementaufgaben6. Zunächst
war dieses Vorhaben schwierig und noch wenig erfolgreich. Zum einen waren die
technischen Komponenten (Hardware) noch nicht ausgereift genug, zum andern
wurden „ […] die Schwierigkeiten der Entwicklung expertenähnlicher Systeme grob
unterschätzt […]“7.
Erst in den 1980er Jahren entwickelten sich die „Management Support Systeme“
(MSS) die v.a. einen wissensbasierten und damit datenintensiven Ansatz verfolgten,
der sich im Laufe der 1970er Jahre (als damals noch propagierte „Künstlichen
Intelligenz“) durchgesetzt hatte. Dieser Ansatz mündete in einem Paradigmenwechsel
und wurde 1983 so beschrieben: „Das fundamentale Problem zum Verständnis von
[künstlicher] Intelligenz ist nicht die Identifikation von wenigen mächtigen Techniken,
sondern eher die Frage, wie sehr viel Wissen repräsentiert werden muß, um seinen
effektiven Gebrauch und Interaktionen zu ermöglichen.“8
Damit war bereits das Grundverständnis für die MSS, wie sie heute realisiert und
benutzt werden, formuliert. Dieses Grundverständnis wurde im Laufe der Zeit noch
durch ein weiteres wichtiges Paradigma der „horizontalen und vertikalen
Systemintegration“ erweitert, um sicherzustellen, dass einmal gewonnene
Informationen nicht auf einer „Dateninsel“ verbleiben, sondern nutzbringend ihren Weg
durch das ganze Unternehmen finden. Das führte in der Folge zu einem Integrations-
ansatz entlang der gelebten oder gewünschten Geschäftsprozesse.9
6 vgl. [Kemper, et al., 2010 S. 1]
7 aus [Puppe, 1988 S. 5], vgl. auch [Kemper, et al., 2010 S. 113]
8 aus [Duda, et al., 1983 S. 220]
9 vgl. [Gluchowski, et al., 2008 S. 7]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 7
Für die nunmehr komplexe und anspruchsvolle Betrachtungsweise hat sich 1996 der
Begriff „Business Intelligence “ von der Gartner Group durchgesetzt10. Es erscheint
passend, dass sich dieser Begriff etabliert hat, da Anspruch und Komplexität schon
dadurch erkennbar werden, dass er sich nur mit einiger Mühe definieren und
abgrenzen lässt.
Einordnung
„Dennoch kann eine erste Annäherung an das Begriffsgebilde erfolgen, indem
Konzepte und Technologien aufgezeigt werden, die sich dem BI […] zuordnen
lassen“11.
Im Folgenden stehen die Bedeutungscluster, wie sie bereits 2002 von P. Mertens
identifiziert wurden12:
Business Intelligence (BI) als Synonym/Label für
Datenverarbeitung (DV) und Informationsverarbeitung (IV) für das Management
eines Unternehmens.
Filter gegen die Informationsflut im Kontext des Informationsmanagements.
Klasse der „Management Informationssysteme“ (MIS) mit besonders schnellen
und/oder flexiblen Auswertungen (OLAP) und den entsprechenden Darstellungen
(Reporting), siehe Kapitel 2.3.2 und 2.3.3.
Frühwarnsysteme mit automatischem Report bei Grenzwertüberschreitungen.
Kerntechnologie bzw. Kernkonzept der BI-Systeme, dem „Data Warehouse“ (DWH),
siehe Kapitel 2.2.1.
Informations- und Wissensspeicher durch Non-Volatilität und Persistenz in den
Datenbanken / DWH, sowie die objektorientierte und regelbasierte Wissens-
repräsentation als Kernmethode innerhalb von Expertensystemen.13
Prozess von „Symptomerhebung, Diagnose, Therapie, Prognose, Therapie-
kontrolle“, wie er schon im Zuge der Definition von Expertensystemen in den 1980er
Jahren formuliert wurde.14
Das oben erwähnte Grundverständnis für die MSS und allgemein für Informations- und
Kommunikationssysteme (IuK-Systeme) wurden in den letzten Jahren um ein weiteres
Paradigma ergänzt, der mittlerweile fast trivial anmutenden Forderung, dass nicht die
DV-Systeme allein für die Optimierungen in einem Unternehmen zu betrachten sind,
10 vgl. [Kemper, et al., 2010 S. 2]
11 aus [Gluchowski, et al., 2008 S. 90]
12 Auflistung in enger Anlehnung an [Mertens, 2002 S. 4], inhaltlich ergänzt.
13 beschrieben in [Mandorf, 2008 S. 11-16]
14 siehe [Puppe, 1988 S. 121 f.]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 8
sondern die Anwender und ihre Bedürfnisse im Zentrum der Betrachtung stehen
müssen.
Der Erfolg insbesondere eines MSS ist also verbunden mit einem ganzheitlichen
Verständnis für die
Aufgaben, die
Menschen mit
Informationen und
Werkzeugen der Informationstechnologie (IT)
zu lösen oder zu erfüllen haben.15
Definition
Zu dem vorgenannten Aspekt von BI-Systemen werden v.a. aus der Praxis (Best
Practice) Hinweise und Verfahren formuliert, die zusammengefasst bedeuten:
„Business Intelligence ist ein Unternehmensprozess!“16 und kein (ausschließlicher) IT-
Prozess.
Insgesamt lässt sich BI schließlich definieren als:
„Business Intelligence (BI) bezeichnet einen integrierten, unternehmensspezifischen,
IT-basierten Gesamtansatz zur betrieblichen Entscheidungsunterstützung.“17.
M-BID Relevanz R1:
Datenintensives Expertensystem In Konzept und Umsetzung vorzusehen: Viel
Speicherplatz, komplexe Datenstruktur und hoher Anspruch an die Funktionalitäten.
Horizontale und vertikale Systemintegration Komplexe Systemstruktur mit geeigneten
Schnittstellen zu vorhandenen Systemen im Unternehmen
Ganzheitliches BI-Verständnis Ist Leitgedanke bei der Konzeption: Die Nutzer müssen
im Mittelpunkt stehen.
2.1.2 Einsatz, Probleme, Strategien und Grenzen
Einsatz
Wie aus Kapitel 2.1.1 ersichtlich, wurde in den vergangenen Jahrzehnten viel Aufwand
betrieben, um Unternehmen möglichst weitreichend informationstechnisch zu
unterstützen. Dies ist nur möglich, wenn sich der damit verbundene Aufwand auch
betriebswirtschaftlich „rechnet“, oder zumindest eine lohnende Investition vermutet
wird. Was sind also die Gründe und Einsatzfelder von BI-Systemen, welche Strategien
werden verfolgt und wodurch wird ihr Einsatz begrenzt?
15 vgl. [Gluchowski, et al., 2008 S. 2 f.]
16 aus [Bachmann, et al., 2011 S. 23]
17 aus [Kemper, et al., 2010 S. 9]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 9
Der Hauptgrund, dass MSS bzw. BI-Systeme zum Einsatz kommen, liegt am hohen
Wert des Produktionsfaktors „Information“ selbst, der als „[…] existenzieller Rohstoff
der Wissensbildung gesehen [wird]“18. Es geht im Kern um den Aufbau von Wissen,
das für die unternehmerischen Entscheidungen notwendig ist und damit letztlich das
Überleben des Unternehmens sichert.
Hierzu müssen Informationen, wie alle anderen Produktionsfaktoren auch,
zur richtigen Zeit
am richtigen Ort
in der erforderlichen Art, Qualität und Menge und
zu möglichst geringen Kosten
bereitgestellt werden19.
Werden die Anforderungen erfüllt, spricht man auch von einer Informationskongruenz.
Üblicherweise kann ein Unternehmen auf viele Informationen zurückgreifen, die im
Unternehmen selbst „produziert“ werden. Diese internen Informationen stammen aus
den operativen IuK-Systemen, den „Ausführungssystemen“, die die betrieblichen
Leistungsprozesse u.a. in den Funktionenbereichen Einkauf, Produktion, Vertrieb,
Kundenpflege und Berichtswesen unterstützen.
Zusammen mit den externen Informationsquellen aus der Umwelt des Unternehmens,
wie Wettbewerberdaten, statistische Erhebungen und Benchmarking, bilden sie die
Informationsbasis, auf die weitergehende Systeme aufbauen, siehe Abbildung 2.
BI
Business
Intelligence
lower
middle
top
Management
Führungssysteme
Ausführungssysteme im Leistungsprozess
Externe Daten
Pla
ne
n u
nd
Ste
ue
rn
Inte
rne
Da
ten
Abbildung 2: Einsatzfeld von BI-Anwendungssystemen20
18 aus [Gluchowski, et al., 2008 S. 27]
19 vgl. [Totok, 2000 S. 25] und [Gluchowski, et al., 2008 S. S. 28 ff.]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 10
Die „Führungssysteme“ unterstützten dann alle Bereiche des Managements, wobei
sich die Aufgaben und Problemstellungen in Richtung Top-Management verändern und
damit auch der Charakter der benötigten Daten und Informationen.
In der Abbildung 3 werden diesbezüglich die wichtigsten Aspekte dargestellt:
Die Problemstellungen werden zunehmend unstrukturierter, also weg von
strukturierten Routinetätigkeiten wie etwa ein Bestell- oder Buchungsvorgang hin zu
Entscheidungen in komplexen Kontexten wie z.B. künftige Markstrategien mit neuen
Produkten auf neuen Märkten.21
Damit verbunden sind die Anwendungssysteme, die von standardisierten
Werkzeugen der IuK-Technik (wie Emailprogramme, Kassen- und
Buchungssysteme) über Reportingsysteme für Berichte und Abfragen bis zu
„maßgeschneiderten“ Systemen für die Geschäftsführung reichen.22 In der Folge hat
das Auswirkung auf die Qualität der Informationen, die von „transaktionstauglich“ bis
„analysetauglich“ reicht, siehe Kapitel 2.3.
Entsprechend ist die Art und Struktur der Daten, die zwischen operativ/unverdichtet
und aggregiert/verdichtet liegt, siehe Kapitel 2.2.
Problem
Daten Lösung
Qualität
verdichtet
unstrukturiert
spezialisiert
analysetauglich
operativ
strukturiert
standardisiert
transaktionstauglich
mengenorientiert
wertorientiert
Reporting
DSS
EIS
Systemschwerpunkt Anwendungssystem
EIS = Executive Information System
DSS = Decision Support System
Management-
Informations-
systeme
Controlling-
Informations-
systeme
Administrations- und
Dispositionssysteme
Abbildung 3: Integrierte Informationssysteme23
Es wird, wie in Abbildung 3 zu erkennen, bei den betrieblichen Anwendungssytemen
unterschieden zwischen
den Administrations- und Dispositionssystemen und
den Management-Informationssystemen (MIS), wie DSS und EIS/FIS.
20 vgl. [Kemper, et al., 2010 S. 9]
21 vgl. [Gluchowski, et al., 2008 S. 25 f.]
22 vgl. [Totok, 2000 S. 37. ff.]
23 eigener Entwurf in Anlehnung an [Totok, 2000 S. 38] und [Gluchowski, et al., 2008 S. 5]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 11
Insbesondere im Bereich der MIS finden die BI-Systeme ihre Anwendung, wobei ihr
strategisch-systematischer Ansatz schon in den Administrations- und Dispositions-
systemen beginnt.
Zusammen mit der Sicht auf die notwendigen Unternehmensressourcen und -prozesse
aus Kapitel 2.1.1 ergibt sich die aktuelle Vorstellung von BI wie folgt:
„Grundsätzlich wird Business Intelligence […] als analytischer Prozess verstanden, der
Unternehmens- und Wettbewerbsdaten in handlungsgerechtes Wissen für die
Entscheidungsfindung überführt“.24
M-BID Relevanz R2:
Wichtiger Produktionsfaktor „Information“ Verlässliches, nachvollziehbares System
Betriebswirtschaftlich lohnend Kosten-Nutzen-Verhältnis ist zu beachten
Selbstproduzierte Daten als Grundlage Daten aus vorhandenen IT-Systemen nutzen
Das Wesen der Daten ändert sich in Richtung BI-System Entsprechende Funktionen zur
Transformation und Anreicherung der Daten konzipieren und umsetzen
Probleme und Strategien
Die Unternehmen sehen sich zunehmend größeren und komplexeren Problemen
gegenübergestellt25:
Steigender Konkurrenzdruck durch zunehmende Globalisierung der Märkte.
Orientierung der Produktion oder Serviceleistung an den Kundenansprüchen
(Abnehmermärkte).
Dadurch wird eine flexiblere und schnellere Reaktion auf Marktveränderungen nötig,
die immer kürzere Lebenszyklen von Produkten nach sich ziehen.
Die zunehmende Konkurrenz führt zu Preiskämpfen und zu notwendigen Rationali-
sierungsmaßnahmen wie z.B. Produktionsoptimierungen durch IT- und Maschinen-
einsatz oder zur Vergrößerung der Unternehmen durch Zusammenschlüsse.
Daraus resultiert eine steigende organisatorische Komplexität innerhalb der
Unternehmen (Aufbau- und Ablauforganisation), sowie in ihrem Umfeld. Das trifft
insbesondere für international tätige Unternehmen zu.
Die notwendige und umfangreiche Informationsversorgung aller Anspruchsgruppen
eines Unternehmens von den Angestellten über die Finanz- und Steuerbehörden bis
zu den Investoren (z.B. den Aktionären).
Die international oft unterschiedliche Rechts- und Richtlinienlage führt zu weiteren
„Reporting-Anforderungen“ z.B. durch Aufsichtsbehörden und Versicherungen.
24 aus [Gansor, et al., 2010 S. 29]
25 vgl. [Kemper, et al., 2010 S. 5 ff.] und [Gluchowski, et al., 2008 S. S.1 ff.]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 12
Der Grad der „Digitalisierung“ ist durch das E-Business (z.B. Online-Handel)
innerhalb der Internettechnologien stark gestiegen. Entscheidende unternehmens-
übergreifende Geschäftsprozesse sind teilweise oder vollständig digitalisiert z.B. bei
SCM und CRM. Aber auch die Informationskanäle zu den Behörden werden (z.B.
durch elektronische Steuerformulare) zunehmend digitalisiert, sodass auch kleine
Unternehmen nicht mehr auf IT- bzw. Anwendungssysteme verzichten können.
Die genannten Anforderungen machen IuK-Systeme in der betrieblichen Praxis nahezu
unverzichtbar. Somit gab es für die Unternehmen letztlich nur die Möglichkeit, nach
den technisch und methodisch geeignetsten Systemen ihrer Zeit Ausschau zu halten.
Auf diese Weise sind viele unterschiedliche Anwendungssysteme im operativen und
administrativen Bereich, aber auch zur Unterstützung des Managements, entwickelt
und eingesetzt worden.
Mittlerweile sehen sich die Unternehmen einem weiteren, daraus resultierenden
Problem gegenüber, nämlich der Entstehung eines „Systemzoos“26. Die Symptome
und Folgen hierzu sind in Anhang 1 zusammengestellt.
Die Praxis hält diesbezüglich einschlägige Beispiele bereit, wie das folgende Zitat vom
Leiter Sales eines mittelständigen Unternehmens:
„>> In den meisten Meetings verbringen wir die Hälfte der Zeit mit der Diskussion,
welche Zahlen die richtigen sind, weil jeder sein eigenes Reporting mitbringt. Ich habe
den Eindruck, aus den Rohdaten lässt sich für jede Kennzahl jeder beliebige Wert
erzeugen.<<“27
Damit wächst die Motivation für die Unternehmen, künftig einer mehr voraus-
schauenden und ganzheitlichen Strategie zu folgen; eher nach dem Motto „agieren
statt reagieren“.
Das führt zur Notwendigkeit einer übergeordneten „BI-Strategie“ als „[…]
zukunftsorientierte Gesamtplanung der BI-Initiativen und -Projekte, abgeleitet aus der
Geschäftsstrategie des Unternehmens.“28
Der Prozess zur Entwicklung der BI-Strategie verläuft wie bei anderen Unternehmens-
strategien in den Phasen: Analyse, Bewertung, Konzeption, Implementierung und
Umsetzungskontrolle.29
Entscheidend ist hierbei die Verschmelzung von den strategischen Unternehmens-
zielen mit den Zielen der BI-Strategie, was zwar leicht gesagt ist, aber meist nur
schwer erreicht wird.
26 vgl. [Gansor, et al., 2010 S. S. 18]
27 aus [Bachmann, et al., 2011 S. 29]
28 aus [Gansor, et al., 2010 S. 33]
29 vgl. [Gansor, et al., 2010 S. 33]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 13
Zur Durchführung und Kontrolle der Prozesse in Richtung BI-Strategie wird deshalb
das Einrichten eines „Business Intelligence Competency Centers“ (BICC)
vorgeschlagen, das aus Mitgliedern der Fach- und Funktionsbereiche sowie Vertretern
aller Managementebenen besteht.30
Aus der BI-Strategie lassen sich dann die notwendigen Maßnahmen zur Gestaltung
und zum Aufbau eines BI-Systems konsequent ableiten.
Abbildung 4 zeigt ein entsprechendes Vorgehensmodel (Wasserfallmodell mit
Feedbackmöglichkeiten), wie aus der BI-Strategie ein „laufendes“ BI-System wird. Die
BI-Strategie wird immer weiter operationalisiert und die Maßnahmen jeder Ebene
werden stets vonseiten der BI-Qualitätssicherung und dem organisatorischen BI-
Projektmanagement flankiert.
Unternehmensstrategie
BI- Analyse
BI- Implementierung
BI- Produktivsetzung
BI- Betrieb und -Wartung
BI-
Qu
alit
äts
ma
na
ge
me
nt B
I- Pro
jektm
an
ag
em
en
t
BI- Design
BI- Strategie
BI- Projektdefinition
Abbildung 4: Vorgehensmodell für BI-Lösungen31
M-BID Relevanz R3:
Komplexere Probleme sind zu lösen System muss die kurzfristige und mittelfristige
Komplexität abbilden können. Anpassung an neue Anforderungen muss möglich sein.
Systemzoo Aktuelle Situation diesbezüglich untersuchen und mögliche Probleme
hieraus identifizieren und berücksichtigen.
BI-Strategie Aus der IST-Analyse heraus ist eine M-BID-Strategie als oberstes
Konzeptionsziel zu formulieren. BICC nicht explizit, Ansätze implizit berücksichtigen.
Grenzen und Chancen
30 vgl. [Gansor, et al., 2010 S. 8]
31 vgl. [Gluchowski, et al., 2008 S. 259]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 14
Obschon „Business Intelligence“ als Begriff und Konzept einige Jahre existiert und
bereits umfänglich in die betriebliche Praxis eingegangen ist32, verführt diese
„wohlklingende“ Bezeichnung oft zur Annahme, es handele sich um ein „Allheilmittel“,
das jedes unternehmensinterne Problem zu lösen vermag.
Damit eine BI-Strategie im Sinne des vorherigen Abschnittes wohl definiert und dann in
Form eines BI-Systems durchgesetzt werden kann, sind entsprechende Abgrenzungen
sehr wichtig; siehe Anhang 2. Das BI-System sollte nicht „Generalverantwortlicher“ für
unternehmerische oder strukturelle Defizite sein. Diese Defizite müssen separat
identifiziert und behoben werden.
Es kann aber durchaus ein „Verbesserungsmotor“ für eine nicht-optimale Situation
sein, da sich in einem BI-System die erwähnten Defizite wie in einem Brennglas
fokussieren. Ein neueres Schlagworte hierfür ist „Closed Loop Quality“, und zeigt auf,
wie die Qualität von unternehmensinternen Prozessen, Strukturen und Daten
hinsichtlich BI kontinuierlich verbessert werden kann, siehe Abbildung 5. Dabei stehen
den Unternehmenszielen und den fachlichen bzw. prozessualen Notwendigkeiten
(Business Needs) entsprechende operationalisierte Kennzahlen (KPI‘s = Key
Performance Indicators) gegenüber, die den Erfolg der Umsetzung durch Überwachen
(Monitoring) aufzeigen.33
Unternehmensstrategie BI- Strategie
Ziele + Business Needs KPI’s formulieren
Operative
Systeme
Monitoring
KPI’s
überwachen
Analyse-
daten
Operative
Prozesse
Extraktions-
prozesse
Operative
Daten
Data
Warehousing
Analyse-
prozesse
Abbildung 5: Closed Loop Quality34
32 vgl. [Gansor, et al., 2010 S. 9]
33 vgl. [Bachmann, et al., 2011 S. 144 f.]
34 eigener Entwurf in Anlehnung an [Bachmann, et al., 2011 S. 145]
2.1 Business Intelligence - Einführung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 15
M-BID Relevanz R4:
BI ist kein Allheilmittel Untersuchen welche vorgelagerten Probleme existieren und diese
dann gegen das M-BID abgrenzen.
BI als Verbesserungsmotor Aspekte des „Closed Loop Quality“ bei Konzeption
berücksichtigen. Kontinuierlichen Verbesserungsprozess als Prinzip ins M-BID einbauen.
2.1.3 BI-Systemschichten
Aus den Abbildungen im Kapitel 2.1.1 lässt sich erkennten, wo die BI-Systeme zum
Einsatz kommen (Abbildung 2) und wie sie die operativen Daten der Transaktions-
systeme nutzen, um sie für analytische Zwecke und Managementunterstützung immer
mehr zu verdichten und zu veredeln (Abbildung 3).
Es stellt sich nun die Frage, welche Systemkomponenten in welcher Struktur in einem
BI-System typischerweise vorhanden sind und wie sie funktionieren, um die
gewünschten Mehrwerte zu erzeugen.
Einen Überblick über die Grundarchitektur von BI-Systemen zeigt die Abbildung 6.
Grundsätzlich ist das Architekturmodell von BI-Systemen in Schichten (Layer)
aufgebaut, die mehr oder weniger scharf voneinander abgegrenzt werden können35:
Datenbereitstellung ist die unterste Schicht im Modell und bildet den Übergang von
den internen operativen Vorsystemen sowie den externen Datenquellen zu der
Datenbasis des BI-Systems. Ein wichtiges Paradigma der BI-Systeme ist hierbei die
Unterscheidung und Trennung der Transaktionsdaten in den operativen
Vorsystemen von den Analysedaten (Dispositionsdaten) im BI-System, siehe Kapitel
2.2.2. Ferner ist die Richtung der Datenströme stets von den Vorsystemen in das
BI-System hinein. Ein Rückweg ist explizit nicht vorgesehen.
In neueren Systemansätzen wird die oft große Menge an unstrukturierten Daten
(also Daten in schlecht-kodifizierbarer Form, wie Bilder, Scans, PDFs, Ton- und
Filmdateien) mit in die Gesamtbetrachtung eingebunden. Sie können zwar nicht
(oder nur z.T.) automatisch ausgewertet werden, können aber mit in die Darstellung
von Analysen einbezogen werden und helfen so bei der Entscheidungsfindung der
Anwender.
Datenanalyse bzw. Informationsgenerierung ist die mittlere Schicht und stellt
Analysefunktionen insbesondere im Kontext OLAP zur Verfügung, die entweder
separat (v.a. in Form von flexiblen Ad-Hoc-Abfragen) zur Anwendung kommen oder
als funktionale Grundlage für die Präsentationsschicht dienen.
35 vgl. [Gluchowski, et al., 2008 S. 108 -116] und [Kemper, et al., 2010 S. 10-13]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 16
Informationspräsentation und -distribution bildet die oberste Schicht eines BI-
Systems und stellt spezielle Oberflächen wie Formulare, interaktive Dialoge,
Berichte und grafische Auswertungen auf einer definierten Plattform bereit.
Hier spielt zudem der Aspekt der Informationsverteilung (Informationsdistribution)
eine wichtige Rolle, der die Verbindung zwischen dem BI-System und dem
betrieblichen Wissensmanagement realisiert.
Durch ein Rechtemanagement wird der Zugriff auf Daten, Informationen und
Funktionen gesteuert.
Operative Systeme
Datenbereitstellung
Datenanalyse
bzw. Informationsgenerierung
Informationspräsentation
und -distribution
BI
ERP SCM CRM PPS
Abbildung 6: Schichtenmodell von BI-Systemen36
M-BID Relevanz R5:
BI-Schichtenmodell Eine entsprechende Systemstruktur ist für das M-BID zu entwickeln.
2.2 Bereitstellung der Daten
2.2.1 Data Warehouse Systemkomponenten
Die BI-Systemschicht der Datenbereitstellung ist derzeit wesentlich vom Konzept des
Data Warehouse (DWH) geprägt.
Im Zentrum des DWH-Konzeptes steht die Erstellung einer zentralen und konsistenten
Datenbasis mit allen entscheidungsrelevanten und nachgefragten Informationen37.
Das Konzept hat sich u.a. aus den Problemen mit heterogenen Systemlandschaften
und proprietären Datenspeichern entwickelt und ist insbesondere von W. Inmon
36 eigener Entwurf in Anlehnung an [Gluchowski, et al., 2008 S. 109] und [Kemper, et al., 2010 S. 11]
37 vgl. [Gluchowski, et al., 2008 S. 118 f.] und [Kemper, et al., 2010 S. 19]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 17
geprägt worden. Ein DWH-System sieht demnach eine zentrale Datenspeicherung
nach folgenden Merkmalen vor:38
Themenorientierung: Die Entitäten (Informationseinheiten) im DWH sind auf die
Geschäftsobjekte z.B. Produkte, Kunden, Regionen, Aufträge ausgerichtet und nicht
auf die Transaktionen, wie in den Datenbanken der operativen Vorsysteme.
Integration bzw. Vereinheitlichung: Die Daten aus allen operativen Vorsystemen
werden zu einer konsistenten, redundanzfreien und inhaltlich widerspruchsfreien
Datenbasis zusammengeführt.
Zeitraumbezug: Die Transaktionsdaten der operativen Vorsysteme werden meist
nur im aktuellen Stand abgespeichert und sind somit zeitpunktbezogen. Für die
Übernahme ins DWH werden sie durch einen Zeitstempel in eine zeitliche
Reihenfolge (Historie) gebracht. Das ermöglicht z.B. das Darstellen von
Entwicklungen bestimmter Kennzahlen in Form von Zeitreihen.
Nicht-Volatilität bzw. Beständigkeit: Während die Daten der operativen Vorsysteme
stets aktualisiert und damit überschrieben werden, bleiben alle Daten in einem DWH
(zumindest über lange Zeit) für zeitraumbezogene Analysen unverändert erhalten.
Operative Systeme
Daten-
bereitstellung
Datenanalyse
bzw. Informationsgenerierung
Informationspräsentation und -distribution
BI
ERP SCM CRM PPS
ETL
ET
L
staging
C-DWH
ODS
DM DM DM
ET
L
Abbildung 7: Systemkomponenten eines DWH-Systems39
38 siehe [Inmon, 2005 S. 29 ff.]
39 eigener Entwurf in Anlehnung an [Gluchowski, et al., 2008 S. 132] und [Kemper, et al., 2010 S. 25].
Die bislang und hier verwendeten Farben für die verschiedenen System-Ebenen werden möglichst auch
weiterhin in den Abbildungen dieser Arbeit durchgehalten und stellen somit direkte optische Bezüge her.
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 18
Die Systemkomponenten eines DWH (Abbildung 7) werden wie folgt unterteilt40:
ETL- bzw. Transformationsprozess, der aus den transaktionsorientierten
(operativen) Daten schrittweise analyseorientierte (dispositive) Daten herstellt. ETL
steht für „Extraktion Transformation Laden“ und bezeichnete ursprünglich nur den
datentechnischen Übergang von den operativen Vorsystemen zum DWH.
Mittlerweile kommt eine Reihe von Transformationsprozessen zwischen den
Systemkomponenten eines DWH zur Anwendung.41
Core Data Warehouse (C-DWH) ist die gemeinsame Datenbasis eines BI-Systems
und verfolgt den Anspruch “einzige Quelle der Wahrheit” (single source of truth) für
alle betriebswirtschaftlichen Analysen im Unternehmen zu sein42. Neuere Ansätze
sprechen vom Enterprise Data Warehouse (E-DWH) und verdeutlichen damit,
dass es sich nicht unbedingt um eine (physikalisch) einzige Datenbank handeln
muss. Bei großen Datenmengen wird das DWH in einzelne „Fachdomänen“
aufgeteilt und durch ein Datenbank-Cluster logisch verbunden.43
Das C-DWH (oder E-DWH) ist somit ein umfangreicher (i.d.R. relationaler)
Datenspeicher, der mittels Transformationsprozessen mit Daten aus den
Vorsystemen oder dem ODS (s.u.) befüllt wird. Aus dem C-DWH werden dann die
Data Marts (s.u.) erzeugt bzw. die analytischen Prozesse und Anwendungen
(OLAP) gespeist. Im Gegensatz zum Data Mart wird im C-DWH eine möglichst
redundanzfreie Datenhaltung in normalisierter Form (also Trennung zwischen
Dimensions- und Faktentabellen, siehe Kapitel 2.2.3) verfolgt. Insbesondere muss
das C-DWH den o.g. Merkmalen der Datenspeicherung im DWH genügen.
Operational Data Store (ODS) ist konzeptuell ähnlich gestaltet wie das C-DWH. Im
Unterschied zum C-DWH speichert ein ODS extrahierte und bereinigte Daten der
operativen Vorsysteme, die aber noch vollständig detailliert und
transaktionsorientiert sind. Für das C-DWH ist der ODS somit eine Vorstufe, wo die
„ausgesuchten und korrigierten Rohdaten“ abgelegt werden. Vorteile vom ODS
ergeben sich für die Beherrschbarkeit der Datenkomplexität, für Maßnahmen bei
Systemfehlern (ähnlich Staging Area, s.u.) sowie für die Weiterentwicklung des BI-
Systems. Ferner findet das ODS in neueren BI-Systemen zur „Realtime-Analyse“
(z.B. für Call-Center) verstärkt Anwendung.44
40 Aspekte im Wesentlichen übernommen aus [Gluchowski, et al., 2008 S. 118 ff.] und
[Kemper, et al., 2010 S. 19 ff.], inhaltlich zusammengeführt und ergänzt.
41 vgl. [Kemper, et al., 2010 S. 25]
42 vgl. [Gluchowski, et al., 2008 S. 123].
43 vgl. [Bachmann, et al., 2011 S. 139]
44 vgl. [Gansor, et al., 2010 S. 54 f.]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 19
Staging Area ist eine reine „Eingangsablage“ für die Daten aus den operativen
Vorsystemen. Es dient i.d.R. als temporärer Zwischenspeicher, wo die
entnommenen Transaktionsdaten unverändert „geparkt“ werden, bis sie (zyklisch
oder bei Bedarf) vom BI-System importiert und verarbeitet werden. Ein Vorteil der
Staging Area ist, dass fehlgeschlagene Prozesse im BI-System nochmals wiederholt
werden können, ohne erneut auf die Daten der Transaktionssysteme (falls
überhaupt noch vorhanden) zurückgreifen zu müssen.45
Data Marts (DM) sind spezifisch Ausschnitte aus dem C-DWH. Durch
Transformationsprozesse (v.a. Aggregation und Anreicherung, siehe Kapitel 2.2.2)
werden aus dem C-DWH „materialisierte Sichten“46 erzeugt, die dann direkt einer
speziellen Applikation oder Funktion zur Verfügung stehen. Damit können DM schon
als Teil der Applikation selbst betrachtet werden, was einen schnellen Zugriff z.B.
auf standardisierte Reports ermöglicht.
Metadaten sind Informationen über die Daten selbst. Das sind zum einen
nutzerorientierte Angaben u.a. zu Art, Inhalt, Bedeutung und Herkunft der Daten
bzw. die Felder oder Attribute, die die Daten aufnehmen. Zum anderen helfen
systemorientierte Metadaten bei der Suche, Auswertung, Klassifizierung, Wartung
und Administration von Daten. Speziell in einem DWH werden durch zahlreiche
Transformationsprozesse die Daten verändert, verschoben, zusammengefasst,
ergänzt und neu abgeleitet. Einer finalen Kennzahl, z.B. das diesjährige
Betriebsergebnis, ist am Ende nicht mehr anzusehen, wie sie entstanden ist. Um
das Vertrauen in die Ergebnisse zu erhöhen und die Datenqualität sicherzustellen,
sollte auch die „Daten-Vita“ dokumentiert werden.47
Administrationsschnittstelle ist ein speziell gesicherter Zugang in den
„Maschinenraum“ des BI-Systems für Spezialisten aus der IT, der
Softwareentwicklung und den Fachbereichen eines Unternehmens. Hierüber kann
das BI-System technisch und fachlich gewartet, angepasst und erweitert werden.
Insbesondere die Zugriffsberechtigungen auf die Daten werden über diesen Zugang
vergeben und verwaltet.
Die genannten Systemkomponenten sind keine „Fertigbauteile“ für ein DWH-System,
sondern eher konzeptuelle Vorlagen für die spezifische Realisierung je nach Bedarf
45 vgl. [Gluchowski, et al., 2008 S. 131]
46 vgl. [Köppen, et al., 2012 S. 14]
47 vgl. [Köppen, et al., 2012 S. 32 f.] und [Kemper, et al., 2010 S. 47 ff.]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 20
und Situation im Unternehmen. Vor allem um den neueren Anforderungen nach großen
und z.T. auch riesigen Datenmengen unter dem Stichwort „Big Data“48 gerecht zu
werden, müssen die Systemkomponenten eines DWH sehr genau entworfen und
zugeschnitten werden.
M-BID Relevanz R6:
DWH-Konzept Entsprechend bei Konzeption zu berücksichtigen.
Merkmale eines DWH Sind Muss-Anforderungen an die Lösung.
DWH-Systemkomponenten M-BID wird durch eine zu konzipierende Auswahl der
möglichen Komponenten realisiert
2.2.2 Transformationsprozess - ETL
Die Transformationsprozesse (ETL) sind die zentralen Aktivitäten der Daten-
verarbeitung und stellen damit eine anspruchsvolle Aufgabe bei der Konzeption eines
BI-Systems dar. Von der Richtigkeit dieser Prozesse hängt der Erfolg eines „BI-
Projektes“ unmittelbar ab49.
Folgende Ergebnisse können diesbezüglich erwartet werden:
Schaffung einer ausreichenden Datenqualität im BI-System.
Verlässlichkeit und Akzeptanz der daraus entstandenen Analysen und Reports.
Anwendung und Mehrwert im täglichen Geschäftsablauf.
Anwendung als „Verbesserungsmotor“, siehe Kapitel 2.1.2.
Bereitstellung eines nützlichen und rentablen Unterstützungssystems.
Die Kosten eines BI-Projektes amortisieren sich, was zu einer dauerhaften
„Lebensberechtigung“ des BI-Systems führt.
Die beschriebene Erwartungshaltung macht deutlich, warum 70% bis 80% des Budgets
eines BI-Projektes für die ETL-Prozesse aufgewendet werden (müssen).50
Die Aufgabe von ETL-Prozessen ist die Transformation der Daten in den folgenden
Stufen51, siehe auch Abbildung 8:
Filterung: Sie besteht aus den Teilen
o Extraktion: Auswahl der Quelldaten aus den operativen Vorsystemen mittels
Import (z.B. via SQL-Abfragen) in den ODS bzw. in das C-DWH
48 siehe u.a. [pmOne AG, 2012 S. 6]
49 vgl. [Bachmann, et al., 2011 S. 87 f.]
50 [Bachmann, et al., 2011 S. 87]
51 Aspekte aus [Kemper, et al., 2010 S. 28 ff.] und [Gluchowski, et al., 2008 S. 133 ff.]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 21
o Bereinigung: Die importierten Daten werden nach syntaktischen und inhaltlichen
(semantischen) Fehlern untersucht und ggf. automatisch oder manuell gesäubert.
Harmonisierung: Die bereinigten Daten der einzelnen Vorsysteme werden zu einer
Datenbasis im C-DWH zusammengeführt. Hierbei wird die Harmonisierung
unterschieden in
o Syntaktisch: Eliminierung von Schlüsseldisharmonien z.B. bei
unterschiedlichen Kunden-ID‘s: „123“ vs. „K_123“ vs. „123#K“.
Egalisieren unterschiedlicher Kodierung der Werte, z.B. „w“ und „f“ für weiblich.
Auflösen von Synonymen, z.B. heißt das Objekt „Kunde“ in Tabellen mal „Knd“
mal „Customer“. Auflösen von Homonymen, z.B. bedeutet „Ansprechpartner“ mal
„Kunde“ mal „Lieferant“.
o Betriebswirtschaftlich: Abgleich der Kennzahlen und ihrer Werte. Ferner die
Festlegung der Granularitäten als kleinste „Korngröße“ der Dimensionen. Z.B.
wäre bei der Dimension „Zeit“ eine Auswahl der Granularitäten aus diesen
Dimensionsstufen möglich:
„Tag, Woche, Monat, Quartal, Jahr“
Entsprechend bei der Dimension „Ort“:
„Stadt, Region, Bundesland, Land“
Aggregation: Verdichten der Kennzahlen entlang der Dimensionsstufen, siehe
Kapitel 2.3.2. Z.B. bei den Granularitäten „Woche und Region“ wäre mit den o.g.
Dimensionsstufen durch Summieren folgendes ermittelbar:
o Umsatz pro Woche, pro Monat, pro Quartal; aber nicht der Tagesumsatz.
o Umsatz pro Region, pro Bundesland, pro Land; aber nicht pro Stadt
Anreicherung: Die Ursprungdaten werden mit weiteren Daten angereichert, um
spätere Analysen und Darstellungen zu vereinfachen oder zu beschleunigen. Somit
können z.B. die bei der Aggregation berechneten Umsatzsummen als zusätzliche
Werte abgespeichert werden. Ein erneuter Zugriff auf diese Werte wäre dann
performanter.
Laden: Die transformierten Daten werden in der jeweiligen Zielumgebung
abgespeichert. Das ist je nach Stufe der Transformation der ODS, das C-DWH oder
die DM.
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 22
Operative SystemeSystem 1
Informationspräsentation und -distribution
Filterung:
- Extraktion
- BereinigungExtrakt 1
System 2
Extrakt 2
Harmonisierung:
- syntaktisch
- betriebswirtschaftlich
Anreicherung:
- Kennzahlen
- Analysen
- Metadaten
Aggregation:
- Dimensionierung
- Verdichtung
Abbildung 8: ELT - Transformationsprozess im BI-System52
M-BID Relevanz R7:
ETL-Prozesse sind anspruchsvoll Transformationen sind genau zu konzipieren und für
die Umsetzung im entsprechenden M-BID-Funktionsmodul formal zu beschreiben.
ETL macht 70% bis 80% des BI-Budgets aus Entsprechend ist Zeit für die Konzeption
und Umsetzung vorzusehen.
2.2.3 Modellierung und Speicherung der Daten
Die Datenmodellierung, also die Gestaltung der Datenstruktur im DWH, ist eine
entscheidende Aktivität beim Aufbau eines BI-Systems. Mit einer zu den
unternehmensinternen Strategien und Anforderungen passenden Datenstruktur wird im
BI-System die Grundlage für eine performante, konsistente und flexible Verarbeitung
und Analyse gelegt.
Dabei wird wie folgt unterschieden:53
Physische Modellierung definiert, wie die Daten tatsächlich (technisch) auf dem
Datenträger gespeichert werden. Sie ist eine Aufgabe der Hersteller von
52 eigener Entwurf in Anlehnung an [Kemper, et al., 2010 S. 48]
53 vgl. [Totok, 2000 S. 123 ff.] und [Kemper, et al., 2010 S. 58 f.]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 23
Datenbanksystem (DBS) bzw. der Datenbankmanagementsysteme (DBMS) und ist
unabhängig von den konkreten Problemlösungen im BI-System.
Semantische Modellierung ist die „Modellierung der realen Welt“, also das
Analysieren von betrieblichen Objekten, Strukturen und Prozessen und die
entsprechende Gestaltung der Daten bzw. Datencontainer im DWH. Im Kontext
eines BI-Systems ist das insbesondere die Modellierung der Kennzahlen und der
entsprechenden Dimensionen, ausgehend von einer Analyse des Informations-
bedarfes und der zur Verfügung stehenden Daten in den operativen Vorsystemen.54
Dazu steht eine Reihe von Prinzipien, Verfahren und Werkzeugen zur Verfügung,
wie insbesondere:
o Entity Relation Model (ERM), wodurch jeder Ausschnitt der Realität durch
Objekte (Entities) und ihre Beziehungen zueinander (Relations) definiert wird.
o Objektorientierte Modellierung (OO-Modellierung) erweitert den Grund-
gedanken von ERM. Dabei hat ein Objekt als Repräsentant der realen Welt
„Zustände und Eigenschaften“ in Form von Attributen, sowie „Fähigkeiten und
Verhalten“ in Form von Methoden bzw. Operationen. Ferner wurde die
Möglichkeit geschaffen, dass Objekte bzw. Objektklassen voneinander Attribute
und Methoden „erben“ können.55
o Unified Modeling Language (UML) ist ein auf die OO-Modellierung
basierendes Standard-Notationssystem, welches die OO-Prinzipien in Form von
Symbolen für die i.d.R. komplexen Modellentwürfe vorhält.
o Architektur integrierter Informationssysteme (ARIS) ist ein von A.W. Scheer
entwickelter und anerkannter Rahmen für die Modellierung von betrieblichen
Informationssystemen.56
o ADAPT ist ein Notationssystem, das speziell für die multidimensionale
Modellierung eines DWH entwickelt wurde. Es stellt Symbole insbesondere für
die Gestaltung von komplexen OLAP-Datenwürfeln (siehe Kapitel 2.3.2) zur
Verfügung.
Für die semantische Modellierung gibt es eine Reihe von Softwaresystemen bzw.
Anwendungen, die den Modellierungsprozess und den grafischen Entwurf
unterstützen.57
54 vgl. [Köppen, et al., 2012 S. 48]
55 vgl. [Totok, 2000 S. 139-141]
56 vgl. [Gansor, et al., 2010 S. 264]
57 vgl. [Gansor, et al., 2010 S. 256]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 24
Logische Modellierung verbindet die semantische und die physische
Modellierungsebene und legt fest, welche logische Form der Datenhaltung im DWH
genutzt wird. Die wichtigste Variante ist derzeit das „Relationale Datenmodell“58, auf
das im Folgenden genauer eingegangen wird.
Die Datenspeicherung im DWH erfolgt typischerweise in einem oder (physikalisch)
mehrere Datenbanken mit relationalen Datenbankmanagementsystemen (RDBMS).
Zwar gibt es Lösungen von nicht-relationalen Datenbanksystemen, die der
Anforderung nach „multidimensionalen Datenräumen“ direkter entsprechen, doch
haben sie sich derzeit aus Gründen der technischen Reife und der Verfügbarkeit auf
dem Markt nur zum Teil durchgesetzt.59
Allerdings wurde der Anforderung durch spezielle Ansätze bei der Datenabfrage
Rechnung getragen; siehe Kapitel 2.3.2. Diese Ansätze werden als R-OLAP
(Relationales OLAP) bezeichnet60. Insofern stehen für die Datenmodellierung
grundsätzlich die gleichen Prinzipien wie bei „klassischen“ operativen RDBMS zur
Verfügung.
Hierbei sind einige Grundbegriffe von Bedeutung:
Normalisierung bzw. Normalform dient dazu die Daten möglichst redundanzfrei
(also ohne Mehrfachspeicherung) in den Datenbanktabellen abzulegen. Diese Form
der Speicherung ermöglicht Konsistenz und Wartbarkeit der Daten.61 Um sie
weitestgehend zu erreichen werden Datentabellen unterschieden in Faktentabellen
und Dimensionstabellen.
Faktentabellen beinhalten die eigentlichen Nutzdaten. Insbesondere werden die
numerischen Werte von Kennzahlen (z.B. Zahlen wie 45230,24) vom BI-System
analysiert, in Berechnungen einbezogen und dem Nutzer dargestellt. 62
Dimensionstabellen beinhalten die Dimensionen der Daten, siehe auch Kapitel
2.2.2. Dimensionen beschreiben die Nutzdaten, indem sie sie kategorisieren. So ist
die o.g. Zahl 45230,24 z.B. der Umsatz in Euro im Monat „Mai“ in der Filiale
„Hamburg“ mit dem Produkt „Mountainbike-Plus“. Erst über die Dimensionen
bekommen Daten einen Bezug zu Zeit, Ort und Bedeutung, sodass die Werte
sinnvoll analysiert und verarbeitet werden können.63
58 vgl. [Kemper, et al., 2010 S. 59]
59 vgl. [Köppen, et al., 2012 S. 52] und [Kemper, et al., 2010 S. 106]
60 vgl. [Köppen, et al., 2012 S. 140]
61 vgl. [Gluchowski, et al., 2008 S. 99]
62 vgl. [Kemper, et al., 2010 S. 66]
63 vgl. [Gluchowski, et al., 2008 S. 155]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 25
Dimensionsstufen oder Dimensionshierarchie gibt die möglichen bzw. erlaubten
Ebenen einer Dimension vor, siehe auch Kapitel 2.2.2. und 2.3.2. Damit lassen sich
Aggregate je Stufe errechnen. Der o.g. Umsatz von 45230,24€ ist somit auf der
Stufe „Monat“ aggregiert worden; ein Wochenumsatz derselben Filiale mit
demselben Produkt wäre z.B. 11307,55€.
Historisierung der Daten ist das zentrale Konzept eines DWH für den
Zeitraumbezug, siehe Kapitel 2.2.1. Damit zeitbezogene Analysen wie z.B.
Zeitreihen möglich werden, müssen alle Daten einen „Zeitstempel“ oder
„Revisionsstand“ erhalten. Das gilt zum einen für die Nutzdaten in den
Faktentabellen; der o.g. Umsatz von 45230,24€ würde z.B. den Revisionsstand
„01.06.2013“ am Tag der Berechnung bekommen. Zum anderen unterliegen auch
die Daten in den Dimensionstabellen einer (wenngleich auch langsameren)
zeitlichen Veränderung, wie z.B. die Umbenennung des Produktes „Mountainbike-
Plus“ in „Smart-Mountainbike“.64
Für die semantisch-logische Modellierung stehen prinzipiell die folgenden Schemata
zur Verfügung65:
Star-Schema besteht aus einer Faktentabelle mit mehreren denormalisierten
Dimensionstabellen auf genau zwei Modellierungsebenen, siehe Abbildung 9.
Fact_Umsatz
PK ID_Umsatz
Wert RevisionFK1 ID_ProduktFK2 ID_ZeitFK3 ID_OrtFK4 ID_Kunde
Dim_Produkt
PK ID_Produkt
Bezeichnung Revision Verkaufspreis Einkaufspreis Produktgruppe
Dim_Ort
PK ID_Ort
Bezeichnung Revision Filiale Region
Dim_Zeit
PK ID_Zeit
Datum Revision
Dim_Kunde
PK ID_Kunde
Name Revision Adresse Kundengruppe
Abbildung 9: Star-Schema66
Snowflake-Schema ist ein erweitertes Star-Schema mit einer Faktentabelle und
mehreren stets normalisierten Dimensionstabellen auf mehreren Modellierungs-
ebenen, siehe Abbildung 10.
64 vgl. [Kemper, et al., 2010 S. 71-82], [Totok, 2000 S. 180-192] und [Baumöl, 1999 S. 345]
65 vgl. [Kemper, et al., 2010 S. 58-71], [Gluchowski, et al., 2008 S. 282-289],
[Köppen, et al., 2012 S. 52-61] und [Totok, 2000 S. 171-179]
66 eigener Entwurf in Anlehnung an [Köppen, et al., 2012 S. 55]
2.2 Bereitstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 26
Fact_Umsatz
PK ID_Umsatz
Wert RevisionFK1 ID_ProduktFK2 ID_ZeitFK3 ID_OrtFK4 ID_Kunde
Dim_Produkt
PK ID_Produkt
Bezeichnung Revision Verkaufspreis EinkaufspreisFK1 ID_Produktgruppe
Dim_Ort
PK ID_Ort
Bezeichnung RevisionFK1 ID_Filiale
Dim_Zeit
PK ID_Zeit
Datum RevisionFK1 ID_Monat
Dim_Kunde
PK ID_Kunde
Name Revision AdresseFK1 ID_Kundengruppe
Dim_Kundengruppe
PK ID_Kundengruppe
Bezeichnung Revision
Dim_Produktgruppe
PK ID_Produktgruppe
Bezeichnung Revision
Dim_Filiale
PK ID_Filiale
Bezeichnung RevisionFK1 ID_Region
Dim_Region
PK ID_Region
Bezeichnung Revision
Dim_Monat
PK ID_Monat
Name RevisionFK1 ID_Jahr
Dim_Jahr
PK ID_Jahr
Jahreszahl Revision
Abbildung 10: Snowflake-Schema67
Fact-Constellation-Schema ist eine Struktur, die ähnlich wie das Star-Schema
aussieht, jedoch zusätzliche Faktentabellen besitzt, z.B. Summentabellen für das
Abspeichern von Aggregaten, siehe Abbildung 51 im Anhang 3.
Galaxy-Schema ist die Kombination aus Snowflake-Schema und Fact-
Constellation-Schema. Bei diesem Schema können die Faktentabellen mit
beliebigen Dimensionstabellen der verschiedenen Modellierungsebenen bzw.
Hierarchiestufen verknüpft sein, siehe Abbildung 52 im Anhang 3.
Bei der Modellierung der unterschiedlichen Komponenten eines DWH können
verschiedene Schemata zum Einsatz kommen. So beinhaltet der ODS mit seinen
operativen „Rohdaten“ üblicherweise mehr heterogene Details und Redundanzen als
das C-DWH, bei dem besonders auf Normalisierung geachtet wird, um die Daten für
die verschiedenen Analysen so flexible wie möglich und nötig bereitzustellen. Bei den
Data-Marts (DM) wird dann wieder auf die Normalisierung zu Gunsten eines schellen
und speziellen Zugriffs auf die Daten von den Reporting-Anwendungen verzichtet68.
M-BID Relevanz R8:
Datenmodell muss zu Strategien und Anforderungen im Unternehmen passen Die IST-
Analyse stellt den derzeitigen Stand möglichst formal dar, damit in der Konzeption die
semantische Modellierung der Datenstruktur durchgeführt werden kann.
ERM, OO-Modellierung Die Modellierungsansätze sind entsprechend anzuwenden
67 eigener Entwurf in Anlehnung an [Köppen, et al., 2012 S. 54]
68 vgl. [Köppen, et al., 2012 S. 15, 27] und [Kemper, et al., 2010 S. 42 f.]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 27
UML, ADAPT Notationssysteme für die Konzeption: Für die Modellierung der
Geschäftsobjekte und deren Beziehungen wird UML genutzt. Für die OLAP-Modellierung
(Kapitel 2.3.2) wird ADAPT verwendet.
Daten-Schemata: Eine geeignete Struktur für das DWH des M-BID ist aus einer
Kombination der Grundschemata zu entwickeln.
2.3 Analyse und Darstellung der Daten
2.3.1 Kategorien von Analysesystemen
Im Laufe der letzten Jahrzehnte sind zahlreiche Analysesysteme für die verschiedenen
Einsatzbereiche und Problemstellungen innerhalb eines Unternehmens entwickelt
worden. Dabei wurde es zunehmend schwieriger die große Vielfalt der diesbezüglichen
Anwendungssysteme sinnvoll zu kategorisieren.
Frühere Ansätze ordnen die Anwendungssysteme den Managementebenen zu, die sie
unterstützen (Managementpyramide, siehe auch Abbildung 2 in Kapitel 2.1.2).
Mittlerweile unterstützen BI-Anwendungssysteme taktische und dispositive Aktivitäten
(diagonal) hinweg über die Geschäftsbereiche (horizontal) und Managementebenen
(vertikal), sodass eine Kategorisierung mittels Managementpyramide nicht mehr
hilfreich erscheint.69
Neuere Ansätze kategorisieren die Anwendungssysteme bzw. deren Komponenten
deshalb nach den technischen oder fachlichen Methoden, die ihnen zugrunde liegen,
siehe Abbildung 11.
Implementierungsansätze
- Klassisches Data Warehousing - Realtime Data Warehousing- Closed-loop Data Warehousing - Active Data Warehousing
Konzeptorientierte Systeme
- Balanced Scorecard - Konsolidierung- Planung und Budgetierung - Wertorientiertes Management
Generische Basissysteme
Berichtssysteme
- Interaktive Reporting-Plattform- Generische Berichte (MIS, EIS)
Freie Datenrecherchen
- SQL 2003- MDX
Modellgestützte Analysen
- DSS, Expert Systems- Data/Text/WebProcess Mining
OLAP Systeme
- Freie OLAP-Analysen- Geführte OLAP-Analysen
Abbildung 11: Analysesysteme für das Management70
69 vgl. [Kemper, et al., 2010 S. 86, 87, 90] und [Bachmann, et al., 2011 S. 105]
70 vgl. [Kemper, et al., 2010 S. 90]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 28
Im Sinne des Schwerpunktes der vorliegenden Arbeit, siehe auch Abgrenzung im
Kapitel 1.3, werden insbesondere die folgenden Grundlagen vorgestellt:
Online Analytical Processing (OLAP), als Basistechnologie zur Analyse
betrieblicher Kennzahlen, sowie das
Reporting innerhalb der Berichtssysteme, als Rahmen zur Darstellung betrieblicher
Kennzahlen.
Aus den andern Kategorien werden zudem einzelne Aspekte herausgegriffen, insofern
sie für OLAP oder das Reporting unterstützend wirken.
M-BID Relevanz R9:
Kategorien der Anwendungssysteme Der Schwerpunkt von M-BID reiht sich durch die
Zielvorgaben in die generischen Systeme ein. Entsprechende technische oder fachliche
Methoden sind zu berücksichtigen.
2.3.2 OLAP - Online Analytical Processing
Anforderungen an ein OLAP-System
Der Begriff „OLAP“ wurde von E.F. Codd schon 1993 geprägt und stellte einen
(damals) innovativen Ansatz zur Analyse betriebswirtschaftlicher Daten in
multidimensionalen Datenräumen vor.71 Ursprünglich wurden zwölf, aber bis 1995
schon fast 300 Aspekte identifiziert, wann man von einem OLAP-System sprechen
kann. Letztlich wurden fünf wesentliche Kriterien konsolidiert, die ein OLAP-System
definieren. Diese Kriterien formulierte N. Pendse und R. Creeth 1995 unter dem
Akronym FASMI: 72
Fast: Das System muss schnell sein. Anfragen sollen je nach Komplexität in 5 bis
20 Sekunden bearbeitet sein.
Analysis: Das System muss umfangreiche Analyse-, Berechnungs- und
Darstellungsmöglichkeiten anbieten. Dabei soll das System möglichst intuitiv und
ohne Systemkenntnisse bedienbar sein.
Shared: Das System muss multiuser-tauglich sein. V.a. muss eine Steuerung der
Zugriffsrechte auf die Daten möglich sein.
Multidimensional: Als Kernkonzept muss das System die multidimensionale Sicht
auf die Daten realisieren; siehe OLAP-Datenwürfel unten.
Information: Das System muss mit großen Datenmengen umgehen können, ohne
dass die Performanz bei hoher Auslastung sinkt.
71 vgl. [Totok, 2000 S. 55, 57]
72 vgl. [Kemper, et al., 2010 S. 100], [Totok, 2000 S. 61 f.] und [Baumöl, 1999 S. 355]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 29
M-BID Relevanz R10:
FASMI-Kriterien eines OLAP-Systems Muss-Anforderungen bei der Konzeption und
Umsetzung des entsprechenden M-BID-Funktionsmoduls
Umsetzungsvarianten
Zur Speicherung und Handhabung der „multidimensionalen Datenräume“ werden
verschiedene Varianten genannt.73
R-OLAP = Relationales OLAP, das auf ein „klassisches“ relationales
Datenbanksystem (RDBMS, siehe auch Kapitel 2.2.3) aufsetzt, aber für die
Datenbankabfragen in Bezug auf die „Multidimensionalität“ optimiert wurde:
o SQL:2013 stellt eine entsprechende Erweiterung der Standard-Abfragesprache
SQL dar.74
o MDX ist eine proprietäre Abfragesprache für Microsoft Datenbanken speziell für
multidimensionale Abfragen. Dabei wird nicht wie bei SQL zunächst auf Tabellen,
sondern auf Cubes (Datenwürfel) zugegriffen. Daraus lassen sich dann
Ausschnitte eines Cube, sogenannte Cellsets extrahieren, die dann u.a. wie
Tabellen weiterbehandelt werden können.75
M-OLAP = Multidimensionales OLAP, ermöglicht die direkte Speicherung von
multidimensionalen Datenräumen in speziell realisierten (herstellerspezifischen)
Datenbanken. Hierdurch soll der Zugriff auf die Datenwürfel besonders performant
werden.
H-OLAP = Hybrides OLAP, stellt die Verbindung bzw. die Zweigleisigkeit der o.g.
Varianten dar. Wie beim Übergang von SQL zu SQL:2013 und schließlich zu MDX
bereits zu sehen ist, werden die Grenzen zwischen R-OLAP und M-OLAP in der
Praxis immer unschärfer.76
M-BID Relevanz R11:
R-OLAP bzw. H-OLAP Bei technischer Konzeption und Umsetzung zu berücksichtigen
SQL2013 bzw. MDX Bei Realisierung/Programmierung der Datenbankabfragen relevant
OLAP-Datenwürfel
Da die entscheidungsrelevanten Informationen aus dem Unternehmen von Natur aus
multidimensional sind, ist „Multidimensionalität“ für ein diesbezügliches Informations-
73 vgl. [Totok, 2000 S. 66 f.] , [Köppen, et al., 2012 S. 140-152] und [Kemper, et al., 2010 S. 106 f.]
74 vgl. [Köppen, et al., 2012 S. 122-129]
75 vgl. [Gluchowski, et al., 2008 S. 186 f.] und [Köppen, et al., 2012 S. 129-135]
76 vgl. [Totok, 2000 S. 70 f.]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 30
system eine Grundanforderung.77 Ein OLAP-System spannt hierfür einen
mehrdimensionalen Datenraum auf, der verschiedene Sichten auf die Daten
ermöglicht.
Dieser mehrdimensionale Datenraum wird typischerweise in Form eines Datenwürfels
(Cube) dargestellt, siehe Abbildung 12. Die Kanten des Würfels repräsentieren die
Dimensionen z.B. Produkt, Zeit, Ort. Die einzelnen Zellen (Cells) des Würfels
beinhalten jeweils einen zugehörigen Wert (Value) einer bestimmten Kennzahl z.B. den
Umsatz. Die verschiedenen Sichten auf die Daten werden durch bestimmte
Ausschnitte aus dem Würfel „Cellset“ realisiert, z.B. nur alle Umsätze der Produkte und
Regionen ab dem Jahr 2005.
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
A4a B4a C4a D4a
A3a B3a C3a D3a
A2a B2a C2a D2a
A1a B1a C1a D1a
Ort
Ze
it
Produkt
cb
d
a
1
2
3
4
A B C D
Abbildung 12: Cube mit den Dimensionen Produkt, Zeit und Ort78
Auch wenn ein Würfel nur drei Dimensionen hat, so kann der im OLAP-System
aufgespannte Datenraum wesentlich mehr (theoretisch unendlich viele) Dimensionen
besitzen. Dieser Umstand wird mitunter durch die Bezeichnung „Hypercube“ statt nur
„Cube“ verdeutlicht.
Für die Erläuterung der nachfolgenden OLAP-Funktionen werden in Abbildung 13 die
relevanten Begriffe (auch aus Kapitel 2.2.2 und 2.2.3) nochmals aufgegriffen und im
Kontext eines Cube mit einem UML-Diagramm dargestellt. Insbesondere der komplexe
Zusammenhang79 zwischen „Dimension“, „Granularität“ „Dimensionsstufe“,
,„Aggregation“ und „Dimensionsstufenelement“ lässt sich damit veranschaulichen.
In einem DWH werden i.d.R. viele Cubes benötigt. Bei dem sogenannten „Multicube-
Ansatz“ wird für jede Kennzahl ein neuer Cube entworfen. Dabei können die
verschiedenen Dimensionen in beliebiger Anzahl und Kombination in mehreren Cubes
vorkommen.
77 vgl. [Totok, 2000 S. 75]
78 eigener Entwurf in Anlehnung an [Kemper, et al., 2010 S. 101]
79 vgl. [Gluchowski, et al., 2008 S. 151-155]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 31
= Umsatz
Cube
= Zeit
Dimension
11..*
= Quartal
Dimensionsstufe
1 1..*
= Q2
Dimensionsstufenelement
1
1..*
= Monat
Granularität
1
1
= Jahr
Aggregation
1
1
= Q2/all/all
Cellset
1 1..* = Q2/Köln/Radio
Cell
1 1..*
= 1351,25
Value
11
Abbildung 13: UML-Diagramm der Cube-Komponenten mit Beispielbefüllung80
Beim „Singlecube-Ansatz“ hingegen werden alle Kennzahlen und Dimensionen in
einem einzigen Cube abgelegt. Diese Variante ist aber meist nicht günstig, da sie
unsinnige Kombinationen abbildet bzw. zulässt (z.B. Verkaufspreis pro Mitarbeiter) was
für die Anwendung explizit wieder verhindert werden muss. Ferner wird durch den
vielen Leerstand im Cube der Speicherplatz nicht optimal genutzt.81
Hier einige Beispiele in der Form
Cube-ID: Zelleninhalt (Dimension 1, Dimension 2, … , Dimension N):
Cube-1: Umsatz (Produkt, Zeit, Ort)
Cube-2: Deckungsbeitrag (Produkt, Zeit, Ort)
Cube-3: Auftragseingang (Produkt, Vertriebsmitarbeiter, Ort, Zeit)
Aber auch die Zellen können mit unterschiedlichen Kennzahlen z.B. pro Scheibe (Slice,
s.u.) belegt sein82. Das ist immer dann sinnvoll, wenn mehrere Kennzahlen die
gleichen Dimensionen besitzen, aber unterschiedliche Szenarien:
Cube-4: Umsatzkennzahlen (Produkt, Zeit, Ort, Szenarien) mit Szenarien aus der
Menge (Ist, Plan, Abweichung)
OLAP-Grundfunktionen
Im Folgenden sind die Funktionen beschrieben, die ein OLAP-System standardmäßig
zur Verfügung stellt.83
80 eigener Entwurf
81 vgl. [Totok, 2000 S. 119-121]
82 vgl. [Totok, 2000 S. 56]
83 vgl. [Köppen, et al., 2012 S. 109-135], [Kemper, et al., 2010 S. 99 - 106],
[Gluchowski, et al., 2008 S. 143-191], [Totok, 2000 S. 55-64], [Baumöl, 1999 S. 351-356., 377-384]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 32
Rotate oder Pivot: Diese Funktion dreht den Cube um eine oder mehrere Achse(n),
sodass eine andere Sicht auf die Daten entsteht. In einer OLAP-Anwendung würde
man die anzuzeigenden Dimensionen umstellen und die Funktion Rotate ändert
dann entsprechend die Perspektive auf die Kennzahlen, z.B.:
Umsätze für einen Ort je (Produkt, Zeit) Umsätze für einen Zeitraum je (Produkt,
Ort), siehe Abbildung 14.
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
A4a B4a C4a D4a
A3a B3a C3a D3a
A2a B2a C2a D2a
A1a B1a C1a D1a
Ort
Ze
it
Produkt
cb
d
a
1
3
4
A B C D
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
Aa1 Ba1 Ca1 Da1
Ab1 Bb1 Cb1 Db1
Ac1 Bc1 Cc1 Dc1
Ad1 Bd1 Cd1 Dd1
Zeit
Ort
Produkt
32
4
1
d
b
a
A B C D
c2
Abbildung 14: Funktion Rotate oder Pivot84
Drill-down und Roll-up sind zwei entgegengesetzte Funktionen. Drill-down erhöht
den Detaillierungsgrad entlang einer Dimension, indem sie die Daten einer tieferen
Dimensionsstufe zurückliefert, siehe Abbildung 15. In einer OLAP-Anwendung
würden man z.B. mit Hilfe eines Plus-Zeichens „+“ ein bestimmtes Jahr „aufklappen“
und darunter die Werte für die einzelnen Monate sehen. Entsprechend liefert Roll-up
die aggregierten Werte der nächsthöheren Dimensionsstufe, z.B. durch
entsprechendes „Zuklappen“ des Jahres.
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
A4a B4a C4a D4a
A3a B3a C3a D3a
cb
d
3
4
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
A4a B4a C4a D4a
A3a B3a C3a D3a
A2a B2a C2a D2a
A1a B1a C1a D1a
Ze
it
Produkt
cb
d
a
1
2
3
4
A B C D
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
A2.2a B2.2a C2.2a D2.2a
A2.1a B2.1a C2.1a D2.1a
A2a B2a C2a D2a
A1a B1a C1a D1a
Ze
it
Produkt
cb
d
a
1
2
2.1
2.2
A B C D
...
___
___
Drill-Down
Roll-Up
Abbildung 15: Funktion Drill-down und Roll-up85
84 eigener Entwurf in Anlehnung an [Köppen, et al., 2012 S. 110]
85 eigener Entwurf in Anlehnung an [Köppen, et al., 2012 S. 111]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 33
Drill-throught und Drill-across sind Funktionen, mit denen sich die
Datenrecherche erweiterten lässt. Wenn in den Cubes z.B. des C-DWH die höchste
Detaillierung bzw. die Granularität erreicht ist, kann mit Drill-throught eine
physikalisch andere Datenquelle „angebohrt“ werden (z.B. der ODS), um noch an
weitere Details zu gelangen. Drill-across ermöglicht die Auswertung über
unterschiedliche Cubes hinweg, aber innerhalb einer Datenbank. Es können z.B. die
Handelsspannen ermittelt werden, indem aus zwei gleichdimensionierten Cubes die
zugehörigen Differenzen aus Verkaufspreis und Einstandspreis errechnet werden,
siehe Abbildung 16.
B2a
123 12315
33 11
22
B2a
123 12312
24 10
17
B2a
123 123
9 1
5=
3-
EinstandspreisVerkaufspreis Handelspanne
Abbildung 16: Funktion Drill-across86
Silce und Dice generieren spezielle Cellsets aus dem Cube. Slice „schneidet
Scheiben“ aus dem Cube, z.B. nur alle Umsätze aus einem bestimmten Produkt.
Dice erzeugt einen Teilraum aus dem Cube, siehe Abbildung 17.
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
A4a B4a C4a D4a
A3a B3a C3a D3a
A2a B2a C2a D2a
A1a B1a C1a D1a
Ze
it
Produkt
cb
d
a
1
2
3
4
A B C D
Slice Dice
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
123 123 123 123
A4a B4a C4a D4a
A3a B3a C3a D3a
A2a B2a C2a D2a
A1a B1a
Ze
it
Produkt
cb
d
a
1
2
3
4
A B C D
C1a D1a
Abbildung 17: Funktionen Slice und Dice87
Split und Merge verhelfen zu einer weiteren Darstellungsvariante der Daten bei der
Projektion auf die Ebene. Split gruppiert die Daten nach den Elementen einer
bestimmten Dimensionsstufe, z.B. alle Umsätze je (Produkt, Zeit) gruppiert nach
86 eigener Entwurf in Anlehnung an [Kemper, et al., 2010 S. 104]
87 eigener Entwurf in Anlehnung an [Köppen, et al., 2012 S. 111]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 34
den Orten, siehe Abbildung 18. Merge ist die inverse Funktion und entfernt die
Gruppierungsebene wieder.88
Gruppe: Ort Produkt / Zeit 1 2 3 4
a
b
A A1a A2a A3a A4a
B B1a B2a B3a B4a
C C1a C2a C3a C4a
D D1a D2a D3a C4a
A A1b A2b A3b A4b
B B1b B2b B3b B4b
... ... ... ... ...
Abbildung 18: Funktion Split89
M-BID Relevanz R12:
OLAP-Analyse bzw. Multidimensionalität Muss-Anforderung bei der Realisierung.
Datenwürfel (Cube) Ist bei der Konzeption des DWH das Kernelement der Modellierung
und wird mittels ADAPT spezifiziert.
OLAP-Funktionen Für die Umsetzung wird das entsprechende M-BID-Funktionsmodul
mit geeigneten OLAP-Funktionen zur Darstellung und Planung von Kennzahlen (Kapitel
2.3.3) konzipiert.
2.3.3 Reporting, Kennzahlen und Dashboards
Reporting
Reporting ist der im IT-Kontext gebräuchliche englische Begriff für das Berichtswesen,
das die Informationsversorgung in einem Unternehmen sicherzustellen hat. Dabei ist
eine Informationskongruenz zu erreichen, wie sie schon im Kapitel 2.1.2 erwähnt ist.
Die im Berichtswesen entstehenden Dokumente sind Berichte bzw. Reports, die in
allen Unternehmensbereichen und auf allen Ebenen zum Einsatz kommen. Hierbei
helfen i.d.R. IT-Systeme, die entsprechend als Berichts- oder Reportingsysteme
bezeichnet werden.90
Insbesondere erzeugen BI-Systeme solche Berichte, die dem Empfänger als
Grundlage für unternehmerische Entscheidungen und Aktivitäten dienen. Für die
Gestaltung der Berichte sind deshalb folgende Kriterien von Bedeutung, die in den
jeweiligen Anwendungsklassen () entsprechende Berücksichtigung finden:91
88 vgl. [Kemper, et al., 2010 S. 103]
89 eigener Entwurf in Anlehnung an [Kemper, et al., 2010 S. 106]
90 vgl. [Totok, 2000 S. 25] und [Gluchowski, et al., 2008 S. 205 f.]
91 vgl. [Gluchowski, et al., 2008 S. 205-209, 218], [Gansor, et al., 2010 S. 45 f.] und
[Klein, 2012 S. 49 f.]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 35
Sender, Ersteller und Empfänger der Berichte; das können jeweils
Einzelpersonen und Gruppen sein.
Die unterschiedlichen Ausrichtungen finden sich in Individualanwendungen,
Teamlösungen und Kollaborationssystemen.
Zweck der Berichte, wie Dokumentation, Entscheidungsvorbereitung, Kontrolle und
Aktivitäten-Trigger.
Das wird je nach Schwerpunkt in den Dispositionssystemen sowie in den
Managementsupportsystemen (siehe Abbildung 3, Kapitel 2.1.2) und insbesondere
in den BI-Systemen umgesetzt.
Inhalt der Berichte, also die fachlichen Objekte und deren Beziehungen, sowie die
Detaillierung und Genauigkeit der Angaben.
Dispositionssysteme arbeiten eher mit detaillierten, Managementsysteme eher
mit verdichteten Daten.
Reichweite, die aufzeigt, von welcher Art und Bedeutung die Aufgaben sind, denen
der Bericht dienlich sein soll: Strategisch, taktisch, operativ.
Entsprechen werden strategische, taktische und operative Systeme für die
unterschiedlichen Managementebenen verwendet.
Form der Berichte, die sich in Darstellungsart, Struktur, Interaktivität, Medium und
Übertragungsart unterscheidet.
Hier kann das Standard-Reporting für das klassische Berichtswesen vom
modernen Management-Cockpit mit seinen interaktiven Oberflächen unterschieden
werden.
Zyklus der Berichte (z.B. täglich, monatlich), der das Erstellungsintervall und den
entsprechenden Betrachtungszeitraum angibt.
Entsprechend bieten die Reportingsysteme u.a. Tages- Wochen- und
Monatsberichte an.
Distribution der Berichte, die in „aktiv“ und „passiv“ polarisiert werden kann92.
Die passiven Reportingsysteme mit ihren Ad-hoc-Berichten, v.a. mittels OLAP-
Analyse, sind für die „Informations-Selbstversorgung“ und verfolgen somit eine Pull-
Strategie. Die Systeme mit automatisierten zyklischen Berichten zählen zu den
aktiven Reportingsystemen und verfolgen eine Push-Strategie, die dem Empfänger
die Informationen aktiv „zuschiebt“. Frühwarnsysteme sind darunter eine spezielle
Klasse, da sie bei Toleranzüberschreitung einer Kennzahl sofort (aperiodisch) einen
Abweichungsbericht generieren und dem Empfänger z.B. per Email zusenden93. Sie
„triggern“ aktiv eine Reaktion beim Empfänger und sind damit ein „proaktives“
System mit klarer Push-Strategie.
92 vgl. [Kemper, et al., 2010 S. 126 f.]
93 vgl. [Totok, 2000 S. 26]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 36
Die genannten Anwendungsklassen und deren Merkmale dienen jedoch mehr der
systematischen Darstellung als der praktischen Unterscheidung der Systeme. In
modernen interaktiven BI-Portalen bzw. Management-Cockpits (s.u.) werden alle
Aspekte so gestaltet und kombiniert, dass sie insbesondere den tatsächlichen
Anforderungen im Unternehmen genügen (form follows function). So schließt sich eine
verdichtete Visualisierung in Form von Geschäftsgrafiken oder Dashboard-Elementen
und eine Detailansicht in Standard-Tabellenform nicht mehr aus94.
M-BID Relevanz R13:
Reporting als Informationsversorgung Ist bei den Zielen vorgesehen und wird bei den
Konzeptionenzielen genauer spezifiziert.
Anwendungsklassen von BI-Systemen Die jeweiligen Kriterien sind
Untersuchungsgegenstände und gehen in das Umsetzungskonzept ein.
Gestaltung eines Reports
„Kein Empfänger liest Berichte aus Freude an der Interpretation von Rohdaten. Er
interessiert sich einfach nur für die wesentlichen Entwicklungen.“95
Aus der betrieblichen Praxis hat sich deshalb eine Reihe von Hinweisen und
Empfehlungen für die inhaltliche und visuelle Gestaltung von Berichten bzw. Web-
Reports herauskristallisiert, die die systematischen Forderungen nach Übersichtlich-
keit, Wiedererkennungswert, konsistenter Struktur, geeigneter Navigation und intuitiver
Bedienbarkeit untermauern oder sinnvoll ergänzen96:
Der Report sollte bezüglich Aussehen und Begrifflichkeiten durchgängig gestaltet
werden. Dazu dient das Erstellen einer Design-Vorlage (Layout Template). Bei
Web-Anwendungen wird eine Vorlage meist durch die Entwicklungsumgebung
ermöglicht oder gefordert. Für komplexe Web-Portale bzw. Management-Cockpits
ist ein Layout als Anwendungsrahmen besonders wichtig, um das Reporting
ansprechend und effizient zu gestalten. Eine geeignete Bedienoberfläche verhindert
Informationsüberflutung, Missverständnisse und Fehlinterpretationen97, siehe
Abbildung 19.
94 vgl. [Gluchowski, et al., 2008 S. 211 f.]
95 aus [Klein, 2012 S. 72]
96 vgl. [Klein, 2012 S. 72 ff.]
97 vgl. [Klein, 2012 S. 33 f.]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 37
Zeitraum Objekt Drucken
Ergebnisgrößen Einflussgrößen Weitere KPIs
Dar-
stellung 5
Dar-
stellung 1
Dar-
stellung 2
Dar-
stellung 3
Dar-
stellung 4
Funktionen
Rahmen
Darstellungs-
form
Anordnung
Abbildung 19: Beispiel-Layout einer Cockpitlösung98
Die Informationen sollten in einer Top-Down-Struktur angeordnet sein, also das
finale Ergebnis zuoberst. Hierfür wird empfohlen, die übliche wissenschaftliche
Vorgehensweise „Erst die detaillierte Herleitung und zuletzt das gefolgerte
Ergebnis.“ bewusst umzudrehen, siehe Abbildung 20.
Details
Kernaussage
Informationspyramide
Das Ergebnis ist im Fokus
Details
Kernaussage
Wissenschaftstrichter
Der Prozess ist im Fokus
Abbildung 20: „Wissenschaftstrichter“ vs. „Informationspyramide“99
Es sollten keine „Zahlenfriedhöfe“ entstehen, also eine zu große Menge und
Diversität an Kennzahlen, die kein Empfänger mehr durchschauen und
interpretieren kann. Stattdessen sollten die Informationen mithilfe von grafischen
Elementen und wenigen aber präzisen textuellen Aussagen (Botschaften) kompakt
vermittelt werden.
Für die Formulierung der Botschaften, den Kernaussagen zu Stand und Entwick-
lungen im Unternehmen, müssen zuvor die passenden Kernfragen der Empfänger
bzw. Nutzer bekannt sein. Damit ist gewährleistet, dass ein BI-System nur die
Fragen beantwortet, die ein Nutzer auch tatsächlich hat.
Ferner sollten die Botschaften „überschneidungsfrei und erschöpfend“ sein100. Das
trägt dazu bei, dass eine Kernfrage von genau einer Botschaft hinreichend
98 vgl. [Klein, 2012 S. 34]
99 vgl. [Klein, 2012 S. 74]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 38
beantwortet wird und der Nutzer nicht selber auf die „Suche nach der besten
Antwort“ gehen muss.
Schließlich ist in diesem Zusammenhang auch die zentrale Bedeutung der Drill-
Down-Funktionalität zu erwähnen. Sie ermöglicht es, dass jede Botschaft wiederum
durch zugrundeliegende Details (Teilbotschaften) erklärt und untermauert werden
kann. Die Drill-Down-Funktion bzw. das ihr zugrunde liegende Top-Down-Prinzip
bedient somit den Informationsbedarf der Nutzer in organischer Weise101, siehe
Abbildung 21.
Während die Umsätze bei Fertiggerichten über Vorjahr
liegen, verlieren die Molkereiprodukte deutlich.
Molkereiprodukte verlieren
12%, Frischprodukte leiden
am stärksten.
Fertigprodukte liegen in
beiden Produktlinien bis zu
9% über Vorjahr.
Frisch-
produkte
verlieren
14%.
Haltbare
Produkte
verlieren
11%
FIT-Line
dank
Werbung
9 % mehr
CLASSIC
gewann v.a.
im Inland 7% To
p-d
ow
n n
ach
Fra
ge:
Wa
rum
?
Abbildung 21: Beispiel für eine Top-Down-Struktur von Botschaft102
M-BID Relevanz R14:
Gestaltungsempfehlungen für das Reporting Vorgaben für die Konzeption der Web-
Oberflächen des M-BID.
Top-Down-Botschaften und zugehörige Kernfragen Eine Leitidee bei der IST-Analyse
zur Bestimmung der Kernfragen der Nutzer. Daraus kann dann der Kennzahlenbedarf (s.u.)
ermittelt werden und schließlich das Layout im Web-Formular bzw. des BI-Portals (s.u.).
Mobile Reporting
Eine Grundvoraussetzung für den effektiven Einsatz von Reportingsystemen ist heut-
zutage eine von Zeit und Ort unabhängige Verfügbarkeit der Berichte bzw. der
entsprechenden Daten auf möglichst interaktiven Oberflächen.
Web-Technologien realisieren die Anforderung nach ständiger, plattformunabhängiger
und flexibler Verfügbarkeit aller relevanten Unternehmensdaten.103 Dabei leisten die
Web-Anwendungen in Internetbrowsern (wie Internet-Explorer und Firefox) den
entscheidenden Beitrag, da sie immer und überall (zumindest wo es eine
Internetverbindung gibt) lauffähig sind. Die Browser realisieren bereits die
Plattformunabhängigkeit bezüglich Betriebssystem und Netzverbindung, da sie von
100 vgl. [Klein, 2012 S. 74]
101 vgl. [Klein, 2012 S. 36]
102 vgl. [Klein, 2012 S. 75]
103 vgl. [Klein, 2012 S. 25, 26, 36 ]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 39
den Herstellern (wie Microsoft und Mozilla) entsprechend vorgesehen und umgesetzt
ist.104
Besonders kommt den Web-Technologien in diesem Kontext zugute, dass sie von
Beginn an für eine hohe Interaktivität und eine optisch ansprechende Gestaltung
entwickelt wurden. Damit eigenen sie sich besonders für das „Mobile Reporting“ oder
„Web-Reporting“, was zu einem verstärkten Einsatz auch im Bereich „BI-Portale“
führte105, s.u.
M-BID Relevanz R15:
Mobile Reporting Muss-Anforderung an das System bei Konzeption und Umsetzung
Plattform Internet-Browser Für die Realisierung zu berücksichtigen
Kennzahlen
Kennzahlen messen unternehmensrelevante Tatbestände, um an ihnen den
momentanen Zustand und die Entwicklung des Unternehmens abzulesen, zu
beurteilen und in Form von Maßnahmen zu verbessern.106
Dazu werden i.d.R. numerische Werte erfasst und erzeugt, die eine möglichst präzise
Aussage über einen Tatbestand zulassen.
Es werden je nach Situation und Bedarf verschiedene Arten von Kennzahlen
eingesetzt: 107
Absolute (originäre) Kennzahlen sind Werte, die meist direkt aus den operativen
Systemen stammen und für sich alleine stehend eine absolute Aussage machen,
z.B. über die Absatzmenge (130 Stück) oder die Höhe des Umsatzes (1500 k€).
Absolute Kennzahlen sind aber nur in einem Kontext aussagekräftig, der entweder
in einem Diagramm dargestellt oder in Form von Verhältniskennzahlen hergestellt
wird.
Verhältniskennzahlen bzw. abgeleitete Kennzahlen sind Werte, die entstehen,
wenn zwei (selten mehrere) originäre Kennzahlen in Beziehung gesetzt werden.
Dabei liefern die verschiedenen Beziehungen folgende Arten von Kennzahlen:
o Gliederungskennzahlen stellen Gesamtgrößen zu gleichartigen Teilgrößen dar
und werden meist in Prozent angegeben, z.B. der Umsatz des Projektes X am
Gesamtumsatz beträgt 25 %.
o Beziehungskennzahlen stellen eine sinnvolle Relation von zwei andersartigen
Größen in Beziehung, z.B. der Umsatz pro Kunde beträgt 5 k€.
104 vgl. [Gluchowski, et al., 2008 S. 217]
105 vgl. [Gluchowski, et al., 2008 S. 214]
106 vgl. [Probst, 2012 S. 14, 22]
107 vgl. [Totok, 2000 S. 118 f.] und [Probst, 2012 S. 12 f.]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 40
o Messkennzahlen zeigt die relative Änderung im zeitlichen Verlauf gegenüber
einem Grundwert, z.B. die Erhöhung des Umsatzes um 150 k€ gegenüber dem
Vorjahreswert ist eine Steigerung um 10%.
Kennzahlen sind die maßgebenden Kontroll- und Steuerungsinstrumente in einem
Unternehmen und sind deshalb auch der Dreh- und Angelpunkt eines BI-Systems.
Sie zeigen nicht nur auf, wie es dem Unternehmen gerade geht, sondern mithilfe von
Kennzahlen können Ziele definiert werden, z.B. die Steigerung des Marktanteils von
9% auf 15% in den nächsten drei Jahren. Aufgrund dieser Zielvorgabe können nun
konkrete Maßnahmen zur Erreichen des Ziels erdacht und umgesetzt werden. Damit
wird auch deutlich, dass Kennzahlen nicht nur informieren, sondern auch durch die
Zielvereinbarungen motivieren. Sie tragen also in hohem Maße dazu bei, dass
Unternehmensstrategien operationalisiert und umgesetzt werden können.108
Harte und weiche Kennzahlen
Eine zentrale Aufgabe im Unternehmen ist das Ermitteln von geeigneten Kennzahlen.
Relativ unproblematisch ist das bei finanziellen Tatbeständen möglich, also bei allem,
was man abzählen und in Form von Geldwert darstellen kann.109
Diese sogenannten „Hard Facts“ und deren Kennzahlen werden auch KPI‘s (Key
Performance Indicator) genannt und nehmen im Reporting eine zentrale Rolle ein.
Aber auch weniger fassbare Tatbestände, wie z.B. optimale Prozesse oder ein gutes
Betriebsklima sind als Voraussetzung für die Leistungserbringung und den Ertrag
immanent wichtig. Seit den 1990er Jahren versucht man deshalb auch die „Soft Facts“
systematisch in die Betrachtung einzubeziehen.
Das Problem ist jedoch, dass die Faktoren nicht so leicht operationalisierbar, also
messbar und überprüfbar sind.
Mit verschiedenen Ansätzen wird versucht, das Problem zu lösen, indem man aus den
„weichen“ Tatbeständen möglichst „harte“ Kennzahlen gewinnt, z.B. in Form von
Beurteilungen und Punktevergabe.
Die bekanntesten Ansätze hierzu sind:110
Balanced Scorecard (BSC) wurde 1992 von R.S. Kaplan und D.P. Norton
entwickelt und erlaubt einen Blick auf das Unternehmen aus vier Perspektiven mit
den zugehörigen Fragestellungen:
108 vgl. [Probst, 2012 S. 14]
109 vgl. [Probst, 2012 S. 22]
110 vgl. [Kemper, et al., 2010 S. 131-141], [Probst, 2012 S. 233-242]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 41
o Finanziell: Wie sehen uns die Anteilseigner?
o Interne Prozesse: Wie können wir unserer Prozesse optimieren? Wo wollen wir
die Besten sein?
o Lernen und Entwicklung: Wie können wir unsere Potentiale fördern?
o Kunden: Wie sehen uns unsere Kunden?
Zu jeder Perspektive werden Ziele, Strategien und Maßnahmen formuliert. Jedes
Ziel erhält mindestens eine Kennzahl, die den Erfolg der Strategie bzw. der
Maßnahmen messbar macht. Schließlich wird definiert bei welchem Wert der
Kennzahl das Ziel erreicht wird. Somit kann der Fortschritt in Richtung der Ziele
bewertet (deshalb der Begriff Scorecard) und im Bedarfsfall im Sinne aller
Perspektiven (deshalb der Begriff Balanced) eingelenkt werden; siehe Abbildung 53
im Anhang 4.
Werteorientiertes Management (VBM = Value Based Management) soll die
Perspektiven „Unternehmenssicht“ und „Kapitalmarktsicht“ zusammenführen.111
Dabei wird auf den Unternehmenswert aus Sicht der Anteilseigner geschaut, dem
„Shareholder Value“. Alle Tatbestände und Faktoren, die am Ende dem
Unternehmenswert direkt oder indirekt zutragen, werden operationalisiert und
kontrolliert. Damit wird sichergestellt, dass der Unternehmenswert nicht nur von den
finanziellen Aspekten (Hard Facts) sondern auch von den unternehmens-
immanenten Aspekten (Soft Facts) abhängt. Ferner gibt es unterschiedliche Werte-
treiber. Solche, die durch das Unternehmen selber beeinflussbar sind, und solche,
die generisch von außen beeinflusst werden; siehe Abbildung 54 im Anhang 4.
M-BID Relevanz R16:
Kennzahlen messen unternehmensrelevante Tatbestände In der IST-Analyse sind die
relevanten Tatbestände und deren Kennzahlen zu identifizieren.
Arten von Kennzahlen Je nach identifiziertem Tatbestand wird eine bestimmte
Kennzahlenart benötigt, was dann Einfluss auf die Gestaltung der ETL-Prozesse hat.
BSC und VBM Als Ausprägungen der konzeptorientierten Systeme (siehe Kapitel 2.3.1)
nicht direkt relevant. Es geht aber als Anforderung ins M-BID ein, dass neben den
Hardfacts auch die Softfacts zu betrachten sind.
Kennzahlenauswahl für das BI-System
Um die relevanten Kennzahlen in einem BI-System verfügbar zu machen, müssen sie
zunächst konkret im Unternehmen ausgesucht, klar definiert und mit allen verabredet
werden. Dazu muss eine IST-Analyse die kritischen Erfolgsfaktoren und den
entsprechenden Kennzahlenbedarf für die Bereiche ermitteln, für die das BI-System
erstellt wird.
111 vgl. [Kemper, et al., 2010 S. 139]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 42
Die dazu notwendigen Aktivitäten sind: 112
Tätigkeitsanalyse durchführen
Unternehmens- und Systemlandschaft analysieren
Kritische Erfolgsfaktoren und die zugehörigen Kernfragen (s.o.) ermitteln
Zugehörige Kennzahlen und deren Kernaussagen (Botschaften) in einem
Erfassungsbogen dokumentieren. Insbesondere werden auch die Kennzahlen
erfasst, die zwar im Unternehmen gebraucht, aber derzeit nicht oder nur
umständlich zu Verfügung stehen.
Informationen über die Kennzahl-Dimensionen (siehe Abbildung 13 in Kapitel 2.3.2)
ermitteln.
Informationen für den ETL-Prozess sammeln. Insbesondere die Aggregationen bzw.
Verdichtungswege der Kennzahlen und deren Formeln sind zu ermitteln (siehe
Kapitel 2.2.2).
Informationen für das semantische Modell (siehe Kapitel 2.2.3) sammeln.
M-BID Relevanz R17:
Aktivitäten der Kennzahlenauswahl Werden im Rahmen der IST-Analyse durchgeführt
und liefern die notwendigen Angaben über die Kennzahlen bzw. Geschäftsobjekte für die
Konzeption.
Dashboard, Management-Cockpit und BI-Portal
Während es bei den Reportingsystemen v.a. um das Ergebnis nämlich den Bericht
geht, sind die Management-Systeme auf die kompakte und übersichtliche
Visualisierung von Informationen auf interaktiven Oberflächen ausgelegt.113
Senden Drucken Einstellungen SupportGlossar SucheBI-PortalAnmelden
News
Wissen
Management- Cockpit
Projekte-Dashboard
Bilanzen-Dashboard
Markt-Dashboard
Mitarbeiter-Dashboard
20%
20%
20%20%
20%
63 54 15
12
34
5
Abbildung 22: Beispielaufbau für ein BI-Portal114
112 vgl. [Totok, 2000 S. 117 ff.] , [Probst, 2012 S. 21 ff.] und [Feyhl, 2004 S. 33]
113 vgl. [Gluchowski, et al., 2008 S. 214 f.]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 43
Wie die Grenzen zu den Reportingsystemen, so sind auch die Grenzen innerhalb
dieser Anwendungsklasse bezüglich Zweck, Reichweite, Form, Distribution usw. nicht
trennscharf. Deshalb werden in der Literatur die entsprechenden Begriffe meist frei und
synonym verwendet. Im Folgenden wird versucht, die gebräuchlichen Begriffe zu
sortieren und den Ergebnissen zuzuordnen, die für den Nutzer sichtbar sind.
In der Abbildung 22 ist folgende Struktur zu erkennen: 115
Das BI-Portal ist das gesamte Anwendungsszenarium. Es ist den Internet-Portalen
von größeren Unternehmen und Organisationen (z.B. Branchenportale)
nachempfunden und wird i.d.R. mit Web-Technologien realisiert. Innerhalb des BI-
Portals befinden sich typische Elemente eines Web-Portals wie Suchfelder und
News-Ticker, aber auch die BI-spezifischen Elemente.
Das Management-Cockpit ist die Zusammenfassung der BI-spezifischen
Elemente, die im Beispiel aus vier Bereichen (Anzeigetafeln) bestehen. Das
Management-Cockpit ist sozusagen die „Pilotenkanzel“ mit den dazu notwenigen
Anzeigen und Funktionen.
Ein Dashboard zeigt einen unternehmensrelevanten „Betriebszustand“ an und ist
im Sinne einer Anzeigetafel (bzw. einer Armatur in einem Cockpit) ein Bereich, der
grafisch und textuell Informationen einer fachlichen Ausrichtung präsentiert116. Im
Beispiel sind das die Monitore für Projekte, Marktanteile, Bilanzwerte und
Mitarbeiterstatus.
Die Dashboards können je nach Zweck und Reichweite sehr unterschiedlich
ausgestattet sein. Meist werden die Kennzahlen und Informationen visuell
dargeboten mittels geeigneter Geschäftsgrafiken (z.B. Linien-, Balken-, und
Kuchendiagramme) sowie typischen Dashboard-Elementen (z.B. Tachometer,
Temperatur- und Füllstand-Anzeigen).117
Zur weiteren Analyse der Kennzahlen werden in den Dashboards Funktionen zur
Verfügung gestellt, die für den Nutzer jeweils nützliche Dienste darstellen.
Es können ferner strukturierte und unstrukturierte Informationen unterschieden
werden. Strukturierte Informationen werden insbesondere in den Dashboards
angezeigt. Unstrukturierte Informationen sind hauptsächlich in den Web-Portal-
typischen Elementen zu finden, wobei die Inhalte z.B. des News-Tickers oder der
Wissensbasis (Knowledge-Base) aus dem Unternehmen selbst stammen. Im Sinne
114 eigener Entwurf in Anlehnung an [Klein, 2012 S. 98], [Kemper, et al., 2010 S. 130] und
[Gluchowski, et al., 2008 S. 217]
115 vgl. [Gluchowski, et al., 2008 S. 214-221], [Kemper, et al., 2010 S. 129 f.] und [Klein, 2012 S. 93-104]
116 Diese Definition ist nicht einheitlich in der Literatur zu finden. Sie ist eher die zusammenfassende
Folgerung aus den betrachteten Beispielen.
117 vgl. [Probst, 2012 S. 219-232] und [Gluchowski, et al., 2008 S. 215]
2.3 Analyse und Darstellung der Daten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 44
eines unternehmensweiten Wissensmanagements kommen sie hier nutzbringend
zum Einsatz.
Interne und externe Suchdienste (wie Google) finden zusätzliche
Informationsquellen.
Im BI-Portal wird noch eine Reihe von Funktionen bereitgestellt, wie z.B. das
Drucken und Versenden von Berichten, die aus den präsentierten Informationen
generiert und exportiert werden.
Hilfsfunktionen, wie z.B. die Weiterleitung zum technischen Support oder das
Aufschalten eines Glossars für Fachbegriffe, tragen zur optimierten Anwendbarkeit
(Usability) des BI-Systems bei.
Bei den „Einstellungen“ befinden sich i.d.R. Nutzer-abhängige Optionen wie z.B.
Anpassungen bezüglich Anzeige, Auswertung, Datenquelle und Datenexport. Ist der
Nutzer ein Administrator oder ein sogenannter „Power-User“118 so stehen ihm z.T.
umfangreiche Optionen für die Systemkonfiguration sowie für die Rechte- Rollen-
und Regel-Verwaltung119 zur Auswahl.
Schließlich verbirgt sich hinter „Anmelden“ bzw. „Abmelden“ das für Portale typische
Prinzip „Einmal anmelden – alles nutzen“ (Single Sign On)120, wodurch der Zugriff
auf alle relevanten Informationen und Funktionen erleichtert wird und zudem in eine
einheitliche Rechteverwaltung eingebunden werden kann.
M-BID Relevanz R18:
Aufbau eines BI-Portals Die Strukturelemente (Portal, Cockpit, Dashboard) sind
Leitfaden bei der Konzeption des M-BID-Portals.
Bereitstellung nützlicher Dienste Sind in der IST-Analyse zu identifizieren
Strukturierte und unstrukturierte Informationen/Daten Beide Aspekte werden untersucht
und konzeptuell berücksichtigt.
Knowledge-Base und Suchdienste Werden konzeptuell im M-BID-Portal berücksichtigt.
Drucken, Exportieren und Versenden Sind wichtige Anforderung im M-BID-Portal
Administrator bzw. Power-User Geht mit ins Konzept für die Systempflege und
Weiterentwicklung ein.
Usability des BI-Portals Wichtiger Leitfaden für die Funktions- und Oberflächen-
gestaltung des M-BID.
118 vgl. [Gansor, et al., 2010 S. 286] und [Bachmann, et al., 2011 S. 215]
119 vgl. [Fiedler, 2010 S. 74]
120 vgl. [Gluchowski, et al., 2008 S. 216]
3.1 Kriterien für die Untersuchung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 45
3 IST-Analyse
3.1 Kriterien für die Untersuchung
Ziel der folgenden Untersuchung ist das Sammeln von konkreten und praxisrelevanten
Anforderungen an das M-BID-System, die den in Kapitel 1.2 formulierten Zielen zur
Umsetzung verhelfen.
Dazu werden mithilfe der Business-Analyse zunächst die organisatorischen,
strukturellen und prozessualen Tatbestände bzw. Geschäftsanforderungen identifiziert,
um daraus ein Lösungskonzept ableiten zu können.121
Die in Kapitel 1.2 formulierten Ziele sowie die technologischen Grundlagen in Kapitel 2
stellen dabei einen Untersuchungsrahmen dar, der die Anforderungen in fachlicher,
organisatorischer und technologischer Hinsicht zusammenhält. Insbesondere werden
dazu die Informationen aus den Feldern „M-BID Relevanz“ herangezogen.
Es geht in der IST-Analyse v.a. um die Beantwortung der folgenden Fragen:
Wem soll das M-BID helfen und wobei?
Was genau soll das M-BID leisten?
In welche Unternehmens- und Systemlandschaft wird das M-BID implementiert?
Was sind die Aufgaben und Tätigkeiten der Nutzer, die unterstützt werden sollen?
Wo sind ggf. Schwachstellen und Optimierungsbedarf in den Strukturen oder
Prozessen?
Welchen Fragen (Kernfragen) stellen sich den Nutzern bei Ihren Aufgaben und
welchen Informationsbedarf haben sie, um die Fragen zu beantworten?
Welche Kennzahlen und Botschaften (Kapitel 2.3.3) gibt es, die den
Informationsbedarf decken, und welche werden zusätzlich benötigt?
Welche Eigenschaften haben diese Kennzahlen?
Welche Dimensionen, Dimensionsstufen, Dimensionsstufenelemente, Granularität
und Aggregationen (Kapitel 2.2.3 und 2.3.2) haben die Kennzahlen?
Zur Beantwortung der Fragen dient das „Expertengespräch“, wobei insbesondere auf
die Kenntnisse und Erfahrung der Mitarbeiter aus der SWE-Abteilung zurückgegriffen
wird. Sie sind sowohl „betroffene“ Anwender als auch Informatiker, und vereinen damit
die beiden typischen Sichtweisen auf eine IT-technisch umzusetzende Geschäfts-
anforderung. Dieser Umstand ist natürlich nicht der Regelfall, aber bei der Realisierung
121 vgl. [Hanschke, et al., 2013 S. 8]
3.1 Kriterien für die Untersuchung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 46
des M-BID sehr nützlich. Schließlich werden die Controlling-spezifischen Aspekte mit
den jeweiligen Fachleuten aus den Bereichen konsolidiert.
Bei der Business-Analyse werden die Geschäftsanforderungen möglichst formal
dokumentiert. Neben grafischen Darstellungen werden auch Anforderungslisten
erstellt. Dabei sollten die Anforderungen wie folgt formuliert sein:122
vollständig und explizit: Ganz beschrieben und ohne implizite Annahmen
spezifisch, eindeutig und abgegrenzt: Beschreibung muss „passen“
verständlich und nachvollziehbar: Keine „Geheimsprache“ benutzen
einheitlich dokumentiert: Z.B. in Listen mit definierten Feldern und Nummern
Im Sinne des zuletzt genannten Aspektes werden in der Untersuchung
Anforderungstags [A1: ] bis [An: ] vergeben, die dann in Form einer Anforderungsliste in
Kapitel 3.3 ausgewertet werden. In einem Anforderungstag steht zudem eine
Kurzbeschreibung und das in Kapitel 2 zugehörige M-BID-Relevanz-Feld:
[Ax: Kurzbeschreibung: Ry]
Um sicherzustellen, dass nur relevante Anforderungen betrachtet werden, sollte man
sich fragen: Sind die Anforderungen…
nützlich - wem oder was dienen sie?
notwendig - geht es nicht auch ohne oder anders?
machbar - ist die Umsetzung realistisch erreichbar?
messbar - ist die Umsetzung/Erfüllung zum Schluss überprüfbar?
priorisiert - wie wichtig ist es?
terminiert - wann kommt es zur Umsetzung?
Die vorstehenden Fragen können als eine Art „Sieb“ genutzt werden, um aus einer
Vielzahl von Möglichkeiten eine beherrschbare Anzahl und Komplexität von relevanten
Anforderungen für die erste Umsetzungsstufe des M-BID zu extrahieren.
Damit die Detaillierungsebene der Anforderung erkennbar ist, wird eine der folgenden
Kategorien in der o.g. Anforderungsliste vergeben:
Hauptanforderung - auf Ebene eines Fachvorgangs wie „Controlling via Budget“
Grobanforderung - auf Ebene einer komplexen Tätigkeit wie „Budget planen“
Teilanforderung - auf Ebene einer Teiltätigkeit wie „Budget vom Vorjahr sichten“
Funktionsanforderung - auf Ebene einer Software-Oberflächenfunktion wie „Budget
anzeigen“
Teilfunktionsanforderung – auf Ebene einer Softwareroutine wie „Anzeigerahmen für
das Budget generieren“
122 vgl. [Hanschke, et al., 2013 S. 56, 248 f.] und [Wikipedia, 2013 a]
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 47
3.2 Untersuchung der aktuellen Situation
3.2.1 Betriebsumgebung - Organisatorischer Rahmen
Die IVV - Ingenieursgesellschaft für Verkehrsplanung und Verkehrssicherung GmbH -
ist ein mittelständiges Unternehmen mit rund 100 Mitarbeitern an sechs Standorten in
Deutschland. Das Unternehmen ist eingebunden in den weltweit operierenden Konzern
PB - Parsons Brinckerhoff Company, der u.a. im Bereich „Rail Infrastructure“ tätig ist.
Die IVV ist seit 33 Jahren ein Ingenieurbüro für Planungs- und Beratungsleistungen im
Verkehrswesen mit dem Schwerpunkt „Schienenverkehr und Bahnanlagen“. Zur
Unterstützung der Planungs- und Entwurfsprozesse von Bahnanlagen entwickelt die
IVV seit Mitte der 1980er Jahre das Softwaresystem ProSig mit derzeit 10 Entwicklern.
ProSig ist ein CAD-basiertes Werkzeug, das 1998 den Status einer Standardsoftware
bei der Deutschen Bahn AG erhalten hat.123
Seitdem wird ProSig zu einem Expertensystem in der Leit-und Sicherungstechnik
(LST) ausgebaut. Insbesondere die Planung von elektronischen Stellwerken ist eine
komplexe und verantwortungsvolle Ingenieursleistung, deren Unterstützung ebenso
komplexe Anforderungen an das Softwaresystem stellt.124
Geschäftsführung
IVV
Profitcenter
Controlling /
Buchhaltung
Vertrieb /
Marketing
Personal (HR)
IT
4 Regionalbereiche
Planung
Softwareentwicklung
ProSig
Projekte und
Gewerke
Projektsteuerung /
Entwicklungscontrolling
Support / Schulung
Softwareentwicklung
Test / Dokumentation
Vertriebsunterstützung
Abbildung 23: Unternehmensstruktur IVV125
Um diesen Anforderungen jetzt und in Zukunft gerecht zu werden, bedarf es
sorgfältiger Planung und Realisierung umfangreicher Projekte in der Software-
entwicklung. Diese gilt es mit dem BI-System M-BID zu unterstützten, siehe Ziele in
Kapitel 1.2.
123 siehe [IVV - ProSig, 2013]
124 siehe [Maschek, 2001 S. 5 ff.] und [Maschek, et al., 2012 S. 22 ff.]
125 eigener Entwurf in Anlehnung an das Organigramm der IVV.
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 48
Die Abbildung 23 zeigt einen Überblick über die IVV mit seinen Leistungsbereichen.
Der Betrachtungsbereich der folgenden Untersuchung ist das Profitcenter
„Softwareentwicklung“ (SWE); darunter speziell der Bereich „Projektsteuerung und
Entwicklungscontrolling“ sowie sein Zusammenspiel mit den Bereichen „Geschäfts-
führung und Controlling“ (siehe rote Felder). [A1: M-BID ist bereichsübergreifendes System: R1]
3.2.2 Systemlandschaft - Struktureller Rahmen
Das zentrale System im Unternehmensumfeld ist ein ERP-System der Firma SAP. Hier
werden alle Leistungsbereiche mit ihren Mitarbeitern, Kostenstellen und Projekten
betriebswirtschaftlich erfasst. Insbesondere die Zahlen aus der Kosten- und
Leistungsrechnung sowie aus der Gewinn- und Verlustrechnung werden dort erfasst.
Ferner werden in das SAP wöchentlich die Projektstunden der Mitarbeiter eingetragen.
Mit den Monatsabschlüssen werden alle betriebswirtschaftlichen Kennzahlen auf einen
neuen Stand gebracht. [A10: SAP ist eine Quelle vom M-BID-System: R2,5,7,8] [A2: Granularität der
Dimension Zeit ist der Monat: R8,12]
Projektstands-
meldung
Projekt-
kalkulation
Vorschau
AE/UMS
Projekt-
übersicht
Budget-
planung
Projektdatei
Geschäftsführung
Controlling
Softwareentwicklung ProSig
Entwicklungs-
planung
Kapazitäten
-planung
Kurzinformationen
Führung
AE_HK
Weitere Systeme
und Dokumente Projekt-
fortschritt
PRSSAP
Profitcenter
Kostenstellen
Projekte
Mitarbeiter
Projektstunden
Projekte
Mitarbeiter
Vorgänge
ToDo’s
Kunden
Lizenzen
Versionen
Testläufe
Abbildung 24: System und Dokumente im Betrachtungsbereich
Neben dem SAP gibt es eine Reihe von Dokumenten, die zum Reporting und
Austausch von Kennzahlen in diversen Reviews und Meetings dient. Einige Excel-
Tabellen davon sind notwendig, weil das SAP derzeit nur eingeschränkt für die
Planung der Kennzahlen eingesetzt wird.
[A3: Reporting realisieren: R13] [A4: M-BID auch für Plan-Kennzahlen: R12]
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 49
Neben den in Abbildung 24 dargestellten Systemen und Dokumenten gibt es noch
einige mehr, die in anderen Kontexten und zur Unterstützung der Leistungsprozesse
im Unternehmen eingesetzt werden, das sind insbesondere:
Diverse Spezialsysteme zur Leistungserstellung, insbesondere CAD-Systeme.
MS-Outlook als Email-Manager für die interne und externe Korrespondenz und
Kommunikation. [A5: Reports via MS-Outlook versenden: R18]
Weitere MS-Office-Produkte (v.a. Excel) für das Herstellen diverser Dokumente. [A6:
Daten in MS-Excel-Tabellen exportieren: R18]
Ein auf MS-Excel basiertes Informationsmanagementsystem (IMS), das
Informationen, Richtlinien, Prozessbeschreibungen und Dokumentenvorlagen allen
Mitarbeitern des Unternehmens zur Verfügung stellt . [A7: Link zum IMS ins M-BID-Portal:
R18]
Ordnerstruktur für das Ablegen der jeweiligen Dateien in den Projekten und
Abteilungen. [A8: Link auf Ordnerstruktur für Zugriff auf unstrukturierte Daten: R18]
Ein Konzern-Intranet der PB Company als globale Kommunikationsplattform und
entsprechendes IMS. [A9: Link vom M-BID-Portal zum PB-Intranet: R18]
Für den speziellen Bereich der Softwareentwicklung (SWE), haben sich zusätzliche
Systeme und Dokumente etabliert.
Im Zentrum steht hier das auf MS-Access selbstentwickelte „Project Ressource
System“ (PRS) mit seinen zahlreichen Tabellen für Stamm- und Verlaufsdaten. [A11:
PRS ist eine Quelle vom M-BID-System: R2,5,7,8]
Die Mitarbeiter der SWE greifen auf weitere spezielle Systeme und Dokumente zurück:
MS-Visual-Studio und AutoCAD der Firma AutoDesk als Entwicklungsumgebung.
[A12: Aufruf/Anzeige von M-BID-Funktionalität aus der Entwicklungsumgebung: R1]
SVN Filemanagementsystem für die Versionsverwaltung der Entwicklungs- und
Unterstützungsdokumente in der SWE.
Die in Abbildung 24 dargestellten Systeme und Dokumente werden noch in der
Konzeption (Kapitel 4) näher betrachtet. Allgemein kann festgehalten werden, dass die
Dokumente größtenteils separat und manuell hergestellt werden. [A13: Alle Daten für die
Tabellen/Reports kommen aus dem M-BID: R2,6] [A6: Daten in MS-Excel-Tabellen exportieren: R18]
Ferner ist aus der Abbildung 24 erkennbar, dass die Systeme und Dokumente einen
verschiedenen Fokus im Unternehmen haben. Der unterscheidet sich darin, wer das
Dokument erstellen, bearbeiten, lesen und ggf. löschen darf. [A14: Management der
Zugriffsrechte realisieren: R10]
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 50
3.2.3 Tätigkeiten - Prozessualer Rahmen
Innerhalb der vorliegenden Arbeit wird die Haupttätigkeit „Monatliches Projekt-Review“
genauer untersucht, da sie die Anforderungen an eine erste Umsetzungsstufe des M-
BID exemplarisch herausstellt, insbesondere an das Framework und das
Anwendungsbeispiel. [A15: M-BID-Dienst für monatliches Projekt-Review realisieren: R6,18]
Der Prozess wird im Folgenden textuell im Top-Down-Schema detailliert:
Monatliches Projekt-Review (Entwicklungsleiter, Projektleiter, Entwickler)
[A16: Verschiedene Rollen im M-BID berücksichtigen: R 10,18]
o Projekte sichten und bewerten [A23: Überblick über die Projekte ermöglichen: R14,18]
Projekt auswählen [A17: Navigation in den Projekten ermöglichen: R14,18]
Projektkennzahlen und zugehörige Informationen anzeigen lassen [A18: Projekt-
Cockpit mit Dashboards realisieren: R16,18] [A29: Link auf Projektdateien zur Verfügung
stellen: R18]
Herstellungskosten (HK) werden als Ist, Soll/kalkuliert, abgerechnet,
prognostiziert (bis Projektende und bis Jahresende) betrachtet
[A19:Dashboard für Herstellungskosten-Ist realisieren: R13,14,18] [A20: Verschiede
Szenarien der Kennzahlen vorsehen: R8,12]
Entsprechende Projektstunden betrachten [A21:Dashboard für Projektstunden-Ist
realisieren: R13,14,18]
HK detailliert betrachten u.a. Reisekosten und Externe Leistungen [A22:
Dashboard für HK-Details realisieren: R14,18]
Umsätze (UM) aus Abrechnungen sowie Auftragseingänge (AE) aus
Nachträgen sowie die zugehörigen HK im Ist und im zeitlichen Verlauf
ansehen (Zeitreihenvergleich) [A24: Dashboard für UM,AE,HK in Zeitreihen
realisieren: R14,18]
Projektfortschritt ansehen: In % und absolute Werte für Vorgänge und
ToDos. Die Werte wurden zuvor u.a. bei den Teambesprechungen ins PRS
eingetragen. [A25: Dashboard für Projektfortschritt-Ist realisieren: R13,14,18]
Projektprognose: Das Projekt bezüglich der notwendigen Projektstunden und
Herstellkosten bewerten, ferner den sich daraus ergebende zeitliche Verlauf
des Projektes. [A26: Dashboard für Projektprognose realisieren: R1,13,14,18]
Wichtige Aspekte und Bewertungen protokollieren [A27: Projekt-Botschaften
editieren: R14]
o Ggf. operative Maßnahmen entwickeln und initiieren
Bei Überschreitung der Soll-Grenzen (zeitlich und/oder finanziell) müssen
Maßnahmen getroffen werden, z.B.
Rechnung legen
Entweder Projektverlängerung beantragen
oder Ressourcen umverteilen
oder Nachtrag mit Auftraggeber (AG) verhandeln
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 51
oder Leistungen in Absprache mit dem AG kürzen
Die Maßnahmen schriftlich festhalten [A28: Dashboard für Maßnahmen realisieren:
R1,13,14,18]
Sonstige Vorkommnisse aus den Projekten betrachten, z.B. Kundenanfragen
[A29: Link auf Projektdateien zur Verfügung stellen: R18]
Projekt schließen und nächstes Projekt [A17: M-BID-Dienst-Funktionen zur Navigation
in den Projekt: R14,18]
o Das Gesamtergebnis des Projektreviews in Stichpunkten festhalten [A30:
Profitcenter-Botschaften editieren: R14]
Eine weitere Haupttätigkeit, die in den Zielen in Kapitel 1.2 genannt wird, ist das
„Quartalsweise Profitcenter-Review“.
Dieser Prozess wird nicht genauer betrachtet, da er nur wenig neue Anforderungen an
das M-BID in der ersten Ausbaustufe generiert. Er impliziert v.a. den Prozess
„Monatliches Projekt-Review“ mehrfach und sieht im Wesentlichen so aus:
Quartalsweises Profitcenter-Review (Geschäftsführer, Kaufmännischer Leiter,
Entwicklungsleiter, Controller)
o Als Vorbereitung Projektreviews durchführen (dreimal pro Quartal), s.o.
o Projekte sichten (in aggregierter/verdichteter Form)
o Gesamtergebnis des Profitcenters (aktuell und im zeitlichen Verlauf) betrachten
o Ergebnis in Form eines Forecast bewerten
o Im 3. Review auch Budgetierung durchführen (separater Prozess)
o Kostenstellenrelevante Zahlen (u.a. Über- und Unterdeckung) betrachten
o Sonstige Vorkommnisse aus dem Profitcenter betrachten, z.B. Mitarbeiterthemen
Auch wenn sich die Ausprägung und Reichweite der Aktivitäten unterscheiden, so ist
das Profitcenter-Review in Bezug auf die betrachteten Kennzahlen im Wesentlichen
eine höhere „Umlaufbahn“ zum Projektreview. [A30: Verdichtung der Kennzahlen auf Quartals-
und Jahressummen: R7]
3.2.4 Kennzahlenbedarf
Folgende zentrale Kennzahlen sind aus der Untersuchung der Tätigkeiten
hervorgegangen und werden im weiteren Verlauf der Arbeit genauer betrachtet:
Umsatz (UM)
Auftragseingang (AE)
Herstellkosten (HK) nebst zugehöriger Projektstunden (STD)
Projektfortschritt (PRJ_PROGRESS)
[A35: Verschiedene Kennzahlen/Cubes ermöglichen: R6,8,12,13]
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 52
Diese Kennzahlen kommen in den Szenarien vor:
IST: Der aktuelle Wert
SOLL: Der vorgegebene bzw. kalkulierten Wert
PROGN: Der prognostizierte Wert
DIF: Die Abweichung bzw. Differenz von IST zu SOLL oder PROGN
[A20: Verschiede Szenarien der Kennzahlen vorsehen: R8,12]
Ferner kommen folgende Ausprägungen bzw. Varianten vor:
AB_IST: Der angerechnete Wert; ist für die HK relevant, HK_AB.
END: Der prognostizierte Wert bis Projektende; kommt derzeit nur für die HK vor,
HK_PROGN_END.
GJ: Der prognostizierte Wert bis Geschäftsjahresende; kommt derzeit nur für die HK
vor, HK_PROGN_GJ.
[A32: Verschiedene Ausprägungen der Kennzahlen vorsehen: R8,12]
Schließlich sind die Aggregationen bei den Betrachtungen entscheidend:
Bei der Betrachtung von HK-IST sind erst mal nur die kulminierten Werte (KULM)
seit Projektanfang interessant.
Bei den Zeitreihenvergleichen sind sowohl die Monatswerte als auch die bis dahin
kulminierten Werte interessant, z.B. HK im Februar 15 k€ , HK bis Februar 133 k€.
[A33: Aggregation der Kennzahlen realisieren: R2,6,7,8,12,17] [A34: Verschiedene Kennzahldimensionen vorsehen: R6,7,8,12,17]
Mit Hilfe der additiv aufgebauten Nomenklatur lassen sich für das Konzept und die
Umsetzung alle erforderlichen Kennzahlen systematisch benennen: Z.B. HK_AB_IST,
für die tatsächlich abgerechneten Herstellungskosten.
Datenherkunft
Die untersuchten Kennzahlen kommen aus den zwei o.g. Datenbanksystemen.
Aus dem SAP können die Daten derzeit nur über einen Export in eine MS-Excel-
Tabelle verfügbar gemacht werden, siehe Abbildung 25. [A36: Datenschnittstelle zu SAP
mittels Excel-Import, R1,5,6,7,8]
Auf die Daten im PRS kann mittels SQL-Anweisungen direkt zugegriffen werden. [A37 :
Datenschnittstelle zu PRS mittels SQL-Anweisungen, R1,5,6,7,8]
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 53
Abbildung 25: Quelle SAP - Ausschnitt MS-Excel-Tabelle des SAP-Exports
Abbildung 26: Quelle PRS - Ausschnitt MS-Access-Formular für Projektfortschritt
Kennzahlenerfassung
Um die Informationen zu den Kennzahlen gemäß Kapitel 2.3.3 (R17) systematisch zu
sammeln, wird üblicherweise ein Erfassungsbogen verwendet, der die Kennzahlen
definiert und ihre Eigenschaften für das BI-System spezifiziert.126
In Tabelle 1 sind die Erfassungsbögen der zentralen Kennzahlen aus der
Untersuchung als Liste abgebildet. Dabei wurden neben den momentan verwendeten
Kennzahlen (z.B. AE_IST) auch die künftigen Kennzahlen aufgenommen (z.B.
DIF_HK_IST_PROGN_END), die meist schon impliziert betrachtet wurden, jetzt aber
als explizite Soll-Anforderung aufgenommen sind. Ferner erhält jede Kennzahl eine
Anforderungsnummer und kann somit im Konzept systematisch berücksichtigt werden.
126 vgl. [Totok, 2000 S. 117 ff.]
3.2 Untersuchung der aktuellen Situation
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 54
Bezeichnung Umsatz Auftragseingang Herstellungskosten Projektfortschritt
Kürzel UM AE HK PROGRESS
Erfolgsfaktor Möglichst hoher Absatzwert der Leistungen und Produkte des Profitcenters SWE.
Möglichst hoher Auftragswert von Leistungen oder Produkten des Profitcenters SWE durch die Kunden.
Möglichst niedrige Aufwendungen für die Herstellung der Produkte oder Leistungen des Profitcenters SWE.
Der Projektfortschritt ist nach Maßgabe des Projektes und der verfügbaren Ressourcen so zu realisieren, dass zeitlich und inhaltlich eine optimale Liefertreue entsteht.
Kernfragen Was haben wir eingenommen bzw. erlöst?
Wodurch sind unsere Kosten gedeckt und wird unser Gewinn realisiert? Was werden wir künftig noch erlösen?
Was kostet die Leistungserstellung? Liegen die HK noch im erlaubten/prognostizierten Bereich?
Was haben wir schon geleistet und was nicht? Wie aufwendig wird das Projekt noch sein?
Beschreibung Umsatz wird erzielt durch den Verkauf von Programmier- und Consulting-leistungen sowie durch Verkauf und Vermietung von Software-Lizenzen.
AE entsteht durch Beauftragung von Programmier- und Consultingleistungen durch die Kunden. Ferner durch Bestellung oder Miete von Software-Lizenzen.
Die HK setzen sich zusammen aus den Fertigungs-, Material- und Sonderkosten. Sie entstehen durch Leistungen innerhalb von SWE-Projekten sowie durch Wartung und Weiterentwicklung der Software.
Der Projektfortschritt in der SWE ergibt sich aus der Betrachtung der Projektvorgänge und der zugehörigen ToDos. Der Projektfortschritt ist ein Schätzwert, der von den Projektleitern ins PRS eingetragen wird.
Einheit € € € %
Kennzahlart absolut, originär UM_IST
absolut, originär AE_IST
absolut (originär) HK_IST, HK_AB_IST, HK_AE_SOLL
Verhältniskennzahl bzw. Gliederungskennzahlen
Formel, Herleitung keine keine diverse, siehe Konzept Erbrachte Leistung zur geforderten Leistung
Datenherkunft SAP > Schnittstellen-xls > "Umsatz HGB"
SAP > Schnittstellen-xls > "** Summe AE-gesamt"
SAP > Schnittstellen-xls > "HK-Zugang"
PRS > Tabelle Projekte > PRJ_GESCHAFFT
Aktualisierung in Quelle
sofort nach Buchung sofort nach Buchung sofort nach Buchung sofort nach Änderung
Aktualisierung in M-BID
monatlich monatlich monatlich monatlich
Szenarien IST, SOLL (gemäß AE_IST)
IST, SOLL (gemäß Kalkulation)
IST, SOLL (gemäß Kalkulation), PROGN_END, PROGN_GJ, (AB_IST)
IST (SOLL = 100%)
Ausprägungen, Varianten
derzeit keine derzeit keine AB_IST, die abgerechneten HK
PRJ für Projektfortschritt CASE für Vorgangsfortschritt
Dimensionen Zeit, Projekt, Szenario
Zeit, Projekt, Szenario Zeit, Projekt, Szenario Projekt
Granularität in Quelle
1 Eurocent 1 Eurocent 1 Eurocent 1%
Granularität in M-BID
1 € (Anzeige: 1€, 1k€)
1 € (Anzeige: 1€, 1k€) 1 € (Anzeige: 1€, 1k€) 1%
Transformationen Aggregation durch Summen (KULM) Abweichungen durch Differenz (DIF)
Aggregation durch Summen (KULM) Abweichungen durch Differenz (DIF)
Aggregation durch Summen (KULM) Abweichungen durch Differenzen (DIF)
Aggregation ggf. durch Mittelwertbildung (geometrisches Mittel), ansonsten Top-Down der Schätzwerte
Aggregationen / Verdichtungswege
Monat > Quartal > Jahr ; Projekt XY > Alle Projekte
Monat > Quartal > Jahr ; Projekt XY > Alle Projekte
Monat > Quartal > Jahr ; Projekt XY > Alle Projekte
ToDo > Vorgang > (Meilenstein) > Projekt XY
Anforderung A42 A43 A44 A45
Tabelle 1: Erfassung der Kennzahlen mit Eigenschaften
3.3 Auswertung der Untersuchung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 55
3.3 Auswertung der Untersuchung
Die Untersuchungsauswertung dient der Vorbereitung der Konzeption bzw. ist schon
ein wichtiger Teil von ihr. Sie trägt die gesammelten Erkenntnisse und Anforderungen
zusammen und bringt sie in eine geeignete Struktur, um sie systematisch betrachten
und umsetzten zu können. Das geschieht typischerweise in Form einer
Anforderungsliste. Sie reichert die gesammelten Anforderungen um Strukturmerkmale
und weitere Details aus der Untersuchung an:
ID: Ist die Identifikationsnummer der Anforderung; sie zeigt keine Rangordnung oder
Reihenfolge an.
Beschreibung: Ein prägnanter Text gemäß den Kriterien aus Kapitel 3.1
Kategorie nach Kapitel 3.1: Hauptanforderung (HA), Grobanforderung (GA), Teilan-
forderung (TA), Funktionsanforderung (FA) und Teilfunktionsanforderung (TFA)
Ist Teil von: Zeigt an, welche größere Anforderung die aktuelle inkludiert.
Priorität: Gibt an, in welcher Ausbaustufe die Anforderung realisiert werden muss.
Relevanzfeld: Zeigt an, aus welchen Grundlagen in Kapitel 2 sich die
Anforderungen herleiten oder untermauern lassen.
Kernfragen: Eine zentrale Bedeutung für die Anforderungen haben die zugehörigen
Fragen, die der Nutzer beantwortet haben möchte.
Informationsbedarf / Aktionsbedarf: Zeigt, womit die Kernfragen grundsätzlich zu
klären sind bzw. was als Aktion des Nutzers darauf folgt.
Das Ergebnis der Untersuchung im gewählten Betrachtungsbereich (siehe Kapitel
3.2.1) wird in der folgenden Anforderungsliste zusammengestellt. Allerdings ist die
Tabelle 2 aus Platzgründen nur ein Auszug; die vollständige Liste befindet sich im
Anhang 5 in Tabelle 4.
ID Beschreibung Kate- gorie
ist Teil von
Prio. Relevanz-Feld Kernfrage des Nutzers
Informationsbedarf / Aktionsbedarf
A1 M-BID ist bereichsübergreifendes System
GA A14, 40
1 R1 Wer ist an den Informationen im M-BID interessiert?
Hinweise über Abteilungen und Rollen / Informationsaustausch
A2 Granularität der Dimension Zeit ist der Monat
TFA A34 1 R8, 12 Was ist feinste Ebene bezüglich der Zeit?
Hinweise über Dimensionen
… … … … … … … …
A44 Kennzahl HK TA A35 1 R8,16 s. Erfassungsbogen entspr. Kennzahl
A45 Kennzahl PRJ_PROGRESS
TA A35 1 R8,16 s. Erfassungsbogen entspr. Kennzahl
Tabelle 2: Auszug aus der Anforderungsliste für das M-BID
4.1 Konzeptionsziele
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 56
4 Konzeption des M-BID-Systems
4.1 Konzeptionsziele
Konzeptionsziele dienen der Orientierung bei der Konzepterstellung. Ferner lassen
sich die Inhalte nach der Umsetzung nochmals im Sinne einer „Abnahme“ überprüfen.
Neben der Formulierung der Wünsche in Form von Zielszenarien (Kapitel 1.2) ist die
Anforderungsliste in der SWE das genauste Maß für die Konzeption und die
Umsetzung. In der Praxis ist die Anforderungsliste der „Nukleus“, aus dem weitere
Darstellungen, Dokumente, Entwicklungsprozesse und Klärungen entstehen. Sie sollen
auch die „Richtschnur“ der vorliegenden Arbeit sein:
Sichtung der Untersuchungsergebnisse, insbesondere die Anforderungsliste in
Tabelle 2, Kapital 3.3 und ihre Detailierung bezüglich der Kennzahlen in Tabelle 1,
Kapitel 3.2.4.
Besprechung der Anforderungen mit den Nutzern und Entwicklern. Im
vorliegenden Fall sind die Rollen in „Personalunion“ besetzt, da die SWE-Abteilung
sich das M-BID-System selber realisiert. Dennoch ist es sinnvoll, diese beiden
Perspektiven einzunehmen und sie auch, wo es wichtig ist, auseinanderzuhalten.
Erstellen von Konzeptionsdokumenten127 zu Aufgaben, Strukturen und
Prozessen:
o Prozesslandkarte zeigt die bisherigen und neuen Prozesse
o Prozessablauf-Diagramm zeigt die Prozesse detailliert
o Swimlane-Diagramm zeigt die Prozesse mit ihren Zuständigkeitsbereichen
o Informationsflussdiagramm zeigt, wie und wodurch die Informationen verlaufen
o Use-Case-Diagramm zeigt die Nutzer und ihre Tätigkeiten in und mit dem M-BID
o GUI-Mockup ist die erste grobe Skizze der M-BID-Bedienoberflächen
Besprechung der Konzeptionsdokumente mit den Nutzern und Entwicklern.
Erstellen von Umsetzungsdokumenten zu Systemaufbau, Objektmodellierung
und Funktionsprogrammierung
o Schichten- und Komponentenmodell
o UML-Klassenmodell für die Modellierung der Geschäftsobjekte
o ADAPT-Diagramm im Kontext BI für die Modellierung der OPLAP-Cubes
o Sequenzdiagramm zeigt die programmatischen Abläufe im M-BID
o GUI-Entwurf ist die Präzisierung des GUI-Mokup
Im weiteren Verlauf schließt sich die Umsetzung eines ersten Prototyps an, siehe
Kapitel 5.2. Danach kann den Nutzern das erste lauffähige Muster präsentiert werden.
127 vgl. [Hanschke, et al., 2013 S. 9] und [Feyhl, 2004 S. 33]
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 57
Üblicherweise geht dann die Konzeption (und damit auch die Untersuchung) in eine
weitere Runde. Diese Tatsache ist durchaus erwünscht, da die Nutzer meist erst beim
Sehen und Probieren erkennen, was sie eigentlich wollten oder wie es noch besser
geht.
Stichworte hierzu sind „Rapid Prototyping“ und „Agile Softwareentwicklung“128. Diese
Entwicklungszyklen gibt es aber nicht nur am Anfang einer Entwicklung, sie sind v.a.
bei komplexen BI-Systemen Teil eines längerfristigen Konzeptes zur „BI-Evolution“129
Bei den Zielen in Kapitel 1.2 wurde dieser Aspekt bereits unter dem Stichwort „M-BID-
Framework“ erwähnt und stellt im Wesentlichen die BI-Strategie (siehe Kapitel 2.1.2,
R3) für das M-BID-System dar, um die SWE-Abteilung bei den komplexen Projekten
angemessen zu unterstützen.
Damit wird bei der Abnahme der ersten M-BID-Umsetzung nicht nur auf die
Anwendungsbeispiele geschaut, sondern auch auf den systematischen Rahmen zur
Weiterentwicklung des M-BID-Systems.
Bei den folgenden Ausführungen wird im Rahmen der vorliegenden Arbeit stets
„exemplarisch“ vorgegangen. Die relevanten Aspekte der Anforderungen werden
aufgezeigt, aber nicht vollständig auf allen Betrachtungsebenen und in allen
Diagrammen „durchexerziert“. Die für die Konzeption typischen Verfahren und deren
Darstellungen werden anhand von relevanten Beispielen durchgeführt, sodass daraus
geeignete Lösungsansätze hervorgehen können.
Die Lösungsansätze L1 bis L11 werden wiederum mit den Anforderungen A1 bis A45
aus der Tabelle 2 in Zusammenhang gebracht, sodass sich die Umsetzung an den
Anforderungen und den theoretischen Aspekten ausrichten kann. Das geschieht u.a. in
den Formen:
Lösungsansätze L1 für A(1, 2, 3, …, N)
Lösungsansätze L5 für A(1, 2, 3, …, N) und gemäß R(1, 2, 3, …, M)
4.2 Konzeption und Lösungsansätze
4.2.1 Prozesslandkarte
Zu Beginn wird aus den Untersuchungsergebnissen eine grobe „Landkarte“ der
bisherigen und künftigen Prozesse erstellt. Sie dient der Dokumentation der Prozesse
128 [Ambler, 2003 S. 12]
129 [Zimmer, et al., 2012 S. 13]
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 58
im Betrachtungsbereich und zur Orientierung, damit man sich nicht im „Jungle“ der
Aktivitäten „verirrt“. Ferner werden Strukturen innerhalb der Prozesse erkennbar, die
für die Umsetzung relevant sein können.
Wie aus der Untersuchung (v.a. Kapitel 3.2.3) erkennbar, bettet sich der Prozess
„Monatliches Projektreview“ in größere Prozesse ein. Ferner unterteilt er sich in
kleinere Teilprozesse, die wiederum in Teilprozesse oder Aufgaben unterteilt werden
können.
Projektreview Quartals-Review
Projektsteuerung und
Entwicklungscontrolling
Proficenter ProSig - Leistungserstellung und Management
Teambesprechungen
Support, Schulung
Projektreview
Projektsichtung MaßnahmenProjektprognose Projektbotschaften
SWE, Test, Doku Vertrieb
Projektsteuerung und Entwicklungscontrolling
Abbildung 27: Ausschnitt aus Prozesslandkarte der SWE-Abteilung
Lösungsansätze L1 für A(4, 15, 17, 18, 23, 26, 27, 28, 31)
Auf der unteren Ebene in der Abbildung 27 sind die Teilprozesse dargestellt, die in
ihrer Detaillierung bereits für eine Unterstützung im M-BID genauer betrachtet werden
können (Kapitel 4.2.2). Z.B. verweist der Prozess „Projektreview“ auf die Anforderung
A18, wonach ein Projekt-Cockpit mit den zugehörigen Dashboards zu entwickeln ist,
u.a. A(23, 26, 27, 28). Dabei waren die „gelben“ Aktivitäten bislang kein expliziter
Bestandteil der monatlichen Projektreviews. Sie stellen somit Umsetzungen im M-BID
dar, die besonders genau mit den Beteiligten abgestimmt werden müssen.
Ferner sind die darüber liegenden Prozesse als Struktur in den Oberflächen des M-BID
vorzusehen.
4.2.2 Ablauf der Prozesse
Die Prozesse aus der Prozesslandkarte (Kapitel 4.2.1) können nun genauer analysiert
und dokumentiert werden. In Abstimmung mit den Beteiligten entstehen
Prozessablaufdiagramme, die soweit detailliert werden, bis die zu realisierenden
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 59
Systemprozesse erkennbar werden. Dabei wird im Folgenden der BPMN-Standard130
für die Notation verwendet; siehe Legende in Abbildung 28.
Ziel ist, dass die notwendigen Geschäftsprozesse und die im M-BID verfügbaren
Systemprozesse weitestgehend miteinander verschmelzen. Damit werden die
Prozessbeteiligten „organisch“ zu den Nutzern des M-BID-Systems.
Sequenzfluss
Sequenzfluss
bedingt
Legende BPMN-Standard:
Aufgabe
Prozess aus
Teilen
Assoziation
Informationsfluss
neu
Xor
or
and
Entscheidungen
Verzweigungen
Startereignis
Endereignis
Zwischenereignis
Abbildung 28: Legende der Diagramme nach BPMN-Standard131
Lösungsansätze L2 für A(3, 4, 8, 15, 17-19, 21-30, 33, 34, 40, 42-45)
In der Abbildung 29 wird der Prozess „Projektreview“ schrittweise in seine Bestanteile
„zerlegt“. Die Details sind dann die Bausteine für die Prozesse und Oberflächen im M-
BID-Portal, insbesondere für die Dashboards A(21-30). Sie werden im Ablauf und
Aufbau möglichst nah entlang der dokumentierten Geschäftsabläufe umgesetzt, siehe
Oberflächenskizze (Kapitel 4.2.5).
Für die Umsetzung müssen entsprechend der Abbildung 29 alle Prozesse aus der
Prozesslandkarte und deren Teilprozesse detailliert werden.
Wie schon bei der Prozesslandkarte erwähnt, sind v.a. die neuen Prozesse (in Gelb)
und deren Umsetzung genauer zu betrachten, da es hierzu noch keine ausreichende
Erfahrung in der SWE-Abteilung gibt.
130 vgl. [Hanschke, et al., 2013 S. 79]; BPMN steht für Business Process Model and Notation
131 Auswahl einiger BPMN-Symbole aus MS-Visio. Die Aufgabe „neu“ gehört nicht zum Standard.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 60
Projekte sichten und bewerten
Projekt sichten
Verläufe ansehen
Projekte sichten und bewerten
Projektreview
Projekt sichten Projektprognose
erstellen
Projektbotschaf-
ten erstellen
Maßnahmen
treffen
Ergebnisse
zusammenfassen
Verläufe
ansehen
Projektfortschritt
ansehen
Projektordner
öffnen
Projektordner
schließen
Projektstunden-
IST ansehen
HK-IST ansehen
Zeitraum
auswählen
Kennzahlen
auswählen (UM,
AE, HK)
Kennzahlen-
reihen vorlegen
Zeitreihen
vergleichen
Projektreview
beginntProjektreview
durchgeführt
Abbildung 29: Prozessablaufdiagramm „Projektreview“
4.2.3 Informationsfluss und Zuständigkeiten
Parallel zu den Ablaufdiagrammen (Kapitel 4.2.2) werden die Untersuchungs-
ergebnisse daraufhin ausgewertet, welche Aktivitäten in welchen Unternehmens-
bereichen anfallen und welche Informationen bzw. Dokumente die Bereiche dazu
benötigen.
Zur Darstellung wird die sogenannte „Swimlane“ verwendet, die den funktions-
übergreifenden Datenfluss und die entsprechende Zuständigkeit für die Prozesse
geeignet visualisiert.
Lösungsansätze L3 für A(1, 5, 6, 10, 11, 14-16, 31, 38, 40)
In Abbildung 30 ist der Prozess „Projektsteuerung und Entwicklungscontrolling“ aus der
Prozesslandkarte in Kapitel 4.2.1 in einer Swimlane dargestellt. Sie zeigt, welche
Nutzergruppen es im M-BID geben wird und wie sie (auch mithilfe des M-BID)
kommunizieren müssen. Insbesondere wird deutlich, wer auf das M-BID zugreifen
muss, wie die Daten hierfür in die Vorsysteme eingetragen werden, und wo noch über
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 61
Excel-Tabellen (XLS) kommuniziert wird. Letzteres verdeutlicht auch, wo die
Anforderung A6 nach Excel-Exporten wirksam wird.
Die verschiedenen Nutzergruppen weisen bereits auf den Aspekt „Nutzer-Rollen und
ihre Zugriffsrechte“ A(14, 16) hin, der im Kapitel 4.2.4 genauer betrachtet wird. Ferner
sind schon einige Systemkomponenten mit Informationsflüssen erkennbar, die in
Kapitel 4.2.6 zum Tragen kommen.
Projektsteuerung und Entwicklungscontrolling
SW-
Entwicklung
Entwicklungs-
leitung
Geschäfts-
leitungProjektleitung Controlling
Teambesprechung
Projektreview
Quartals-Review
Rechnung legen
Daten in SAP
aktualisieren
Quartals-Review
vorbereiten
PRS
M-BID
XLS
XLS
PRS
M-BID
aktualisieren
SAP
M-BID
M-BID
Abbildung 30: Swimlane "Projektsteuerung und Entwicklungscontrolling"
4.2.4 Anwendungsfälle - Use-Cases
Die Use-Cases fokussieren auf die Nutzer (User) und ihre Aktivitäten im und mit dem
System. Hier werden alle bisherigen Untersuchungen und Auswertungen benötigt, um
die erforderlichen Systembereiche (Oberflächen oder Module) mit den notwendigen
Anwendungsfällen (Funktionen, Dienste oder Links auf solche) zu beschreiben.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 62
SWE-Projektleiter
SW-Entwicklungsleiter
M-BID-Admin
SW-Entwickler
Controller
Kaufmännischer Leiter Geschäftsführer
M-BID-Portal –
Profitcenter SWE
Budget / Forecast
Forderungen und
Verbindlichkeiten
Qualitätsmonitor
Projekte / Review
Mitarbeiter
Events / Sonstiges
SWE-Dispatcher
=
=
SW-Entwicklung
read-only
read / write
Links / Logs
M-BID-Power-User
Einstellungen
Abbildung 31: Use-Cases "M-BID-Portal - Profitcenter"
Lösungsansätze L4 für A(1, 7, 8, 9, 14, 15, 16, 17, 18, 38, 40)
In Abbildung 31 sind die Anwendungsfälle auf der obersten Ebene im M-BID-Portal
aufgeführt. Neben der zentralen Unterstützung für das Projektreview sind weitere
Dienste erkennbar, die künftig mit dem M-BID unterstützt werden könnten. Sie werden
derzeit zwar nicht vertieft, kommen aber teilweise in den Oberflächenentwürfen (Kapitel
4.2.5 und 4.2.11) als „Hüllen“ für künftige Dienste vor.
Ferner sind die relevanten Rollen im M-BID-System dargestellt, sowie exemplarisch die
Zugriffe der Rollen „SW-Entwickler“ und „SWE-Projektleiter“ auf die entsprechenden
Dienste. Hierbei wird unterschieden zwischen einem rein lesenden Zugriff (read-only)
und einem auch schreibenden Zugriff (read/write). Dieser Unterschied wird im M-BID
durch Zuweisung spezifischer Rechte realisiert.
Dabei wird wie folgt vorgegangen:
Einrichten von Usern bzw. Nutzern, die sowohl physische Personen als auch
Systemkomponenten (Services und Engines, siehe Kapitel 4.2.6) sein können.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 63
Einrichten von Rollen gemäß Abbildung 31.
Einrichten von Rechten (Lesen, Schreiben/Ändern, Löschen, Neuerstellen) an den
unterschiedlichen Diensten und Funktionen im M-BID.
Einrichten von Nutzergruppen, z.B. „SWE-Abteilung“.
Schließlich die Zuordnung der genannten Aspekte derart:
o Rollen bekommen Rechte
o Nutzer erhalten Rollen und haben damit Rechte
Dieses in A(14,16) geforderte Rechtemanagement wird über eine entsprechende
Konfiguration des Datenbankmanagementsystems MS-SQL-2012 realisiert, das in
Kapitel 4.2.6 noch genauer beschrieben wird.
4.2.5 Oberflächenskizze - GUI-Mockup
Mit den bisherigen konzeptuellen Auswertungen sind schon eine ganze Reihe von
Anforderungen an das M-BID-System betrachtet und eingeordnet worden. Mit diesen
Informationen und den entsprechenden Ausführungen in den Grundlagen aus Kapitel 2
(siehe Verweise auf Relevanz-Felder in den Anforderungen) lässt sich eine erste
Skizze der Nutzeroberflächen im M-BID entwerfen.
Wie schon bei den Konzeptionszielen erwähnt, ist dieser Vorgang sehr zentral und
bedeutsam, da die Entwickler und künftigen Nutzer das System zum ersten Mal
„wirklich sehen“ können. Das sogenannte GUI-Mockup132 ist meist eine grobe
Zeichnung mit Stiften auf Papier oder Tafel; so kann z.B. in einer Expertenrunde das
Modell zusammen mit den Umsetzungsideen allmählich entstehen.
Lösungsansätze L5 für die unter L1 bis L4 genannten Anforderungen und A(27, 30).
Ferner ist die Grundlage der Umsetzung das Kapitel 2.3.3 R(14, 18).
In Abbildung 32 sind alle Skizzen des M-BID-Portals im Überblick zu sehen, wobei jede
Papier-Bahn eine weitere Detaillierungsebene darstellt.
Von Grob (links) nach Fein (rechts):
Ebene „Profit-Center“ mit den möglichen Diensten, siehe Use-Cases Kapitel 4.2.4.
Ebene „Alle Projekte“ mit den relevanten Projekten der SWE-Abteilung.
Ebene „Projekt XY“ zeigt die Dashboards mit den Kennzahlen und Botschaften
eines konkreten Projektes gemäß den Prozessen aus Kapitel 4.2.2
Ebene „Details“ zeigt die detaillierte Kennzahlen hinter dem Dashboard (Drill-down).
132 GUI=Graphical User Interface, Mockup bedeutet übersetzt „Attrappe“
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 64
Abbildung 32: GUI-Mockup "M-BID-Portal"
Insbesondere sind auf der Ebene „Projekt XY“ die Kennzahlen-Dashboards mit ihren
grafischen Elementen (Tachometer, Linien/Kurven und Tabelle) erkennbar.
Gemeinsam mit der Auswahlliste auf Ebene „Alle Projekte“ bilden sie das „Projekt-
Cockpit“ des M-BID-Systems. Ferner sind immer wiederkehrende Symbole und
Strukturen erkennbar, die das M-BID-Portal auf allen Ebenen strukturieren. Eine
Verfeinerung der Skizzen erfolgt in Kapitel 4.2.11 nach weiteren Konzeptionen.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 65
4.2.6 Systemaufbau und Systemkomponenten
Nachdem im vorherigen Kapitel ein erstes Bild von den Oberflächen des M-BID
entstanden ist, wird nun ein Entwurf des IT-Systems erstellt, das die gewünschten
Oberflächen realisieren muss.
Lösungsansätze L6 für alle Anforderungen und gemäß R(2-7, 9, 10, 11, 15)
Zunächst braucht das M-BID-System die notwendigen Systemkomponenten, die nach
Kapitel 2.2.1 (R6) ein DWH-System ausmachen. Im Hinblick auf die Untersuchung der
Situation und den BI-Systemschichten in Kapitel 2.1.3 (R5) ergibt sich der folgende
Aufbau, siehe auch Abbildung 33:
Operative Systeme
o PRS und SAP, wie sie in Kapitel 3.2.2 beschrieben sind.
Datenbereitstellung
o Die Staging-Area wird beim M-BID keine Datenbank im eigentlichen Sinn sein,
sondern nur ein Ablageort für die Excel-Tabelle (XLS), die aus SAP exportiert
wird und als Datenschnittstelle zum M-BID fungiert. Sie wird vom M-BID-Admin
oder Power-User mittels M-BID-Engine-SAP2ODS (s.u.) in einen Dateiordner auf
dem M-BID-Server hochgeladen. Von dort aus wird die Tabelle auf Anforderung
importiert.
o Der Operational Datastore ODS beinhaltet beim M-BID die notwenigen Daten
aus PRS und SAP. Hierfür werden die Daten aus den Vorsystemen durch die
ETL-Prozesse (s.u.) gefiltert, also extrahiert und bereinigt. Die Daten sind
„quellen-nah“ gespeichert, also insbesondere in der Normalform, wie sie aus den
Vorsystemen herauskommen:
Aus PRS kommen die „Projektobjekte“ mit den entsprechenden Verweisen
und Primärschlüsseln.
Aus SAP bzw. der SAP-XLS kommen „Monatsobjekte“, die vollständig
denormalisiert sind, siehe Abbildung 25.
o M-BID-Service-PRS2ODS ist der erste von zwei ETL-Prozessen auf der Ebene
der Datenbereitstellung. Er extrahiert die Daten mittels SQL-Abfragen direkt aus
dem PRS und bereinigt sie von syntaktischen Fehlern, siehe Kapitel 4.2.9
o M-BID-Engine-SAP2ODS ist das Pendant für das SAP. Der ETL-Prozess hat
aber die o.g. Besonderheit bei der Extraktion, da auf das SAP aus Gründen der
Datensicherheit und des Datenschutzes nicht direkt zugegriffen werden kann.
Somit kann der Import der SAP-Daten nicht interventionsfrei ablaufen und es ist
eine entsprechende Nutzeroberfläche (GUI) zu realisieren. Um diesen Aspekt zu
verdeutlichen, sieht das Konzept zwei unterschiedliche Prozess-Typen vor:
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 66
Automatisch ablaufende Prozesse werden „Service“ genannt und werden
durch systeminterne Anlässe (z.B. Time- und Event-Trigger) ausgelöst.
Die Prozesse, die einen Eingriff des Nutzers erfordern und somit eine GUI,
werden „Engine“ genannt. Sie werden auch durch Nutzer-Anforderung (On-
Demand-Trigger) ausgelöst.
Datenanalyse und Informationsgenerierung
o Das Central Data Warehouse C-DWH wird auch beim M-BID die „single source
of truth“ sein und beinhaltet die aufbereiteten Daten aus dem ODS. Dazu werden
die Daten des ODS aus den Bereichen PRS und SAP harmonisiert, also
semantisch bzw. betriebswirtschaftlich zusammengeführt, siehe Kapitel 2.2.2
(R7). Das C-DWH soll in der 3.Normalform sein, es wird also mit vollständigen
Snowflake-Schemata realisiert, siehe Kapitel 2.2.3 (R8). Mit der 3.Normalform
kann das C-DWH flexibel als Quelle für alle weiteren und künftigen Analysen im
OLAP-Kontext dienen.
o Die Data Marts DM werden die speziellen Speicher für verdichtete Daten, die von
den Diensten oder Funktionen im M-BID-Portal, -Cockpit und -Dashboard
benötigt werden. Die DM werden, wie die anderen Datenbanken, auf dem M-BID-
Server aufgesetzt. Der Zusammenhang zwischen den Diensten und den DM ist
dabei wie folgt:
Pro M-BID-Cockpit steht ein DM zur Verfügung. Z.B. für das Projekte-Cockpit
auf der Ebene „Alle Projekte“, mit anschließender Filterung auf ein konkretes
Projekt der Ebene „Projekt XY“, siehe Kapitel 4.2.5.
Pro M-BID-Dashboard steht eine Tabellen im DM für die verdichteten
Kennzahlen zur Verfügung. Hier werden z.B. die aggregierten Summen und
berechneten Differenzen für die Tachometer-Anzeige „HK-IST“ vorgehalten,
die zuvor von speziellen ETL-Prozessen generiert wurden. Ferner gehört eine
weitere Tabelle zu einem Dashboard für die Anzeige der Botschaften. Dabei
ist die Anzeige immer der aktuelle Stand aus dem C-DWH. Bei den Reviews
werden dann neue Botschaften geschrieben und ins C-DWH „gesendet“.
Danach werden sie von einem M-BID-Service wieder aus dem C-DWH ins DM
(per New-Trigger) aktualisiert, siehe Datenfluss in Abbildung 33, sowie Kapitel
4.2.10.
o M-BID-Service-ODS2DWH realisiert die ETL-Prozesse der Harmonisierung (R7)
und wird automatisch angestoßen, wenn im ODS neue Daten vorliegen.
o M-BID-Service-DWH2DM realisiert die ETL-Prozesse der Aggregation und
Anreicherung (R7) und wird automatisch angestoßen, wenn im C-DWH neue
Daten vorliegen, bzw. wenn für einen „Cockpit-Zugriff“ die Tabellen im DM
aktualisiert werden müssen, siehe Kapitel 4.2.9.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 67
Informationspräsentation und -distribution
o Die DM sind physikalisch gesehen Datenbanken. Aber inhaltlich so nah an den
Dashboards, dass sie auch dieser BI-Systemschicht zugeordnet werden können.
Aus diesem Grund wird bei den DM auf eine durchgehende Normalform
verzichtet. Die Daten werden von den o.g. M-BID-Services derart generiert und
im DM abgelegt, dass sie am besten die Dashboards bedienen können.
o M-BID-Engine-ProfitCenterSWE ist aus der Sicht des Nutzers das zentrale
Programm-Modul im M-BID-System. Es realisiert alle notwendigen Funktionen
und stellt sie auf der Browser-Oberfläche der mobilen Endgeräte zur Verfügung,
siehe Kapitel 4.2.11.
o Das M-BID-Frontend sind die mobilen Endgeräte auf der Client-Seite des M-BID
z.B. Laptops oder Tabletts, die mit dem Browser „Internet Explorer“ (IE) vom
Microsoft ausgestattet sind. Technisch wären auch andere Browser möglich, aber
eine interne Firmenvorschrift bzw. Konzernvorgabe fordert den IE. Natürlich kann
auch von einem stationären Arbeitsplatzrechner mittels IE-Browser auf den M-
BID-Server zugegriffen werden. Mit dieser Client-Server-Lösung ist das M-BID
nicht nur mobil einsetzbar, sondern auch multiuser-fähig, siehe die FASMI-
Anforderung „Shared“ in Kapitel 2.3.2, R10.
Die Metadatenbank steht allen M-BID-Services und -Engines zur Verfügung und
beinhaltet folgende Daten:
o Beschreibungstexte für die Kennzahlen und Auswertungen im Sinne von
Erklärungskomponenten in Fach- oder Expertensystemen133. Die Informationen
werden von der M-BID-Engine-ProfitCenterSWE ausgelesen und dem Nutzer
dargestellt. Dadurch kann z.B. die Bedeutung der Kennzahl „HK“ direkt im
Dashboard (u.a. als Tooltip) angezeigt werden. Die Beschreibungen können
direkt aus den Erfassungsbögen der Tabelle 1 in die Metadatenbank über-
nommen werden.
o Systeminformationen, die bei der Verarbeitung in den Engines und Services
entstehen. Sie stehen als Statusmeldungen oder Fehlerwarnungen dem Nutzer
und Admin zur Verfügung, siehe Use-Case „Links / Logs“. Die System-Logs
haben v.a. zwei Vorteile: Zum einen helfen sie bei einer etwaigen Fehlersuche,
zum anderen schaffen sie durch die Statusmeldungen Vertrauen und
Transparenz, siehe Kapitel 2.1.2 (R2).
o Informationen zur Datenherkunft in Form einer „Daten-Vita“, siehe Kapitel 2.2.1
(R6). Die „Daten-Vita“ wird in Kapitel 4.2.7 genauer erläutert.
133 vgl. [Savory, 1988 S. 128]
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 68
Die Administrationsschnittstelle wird im M-BID eine GUI sein, die im M-BID-
Portal erreichbar ist, siehe Use-Case „Einstelllungen“ in Abbildung 31. Hier kann der
M-BID-Admin oder Power-User das M-BID-System konfigurieren und die Rollen und
Rechte vergeben (R6). Die Admin-Schnittstelle ist in Abbildung 33 nicht separat
abgebildet, da sie Teil der zentralen M-BID-Engine ProfitCenterSWE ist.
M-BID-Service
„PRS2ODS“
ETL: Filterung
M-BID-Frontend
Mobile Endgeräte
PRS-Frontend SAP-Frontend
PRS
C-DWH
ODS
SAP
DM
Staging
M-BID-Engine
„SAP2ODS“
ETL: Filterung
M-BID-Service
„ODS2DWH“
ETL:
Harmonisierung
M-BID-Engine
„ProfitCenterSWE“
Web-Visualisierung
M-BID-Service
„DWH2DM“
ETL: Aggregation
und Anreicherung
Meta
SAP-Export
bidirektional
Datenfluss
Abbildung 33: M-BID-System mit Komponenten und Datenströmen134
M-BID-Framework
Mit dem Aufbau des M-BID-Systems stellt sich auch die Frage, was das M-BID-
Framework aus den Zielen in Kapitel 1.2 und 4.1 konzeptuell und für die Umsetzung
gemäß R(3, 4) ausmacht. Im Folgenden werden die wichtigsten Aspekte hierzu
genannt:
Erweiterbare Grundstruktur aus der Sicht der SW-Entwickler, damit künftige
Anforderungen an das M-BID möglichst reibungslos realisiert werden können.
134 Zur besseren Nachvollziehbarkeit wurden die gleichen Farben wie in Abbildung 7 verwendet.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 69
Vorgegebene Systematik mit
o Hardware und Software, v.a. dem M-BID-Server mit dem Datenbanksystem MS-
SQL-2012135 und der Windows-Laufzeitumgebung für das M-BID-System.
o zukunftstauglichen Programmiertechnologien und SQL-Zugriffstandards, wie sie
mit ASP.NET und LINQ von Microsoft gegeben sind.
o Standards für die Netzkommunikation mit dem M-BID-Server sowie für die
Darstellung im Browser für den Online-Zugriff auf das M-BID.136
o Standards für die Beschreibung von Geschäftsfällen und -objekten, wie sie in der
vorliegenden Arbeit realisiert werden, und im Kontext der Ontologie137 gefordert
sind.
Basisklassen und Grundkonfigurationen für alle wiederverwendbaren Kompo-
nenten wie
o Diagrammtypen und Diagrammelemente, z.B. Tachometer und Tacho-Nadel
o Transformationsregeln, z.B. für die Aggregation per Summe
o Verbindungobjekte (Connections) zu den Datenbanken, z.B. für eine einheitliche
Datenbank-Authentifizierung aller M-BID-Engines und -Services
o OLAP-Cubes und deren Abfrage-Ergebnisse
o Web-Templates für das Grunddesign im M-BID-Portal, u.a. mit CSS-Stylesheets
Framework-Dokumentation für das Systemverständnis, was insbesondere durch
die vorliegende Arbeit ermöglicht wird.
4.2.7 Reporting der Kennzahlen mit Dashboardelementen
Die zentralen Informationen im M-BID sind die Kennzahlen, wie sie im Kapitel 3.2.4
beschrieben und in der Tabelle 1 erfasst worden sind. Für die Umsetzung ist nun von
Bedeutung, welche Darstellungsformen für die Kennzahlen in den Dashboards gewählt
werden und welche Formeln dafür notwendig sind. Diese Formeln sind dann das
Instrumentarium der ETL-Prozesse bei der Aggregation und Anreicherung, siehe
Kapitel 4.2.8. Im Folgenden wird anhand der Kennzahl Herstellungskosten (HK) und
den zugehörigen Kennzahlen dieser Konzeptschritt erläutert.
135 siehe [Microsoft, 2013 b]
136 siehe dazu auch [Geiss, 2012 S. 6,8]
137 Ontologie (Ontology) meint hier die Schaffung eines unbedingt konsistenten Datenmodells im
ganzen Unternehmen, was auch automatisiert z.B. mit XML-Standards überwacht und erweitert werden
kann; vgl. [Wang, et al., 2008 S. 81 f.]
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 70
Lösungsansätze L7 für A(3, 4, 15, 18, 19, 20, 21, 28, 31, 32, 33, 44) und gemäß R(2,
13, 14, 16, 18)
Aus der Tabelle 1 können in der Spalte „Herstellungskosten“ folgende Informationen
abgelesen werden, die in diesem Zusammenhang relevant sind:
Der Erfolgsfaktor ist eine „möglichst niedrige Aufwendung für die Herstellung der
Produkte oder Leistungen des Profitcenters SWE“. Diesen kritischen Pfad gilt es
also hinreichend „auszuleuchten“.
Die entsprechenden Kernfragen „Was kostet die Leistungserstellung? Liegen die HK
noch im erlaubten/prognostizierten Bereich?“ müssen beim Betrachten des
Dashboards möglichst gut beantwortet werden.
Die Granularität im M-BID soll 1€ sein, mit der auch gerechnet wird. Die
Anzeigegenauigkeit sollen je nach Detaillierung 1 € oder 1k€ (k=1000) sein.
Die Beschreibung „Die HK setzen sich zusammen aus den Fertigungs-, Material-
und Sonderkosten. Sie entstehen durch Leistungen innerhalb von SWE-Projekten
sowie durch Wartung und Weiterentwicklung der Software“ gibt sowohl Hinweise auf
den „Eisatzort“ der Kennzahl, als auch auf eine erste Formel in diesem Kontext.
HK_IST = STD_K_IST + RU_K_IST + TRAPAC_K_IST + MATSUB_K_IST + SONST_K_IST mit
HK_IST, die aufgelaufenen Herstellungskosten in einem Projekt
STD_K_IST, die Kosten für die verbrauchten Projektstunden
RU_K_IST, die Kosten für Reisen und Übernachtungen
TRAPAC_K_IST, die Kosten für Transport und Verpackung
MATSUB_K_IST, die Kosten für Material und extern zugekaufte Leistungen
SONST_K_IST, die sonstigen Kosten
Formel 1: Herstellungskosten im IST
Die absoluten Kennzahlen sind HK_IST, HK_AB_IST, HK_SOLL, wobei HK_IST
sowohl berechnet aus dem SAP kommt, als auch mit der Formel 1 im M-BID
berechnet werden kann. Im Sinne der Tatsache, dass das M-BID ein Analysesystem
sein soll, wird HK_IST aus den originären Daten errechnet und dann mit dem Wert
aus SAP verglichen. Bei Abweichungen wird eine Warnmeldung über die
Systemlogs (siehe Kapitel 4.2.6) ausgegeben. Das ist eine in der Praxis oft
gewählte Möglichkeit, die redundanten Daten für Plausibilitätskontrollen zu ver-
wenden.
Die zu realisierenden Szenarien sind IST, SOLL (gemäß Kalkulation),
PROGN_END, PROGN_GJ, mit der zusätzlichen Variante AB_IST für die
abgerechneten HK. AB_IST wird aber auch als Szenario modelliert, siehe Kapitel
4.2.8.
Damit sind zusammengefasst folgende Größen und Formeln für das HK-Dashboard
(vergleiche mit Abbildung 34) relevant:
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 71
HK_IST = STD_K_IST + RU_K_IST + TRAPAC_K_IST + MATSUB_K_IST + SONST_K_IST, s.o.
(große Tachonadel)
HK_AB_IST (grüner Bereich)
zur Kontrolle, ob man nicht zu sehr in Vorleistung geht
DIF_HK_PROGN_END_HK_AB_IST = HK_PROGN_END – HK_AB_IST (gelber Bereich)
zur Kontrolle, ob die Gewinnmarge des Projektes noch verbessert werden kann oder nicht
HK_PROGN_GJ (kleine Tachonadel)
zur Kontrolle, ob noch Rückstellungen für das kommende Jahr notwendig sind
DIF_HK_SOLL_HK_PROGN_END = HK_SOLL - HK_PROGN_END (orange Bereich)
zur Kontrolle, ob noch „Luft“ im Projekt ist, ohne Bedrohung des kalkulierten Gewinns
DIF_AE_IST_HK_SOLL = AE_IST - HK_SOLL (roter Bereich)
zur Kontrolle, ob noch kostendeckend gearbeitet wird, oder man schon „draufzahlt“
Formel 2: Formeln für das Herstellungskosten-Dashboard
Mit den bisherigen Angaben kann das HK-Dashboard entwickelt werden. Als Ansatz
wurde bereits im GUI-Mockup in Kapitel 4.2.5 die Dashboard-Anzeige „Tachometer“
vorgeschlagen.
In Summe sollte v.a. eine geeignete Darstellung bezüglich der o.g. Kernfrage gewählt
werden. Sicherlich gibt es viele Möglichkeiten ein HK-Dashboard darzustellen, aber
Einiges kann auch ausgeschlossen werden. Z.B. ein Kurvenverlauf mit Linien ist wenig
geeignet, da es sich beim HK-Dashboard um eine „Momentaufnahme“ handelt.
Ein Balkendiagramm oder Ähnliches wäre auch möglich, da aber der Ordnungsrahmen
ein „Cockpit“ ist, scheint ein Tachometer die hierfür organische Lösung zu sein.
HK-IST 135 k€
HK_SOLLHK_PROGN_END
HK_AB_IST
AE
81
HK_PROGN_GJ179 k€
Alles im
grünen
Bereich
Achtung: Prognose bis
Projektende anpassen
Warnung: Ab hier
schmilzt der Gewinn
ab. Nachtrag
erforderlich.
Warnung: Ab hier macht
das Projekt Verlust
Abbildung 34: Tachometer für Anzeige der Herstellkosten
Letztlich ist das Aussehen der Dashboards immer auch eine Geschmacksfrage der
Nutzer und des Designers. Entscheidend ist, dass die in der Formel 2 relevanten Werte
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 72
richtig abgebildet werden. Ebenso wichtig ist die Abstimmung des Designs mit den
Nutzern und die Wiederverwendung der Designvorlagen für ähnliche Zwecke.
Für die Umsetzung im M-BID zeigt die Abbildung 34 das HK-Dashboard:
Die in der Formel 1 definierte Kennzahl HK_IST wird als große Tacho-Nadel
dargestellt, sie ist also die Führungsgröße in dieser Anzeige; ähnlich der
Geschwindigkeit beim Auto.
Die in der Formel 2 definierten Werte sind die Länge der Tacho-Bereiche, z.B. der
grüne Bereich ist HK_AB_IST, also der Bereich, wo die HK noch unterhalb jeder
Grenze liegen und insbesondere schon abgerechnet bzw. bezahlt wurden. Das stellt
den finanziellen Idealzustand im Projekt dar und führt insofern zur Botschaft „Alles
im grünen Bereich“.
Die kleine graue Tacho-Nadel dient der Darstellung von PROGN_GJ, also der
prognostizierten HK im laufenden Geschäftsjahr. Dieser Wert hätte auch als Tacho-
Bereich dargestellt werden können, allerdings würde das zu einer starken
Überlappung mit den o.g. Tacho-Bereichen führen. Dieser Wert ist eine zeitnahe
Abschätzung, wohingegen die anderen Werte eher auf das Gesamtprojekt
ausgerichtet sind. Insofern ist es sinnvoll, hierfür eine separate Darstellung zu
wählen.
STD-IST 1.450 h
STD_SOLL
81
STD-AB-IST1900 h
STD_AB_IS
T
STD_PROGN_END
Alles im
grünen
Bereich
Achtung:
Stundenschätzung bis
Projektende anpassen
Warnung: Nachtrag
erforderlich.
Abbildung 35: Tachometer für Anzeige der Projektstunden
Die Abbildung 35 zeigt das entsprechende Projektstunden-Dashboard (STD-
Dashboard). Es wurde mit den entsprechenden Werten und Überlegungen entwickelt
wie das HK-Dashboard. Der einzige Unterschied liegt im Anwendungsfokus bzw. der
Reichweite, siehe Kapitel 2.3.3 (R13). Das STD-Dashboard ist besser für die
Absprache mit den SWE-Projektleitern und SW-Entwicklern geeignet, da es auf dieser
operativen Ebene nicht um Geldwerte, sondern um geleistete und verfügbare
Projektstunden geht. Das ist auch daran erkennbar, dass der Bereich, wo der Gewinn
„abschmilzt“ (DIF_AE_IST_HK_SOLL) nur noch ein kurzer roter Hinweis-Balken ist.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 73
Tatsächlich stehen „per Unternehmensinteresse“ in diesem Bereich auch keine
Projektstunden mehr zur Verfügung. Ein etwaiger Engpass muss zuvor im HK-
Dashboard erkannt und über eine Maßnahme (z.B. einen Nachtrag, siehe A28)
behoben werden.
Die Einbettung der Dashboard-Anzeigen in das entsprechende Dashboard findet in
Kapitel 4.2.11 statt.
4.2.8 Datenmodellierung und OLAP-Cubes
Nachdem die Anforderung an das M-BID in den bisherigen Schritten hinreichend
beleuchtet wurden, kann mit der Konzeption auf Ebene der Datenhaltung begonnen
werden. Sie stellt dar, welche Tabellen bzw. Cubes nötig sind, um die identifizierten
Geschäftsobjekte und deren Beziehungen im M-BID-System abzubilden. Die
Datenmodellierung stellt damit die Grundlage für die programmtechnische Umsetzung
der ETL-Prozesse dar, die in Kapitel 4.2.9 genauer betrachtet wird.
Lösungsansätze L8 für A(2, 3, 4, 10, 11, 13, 15, 18, 19, 20-28, 30-35, 41-45) und
gemäß R(1, 6, 7, 8, 10, 12)
ODS
Wie in Kapitel 4.2.6 beschrieben, wird das ODS „quellen-nah“ modelliert. Im M-BID
bedeutet das die Übernahme u.a. der Monatsobjekte aus dem SAP, siehe Abbildung
25, und der Projektobjekte aus dem PRS, siehe Abbildung 26.
Da diese Objekte aus unterschiedlichen Quellen kommen, ist es nicht erstaunlich, dass
sie unterschiedliche Primärschlüssel (IDs) bezüglich der Projekte haben. Im Sinne
einer syntaktischen Harmonisierung (Kapitel 2.2.2, R7) ist eine Zuordnungstabelle
(Mapping) vorzusehen, mit der die Eliminierung der Schlüsseldisharmonien vorge-
nommen werden kann, siehe dazu Kapitel 4.2.9.
ODS_SAP_Projektstand
PK ID
Revision PRJ_ID_SAP PRJ_LABEL_SAP HK_IST STD_K_IST RU_K_IST TRAPAC_K_IST MATSUB_K_IST SONST_K_IST HK_AB_IST HK_SOLL STD_IST AE_IST UM_IST HK_REST_IST
ODS_PRS_Projekte
PK ID
RevisionFK1 PRJ_ID_PRS PRJ_LABEL_PRS REV_STAND PRJ_BEGINN_UMSETZUNG PRJ_ENDE_UMSETZUNG AE_SOLL BERMERKUNG STD_SOLL STD_S HK_SOLL STD_K_SOLL GM_AE
ODS_PRJ_ID_Mapping
PK ID
PRJ_ID_PRSFK1 PRJ_ID_SAP
Abbildung 36: ODS-Tabellen für die Quellsysteme PRS und SAP
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 74
Die Abbildung 36 zeigt exemplarisch die Tabellen im OSD, die im nächsten
Transformationsschritt in das C-DWH überführt werden. Neben den IDs sind auch die
Kennzahlen enthalten, die für die Formeln aus Kapitel 4.2.7 notwendig sind.
C-DWH
ADAPT (Application Design for Analytical Processing Technologies) ist ein komplexes
Notationssystem für OLAP-Anwendungen und deren Datenmodellierung im DWH,
siehe auch Kapitel 2.2.3 (R8). Im folgenden Beispiel werden die zentralen Aspekte der
logischen Modellierung des C-DWH im M-BID dargestellt.
Entsprechend ist nur ein Teil der ADAPT-Notationssymbole für das Beispiel von
Bedeutung, siehe Legende in Abbildung 37.
„Cube, Dimension, Hierarchie, Hierarchiestufe und Hierarchiestufenelement“ sind
die Komponenten, wie sie in Kapitel 2.3.2 beschrieben sind.
„Funktion“ ist eine Umrechnungsvorschrift, die im OLAP-System eine Trans-
formation realisiert, siehe Kapitel 4.2.9.
Der Verbinder „Muss-Abfolge“ (strict precedence) zeigt an, dass eine
Hierarchiestufe als zwingenden Vorgänger die darüber liegende Stufe hat. Die
höhere Stufe wird entsprechend zwingend von der unteren Stufe detailliert.
Der Verbinder „Kann-Abfolge“ (loose precedence) zeigt an, dass die Verbindung zur
darüber liegenden Stufe sein kann aber nicht sein muss. Jedoch zur wiederum
darüber liegenden Stufe ist die Verbindung zwingend.
Dimension1
Dimension2
Cube Dimension
Hierarchie
Hierarchiestufe{ }
{ } Hierarchiestufen-
elementKann-Abfolge Muss-Abfolge
Funktion / Transformation
Abbildung 37: Legende ADAPT-Notation
Abbildung 38 zeigt das Cube für die Aufnahme der Herstellungskosten (HK) mit seinen
Dimensionen, wie sie v.a. in Kapitel 3.2.4 und 4.2.7 identifiziert wurden.
Dimension Projekt mit einer Dimensionshierarchie, die auf oberster Ebene mit
der Aggregation „Alle Projekte“ beginnt (siehe erste Muss-Abfolge) und dann
über die Ebene „Projekt XY“ immer weitere Details vorhält, siehe auch L(5, 6).
Eine Besonderheit ist die „Kann-Abfolge“ zwischen der Stufe Projekt und
Vorgang bzw. zwischen Meilenstein und Vorgang, die sich konkret auf die
Datenmodellierung im C-DWH auswirkt. In Abbildung 39 ist hierzu links oben
erkennbar, dass in der Dimensionstabelle „Vorgang“ zwei Fremdschlüssel (FK)
vorzusehen sind. Der FK1 ist der Verweis zum Meilenstein der sein kann, und
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 75
der FK2 ist der Verweis zum Projekt, der sein muss, weshalb er im UML-
Klassenmodell fett geschrieben wird.
Dimension Zeit mit den Stufen Jahr, Quartal, Monat. Die Stufe Quartal ist in
Abbildung 38 exemplarisch in seine Stufenelemente Q1 bis Q4 aufgefächert.
Die Dimension Detail hat nur die Aggregationsstufen (gesamte) HK und
Position. Letztere hält die Bestandteile vor, aus denen die gesamten HK
aufsummiert sind, siehe Formel 1 .
Projekt
Projekt_Hierarchie
ProjektXY{ }
Vorgang{ }
ToDo{ }
Meilenstein{ }
Zeit
Zeit_Hierarchie
Jahr{ }
Quartal{ }
Monat{ }
Szenario
{ } IST
{ } SOLL
{ } PROGN_END
{ } PROGN_GJ
{ } AB_IST
{ } Q2
{ } Q1
Projekt
Zeit
Detail
Szenario
DWH_CUBE_HK
Detail
Detail_Hierarchie
HK{ }
Position{ }
{ } STD_K
{ } RU_K
{ } TARPAC_K
{ } MATSUB_K
{ } SONST_K
{ } Q3
{ } Q4
Abbildung 38: Cube Herstellungskosten mit den vier Dimensionen
Dimension Szenario hat keine Dimensionshierarchie, sondern direkte
Stufenelemente, die keine Priorität untereinander haben. Sie ermöglichen das
Speichern der unterschiedlichen HK-Werte bezüglich ihrer Reichweite; also ob
es sich um einen Istwert oder einen Planwert (SOLL, PROGN) handelt.
Darunter ist auch das Element AB_IST, das eigentlich kein Szenario sondern
eine Variante darstellt, siehe Tabelle 1. Da aber die abgerechneten HK derzeit
nur als Istwert vorkommen, kann auf eine separate Dimension „Variante“ oder
gar einen separaten Cube „HK_AB“ verzichtet werden. In weiteren
Ausbauschritten des M-BID könnte diese Anforderung ggf. entstehen.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 76
DWH_CUBE_HK
PK ID_HK
Wert RevisionFK3 ID_ProjektFK2 ID_MonatFK4 ID_DetailFK1 ID_Szenario
Dim_Projekt
PK ID_Projekt
Bezeichnung Revision
Dim_Jahr
PK ID_Jahr
Bezeichnung Revision
Dim_Meilenstein
PK ID_Meilenstein
Bezeichnung RevisionFK1 ID_Projekt
Dim_Quartal
PK ID_Quartal
Bezeichnung RevisionFK1 ID_Jahr
Dim_Monat
PK ID_Monat
Bezeichnung RevisionFK1 ID_Quartal
Dim_Vorgang
PK ID_Vorgang
Bezeichnung RevisionFK1 ID_MeilensteinFK2 ID_Projekt
Dim_ToDo
PK ID_ToDo
Bezeichnung RevisionFK1 ID_Vorgang
Dim_Szenario
PK ID_Szenario
Bezeichnung Revision
Dim_Detail
PK ID_Detail
Bezeichnung Revision
Abbildung 39: Klassenmodel des Cubes Herstellungskosten
Die in Kapitel 2.2.3, R8 geforderte Historisierung im DWH wird im M-BID über einen
Zeitstempel im Attribut „Revision“ realisiert. Der Revisionsstand wird automatisch
eingetragen sobald ein Wert in einer Tabelle geändert wurde. Im M-BID wird jedem
Objekt ein solcher Zeitstempel zugewiesen. Damit lässt sich über einen Vergleich
bestimmen, welche Angaben in den Dimensionstabellen für den gerade betrachteten
Wert der Faktentabelle gültig sind. Das sind die Dimensionsangaben, deren
Revisionsstand größer oder gleich dem Revisionsstand des betrachteten Wertes sind.
Die in Kapitel 4.2.6 beschriebenen Tabellen für die Botschaften im M-BID-System
haben zwei Orte. Zum einen ist im C-DWH die zentrale Botschaften-Tabelle für das
gesamte M-BID, zum anderen werden für die DM der Cockpits relevante Botschaften
aus der zentralen Tabelle extrahiert und dann in den Cockpits angezeigt.
Hierfür wird aber kein komplexes Cube benötigt, sondern eine „flache“ Key-Value-
Tabelle mit den folgenden Eigenschaften:
DWH_TAB_BOTSCHAFTEN ID | Revision | Key | Botschaft | Autor | Priorität
Key ist eine Zeichenkette (String), die u.a. die Anzeige-Ebene (breadcrumbs138) im M-
BID-Portal aufnimmt, auf der die Botschaft editiert wurde, z.B. „Profitcenter_SWE >
Alle_Projekte > ProjektXY“. Damit kann bei einem späteren Zugriff von einem ETL-
Prozess entschieden werden, ob eine Botschaft aus dem C-DWH in ein DM extrahiert
wird oder nicht.
138 „Brotkrümelnavigation“ wird auf Internetseiten die interaktive Navigationsleiste am oberen Bildrand
genannt , mit deren Hilfe ein Nutzer schnell erkennt, wo er sich gerade befindet, siehe Kapitel 4.2.11.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 77
DM
Die DM beinhalten speziell aufbereitete Daten aus den Cubes des C-DWH, um die
Dashboards mit Kennzahlen und Botschaften zu versorgen.
In einem DM (zu einem Cockpit) gibt es jeweils zwei Tabellen pro Dashboard, siehe
Kapitel 4.2.6. Eine Tabelle ist für die Botschaften des Dashboards, die eine relevante
Untermenge der Informationen aus dem C-DWH enthält. Eine weitere Tabelle ist für
die Kennzahlen bzw. für die Elemente der Dashboard-Anzeigen. In Abbildung 41
(Kapitel 4.2.9) ist rechts die Tabelle DM_DASH_HK zu sehen, wo über die Dimension
Dash_Element die notwendigen Werte für das Dashboard vorgehalten werden.
Metadaten
Um die Informationen aufzunehmen, die in Kapitel 4.2.6 unter dem Stichwort
Metadaten beschrieben sind, werden in einer separaten Datenbank eine Reihe von
Tabellen benötigt. Hier sind exemplarisch zwei Tabellen aufgeführt:
Die Tabelle für die Daten-Vita hat die Form
META_DATENVITA ID | Revision | Key | Tool | Toolrevison | Aktion | Quellen
Key ist ein String, der die Verbindung der Vita zur Kennzahl realisiert.
Mit den Angaben Tool und Toolrevison wird die Funktion bzw. Transformation
identifiziert, die einen Wert verändert hat. Aktion und Quelle gibt an, welche
Operation durchgeführt wurde und aus welchen Quellen die Operanden stammen.
Mit der Zeit entsteht eine Art Daten-Pfad139 für jedes Datum im M-BID, der bei einer
Fehlersuche im System oder als Tooltip ein hilfreicher Hinweis für den Nutzer sein
kann.
Die Tabelle für die Daten-Beschreibungen hat die Form
META_BESCHREIBUNG ID | Revision | Key | Beschreibungstext
Key realisiert die Verbindung zu den beschriebenen Elementen, z.B. die Kennzahl
HK mit der Beschreibung aus der Tabelle 1. Die Beschreibungstexte werden dann
als Quelle für einen Tooltip oder in Verbindung mit der Daten-Vita für einen
Systemreport herangezogen.
Es ist wahrscheinlich, dass die Metadatenbank sehr schnell groß wird, weshalb es
aus Gründen der Performanz gut ist, sie in einer eigenständigen Datenbank zu
realisieren und nicht im C-DWH.
139 vgl. [Kemper, et al., 2010 S. 50]
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 78
4.2.9 ETL-Prozesse - Transformationen
Die in Kapitel 2.2.1 und 2.2.2 beschriebenen ETL-Prozesse wurden in Kapitel 4.2.6 mit
den unterschiedlichen M-BID-Services und -Engines in Zusammenhang gebracht.
Damit diese Systemfunktionen (siehe auch Abbildung 33) entsprechend umgesetzt
werden können, muss definiert werden, welche ETL-Prozesse es im M-BID gibt, wo sie
zum Einsatz kommen und was sie leisten sollen.
Lösungsansätze L9 für A(1, 3, 4, 10, 11, 13, 15, 18, 19, 20, 21, 20-28, 30-45) und
gemäß R(7, 8, 11, 12, 13)
Im Folgenden wird pro Klasse der ETL-Prozesse jeweils ein Anwendungsbeispiel
genauer untersucht. Dabei wird erneut auf die ADAPT-Notation zurückgegriffen, siehe
Legende in Abbildung 37.
Extraktion im M-BID-Service-PRS2ODS und M-BID-Einige-SAP2ODS
Dieser Prozess steht insbesondere am Anfang der Datenverarbeitung und hat die
Aufgabe, aus den Vorsystemen SAP und PRS die notwendigen Daten für das M-BID-
System zu importieren. Das geschieht mittels der SAP-XLS-Schnittstelle bzw. den
SQL-Abfragen an das PRS, siehe Kapitel 4.2.6. Dieser Extraktionsvorgang wird
zunächst konzeptuell mit Zuordnungsvorschriften (Mappings) beschrieben. In diesem
Kontext sind die zwei Mappings SAP2ODS und PRS2ODS relevant. In Formel 3 ist das
Mapping SAP2ODS aufgeführt, das zeigt welche Quelldaten aus der SAP-XLS
genommen werden und in welche Zieldaten sie überführt werden.
Dabei stellt die M-BID-Einige-SAP2ODS sicher, dass nur Daten übernommen werden,
die im M-BID noch nicht vorliegen, also nur die Monatsobjekte, die neuer sind als das
zuletzt eingelesene.
Kopfzeile ID ==> PRJ_ID_SAP
Kopfzeile Label ==> PRJ_ LABEL _SAP
Spaltenname Monatsobjekt ==> REV_STAND
"Total material costs" ==> MATSUB_K_IST
"Engineering costs" ==> STD_K_IST
"Transport & packing" ==> TRAPAC_K_IST
"Project management" ==> RU_K_IST
"Others" ==> SONST_K_IST
"HK-Zugang" ==> HK_IST (Kann auch errechnet werden)
"Rst.-Zugang" ==> HK_REST_IST (Kann auch errechnet werden)
"Umsatz HGB" ==> UM_IST
"Abgerechnete HK HGB" ==> HK_AB_IST
"** Summe AE-gesamt" ==> AE_IST
"** Summe AE-HK-gesamt" ==> HK_SOLL
"680516 LV Projektierung" ==> STD_IST
Formel 3: Mapping SAP2ODS
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 79
Bereinigung im M-BID-Service-PRS2ODS und M-BID-Einige-SAP2ODS
Der einzige Mechanismus aus dieser Transformationsklasse ist zunächst der, fehlende
Werte, die im weiteren Verlauf für die Berechnungen der Kennzahlen benötigt werden,
über die Systeminformationen (siehe Kapitel 4.2.6) zu reporten. Das führt in der Folge
zu dem Importstatus „nicht erfolgreich“, und die fehlenden Werte müssen vom M-BID-
Admin oder Power-User „online“ oder nach Möglichkeit in den Quellsystemen ergänzt
werden.
Harmonisierung im M-BID-Service-ODS2DWH
Diese Transformation muss insbesondere dort harmonisieren, wo im PRS und SAP
dieselben fachlichen Inhalte vorkommen aber unterschiedlich abgelegt sind und/oder
Werte redundant sind. Das ist u.a. im Folgenden der Fall:
Primärschlüssel der Projekte: PRJ_ID_SAP vs. PRJ_ID_PRS Eliminierung der
Schlüsseldisharmonien mittels der Zuordnungstabelle ODS_PRJ_ID_MAPPING in
Abbildung 36. Der M-BID-Service-ODS2DWH kann über dieses Mapping alle Daten
zu einem Projekt zusammenführen und in den Cubes des C-DWH ablegen. Die IDs
der Quellsysteme sind ab dann keine Schlüsselattribute mehr, sondern nur noch der
Primärschlüssel der Dimensionstabelle Dim_Projekt, siehe Abbildung 39. Die
ursprünglichen IDs werden noch rein informativ zur Anzeige in den Dashboards
verwendet.
Projektbeschreibung: PRJ_LABEL_SAP vs. PRJ_LABEL_PRS Bei der
Zusammenführung werden die beiden Beschreibungen verglichen und bei
Unterschied als Systeminformation reportet. Allerdings führt das nicht zu einem
ungültigen Import, da automatisch immer die Beschreibung aus dem PRS
übernommen wird. Ausnahme: Die Beschreibung ist im PRS nicht vorhanden, dann
wird diejenige aus dem SAP übernommen.
Bei redundanten Werten, wie z.B. HK_SOLL ist das SAP die alleingültige Quelle.
Sind diese Kennzahlen im SAP nicht vorhanden, muss die oben beschriebene
Bereinigung bereits einen Fehler „werfen“. Ansonsten werden die Kennzahlen
verglichen und ggf. als „ungleich“ reportet, damit die Werte im Sinne eines
„Verbesserungsmotors“ (siehe Kapitel 2.1.2, R4) im PRS korrigiert werden können.
Aggregation im M-BID-Service-DWH2DM
Die Aggregationen sind im OPLAP-System zentrale Funktionen, weshalb sie auch in
der ADAPT-Notation formalisiert dargestellt werden können. Die Abbildung 40 zeigt die
Aggregation über die Dimension Zeit mit den speziellen Transformationsvorschriften
auf jeder Dimensionsstufe.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 80
Zeit Zeit_Hierarchie
Jahr{ }
Quartal{ }
Monat{ }
{ } Q2
{ } Q1Q1+Q2+Q3+Q4
Summe(Monate)
Summe(Jahre)
{ } Q3
{ } Q3
Abbildung 40: Aggregation über die Dimension Zeit im DWH_CUBE_HK
Ähnliche Aggregationen sind auch über die anderen Dimensionen vorzusehen, sodass
die grundlegenden OLAP-Funktionen Drill-down und Roll-up aus Kapitel 2.3.2 realisiert
werden können.
Anreicherung im M-BID-Service-DWH2DM
Für die Darstellung der HK-Kennzahlen in einem Dashboard wird eine Reihe von
Berechnungen benötigt um die Dashboard-Anzeigen zu steuern.
Szenario
{ } IST
{ } SOLL
{ } PROGN_END
{ } PROGN_GJ
{ } AB_IST
Dash_Element
DM_DASH_HK
Dash_Element
Projekt
Zeit
Szenario
Detail
DWH_CUBE_HK
{ } BEREICH_GRUEN
{ } BEREICH_GELB
{ } NADEL_GROSS
{ } NADEL_KLEIN
{ } BEREICH_ORANGE
{ } BEREICH_ROT
Projekt
Zeit
Szenario
DWH_CUBE_AE
HK_SOLL - HK_PROGN_END
AE_IST - HK_SOLL
Details
Detail_Hierarchie
HK{ }
Abbildung 41: Anreicherungen für das HK-Dashboard im DM_DASH_HK
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 81
Da im DM die grundlegenden Werte für ein Dashboard statisch vorgehalten werden,
müssen die Berechnungen vorab erfolgen und im DM im Sinne einer Anreicherung
abgelegt werden. In Abbildung 41 wird die Transformation des M-BID-Service-
DWH2DM dargestellt, die aus den normalisierten Daten im C-DWH die speziellen
Daten im DM für das HK-Dashboards (DM_DASH_HK) generiert. Exemplarisch
werden die Werte DIF_HK_SOLL_HK_PROGN_END und DIF_AE_IST_HK_SOLL aus
der Formel 2 (Kapitel 4.2.7) berechnet, die dann in den Stufenelementen
BEREICH_ORANGE bzw. BEREICH_ROT abgelegt werden. Von dort können sie
direkt vom M-BID-Service-ProfitCenterSWE für die Visualisierung des HK-Dashboards
verwendet werden.
4.2.10 Programmablauf im M-BID-System
Einer der letzten Schritte in der Konzeption ist das Skizzieren der Programmabläufe im
Zielsystem. Mit Hilfe einer weiteren UML-Notation, dem Sequenzdiagramm, werden im
Folgenden zwei Anwendungsfälle exemplarisch dargestellt. Dabei wird auf eine
vollständige Notation der Programmschritte zugunsten einer besseren Übersicht
verzichtet.
Lösungsansätze L10 für alle Anforderungen gemäß R(1-6, 9, 10-15, 18)
Die erste Sequenz in Abbildung 42 ergibt sich aus dem Use-Case "Projekte/Review" in
Kapitel 4.2.4., Abbildung 35:
Das initiale Ereignis (Event) ist das Klicken des Nutzers auf ein konkretes ProjektXY
im Projekte-Cockpit, siehe dazu auch den Entwurf der Oberfläche in Kapitel 4.2.11,
Abbildung 44. Diese Nutzer-Aktion findet im M-BID-Frontend statt, also auf der
Clientseite des M-BID-Systems.
Das Frontend löst über das Internet oder Intranet eine Anforderung an die M-BID-
Engine-ProfitCenterSWE aus, die in der Sequenz mit dem Funktionsaufruf
"displayCockpit(ProjektXY)" bezeichnet ist140. Der CockpitCreator wird "beauftragt"
und baut nun das gewünschte Cockpit zusammen, u.a. benötigt er dazu die
notwendigen Dashboards.
140 Die Funktionsnamen sind konzeptueller Natur und können bei der Umsetzung abweichen.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 82
Hierfür wird der DashboardCreator aufgerufen, der u.a. das HK-Dashboard erstellt.
Er braucht hierfür die relevanten Kennzahlen und die passenden Botschaften aus
dem DM.
Die Informationen zu den Dashboards werden letztlich dem DM entnommen, das
über einen "Verwalter", dem DM-Handler, angesprochen wird.
Alle Funktionen liefern auf dem Rückweg (return) ihre Ergebnisse den aufrufenden
Funktionen zurück, sodass das Projekte-Cockpit für das ProjektXY schließlich dem
Nutzer angezeigt wird.
Nutzer M-BID-Frontend Engine-ProfitCenterSWE DashboradCreator DM-Handler
ProjektXY angeklickt displayCockpit(ProjektXY)
CockpitCreator
createDashboard(HK)createCockpit(ProjektXY) getValues(DASH_HK)
return Dash-Elelements
getMessages(DASH_HK)
return Dash-Messagesreturn HK-Dashb.return XY-Cockpit
(next Dashboard)
return HTML-SeiteXY-Cockpit anzeigen
Abbildung 42: Sequenz zum Use-Case „ProjektXY anzeigen“
Der zweite Use-Case wird in Abbildung 43 genauer betrachtet. Er wurde bereits in
Kapitel 4.2.6 beschrieben und wird immer dann ausgelöst, wenn neue Botschaften
verfasst und gesendet werden:
Das auslösende Ereignis ist das Klicken des Pfeils "edit" in einem Dashboard, siehe
Oberflächenentwurf in Abbildung 44.
Die Anforderung wird über das Netz an die M-BID-Engine-ProfitCenterSWE
gesendet.
Der DWH-Handler wird nun beauftragt, die gesendete Botschaft in das C-DWH
einzutragen.
Danach stößt die Engine eine Transformation vom C-DWH zum DM an.
Der entsprechende Service besorgt sich die notwendigen Daten aus dem C-DWH.
Der DM-Handler schreibt die Daten schließlich in das DM.
Nun sind die Daten zwar im DM, aber der Nutzer sieht die neue Botschaft noch
nicht. Dazu stößt die Engine selber nochmals die o.g. Funktion
"displayCockpit(ProjektXY)" (siehe roter Pfeil) an.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 83
In der Folge werden die Informationen im Dashboard aktualisiert und dem Nutzer
angezeigt. 141
Nutzer M-BID-Frontend Engine-ProfitCenterSWE DWH-Handler Service-DHW2DM DM-Handler
Botschaft senden sendDashMessage(Text) setMessage(Text, DASH_HK)
createDM(Projekte)
getCubeVal(HK, P, Z, D, S)
getMessages(Key)
return HK-Werte
write(DASH_HK)return Dash-Messages
return Status
return Statusreturn Status
return HTML-SeiteXY-Cockpit anzeigen displayCockpit(ProjektXY)
Abbildung 43: Sequenz zum Use-Case „Dashboard-Botschaft senden“
4.2.11 Oberflächenentwurf mit Dashboards
Zur „Halbzeit“ wurde in Kapitel 4.2.5 eine erste Skizze der Oberflächen mit dem GUI-
Mockup hergestellt. Nachdem nun die Konzeption die Anforderung an das M-BID von
allen Seiten beleuchtet hat, kann ein detaillierter Entwurf die erste Umsetzung
vorbereiten. Im Gegensatz zu langen textuellen Spezifikationen, können Entwickler und
Nutzer mit dem GUI-Entwurf sehr schnell erkennen, ob das System grundsätzlich
geeignet ist und die Bedienoberflächen praktikabel und ansprechend sind.
Lösungsansätze L10 für A(1, 3-9, 13-34, 36-45) gemäß R(1, 2, 4, 9, 10, 13, 14, 15,
18)
Für die erste Umsetzung ist laut A18 das Client-seitige M-BID-Frontend mit seinen
Hauptbestandteilen Portal, Cockpits und Dashboards gemäß R18 zu entwerfen, siehe
auch Kapitel 4.2.6.
141 Die prinzipiell dargestellte Sequenz wird noch nicht optimal sein, da das Aktualisieren nur der
Botschaften i.d.R. keine vollständige Transformation ins DM benötigt. Wenn doch, sollte sie in einem
eigenen Parallelprozess (Thread) stattfinden, sonst muss der Nutzer zu lange auf eine Reaktion warten.
4.2 Konzeption und Lösungsansätze
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 84
Abbildung 44 zeigt hierzu den ersten Entwurf. Die wichtigsten Aspekte der Konzeption
finden sich darin wieder:
Das M-BID-Frontend hat als Systemgrundlage den Internet Explorer und ist damit
eine mobile Client-Server-Anwendung für das Web-Reporting, siehe u.a. A3, R15,
auch Kapitel 4.2.6.
Export SucheM-BID-PortalNutzer Links SystemDrucken ?
Projekte
Projekt 1
Projekt 2
Projekt 3
Projekt 4
ProjektXY
Projekt 7
Projekt 8
Projekt 9
Projekt 10
ProfitCenter SWE Projekte ProjektXY
Herstellungskosten (HK)
Lorem ipsum dolor sit amet, consetetur sadipscing
elitr.15.08.2013, umi.
Sed diam nonumy eirmod tempor invidunt ut labore
et dolore magna aliquyam erat, sed diam voluptua.
02.08.2013, umi.
In vulputate velit esse! 01.08.2013, umi.
HK im grünen Bereich. Mehr STD nötig. 15.08.2013, umi.
Projektstunden (STD)
Tet clita kasd gubergren, no sea takimata volkus
est. 15.08.2013, umi.
Onsectetuer in temporare fluktus adipiscing elit,
more
change
more
change
edit
explain
ProjektXY edit
edit
back
Abbildung 44: Oberflächenentwurf M-BID-Portal mit Projekte-Cockpit
Am oberen Bildrand befindet sich ein „statischer Bereich“ mit einer Funktionsleiste,
die sich aus den Anforderungen und Use-Cases ergibt. Ferner bleiben die „bread-
crumbs” als Navigation im M-BID-Portal permanent erhalten, siehe Kapitel 4.2.8 und
das GUI-Mockup in Kapitel 4.2.5. Der Pfeil „back“ führt immer zu der nächsthöheren
Darstellungsebene des Portals zurück; hier wäre das die Ebene „Projekte des
Profitcenters SWE mit den entsprechenden Botschaften“, siehe Use-Cases in
Kapitel 4.2.4.
Am linken Bildrand befindet sich die „Cockpit-Steuerung“. Im vorliegenden Fall ist
das die Auswahl der möglichen Projekte des Profitcenters.
Mit der Auswahl von ProjektXY werden die Dashboards im Hauptteil des Cockpits
entsprechend befüllt. Die Dashboards sind mit einer Grau-Weiß-Abfolge klar
4.3 Ergebnis der Konzeption
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 85
voneinander getrennt. Ein Cockpit kann somit generisch, je nach Bedarf und
Anforderung, mit Dashboards erweitert werden.
Ein Dashboard besteht (maximal) aus den folgenden Bereichen:
o Überschrift mit „Stimmungsbarometer“, ein Pfeil im Kreis, der durch Richtung und
Hintergrundfarbe anzeigt, wie es im zugehörigen Bereich tendenziell aussieht.
o Botschaften des Bereiches, die mit Datum und Autorkürzel angezeigt werden; die
neuste Botschaft zuoberst. Als kompaktes Ergebnisprotokoll der Reviews werden
maximal drei Botschaften mit je drei Zeilen zugelassen. Weitere (textuelle)
Details können ggf. über „Links“ in der Funktionsleiste oder direkt über „more“
gefunden werden.
o Der Funktionsbereich mit mehreren Pfeilen für erweiterte Funktionalitäten:
„more“ führt zur nächsten Detaillierungsstufe; im Falle des HK-Dashboards
(A19) zu HK-Details (A22) mit einer tabellarischen Aufführung aller HK-
Bestandteile laut Formel 1.
„change“ ermöglicht Änderungen an der Anzeige, z.B. die Auswahl eines
anderen Zeitraums bzw. Zeitpunkts der Berechnung oder Betrachtung.
„edit“ ermöglicht das Verfassen und Senden von neuen Botschaften. Ferner
können alte Botschaften aus der Anzeige entfernt werden. Sie bleiben im C-
DWH erhalten, werden aber nicht mehr bei der Transformation in das DM
übernommen.
„explain“ zeigt die Metainformationen zu einem Dashboard und seinen
Kennzahlen an. Insbesondere die Kennzahlenbeschreibung aus der Tabelle 1,
ferner die Daten-Vita und die Systeminformationen aus Kapitel 4.2.6 und
4.2.8.
4.3 Ergebnis der Konzeption
Das Ergebnis der Konzeption ist ein Entwurf des M-BID-Systems auf allen Ebenen,
also die sichtbaren Oberflächen des Frontend (Kapitel 4.2.5 und 4.2.11) und der nicht-
sichtbare Systemteil des „Backend“. Dabei ist wichtig, dass auch ein geeigneter
Arbeitsrahmen (M-BID-Framework, siehe Kapitel 4.2.6) für künftig Erweiterungen
vorgegeben wurde.
Das zentrale „Werkzeug“ in der Konzeption waren die Konzeptionsdokumente bzw.
deren grafischen Notationen (Abbildung 27 bis Abbildung 44), die i.d.R. fließend in die
entsprechenden Umsetzungsdokumente übergehen.
Mit diesem „Rüstzeug“ kann die Realisierung des M-BID begonnen werden, siehe
folgendes Kapitel.
5.1 Einleitung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 86
5 Realisierung des M-BID-Systems
5.1 Einleitung
Die folgenden Aktivitäten sollen die Konzeption und die Lösungsansätze aus Kapitel
4.2 einer ersten Umsetzung zuführen. Dabei liegt der Schwerpunkt mehr auf den
(sichtbaren) Ergebnissen des technischen und fachlichen Prototyps und weniger auf
den vielen softwaretechnischen Anforderungen, die auf der Programmier-Ebene
relevant werden. Auch die Hardware-nahen und Laufzeit-spezifischen Anforderungen
werden nur erwähnt, aber nicht vertieft. Das Kapitel kann somit vergleichsweise kurz
gefasst werden, da es für die prinzipiellen Entwicklungsaspekte des M-BID nur noch
wenig Mehrwert bringt.
5.2 Technischer Prototyp
5.2.1 Erster Testlauf
Um die grundsätzliche technische Machbarkeit des Konzeptes zu überprüfen, wurde
zunächst mit „einfachen Mitteln“ das System in groben Teilen aufgebaut.
Danach wurde mit dem „technischen Prototyp“ ein erster Versuchslauf durchgeführt,
der die folgende Sequenz beherrschen sollte, siehe auch Abbildung 45:
Eine Zahl (z.B. 4712,00) wird vom M-BID-Service-PRS2ODS aus dem PRS mittels
SQL ausgelesen. Der Service simuliert eine Transformation (Bereinigung) indem er
das Zahlenformat modifiziert (4712,00 4712), danach wird der Wert in den ODS
geschrieben.
Der Service ODS2DWH simuliert eine Harmonisierung (4712 4711) und schreibt
das Ergebnis in das C-DWH.
Der Service DWH2DM simuliert eine Anreicherung durch Addition von 1000 und
schreibt das Ergebnis (5711) in das DM.
Die Engine ProfitCenterSWE bekommt über das M-BID-Frontend eine Nutzer-
Anforderung. Daraufhin wird der Wert aus dem DM mit einer einfachen Grafik und
einer Test-Botschaft kombiniert.
Diese simulierte Dashboard-Anzeige soll schließlich vom M-BID-Frontend im IE-
Browser angezeigt werden.
Ein zweiter Testlauf soll mit einer leicht veränderten Zahl (z.B. 1815,00) die
Aktualisierung im System ausprobieren.
5.2 Technischer Prototyp
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 87
4712,004712
5711
Dies ist eine
Test-Botschaft
Ganzzahl(4711,00)
M-BID-Service
„PRS2ODS“
ETL: Filterung PRS
C-DWH
ODS
DM
M-BID-Service
„ODS2DWH“
ETL:
Harmonisierung
M-BID-Engine
„ProfitCenterSWE“
Web-Visualisierung
M-BID-Service
„DWH2DM“
ETL: Aggregation
und Anreicherung
5711 + 1000
5711
Dies ist eineTest-Botschaft
4711
Abbildung 45: Versuchsablauf für den technischen Prototyp
Abbildung 46 zeigt die Ausgabe des technischen Prototyps im Frontend. Damit konnte
gezeigt werden, das das M-BID-System nach den Lösungsansätzen (v.a. L6)
grundsätzlich funktioniert, also die technische Machbarkeit gegeben ist.
Abbildung 46: Ausgabe des technischen Prototyps
5.2.2 Weiteres Vorgehen
Nach dem „Probelauf“ konnte mit der Umsetzung der fachlichen Anforderungen
begonnen werden. Dazu wurde es nötig, die Systemkomponenten aus L6 für einen
„fachlichen Prototyp“ zu entwickeln. Das Etappenziel lautete demnach: Entwicklung
des M-BID mithilfe der Lösungsansätze L1-L10, um ein Projekte-Cockpit mit HK- und
STD-Dashboard ansatzweise zu realisieren. Dabei sollte bereits der Grundaufbau des
M-BID-Portals aus L11 strukturell realisiert und die Hauptelemente erkennbar sein. Die
Umsetzung des fachlichen Prototyps wird im folgenden Kapitel genauer beschrieben.
5.3 Fachlicher Prototyp
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 88
5.3 Fachlicher Prototyp
5.3.1 Systemspezifikation mit Hard- und Software
Das M-BID wurde gemäß L6 mit den folgenden Systemkomponenten realisiert.
System-Hardware:
M-BID-Server: Server-Rechner von Dell mit RAID5-System zur Datensicherung
M-BID-Client:
o Arbeitsplatzrechner, Dell-Workstation
o Laptop von Dell
System-Software:
M-BID-Backend:
o Betriebssystem: MS Windows 7 Professional - 64 Bit
o Datenbankmanagementsystem: MS-SQL Server 2012
o Add-on für OLAP: Analysis-Services für MS-SQL 2012 142
o Web-Server: MS IIS 7.5 (Microsoft Internet Information Services)
M-BID-Frontend:
o Betriebssystem: MS Windows 7 Professional - 64 Bit
o Web-Browser: MS Windows Internet Explorer (IE), Version 9.0
Entwicklungsumgebung:
Technologie: ASP.NET mit MS VisualStudio 2012143
Zusätzliche API: „DotNetCharting“ als grafische Toolbox, die im ASP.NET-Kontext
weitere C#-Klassen für die Darstellung der Dashboard-Anzeigen (z.B. Tachometer)
zur Verfügung stellt.144
5.3.2 Klassenstruktur im Programmcode
Die grundsätzliche Struktur im Quellcode ist innerhalb von ASP.NET für die Client-
Server-Architektur optimiert, siehe Abbildung 47. Folgender Programmaufbau wird
damit realisiert:
C#-Klassen
*.aspx.cs
WebForms
*.aspx
HTLM-Seiten
*.aspx
Client Server
Abbildung 47: Zusammenhang der Quelldateien im ASP.NET-Kontext
142 siehe [Microsoft, 2013 a]
143 siehe [Schwichtenberg, 2013]
144 siehe [Corporate Web Solutions Ltd., 2013]
5.3 Fachlicher Prototyp
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 89
Der Client-seitige HTML-Code wird auf Anforderung des Nutzers über das Netz in
den Browser geladen und führt zur Darstellung der gewünschten Seiten im M-BID-
Frontend. Im Code-Fragment der Formel 4 ist (in rot) zu sehen, wie das Bild einer
Dashboard-Anzeige (chartSteam.jpg) in die HTML-Seite eingebunden wird.
Damit dieses Bild angezeigt werden kann, muss es zuvor erzeugt und im
angegebenen Ordner (…/temp) Client-seitig abgelegt werden. Diese Anforderung
wird mit Aufruf dieser Seite an den M-BID-Server übermittelt.
<!DOCTYPE html>
…
style="height:300px;width:300px;border-width:0px;" />
</p>
<p>
NewChart:
<img src="temp/chartStream.jpg"></img>
</p>
…
Formel 4: HTML-Seite für das M-BID-Frontend
Server-seitig werden die Anforderungen vom Frontend mithilfe sogenannter
WebForms für die Darstellung realisiert. Dazu werden in einer Art Hybrid-Code die
HTML-Tags mit Quellcode von C# kombiniert. Die Funktionsaufrufe sind in
speziellen Tags <%...%> untergebracht und werden zur Laufzeit vom Server
ausgewertet. Dabei greift die WebForm auf eine Klassen-Bibliothek zurück, die im
Kopf der WebForm hinter „CodeBhind“ angegeben ist, siehe Formel 5. In diesem
Beispiel wird die Methode „DisplayChart();” aufgerufen, die in der Library
„WebForm1.aspx.cs“ zu finden ist.
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs"
Inherits="WebApplication2.WebForm1" %>
…
<p>
NewChart:
<% DisplayChart(); %>
</p>
…
Formel 5: WebForm für das M-BID-Frontend
Die o.g. Bibliotheken oder Libraries stellen auf der Ebenen der Fachlichkeit alle C#
Klassen mit den notwendigen Eigenschaften und Funktionen zur Verfügung. Die
Programm- bzw. Klassenstruktur ist dabei nach den Vorgaben der OO-Modellierung
zu gestalten, siehe Kapitel 2.2.3, R8.
In Formel 6 wird ein Ausschnitt der Funktion „DisplayChart()“ gezeigt, die als
Rückgabe eine Funktion „Response.Write“ anstößt. Hierdurch wird der
Funktionsaufruf in der WebForm zur Laufzeit durch den String ersetzt, der in der
HTML-Seite schließlich das Bild „chartSteam.jpg“ einbindet.
5.3 Fachlicher Prototyp
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 90
protected void DisplayChart()
{
…
if (fi.Extension != ".swf")
{
Response.Write("<img src=\"" + filePath + "\"></img>");
}
…
Formel 6: C# Klassen für das M-BID-Frontend
Der Browser stellt schließlich die Webseite mit dem „NewChart“ (das erste Test-
Tachometer) im M-BID-Frontend dar, siehe Abbildung 48.
Abbildung 48: Anzeige des ersten Test-Tachometers145
5.3.3 Prototyp-Version des M-BID
Für den technischen und insbesondere fachlichen Prototyp gab und gibt es mehrere
Handlungsebenen:
Einrichten und Konfigurieren der Systemkomponenten durch die IT-Fachkräfte nach
den Vorgaben aus Kapitel 5.3.1 und L6.
Einrichten der Entwicklungsumgebung im MS-Visual-Studio für ein neues
Entwicklungsprojekt durch die SW-Entwickler; u.a. Erstellen und Konfigurieren
neuer Projektmappen, sowie der Aufbau eines „Klassengerüstes“ im Sinne der OO-
Modellierung und gemäß den Vorgaben aus L8 und L9.
Konfigurieren und Implementieren der Komponenten zur Datenhaltung, also ODS,
C-DWH und DM gemäß L6 und L8.
Implementieren des „M-BID-Backend“, also alle Funktionen gemäß L(4, 7, 9, 10,11)
in den M-BID-Services und Engines laut L6.
Implementieren des M-BID-Frontend in der M-BID-Engine-ProfitCenterSWE laut L6
auf der Ebene der WebForms aus Kapitel 5.3.2.
Wie in der Praxis üblich, werden die Aktivitäten auf verschiedene Fachkräfte aufgeteilt.
Dafür wird eine „Implementierungsgrenze“ zwischen Backend und Frontend gezogen.
145 realisiert mit der Test-Version von DotNetCharting.com, daher ein Hinweis in der Grafik (Logo) , siehe
[Corporate Web Solutions Ltd., 2013]
5.3 Fachlicher Prototyp
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 91
Zudem wird eine Grenze zwischen den fachlichen Funktionen und den Funktionen für
die Datenhaltung bzw. Datenorganisation gezogen.
Das ermöglicht die Entkopplung der programmatischen Ebenen nach dem „Model-
View-Control-Prinzip“146, also die Trennung via Programmschnittstellen von
Model: Zugriff auf die Daten über die Datenbanksysteme
View: Darstellung auf der Oberfläche
Control: Fachliche Verarbeitung im Systemkern
Diese Entkopplung spiegelt sich deutlich in der Klassenstruktur der Ebenen wider,
siehe auch Kapitel 5.3.2. Dabei ist stets die Prämisse, dass man eine Ebene
technologisch austauschen könnte (z.B. ein anderes Datenbanksystem ans M-BID
anbinden) ohne einen Eingriff in einer andere Ebene (z.B. Anpassen der ETL-
Funktionen) vornehmen zu müssen.
Auch zwischen dem Backend und Frontend des M-BID ist diese Trennung wichtig,
damit auf den Client-Rechnern keine fachlichen (betriebswirtschaftlichen) Funktionen
ausgeführt werden, sondern nur solche, die für die Darstellung relevant sind. Das
ermöglicht eine hohe Kompatibilität mit den Frontend-Browsern und den Schutz vor
unberechtigtem Zugriff auf die fachliche Realisierung.
Als Zwischenergebnis wurden die Dashboard-Anzeigen gemäß L7 realisiert.
Mit Hilfe der Entwicklungsversion von DotNetCharting (siehe Kapitel 5.3.1) entstand
eine Implementierung recht nah am Entwurf, vergleiche L7 bzw. L11. Als Besonderheit
musste hierbei eine Dynamik in die Tachometer eingebaut werden, für den Fall, dass
z.B. die Gesamtprognose über dem Auftragseingang liegt. Für solche kritischen
Projekte rutschen die farbigen Bereichsbalken nach hinten mit, sodass die farbliche
Zuordnung zu den Kennzahlen erhalten bleibt. So erkennt der Betrachter auf einen
Blick, dass dieses Projekt in „Schieflage“ geraten ist, siehe Abbildung 49.
Abbildung 49: HK-Dashboard für eine guten und einen kritischen Projektstand
146 vgl. [Wikipedia, 2013 b]
5.3 Fachlicher Prototyp
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 92
Abbildung 50 zeigt schließlich den Screenshot des M-BID-Portals in der ersten Version
gemäß dem Entwurf aus L11. Zu erkennen ist der in Kapitel 4.2.11 beschriebene
Grundaufbau. Dabei wurde jeder Bereich als eigene „HTML-Division“ (div) realisiert,
um eine unabhängige optische Gestaltung mit den CSS (siehe Kapitel 4.2.6, L6) zu
ermöglichen. Ferner wird dadurch das Aktualisieren der Bereiche auf der Ebene des
Browsers entkoppelt und die Ladevorgänge können unabhängig voneinander
durchgeführt werden. Damit wird z.B. nur das HK-Dashboard aktualisiert (und nicht die
ganze Webseite), wenn eine neue Botschaft verfasst und gesendet wurde, siehe
entsprechende Sequenz in Kapitel 4.2.10.
Abbildung 50: Screenshot vom fachlichen Prototyp des M-BID-Portals
6.1 Ergebnisse und Schlussbewertung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 93
6 Zusammenfassung
6.1 Ergebnisse und Schlussbewertung
Die Ergebnisse der vorliegenden Arbeit werden im Folgenden tabellarisch dargestellt.
Dabei wird den (eingekürzten) Formulierungen der Ziele aus Kapitel 1.2 jeweils eine
zusammenfassende Bewertung bzw. Beschreibung gegenübergestellt, die den Grad
der Zielerfüllung und die weiteren Perspektiven darstellt.
Nr. Primärziele nach Kapitel 1.2 Zusammenfassende Bewertung
1 Entwicklung eines lauffähigen M-BID-System als „Kontrollmonitor“ für die Kennzahlen der Abteilung „Softwareentwicklung“ (SWE) der IVV GmbH.
Durch die vorliegende Arbeit wurde der Weg zu diesem generellen Ziel konzeptuell und systematisch vorgezeichnet. Die Prototyen haben gezeigt, dass die Lösungsansätze aus Kapitel 4.2 grundsätzlich relevant und valide sind.
2 Das M-BID soll v.a. die erweiterten Anforderungen an das Controlling der SWE unterstützen, seit die Abteilung ein eigenes Profitcenter geworden ist und die Anzahl der Mitarbeiter deutlich anstieg.
Konzeptuell ist dieses Ziel eingebracht worden. Wie sich das M-BID in der Praxis erweisen wird, ist Gegenstand einer kontinuierlichen Kontrolle im Sinne des "Verbesserungsmotors" aus Kapitel 2.1.2
3 Das M-BID soll dazu beitragen, den finanziellen und organisatorischen Überblick bei der SWE zu behalten.
V.a. die Anforderung "Überblick" war eines der Leitmotive bei der Konzeption, weshalb die Verdichtung und Visualisierung auch ein zentraler Aspekt in BI-Systemen allgemein und im M-BID im Besonderen ist.
4 Das M-BID muss strukturierte und unstrukturierte Probleme und Prozesse erfassen und darstellen können..
Die Systemkomponenten, Use-Cases und Cockpit-Funktionen sind entsprechend ausgelegt worden, dass sowohl Kennzahlen strukturiert verarbeitet werden, als auch der Zugriff auf unstrukturierte Daten z.B. aus den Projektordnern möglich ist. Das wichtige Bindeglied sind dabei die Botschaften auf den verschiedenen Ebenen im M-BID-Portal
5 Das M-BID muss die notwendigen Kennzahlen liefern, sie geeignet darstellen und aufzeigen, wo es kritische Abweichungen gibt.
Mit dem fachlichen Prototyp ist eine erste Umsetzung in diese Richtung erfolgt. Die Tachometer in den Dashboards für HK und STD zeigen bereits anschaulich, wie es um ein Projekt bestellt ist.
6 Das M-BID soll bei den monatlichen Projektreviews und den täglichen Team-Meetings eingesetzt werden und auf die wichtigsten operativen und taktischen Fragen schnelle und zuverlässige Antworten bereithalten.
Über den künftigen praktischen Einsatz wird das M-BID im Sinne einer "agilen Entwicklung" ausgebaut und kontinuierlich verbessert. Somit wird mit dem M-BID die bisherige Strategie in der SWE-Abteilung fortgesetzt, mit Hilfe von individuellen IT-Tools auch die Arbeitsprozesse zu definieren und zu optimieren.
7 Das M-BID soll für die Quartalsreviews mit der Geschäftsführung die notwendigen verdichteten Kennzahlen liefern, die auch bei der Abschätzung bzw. Prognose für das laufende Jahr (Forecast) und das kommende Jahr (Budget) betrachtet werden. Das M-BID soll somit auch bei strategischen Entscheidungen mithelfen, da es künftige Trends erkennen lässt, aus denen sich Chancen und Risiken ergeben könnten.
Diese Zielfunktion gilt es mit dem M-BID zu erreichen. Dafür wurden konzeptuell die Grundlagen gelegt, die v.a. mit den Dashboards ein leistungsfähiges Framework darstellen. Eine der nächsten Umsetzungen wird hierbei das Budget-Forecast-Cockpit aus den Use-Case in Kapitel 4.2.4 sein, das als Hilfsmittel bei den Quartalsreviews dienen soll.
8 Das M-BID soll im Sinne eines BI-Systems alle zur Auswertung benötigten Daten aus den operativen Systemen sammeln und zusammenführen.
Die derzeitigen Quellen des M-BID (PRS und SAP) wurden schon "angebohrt". Im Laufe des Einsatzes kommen ggf. noch weitere Datenquellen (z.B. externe Daten) dazu.
9 Das M-BID soll im Rahmen dieser Arbeit (und auch künftig) nicht als „fix-und-fertiges“ System umgesetzt werden, sondern als Arbeitsrahmen (Framework), der die Voraussetzung schafft, die relevanten Anforderungen schrittweise und flexibel (agil) umzusetzen.
Das M-BID-Framework ist in Kapitel 4.2.6 definiert worden und ging in die Konzeption der Systemkomponenten mit ein. Noch ist nicht vollständig abzusehen, wie geeignet die Ansätze sein werden. Aber auch das Framework darf durchaus Teil des dynamischen Entwicklungsprozesses sein.
6.2 Kritische Würdigung
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 94
10 Im M-BID-Framework werden die notwendigen technologischen Grundlagen gelegt und anhand von ersten Anwendungsbeispielen „ausprobiert“. Diese Anwendungsbeispiele, wie v.a. eine Tachometeranzeige für die Darstellung der Herstellungskosten, sollen die Hauptprinzipien eines BI-Systems nutzen und deren Umsetzung im M-BID validieren und dokumentieren. Dazu wird das Thema BI genau beleuchtet und Beiträge aus der Wissenschaft und der Praxis ausgewertet. Mit der Gegenüberstellung von IST und SOLL wird dann ein Konzept für die Umsetzung gefunden.
Diese Ziele drücken den "Auftrag" kompakt aus, der im Rahmen der vorliegenden Arbeit im Wesentlichen bearbeitet wurde. In den Kapiteln 2 bis 5 wurden die relevanten Aspekte entsprechend beleuchtet, konzipiert, realisiert und dargestellt.
Sekundärziele nach Kapitel 1.2
11 Der Blick auf die Prinzipien und Techniken einer verwandten Systemklasse soll zu anwendbarem Wissen für die anstehende Umstellung des ProSig-Datenbanksystems führen. Insbesondere die Methoden beim Realisieren eines Data-Warehouse (DWH) scheinen hierfür geeignet.
Die ersten Gespräche mit Teamkollegen zu BI- bzw. M-BID-Themen haben bereits zu guten Ansätzen für die notwendige Migration geführt, die wahrscheinlich ohne die vorliegende Arbeit nicht so schnell entwickelt worden wären. Dabei steht auch der MS SQL-Server 2012 im Fokus.
12 Für die Umsetzung des M-BID werden eine IST-Analyse und eine SOLL-Konzeption benötigt, die auch zur Optimierung der Strukturen und Prozesse in der SWE führen können.
Wie im Kontext der "BI-Strategie" und in Ziel 6 erwähnt, soll es zwischen der Entwicklung des M-BID und der Entwicklung bzw. Optimierung der SWE-Prozesse eine direkte Synergie geben. Dieser Effekt ist z.T. bereits durch die vorliegende Arbeit eingetreten. Dass er auch weiterhin anhält, kann mit einiger Sicherheit angenommen werden. Ähnlich positive Erfahrungen wurden in der SWE-Abteilung bereits beim Aufbau des PRS ab 2005 gemacht.
13 Schließlich kann man sich das M-BID auch als BI-System der IVV vorstellen, was aber im Rahmen dieser Arbeit nur als Ausblick formuliert werden kann.
Dieses Ziel war zwar nicht mehr im Fokus der vorliegenden Arbeit, aber als ferne Perspektive war es eine wichtige Orientierungshilfe bei der Konzeption. Allein schon die Ausgestaltung des BI-Portals mit der obersten Navigationsebene "Profitcenter" in den bread-crumbs spiegelt diese Perspektive.
Tabelle 3: Zusammenfassende Bewertung der Ergebnisse
6.2 Kritische Würdigung
Allein die Theorie zum Thema „Business Intelligence“ ist sehr umfangreich und
komplex. Dadurch war es schwierig den Umfang im Theorieteil angemessen zu halten.
Wenn dann noch die Aufgabe dazukommt, so eine komplexe Theorie in die Praxis
umzusetzen, wird es i.d.R. nicht weniger komplex, sondern schnell auch
unübersichtlich.
Deshalb war es wichtig und gleichsam schwierig in den konzeptuellen Teilen (Kapitel 3
und 4) auf das Prinzipielle und Notwendige zu fokussieren, ohne die Grundlagen der
Umsetzung zu „bedrohen“. Denn eine Motivation des Autors war, das M-BID im
Rahmen der Diplomarbeit auf jeden Fall im ersten Entwurf und mindestens als
Framework umzusetzen, sonst wäre es bei der im Alltag anfallenden Arbeit in der
SWE-Abteilung wahrscheinlich bei einem „schönen“ Konzept geblieben. Deshalb sind
einige Details in der vorliegenden Arbeit umfangreicher abgebildet, als wenn das
Vorhaben erst mal nur theoretisch betrachtet worden wäre.
6.3 Aussichten
Diplomarbeit - Volker Uminski - 20.09.2013 - Mobile Business-Intelligence Dashboard (M-BID) 95
So aber wurde das M-BID bereits teilweise realisiert, und es ist erkennbar, dass es
hilfreich zum Einsatz kommen kann. Hier wirkt, wie bei den Kennzahlen, die „Macht
des Faktischen“ mehr als viele Pläne und gute Vorsätze.
6.3 Aussichten
Nach z.T. rasanten Entwicklungen der Technologien für BI-Systeme in den
vergangenen Jahrzehnten, ist sicher auch in den nächsten Jahren eine Weiter-
entwicklung der entsprechenden Hard- und Software zu erwarten. Ferner wird es auch
künftig immer wieder neue „Knowhow-Strömungen“ wie „Big Data“ (siehe Kapitel 2.2.1)
geben, die dazu beitragen BI-Systeme effizienter zu gestalten. Der aktuelle Trend, BI-
Systeme noch stärker an die individuellen Bedürfnisse der Nutzer anzupassen, hat sich
bereits durch umfangreiche APIs kommerzieller Systeme abgezeichnet und wird seit
einigen Jahren noch verstärkt durch frei zugängliche Systemlösungen innerhalb von
„Open Source BI“147.
Somit ist auch für das M-BID eine gewisse Dynamik zu erwarten, die entsprechende
Anpassungen nach sich ziehen wird. Daneben gibt es aber auch eine Reihe von
konkreten Perspektiven für das M-BID-System:
Abbildung weiterer Kennzahlen wie Deckungsbeiträge, Umsatz pro Kunde, etc.
Verfeinerte Betrachtung durch Dimensionen bzw. Verdichtungswege wie „Kunden“,
„Vertriebswege“, und „Produkte“. Bei Letzterem wäre die derzeitige Dimension
„Projekt“ nur eine von mehreren Hierarchien der Produkt-Dimension, siehe
Abbildung 55 im Anhang 6.
Entwickeln von weiteren Cockpits für die verschiedenen Arbeitsprozesse in der
SWE. Z.B. wird demnächst im Rahmen eines Studienpraktikums in der SWE-
Abteilung ein „Test-Cockpit“ zur Unterstützung der Prozesse bei Softwaretests
entwickelt. Der systematische Rahmen zur Umsetzung wird das M-BID-Framework
sein.
Ausbau des M-BID in Richtung „Data-Mining“, z.B. zur Unterstützung der
Aufwandsschätzung von komplexen Projekten durch Vergleich von bereits
umgesetzten Anforderungen aus der Projekthistorie mit den aktuellen
Anforderungen.
Schließlich die schon im Kapitel 1.2 erwähnte Perspektive, das M-BID auch als BI-
System der IVV zu etablieren, was sicherlich zu einem deutlichen Anstieg der
Anforderungen führen würde, aber aus der Sicht eines Business-Intelligence-
Systems eine reizvolle Aufgabe wäre.
147 spezielle Open-Source-Anwendungen im BI-Bereich, siehe [Gluchowski, 2009]
I
Literaturverzeichnis
Ambler, Scott W. 2003. Agile Database Techniques: Effective Strategies for the Agile
Software Developer. Indianapolis, USA : Wiley Publishing, Inc, 2003.
Arnold, Frank. 2010. Management - Von den Besten lernen. München : Carl Hanser
Verlag, 2010.
Bachmann, Roland und Kemper, Guido. 2011. Raus aus der BI-Falle. Wie Buniness
Intelligence zum Erfolg wird. 2. Auflage. Heidelber, u.a. : Verlagsgruppe Hüthig Jehle
Rehm GmbH, 2011.
Baumöl, Ulrike. 1999. Target Costing bei der Softwareentwicklung. München : Verlag
Vahlen, 1999.
Corporate Web Solutions Ltd. 2013. DotNetCharting. [Online] 2013. [Zitat vom: 03.
09 2013.] http://www.dotnetcharting.com/.
Duda, R. und Shortliffe, E. 1983. Expert Research Sience. 1983. zitiert in [Puppe,
1988, S.7].
Feyhl, Achim W. 2004. Management und Controlling von Softwareprojekten.
Wiesbaden : Gabler Verlag, 2004.
Fiedler, Rudolf. 2010. Controlling von Projekten. 5. erweiterte Auflage. Wiesbaden :
Vieweg + Teubner, 2010.
Gansor, Tom, Totok, Andreas und Stock, Steffen. 2010. Von der Strategie zum
Business Intelligence Competency Center (BICC). München, Wien : Carl Hanser
Verlag, 2010.
Geiss, Olaf. 2012. Herausforderung Mobile BI - Integration in bestehende BI-
Landschaften. [Hrsg.] Peter Gluchowski. BI-Spektrum. 2012, 01-2012, S. 6-9.
Gluchowski, Peter. 2009. Beitrag zum Workshop Open Source Business Intelligence
2009. [Online] 24. 09 2009. [Zitat vom: 10. 09 2013.] http://www.osbi-
workshop.de/2009/presentation/07_Gluchowski_Open_Source_Business_Intelligence.
pdf.
Gluchowski, Peter, Gabriel, Roland und Dittmar, Carsten. 2008. Management
Support Systeme und Business Itelligence. Berlin, Heidelberg : Springer-Verlag, 2008.
Hanschke, Inge, Giesinger, Gunnar und Goetze, Daniel. 2013. Business-Analyse -
einfach und effektiv: Geschäftsanforderungen verstehen und in IT-Lösungen umsetzen.
München : Carl Hanser Verlag, 2013.
Inmon, W.H. 2005. Building the Data Warehouse, 4.Auflage. New York : s.n., 2005.
zitiert in [Kemper, et al., 2010 S. 19].
II
IVV - ProSig. 2013. ProSig® bei der Deutschen Bahn AG. [Online] 2013. [Zitat vom:
04. 09 2013.] http://www.ivv-gmbh.de/de/prosigr/referenzen/prosigr-bei-der-deutschen-
bahn-ag.html.
Kemper, Hans-Georg, Baars, Henning und Mehanna, Walid. 2010. Business
Intelligence - Grundlagen und praktische Anwendungen. 3. überarbeitete und
erweiterte Auflage. Wiesbaden : Vieweg + Teubner, 2010.
Klein, Andreas, [Hrsg.]. 2012. Reporting und Business Intelligence. Freiburg, Berlin,
München : Haufe Gruppe, 2012.
Köppen, Veit, Saake, Gunter und Kai-Uwe, Sattler. 2012. Data Warehouse
Technologien. Heidelberg, u.a. : mitp-Verlag, 2012.
Leipert, Ralph. 2013a. Business Intelligence Wissensportal. Business Intelligence als
Integrationsplattform. [Online] 2013a. [Zitat vom: 09. 07 2013.] http://www.business-
intelligence24.com/business-intelligence-definition/business-intelligence-
integrationsplattform.
Mandorf, Susanna. 2008. Einführung in Exertensysteme - Beitrag zur Gundlage des
Kowledge Engineering. München, Ravensburg : GRIN Verlag, 2008.
Maschek, Ulrich. 2001. Datenmodell zur Planung von LST-Anlagen. [Online] 2001.
[Zitat vom: 09. 02 2013.] http://tu-
dresden.de/Members/ulrich.maschek/dateien/U_Maschek-
Datenmod_Planung_Stw.pdf.
Maschek, Ulrich, et al. 2012. PlanPro - Durchgängige eletronische Datenhaltung im
ESTW-Planungsprozess. Signal und Draht. 2012, 09/2012, S. 22-26. Quelle:
www.ProSig.de/download.html.
Mertens, P. 2002. Business Intelligence - ein Überblick, Arbeitspapier an der
Universität Erlangen-Nürnberg 2/2002. Nürnberg : s.n., 2002. zitiert in [Kemper, et al.,
2010 S. 3].
Microsoft. 2013 a. Entwicklerhandbuch (Analysis Services). [Online] 2013 a. [Zitat
vom: 03. 09 2013.] http://technet.microsoft.com/de-de/library/bb500153.aspx.
—. 2013 b. MS-SQL-Server. [Online] Microsoft, 2013 b. [Zitat vom: 03. 09 2013.]
http://www.microsoft.com/en-us/sqlserver/product-info.aspx.
pmOne AG. 2012. What Works - Business Intelligence und Data Warehousing. [Hrsg.]
TDWI Germany e.V. 2012, 1-2012, S. 6,7.
Probst, Hans-Jürgen. 2012. Kennzahlen - Richtig anwenden und interpretieren.
München : Redline Verlag, 2012.
Puppe, Frank. 1988. Einführung in Expertensystemen. Berlin, Heidelberg, New York :
Springer-Verlag, 1988.
III
Savory, Stuart. 1988. Grundlagen von Expertensystemen. München : R. Oldenbourg
Verlag, 1988.
Schwichtenberg, Holger. 2013. Microsoft ASP.NET 4.5 mit Visual C# 2012 - Das
Entwicklerbuch. Köln : O'Reilly Verlag GmbH, 2013.
Totok, Andreas. 2000. Modellierung von OPLA- und Data Warehouse-Systemen.
Wiesbaden, 2000.
Wang, Qing, Pfahl, Dietmar und Raffo, David M. 2008. Making Globally Distributed
Software Development a Succes Story. Berlin, Heidelberg, New York : Springer Verlag,
2008.
Wikipedia. 2013 a. Anforderungsanalyse (Informatik). [Online] 2013 a. [Zitat vom: 29.
08 2013.] http://de.wikipedia.org/wiki/Anforderungsanalyse_(Informatik).
—. 2013 b. Model View Controller. [Online] 2013 b. [Zitat vom: 03. 09 2013.]
http://de.wikipedia.org/wiki/Model_View_Controller.
Zimmer, et al. 2012. Standards für Agile BI in der BI-Community durch den TDWI.
[Hrsg.] Peter Gluchowski. BI-Spektrum. 2012, 05/2012.
IV
Anhang
Anhang 1: Systemzoo und seine Folgen
[Anhang zu Kapitel 2.1.2 – Probleme und Strategien]
Ein „Systemzoo“ ist insbesondere durch folgende Symptome erkennbar148:
Unterschiedliche Hard-und Softwarelösungen von unterschiedlichen Anbietern
Hohe Kosten für Wartung, Schulung und Weiterentwicklung
Viele Medien- und Systembrüche an zahlreichen Schnittstellen
Hoher Integrationsaufwand durch spezielle Daten- und Systemschnittstellen.
Viele verschiedene und unattraktive Lizenzmodelle
Hohe Spezialisierung und „Sonderlösungen“ für bestimmte Gruppen und Rollen im
Unternehmen
Und v.a. eine fehlende durchgängige Systemarchitektur mit einem konsistenten
einheitlichen Datenmodell
Daraus resultiert eine Reihe von Problemen, die einen effizienten Einsatz von BI-
Systemen erschweren oder sogar verhindern149:
Eine heterorege Systemlandschaft mit z.T. völlig proprietären Systemen für einzelne
Fachbereiche und Nutzergruppen, die nebeneinander existieren und auf Dauer die
IT-Abteilung beschäftigen bzw. belasten.
Unklare und schlechte Datenqualität, da oft eine gemeinsame Datenbasis (wie z.B.
eine gemeinsame Stammdatenbasis) fehlt und auch kein automatisierter Abgleich
zwischen den Teilsystemen stattfindet.
Der mangelnde Abgleich zwischen den Bereichen führt dazu, dass fehlende Daten
„irgendwie“ manuell hinzugefügt werden.
Undefinierte Analyseprozesse, da sich jeder Bereich seine eigenen Regeln und
Anforderungen entwickelt, welche Daten mit welcher Methode zu welchen
Kennzahlen und Berichten verdichtet und aufbereitet werden.
Unbekannte Datenherkunft, da mit steigender Komplexität bzw. Undurch-
schaubarkeit der Systemlandschaft und Analyseprozesse nicht mehr klar ist, aus
welchen Vorsystemen die Daten letztlich stammen, wie sie erhoben bzw. verdichtet
wurden und welche Informationen sich noch aus ihnen ableiten lassen. Metadaten,
die dieses Problem eindämmen, fehlen meist; siehe Kapitel 2.2.1.
Infolge der o.g. Situation kommt es zu mangelndem Vertrauen in die Daten und in
die daraus abgeleiteten Informationen. Die Investitionen in die BI-Systeme bringen
148 im Wesentlichen übernommen aus [Gansor, et al., 2010 S. 18]
149 vgl. [Bachmann, et al., 2011 S. 41-44] und [Gansor, et al., 2010 S. 14-19]
V
nicht den erhofften Nutzen und Ihre Akzeptanz, insbesondere auf der
Führungsebene, geht zurück.
Letztlich finden wichtige unternehmerische Entscheidungen entweder auf unsicherer
Datenlage statt oder werden wieder nach „Bauchgefühl“ getroffen.
Anhang 2: Notwenige Abgrenzungen für ein BI-System
[Anhang zu Kapitel 2.1.2 – Grenzen]
BI ist kein Ersatz für150
eine fehlende oder unschlüssige Unternehmensstrategie, im Gegenteil, BI wird nach
ihr ausgerichtet.
eine fehlende Definition bzw. Abgrenzung bezüglich Unternehmensstruktur,
Zuständigkeiten und Arbeitsprozessen. Vorhandene Lücken und Unstimmigkeiten
müssen zuvor ermittelt und durch gesonderte Maßnahmen und Absprachen
behoben werden.
eine fehlende Gesprächs- und Austauschplattform zwischen den Fach- bzw.
Funktionsbereichen. Hier muss z.B. durch Schulungsmaßnahmen und Workshops
ein gemeinsames Verständnis für die Aufgaben und Lösungen entstehen, bevor die
unterschiedlichen Sichtweisen durch ein (noch so gutes) BI-System
aufeinanderprallen und letztlich das System aus Befindlichkeiten, Vorbehalten,
Verunsicherungen oder Machtinteressen nicht zur Anwendung kommt.
eine fehlende Steuerung bzw. Steuersystematik im Unternehmen. BI kann keine
neuen Prozesse oder Strukturen durchsetzen, wenn ansonsten kein Beachten und
Durchsetzen von „oben“ durch Informieren und Anweisen erfolgt.
eine fehlende oder unzureichende Integrationsplattform. Oft wurden BI-Systeme
schon dazu „missbraucht“ einen bereichsübergreifenden Datenabgleich der
operativen Systemen (wie SCM, CRM, ERP, E-Procurement) zu realisieren, durch
datentechnische „Rückschnittstellen“ vom zentralen DWH in die Datenbanken der
Transaktionssysteme. Die BI-Systeme sind auf eine analytische Verarbeitung
ausgerichtet (u.a. OLAP und Reporting, siehe Kapitel 2.3) und nicht auf die Haltung
und Verarbeitung von Transaktionsdaten (OLTP). Hierfür muss eine umfassende
Integrationsplattform z.B. im Kontext der EAI (Enterprise Applikation Integration)
geschaffen werden151.
150 vgl. [Gansor, et al., 2010 S. 34 ff.] und [Bachmann, et al., 2011 S. 39 ff.]
151 vgl. [Leipert, 2013a]
VI
Anhang 3: Datenschema Fact-Constellation und Galaxy
[Anhang zu Kapitel 2.2.3 – Modellierung der Daten]
Fact_Umsatz
PK ID_Umsatz
Wert RevisionFK1 ID_ProduktFK2 ID_ZeitFK3 ID_OrtFK4 ID_Kunde
Dim_Produkt
PK ID_Produkt
Bezeichnung Revision Verkaufspreis Einkaufspreis Produktgruppe
Dim_Ort
PK ID_Ort
Bezeichnung Revision Filiale Region
Dim_Zeit
PK ID_Zeit
Datum Revision
Dim_Kunde
PK ID_Kunde
Name Revision Adresse Kundengruppe
Fact_Umsatz_Kulminiert
PK ID_Umsatz
Wert RevisionFK3 ID_ProduktFK2 ID_ZeitFK4 ID_OrtFK1 ID_Kunde
Abbildung 51: Fact-Constellation-Schema152
Fact_Umsatz1
PK ID_Umsatz
Wert RevisionFK1 ID_ProduktFK2 ID_ZeitFK3 ID_OrtFK4 ID_Kunde
Dim_Produkt1
PK ID_Produkt
Bezeichnung Revision Verkaufspreis EinkaufspreisFK1 ID_Produktgruppe
Dim_Ort1
PK ID_Ort
Bezeichnung RevisionFK1 ID_Filiale
Dim_Zeit1
PK ID_Zeit
Datum RevisionFK1 ID_Monat
Dim_Kunde1
PK ID_Kunde
Name Revision AdresseFK1 ID_Kundengruppe
Dim_Kundengruppe1
PK ID_Kundengruppe
Bezeichnung Revision
Dim_Produktgruppe1
PK ID_Produktgruppe
Bezeichnung Revision
Dim_Filiale1
PK ID_Filiale
Bezeichnung RevisionFK1 ID_Region
Dim_Region1
PK ID_Region
Bezeichnung Revision
Dim_Monat1
PK ID_Monat
Name RevisionFK1 ID_Jahr
Dim_Jahr1
PK ID_Jahr
Jahreszahl Revision
Fact_Umsatz_Kulminiert
PK ID_Umsatz
Wert RevisionFK1 ID_ProduktFK3 ID_KundeFK2 ID_MonatFK4 ID_Ort
Abbildung 52: Galaxy-Schema153
152 eigener Entwurf in Anlehnung an [Köppen, et al., 2012 S. 59]
VII
Anhang 4: Balanced Scorecard und Wertetreiber im Unternehmen
[Anhang zu Kapitel 2.3.3 – Harte und weiche Kennzahlen]
Lern- und
Entwicklungsperspektive
Wie können wir unsere
Potenziale fördern?
Ziele Indikatoren Maßnahmen
Vision
und
Strategie
Kundenperspektive
Wie sehen uns unsere
Kunden?
Ziele Indikatoren Maßnahmen
Finanzperspektive
Wie sehen uns die
Anteilseigner?
Ziele Indikatoren Maßnahmen
Interne Prozessperspektive
Wie können wir unserer
Prozesse optimieren?
Ziele Indikatoren Maßnahmen
Abbildung 53: Balanced Scorecard154
Marktanteil
Image
Durchschnitt
Marktpreis
Produktions-
kosten
Qualität
Verkaufte
Stückzahl
Stückpreis
Umsatzkosten
Umsatzerlös
Betrieblicher
Aufwand
Wertminderung
Abschreibung
Bestand
Rohstoffe
Bestand
Halbzeuge
Bestand
Fertigprodukte
Forderungen
Umsatz-
wachstum
EBITDA
Steuern
Invest. Anlage-
vermögen
Invest. Umlauf-
vermögen
Kapitalkosten
Netto-Cashflow
Free Cashflow
Betriebliche
Investitionen
Diskontsatz
Shareholder
Value
Geschäftsspezifische
Wertetreiber
Generische
(externe)
Wertetreiber
Ergebnisse
Abbildung 54: Wertetreiber im Unternehmen155
153 eigener Entwurf in Anlehnung an [Köppen, et al., 2012 S. 59]
154 vgl. [Probst, 2012 S. 233], vgl. auch [Kemper, et al., 2010 S. 132]
VIII
Anhang 5: Anforderungsliste für das M-BID-System
[Anhang zu Kapitel 3.3 – Auswertung der Untersuchung]
ID Beschreibung Kate- gorie
ist Teil von
Prio. Relevanz-Feld Kernfrage des Nutzers
Informationsbedarf / Aktionsbedarf
A1 M-BID ist bereichsübergreifendes System
GA A14, 40
1 R1 Wer ist an den Informationen im M-BID interessiert?
Hinweise über Abteilungen und Rollen / Informationsaustausch
A2 Granularität der Dimension Zeit ist der Monat
TFA A34 1 R8, 12 Was ist feinste Ebene bezüglich der Zeit?
Hinweise über Dimensionen
A3 Reporting realisieren GA A40 1 R13 Wie geht es der SWE-Abteilung?
Botschaften, Kennzahlen, Vergleiche
A4 M-BID auch für Plan-Kennzahlen
FA A20 1 R12 Wie wird/soll sich die SWE-Abteilung entwickeln?
Kennzahlen, Vergleiche / Planwerte speichern
A5 Reports via Outlook versenden
FA A3 2 R18 Wie erfahre ich über Neuigkeiten?
Hinweise über Neues an bekannten Orten / Zugriff auf Information "vorort"
A6 Daten in MS-Excel-Tabellen exportieren
FA A3 2 R18 Wie findet ein "konventioneller" Datenaustausch statt? Wie kann ich die Daten weiterverarbeiten?
Hinweise über Exportfunktionen/ Exportieren der Daten
A7 Link zum IMS ins M-BID-Portal
FA A38 2 R18 Wo bekomme ich z.B. eine bestimmte Dokumentenvorlage?
Wegweiser/Link folgen
A8 Links auf Ordnerstruktur für Zugriff auf unstrukturierte Daten
TA A38 1 R18 Wo finde ich meine Projekt- und/oder Abteilungsdokumente?
Wegweiser/Link folgen
A9 Link vom M-BID-Portal zum PB-Intranet
FA A38 2 R18 Was gibt es Neues bei PB?
Wegweiser/Link folgen
A10 SAP ist eine Quelle vom M-BID-System
TA A39 1 R2,5,7,8 Wo kommen die Daten z.B. zum Projektstand her?
Hinweise zur Datenherkunft
A11 PRS ist eine Quelle vom M-BID-System
TA A39 1 R2,5,7,8 Wo kommen die Daten z.B. zum Projektfortschritt her?
Hinweise zur Datenherkunft
A12 Aufruf/Anzeige von M-BID-Funktionalität aus Entwicklungsumgebung
FA A40 3 R1 Wie erfahre ich über Neuigkeiten?
Hinweise über Neues an bekannten Orten / Zugriff auf Information "vorort"
A13 Alle Daten für die Tabellen und Reports kommen aus dem M-BID
TA A3 1 R2,6 Wo schaue ich als erstes nach, wenn ich Informationen / Daten brauche?
Hinweise zur Datenherkunft
A14 Management der Zugriffsrechte realisieren
GA A40 1 R10 Was darf ich im M-BID ansehen und machen?
Hinweise über Rechte und Einstellungen
155 vgl. [Kemper, et al., 2010 S. 141]
IX
A15 M-BID-Dienst für monatliches Projekt-Review realisieren
GA A3 1 R6,18 Was hat sich im vergangenen Monat in den Projekten verändert?
Botschaften, Kennzahlen, Vergleiche, Inhalt von Projektdateien
A16 Verschiedene Rollen im M-BID berücksichtigen
TA A14 1 R10,18 Was darf ich alles im M-BID? Wie ist das System für mich konfiguriert?
Hinweise über Rechte und Einstellungen / Änderungen durchführen (lassen)
A17 Navigation in den Projekten ermöglichen
FA A15 1 R14, 18 Wie komme ich zum Projekt XY?
Wegweiser/Link folgen
A18 Projekt-Cockpit mit Dashboards realisieren
TA A15 1 R16,18 Wie sieht das Projekt XY aus?
Botschaften, Kennzahlen, Vergleiche, Inhalt von Projektdateien
A19 Dashboard für Herstellungskosten-Ist realisieren
FA A18 1 R13,14,18 Wie haben sich die Herstellungskosten des Projektes XY entwickelt?
Botschaften, Kennzahlen
A20 Verschiede Szenarien der Kennzahlen vorsehen
TA A34 1 R8,12 Wie verhält sich Ist zu Soll? Bin ich noch im "grünen Bereich"?
Kennzahlen, Abweichungen
A21 Dashboard für Projektstunden-Ist realisieren
FA A18 1 R13,14,18 Reichen die Stunden noch?
Kennzahlen, Abweichungen
A22 Dashboard für HK-Details realisieren
FA A18, 19
1 R14,18 Wie setzen sich die HK zusammen?
Kennzahlen, Beschreibungen
A23 Überblick über die Projekte ermöglichen
FA A15 1 R14,18 Welche Projekte gibt es und wie sehen sie grob aus?
Botschaft
A24 Dashboard für UM,AE,HK in Zeitreihen realisieren
FA A18 1 R6,14 Wie hat sich das Projekt XY entwickelt? Ist u.a. der AE noch über HK? Welche Tendenzen sieht man?
Kennzahlen, Vergleiche, Tendenzen / einzelne Grafen an- und ausschalten für bessere Übersicht
A25 Dashboard für Projektfortschritt-Ist realisieren
FA A18 1 R13,14,18 Wie weit ist das Projekt XY gediehen? Was bleibt zu tun?
Kennzahlen, Aufstellungen, Beschreibung
A26 Dashboard für Projektprognose realisieren
FA A18 1 R1,13,14,18 Wie geht es mit dem Projekt weiter? Wie viele Stunden / wie viele HK werden noch gebraucht?
Alle Informationen, die unter A18 verfügbar sind, sowie letzte Prognosewerte. / Eintragen und Speichern der aktuellen Prognose
A27 Projekt-Botschaften editieren
FA A18 1 R14 Was ist bei Projekt XY anzumerken? Was wollen andere wissen und sehen?
Alle Informationen unter A18 / Botschaften zu den entsprechenden Kernfragen formulieren und speichern.
A28 Dashboard für Maßnahmen realisieren
FA A18 1 R1,13,14,18 Wo gibt es Handlungsbedarf? Was muss wie und mit wem passieren?
Alle Informationen unter A18 / Festhalten der zu treffenden Maßnahmen als Text und Typ.
X
A29 Link auf Projektdateien zur Verfügung stellen
FA A8,18 1 R18 Was sind die Fakten und Vorkommnisse hinter den Zahlen?
Inhalt von Projektdateien / zu Projektdateien navigieren
A30 Profitcenter-Botschaften editieren
FA A15 1 R14 Was ist bei den Projekten des Profitcenters anzumerken? Was wollen andere wissen und sehen?
Alle Informationen unter A15 / Botschaften zu den entsprechenden Kernfragen formulieren und speichern.
A31 Verdichtung der Kennzahlen auf Quartals- und Jahressummen
TFA A33 2 R7 Was hat sich beim Profitcenter XY im letzten Quartal getan? Wie sieht es im Jahresvergleich aus?
Alle Informationen unter A15 sowie weitere Profitcenter-Kennzahlen
A32 Verschiedene Ausprägungen der Kennzahlen vorsehen
TA A34 1 R8,12 Welche Anwendungsfälle der Kennzahlen gibt es?
Hinweise und Darstellung der Möglichkeiten / Auswahl
A33 Aggregation der Kennzahlen realisieren
GA A41 1 R2,6,7,8,12,17 Wie sehen die Kennzahlen gruppiert bzw. detailliert aus?
Kennzahlen in verdichteter bzw. aufgegliederter Form. / Drill-Down und Roll-Up
A34 Verschiedene Kennzahldimensionen vorsehen
GA A41 1 R6,7,8,12,17 Von welchen Größen hängen die Kennzahlen ab?
Anzeige der möglichen Dimensionen / Auswahl
A35 Verschiedene Kennzahlen/Cubes ermöglichen
GA A41 1 R6,8,12,13 Welche Kennzahlen zeigt die momentane Situation am besten?
Hinweise über die Kennzahlen und deren Werte / Auswahl
A36 Datenschnittstelle zu SAP mittels Excel-Import
FA A10 1 R1,5,6,7,8 Wo kommen die Daten z.B. zum Projektstand her?
Hinweise zur Datenherkunft
A37 Datenschnittstelle zu PRS mittels SQL-Anweisungen
FA A11 1 R1,5,6,7,8 Wo kommen die Daten z.B. zum Projektfortschritt her?
Hinweise zur Datenherkunft
A38 Links zu anderen Datenquellen realisieren
HA - 1 R18 Wie komme ich an Informationen außerhalb des M-BID?
Wegweiser/Link folgen
A39 Daten aus operativen Vorsystemen importieren
HA - 1 R2,5,7,8 Wo kommen die Daten her und welche Informationen gibt es?
Hinweise zur Datenherkunft und Kennzahlen / Auswahl
A40 Zugriff auf die Daten und Informationen des M-BID realisieren
HA - 1 R1,2, 6,10,13, 18
Welche (neuen) Information gibt es im M-BID?
Botschaften, Kennzahlen, Vergleiche / Auswahl und ggf. Bewertung
A41 Datenstruktur im M-BID realisieren
HA - 1 R6,7,8,10,12,13, 17,18
Welche Objekte gibt es und welche Beziehungen haben sie?
Hinweise und Darstellung der Möglichkeiten / Auswahl
A42 Kennzahl UM TA A35 1 R8,16 s. Erfassungsbogen entspr. Kennzahl
A43 Kennzahl AE TA A35 1 R8,16 s. Erfassungsbogen entspr. Kennzahl
A44 Kennzahl HK TA A35 1 R8,16 s. Erfassungsbogen entspr. Kennzahl
A45 Kennzahl PRJ_PROGRESS
TA A35 1 R8,16 s. Erfassungsbogen entspr. Kennzahl
Tabelle 4: Vollständige Anforderungsliste für das M-BID-System
XI
Anhang 6: Dimension Produkt für M-BID-Erweiterung
[Anhang zu Kapitel 6.3 – Aussichten]
Produkt
Projekt_Hierarchie
ProjektXY{ }
Vorgang{ }
ToDo{ }
Meilenstein{ }
Versions_Hierarchie
Vollversion{ }
Modul_Hierarchie
ServicePack{ }
Modulgruppe{ }
Modul{ }
Abbildung 55: Künftige Dimension „Produkt“