Fünf Dinge, die Sie wis­sen soll­ten, Fort­setz­ung (4/5)

Wir fahren fort mit dem Vierten der fünf Punkte, die ich persönlich als „essentiell“ ansehe. Schritt eins, betitelt mit „Wissen sollten, was Sie wissen möchten“, drehte sich darum, die Geschäftsprozesse zu verstehen und darauf aufbauend eine Fragestellung möglichst detailliert zu erarbeiten sowie zu beschreiben. Dies war die Basis dafür, diese auch wirklich konkret beantworten zu können. Nur durch genaue inhaltliche Durchdringung der betrieblichen Abläufe können die Analyseanforderungen entsprechend gut formuliert werden. Wir hatten als Beispiel ein Thema herangezogen, das man dem Bereich „Compliance“ zuordnen kann: „Zahlungen in kritische Länder“. Die konkreten Fragen, die sich daraus ergaben, wurden wie folgt beschrieben:

• Erstelle eine Liste von Ausgangszahlungen an Kunden oder Lieferanten.
• Prüfe, ob es zu Zahlungen ohne Geschäftspartner gekommen ist („Aufwand an Bank“).
• Für diese Ausgangszahlungen soll das Bankland des Zahlungsempfängers identifiziert werden.
• Im Kern der Analyse wird das Land, in das die Zahlung geleistet wurde, mit der Liste von Ländern abgeglichen, die auf Grund von CPI/Embargo oder Steueraspekten als kritisch definiert wurden.

Im zweiten Artikel wurde erklärt, wie wichtig es ist zu „wissen, mit welchen Systemen man es zu tun hat“. In unserem fiktiven Beispiel konnten wir herausfinden, dass unsere Zahlungstransaktionen sich auf einem SAP® System „SY2“ mit Release SAP® ERP ECC 6.0 befinden, da dort die Buchhaltung für alle Teilgesellschaften weltweit zentral abgewickelt wird.

Aspekt 4: Wissen, was die Analysetools können

Nach der Erarbeitung der Datenstrukturen und der Definition des notwendigen Inputs können wir mit dem Analysieren beginnen. Dafür müssen wir die technischen Möglichkeiten der Analysetools kennen, aber auch deren Grenzen und Einschränkungen. Hier dreht es sich also konkret um die Beschreibung der Tools, die für das CCM Projekt benötigt werden.

Natürlich hängt dies von der gewünschten Ausgestaltung und den technischen Rahmenbedingungen ab, die geschaffen werden sollten (oder mit denen man zurechtkommen muss, da bereits vorhanden). Was auf alle Fälle benötigt wird, ist eine Software, mit der Datenanalyse gemacht werden kann (crunching) und in der die Analyseroutinen enthalten sind. Was jedoch auch in der Regel gebraucht wird, da es dem ganzen vorgeschaltet ist, ist ein Tool für Datenextraktion, das auf die notwendigen Quelldaten zugreift, diese extrahiert und auf einem Laptop oder Server ablegt. Die folgende Abbildung zeigt beispielhaft eine solche Architektur. Quelle ist der ISACA Artikel “Automated Audit Testing for SAP Data – Benefit or Just Another Black Box?” (Kim-Reinartz, A.; Wenig, S.: „Automated Audit Testing for SAP Data – Benefit or Just Another Black Box?“, in ISACA Journal, Volume 3/2011, S. 25-30. Originalartikel; Deutsche Übersetzung).

Ob man ein Datenanalysetool benötigt, hängt grundsätzlich von der Frage ab “Innerhalb oder Außerhalb”?

Innerhalb bedeutet, dass Sie versuchen können, die Daten direkt im oder mittels des ERP Systems, etwa des im Beispiel beschriebenen SAP® Systems, zu analysieren. „Außerhalb“ würde heißen, dass die Daten wie in der Einleitung beschrieben extrahiert und auf einem separaten Computer analysiert werden. Für unser Beispiel werden wir uns mit letzterem beschäftigen, und die zu analysierenden Daten erst einmal extrahieren.

Dies bietet in der Tat einige wichtige Vorteile:

