Aufbau eines Spend-Cubes
Im Projektbeispiel stellte der Aufbau eines konsolidierten Spend-Cubes die größte Herausforderung dar. Das Unternehmen verfügte über eine IT-Landschaft bestehend aus mehreren nicht harmonisierten ERP-Systemen und zahlreichen weiteren Lösungen. So befinden sich beispielsweise die Einkaufsstammdaten nicht direkt im ERP-System. Um alle definierten Kennzahlen berechnen zu können, war es notwendig neben den Transaktionsdaten aus unterschiedlichen SAP-Modulen und weiteren ERP-Systemen die Einkaufsstammdaten in einem Spend-Cube zusammenzuführen. Dazu wurde ein Spend Cube in einem Data Warehouse aufgebaut.
Um sicherzustellen, dass die richtigen Informationen in der korrekten Form vorhanden sind, musste für jede Kennzahl im Detail definiert werden, welche Informationen aus welchem System für die Berechnung der Kennzahl herangezogen werden soll. Dazu waren Termine mit Experten und Key-Usern der einzelnen Systeme notwendig. Dabei stellte sich immer wieder heraus, dass einzelne für die Berechnung von Kennzahlen notwendige Informationen systemseitig nicht vorhanden sind oder es Sonderfälle gibt, die dazu führen, dass ein korrektes Ergebnis der Kennzahl nicht garantiert werden kann. Um diese Schwierigkeiten zu beheben, war es notwendig, diverse Datenmanipulationen bzw. -selektionen direkt im Spend-Cube auszuführen.
Aufgrund der Komplexität des Spend-Cubes und der Vielzahl an Daten aus unterschiedlichen Systemen sowie der umfangreichen Nebenrechnungen war es von großer Bedeutung für den Projekterfolg ein umfangreiches Testkonzept zu entwickeln. Ziel war es bereits in einem möglichst frühen Entwicklungsstadium erste Plausibilisierungstests durchzuführen. Es wurde ein vierstufiges Testkonzept bestehend aus Modul-, Integrations-, Funktions- und Akzeptanztests erarbeitet.
- Beim Modultest wurden einzelne Berechnungen und Funktionen des Spend-Cubes entwicklungsbegleitend direkt von dem zuständigen Entwickler mit einfachen Beispielwerten getestet. So wurde beispielsweise bei Berechnungen überprüft, ob das Ergebnis aus technischer Sicht valide ist. Die Module werden in der Regel unabhängig von anderen Funktionen getestet. Es wird lediglich aus technischer Sicht überprüft, ob die Berechnung die Vorgaben erfüllt.
- Im Funktionstest wurde hingegen getestet, inwieweit die erzielten Ergebnisse auch aus inhaltlicher Controlling- bzw. Einkaufssicht plausibel sind.
- Der Integrationstest diente dazu zu überprüfen, ob die einzelnen Module des Spend-Cubes sowohl technisch als auch inhaltlich korrekt ineinander griffen. Hierbei konnten erstmals Schwierigkeiten in den Schnittstellen identifiziert und anschließend korrigiert werden. Für Funktions- und Integrationstest wurden Experten aus dem Projektteam aus den Bereichen Controlling und Einkauf hinzugezogen.
- Der Akzeptanztest stellte die letzte große Testphase dar. Hierbei wurde ein kompletter End-to-End-Test des gesamten Systems von mehreren Benutzern aus Endusersicht durchgeführt.