Liebe Datenanalysten,

mit einer kleinen clicks!-Reihe im April, Mai und Juni haben wir die Ausgabeformate und ?kanäle vorgestellt, in denen und über die Be­richte automatisch erzeugt, aktualisiert, konfektioniert und verteilt werden können. Daraufhin erreichten uns zahlreiche interessierte Rückfragen zum Publisher bzw. Berichtsserver, wie das Modul in DeltaMaster 5 heißt. Einige dieser Fragen sind schnell beantwor­tet. Etwa diese: Ist so ein Automatismus, ein „Server“, nicht nur et­was für große Anwendungen, viele Berichtsempfänger, häufige Ak­tuali­sie­rungen? Nein! Von Automation profitiert man selbst dann, wenn man nur eine Berichts­mappe zu exportieren oder zu versenden hat, das aber öfter als einmal oder für mehr als ei­nen Empfänger. Schon da fängt das Streben nach Effizienz an und schon dabei kann Delta­Master helfen. Eine andere Frage: Geht das mit jedem Bericht oder ist beim Berichtsaufbau et­was zu beachten? Die Antwort in Kurz­form: im Prinzip ja; am besten ja. Die ausführ­li­che Antwort, wie man publizierfreundliche Berichte gestaltet, geben wir auf den fol­genden Seiten. Wenn Sie diese Über­legungen be­her­zi­gen, dann kommt das nicht nur einem au­to­mati­sierten, statischen Reporting zugute, sondern Sie profitieren auch beim interak­tiven, dynami­schen Repor­ting. Und wieder ist der Effizienz gedient.

Herzliche Grüße
Ihr Team von Bissantz & Company

Ob sich Berichte gut automatisch aktualisieren und an unterschiedliche Empfänger bzw. Berichtsgegen­stände anpassen lassen, hängt auch davon ab, wie die Berichte konstruiert sind. Schließlich gibt es mehrere Wege zu einem Ziel, zu einer bestimmten Darstellung – und es ist ein Unterschied, ob ein Bericht einmal erstellt und danach nicht mehr benötigt wird oder ob er immer wieder verwendet, vari­iert, als Vorlage genutzt werden soll. Dann kommt es besonders auf die Berichtslogik an.

Eingabe, Verarbeitung, Ausgabe

Um Empfehlungen für einen „publizierfreundlichen“ Berichtsaufbau zu geben, führen wir uns einmal die Arbeitsweise von Publisher (DeltaMaster 6) und Berichtsserver (DeltaMaster 5) vor Augen. Sie lässt sich grob gemäß dem EVA-Prinzip gliedern:

1. Eingabe: DeltaMaster öffnet die Berichtsquelle (eine Anwendung im Repository oder eine Analy­se­sitzung in einer DAS- oder DM2GO-Datei) und stellt die Verbindung zur Analysedaten­bank her (dem Data Warehouse).
2. Verarbeitung: Die Berichte aus der Berichtsquelle werden neu berechnet. Dazu führt Delta­Master alle erforderlichen Datenbankabfragen aus, sodass die Berichte den aktuellen Daten­stand widerspiegeln. Vor diesen Abfragen lassen sich die Berichte mit drei Werkzeugen anpas­sen:

• Beim Berichtsupdate ändert DeltaMaster in allen Berichten die Sicht (die Filter) und stellt in jeder angegebenen Dimension die ausgewählten Elemente ein. Im Beispiel soll die Periode auf Juli 2016 geändert werden. Typischer Anwendungsfall: Der Monats­abschluss ist fer­tig, die Daten im Würfel sind frisch aufbereitet; nun muss in allen Berichten der neue Monat eingestellt werden. Auf Schritt 3, die Ausgabe, hat das Berichtsupdate keine un­mittelbare Auswirkung.