1. Performance
2. Unabhängigkeit
3. Flexibilität

Als Erstes sollte man an die Performance der Analysen und mögliche Beeinträchtigungen des ERP Systems an sich denken. Wenn man die Daten außerhalb des SAP® Systems analysiert, kann dessen Leistung durch die Analysen auch nicht beeinträchtigt werden.Man stelle sich eine umfangreiche und komplexe Analyse vor, die 50 Tabellen in Kombination mit Millionen oder manchmal sogar Milliarden an Datensätzen erfordert: Würde man dieses Vorhaben direkt auf dem SAP® System an sich durchführen wollen, so würden die meisten IT Administratoren wohl definitiv davon abraten. Befinden sich jedoch die Daten erst einmal außerhalb des Systems, auf einem separaten Computer bzw. Server, ist man völlig frei in der Umsetzung seiner Analysen – das Produktivsystem wird keinesfalls beeinträchtigt. Im ISACA Artikel hatten wir das Ganze als „Download once – Analyze often“ charakterisiert.

Zweitens sollte man die Unabhängigkeit und Verlässlichkeit der Vorgehensweise im Hinterkopf behalten. Wenn man selber auf die Daten zugreifen kann mittels eines eigenen Download-Tools, kann man sich sicher sein, dass es sich wirklich um die Originaldaten handelt, und diese nicht vorsätzlich oder absichtlich verändert wurden. Man denke an Fraud-Untersuchungen bzw. Betrugsaufdeckungsverfahren: Hier sollte man sicherstellen, dass möglichst wenige Personen Zugriff auf diese sensiblen Daten bekommen, bevor sie die „Analyseeinheit“ erreichen. Bestenfalls haben Sie eine zuverlässige Datenextraktionssoftware im Einsatz und können mittels dieser selber auf die Daten zugreifen.

Als dritter Vorteil, ähnlich der Unabhängigkeit beim Datenzugriff, ist die weitaus größere Flexibilität zu nennen. Falls sich die Daten auf einem eigenen Server befinden, also aus dem Ursprungssystem extrahiert wurden, können diese zusätzlich zum CCM Ansatz in unserem Beispiel auch für Ad-Hoc Analysen genutzt wurden; man kann diese Daten mobil (etwa in Verbindung mit einer verschlüsselten Festplatte) für Analysen nutzen, zum Beispiel in Verbindung mit Audits, die vor Ort durchgeführt werden.

Aus diesem Grund werden wir für unser Beispiel “Zahlungen in kritische Länder” in einer CCM Umgebung Datenextraktionssoftware einsetzen. Falls Sie eine Kaufentscheidung treffen müssen, sollten Sie unter anderem folgende Aspekte mit in Betracht ziehen:

• Nur-Lesezugriff
• Massendatenfähigkeit
• Performance
• Delta-Downloads
• Automatisierungsmöglichkeiten
• Usability
• Die richtigen Zielformate
• Datenschutz

Natürlich kann der Eindruck entstehen, dass wir hier etwas voreingenommen sind, da wir eine Software anbieten, die diese Kriterien erfüllt und Daten aus SAP® Systemen extrahiert, aber für diesen Artikel haben wir auf Marketing verzichtet und führen die einzelnen Punkte objektiv an.

Nur-Lesezugriff bedeutet, dass die Datenextraktionssoftware nicht in der Lage sein sollte, die Daten auf dem Quellsystem zu verändern; alle Projektbeteiligten werden viel entspannter sein, wenn die Daten weder absichtlich noch unabsichtlich verändert werden können. Für die Extraktionsmöglichkeiten sollte gelten, dass das Tool wirklich für große Datenmengen (Big data) geeignet sein muss. Wenn man an die Zahlungsvorgänge in unserem Beispiel denkt, könnten sich hier im Kunden- und Lieferantenbereich Millionen Datensätze über die Jahre angesammelt haben; gerade in Verbindung mit Hauptbuch oder Änderungstabellen wurden wir in der Vergangenheit mit Datensatzzahlen konfrontiert, die sich im Milliardenbereich bewegt haben – das Datenextraktionstool muss in der Lage sein, diese zu verarbeiten bzw. extrahieren zu können.

