Liebe Datenanalysten,

als Saure-Gurken-Zeit bezeichnet man im Pressewesen einen Jahresabschnitt, in dem nicht viel passiert, sodass es nicht viel zu berichten gibt. Mangels anspruchsvoller, spannender Themen schwadronieren die Blätter dann oft über Kuriositäten, Skurriles und andere Nebensächlichkeiten, die eigentlich nicht berichtenswert sind. Trotzdem erscheint die Zeitung. Jeden Tag. Wer hätte sich da nicht schon einmal gewünscht, das Abonnement würde erst dann wieder bedient, wenn sich wirklich etwas tut …

Im Unternehmen erleben wir das selten: Da tut sich immer etwas, über das zu informieren sich lohnt. Dennoch, immer wieder hört man die Forderung, ein System solle auf bestimmte Situationen achten und nur dann Laut geben, wenn es etwas vorab Definiertes zu vermelden gibt, zum Beispiel einen Umsatzrückgang, der bestimmte Schwellen überschreitet. Damit könnte man das regelmäßige Reporting ergänzen und sich im Falle von Ausnahmesituationen speziell warnen lassen. Könnte? Kann! Seit dem letzten DeltaMaster-Release 5.3.6 funktioniert das besonders elegant. Wie, das lesen Sie in dieser Ausgabe der clicks!.

Herzliche Grüße
Ihr Team von Bissantz & Company

Zusätzlich zu einem regelmäßigen Reporting ist DeltaMaster in Kombination mit dem Berichtsserver in der Lage, ereignisabhängig zu berichten. Dazu hinterlegen Sie vorab Prüfkriterien in der Analysesitzung, zum Beispiel Schwellwerte für Abweichungen. Diese werden dann vom Berichtsserver routinemäßig überwacht. Nur wenn die Bedingungen erfüllt sind, erfolgt eine Benachrichtigung in Form eines Berichts, der etwa per E?Mail versandt wird. Diese Idee wird oft als Exception Reporting, Ausnahmeberichterstattung, Alerting oder auch Monitoring bezeichnet.

In den DeltaMaster clicks! 06/2007 hatten wir schon einmal einen Trick vorgestellt, wie sich dies mit MDX im Berichtsgenerator realisieren lässt. Das dort beschriebene Verfahren funktioniert weiterhin – jedoch ist mit dem Release DeltaMaster 5.3.6 die Ausnahmeberichterstattung wesentlich leistungsfähiger, flexibler und einfacher geworden.

Aufgabenteilung

Zwei Dinge sind zu tun, wollen wir nur „gegebenenfalls“ benachrichtigt werden und nicht ständig:

• Zum einen müssen wir die Bedingungen festlegen, von denen abhängen soll, ob wir ein Signal (einen Bericht) bekommen oder nicht. Das erledigen wir in der Analysesitzung in DeltaMaster.
• Zum anderen müssen wir sicherstellen, dass die Bedingungen regelmäßig überprüft werden. Das erledigt ein Job im Berichtsserver, den wir zeitgesteuert immer wieder ausführen lassen. Nur wenn die Bedingungen erfüllt sind, soll er einen Report generieren und zustellen.

Für jeden Bericht können Sie individuell bestimmen, ob er vom Berichtsserver nur dann ausgegeben werden soll, wenn gewisse festzulegende Kriterien erfüllt sind, oder immer (das ist die Voreinstellung). Diese Konfiguration speichert DeltaMaster in der Analysesitzung (.das-Datei).

Ablauf

In jedem Berichtsserver-Job dient eine .das-Datei als Vorlage (Berichtsquelle). Bei der Verarbeitung der Sitzung (bzw. der ausgewählten Ordner) berechnet und untersucht der Berichtsserver jeden Bericht und entscheidet, ob er in das Ergebnis des Jobs eingehen soll oder nicht.

• Ist ein Bericht nicht für das Exception Reporting markiert (Voreinstellung), so wird er in das Ergebnis übernommen.
• Ist für den Bericht hingegen das Exception Reporting aktiviert, prüft der Berichtsserver die festgelegte Bedingung. Ist sie erfüllt, wird der Bericht in das Ergebnis des Jobs aufgenommen; andernfalls ignoriert der Berichtsserver den Bericht und stellt ihn nicht in das Ergebnis ein.

Am Ende der Jobverarbeitung gibt der Berichtsserver das Ergebnis im gewünschten Format und auf die gewünschte Verteilungsart aus. Und wenn nach allen Prüfungen letztlich kein Bericht in das Ergebnis aufgenommen wurde, dann gibt es für den Berichtsserver nichts weiter zu tun: Er hat seinen Dienst getan und darf untätig bleiben, es werden keine Berichte generiert, nichts wird versendet – das ist Exception Reporting. Der Job endet dann mit dem Hinweis: „No result generated because all reports are discarded.“ Das ist eine Status- und keine Fehlermeldung, denn das Nichtstun war ja intendiert.

Bedingungen in den Berichtseigenschaften

