1  EINLEITUNG  4

2  IT-KENNZAHLEN  5

2.1  WAS SIND IT-KENNZAHLEN?  5

2.2  WOZU DIENEN IT-KENNZAHLEN?  5

2.3  KATEGORIEN VON KENNZAHLEN  5

2.3.1  Technische IT -Kennzahlen.  6

2.3.2  Betriebswirtschaftliche IT -Kennzahlen  7

2.3.3  Organisatorische IT-Kennzahlen.  7

2.3.4  Kundenorientierte IT-Kennzahlen  7

3  SERVICE LEVEL AGREME NTS (SLA)  8

3.1  WAS IST EIN SLA?  8

3.2  IT-KOSTEN.  8

3.3  WOZU WIRD EIN SLA BENÖTIGT?  9

3.4  WIE WIRD EIN SLA ZUR ZEIT KONTROLLIERT?  9

4  ANFORDERUNG AN DIE SOFTWARELÖSUNG  11

4.1  WAS SOLL DIE EINZUFÜHRENDE SOFTWARE LEISTEN?  11

4.2  BETRIEB DER EINZUFÜHRENDEN SOFTWARE.  12

4.3  FLEXIBLILTÄT/ERWEITERBARKEIT DER EINZUFÜHRENDEN SOFTWARE  12

4.4  KOSTEN DER EINZUFÜHRENDE SOFTWARE  12

5  MAKE OR BUY.  13

5.1  ANALYSE DER BESTEHENDEN STRUKTUR  13

5.1.1  Lösungsmöglichkeiten mit vorhandenen Mitteln  13

5.1.2  Welche Arbeiten sind nötig?  13

5.2  ENTSCHEIDUNG MAKE OR BUY.  13

6  DEFINITION.  15

6.1  DATENMODELL  16

6.1.1  Anforderungen  16

6.1.2  Umsetzung des relationalen Modells  17

6.1.3  SQL-Views  18

7  DATA WAREHOUSE (DWH)  20

7.1  WAS IST EIN DWH?  20

7.2  EXTRAKTION TRANSFORMATION LADEN (ETL)  21

7.3  ONLINE ANALYTICAL PROCESSING (OLAP)  22

7.4  WARUM DWH UND KEINE RELATIONALE DATENBANK (RDB)?  22

8  REALISIERUNG  23

8.1  AUSWAHL DER SOFTWARE  23

8.2  ERFORDERLICHE SOFTWARE FÜR DAS PROJEKT.  23

8.2.1  Informatika Powercenter  24

8.2.2  Cognos Impromptu  25

8.2.3  Cognos Powerplay Transformer  26

8.2.4  Cognos Powerplay  27

8.2.5  Cognos KPI Buisness-Pack  27

8.2.6  Cognos Upfront  30

8.3  CUSTOMIZING  30

Seite  2 von  44

8.3.1  KPD.  31

8.3.2  UTML (Upfront Template Markup Language)  32

8.3.3  KTML (KPI Template Markup Language)  32

9  DARSTELLUNG IM INTRANET.  33

9.1  TYPISCHER ARBEITSABLAUF ZUM EINBINDEN NEUER KENNZAHLEN IN DEN  

INTRANETAUFTRITT.............................................................................................................   33

9.2  ERGEBNIS  34

9.3  WURDEN DIE PROJEKTZIELE ERREICHT?  36

10  PERSÖNLICHE ERFAHRUNG.  37

11  GLOSSAR  38

12  ANHANG.  40

12.1  DOKUMENTATION ZU KTML  40

12.1.1  Variablen.  40

12.1.2  Kontrollstrukturen.  43

13  QUELLEN.  44

Seite  3 von  44

1 Einleitung

Die BMW Projekte „IT-Kennzahlen“ und „Service Level Agreement“ beschäftigt sich mit der hierarchisch strukturierten und schnell erfassbaren Darstellung von erfassten Performance- und Verfügbarkeitsmessdaten der IT -Infrastruktur der BMW Group.

Das Projekt umfasst das Teilprojekt IT-Kennzahlen und das Teilprojekt Service Level Agreement. Die Service Level Agreements setzen sich aus den IT-Kennzahlen zusammen und sollen um eine individuelle Bewertungsfunktion erweitert werden. Die Visualisierung soll über das Intranet auf PC-Systemen und in einer zweiten Leistungsstufe auf Palm-Tops realis iert werden. Dem Management soll damit ein Kontrollinstrument zur Verfügung stehen.

Seite 4 von 44

2 IT-Kennzahlen

2.1 Was sind IT-Kennzahlen?

IT-Kennzahlen werden aus den wesentlichen Performancemessdaten der IT-Infrastruktur der BMW Group abgeleitet. Diese Daten werden durch Online-Messungen an den jeweiligen Systemen oder durch Befragungen von den für die Messergebnisse verantwortlichen Personen erfasst. Eine Kennzahl setzt sich aus folgenden Komponenten zusammen

• Ist

• Soll

• Trend

• Historienwerte

• Schwell- &Toleranzwerte