Trotzdem muss die eingangs formulierte Forderung, dass die Systemperformance des ERP Systems (in unserem Falle SAP®) nicht beeinträchtigt werden darf, weder durch die Analysen an sich, noch durch die Extraktion im Vorfeld, verdeutlicht werden. Bestenfalls können mit dem Extraktionstool die Daten rund um die Uhr heruntergeladen werden, ohne dass dies zu Beeinträchtigungen in irgendeiner Form führt. Zudem ist es, speziell für ein CCM-Szenario, von Bedeutung, dass ein Delta an Daten heruntergeladen werden kann. Das bedeutet, statt eines kompletten Datenabzuges aller REGUH Datensätze Monat für Monat ist man in der Lage, nur die im letzten Monat neu hinzugekommenen Datensätze (das Delta) zu extrahieren. Das hängt nahezu direkt zusammen mit der Anforderung der Automatisierung. Es sollte keines manuellen Eingriffes durch einen Benutzer bedürfen, die Datenextraktion jedes Mal aufs Neue zu starten. Gerade für kontinuierliche bzw. regelmäßige Analysen sollte eine solche Automatisierung mittels Zeitsteuerung („Scheduling“) möglich sein. Für den Fall, dass ein Benutzer aus verschiedenen Gründen das Downloadtool manuell bedienen muss (um z.B. für Ad-Hoc Analysen weitere Daten zu beschaffen) spielt eine gute Usability eine gewichtige Rolle. Es sollte möglich sein, technische Dinge wie Datenextraktion aus einem SAP® System von Personen durchführen zu lassen, die primär betriebswirtschaftlichen, nicht technischen Background haben.

Hier wäre es gut, wenn der im letzten Kapitel definierte Tabellen- und Feldkatalog ohne viel Aufwand als Input für das Extraktionstool verwendet werden könnte, ohne dass dies manuell zu geschehen hat. Zu guter Letzt sollen noch die Datenformate angesprochen werden, auch in Verbindung mit Datenschutzaspekten. Das Datenextraktionstool ist die Schnittstelle zwischen dem SAP® System und der Analysesoftware. Es konvertiert die Daten idealerweise bereits während des Extraktionsvorganges in das Format, das die Datenanalysesoftware benötigt. So wird sichergestellt, dass die Daten möglichst ohne Medien- oder Formatbruch von A nach B gelangen, und das Risiko von Veränderungen so klein wie möglich gehalten wird. Auch Datenschutzaspekte, Verschlüsselung oder Anonymisierung kann in diesem Zusammenhang von Bedeutung sein, je nach gesetzlichen Regelungen oder internen Richtlinien.

Für unser Beispiel gehen wir davon aus, dass das Extraktionstool oben genannte Kriterien erfüllt, und dass die Daten basierend auf der im letzten Kapitel definierten Tabellen- und Feldliste heruntergeladen wurden. Sie befinden sich nun in der Datenanalysesoftware. Was sollte aber nun bei der Datenextrakionssoftware beachtet werden? Viele der hier aufgeführten Checklist-Punkte decken sich mit den Anforderungen, die bereits im Rahmen der Datenextraktion definiert wurden:

• Massendatenfähigkeit
• Performance
• Client/Server Architektur
• Automatisierung
• Usability
• Transparenz
• Nur-Lesezugriff
• Content
• Ausgabeformate

Es ist ziemlich offensichtlich, dass auch hier die Fähigkeit zur Verarbeitung von Massendaten benötigt wird. Wenn Millionen von Datensätze aus dem SAP® System extrahiert wurden, müssen diese auch von der Analysesoftware verarbeitet werden können. In der Tat wird es in vielen Fällen spezieller Software bedürfen, denn die „Standardsoftware“ die zwar oft ohnehin verfügbar ist, hat oft enge Grenzen, wenn es um das verarbeitbare Datenvolumen geht. In der Regel sind deswegen Tools wie Microsoft Excel™ oder sogar Microsoft Access™ nicht ausreichend. Excel 2010™ zum Beispiel gibt die Grenzen mit 1.048.576 Datensätzen an, was für viele umfangreichere Analysen einfach nicht genug ist. Schon bei der Analyse des Hauptbuches ist hier oft Schluss. Sogar Access 2010™ stößt mit einem Limit von 2 Gigabyte pro Datenbank in der Regel zu schnell an seine Grenzen, wenn es um CCM-Projekte geht.