Die Bedingungen, wann ein Bericht in das Ergebnis eines Jobs aufgenommen werden soll, legen Sie in den Berichtseigenschaften (Kontextmenü) eines jeden Berichts fest. Grundsätzlich kennt DeltaMaster zwei Varianten, die zu überprüfende Bedingung zu formulieren: nach der Anzahl der Datenzeilen, die ein Bericht enthält, oder über einen benutzerdefinierten MDX-Ausdruck.

Prüfkriterium: Berichtslänge

Die erste Variante – nach Anzahl der Zeilen – ist vor allem für Pivottabellen oder überwiegend tabellarische Berichtstypen wie die Rangfolge und PowerSearch gedacht.

Eine häufige Anwendung für das Alerting sind (numerische) Filter. Als Beispiel haben wir einen benutzerdefinierten Analysewert erstellt, der die Plan-Ist-Abweichung des Umsatzes in Prozent erfasst.

Ohne weitere Filterung mag dadurch eine Liste wie die hier abgebildete entstehen. Die gezeigte Situation wird manchem noch nicht als besonders bedrohlich erscheinen, denn die relativen Abweichungen sind noch relativ gering. (Zur Abwägung zwischen relativen, absoluten und gewichteten Abweichungen hatten wir uns übrigens in den DeltaMaster clicks! 06/2008 ausgelassen.)

Wir nehmen einmal an, dass erst eine Planunterschreitung von 5 % oder mehr einen Alarm rechtfertigen soll.

Mithilfe eines Filters in der Achsendefinition lässt sich diese Anforderung in der Pivottabelle schnell umsetzen.

Das Ergebnis der Filterung zeigt die Abbildung: Da wir in der aktuellen Datenlage keine Abweichung „schlimmer“ als 5 % haben, enthält er keine Datenzeilen, er bleibt leer.

Mit der Bedingung Bericht in das Ergebnis eines Berichtsserver-Jobs nur aufnehmen, wenn die Tabelle mehr als 0 Zeilen umfasst würde der Berichtsserver in der hier gezeigten Datenlage also keinen Report generieren. Führen wir den Job für einen anderen Zeitraum aus, mag es hingegen durchaus Regionen geben, in denen der Plan um mehr als 5 % unterschritten wird. Die Tabelle wäre dann länger, die Bedingung nicht mehr erfüllt und der Bericht würde im Ergebnis des Jobs berücksichtigt – er würde also ausgegeben und verteilt.

Im Allgemeinen empfiehlt es sich, in Pivottabellen, die abhängig von ihrer Zeilenanzahl in das Exception Reporting eingehen, die leeren Zeilen auszublenden (Optionen in der Achsendefinition, im Kontextmenü oder im Menü Ich möchte). Andernfalls kann es vorkommen, dass eine Abfrage zwar keine Werte zurückliefert, die Tabelle aber trotzdem Zeilen enthält, die etwa per Elementauswahl festgelegt worden sind. Die Tabelle würde dann vom Berichtsserver nicht ausgeschlossen, weil dieser auf die vorhandenen Zeilen abstellt und nicht auf das Vorhandensein von Werten. Berücksichtigt werden stets nur die Datenzeilen, die Überschriften zählen nicht mit.

Prüfkriterium: MDX-Bedingung

Alternativ können Sie als Kriterium einen beliebigen MDX-Ausdruck hinterlegen, um auch solche Bedingungen anzugeben, die unabhängig vom jeweiligen Bericht oder von dessen Länge sind. Für manche Berichtstypen, bei denen die Zeilenanzahl inhaltlich nicht sinnvoll bestimmt werden kann, zum Beispiel Flexreports und Kombinationscockpits, sind nur MDX-Bedingungen verfügbar.

Wenn der Ausdruck „true“ zurückliefert, wird der Bericht in das Ergebnis des Berichtsserver-Jobs aufgenommen, bei „false“ nicht.

Zum leichteren Editieren des Ausdrucks können Sie über den Link Bearbeiten rechts unten den MDX-Editor starten, der etwa auch bei berechneten Mengen, bei benutzerdefinierten Analysewerten usw. zur Verfügung steht. In der Abbildung haben wir die Fünf-Prozent-Hürde für die Gesamtumsatzabweichung in der Berichtssicht festgeschrieben. Diese Definition könnte zum Beispiel auch für eine Geo-Analyse oder andere Detailberichte gelten, die nur dann präsentiert werden sollen, wenn die Gesamtsituation dies erfordert.

Anders als an den übrigen Stellen, an denen DeltaMaster die Eingabe von MDX anbietet, wird dieser Ausdruck jedoch nicht sofort benutzt, sondern zur späteren Verwendung im Berichtsserver gespeichert. Deswegen können Sie hier zusätzlich die Syntax überprüfen lassen. DeltaMaster verifiziert dann, ob der Ausdruck formal korrekt ist, und zeigt zur Kontrolle an, ob die Bedingung für die im Bericht gespeicherte Sicht erfüllt ist. Bei der späteren Abarbeitung des Jobs im Berichtsserver mag die Sicht freilich eine andere sein, etwa weil ein Berichtsupdate oder ein Berichtsgenerator wirken, und somit auch das Ergebnis der Prüfung anders ausfallen.

