Liebe Datenanalysten,

„keine Nachrichten sind gute Nachrichten“, hört man gestresste Manager gelegentlich sagen. Schwingt darin eine Spur Pessimismus mit, dass jede Botschaft an ihre Adresse nur etwas Unangenehmes bedeuten kann? Oder eher eine gesunde Zuversicht, dass schon nichts Schlimmes passiert sein wird, solange man keine Nachricht erhält? Oder kommt da schlicht der Wunsch zum Ausdruck, angesichts des hohen Nachrichtenaufkommens, mit dem man heute zu kämpfen hat, einmal wenig bis keine Nachrichten zu bekommen?

Mit DeltaMaster und dem zugehörigen Berichtsserver können Sie auf solche Versorgungswünsche rasch reagieren. Im Sinne einer Ausnahmeberichterstattung („Exception Reporting“) legen Sie datengetrieben fest, wann Reports erstellt und versendet werden sollen – und wann nicht. Wenn das keine gute Nachricht ist!

Herzliche Grüße
Ihr Team von Bissantz & Company

Manche Berichtsempfänger wünschen sich, dass sie nicht ständig Berichte erhalten, sondern nur in bestimmten Situationen benachrichtigt werden, etwa wenn ein Schwellwert erreicht oder überschritten wird. Diese Spielart des Berichtswesens nennt man auch Ausnahmeberichterstattung, Exception Reporting oder Alerting. Der Berichtsserver, dessen Hauptaufgabe das periodische Erzeugen und Verteilen von Reports ist, beherrscht diese Variante. Ausführlich hatten wir den Berichtsserver in den DeltaMaster clicks! 08/2005 vorgestellt; hier wollen wir uns darauf konzentrieren, wie Sie dem System „beibringen“, auf gewisse Datenkonstellationen zu achten und nur bei bestimmten Ereignissen tätig zu werden.

Der Schlüssel für das Exception Reporting liegt im Feld Berichtsgenerator, links unten im Berichtsserver. Hier definieren Sie so genannte Iteratoren, die in einer Schleife mehrere Elemente einer Dimension hintereinander aufzählen. Für jedes dieser Elemente berechnet DeltaMaster die Berichte in den ausgewählten Berichtsmappen und verteilt sie zum Beispiel per E-Mail oder auf den Dateiserver.

Ein Anwendungsfall in unserem Referenzmodell „Chair“ sind Vertriebsstatistiken, die für jeden regionalen Absatzmarkt zu erstellen sind: Im Fenster Berichtsgenerator stellen Sie ein, dass die Iteration die Quelldimension Kunden durchlaufen soll. In der Spalte Bericht je Element aus wählen Sie mit dem Dimensionsbrowser die Elemente Nord, Ost, Süd und West aus. Wenn Sie diesen Job ausführen, generiert DeltaMaster (bzw. der Berichtsserver) für jede Region die ausgewählten Berichte.

Mit ein wenig MDX lässt sich dieser Mechanismus ausnutzen, um nur in genau definierten Fällen Berichte zu erzeugen und zu versenden.

Berichtsgenerator-Elemente filtern

Durch das Auswählen der vier Vertriebsregionen haben wir einen MDX-Ausdruck erzeugt und in das Feld Bericht je Element aus eingetragen:

[Kunden].[Europa].[Deutschland].[Nord], [Kunden].[Europa].[Deutschland].[Ost],
[Kunden].[Europa].[Deutschland].[Süd], [Kunden].[Europa].[Deutschland].[West]

Alternativ können Sie direkt den MDX-Ausdruck „[Kunden].[Region].Members“ eingeben (Taste F2).

Dieser Code beschreibt ein so genanntes Set, dessen Elemente vom Berichtsgenerator verarbeitet werden. Das Set muss nicht zwingend durch explizite Benutzerauswahl festgelegt werden, sondern man kann es auch von einem MDX-Ausdruck dynamisch bestimmen lassen. Hier bietet sich insbesondere die Filter-Funktion an. Ihre allgemeine Syntax lautet:

Filter(<Mengenausdruck>, <Logischer Ausdruck>)

Der logische Ausdruck wird als Vergleichskriterium benutzt und für jedes Element des Mengenausdrucks geprüft. Als Rückgabe liefert die Funktion diejenigen Elemente des Mengenausdrucks, welche die Bedingung erfüllen. Wenn das resultierende Set leer ist, so hat der Berichtsserver keine Elemente zum Aufzählen und er erzeugt keinen Bericht. Umgekehrt formuliert: Nur wenn die (Ausnahme-)Bedingung erfüllt ist, erstellt und verteilt DeltaMaster Berichte im Sinne des Exception Reporting.

Beachten Sie den feinen Unterschied: Wenn im Berichtsgenerator im Feld Bericht je Element aus gar nichts eingetragen ist, führt DeltaMaster keine Iteration aus. Ist hingegen ein MDX-Ausdruck eingetragen, der ein leeres Set zurückliefert, endet der Job, ohne dass Berichte erzeugt werden.

