Business Intelligence - auch für die IT

Die Zeiten, in denen der Einsatz von Lösungen für Business Intelligence (BI) und Corporate-Performance-Management (CPM) auf die Bereiche Finance and Controlling beschränkt war, sind in den meisten Unternehmen vorbei. Längst werden die Möglichkeiten leistungsstarker BI-Werkzeuge für Reporting und Analyse sowie verstärkt auch für die Planung in anderen Unternehmensbereichen genutzt, so etwa vom Sales und Marketing bis hin zur Personalabteilung. Ferner herrscht weitgehend Konsens darüber, dass sich die Bündelung von BI-Kompetenzen in Business Intelligence Competence Centern (BCC) vorteilhaft auf Effektivität und Effizienz der Informationsversorgung auswirkt. Dies hat bereits in vielen Unternehmen zu einer Neuausrichtung der operativen Umsetzung der BI-Strategie geführt. Diese Umstrukturierungen gehen meist einher mit einer Zusammenführung der gewachsenen, heterogenen Insellösungen verschiedener BI- und Data-Warehouse-Implementierungen. Doch obwohl diese Konsolidierungs- und Zentralisierungsmaßnahmen oft in der Verantwortung der IT liegen, könnte gerade dieser Unternehmensbereich die genannten Erkenntnisse häufig noch wesentlich besser umsetzen, als es bisher geschieht.

Reporting nur punktuell

Exemplarisch soll hier auf das Application-Lifecycle-Management (ALM) von Software und Systemen eingegangen werden. In den einzelnen Phasen der Entwicklung und des Betriebs sowie in den verschiedenen beteiligten Teams wird eine Vielzahl unterschiedlicher Software eingesetzt. Dies reicht von Werkzeugen zum Portfolio- und Projekt-Management über Anforderungs- und Defect-Management-Lösungen bis hin zu Tools zur Überwachung des Betriebs und der Einhaltung von SLAs. Dabei wird zur Gewinnung und Analyse der Informationen auf breiter Front auf die Auswertungsmöglichkeiten zurückgegriffen, die direkt von den verwendeten Werkzeugen bereitgestellt werden. Die Nutzung der integrierten Reporting-Möglichkeiten hat selbstverständlich ihre Vorteile. Für einen ausgewählten Adressatenkreis sind die gewünschten Informationen, häufig mit Hilfe vordefinierter Reports, schnell und einfach abrufbar.

Allzu schnell stößt man jedoch mit diesen "Bordwerkzeugen" an Grenzen. Werkzeug- und damit bereichs- oder domänenübergreifende Auswertungen und die Integration der Informationen in einen erweiterten Kontext sind damit nur schwer möglich. Was sind die Folgen? Aufgrund der vielen, unzusammenhängenden Einzelinformationen, die wegen des gesteigerten Aufwands ihrer Beschaffung und Aufbereitung zudem oft nicht schnell genug bereitgestellt werden können, erhöht sich das Risiko, falsche oder zumindest suboptimale Entscheidungen zu treffen. Verschiedene Formate und die Herkunft von Daten aus unterschiedlichen Quellen erschweren die Vergleichbarkeit. In der Konsequenz ergeben sich zum Teil gravierende Informationsdefizite. Der Status sowie die Effektivität und Effizienz von Prozessen und Methoden der Projekte können kaum noch objektiv beurteilt werden. Insgesamt verlagern sich die Aktivitäten vom Agieren aufs Reagieren, gleichzeitig kann die Wirksamkeit von gegensteuernden Maßnahmen nur schwer bewertet werden.

Aus Sicht der beteiligten Entscheider (von Team- und Teilprojektleitern bis hin zur Geschäftsführung) sind dies nur schwer hinzunehmende Einschränkungen. Höchste Zeit also, das Prinzip von Business Intelligence, die richtigen Informationen zum richtigen Zeitpunkt in der richtigen Form zur Verfügung zu stellen, auch auf das ALM anzuwenden. Dabei sollten natürlich die bereits im Unternehmen vorhandenen BI-Applikationen zur Anwendung kommen und die vorhandenen Governance-Richtlinien, Kompetenzen und Erfahrungen genutzt werden.

Beispiele für Ziele, Kennzahlen und Dimensionen für einige Domänen des ALM

