Als es bei einem Kunden hieß, dass das bestehende Datenmodell komplett neu aufgesetzt werden soll, galt es natürlich auch die dazugehörige DeltaMaster-Anwendung neu zu gestalten. Es mussten die bestehenden Berichte analysiert werden – welche Berichte können übernommen werden, welche bieten Optimierungspotenziale? Dabei sind wir auf einen Bericht gestoßen, der für viele Endanwender essenziell war und ist. In dem Bericht wird die gesamte Wertschöpfungskette der konzerninternen IT-Dienstleistungen dargestellt. Aufgrund der Komplexität des Sachverhalts war der Bericht jedoch sehr fragil und nahezu unmöglich wartbar. Hinzu kam, dass die gesamte Wertschöpfungskette aufgrund der Modellierung im neuen Modell nicht mehr in einem Bericht dargestellt werden konnte.

Es stellte sich also die Frage, wie können wir den Sachverhalt möglichst komfortabel für den Endanwender abbilden und dabei im Vergleich zur alten Lösung einen Mehrwert generieren. Die Lösung wird in diesem Blogbeitrag vorgestellt und auf die elementaren Bestandteile heruntergebrochen, um einen Leitfaden für die Darstellung von Wertschöpfungsketten zu entwickeln.

Beschreibung der Ausgangslage

Damit das im Folgenden vorgestellte Beispiel besser nachvollzogen werden kann, soll an dieser Stelle die Wertschöpfungskette erklärt werden.

Abbildung 1: Wertschöpfungskette

Der Abbildung 1 kann der gesamte Prozess der Wertschöpfung, der für das Beispiel relevant ist, entnommen werden. Am Anfang stehen immer die Werksaufträge (WA), die die Technischen Service Varianten (TSV) „befüllen“. Die Technischen Service Varianten wiederum können entweder in einen Business Service (BS), der das „Endprodukt“ darstellt, oder in eine im Prozess nachgelagerte Technische Service Variante eingehen. Eine Technische Service Variante stellt aber niemals das „Endprodukt“ dar. Kostenstellen stellen den Endkunden dar. Sie beziehen ausschließlich Leistungen aus Business Services, wie beispielsweise einen Telefonanschluss, Zugang zum ERP-System oder Speicherplatz in der Cloud, und werden entsprechend der jeweiligen Herstellkosten der einzelnen Bestandteile des Business Services über die interne Leistungsverrechnung abgerechnet.

Jedem „Teilprodukt“ oder „Endprodukt“ ist ein verantwortlicher Manager zugeordnet, der den Leistungsbezug plant und die Abrechnung steuert. Für diese ist zum Beispiel interessant, welche Kunden durch eine Erhöhung oder Verringerung der Herstellkosten eines Werksauftrag oder einer Technischen Service Variante in welcher Höhe betroffen sind oder einfach eine Übersicht welche Business Services indirekt von einem bestimmten Werksauftrag beliefert werden.

Wie soll nun dieser Prozess möglichst einfach und intuitiv in DeltaMaster dargestellt werden? Zunächst haben wir uns von dem Gedanken verabschiedet, alles in einem Bericht darzustellen. Jeder Schritt der Kette hat seinen eigenen Bericht (Abbildung 2) bekommen. Diese Berichte wurden mit Hilfe von Verknüpfungen miteinander verbunden, da eine Nutzung der Navigation aufgrund der Fragstellungen und dem Ziel eines möglichst einfachen Berichtsdesigns nicht zielführend war.

Abbildung 2: Berichtsliste

Umsetzung

Am Beispiel des Weges von einer Technischen Service Variante zu einem Business Service soll inklusive der hierbei zu berücksichtigenden Besonderheiten der Berichtsbau erläutert werden. Aus Datenschutzgründen dürfen die verwendeten Screenshots keine Zahlen wiedergeben und es dürfen keine Bezeichnungen der Elemente oder Namen der verantwortlichen Manager angezeigt werden.