Nehmen wir an, wir wollten nur für die Regionen Berichte erzeugen, in denen der Umsatz im Mai über 1 Million lag. Dazu würden wir eingeben:
Filter ([Kunden].[Region].Members, ([Measures].[Umsatz], [Perioden].[2007].[2007_Q2].[2007_Q2_5], [Wertarten].[Ist], [Time Utility].[Ist]) > 1000000)

Mit dem ersten Parameter „[Kunden].[Region].Members“ wählen wir zunächst die Elemente der Kundendimension auf der Ebene der Regionen aus; das entspricht genau dem, was wir oben per Dimensionsbrowser vorgegeben hatten. Der zweite Parameter „([Measures].[Umsatz], …“ beschreibt die Regel, die für jedes Element überprüft wird: Der Umsatz soll größer als eine 1 Million sein. Komplexere Kriterien lassen sich mit logischen Operatoren wie AND, OR, NOT und XOR formulieren. Zeitangaben können mithilfe des SQL-Aktualisierungs-Befehls automatisch angepasst werden.

Wichtig ist, dass die Vergleichsanalysewerte vollständig spezifiziert sind, denn wenn der Vergleich intern berechnet wird, ist die Sicht des Berichts nicht verfügbar. Daher haben wir in allen Dimensionen, in denen wir nicht die Top-Elemente betrachten wollen, explizit angegeben, welche Elemente wir berücksichtigen möchten, etwa den Zeitpunkt und die Wertart.

Mit Abweichungen und anderen berechneten Größen vergleichen

Oft wird man als Grenzwert nicht eine absolute Größe betrachten, sondern Abweichungswerte, beispielsweise eine prozentuale Plan-Ist-Abweichung oder die Veränderung gegenüber dem Vormonat. Solche Dinge sind typischerweise als berechnete Elemente modelliert.

Um sie in MDX verwenden zu können, benötigen wir ihre internen MDX-Namen. Diese zeigt DeltaMaster an verschiedenen Stellen an, zum Beispiel im Dimensionsbrowser, wenn Sie die Alt-Taste gedrückt halten und mit der Maus auf den Namen eines Elements zeigen.

Auch berechnete Kennzahlen, wie etwa ein Deckungsbeitrag, sind mit ihrem MDX-Namen anzugeben, den wir zum Beispiel in den Analysewerteigenschaften erfahren: auf der Registerkarte System in der Zeile Name.

Wenn wir also den Versand unserer Vertriebsstatistiken nicht von der absoluten Höhe des Umsatzes abhängig machen wollen, sondern von der Plan-Ist-Abweichung des Deckungsbeitrags, ermitteln wir zunächst die benötigten MDX-Namen. In unserem Referenzmodell heißt der Deckungsbeitrag intern „[Measures].[Deckungsbeitrag]“ und die Plan-Ist-Abweichung ist als ein berechnetes Element in der Wertart-Dimension angelegt, welche in MDX „[Wertarten].[Plan-Ist Abw. %]“ heißt.

Daraus folgt der Filterausdruck:

Filter ([Kunden].[Region].Members, ([Measures].[Deckungsbeitrag], [Perioden].[2007].[2007_Q2].[2007_Q2_5], [Wertarten].[Plan-Ist Abw. %],
[Time Utility].[Ist]) < -0.05)

Damit werden nur für die Kundenregionen Reports produziert, bei denen der Deckungsbeitrag mehr als 5 % unter dem Plan lag.

Der erhobene Zeigefinger

Bei der Ausnahmeberichterstattung geht es letztlich darum, Information zu unterdrücken. Die Berichtsempfänger sollen eben nicht laufend informiert werden, sondern nur in ausgewählten Situationen, die man pauschal und vorab definiert hat. Und über Schwellwert-Konzepte mag man geteilter Meinung sein: Ist eine Abweichung wirklich erst ab 5 % relevant und 4,98 % sind uns egal? Auf welcher Verdichtungsebene zieht man welche Grenze?

Der Wirtschaftsinformatiker Norbert Szyperski warnte schon 1978: „Festgeschriebene Schwellenwerte, verbunden mit der Management-by-Exception-Fiktion, sind daher gefährlich. Das Management sollte neugierig sein, d. h. neue Informationsverknüpfungen suchen und nicht nur wie eine Kontrollperson auf einer Schaltbühne aufmerksam dösen“ (zitiert nach Mertens/Griese, Integrierte Informationsverarbeitung 2, Wiesbaden 2002).

Setzen Sie den datengetriebenen Berichtsversand also mit Bedacht ein, zumal Ihnen DeltaMaster alle Werkzeuge an die Hand gibt, Standardberichte so attraktiv und informationsdicht zu gestalten, dass man sie nicht wegwünscht, sondern sich darauf freut.