• Relevanz für das Business

2.2 Wozu dienen IT-Kennzahlen?

Die IT-Kennzahlen und ihre anwenderfreundliche Präsentation dienen als Steuerungsinstrument für das IT -Managment. Es ist eine operative Sicht auf die IT-Infrastruktur der BMW-Group. Die Kennzahlen sind Grundlage für die Planung und das Benchmarking der IT-Infrastruktur. Die Kennzahlen erhöhen die Transparenz und dienen als Kontrolle der Leistungserfüllung (SLA) gegenüber den internen IT-Kunden

2.3 Kategorien von Kennzahlen

Nachfolgend werden beispielhafte Ausschnitte der Kategorien der gemessenen Kennzahlen und die wichtigsten Messpunkte aufgeführt.

2.3.1 Technische IT -Kennzahlen

2.3.2 Betriebswirtschaftliche IT -Kennzahlen 2.3.3 Organisatorische IT -Kennzahlen

2.3.4 Kundenorientierte IT-Kennzahlen

Seite 5 von 44

2.3.1 Technische IT-Kennzahlen

Incident Management Performance: Incident Managment beschäfitigt sich mit der Lösung von aufgetretenen technischen Problemen. Relevante Kennzahlen sind z.B.

• Anzahl der eingegangenen Problemstellungen (Calls) (nach Prioritäten)

• Wie lange musste ein Benutzer auf die Bearbeitung seines Problem warten (Wartezeit)?

• Wie lange dauerte es, bis das Problem behoben war (Reaktionszeit)?

• Welche Kosten wurden pro Call verrechnet?

• Sofortlösungsquote

Storage: Relevante Kennzahlen sind z.B.

• Volumen

• Verhältnis Brutto / Netto Kapazität

• Auslastung

• Kosten / Gbyte Server: Relevante Kennzahlen sind z.B.

• Anzahl und Leistung (pro Gruppe),

• Auslastung (pro Gruppe)

• Verfügbarkeit

• Kosten / Leistung (pro Gruppe) Mainframe: Relevante Kennzahlen sind z.B.

• Installierte Leistung

• Auslastung

• Kosten / MIPSh

• Verfügbarkeit Netzwerk: Relevante Kennzahlen sind z.B.

• SLA Performance

Betriebsübernahme: Relevante Kennzahlen sind z.B.

• Anzahl Projekte in den einzelnen Phasen

• Laufzeiten der Projekte durch den Prozess

• Anzahl Terminverschiebungen

Seite 6 von 44

2.3.2 Betriebswirtschaftliche IT-Kennzahlen Hardware Assets: Vorhandene Hardware im Unterne hmen

Software Assets: Vorhandene Software im Unternehmen

Wartungskostenanteil (HW & Software): Wie hoch sind die Wartungskosten im Vergleich zu den Hard- bzw. Softwarekosten?

2.3.3 Organisatorische IT-Kennzahlen

Invest SOLL / IST: Soll- und Ist-Werte der Investitionskosten

Budget SOLL / IST: Soll- und Ist-Werte des Bugets

Kostentreiber (Top 5): Die fünf größten Kostenverursacher

Fremdleistungen SOLL / IST: Soll- und Ist-Werte für Fremdleistungskosten

Verhältnis Fremdle istung / Eigenleistung : Verhältnis der Kosten für Fremd - und Eigenleistungen

2.3.4 Kundenorientierte IT-Kennzahlen

Kundenzufriedenheit: Kunden sind die IT-Nutzer bei der BMW -Group IT-Kosten / Mitarbeiter: Wie hoch sind die IT -Kosten pro Mitarbeiter? IT-Kosten / Fahrzeug: Wie hoch sind die IT -Kosten pro produziertemFahrzeug? Abdeckungsgrad mit SLAs: Wird der SLA erfüllt?

Seite 7 von 44

3 Service Level Agrements (SLA)

3.1 Was ist ein SLA?

Um zu verstehen, was ein Service Level Agrement (SLA) ist, muss man die Struktur der IT in der BMW AG etwas näher betrachten.

Sämtliche Ressourcen bezüglich IT (Plattenplatz, CPU-Zeit, Netzwerkverbindungen, usw.) werden bei BMW zentral verwaltet und den einzelnen Fachabteilungen zur Verfügung. Jede Abteilung macht eine Abschätzung, wie viel IT- Ressourcen sie für das jeweilige Geschäftsjahr benötigt und schließt mit dem Rechenzentrum einen Vertrag ab. In diesem wird festgehalten, wie viel der jeweiligen Ressourcen das Rechenzentrum der jeweiligen Abteilung zur Verfügung stellt (z. B. 100GB auf ServerXY oder 1000 MIPSH auf ServerXY) und welche Toleranzen dabei einzuhalten sind. Diese Leistungsbereitstellung wird im folgenden ‚Service’ genannt. Es wird genau festgelegt, welche Verfügbarkeit ein Service haben soll (z. B. 99%).

