Download - Diplomarbeit · OLAP Online Analytical Processing OLPT Online Transaction Processing OO object oriented /objektorientiert PB Parsons Brinckerhoff Comany PPS Produktionsplanungs- und

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


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


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.

http://www.google.de/

1.4 Vorgehensweise


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


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


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.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]



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,


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.]



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]



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.]



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.



22 vgl. [Totok, 2000 S. 37. ff.]

23 eigener Entwurf in Anlehnung an [Totok, 2000 S. 38] und [Gluchowski, et al., 2008 S. 5]



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.]

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]



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]




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]



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


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.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]



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.



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.]



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


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.]



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.]



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.



Operative SystemeSystem 1


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.]



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]



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]


62 vgl. [Kemper, et al., 2010 S. 66]




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]



Fact_Umsatz

PK ID_Umsatz


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


Dim_Filiale

PK ID_Filiale

Bezeichnung RevisionFK1 ID_Region

Dim_Region

PK ID_Region


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


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


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.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]



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]



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.]



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]


79 vgl. [Gluchowski, et al., 2008 S. 151-155]



= 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]



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





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





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]


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.]



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]



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.


95 aus [Klein, 2012 S. 72]

96 vgl. [Klein, 2012 S. 72 ff.]

97 vgl. [Klein, 2012 S. 33 f.]



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]



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 ]



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€.



106 vgl. [Probst, 2012 S. 14, 22]

107 vgl. [Totok, 2000 S. 118 f.] und [Probst, 2012 S. 12 f.]



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]



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]



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]




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]



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]


3.1 Kriterien für die Untersuchung


3 IST-Analyse


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]



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



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.



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]



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.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



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]



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]



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.]



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



ToDo > Vorgang > (Meilenstein) > Projekt XY

Anforderung A42 A43 A44 A45

Tabelle 1: Erfassung der Kennzahlen mit Eigenschaften

3.3 Auswertung der Untersuchung


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


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


Ü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.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]



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



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.



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



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.



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.



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“



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.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:



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.




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]



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.



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.]



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:



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



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.



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



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



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.



DWH_CUBE_HK

PK ID_HK

Wert RevisionFK3 ID_ProjektFK2 ID_MonatFK4 ID_DetailFK1 ID_Szenario

Dim_Projekt

PK ID_Projekt


Dim_Jahr

PK ID_Jahr


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


Dim_Detail

PK ID_Detail


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.



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.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



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.



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



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.



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.



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.



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


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


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


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



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]

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;" />





NewChart:

<img src="temp/chartStream.jpg"></img>



…

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" %>

…



NewChart:

<% DisplayChart(); %>



…

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.

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]



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]



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


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


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


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


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


Abbildung 51: Fact-Constellation-Schema152

Fact_Umsatz1

PK ID_Umsatz


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


Dim_Produktgruppe1

PK ID_Produktgruppe


Dim_Filiale1

PK ID_Filiale

Bezeichnung RevisionFK1 ID_Region

Dim_Region1

PK ID_Region


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


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?


Finanzperspektive

Wie sehen uns die

Anteilseigner?


Interne Prozessperspektive

Wie können wir unserer

Prozesse optimieren?


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


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?


A9 Link vom M-BID-Portal zum PB-Intranet

FA A38 2 R18 Was gibt es Neues bei PB?


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?


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?


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?


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?


A37 Datenschnittstelle zu PRS mittels SQL-Anweisungen

FA A11 1 R1,5,6,7,8 Wo kommen die Daten z.B. zum Projektfortschritt her?


A38 Links zu anderen Datenquellen realisieren

HA - 1 R18 Wie komme ich an Informationen außerhalb des M-BID?


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“