Startpunkt soll der Bericht sein, der die Verteilung der Technischen Service Varianten auf weitere Technische Service Varianten oder Business Services darstellt (Abbildung 3). In der Startansicht werden für den TSV-Manager, Empfänger-TSV und Business Services die All-Member angezeigt, um die Bildung von Kreuzprodukten und damit sehr langen Berichten zu verhindern. Die Sender-TSVs werden auf der vorletzten Hierarchieebene Technischer Service angezeigt, um die Länge des Berichts im Rahmen zu halten. Dieser Aufbau, dass in der Startansicht nur für die Dimension, die in dem jeweiligen Bericht im Fokus stehen soll, Elemente angezeigt werden, findet sich in allen Berichten, die zu der Analysekette gehören, wieder.

Abbildung 3: Schritt 1

Über eine Verknüpfung im Zeilenkopf (Abbildung 4) können zu einem ausgewählten Technischen Service die darunter liegenden Varianten angezeigt werden (Abbildung 5).

Abbildung 4: Verknüpfung zu Schritt 2

Abbildung 5: Schritt 2

Bei dieser Verknüpfung sind Start- und Zielbericht der gleiche Bericht, nur wird der Bericht jetzt auf den Technischen Service der Zeile, aus der man abgesprungen ist, gefiltert. Es wäre also auch möglich diese Ansicht über das Setzen eines Filters zu erreichen. Auf das Anzeigen weiterer Informationen wird noch verzichtet, da einige Technische Services sehr viele Technische Service Varianten haben können und in diesem Fall das Anzeigen weiterer Informationen schnell zu einem unübersichtlichen Bericht führen kann.

Aus dieser Ansicht ist wieder ein Absprung vom Zeilenkopf möglich (Abbildung 6), der dem Leser die TSV-Verteilung der Technischen Service Variante der ausgewählten Zeile in weitere Technische Service Varianten und/oder Business Services anzeigt (Abbildung 7).

Abbildung 6: Verknüpfung zu Schritt 3

Dieser Absprung funktioniert nach dem gleichen Prinzip, wie der vorherige Absprung und hätte auch durch das direkte Setzen eines Filters ohne den Zwischenschritt erfolgen können. Voraussetzung hierfür wäre jedoch, dass gezielt nach einer bestimmten Technischen Service Variante gesucht wird und die Analyse nicht von Abweichungen oder Veränderungen getrieben ist, die erst beim Betrachten des Berichts auffallen. In diesem dritten Schritt werden alle Technischen Service Varianten und Business Services angezeigt, die von der ausgewählten Technischen Service Variante „befüllt“ werden. Außerdem wird der verantwortliche TSV-Manager angezeigt.

Neben der Suche nach einer bestimmten Technischen Service Variante, wäre es auch möglich nach einem TSV-Manger zu filtern. In diesem Fall erhält man die gleiche Ansicht, wie im dritten Schritt, mit dem Unterschied, dass alle Sender-TSVs, die von der ausgewählten Person verantwortet werden, angezeigt werden. Der entsprechende Zeilenaufriss wird mit Hilfe von dynamischem MDX über eine Fallunterscheidung der ausgewählten Filterelemente gesteuert. Hierbei werden jedoch ausschließlich die <view>-Referenzen genutzt. Die Crossjoin- und Generate-Funktionen werden bewusst vermieden.

Abbildung 7: Schritt 3

In einem letzten Schritt wird in diesem Beispiel die BS-Struktur eines Business Services betrachtet, der von der betrachteten Technischen Service Variante befüllt wird (Abbildung 8).

Abbildung 8: Verknüpfung zu Schritt 4

Mit dieser Verknüpfung gelangt man in einen neuen Bericht (Abbildung 9). In diesem Bericht ist der Business Service das zentrale Element. Wird dieser Bericht durch einen Absprung aufgerufen, ist er auf den Business Service des Absprungs gefiltert. Bei einem Absprung werden jedoch auch die Zeilenelemente für den Sender-TSV, Empfänger-TSV und TSV-Manager übernommen. Der Filter auf das TSV-Sender-Element wird jedoch durch die Definition in der Achse übersteuert. Diese Möglichkeit gibt es für Empfänger-TSV und TSV-Manager nicht, da diese nicht in den Zeilen angezeigt werden.

Der hier angezeigte TSV-Manager ist kein Element einer eigenen Hierarchie, sondern ein Attribut des TSV-Elements. Für diese Dimensionen wurde in den Berichtseinstellungen ein fixierter Filter auf dem All-Member eingestellt, wodurch die durch den Absprung übergebenen Filter keine Auswirkung auf den Bericht haben.

Abbildung 9: Schritt 4

Zusammenfassung und praxiserprobte Hinweise zur Umsetzung

Ein wie in diesem Beispiel gezeigtes Vorgehen kann von jedem Punkt der Wertschöpfungskette aus in jede Richtung durchgeführt werden. Da es zu jedem Prozessschritt aus Abbildung 1 einen eigenen Bericht gibt, kann jeder Stakeholder an dem für ihn relevanten Punkt starten. In jedem dieser Berichte kann entweder über die gezielte Suche nach einem entsprechenden Element in der Sicht oder über die Nutzung von Verknüpfungen eine Analyse begonnen werden. Dies ermöglicht eine vollumfängliche Analyse der Wertschöpfungskette nach den individuellen Bedürfnissen.

Alle hierfür verwendeten Berichte haben eine ähnliche Struktur in der Spalten- und Zeilenachse, damit man sich schnell und einfach orientieren kann. Alle Berichtsdefinitionen wurden mit DeltaMaster-Standardfunktionen realisiert. Lediglich Fallunterscheidungen in der Achsendefinition der Zeilen wurden durch benutzerdefiniertes MDX erreicht. Das MDX definiert, welchen Dimensionsebenen Elemente angezeigt werden sollen, wenn bestimmte Filter in der Sicht gesetzt sind. Diese weisen aufgrund der Anzahl an unterschiedlichen Bedingungen und Abhängigkeiten untereinander zwar eine gewisse Komplexität auf, sind für sich genommen aber relativ simpel gehalten, da auf die Crossjoin- und die Generate-Funktionen gänzlich verzichtet werden konnte. Wie bereits erwähnt, genügt immer die <view>-Referenz. Hierdurch sind diese Berichte trotz ihrer komplexen Möglichkeiten sehr robust und für den geübten DeltaMaster-Anwender gut wartbar.

Selbstverständlich kann das vorgestellte Beispiel in den wenigsten Fällen genauso für die Analyse anderer Wertschöpfungsketten verwendet werden, jedoch lässt sich ein genereller Leitfaden ableiten, der bei der Erstellung entsprechender Berichte helfen kann und sich potenzielle Fehler vermeiden lassen. So können zum Beispiel auch Fertigungsabläufe über bestimmte Maschinen oder Lieferketten mit DeltaMaster analysiert werden.

Bei der Erstellung der Berichte sollten folgende Punkte beachtet werden:

• Vorab klare Definition und sicheres Verständnis des Prozesses!
• Von Beginn an mit einem stark reduzierten Filterkontext arbeiten. Nur die nötigsten Dimensionen und Dimensionsebenen als Filter zulassen.
• Den Berichtsbau auf einer aggregierten Ebene beginnen, damit nicht versehentlich sehr große und rechenintensive Kreuzprodukte auf der Zeilenachse angezeigt werden.
• Klar definieren, welche Informationen angezeigt werden, wenn ein bestimmter Filter gesetzt wurde!
  • Sollte aufgrund der Anzahl an Ausprägungen erst ab einer bestimmten Kombination an Filtern die unterste Ebene angezeigt werden?
  • Genügt eine aggregierte Ebene als Einstieg, in die je nach Bedarf durch Drill-down und Filtern granularer werden kann?
  • Unterschiedliche Fälle eindeutig definieren und nach Möglichkeit zusammenfassen, um verwendetes MDX möglichst simpel und übersichtlich zu halten.
  • Sollte eine neue Bedingung nachträglich hinzukommen, immer das gesamte Konstrukt prüfen.
• Bedingungen bei Absprüngen verwenden: Absprünge sollen nur dann möglich sein, wenn sie inhaltlich wirklich sinnvoll sind.
• Filter in den Berichtseinstellungen verwenden.