Der zwischen der Abteilung und dem Rechenzentrum abzuschließende Vertrag wird als SLA bezeichnet. In dem Vertrag werden die Toleranzen für bestimmte Services z. B. (Bereitstellung von Plattenplatz, CPU-Zeit, usw.) festgehalten.

3.2 IT-Kosten

Es stellt sich die Frage, wieso innerhalb eines Unternehmens überhaupt eine Verrechung über die zur Verfügung stehenden Ressourcen stattfindet. Dies kann man verstehen, wenn man sich vor Augen führt, dass heutzutage in einem modernen Automobil ein hoher Prozentsatz der Kosten für IT im weitesten Sinne veranschlagt werden müssen. Diese Kosten beinhalten alles, angefangen von der Software für das Navigationssystem bis hin zu den Kosten, die ein Prozessor in einem Server verursacht, wenn er die Gehaltsabrechnungen der Mitarbeiter berechnet. Die einzige Möglichkeit sich diese Kosten bezahlen zu lassen, ist sie in den Verkaufspreis der Produkte (der Pkws) mit einzuberechnen. Also: je höher die IT-Kosten, umso höher die Kosten für die Produkte. BMW erzeugt eine genaue Aufstellung der IT -Kosten und hält sämtliche Abteilungen an die IT-Kosten zu minimieren. Das geeignetste Mittel dazu ist es, genau Buch über die Kosten zu führen und den jeweiligen Abteilungen in

Seite 8 von 44

Rechnung zu stellen. Da jede Abteilung nur ein begrenztes Budget hat, achten die entsprechende Abteilung genauestens darauf, die Kosten zu minimieren.

3.3 Wozu wird ein SLA benötigt?

Innerhalb der BMW Group werden sich Kunde und Lieferant in einem Vertag über die zu leistende Arbeit und deren Qualität einig. Wenn die Qualität der geleisteten Arbeit nicht den Vereinbarungen entspricht, kann der Kunde vom Lieferanten eine Preisminderung verlangen.

Wenn das vom IT -Service -Center gelieferte Produkt nicht den Qualitätsansprüchen des Kunden (die einzelnen Fachabteilungen) entspricht, also falls irgendwelche Toleranzen nicht eingehalten wurden, hat der Kunde das Recht, dies zu beanstanden.

Nach diesem Kunde-Lieferant -Prinzip werden die IT -Service -Verträge bei BMW abgeschlossen.

3.4 Wie wird ein SLA zur Zeit kontrolliert?

Um zu ermitteln, welche Leistungen die jeweiligen Systeme zu Verfügung stellen, werden täglich Leistungsmessungen durchgeführt. Hierzu werden in regelmäßigen Abständen Standardaufgaben durchgeführt und die Zeit, welche das System benötig, diese Aufgabe zu erledigen, gemessen. Diese Messdaten werden in einem Logfile gespeichert, welches zur späteren Weiterverarbeitung genutzt werden kann.

Ein Tool, welches auf einem Clientrechner läuft, greift auf diese Protokolldaten zu, extrahiert die relevanten Messdaten und berechnet die durchschnittlichen Verarbeitungszeit bzw. die Verfügbarkeit eines Systems und stellt diese Daten in einem Worddokument zu Verfügung. Diese Worddokumente werden im Intranet den jeweiligen Abteilungen zur Verfügung gestellt, so dass sie kontrollieren können, ob Ihre Vorgaben erfüllt wurden.

Seite 9 von 44

(Ausschnitt aus dem erzeugten Messprotokoll)

Tabelle 1 Quelle: BMW Group Abteilung FZ-400

Ziel des Projektes ist, dem Anwender visuell aufbereitete Ergebnisse zu präsentieren, mit dem er mit minimalem Aufwand seinen SLA überprüfen kann.

Seite 10 von 44

4 Anforderung an die Softwarelösung

4.1 Was soll die einzuführende Software leisten?

Bisher werden die Messdaten in Worddokumenten dargestellt. Dies ist sehr unübersichtlich und wenig transparent. Die Software soll jedem SLA einen Status zuweisen, der anzeigt, ob sich die Werte in den vorgegebenen Toleranzen befinden. Wenn ein Toleranzwert überschritten wurde, muss der Benutzer die Möglichkeit haben schnell den Auslöser der Überschreitung zu finden.

4.2 Betrieb der einzuführenden Software

Der Betrieb soll weitgehend automatisch ablaufen: Ein Batchjob befüllt in regelmäßigen Abständen das Datawarehouse (DWH) und hält es so auf einem aktuellen Stand. Die Stati der SLAs werden in regelmäßigen Abständen aktualisiert. Wenn neue Messpunkte in einen SLA mit aufgenommen werden sollen, die noch nicht im DWH vorhanden sind, muss das DHW entsprechend angepasst werden. In diesem Fall muss das Datenmodell erweitert oder verändert werden.

4.3 Flexibliltät/Erweiterbarkeit der einzuführenden Software