Domäne	Ziele	Kennzahlen	Dimensionen
Requirements-Management	• Stabile Anforderungen • Kontrollierte Änderungen • ...	• Anforderungen (#) • Änderungen (#) • Requirements Churn • ...	• Zeit • Programme • Projekte • Projektphasen/Iterationen/Sprints • Teams • Priorität (Anforderung/Test/Defect) • Fehlerkategorien • ...
Test-Management	• Vollständige Testabdeckung • Erfolgreiche Testabwicklung • Berücksichtigung Testaufwand • ...	• Testfälle/Anforderung • Testfälle (#) • Aufwand/Testfall • Automatisierungsgrad • Fehlgeschlagene Regressionstestfälle • ...	Defect-Management
• Zeitnahe Fehlerbehebung • Nachhaltige Fehlerbehebung • ...	• Defects (#) • Dauer Fehlerbehebung • Erfolgreiche Nachtests • ...

Konzeptionelle Vorarbeit

Wie bei allen BI-Projekten muss man sich vor Beginn der technischen Umsetzung intensiv mit den Anforderungen auseinandersetzen und die entsprechende konzeptionelle Vorarbeit leisten, um sicherzustellen, dass wirklich nur die relevanten Informationen aus den Quellsystemen in das Datenmodell integriert werden. Ausgangspunkt auf dem Weg zu den Kennzahlen und den zugehörigen Dimensionen sollten analog zu dem von Ralph Kimball vorgeschlagenen Vorgehen die zu steuernden Prozesse und die dabei jeweils verfolgten Ziele sein.

Aus Sicht des Anforderungs-Managements wäre dies etwa eine möglichst geringe Änderungsrate der in den nächsten Entwicklungszyklen umzusetzenden Requirements.

Ein Ziel des Release-Managements wäre beispielsweise, in einem neuen Release die Stabilität der bereits implementierten Funktionen sicherzustellen.

Als Ziel des Defect-Managements lässt sich wiederum die schnelle Bearbeitung und Behebung der gefundenen Fehler formulieren.

Erste Kennzahlen

Somit wären als erste Kennzahlen bereits die Zahl bestehender, neuer und geänderter Anforderungen, die Fehlerzahl in den Regressionstests sowie die Zahl und Bearbeitungszeiten von Defects identifiziert. Anschließend sind die gefundenen Kennzahlen auf die sie charakterisierenden Attribute hin zu analysieren, um daraus auf die Dimensionen zu schließen. Neben der "obligatorischen" Zeitdimension wären dies im ALM insbesondere die Releases oder Entwicklungszyklen und die Komponenten oder fachlichen Bereiche der Software. Relevante Filterkriterien für Anforderungen und Defects sind insbesondere Klassifizierungen nach Priorität, Kritikalität oder Risikoklasse.

Beim Aufbau des Datenmodells sollte man dabei dem Prinzip der "shared dimensions" folgen, nach dem identische Dimensionen, die für mehrere Kennzahlen relevant sind, für diese Metriken "wiederverwendet" werden. Auf diese Art lassen sich die Metriken der Data Marts einzelner Teildomänen miteinander vernetzen, so dass domänenübergreifende Auswertungen zur Analyse von Kausalzusammenhängen möglich werden.

Ein Praxisbeispiel wäre die Ursachen-analyse eines sprunghaften Anstiegs der in der Testphase eines Release gefundenen Defects. Möglicherweise ist dies auf eine besonders hohe Änderungsrate von bestehendem Code in der vorhergehenden Entwicklungsphase zurückzuführen? Oder ist die hohe Fehlerrate durch viele Changes an den Anforderungen der Iteration begründet? Ein entsprechendes Datenmodell erlaubt es, Zusammenhänge zu identifizieren, mit denen sich die Fragen beantworten lassen.

Komplexe ETL-Prozesse

Parallel zur Ermittlung der Kennzahlen und Dimensionen und dem Aufbau des entsprechenden Datenmodells erfolgt das Mapping der bereitzustellenden "fachlichen" Informationen auf die in den Quellsystemen vorhandenen Datenstrukturen sowie eine konzeptionelle Ausarbeitung der ETL-Prozesse für die Datenextraktion.

Bei allen Vorteilen kann mit der Einbindung von IT-Domänen wie der Softwareentwicklung in die bestehende Business-Intelligence- beziehungsweise Data-Warehouse-Landschaft ein erheblicher Aufwand verbunden sein. Insbesondere die Komplexität der ETL-Prozesse zur Integration der Datenquellen der vielen einzelnen Case-Tools sollte nicht unterschätzt werden. Unternehmen, die dies planen, sollten daher gezielt mit den Disziplinen beziehungsweise Applikationen beginnen, in denen besonders gravierende Informationsdefizite bestehen und in denen durch eine Verbesserung der Informationsversorgung der größte Mehrwert erzielt werden kann.

Besonders komfortabel wäre es natürlich, die Konzeption und technische Umsetzung einer BI-Infrastruktur für den IT-Bereich in einer Out-of-the-Box-Lösung vorgefertigt präsentiert zu bekommen. Das verspricht beispielsweise IBM mit ihrer Lösung "Rational Insight". Tatsächlich erhält der Kunde damit ein umfangreiches Paket, das die wichtigsten Komponenten einer Informationsplattform für die Analyse der ALM-Prozesse enthält. Herzstück ist die Performance-Management-Lösung von Cognos. Hinzu kommt vordefinierter Content zur Analyse von Daten aus den Bereichen Anforderungen, Architektur, Prozess und Portfolio, Qualität sowie Änderung und Freigabe.

Den Kern von Rational Insight bildet das Rational Insight Data Warehouse (RIDW) in Form eines vordefinierten, offenen Schemas zur normalisierten, auswertungsoptimierten Speicherung der Daten aus den Quellsystemen. Das RIDW lässt sich auf DB2, Microsofts SQL Server oder einer Oracle-Datenbank bereitstellen. Zur Extraktion, Transformation und zum Laden der Daten ins RIDW steht der Cognos Data Manager zur Verfügung. Die erforderlichen ETL-Prozesse werden für die hauseigenen Rational-Produkte gleich mitgeliefert, aber auch vordefinierte Schemata etwa für Microsoft Project sind vorhanden. Durch die offene REST-Architektur lassen sich weitere Datenquellen anschließen.

Cognos Framework Manager

Die Verwaltung der Metadaten erfolgt im Cognos Framework Manager. In diesem werden die fachlichen Auswertungsobjekte wie Kennzahlen und Dimensionen, die in den Berichts- und Analyse-Tools des Frontends verwendet werden, auf Basis der Daten im RIDW modelliert. Durch die Bildung dieser Business-Sicht auf die Daten wird von den einzelnen Tabellen und den Schemata der Datenbankebene abstrahiert. Zusätzlich zu den Daten im Data Warehouse lassen sich auch weitere, operative Datenquellen hier direkt einbinden und den Berichtserstellern und Analysten zur Verfügung stellen. Die Metadaten-Modelle für die Rational-Produkte sind ebenfalls enthalten. Bei Bedarf sind die Framework-Manager-Modelle anpassbar, was bei den üblichen kundenspezifischen Modifikationen der Objekte in den einzelnen Werkzeugen ohnehin erfolgen müsste.

Schließlich stehen mit dem Berichts-Server von Rational Insight als einer Instanz des Cognos-BI-Servers die zentralen Komponenten für Business Intelligence zur Verfügung: Report Studio, Query Studio, Cognos Connection und Cognos Administration. Report Studio bietet eine professionelle Report-Erstellung. Die darin vordefinierten Auswertungen werden den Anwendern in dem Web-Frontend von Cognos Connection bereitgestellt, worin sich mittels Query Studio auch individuelle Ad-hoc-Abfragen erstellen lassen. Noch einmal vereinfacht wird der Start mit Rational Insight durch ein ganzes Bündel vordefinierter Reports und Dashboards. Statt "auf der grünen Wiese" anfangen zu müssen, können auf Grundlage der bereits enthaltenen Auswertungen die eigenen Informationsanforderungen abgeleitet und angepasste Reports und Dashboards erstellt werden.

Fazit

Es ist höchste Zeit, die in einem Unternehmen bestehenden BI-Ansätze auf den Bereich des Application-Lifecycle-Managements auszudehnen. Wie bei allen Business-Intelligence-Projekten kann dies zu Beginn mit erheblichem Aufwand verbunden sein. Doch gerade für große Entwicklungsvorhaben sollten Unternehmen kalkulieren, ob sich diese Investition in eine verbesserte Transparenz und Steuerbarkeit ihrer IT-Projekte nicht sehr schnell rentieren wird. Dies gilt natürlich besonders für solche Unternehmen, in denen die Entwicklung von Software und Systemen zum Kerngeschäft zählt. (ph)