• Im Berichtsgene­ra­tor legt man mehre­re Elemente fest, die in einer Schleife verarbeitet werden (Iteration), um die Sicht (die Filter) wieder­holt zu än­dern. Auf Schritt 3, die Ausgabe, hat der Berichtsgene­ra­tor unmittel­ba­r Aus­wir­kung: Für jedes Element dieser Schleife wird eine eigene Ausgabe erzeugt. Bei­spiels­weise soll für jeden Außendienstmitarbeiter, Kostenstellenleiter usw. eine eigene Be­richts­mappe erstellt und etwa eine eigene E-Mail versendet werden. Im Beispiel sind in der Kundendimension die Elemente „Nord“, „Süd“, „Ost“ und „West“ ausgewählt. Das bewirkt Folgendes: Zuerst werden alle Berichte aus der Berichtsquelle auf das Ele­ment „Nord“ umgestellt, mit dieser Filtereinstellung berechnet, ausgegeben (zum Bei­spiel im HTML-Format) und verteilt (zum Beispiel per E-Mail). Dann ist das nächste Element an der Reihe, „Süd“. Wieder stellt DeltaMaster die Filter in allen Be­richten um, berechnet sie neu, erzeugt die Ausgabedatei(en) und versendet das Ergeb­nis. Anschlie­ßend wird „Ost“ verarbeitet, schließlich „West“.

• Auch der Berichtsmappengenerator verarbeitet mehrere Elemente in einer Schleife, er­zeugt damit jedoch nicht mehrere Ausgabedateien, sondern neue Ordner und Berichte innerhalb der Berichtsmappe aus der vorgegebenen Anwendung bzw. Analysedatei. Das Werkzeug ist über die Einstellungen eines Jobs zu erreichen und wurde in den Delta­Master clicks! 06/2006 vorgestellt. Auf Schritt 3, die Ausgabe, hat er keine unmit­telbare Auswirkung. Der Berichtsmappengenerator wird selten und nur für spezielle Aufgaben verwendet – schließlich ist man bestrebt, mit wenigen, interaktiven Berichten auszukommen, statt viele statische Berichte in der Berichts­mappe vorzuhalten. Deshalb gehen wir im Folgenden nicht weiter auf dieses Werkzeug ein.

Auf welche Berichte die Werkzeuge angewendet werden, ist im Fenster Berichtsordner einzustellen: entweder nur die Berichte in den ausgewählten Berichtsordnern, ggf. mit Un­terordnern, oder, falls nichts ausgewählt ist, auf alle Berichte der Berichtsquelle. Für alle Werk­zeuge gilt: Die jeweiligen Anpassungen wirken sich nur auf die weitere Verarbeitung durch den Publisher aus, nicht auf die gespeicherte Berichtsquelle.

3. Ausgabe: DeltaMaster gibt die Berichte im festgelegten Berichtsformat, über die festgelegte Vertei­lungsart aus, zum Beispiel als PDF-Dokument, das auf dem Fileserver gespeichert wird, als HTML-Seite, die per E-Mail verteilt wird, oder als neue DeltaMaster-Anwendung im Repository. Ausführliche Hinweise zu den Berichtsformaten und Verteilungsarten finden Sie in den Delta­Master clicks! 04/2016, 05/2016 und 06/2016. Möglicherweise gelangen nicht alle verarbeite­ten Berichte in die Ausgabe: Beim sogenannten Exception Reporting können Bedingungen fest­ge­legt werden, wann ein Bericht ausgegeben werden soll und wann nicht. Ausführlich beschrie­ben ist das Exception Reporting in den DeltaMaster clicks! 11/2008.

Kurz gesagt: Das Berichtsupdate ändert die Sicht innerhalb der Berichtsmappe, ohne zusätzliche Ausga­ben zu erzeugen. Der Berichtsgenerator ändert die Sicht in der Berichtsmappe in einer Schleife und erzeugt für jede neue Sicht eine individuelle Ausgabe. In der Praxis wird beides oft in Kombination ein­gesetzt. Beispielsweise soll in allen Berichten der neue Monat eingetragen werden (Berichtsupdate), bevor die Berichtsmappe für jede einzelne Kostenstelle oder Niederlassung ausgefertigt und einzeln gespeichert oder versandt wird (Berichtsgenerator).

Dreh- und Angelpunkt: die Sicht

Aus alledem geht hervor: Vor allem verändert der Publisher die Sicht. Das ist seine eigene, große Leis­tung! Bei den meisten anderen Aufgaben stützt sich der Publisher auf die Funktionalität des interaktiven DeltaMaster-Programms: Die Datenbank abfragen, Berichte berechnen, Exportdokumente erstellen: das macht DeltaMaster ja sonst auch, auf Geheiß des Anwenders. Der Publisher kann diese Funktionen aufrufen und mitbenutzen – und trägt als eigene Wertschöpfung die automatische Veränderung der Sicht bei.

Und damit ist das Geheimnis von Berichten, die sich gut automatisch aktualisieren und individualisieren lassen, gelüftet: Über die Sicht muss das möglich sein, allein durch Änderung der Sicht.