Unbegrenzte Datensätze verarbeiten zu können ist eine Seite der Medaille – diese auch in vernünftiger Geschwindigkeit analysieren zu können, eine andere. Die Datenanalysesoftware muss in der Lage sein, Daten schnell und mit guter Performance zu verarbeiten. Das hängt oft vom Datenformat ab, auf dem die Analysesoftware basiert, aber auch von der Softwarearchitektur der Lösung. Natürlich könnte man den Versuch machen, Engpässe in diesem Fall mit sehr performanter Hardware auszugleichen; andererseits macht es oft keinen Sinn, architektonische Softwareschwächen dadurch auszugleichen, dass man x Server in Reihe schaltet (der „kill it with iron“-Ansatz). Sogar für den Fall, dass die Analysesoftware im Moment performant genug ist, ist der Aspekt der Skalierbarkeit zu berücksichtigen. Eine analytische Fragestellung bedarf vielleicht relativ weniger Daten, aber wenn man ein Portfolio von 100 und mehr Fragestellungen aufgebaut hat, kann das aus Performancesicht zum Problem werden, wenn man nicht vorsorgt.

Da wir nach wie vor über einen CCM-Ansatz sprechen, also eine Continuous-Controls-Umgebung, müssen auch die Datenanalysen nach einem bestimmten Zeitplan ausgeführt werden können. Auch hier bedarf es also der Möglichkeit der Automatisierung. Wenn beispielsweise unsere „Zahlungen in kritische Länder“ monatlich ausgeführt werden sollen, bedarf dies eines Programmes oder Makros („Analyseroutine“), das mittels einer internen Uhr („Scheduler“) automatisch ausgeführt werden kann. Viele Analysetools bieten die Möglichkeit, Makros zu erstellen oft mittels eigener Programmier- oder Skriptsprachen, in der die Analysen erstellt und implementiert werden können. Wenn Sie mit Programmierung nicht vertraut sind, denken Sie an Excel Makros, die aufgenommen und beliebig oft wieder abgespielt werden können.

Der Bedarf, eine zentrale CCM-Lösung zu etablieren, die auch noch Performanz und mit dem SAP® System über die Datenextraktionsschnittstelle integriert ist, und die Ergebnisse an Einheiten und Abteilungen weltweit automatisiert verteilt, bedarf in der Regel einer vollwertigen Client/Server-Lösung. Ganz abgesehen vom möglicherweise großen Datenvolumen bedarf es eines profunden Vehikels, wenn man diese Reise aus Projektsicht aufbricht. Viele Tools können lokal installiert werden und sind auch ziemlich mächtig, aber alle genannten Anforderungen lassen sich in der Regel nur mit einer Software abdecken, die für Teamarbeit und verteilte Systeme konzipiert wurde, User- und Rechtemagement bietet, Multiprozessor-Nutzung garantiert und im Hintergrund weiterarbeitet, auch wenn die Laptops der Datenanalysten schon lange geschlossen sind.

Die Programmiersprache, aber auch das Programm an sich muss eine gute Usability bieten. Es gibt viele gute Tools am Markt, die allerdings eher technisch orientiert sind. Diese sollen jedoch oft von Benutzern bedient werden, die kaum oder wenig IT Background haben – sie bringen jedoch die betriebswirtschaftlichen Fragestellungen mit und können die Ergebnisse interpretieren. Die Analysesoftware muss also den Zugang ermöglichen, betriebswirtschaftliche Fragestellungen mit technischen Mitteln lösen zu können, ohne in der Bedienung zu IT-lastig zu sein.