Die Software muss sich an Änderungen im Datenmodell, Bewertungsfunktionen und Design anpassen können. Diese Anpassung muss ohne viel Aufwand realisierbar sein. Die Software sollte Funktionen oder Schnittstellen bereitstellen, mit der man diese Änderungen vornehmen kann.

Die Erweiterung in der zweiten Leistungsstufe um die Darstellung auf Palm-PDAs soll mit der Software möglich sein. Auch die Überführung in eine Balanced Scorecard muss realisierbar sein.

4.4 Kosten der einzuführende Software

Da es sich bei der Software um die anwenderfreundliche Darstellung eines bestehenden Messsystems handelt, ist es nicht erforderlich eine betriebswirtschaftliche Mehrwertrechnung aufzustellen. Für dies Projekt ist kein spezielles Budget erforderlich und beantragt worden.

Seite 12 von 44

5 Make or Buy

5.1 Analyse der bestehenden Struktur

Bevor eine Software entwickelt oder beschafft wird, muss analysiert werden, ob nicht schon vorhandene System zur Verfügung stehen, die bei der Lösung des Problems zum Einsatz kommen können.

5.1.1 Lösungsmöglichkeiten mit vorhandenen Mitteln

Für dies Projekt stehen für nachfolgend beschriebenen Aufgaben die bei der BMW Group bereits vorhandenen Softwareprodukte zu Verfügung.

Tabelle 2

5.1.2 Welche Arbeiten sind nötig?

Wenn mit den bestehenden Softwareprodukten gearbeitet werden soll, sind folgende Arbeiten erforderlich.

• Für das Befüllen der DB müssen im Powercenter die entsprechenden Quellen bekannt sein.

• Powercenter muss anhand einer vorgegebenen Datenstruktur die Daten in die Oracle -DB einpflegen.

• Mit der JSPund Java Beans werden die Funktionalitäten und die Darstellung der Daten realisiert.

• Die Präsentation findet auf einem Webbrowser statt.

Der Löwenanteil der zu leistenden Arbeit ist die Entwicklung der Funktionalitäten mit JSP und Java.

5.2 Entscheidung Make or Buy

Bei größeren Softwareprojekten stellt sich immer die Frage, ob man die erforderliche Software selber entwickeln oder von einem externen Anbieter eine bereits existierende Standardsoftware kaufen soll. Seite 13 von 44

In der folgenden Tabelle werden die Vor- und Nachteile von extern erworbener Standardsoftware aufgeführt.

Tabelle 3 Quelle: [4]

Bei dem aktuellen Projekt sprach darüber hinaus für den Erwerb von Standardsoftware, dass bereits von einem Anbieter mehrere Produkte vorhanden waren und somit ein gewachsenes Know-how über die Produktfamilie existierte. Des Weiteren erlaubte der angepeilte Termine des Echtbetriebes eine lange Entwicklungs- und Erprobungszeit nicht.

Anhand der unten aufgeführten Entscheidungsmatrix wird beurteilt, welche Vorgehensweise die richtige ist.

Tabelle 4

Ergebnis: Eine Bewertung ergab einen Kostenvorteil und eine strategischen Vorteil für Buy

Seite 14 von 44

6 Definition

Die BMW Group schreibt für jedes Softwaresystem, welches entwickelt und eingesetzt werden soll, eine Musterarchitektur vor. An dieser muss sich die Entwicklung orientieren.

Ein Hauptziel der Musterarchitektur besteht darin, IT-Projekten sofort nutzbare, betreibbare Musterlösungen als Kombination von harmonierenden Blueprint -Produkten zur Verfügung zu stellen.

Bei der Definition muss geprüft werden, in welchen Musterarchitekturen das jeweilige System einzuordnen ist. Falls nötig, muss das Projekt entsprechend der vorgegebenen Architektur angepasst werden. Eine Kombination mehrerer Architekturen ist allerdings auch möglich.

Bsp.:

Musterarchitektur DWH - Data Warehouse

Abbildung 2 Quelle: BMW Group Abteilung FZ-12

Die Anforderung welche an die Softwarelösung gestellt wurde machte es nötig die Musterarchitektur ‚Standart-Web Lösung’ und ‚Data Warehouse’ zu kombinieren.

Seite 15 von 44

Abbildung 3 Quelle: BMW Group Abteilung FZ-12

6.1 Datenmodell

6.1.1 Anforderungen

Die an das Datenmodell zu stellenden Anforderungen sind folgende:

• Messdaten müssen in ein DWH übertragen und verdichtet werden können

• Messdaten müssen über Namen, Monat und SLA-Namen identifizierbar sein

• Datenmodell muss übersichtlich sein

Das physikalische Modell stellt eine erhöhte Abstraktion da. Die einzelnen Messepunkte werden nicht in einzelnen Tabellen abgespeichert, sondern in einer gemeinsamen Tabelle und jeder Messewert wird mit einer Tabelle verknüpft, in der die jeweilige Messgröße eingetragen ist.

Dies hat den Vorteil, dass die Datenstruktur bei Hinzunahme von weiteren Messpunkten keine neuen Tabellen erstellt werden müssen, sondern die Messergebnisse in die bestehende Tabelle eingetragen werden können. Da die Daten von einem DWH verdichtet werden sollen, ist dies Modell nicht praktikabel,