Dynamisch sollen die Berichte sein

Ein publizierfreundlicher Bericht ist also so zu konstruieren, dass die angestrebte automatische Variation keine Strukturänderungen erforderlich macht, sondern nur von der Sicht abhängt – von Filtern, wie man sie auch in der Filterleiste bzw. im Fenster Sicht einstellen würde. Oder, um es handwerklich auszudrü­cken: Wenn ein Berichtsempfänger im Präsentationsmodus von DeltaMaster 6 bzw. im Viewer-Modus von DeltaMaster 5 die Berichtsmappe so umstellen kann, dass für ihn maßgeschneiderte Ansichten ent­stehen, dann kann es auch der Publisher. Oder, wieder anders ausgedrückt: Was gut ist für ein dynami­sches, interaktives Berichtswesen, bewährt sich genauso beim statischen, automatisierten Reporting. So einfach ist das: Wer gute statische Berichte in Serie produzieren muss, braucht dazu nur einen guten dynamischen Bericht.

An zwei einfachen Beispielen zeigen wir, wie sich diese Dynamik herstellen lässt. Bei beiden handelt es sich um Grafische Tabellen (Pivottabellen). Dabei kommt es besonders auf das Verhältnis von Achsen­definition und Sicht an.

Beispiel 1: Vormonatsvergleich

In diesem sehr einfachen Bericht wird ein bestimmter Mo­nat den drei letzten Monaten gegenübergestellt, etwa April, Mai, Juni und Juli. Das lässt sich auf verschiedene Weisen erreichen.

In einem ersten Versuch wurde der Bericht so entwor­fen, dass die Monate in der Sicht eingestellt und in der Achsendefinition als Ebenenauswahl referenziert sind. Das kann man so machen – aber es geht geschickter. Das Problem beim Publizieren ist: Würde man diesen Bericht im nächsten Monat fortschreiben wollen und dazu vier neue Monate im Berichtsupdate einstellen, so erhielte man in diesem speziellen Bericht zwar tat­sächlich das erwünschte Ergebnis. Allerdings stellte man diese Sicht zugleich für alle anderen Berichte in der Berichtsquelle ein, mit dem mutmaßlich unerwünsch­ten Ergebnis, dass in vielen anderen Berichten womög­lich die Summe der vier Monate ausgewiesen wird.

Besser geht es so: Zuerst beschreibe man die Berichts­aufgabe abs­trakt! Im Prinzip soll der Bericht ja nicht April, Mai, Juni, Juli zeigen, sondern den „aktuellen Monat“ und die drei Monate davor – unab­hängig davon, welches gerade der aktuelle Monat ist. Eine Möglich­keit, dies abzubilden, sind die Zeitanalyseelemente von Delta­Master, für die in den meisten Analysemodellen eine Hilfs­dimension „Periodenansicht“ (Time Utility) vorgesehen ist. Die Elemente „ak­tuell“ und „Vorperiode“ sind regelmäßig bereits vorhanden. Hier wären also lediglich Elemente für die weiter zurückliegenden Monate zu modellieren, „Vorperiode (-2)“ und „Vorperiode (-3)“.

Mit einer solchen Definition hängt der Bericht nur noch von einem Filter ab: Der „aktuelle Monat“ verweist auf den einen Monat, der in der Sicht eingestellt ist, Juli 2016. Die anderen drei Elemente tun das ebenso, mit einem entsprechenden Versatz. So entsteht eine glei­tende Darstellung, die von einem einzigen Filterelement abhängt und ohne Verrenkungen eingestellt werden kann, ob mit Publisher oder interaktiv. Das ist elegant und effizient!

Ausführliche Hinweise zu den Zeitanalyseelementen finden Sie in den DeltaMaster clicks! 08/2007. Falls keine eigene Hilfsdimension zur Verfügung steht, lassen sich Zeitanalyseelemente auch direkt in der Zeitdimension anlegen, wie in den DeltaMaster deltas! 5.6.3, Punkt 3, beschrieben. Kenner machen es sich mit MDX noch ein­facher: Der Ausdruck „<view>.lag (3):<view>“ in der Zeitdimension führt im Ergebnis zur gleichen Spalten­struktur wie die Elementauswahl in der Periodenansicht.