Job im Berichtsserver anlegen

Im Berichtsserver müssen Sie keine weiteren Vorkehrungen treffen – ob die Ausnahmebehandlung anzuwenden ist, richtet sich allein nach den Einstellungen in den Berichtseigenschaften. Sie legen also wie gewohnt einen neuen Job für die präparierte Analysesitzung an.

Meist wird man als Verteilungsart „mail“ wählen, um den Empfänger im Falle eines Falles direkt und aktiv ein Signal zu geben. Übrigens: Ebenfalls seit der Version 5.3.6 beherrscht der Berichtsserver-Office den HTML-Export (siehe DeltaMaster deltas! 5.3.6, Nr. 12), sodass auch etwa ein PDA, ein Blackberry oder andere mobile Geräte die Mitteilung gut anzeigen können.

Wenn Sie mehrere Berichtsmappen für Ausnahmesituationen vorbereitet haben, lohnt es sich, diese in einer eigenen Jobgruppe zusammenzufassen. Es genügt dann ein einziger Eintrag im Scheduler (siehe unten), um alle im selben Intervall regelmäßig zu überwachen. Tragen Sie in allen zusammenzufassenden Jobs im Feld Jobgruppe denselben Namen ein, zum Beispiel „Exception Reporting“. Das Feld finden Sie ziemlich weit rechts in der Jobdefinition.

Zeitsteuerung für die Ereignisüberwachung

Der Job, der unsere Schwellwerte oder sonstige Bedingungen überwacht, ist nun eingerichtet. Er muss regelmäßig, am besten automatisch ausgeführt werden, zum Beispiel einmal am Tag, damit das definierte Ereignis tatsächlich bemerkt werden kann. Hierzu nutzen Sie die gleichen Zeitplanungsmechanismen wie für einen regelmäßig und unbedingt auszuführenden Job, also zum Beispiel den SQL Server-Agent von Microsoft SQL Server oder andere, spezialisierte Scheduling-Werkzeuge – oder einfach den Kommandozeilenbefehl „at“ unter Windows oder die Geplanten Tasks in der Systemsteuerung.

Als auszuführendes Programm wählen Sie den vollständigen Pfad zum Berichtsserver und ergänzen als Parameter die Id des Jobs, der ausgeführt werden soll, bzw. den Namen der Jobgruppe, wenn Sie Ihre Ausnahme-Jobs in einer solchen zusammengefasst haben.

Der Aufruf könnte dann etwa so aussehen:

„C:ProgrammeDeltaMaster 5.3ReportServer.exe“ 5

für den Job mit der JobID 5 oder

„C:ProgrammeDeltaMaster 5.3ReportServer.exe“ „Exception Reporting“

für die genannte Jobgruppe. Die Anführungszeichen sind anzugeben, wenn Leerzeichen im Pfad oder im Gruppennamen vorkommen.

Teilweise oder gar nicht

Die vorgestellten Funktionen können Sie nicht nur zum vollständigen Unterdrücken von Benachrichtigungen verwenden, sondern auch zum „Ausdünnen“ der zu verteilenden Berichtsmappen. Da die Prüfbedingungen je Bericht gelten, können manche Auswertungen automatisch ausgesondert werden, während andere „durchkommen“. Zwei typische Anwendungsfälle sind fehlende Werte und fehlende Berechtigungen. Wenn Sie in einem Berichtsordner beispielsweise die Berichte „Plan Inland“ und „Plan Ausland“ gespeichert haben, für das Ausland aber noch keine Planungsrunde stattgefunden hat und es somit keine Werte in der Datenbank gibt, lässt sich der Auslandsbericht mit der Exception-Reporting-Option automatisch vom Versand ausschließen – er erscheint dann gar nicht erst in der generierten Berichtsmappe. Unterschiedliche Berechtigungen können eine ähnliche Wirkung entfalten: Falls ein Bericht mit den Berechtigungen eines bestimmten Benutzers keine Werte zurückliefert, lässt sich der Report automatisch unterdrücken.

Möchten Sie die Informationsversorgung ereignisabhängig komplett unterbinden, achten Sie darauf, dass alle Berichte in Ihrer Berichtsmappe (bzw. in den Ordnern, die Sie im Berichtsserver-Job ausgewählt haben) für das Exception Reporting markiert sind. Andernfalls ist das Ergebnis des Jobs niemals „leer“, sodass immer Berichte generiert und verteilt werden.

Mahnende Schlussworte

Schon mehrfach haben wir betont: Aus mehreren Gründen sehen wir die Ausnahmeberichterstattung zwiespältig, geht es doch im Kern darum, Information zurückzuhalten. Deshalb sei ein weiteres Mal auf den Wirtschaftsinformatik-Pionier Norbert Szyperski verwiesen, der schon 1978 warnte:

„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)

Und der Business-Intelligence-Pionier Nicolas Bissantz formulierte als vorzugswürdige Alternative: „Lieber ist es mir, wir gestalten Standardberichte so attraktiv und informationsdicht, dass es Freude macht, sie zu lesen und man gar nicht auf die Idee kommt, sie unterdrücken zu wollen.“