Seite 16 von 44

Im logischen Modell wird zu jeder Messgruppe eine separate Tabelle angelegt. Dies hat den Vorteil, das anhand der Tabellen zu erkennen ist, um welche Art von Daten es sich handelt. Das Datenmodell wird deutlich übersichtlicher. Des weiteren muss bei der Übertragung in ein DWH keine Verarbeitungslogik zwischengeschaltet werden. Nachteilig bei diesem Modell ist allerdings, dass bei jeder Hinzunahme einer weiteren Messgruppe auch das Datenmodell verändert werden muss

6.1.2 Umsetzung des relationalen Modells

Als Beispiel für das relationale Datenmodell dient die Messgruppe ‚Servermeasure’. In ‚Servermeasure’ werden die Daten über CPU- und Speicherauslastung sowie die Anzahl der laufenden Jobs erfasst. Jeder Messwert ist einem Server und jeder Server ist wiederum einer Servergruppe zugeordnet.

Abbildung 4 Quelle: BMW Group Abteilung FZ-400

Seite 17 von 44

6.1.3 SQL-Views

Auf die Messwerte in der Datenbank mussten Sichten definiert werden, welche die relevanten Daten filtern und erforderliche Berechnungen durchführen. Nachfolgende Abbildung beschreibt die Sichtenhierarchie.

Abbildung 5

Seite 18 von 44

Anmerkung: Nach den bisherigen Erfahrungen muss überlegt werden, ob eine Implementierung über Cursor in einer PL/SQL-Umgebung nicht sinnvoller wäre. Durch die mehrfach notwendige Sortierung sämtlicher Daten ergibt sich eine sehr lange Verarbeitungszeit und ein sehr hoher Speicherverbrauch.

Seite 19 von 44

7 Data Warehouse (DWH)

7.1 Was ist ein DWH?

Ein Data Warehouse ist eine multidimensionale Datenbank, in der die Daten nicht als Tabellen sondern als Matrizen gespeichert werden. Bei genügend großen Datenmengen wird die Darstellung in Tabellenform sehr schnell unübersicht lich. Weiterhin sind Abfragen auf diese Tabelle sehr komplex. Will man beispielsweise die Summe der verkauften blauen Autos bestimmen, oder sich eine Übersicht über die Verkaufszahlen pro Fahrzeugtyp verschaffen, so muß das Datenbanksystem in beiden Abfragen die Tabelle von oben bis unten durchgehen.

Eine elegantere Möglichkeit, diese Tabelle darzustellen, ist die Matrixdarstellung.

Diese Darstellungsart hat folgende Vorteile:

1. Ein Benutzer erkennt sofort die Anzahl der in der Datenbank vorhandenen Ausprägungen einer Dimension (hier: Farbe und Fahrzeugtyp) 2. Für die im Text weiter oben genannten Auswertungen müssen nur Zeilenbzw. Spaltensummen gebildet werden. So müssen für die Anzahl aller verkauften blauen Autos nur die Werte der dritten Spalte addiert, für die

Seite 20 von 44

Verkaufszahlen der verschiedenen Fahrzeugtypen die entsprechenden Zeilensummen gebildet werden.

Die Matrixdarstellung läßt sich bezüglich der Dimensionen verallgemeinern. Durch die Hintereinanderordnung von mehreren Tabellen entsteht ein Datenwürfel. Mit dem Datenwürfel lassen sich jetzt zum Beispiel auch Fragen nach den

Gesamtverkäufen eines Aut ohändlers beantworten. In diesem Fall müßte nur der Inhalt der Zellen der gesamten Ebene des gewählten Händlers addiert werden.

7.2 Extraktion Transformation Laden (ETL)

In einem DWH werden Daten aus unterschiedlichen, meist heterogenen Datenquellen mittels eines ETL-Tools extrahiert, transformiert, harmonisiert, verdichtet und in das DWH geladen. Das Standarttool der BMW -Group ist für diesen Zweck das Softwareprodukt Powercenter© der Firma Informatica. Mit diesem Tool hat man die Möglichkeit auf unterschiedlichste relationale Datenbanken, Excel-Sheets, Access-Datenbanken, CSV-Dateien, usw. zuzugreifen.

Seite 21 von 44

Abbildung 7 Quelle [4]

7.3 Online Analytical Processing (OLAP)

Nachfolgend sind die Standardfunktionen aufgeführt, welche auf ein DWH zur Informationsfindung angewendet werden können.

• Pivoting (Erzeugen einer Kreuztabelle)

• Drill down (Anzeige eines größeren Detaillierungsgrads)

• Roll-up (Verringerung des Detaillierungsgrads)

• Drill through (Durchgriff auf weitere Daten, ggf. andere Dimensionen)

• Slice (Verringerung der dargestellten Dimensionen)

• Dice (Vertauschung der Dimensionen in der Ansicht)

