Die Erfolgsfaktoren eines Business Intelligence (BI) Projekts sind identisch mit jenen eines Data Warehouse (DWH) Projekts, denn ein BI-Projekt baut in der Regel auf einem Data Warehouse auf. Das DWH sammelt und berechnet Daten, das BI analysiert diese und wertet sie aus.

Technologie und BI-Produkte sind eine wichtige Grundlage, im Zentrum stehen aber die Kennzahlen. Diese Kennzahlen müssen vom Business definiert und danach von der Entwicklung umgesetzt werden. Dieses Zusammenspiel birgt Potential für Missverständnisse – daher ist die Kommunikation und Zusammenarbeit im gemischten Team von Business und Technik wichtig. Wie diese Zusammenarbeit gefördert werden kann und welche weiteren Faktoren in den unterschiedlichen Prozessphasen wichtig sind, wird in den nächsten Abschnitten beschrieben.

Anforderungen: «Die Benutzer haben das Sagen.»

Ziel muss es sein, die richtigen und wichtigen Kennzahlen so darzustellen, dass diese möglichst intuitiv genutzt werden können. Daten, welche keinen Mehrwert bringen, sollen konsequent weggelassen werden. Damit alle vom Gleichen sprechen, ist es wichtig, in einer Schulung die Konzepte und Grundlagen eines DWH zu vermitteln. Für den ersten Entwicklungsschritt ist es ratsam, kleine und klar definierte Anforderung umzusetzen.

Architektur: «Think big, start small.»

Im Laufe des Aufbaus eines DWHs werden ständig neue Kennzahlen gefordert. Die DWH-Architektur muss deshalb skalierbar sein. Es lohnt sich, von Anfang an auf eine Standardarchitektur zu setzen. Daten, welche für die Auswertungen und Analysen nicht zwingend benötigt werden, erhöhen lediglich die Komplexität des Systems und gehören nicht ins DWH. Deshalb gilt hier: weniger ist mehr. In diesem Sinn ist auch eine Archivierung nur dann sinnvoll, wenn sie zu Analysezwecken gebraucht wird.

Releaseplanung: «In kleinen Schritten zum Ziel.»

Ein Projekt wird in einzelne Releases unterteilt. Neue Anforderungen werden gesammelt und je nach Priorisierung in einen früheren oder späteren Release verpackt. Während das Business den Kundennutzen sicherstellt, schätzt die Entwicklung den Aufwand für die Umsetzung ab. Der Aufwand ist am einfachsten in Komplexitätsstufen zu definieren. In der Entwicklungsmethode SCRUM wird diese Komplexität in Story Points beschrieben.

Implementation: «Wir ziehen am gleichen Strick in dieselbe Richtung.»

Die Grundpfeiler dazu sind Transparenz und eine offene Kommunikation. Die agile Entwicklungsmethode SCRUM fördert eine solche Arbeitskultur. Offene Aufgaben eines Releases können vom Entwickler frei gewählt werden. Das stärkt die Selbständigkeit und motiviert. Hindernisse werden zeitnah im Team angesprochen und gelöst. Dies erhöht die Effizienz und verbessert die Qualität der Resultate.


Tipps für BI-Projekte:
Agile Zusammenarbeit zwischen Technik und Business
Schulung der Konzepte und Grundlagen DWH
Standardarchitektur
Weniger ist mehr: nur was nötig ist
Kleine Schritte
Zeitnahe Tests

Testing: «Ein erfolgreiches Testing findet die Fehler.»

Die häufigsten Fehler rühren daher, dass das Entwicklungsteam etwas anderes versteht und umsetzt, als das Business meint. In einem ersten Schritt zeigen sogenannte Regressionstests auf, ob die bisherige Funktionalität weiterhin fehlerfrei läuft. Diese Tests können einfach automatisiert werden. In einem zweiten Schritt wird die neue Funktionalität getestet. Für einen vollständigen Abschluss des Releases sind die Funktionalitätstests durch das Business zentral. Zeitnahes Testen durch kurze Release-Zyklen bringt den Vorteil, dass die Definition der Anforderungen noch präsent ist. Die zu testende Funktionalität bleibt überschaubar. Dieser Prozess verlangt eine gute Zusammenarbeit zwischen Entwicklung und Business. Kurze Kommunikationswege und ein offener Umgang mit Fehlern helfen dabei. Der erfolgreiche Test wird zum gemeinsamen Ziel.

Benutzerschulung: «Wer ein System kennt, kann dieses auch nutzen.»

Wenn der Benutzer beim Erarbeiten einer neuen Funktionalität von Anfang an mit im Boot sitzt, wird ihm später der Gebrauch wesentlich einfacher fallen. Das hat auch zur Folge, dass das Business in die Entwicklung integriert wird und deshalb die Benutzerschulung gleich selbst durchführen kann.

Agile Softwareentwicklung

Die Erfolgsfaktoren der einzelnen Prozessschritte können in technische und methodische eingeteilt werden. Bei den methodischen Erfolgsfaktoren stehen die kurzen Release-Zyklen mit übersichtlicher Funktionalität und die gute Zusammenarbeit im Vordergrund. Es wird dadurch möglich, auf Änderungen der Anforderungen relativ informell und schnell zu reagieren. Dieses Vorgehen entspricht dem Grundprinzip der agilen Softwareentwicklung wie SCRUM. Es zeigt sich, dass die agile Softwareentwicklung auch oder gerade im Bereich des DWH von Vorteil ist. Gerade bei einem DWH ist anfangs oft unklar, welche Kennzahlen interessant sind und mit einem vernünftigen Aufwand umgesetzt werden können. Deshalb ist es wichtig, dass rasch Resultate sichtbar gemacht und weitere Ziele festgelegt werden können. Nur ein DWH, das sich entwickeln kann, wird auch genutzt. Oder anders gesagt: ein DWH, das genutzt wird, muss sich weiter entwickeln und neuen Anforderungen anpassen können.

Fazit: «Jedes Unternehmen hat eigene Anforderungen.»

Die Anforderungen in einem BI/DWH-Projekt sind von Unternehmen zu Unternehmen unterschiedlich. Jedes Unternehmen weist unterschiedliche Kennzahlen und Quellsysteme auf. Unter diesen Voraussetzungen wird ein BI/DWH-Projekt zu einem individuellen Projekt mit grossem Entwicklungsanteil. Deshalb gelten in einem DWH viele Erfolgsfaktoren aus der Softwareentwicklung generell und nur einige sind DWH-spezifisch. Das bedingt, dass die Projektverantwortlichen neben technischem und unternehmerischem Fachwissen auch vertiefte Kenntnisse in der Durchführung von Software-Projekten mitbringen.

Dr. Andrea Kennel, Dr. sc. techn (Informatik) sowie eMBA
Geschäftsführerin InfoPunkt Kennel GmbH

langjährige Erfahrung in BI Projekten
sowohl in der Projektleitung als
auch in der Umsetzung
andrea (at ) infokennel.ch
www.infokennel.ch