Zum gewählten Beispiel ist anzumerken: In einer produktiven Anwendung würden wir empfehlen, nicht nur ein paar Monate nebeneinander zu schrei­ben – das hätte zu wenig Signalwirkung und Hand­lungsimpuls. Interessanter wäre es etwa, den Drei-Monats-Durchschnitt auszurechnen und die Abweichung des aktuellen Monats zu diesem Durchschnitt anzugeben. Damit bekommt der Bericht eine Aussage! Eine schrittweise Anleitung dazu finden Sie in den DeltaMaster clicks! 07/2011.

Beispiel 2: Berichte je Vertriebsregion

In diesem Beispiel soll ein einfacher Plan-Ist-Vergleich für die verschiedenen Vertriebsregionen ausgefertigt werden.

Der Berichtsredakteur hat sich dafür entschieden, die Re­gion als Elementauswahl in der Achsendefinition einzu­stellen. Das kündigte sich schon im Präsentationsmodus an, in der vorigen Abbildung: Die Region „Süd“ steht in Klammern. Die Klammern besagen: Der Filter ist im aktu­ellen Bericht zwar eingestellt, wird aber nicht angewendet – die Festlegung in der Achsendefinition hat Vorrang, der Filter ist in diesem Bericht wirkungslos. Und auch dem Publisher ist ein Element nicht zugänglich, das als Element­auswahl in der Achsendefinition ausgewählt ist. Das ist ja gerade das Wesen der Elementauswahl in der Achsendefi­nition: Was hier eingestellt ist, gilt unabhängig von der Sicht und ist damit auch unabhängig von Berichtsupdate und Berichtsgenerator.

Die Lösung ist offensichtlich: Man lege den Bericht so an, dass nur die wirklich unveränderlichen Merkmale in der Achsendefinition beschrieben sind, also zum Bei­spiel die Spaltenstruktur mit Zeitvergleichen oder Ab­wei­chungen. Für Dimensionen wie Kunden, Produkte, Materialien, Niederlassungen oder Kostenstellen kann man das fast pauschal sagen: Sie sollten tunlichst über die Sicht eingestellt sein, nicht über die Achse.

Mit dieser Definition lässt sich der Bericht ohne Weite­res automatisch über die Regionen iterieren.

Geringe Voraussetzungen, große Wirkung

Der Publisher ist eine ausgesprochen schlanke Komponente. Er ist im Installations- bzw. Lieferumfang von DeltaMaster 6 enthalten. Der Berichtsserver von DeltaMaster 5 kann als Zusatzoption mitinstalliert werden oder man kopiert ein paar Dateien zusätzlich in das DeltaMaster-Programmverzeichnis, aus einem ZIP-Archiv im Umfang von derzeit weniger als 1 MB. Dieser geringe Speicherplatzbedarf und die simple Inbetriebnahme sind darauf zurückzuführen, dass wesentliche Funktionen etwa zum Neube­rechnen von Berichten und zum Exportieren bereits in DeltaMaster enthalten sind. Diese Funktionen werden beim Publizieren ledig­lich „ferngesteuert“.

Falls Sie den Publisher/Berichtsserver zunächst einmal ausprobieren wollen, können Sie Ihrer IT also Entwarnung geben: Der Berichtsserver heißt nur deshalb „Server“, weil er sich so servil verhält und weil er etwas automatisch tut (statt interaktiv) – er braucht aber weder ein Server-Betriebssystem noch einen eigenen Rechner oder Benutzer noch spezielle Systemdienste, sondern kann als Zusatzkomponente zur Automation auf jedem PC oder Laptop genutzt werden, auf dem jemand interaktiv mit DeltaMaster arbeitet. Einzig die Benutzerberechtigungen sind zu beachten: Wer mit DeltaMaster 6 Anwendungen aus dem Repository publizieren möchte, muss für diese Anwendungen den Rollen „Berichtsverteilung definieren“ und/oder „Berichtsverteilung ausführen“ zugeordnet sein. Diese Rollen sind unabhängig voneinander (die eine schließt die andere nicht ein), sodass man oft beide Rollen zuweisen wird. Eine spezielle Lizenz wird für DeltaMaster 6 nicht benötigt, da das Publizieren bereits von den REPORTING-Lizenzen abgedeckt ist. In DeltaMaster 5 sind für den Berichtsserver eigene Lizenzen erforderlich.

Für sehr große Lösungen ist es möglich, die Ausführung von Jobs auf einen anderen Rechner zu verla­gern. Wir sprechen dann vom „ReportService“ im Unterschied zum „ReportServer“, siehe DeltaMaster deltas! 5.4.2, Punkt 27.