7.4 Warum DWH und keine relationale Datenbank (RDB)?

Die anfallenden großen Datenmengen (z. B. allein 500.000 Datensätze täglich für den Serverbetrieb) machen es erforderlich, die Datenhaltung zu verdichten. Dadurch wird ein schnellerer Zugriff auf die Datensätze sichergestellt. Darüber hinaus verlangen viele in Frage kommenden Darstellungstools ein Data Warehouse als Datenquelle.

Seite 22 von 44

8 Realisierung

8.1 Auswahl der Software

In einer Entscheidungsmatrix werden die relevanten Entscheidungskriterien eingetragen und mit einer Wichtung verknüpft. Die Kriterien der einzelnen Produkte werden mit Schulnoten von 1-6 bewertet und ein Gesamtergebnis wird berechnet. Anhand dieses Ergebnisses kann man sich für die eine oder andere Lösung entscheiden. Diese Vorgehensweise hat darüber hinaus folgende Vorteile: für Dritte transparent, auch später noch nachvollziehbar.

Tabelle 7 Quelle: BMW Group Abteilung FZ-400

Die Entscheidung fiel nach einer Evaluierungsphase und einem dreitägigen Workshop auf die Produkte KPI Businesspack© der Firma Cognos.

8.2 Erforderliche Software für das Projekt

Um mit dem KPI Businesspack© die Daten wie gefordert darstellen zu können, sind noch einige Softwareprodukte erforderlich, die zur Aufbereitung der Messdaten benutzt werden. Diese Produkte waren schon im Softwarepool von BMW vorhanden, mussten daher nicht neu lizenziert werden und das entsprechende Kow How ist auch schon in der BMW Group vorhanden.

Seite 23 von 44

Nachfolgend werden die erforderlichen Produkte der Firma Cognos beschrieben und zwar

• Infromatika Powercenter ©

• Cognos Impromptu©

• Cognos Powerplay Transformer©

• Cognos Powerplay©

• Cognos KPI-Businesspack©

• Cognos Upfront©

8.2.1 Informatika Powercenter©

Informatica PowerCenter© ist eine Datenintegrationspaltform für Unternehmen. Es wird eingesetzt, um Datawarehouses zu erzeugen und zu verwalten. Mit Powercenter ist es möglich Daten von heterogenen Datenquellen zu extrahieren und harmonisiert in ein Datawarehouse einzufügen.

Abbildung 8 Quelle: www.informatica.com

Seite 24 von 44

8.2.2 Cognos Impromptu©

Impromtu© der Firma Cognos ist ein SQL-Query-Client mit dem es möglich ist, Abfragen auf relationale Datenbanken auszuführen und diese Abfragen in Abfragedefinitionen zu speichern.

Abbildung 9 Quelle: BMW Group Abteilung FZ-400

Seite 25 von 44

8.2.3 Cognos Powerplay Transformer©

Der Powerplay Transformer© dient dazu relationale Datenbanken in Data Warehouses zu überführen. Der Transformer benutzt die Abfragedefinitionen von Impromtu, um auf die relationalen Tabellen zuzugreifen. Im Transformer werden Hierarchien für den Drill-Through-Prozess definiert. Es wird festgelegt, welche Kennzahlen dargestellt werden und welche Operationen bei der Verdichtung ausgeführt werden sollen (Mittelwert-, Summenbildung, usw. ). Ferner wird ein Rechtekonzept aus einem LDAP-Server übernommen. Nach der Definition erstellt der Transformer einen Datenwürfel (Powercube).

Abbildung 10 Quelle: BMW Group Abteilung FZ-400

Seite 26 von 44

8.2.4 Cognos Powerplay©

Cognos Powerplay© dient dazu Powercubes auf anwenderfreundliche Weise zu betrachten. Es können Listenreports erstellt werden sowie 2D- bzw 3D-Grafiken betrachtet werden. Hier werden auch Slice & Dice, sowie die Drill Through-Operationen ausgeführt. Die Listen- bzw. Diagrammreports können abgespeichert werden, um später auf sie verweisen zu können.

Abbildung 11 Quelle: BMW Group Abteilung FZ-400

8.2.5 Cognos KPI Buisness-Pack©

Das Produkt ermöglicht eine hochverdichtete Darstellung von Kennzahlen über Ampelcharts - und ähnliche Darstellungsarten - mit zusätzlicher Anreicherung durch beliebige Report Objekte (Powerplay©, Impromptu©, Excel, etc.). Das System erlaubt die Erstellung von Logiken zur Verdichtung der Stati einzelner Kennzahlen zu Gruppierungen.

Seite 27 von 44

Mit einer graphischen Benutzeroberfläche wird eine hierarische Struktur für die Kennzahlen festgelegt. Diese Struktur besteht aus mehreren Gruppen und Untergruppen. Das niedrigste Element ist der eigentliche Messwert. Jedem Messwert werden Schwellwerte für die Stati grün, gelb und rot sowie eine Gewichtung für die BubbleUp-Funktion zugewiesen.

Es gibt mehrere Möglichkeiten Statuswerte aus tieferliegenden Messwertgruppen an die nächst höherliegende Gruppe zu übergeben.

1. Bubble up highest: Der höchste Wert (Status) wird an die darüberliegende Ebene übergeben.

2. Bubble up lowest: Der niedrigeste Wert (Status) wird an die darüberliegende Ebene übergeben.

3. Bubble up weighted: Jeder Wert bekommt eine Wichtung und anhand dieser Gewichtung wird der Status für die darüberliegende Gruppe errechnet. Bsp.:

In der Gruppe ‚Serverauslastung’ gibt es vier Messpunkt:

Tabelle 8

Der errechnete Wert ist 2,8 und somit wird der übergeordneten Gruppe ‚Serverauslastung’ der Status grün zugewiesen.

Seite 28 von 44

Abbildung 12 Quelle: BMW Group Abteilung FZ-400

Nachdem die Struktur fertig aufgebaut ist, wird ein Buildprozess gestartet, der sämtliche Daten in einem XML-Dokument speichert. Der anschließende Publishprozess erzeugt anhand von Templates HTML-Dateien, die entsprechend der vorgegebenen Struktur verlinkt werden.

Die Aufgabe der Templates wird in Abschnitt 8.3 ausführlicher beschrieben.

Seite 29 von 44

8.2.6 Cognos Upfront©

Cognos ist ein Webfrontend, welches für die Darstellung der Struktur, welche im KPI Businesspack© angelegt wurde, genutzt werden kann. Das System kann auf einen LDAP-Server zugreifen und somit ein Zugriffsrechtesystem implementieren. Im Rahmen des Projektes hat sich das Projektteam gegen die Verwendung des Upfront entschieden, da die gewünschte Flexibilität der Darstellung nicht realisierbar war.

Abbildung 13 Quelle: BMW Group Abteilung FZ-400

8.3 Customizing

Die Standardansicht, welche von Upfront und KPI Businesspack© angeboten wird, war für die geforderten Zwecke nicht ausreichend. Es fehlten die Anzeige der Schwellwerte, die Annäherung an die Schwellwerte, der Historienwerte und des Trends. Ferner sollte das Design an die Wünsche von BMW Group angepasst werden. Aus diesem Grund musste mit Hilfe der Formatierungssprachen UTML und KTML das Design angepasst werden.

Seite 30 von 44

8.3.1 KPD

Ein KPD-Dokument ist ein XML-Dokument , in welchem alle Daten, welche mit dem KPI Businesspack© erzeugt wurden, strukturiert abgelegt werden. Leider stimmt die Namensgebung der einzelnen Attribute nicht mit der Namensgebung des Datastores von Upfront und dem KPI Businesspack© überein(siehe 8.3.2).

Folgende Abbildung zeigt einen Ausschnitt der XML-Struktur des KPD-Files:

- name="d5578696-d551-11d6-a386-a84c88f1df16" build="true" weight="10"

isready="true" publish="true" priority="3" canrollup="true"

timestamp="2452589.959777765" updatefrequency="always">

Abbildung 14 Quelle: BMW Group Abteilung FZ-400 Seite 31 von 44

8.3.2 UTML (Upfront Template Markup Language)

UTML ist ein XSL-Dialekt, der dazu dient, die Gestaltung der HTML-Seiten in Upfront© zu manipulieren. Die in UTML erzeugten Templates greifen auf den Datastore von Upfront© zu. Dieser Datastore wird aus dem KPD-Dokument erzeugt. Wie bereits erwähnt, stimmen die Attributnamen aus dem KPD-File nicht mit den Variabelennamen des Datastore überein.

8.3.3 KTML (KPI Template Markup Language)

KTML ist ein von der Firma Cognos entwickelter XSL-Dialet. Diese Sprache war eigentlich nicht dazu gedacht, dass die Cognos-Kunden damit Ihr Customizing vornehmen. Da aber die Aufgabenstellung in UTML nicht zu lösen war, musste das Customizing in KTML vorgenommen werden. Erschwerenderweise gab es von der Firma Cognos keine Dokumentation zu dieser Sprache, so dass erst einmal eine eigene Dokumentation von dem Autor dieser Studienarbeit angefertigt werden musste. Ausschnitte aus der Dokumentation befinden sich im Anhang.

Seite 32 von 44

9 Darstellung im Intranet

In diesem Abschnitt wird beschrieben, wie mit der aufgebauten Infrastruktur gearbeitet wird und das Ergebnis des Projektes dargestellt.

9.1 Typischer Arbeitsablauf zum Einbinden neuer Kennzahlen in den Intranetauftritt

1. Es wird vorausgesetzt, dass die Messdaten sich in einer zentralen relationalen Datenbank befinden. Falls dies nicht der Fall ist, muss mittels eines ETL-Tools dafür gesorgt werden.

2. Falls erforderlich müssen auf diese Datenbank mittels SQL Sichten definiert werden.