So weit so gut, aber was bedeutet „Transparenz“ im Zusammenhang mit der Analysesoftware? Für Sie als Datenanalysten kann das ein gewichtiges Feature sein, das Ihr Leben einfacher macht. Stellen Sie sich vor, dass Sie nicht eine, sondern 20 Analysen durchführen müssen. Stellen Sie sich vor, dass Sie die Ergebnisse an 20 Abteilungen weltweit verteilen müssen, und damit auch auf Management-Ebene Aufmerksamkeit auf sich ziehen, wenn Ihre Analyseergebnisse Risiken aufzeigen oder anderweitig schwergewichtige Fragen aufwerfen. Sie werden wahrscheinlich häufig mit der Frage konfrontiert „Moooooment, wurde die Analyse überhaupt korrekt durchgeführt? Wie wurde sichergestellt, dass kein Fehler gemacht wurde beim Erstellen der Auswertung? Ist denn berücksichtigt worden, dass man xyz beachten muss?“ Vermutlich eine der schlechtesten Antworten in diesem Zusammenhäng wäre „Keine Ahnung, ich habe einfach auf den Knopf gedrückt und das Ding gestartet.“ Im ISACA Artikel, der oben angesprochen wurde, haben wir betont, dass es wichtig ist, einen „Black Box Effekt“ zu vermeiden. Software und Analysen müssen so transparent wie möglich sein. Viele Analysetools bieten eine Logfile-Funktionalität, die hier sehr nützlich sein kann. Falls dies im Einzelfall nicht ausreichend ist, muss mittels geeigneter Dokumentation unterstützt werden.

Dass die Daten im Rahmen der Analysen ebenfalls im Nur-Lesezugriff verarbeitet werden, vermeidet unbeabsichtigte Fehler und Verfälschungen der Originaldaten, etwa durch versehentliches Überschreiben von Werten (im Englischen gibt es hier den netten Ausdruck “Fat Finger Errors” oder Copy&Paste Fehler, etwa beim Übertragen von Formeln auf mehrere Zellen. Es darf nicht vergessen werden, dass wir es hier in der Regel mit sehr großen Datenmengen und komplexen Strukturen zu tun haben. Manuelle Fehler sind in diesem Zahlenhaufen nur sehr schwer durch bloßes „Durchlesen“ der Daten zu finden.

Es gibt einige Analysewerkzeuge am Markt, auf die diese Beschreibung zutrifft. Eines davon ist ACL™ (Audit Command Language) von ACL Services Limited oder IDEA von Audicon. Für unsere Projekte benutzen wir in der Hauptsache ACL™, denn viele der oben aufgeführten Kriterien sind dort mehr oder weniger vollumfänglich vorhanden; zumindest sind sie gut balanciert. Mit der neuen Client/Server Lösung ACL™ Analytic Exchange (AX) kann man im Bereich CCM und Zusammenarbeit von Teams sehr viel erreichen, und auch die Desktoplösung ACL™ Analytics (AN) hat sich im Bereich neuer Features und Usability zunehmend weiterentwickelt. Wenn Sie ein CCM Projekt durchführen wollen, nutzen Sie obige Checkliste, und entscheiden Sie für Sich, welche Lösung Ihren Ansprüchen am besten genügt. Auch Testlizenzen oder Proof-of-Concepts sind bei diesen komplexen Themen hilfreich.

Zu guter Letzt sollten Sie nach “Content” Ausschau halten. Sie müssen möglicherweise das Rad nicht neu erfinden. Hunderte Firmen haben möglicherweise bereits vor Ihnen „Zahlungen in kritische Länder“ basierend auf Daten aus einem SAP® System analysiert. Statt 50 Personentage an Implementierungsarbeit in die Neuentwicklung dieser Analyseroutine zu stecken, gibt es möglicherweise bereits eine out-of-the-box Lösung für die Analysesoftware, die Sie angeschafft haben oder anschaffen wollen. Das kann Ihre Projekte in Kernpunkten wesentlich beschleunigen. Die Analysesoftware ist nur die Hülle – Content is Key.

Wenn wir unsere “5 Punkte” als Checkliste zu Grunde legen, haben wir damit die ersten vier Punkte erfolgreich klären können: