3.2.1 Von der Skizze zum maßstabsgetreuen Detailkonzept
Für die technische Umsetzung unserer Dashboards diente uns Lumira Designer aus der Business Objects Suite. Durch die Einbindung der relevanten Datenquellen in SAP BW[1] konnten wir diese über BEx-Queries mit den grafischen Komponenten verknüpfen. Es hat sich jedoch schnell gezeigt, dass eine interaktive Applikation in Lumira Designer bzw. Design Studio ohne umfangreiches Scripting nicht möglich sein wird.
Vor allem bei der Implementierung der ersten Dashboards hatte noch niemand eine konkrete Vorstellung, wie die Objekte in der Applikation genau aussehen werden. Wir nahmen unsere handschriftlichen Skizzen (vgl. Abb. 3) und versuchten, die Seiten in Lumira Designer aufzubauen. Erst dabei wurde uns klar, dass die Implementierung und Darstellung gewisser Objekte nicht wie in den Skizzen vorgesehen möglich sind. In der Realität gab es andere Größenverhältnisse:
- die Echtzahlen waren deutlich länger/kürzer als in der Skizze vorgesehen,
- der Platz für Beschreibungsfelder war zu klein, um lesbare Texte zeigen zu können und
- für andere Grafiken war bspw. wieder zu viel Platz vorgesehen, sodass sie eher "verloren" wirkten und das Design in keinem harmonischen Einklang stand.
Wir verfeinerten deshalb unser Konzept um eine Stufe und platzierten dazu sämtliche Elemente im korrekten Seiten- und Größenverhältnis auf PowerPoint-Folien. Damit gingen wir mit den verantwortlichen Controllern in eine zweite Abstimmungsrunde. Dies war zwar eine mühsame Tätigkeit, jedoch ersparten wir uns damit viel Entwicklungsaufwand, da die (Um-)Gestaltung in PowerPoint deutlich einfacher und schneller ist, als eine Bearbeitung in Lumira Designer. Abb. 4 zeigt das verfeinerte Konzept unserer Startseite. Die rot eingekreisten Ziffern stellen die Absprunglogik im Navigationsbaum dar. Folgende (zusätzliche) Abkürzungen werden verwendet:
- ACT/BUD/PY: Actual (Ist)/Budget/Previous Year (Vorjahr)
- abs./perc.: Anzeige der Abweichung in absoluten Zahlen/als Prozentwert
- YTD: Year-to-Date (kumulierter) Wert
- CM: Contribution Margin (Deckungsbeitrag)
- Rev.-FC Revenues Forecast
Es hat sich dabei auch gezeigt, dass die Mitarbeit eines Entwicklers am Detailkonzept wichtig ist. Personen mit dem Verständnis und den Kenntnissen für die Möglichkeiten und Schwierigkeiten bei der technischen Umsetzung können Diskussionen viel schneller wieder auf einen pragmatischen Kurs bringen. Leider mussten wir anfangs auch mehrmals feststellen, dass wir Ressourcen gelegentlich in zu aufwendigen Zusatzfunktionalitäten ohne wesentlichen Mehrwert bündelten.
Abb. 4: Detailkonzept der Startseite
Durch die im Zuge der Implementierung immer größer werdende Anzahl der Dashboard-Seiten und der damit verbundenen hohen Anzahl an Datenquellen mussten wir aus Performance-Gründen die Ladelogik in Lumira Designer optimieren. Ab sofort wurden über Scripts nur mehr jene Datenquellen geladen bzw. aktualisiert, die für die aktuell angezeigte Dashboard-Seite erforderlich waren. Dies war ein weiterer wichtiger Schritt in Richtung Benutzerakzeptanz.
3.2.2 Implementierungsaufwand mit graphomate extensions reduziert
Bei der Einhaltung unserer selbst auferlegten Reporting-Richtlinien im Hinblick auf den IBCS-Standard sind wir mit den vorhandenen Standardmitteln gescheitert. Eine entsprechende Darstellung von Tabellen und Charts war nicht möglich bzw. wäre nur mit nicht vertretbarem Zusatzaufwand möglich gewesen. Wir haben uns deshalb für die Verwendung von Extensions der Firma graphomate GmbH entschlossen. Dabei handelt es sich um IBCS zertifizierte Erweiterungen für verschiedene Frontend-Tools. Derzeit verwenden wir in Lumira Designer graphomate charts, graphomate tables und graphomate bubbles.[1] Auch die für die Übersichtlichkeit wichtige Skalierung von Werten in Tabellen und Charts konnten wir damit automatisch und ohne Zusatzaufwand sicherstellen.
Als Kommentarlösung haben wir eingabefähige BEx-Queries für Texte erstellt, die im Zuge des Periodenabschlusses von den Business Controllern über Analysis for Office befüllt werden. Abhängig von der jeweiligen Seite im Dashboard speichern wir diese auf Buchungskreis-, Monats- bzw. Produktebene. Über ein Script in der Designer-Applikation werden die Zeichenketten anschließend ausgelesen. Es hat sich jedoch gezeigt, dass diese Standardfunktionalität auch relativ aufwendig ist.
Zur zentralen Wartung haben wir sämtliche Komponenten, die im Dashboard verwendet werden, über benutzerdefinierte CSS-Files[2] beschrieben. So konnten wir Kacheln, Tabellen, Charts, Textfelder u.v.m. einfach kopieren. Dabei war sichergestellt, dass im Falle einer notwendigen Anpassung die Änderung für alle betroffenen Elemente automatisch mitgezogen wird. Auch bei den Scripts versuchten wir allgemeine Standard-Routinen zu schaffen.
3.2.3 Beispielseiten aus dem Dashboard
In Abb. 5 findet sich ein Screenshot der...
Das ist nur ein Ausschnitt aus dem Produkt Controlling Office. Sie wollen mehr?
Jetzt kostenlos 4 Wochen testen
Anmelden und Beitrag in meinem Produkt lesen