3. In Cognos Impromtu© werden Abfragen auf die Tabellen oder die Sichten der zentralen Datenbank definiert. Diese Abfragen werden in Abfragedefinitionen gespeichert.

4. Der Cognos Powerplay Transformer© wird verwendet, um einen Datenwürfel für das Datawarehouse zu erstellen. Im Datenwürfel müssen die Dimensionen, die Verdichtungsoperationen und die Hierarchieebenen festgelegt werden.

5. Diese Datenwürfel werden in Cognos Powerplay© geladen. Die erforderlichen Ansichten werden durch Slice & Dice - bzw. Drill Through -Operationen erzeugt und gespeichert.

6. In Cognos KPI Business Pack© wird ein neues Business Pack geladen oder ein bestehendes geöffnet. Es werden Messgruppen angelegt, auf Daten- und Reportquellen verwiesen und Schwellwerte und ggf. Wichtungen für Bubble Up -Funktion zugewiesen. Anschließend werden in dem Buildprozess die Messgruppen und Kennzahlen in das XML-Dokument geschrieben. Zum Schluss wird der Publish-Prozess ausgeführt, der die HTML-Dokumente erzeugt und auf den Webserver kopiert. 7. Das Ergebnis kann im Webbrowser betrachtet werden.

Seite 33 von 44

9.2 Ergebnis

Auf der Startseite sieht man die vier Kategorien mit den entsprechenden Stati. Man kann erkennen, dass in den Kategorien ‚Technisch’ und ‚Kunden’ eine Überschreitung bzw. eine Annäherung an den Schwellwert stattgefunden hat. Die Zahl in Klammern nach dem Kategorienamen zeigt an, wie viel Untergruppen sich in der Kategorie befinden.

Abbildung 16 Quelle: BMW Group Abteilung FZ-400

In der nächste Ebenen erscheinen sowohl neue Messgruppen, wie auch aktuelle Kennzahlen. Die Kennzahlen haben einen aktuellen Wert, sowie einen vereinbarter Zielwert.

Seite 34 von 44

Abbildung 17 Quelle: BMW Group Abteilung FZ-400

In der Detailansicht stehen dem User weitere Informationen zur Verfügung. Es ist möglich Historienwerte und von Cognos Powerplay erzeugte Reports zu betrachten

Abbildung 18 Quelle: BMW Group Abteilung FZ-400

Seite 35 von 44

9.3 Wurden die Projektziele erreicht?

Zum Zeitpunkt des Verfassens dieses Berichtes wurde folgende Ziele erreicht:

• Dateninfrastruktur aufgebaut

• Erforderliche Software eingeführt und angepasst

• Know-how über die erforderliche Software erworben

• Erforderliche Arbeitsabläufe definiert.

• Die Datenhaltung teilweise befüllt

Folgende Aufgaben stehen noch aus:

• Dateninfrastruktur: wenn erforderlich, anpassen

• Befüllung der Datenhaltung abschließen

Die Abteilung kam zu dem Schluss, dass die Projektziele erfolgreich umgesetzt worden sind.

Seite 36 von 44

10 Persönliche Erfahrung

Für mich war die Möglichkeit, von Anfang an bei einem solchen Projekt aktiv mitzuarbeiten eine sehr gewinnbringende Erfahrung. Ich habe miterlebt, wie eine konzeptionelle Idee schrittweise Gestalt annahm und schlussendlich realisiert wurde.

Äußerst interessant war für mich, zu beobachten, wie sich in der Evaluierungsphase die einzelnen Softwareanbieter präsentiert haben und wie über Preis und Leistung verhandelt wurde.

Ich habe mitbekommen, wie die abteilungsübergreifende Arbeit bei der BMW Group ablaufen kann und welche Herausforderungen sich dabei ergeben können, die im Rahmen der Projektarbeit zwingend gelöst werden müssen.

Sehr lehrreich war, immer wieder dazu angehalten zu werden, vor jeder Arbeit sich erst genaue Gedanken über das geforderte Ergebnis zu machen. Die Arbeit muss entsprechend strukturiert werden. Konzeptloses Arbeiten kann bei einem so großen Unternehmen wie der BMW Group schnell in eine Sackgasse führen und ist unproduktiv.

Alles in allem fand ich die Arbeit bei der BMW Group sehr interessant und aufschlussreich.

Seite 37 von 44

11 Glossar

12 Anhang

12.1Dokumentation zu KTML

Nachfolgend ist ein Auszug aus der vom Autor erstellten Dokumentation abgebildet.

12.1.1 Variablen

12.1.2 Kontrollstrukturen

13 Quellen

[1] Intranet der BMW Group [2] Referat Data Warehouse: Konzeption, technische Elemente, Nutzen und Kosten von Stephan Wiesebach [3] Präsentation IT-Kennzahlen von D. Bieber BMW Group [4] Vorlesungsskript Betriebliche Informationssystem von Dr. Peter Lüders [5] Business Intelligence, Grothe, Gentsch, Verlag Addison-Wesley [6] Cognos Upfront Developer Guide [7] www.wissen.de

Seite 44 von 44