Posts

Process Mining Tools – Artikelserie

Process Mining ist nicht länger nur ein Buzzword, sondern ein relevanter Teil der Business Intelligence. Process Mining umfasst die Analyse von Prozessen und lässt sich auf alle Branchen und Fachbereiche anwenden, die operative Prozesse haben, die wiederum über operative IT-Systeme erfasst werden. Um die zunehmende Bedeutung dieser Data-Disziplin zu verstehen, reicht ein Blick auf die Entwicklung der weltweiten Datengenerierung an. Waren es 2010 noch 2 Zettabytes (ZB), sind laut Statista für das Jahr 2020 mehr als 50 ZB an Daten zu erwarten. Für 2025 wird gar mit einem Bestand von 175 ZB gerechnet.

Hier wird das Datenvolumen nach Jahren angezeit

Abbildung 1 zeigt die Entwicklung des weltweiten Datenvolumen (Stand 2018). Quelle: https://www.statista.com/statistics/871513/worldwide-data-created/

Warum jetzt eigentlich Process Mining?

Warum aber profitiert insbesondere Process Mining von dieser Entwicklung? Der Grund liegt in der Unordnung dieser Datenmenge. Die Herausforderung der sich viele Unternehmen gegenübersehen, liegt eben genau in der Analyse dieser unstrukturierten Daten. Hinzu kommt, dass nahezu jeder Prozess Datenspuren in Informationssystemen hinterlässt. Die Betrachtung von Prozessen auf Datenebene birgt somit ein enormes Potential, welches in Anbetracht der Entwicklung zunehmend an Bedeutung gewinnt.

Was war nochmal Process Mining?

Process Mining ist eine Analysemethodik, welche dazu befähigt, aus den abgespeicherten Datenspuren der Informationssysteme eine Rekonstruktion der realen Prozesse zu schaffen. Diese Prozesse können anschließend als Prozessflussdiagramm dargestellt und ausgewertet werden. Die klassischen Anwendungsfälle reichen von dem Aufspüren (Discovery) unbekannter Prozesse, über einen Soll-Ist-Vergleich (Conformance) bis hin zur Anpassung/Verbesserung (Enhancement) bestehender Prozesse. Mittlerweile setzen viele Firmen darüber hinaus auf eine Integration von RPA und Data Science im Process Mining. Und die Analyse-Tiefe wird zunehmen und bis zur Analyse einzelner Klicks reichen, was gegenwärtig als sogenanntes „Task Mining“ bezeichnet wird.

Hier wird ein typischer Process Mining Workflow dargestellt

Abbildung 2 zeigt den typischen Workflow eines Process Mining Projektes. Oftmals dient das ERP-System als zentrale Datenquelle. Die herausgearbeiteten Event-Logs werden anschließend mittels Process Mining Tool visualisiert.

In jedem Fall liegt meistens das Gros der Arbeit auf die Bereitstellung und Vorbereitung der Daten und der Transformation dieser in sogenannte „Event-Logs“, die den Input für die Process Mining Tools darstellen. Deshalb arbeiten viele Anbieter von Process Mining Tools schon länger an Lösungen, um die mit der Datenvorbereitung verbundenen zeit -und arbeitsaufwendigen Schritte zu erleichtern. Während fast alle Tool-Anbieter vorgefertigte Protokolle für Standardprozesse anbieten, gehen manche noch weiter und bieten vollumfängliche Plattform Lösungen an, welche eine effiziente Integration der aufwendigen ETL-Prozesse versprechen. Der Funktionsumfang der Process Mining Tools geht daher mittlerweile deutlich über eine reine Darstellungsfunktion hinaus und deckt ggf. neue Trends sowie optimierte Einsteigerbarrieren mit ab.

Motivation dieser Artikelserie

Die Motivation diesen Artikel zu schreiben liegt nicht in der Erläuterung der Methode des Process Mining. Hierzu gibt es mittlerweile zahlreiche Informationsquellen. Eine besonders empfehlenswerte ist das Buch „Process Mining“ von Will van der Aalst, einem der Urväter des Process Mining. Die Motivation dieses Artikels liegt viel mehr in der Betrachtung der zahlreichen Process Mining Tools am Markt. Sehr oft erlebe ich als Data-Consultant, dass Process Mining Projekte im Vorfeld von der Frage nach dem „besten“ Tool dominiert werden. Diese Fragestellung ist in Ihrer Natur sicherlich immer individuell zu beantworten. Da individuelle Projekte auch einen individuellen Tool-Einsatz bedingen, beschäftige ich mich meist mit einem großen Spektrum von Process Mining Tools. Daher ist es mir in dieser Artikelserie ein Anliegen einen allgemeingültigen Überblick zu den üblichen Process Mining Tools zu erarbeiten. Dabei möchte ich mich nicht auf persönliche Erfahrungen stützen, sondern die Tools anhand von Testdaten einem praktischen Vergleich unterziehen, der für den Leser nachvollziehbar ist.

Um den Umfang der Artikelserie zu begrenzen, werden die verschiedenen Tools nur in Ihren Kernfunktionen angewendet und verglichen. Herausragende Funktionen oder Eigenschaften der jeweiligen Tools werden jedoch angemerkt und ggf. in anderen Artikeln vertieft. Das Ziel dieser Artikelserie soll sein, dem Leser einen ersten Einblick über die am Markt erhältlichen Tools zu geben. Daher spricht dieser Artikel insbesondere Einsteiger aber auch Fortgeschrittene im Process Mining an, welche einen Überblick über die Tools zu schätzen wissen und möglicherweise auch mal über den Tellerand hinweg schauen mögen.

Die Tools

Die Gruppe der zu betrachteten Tools besteht aus den folgenden namenhaften Anwendungen:

Die Auswahl der Tools orientiert sich an den „Market Guide for Process Mining 2019“ von Gartner. Aussortiert habe ich jene Tools, mit welchen ich bisher wenig bis gar keine Berührung hatte. Diese Auswahl an Tools verspricht meiner Meinung nach einen spannenden Einblick von verschiedene Process Mining Tools am Markt zu bekommen.

Die Anwendung in der Praxis

Um die Tools realistisch miteinander vergleichen zu können, werden alle Tools die gleichen Datengrundlage benutzen. Die Datenbasis wird folglich über die gesamte Artikelserie hinweg für die Darstellungen mit den Tools genutzt. Ich werde im nächsten Artikel explizit diese Datenbasis kurz erläutern.

Das Ziel der praktischen Untersuchung soll sein, die Beispieldaten in die verschiedenen Tools zu laden, um den enthaltenen Prozess zu visualisieren. Dabei möchte ich insbesondere darauf achten wie bedienbar und anpassungsfähig/flexibel die Tools mir erscheinen. An dieser Stelle möchte ich eindeutig darauf hinweisen, dass dieser Vergleich und seine Bewertung meine Meinung ist und keineswegs Anspruch auf Vollständigkeit beansprucht. Da der Markt in Bewegung ist, behalte ich mir ferner vor, diese Artikelserie regelmäßig anzupassen.

Die Kriterien

Neben der Bedienbarkeit und der Anpassungsfähigkeit der Tools möchte ich folgende zusätzliche Gesichtspunkte betrachten:

  • Bedienbarkeit: Wie leicht gehen die Analysen von der Hand? Wie einfach ist der Einstieg?
  • Anpassungsfähigkeit: Wie flexibel reagiert das Tool auf meine Daten und Analyse-Wünsche?
  • Integrationsfähigkeit: Welche Schnittstellen bringt das Tool mit? Läuft es auch oder nur in der Cloud?
  • Skalierbarkeit: Ist das Tool dazu in der Lage, auch große und heterogene Daten zu verarbeiten?
  • Zukunftsfähigkeit: Wie steht es um Machine Learning, ETL-Modeller oder Task Mining?
  • Preisgestaltung: Nach welchem Modell bestimmt sich der Preis?

Die Datengrundlage

Die Datenbasis bildet ein Demo-Datensatz der von Celonis für die gesamte Artikelserie netter Weise zur Verfügung gestellt wurde. Dieser Datensatz bildet einen Versand Prozess vom Zeitpunkt des Kaufes bis zur Auslieferung an den Kunden ab. In der folgenden Abbildung ist der Soll Prozess abgebildet.

Hier wird die Variante 1 der Demo Daten von Celonis als Grafik dargestellt

Abbildung 4 zeigt den gewünschten Versand Prozess der Datengrundlage von dem Kauf des Produktes bis zur Auslieferung.

Die Datengrundlage besteht aus einem 60 GB großen Event-Log, welcher lokal in einer Microsoft SQL Datenbank vorgehalten wird. Da diese Tabelle über 600 Mio. Events beinhaltet, wird die Datengrundlage für die Analyse der einzelnen Tools auf einen Ausschnitt von 60 Mio. Events begrenzt. Um die Performance der einzelnen Tools zu testen, wird jedoch auf die gesamte Datengrundlage zurückgegriffen. Der Ausschnitt der Event-Log Tabelle enthält 919 verschiedene Varianten und weisst somit eine ausreichende Komplexität auf, welche es mit den verschiednene Tools zu analysieren gilt.

Folgender Veröffentlichungsplan gilt für diese Artikelserie und wird mit jeder Veröffentlichung verlinkt:

  1. Celonis (erscheint demnächst)
  2. PAFnow (erscheint demnächst)
  3. MEHRWERK (erscheint demnächst)
  4. Lana Labs (erscheint demnächst)
  5. Signavio (erscheint demnächst)
  6. Process Gold (erscheint demnächst)
  7. Fluxicon Disco (erscheint demnächst)
  8. Aris Process Mining der Software AG (erscheint demnächst)

Artikelserie: BI Tools im Vergleich – Datengrundlage

Dieser Artikel wird als Fortsetzung des ersten Artikels, einer Artikelserie zu BI Tools, die Datengrundlage erläutern.

Als Datengrundlage sollen die Trainingsdaten – AdventureWorks 2017 – von Microsoft dienen und Ziel soll es sein, ein möglichst gleiches Dashboard in jedem dieser Tools zu erstellen.

Bei der Datenbasis handelt es sich bereits um ein relationales Datenbankmodel mit strukturierten Daten, welches als Datei-Typ .bak zur Verfügung steht. Die Daten sind bereits bereinigt und normalisiert, sowie bestehen auch bereits Beziehungen zwischen den Tabellen. Demnach fallen sowohl aufwendige Datenbereinigungen weg, als auch der Aufbau eines relationalen Datenmodells im Dashboard. In den meisten Tools ist beides möglich, wenn auch nicht das optimale Programm. Vor allem sollte vermieden werden Datenbereinigungen in BI Tools vorzunehmen. Alle Tools bieten einem die Möglichkeit strukturierte und unstrukturierte Daten aus verschiedensten Datenquellen zu importieren. Die Datenquelle wird SQL Server von Microsoft sein, da die .bak Datei nicht direkt in die meisten Dashboards geladen werden kann und zudem auf Grund der Datenmenge ein kompletter Import auch nicht ratsam ist. Aus Gründen der Performance sollten nur die für das Dashboard relevanten Daten importiert werden. Für den Vergleich werden 15 von insgesamt 71 Tabellen importiert, um Visualisierungen für wesentliche Geschäftskennzahlen aufzubauen. Die obere Grafik zeigt das Entity-Relationship-Modell (ERM) zu den relevanten Tabellen. Die Datengrundlage eignet sich sehr gut für tiefer gehende Analysen und bietet zugleich ein großes Potential für sehr ausgefallene Visualisierungen. Im Fokus dieser Artikelserie soll aber nicht die Komplexität der Grafiken, sondern die allgemeine Handhabbarkeit stehen. Allgemein besteht die Gefahr, dass die Kernaussagen eines Reports in den Hintergrund rücken bei der Verwendung von zu komplexen Visualisierungen, welche lediglich der Ästhetik dienlich sind.

Eine Beschränkung soll gelten: So soll eine Manipulation von Daten lediglich in den Dashboards selbst vorgenommen werden. Bedeutet das keine Tabellen in SQL Server geändert oder Views erstellt werden. Gehen wir einfach Mal davon aus, dass der Data Engineer Haare auf den Zähnen hat und die Zuarbeit in jeglicher Art und Weise verwehrt wird.

Also ganz nach dem Motto: Help yourself! 😉

Daten zum Üben gibt es etliche. Einfach Mal Github, Kaggle oder andere Open Data Quellen anzapfen. Falls ihr Lust habt, dann probiert euch doch selber einmal an den Dashboards. Ihr solltet ein wenig Zeit mitbringen, aber wenn man erstmal drin ist macht es viel Spaß und es gibt immer etwas neues zu entdecken! Das erste Dashboard und somit die Fortsetzung dieser Artikelserie wird  Power BI als Grundlage haben.

Hier ein paar Links um euch startklar zu machen, falls das Interesse in euch geweckt wurde.

Dataset: AdventureWorks 2017

MS SQL Server

MS SSMS

MS Power BI (Desktop)

Artikelserie: BI Tools im Vergleich – Einführung und Motivation

„Mit welchem BI-Tool arbeitest du am liebsten?“ Mit dieser Frage werde ich dieser Tage oft konfrontiert. Meine klassische Antwort und eine typische Beraterantwort: „Es kommt darauf an.“ Nach einem Jahr als Berater sitzt diese Antwort sicher, aber gerade in diesem Fall auch begründet. Auf den Analytics und Business Intelligence Markt drängen jedes Jahr etliche neue Dashboard-Anbieter und die etablierten erweitern Services und Technik in rasantem Tempo. Zudem sind die Anforderungen an ein BI-Tool höchst unterschiedlich und von vielen Faktoren abhängig. Meine Perspektive, also die Anwenderperspektive eines Entwicklers, ist ein Faktor und auch der Kern dieser Artikelserie. Um die Masse an Tools auf eine machbare Anzahl runter zu brechen werde ich die bekanntesten Tools im Vergleich ausprobieren und hier vorstellen. Die Aufgabe ist also schnell erklärt: Ein Dashboard mit den gleichen Funktionen und Aussagen in unterschiedlichen Tools erstellen. Im Folgenden werde ich auch ein paar Worte zur Bewertungsgrundlage und zur Datengrundlage verlieren.

Erstmal kurz zu mir: Wie bereits erwähnt arbeite ich seit einem Jahr als Berater, genauer als Data Analyst in einem BI-Consulting Unternehmen namens DATANOMIQ. Bereits davor habe ich mich auf der anderen Seite der Macht, quasi als Kunde eines Beraters, viel mit Dashboards beschäftigt. Aber erst in dem vergangenen Jahr wurde mir die Fülle an BI Tools bewusst und der Lerneffekt war riesig. Die folgende Grafik zeigt alle Tools welche ich in der Artikelserie vorstellen möchte.

Gartner’s Magic Quadrant for Analytics and Business Intelligence Platform führt jedes Jahr eine Portfolioanalyse über die visionärsten und bedeutendsten BI-Tools durch, unter der genannten befindet sich nur eines, welches nicht in dieser Übersicht geführt wird, ich jedoch als potenziellen Newcomer für die kommenden Jahre erwarte. Trotz mittlerweile einigen Jahren Erfahrung gibt es noch reichlich Potential nach oben und viel Neues zu entdecken, gerade in einem so direkten Vergleich. Also seht mich ruhig als fortgeschrittenen BI-Analyst, der für sich herausfinden will, welche Tools aus Anwendersicht am besten geeignet sind und vielleicht kann ich dem ein oder anderen auch ein paar nützliche Tipps mit auf den Weg geben.

Was ist eigentlich eine „Analytical and Business Intelligence Platform“?

Für alle, die komplett neu im Thema sind, möchte ich erklären, was eine Analytical and Business Intelligence Platform in diesem Kontext ist und warum wir es nachfolgend auch einfach als BI-Tool bezeichnen können. Es sind Softwarelösungen zur Generierung von Erkenntnissen mittels Visualisierung und Informationsintegration von Daten. Sie sollten einfach handhabbar sein, weil der Nutzer für die Erstellung von Dashboards keine speziellen IT-Kenntnisse mitbringen muss und das Userinterface der jeweiligen Software einen mehr oder minder gut befähigt die meisten Features zu nutzen. Die meisten und zumindest die oben genannten lassen sich aber auch um komplexere Anwendungen und Programmiersprachen erweitern. Zudem bestimmt natürlich auch der Use Case den Schwierigkeitsgrad der Umsetzung.

Cloudbasierte BI Tools sind mittlerweile der Standard und folgen dem allgemeinen Trend. Die klassische Desktop-Version wird aber ebenfalls von den meisten angeboten. Von den oben genannten haben lediglich Data Studio und Looker keine Desktop- Version. Für den einfachen User macht das keinen großen Unterschied, welche Version man nutzt. Aber für das Unternehmen in Gesamtheit ist es ein wesentlicher Entscheidungsfaktor für die Wahl der Software und auch auf den Workflow des Developers bzw. BI-Analyst kann sich das auswirken.

Unternehmensperspektive: Strategie & Struktur

Die Unternehmensstrategie setzt einen wesentlichen Rahmen zur Entwicklung einer Datenstrategie worunter auch ein anständiges Konzept zur Data Governance gehört.

Ein wesentlicher Punkt der Datenstrategie ist die Verteilung der BI- und Datenkompetenz im Unternehmen. An der Entwicklung der Dashboards arbeiten in der Regel zwei Parteien, der Developer, der im Unternehmen meistens die Bezeichnung BI- oder Data Analyst hat, und der Stakeholder, also einzelner User oder die User ganzer Fachabteilungen.

Prognose: Laut Gartner wird die Anzahl der Daten- und Analyse-Experten in den Fachabteilungen, also die Entwickler und Benutzer von BI Tools, drei Mal so schnell wachsen verglichen mit dem bereits starken Wachstum an IT-Fachkräften.

Nicht selten gibt es für ein Dashboard mehrere Stakeholder verschiedener Abteilungen. Je nach Organisation und Softwarelösung mit unterschiedlich weitreichenden Verantwortlichkeiten, was die Entwicklung eines Dashboards an geht.

Die obige Grafik zeigt die wesentlichen Prozessschritte von der Konzeption bis zum fertigen Dashboard und drei oft gelebte Konzepte zur Verteilung der Aufgaben zwischen dem User und dem Developer. Natürlich handelt es sich fast immer um einen iterativen Prozess und am Ende stellen sich auch positive Nebenerkenntnisse heraus. Verschiedene Tools unterstützen durch Ihre Konfiguration und Features verschiedene Ansätze zur Aufgabenverteilung, auch wenn mit jedem Tool fast jedes System gelebt werden kann, provozieren einige Tools mit ihrem logischen Aufbau und dem Lizenzmodell zu einer bestimmten Organisationsform. Looker zum Beispiel verkauft mit der Software das Konzept, dem User eine größere Möglichkeit zu geben, das Dashboard in Eigenregie zu bauen und gleichzeitig die Datenhoheit an den richtigen Stellen zu gewährleisten (mittlerer Balken in der Grafik). Somit wird dem User eine höhere Verantwortung übertragen und weit mehr Kompetenzen müssen vermittelt werden, da der Aufbau von Visualisierung ebenfalls Fehlerpotential in sich birgt. Ein Full‑Service hingegen unterstützt das Konzept fast aller Tools durch Zuweisen von Berechtigungen. Teilweise werden aber gewisse kostenintensive Features nicht genutzt oder auf Cloud-Lizenzen verzichtet, so dass jeder Mitarbeiter unabhängig auf einer eigenen Desktop-Version arbeitet, am Ende dann leider die Single Source of Truth nicht mehr gegeben ist. Denn das führt eigentlich gezwungenermaßen dazu, dass die User sich aus x beliebigen Datentöpfen bedienen, ungeschultes Personal falsche Berechnungen anstellt und am Ende die unterschiedlichen Abteilungen sich mit schlichtweg falschen KPIs überbieten. Das spricht meistens für ein Unternehmen ohne vollumfängliches Konzept für Data Governance bzw. einer fehlenden Datenstrategie.

Zu dem Thema könnte man einen Roman schreiben und um euch diesen zu ersparen, möchte ich kurz die wichtigsten Fragestellungen aus Unternehmensperspektive aufzählen, ohne Anspruch auf Vollständigkeit:

  • Wann wird ein Return on Invest (ROI) realisiert werden?
  • Wie hoch ist mein Budget für BI-Lösungen?
  • Sollen die Mitarbeiter mit BI-Kompetenz zentral oder dezentral organisiert sein?
  • Wie ist meine Infrastruktur aufgebaut? Cloudbasiert oder on Premise?
  • Soll der Stakeholder/User Zeit-Ressourcen für den Aufbau von Dashboards erhalten?
  • Über welche Skills verfügen die Mitarbeiter bereits?
  • Welche Autorisierung in Bezug auf die Datensichtbarkeit und -manipulation haben die jeweiligen Mitarbeiter der Fachabteilungen?
  • Bedarf an Dashboards: Wie häufig werden diese benötigt und wie oft werden bestehende Dashboards angepasst?
  • Kann die Data Exploration durch den Stakeholder/User einen signifikanten Mehrwert liefern?
  • Werden Dashboards in der Regel für mehrere Stakeholder gebaut?

Die Entscheidung für die Wahl eines Dashboards ist nicht nur davon abhängig, wie sich die Grafiken von links nach rechts schieben lassen, sondern es handelt sich auch um eine wichtige strategische Frage aus Unternehmersicht.

Ein Leitsatz hierbei sollte lauten:
Die Strategie des Unternehmens bestimmt die Anforderungen an das Tool und nicht andersrum!

Perspektive eines Entwicklers:      Bewertungsgrundlage der Tools

So jetzt Mal Butter bei die Fische und ab zum Kern des Artikels. Jeder der Artikel wird aus den folgenden Elementen bestehen:

  • Das Tool:
    • Daten laden
    • Daten transformieren
    • Daten visualisieren
    • Zukunftsfähigkeit am Beispiel von Pythonintegration
    • Handhabbarkeit
  • Umweltfaktoren:
    • Community
    • Dokumentation
    • Features anderer Entwickler(-firmen) zur Erweiterung
    • Lizenzmodell
      • Cloud (SaaS) ODER on premise Lizenzen?
      • Preis (pro Lizenz, Unternehmenslizenz etc.)
      • Freie Version

 

Im Rahmen dieser Artikelserie erscheinen im Laufe der kommenden Monate folgende Artikel zu den Reviews der BI-Tools:

  1. Power BI von Microsoft
  2. Tableau
  3. MicroStrategy (erscheint demnächst)
  4. Looker (erscheint demnächst)
  5. Qlik Sense (erscheint demnächst)

Über einen vorausgehend veröffentlichten Artikel wird die Datengrundlage erläutert, die für alle Reviews gemeinsam verwendet wird: Vorstellung der Datengrundlage

Wie Wirtschaftsprüfer mit auditbee die Nadel im Heuhaufen finden – Teil 2/2

Dies ist Teil 2/2 des Artikels, lesen Sie hier Wie Wirtschaftsprüfer mit auditbee die Nadel im Heuhaufen finden – Teil 1/2.

Auditbee – Datenanalyse mit Qlik Sense in der Wirtschaftsprüfung

Wir sind es mittlerweile gewohnt, vieles einfach per Knopfdruck mit unserer App zu erledigen. Warum sollte etwas anderes für die Datenanalyse gelten?

Das Ziel von auditbee ist, die Datenanalyse durchgängig in die Prüfung zu integrieren. Jeder Prüfer hat mit dem auditbee Dashboard die Möglichkeit, Daten schnell und einfach selbst zu analysieren. Nicht nur für Journal Entry Tests, sondern auch zur Prüfungsplanung, Verständnisgewinnung, Risikobeurteilung und Dokumentation.

Hierzu werden die aus der Finanzbuchhaltung extrahierten GDPdU-Daten vom auditbee Team als Service verarbeitet und dem Prüfer als abgestimmtes Modell zu Verfügung gestellt.

auditbee basiert auf der Business Intelligence Software Qlik Sense, eine in vielen Unternehmen weltweit eingesetzte Reporting Lösung. Mit Qlik Sense werden die Daten über grafische Objekte dargestellt, damit Sie für den Anwender leicht zu erfassen sind.

Mit auditbee auf Basis von Qlik Sense entsteht aus den Daten des Geschäftsjahres, dem Vorjahr und dem Folgejahr ein Modell mit verschiedenen Analysen zur Beurteilung von Geschäftsentwicklungen, für analytische Prüfungshandlungen und Journal Entry Tests. Darüber hinaus werden die Going Concern Annahme (Fortführungsprognose), Performance- und Risikoindikatoren automatisiert anhand von Erwartungswerten oder eines Risiko-Scores beurteilt.

In auditbee sind eine Vielzahl an Dashboards mit unterschiedlichen Themen eingerichtet. Jedes enthält vordefinierte Journal Entry Tests, um prüferische Fragen zu ergründen. Zudem ermöglichen die verschiedenen grafischen Objekte Ad-hoc Analysen – Zeitreihenentwicklung, Kennzahlen, Rangfolgen, etc. – um Auffälligkeiten auf den Grund zu gehen.

Abb1: Bilanzanalyse und Bestimmung der Wesentlichkeit

Abb1: Bilanzanalyse und Bestimmung der Wesentlichkeit

Abb2: Analyse des Buchungsverhaltens nach Nutzer, Erfassungsdatum und Posten

Abb2: Analyse des Buchungsverhaltens nach Nutzer, Erfassungsdatum und Posten

Abb3: Analyse des Zahlungsverhaltens nach Kunde und Zahlungsbedingung

Abb3: Analyse des Zahlungsverhaltens nach Kunde und Zahlungsbedingung

Der Audit Workflow führt den Prüfer durch die verschiedenen Prüfungsgebiete – von der Bilanzanalyse, über die Beurteilung von Performance- und Risikoindikatoren bis hin zu einer Vielzahl an themenbezogener Journal Entry Tests.

Abb4: Teilausschnitt des Audit Workflows in auditbee

Abb4: Teilausschnitt des Audit Workflows in auditbee

Prüfung mit auditbee – Beispiel: Beurteilung der zeitnahen Erfassung von Umsatzerlösen

Die Prüfung erfolgt immer nach einem ähnlichen Schema. Der Prüfer hat eine Frage, mit der er ein Fehlerrisiko einschätzen und Prüfungsaussagen treffen möchte. Mit der Frage, welche Umsatzbuchungen nicht zeitnah erfasst wurden, wird z.B. der periodengerechte Ausweis überprüft. Ein Kontoblatt kann diese Frage in der Regel nicht beantworten, weil das Erfassungsdatum nicht vorhanden ist. In auditbee sind jedoch alle extrahierten Felder aus der Finanzbuchhaltung miteinander als Modell verbunden. Deswegen können auch alle Datensätze daraufhin überprüft werden, wie groß die Zeitspanne zwischen dem Buchungs- und dem Erfassungsdatum ist. Das Erfassungsdatum ist das mit Eingabe im System protokolierte Datum. Das Buchungsdatum ist dagegen frei wählbar, sollte aber auf den Tag der Lieferung-/Leistungserbringung datiert sein.

Leistungen sind innerhalb weniger Tage abzurechnen und in der Buchhaltung zu erfassen (§ 239 Abs. 2 HGB). Wenn die Zeitspanne z.B. mehr als 30 Tage beträgt, gelten diese Buchungen als auffällig. Es besteht ein Risiko, dass entweder organisatorische Mängel bestehen (Freigaben bzw. Abrechnungen dauern zu lange) oder Umsätze abgesprochen und damit Fehlerhaft sein können. Buchungen am Jahresende tragen ein höheres Risiko. Rechnungen können z.B. nur deshalb gestellt worden sein, weil der Einkaufsverantwortliche des Kunden noch Budget hatte und dieses ausschöpfen wollte. Anders herum hat möglicherweise das Unternehmen vorzeitig Leistungen zum Jahresende abgerechnet, obwohl diese noch nicht vollständig erbracht sind. In beiden Fällen besteht das Risiko der Periodenverschiebung von Umsätzen.

Abb5: Übersicht Umsatzerlöse im Geschäftsjahr

Abb5: Übersicht Umsatzerlöse im Geschäftsjahr

Über die vordefinierte Journal Entry Test Abfrage – zeitnah BUDAT – werden dem Prüfer per Knopfdruck alle Buchungszeilen angezeigt, die das Merkmal – Erfassung zu Buchung > 30 Tage – aufweisen.

Abb6: JET-Abfrage – Alle Buchungen mit einer Zeitspanne > 30 Tagen

Von den Belegen wählt der Prüfer alle Buchungen per Dezember aus, um die richtige Periodenabgrenzung zu überprüfen.

Abb7: Dezemberbuchungen innerhalb der JET Analyse

Abb7: Dezemberbuchungen innerhalb der JET Analyse

Innerhalb der Umsatzbuchungen sind für den Prüfer solche Buchungen relevant, die an bestimmte Kunden gestellt wurden (wegen des Risikos auf dolose Handlungen).

Abb8: Filterung auffälliger Kunden

Abb8: Filterung auffälliger Kunden

Als letzten Filter wählt der Prüfer alle Beträge oberhalb der Nichtaufgriffsgrenze aus

"Abb9:

Abb9: Schichtungen nach Beträgen > 25k

Aus den verbleibenden Belegen wählt der Prüfer eine Stichprobe bewusst aus, um anhand von Nachweisen (Rechnungen, Lieferscheine, etc.) zu überprüfen, ob die Buchungen berechtigt, richtig und periodengerecht erfolgt sind. Hierzu kann er die Belegliste aus auditbee in Excel exportieren, um Sie dem Buchhalter als Belegauswahl zuzusenden. Außerdem dokumentiert der Prüfer seine Ergebnisse in der Qlik Sense Story.

Abb10: Strukturierte bewusste Belegauswahl – 4 von 13 Belege nach

Abb10: Strukturierte bewusste Belegauswahl – 4 von 13 Belege nach

Zusammenfassung und Ausblick

Datenanalysen ermöglichen dem Prüfer sehr tiefe Einblicke in die Geschäftsentwicklung des Mandanten. So kann er nicht nur sein Verständnis vom Unternehmen stetig weiterentwickeln, die Datenanalyse hilft ihm auch, Massendaten angemessen zu überprüfen.

Damit der Prüfer mit der Datenanalyse die Nadel im Heuhaufen finden, relevante Entwicklungen erkennen und Zusammenhänge besser verstehen kann, muss sie jedoch in die Prüfung integriert sein. Das bedeutet, dass sie nicht nur für Journal Entry Tests durch Spezialisten, genutzt wird, sondern jedes einzelne Teammitglied selbst anhand der Daten Auffälligkeiten leicht erkennen und überprüfen kann. Außerdem wird die Analyse zur Risikobeurteilung verwendet. Dadurch können unkritische Bereiche von weitergehenden Prüfungshandlungen ausgenommen werden. Durch die Fokussierung und das Filtern auffälliger Datensätze kann schließlich der Umfang von Einzelbelegprüfungen deutlich verringert werden.

auditbee übernimmt als Service die Datenaufbereitung und stellt dem Prüfer ein fertig abgestimmtes Dashboard-Modell zur Verfügung, dass der Prüfer mit der BI Software Qlik Sense nutzen kann. Damit baut die Kanzlei Risiken ab, weil Sie weniger von Spezialisten abhängig ist. Zum anderen enthält das auditbee Modell jede Menge menschlichen Sachverstand und Logik in Form von Journal Entry Test Abfragen, Kennzahlen bis hin zu dynamischen Beurteilungen. Dadurch spart sich der Prüfer die Zeit, die entsprechenden Fragen und Analysen selbst mit Excel oder einem anderen Softwarelösungen zu modellieren.

Wirtschaftsprüfung ist Teamarbeitet. Jeder bringt seine individuellen Stärken und Fachwissen ein. Deshalb braucht das Team immer auch jemanden, dessen Stärke in der Analyse liegt, um schnell und effizient Auffälligkeiten zu erkennen und diese durch richtige Fragen und Nachweise angemessen zu würdigen. Jedoch ist der Spezialist Dank auditbee nicht mehr alleine. Das ganze Team hat nun Zugriff auf alle GDPdU Daten aus der Finanzbuchhaltung und auch die Dokumentation erfolgt innerhalb einer Lösung – und das ist auditbee!

Wie Wirtschaftsprüfer mit auditbee die Nadel im Heuhaufen finden – Teil 1/2

ERP, CRM, FiBu – täglich durchlaufen unzählige Geschäftsprozesse die IT-Systeme von Unternehmen. Es entstehen Ströme aus Massendaten, die am Ende in der Finanzbuchhaltung münden und dort automatisch auf Konten erfasst werden.

Mit auditbee können Wirtschaftsprüfer diese Datenströme wirtschaftlich und einfach analysieren. auditbee integriert die Datenanalyse in den gesamten Prüfungsverlauf und macht Schluss mit ausgedruckten Kontenblättern, komplizierten Datenabfragen sowie dem Zufall bei der Fehlersuche.

Wirtschaftsprüfer und die Nadel im Heuhaufen

Die Finanzdaten von Unternehmen sind wichtig für viele Adressaten – Gesellschafter, Banken, Kunden, etc. Deswegen ist es die gesetzliche Aufgabe des Wirtschaftsprüfers, wesentliche Fehler in der Buchhaltung und dem Jahresabschluss aufzudecken. Dazu überprüft er einzelne Sachverhalte mit hohem Fehlerrisiko und Prozesse, bei denen systematische Fehler in Summe von Bedeutung für den Abschluss sein können (IDW PS 261 n.F.).

Die Prüfung gleicht jedoch der Suche nach der Nadel im Heuhaufen!

Fehler sind menschlich und können passieren. Das Problem ist, dass sie im gesamten Datenhaufen gut verborgen sein können – und je größer dieser ist, desto schwieriger wird die Suche. Neben Irrtümern können Fehler auch durch absichtliche Falschdarstellungen und bewusste Täuschungen entstehen. Um solche dolosen Handlungen festzustellen, hat der Prüfer häufig tief im Datenhaufen zu graben, weil sie gut versteckt sind. Deswegen sind auch nach international anerkannten Prüfungsgrundsätzen die Journalbuchungen zu analysieren (ISA 240.32).

Die Suche nach dem Fehler

Noch vor einigen Jahren bestand die Prüfung hauptsächlich darin, eine Vielzahl an bewusst ausgewählten Belegen als Stichprobe in Papier einzusehen und mit den Angaben in der Buchhaltung abzustimmen – analog mit Stift und Textmarker auf ausgedruckten Kontenblättern. Dafür mussten Unmengen Belege kopiert und Kontenblätter ausgedruckt werden. Das hat nicht nur Papier verschwendet, sondern auch sehr viel der begrenzten Zeit gekostet. Zu allen Übels mussten die so entstandenen Prüfungsakten noch Kistenweise zum Mandanten hin- und wieder zurück transportiert werden. Es gab keine digitale Alternative.

Heute haben viele Unternehmen ihre Belege digitalisiert und setzen Dokumentenmanagement-systeme ein. Eine enorme Arbeitserleichterung für den Prüfer, der jetzt alle Belege digital einsehen kann. Weil der Datenhaufen jedoch gleichzeitig immer weiter wächst, entstehen neue Herausforderungen. Die Datenmenge als Grundgesamtheit wirkt sich beispielsweise auf den Umfang einer Stichprobe aus. Um Massendaten aus automatisierten Geschäftsprozessen wirtschaftlich überprüfen zu können, sind daher Datenanalysen unerlässlich.

Mit dem BMF-Schreiben „Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen – GDPdU“ wurde im Jahr 2001 der Grundstein für die Datenanalyse in der Prüfung gelegt. Der Nachfolger „Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff – GoBD“ wurde 2014 veröffentlicht. Mit den BMF-Schreiben hat eine gewisse Normierung der steuerlich relevanten Daten (GDPdU/GoBD-Daten) durch die Finanzverwaltung stattgefunden. Diese lassen sich aus jeder Buchhaltungssoftware extrahieren und umfassen sämtliche Journalbuchungen.

Mit Datenanalysen kann der Prüfer nicht nur das Unternehmen und dessen Entwicklung besser verstehen. Dank der GDPdU/GoBD-Daten können Fehler mit auditbee viel leichter gefunden werden, weil sich der Prüfer jeden Halm im Datenhaufen ganz genau ansehen, Auffälligkeiten erkennen und hinterfragen kann. Mit der Analyse und Risikobeurteilung wird zudem die Belegprüfung deutlich reduziert, weil sich der Prüfer bei der Auswahl auf auffällige und risikobehaftete Daten beschränken kann.

Integration der Datenanalyse in die Prüfung – Spezialisten oder Self-Service

Das Tagesgeschäft des Wirtschaftsprüfers ist sehr vielfältig – Prüfung, Unternehmensbewertung, Steuerberatung. Deshalb erfolgt die Datenanalyse regelmäßig durch Spezialisten. Das sind IT-affine Mitarbeiter innerhalb der Kanzlei, die sich im Rahmen von Projekten selbständig weitergebildet oder eine Qualifikation als CISA bzw. IT Auditor haben.

Der Spezialist überprüft die Journalbuchungen (Journal Entry Tests) mit Excel oder einer Analysesoftware für Prüfer (DATEV Datenanalyse, IDEA, ACL). Oft ist er aber nicht mehr an der weiteren Prüfung beteiligt. Stattdessen führt der Prüfer mit seinen Assistenten als Team vor Ort die Hauptprüfung durch. Dabei werden häufig Konten erneut für die Belegauswahl in Excel gezogen. Das führt nicht nur zu Medienbrüchen, sondern erhöht auch die Wahrscheinlichkeit für Doppelarbeit, Fehler und Missverständnisse.

Neben alten Gewohnheiten und Zeitdruck ist die Analysesoftware oft selbst ein Grund, weshalb die Datenanalyse in der Praxis selten in die Prüfung integriert ist. Schließlich erfordern die Softwarelösungen einiges an IT-Kenntnis in der Einrichtung und Bedienung. Zudem ist die Interpretation von überwiegend in Tabellen dargestellten Daten schwierig und umständlich.

Mit auditbee als vorbereitete Dashboard Lösung auf Basis von Qlik Sense kann jeder im Team seine Daten selbst analysieren. Damit wird die Datenanalyse in die Prüfung integriert und kann ihr volles Potential entfalten.

auditbee als Self-Service BI-Lösung lässt sich so einfach bedienen, dass das Prüfungsteam nicht mehr von einzelnen Spezialisten abhängig ist. Damit aber nicht jeder bei 0 anfängt, werden die Daten bereits vom auditbee Team als Service in die BI-Software Qlik Sense geladen und abgestimmt. Zudem sind bereits verschiedene Dashboards zur Analyse eingerichtet. Der einzelne Anwender kann sich mit auditbee Daten und Kennzahlen ansehen, ohne eine einzige Formel eingeben zu müssen. Die Navigation und das dynamische Filtern der Daten im gesamten Dashboard erfolgt mit der Maus und das nahezu in Echtzeit. Anstatt von Abfragen mit langen Ladezeiten und Duplizierung der Daten können diese sofort im gesamten auditbee Modell nach unterschiedlichen Dimensionen (mehrdimensional) analysiert werden.

Mit auditbee zur strukturierten Belegauswahl

Bei der traditionellen bewussten Auswahl sucht sich der Prüfer Belege nach eigenem Ermessen anhand der Informationen auf dem Kontoblatt aus. Das sind regelmäßig Betrag, Buchungsdatum oder Buchungstext. Diese Methode ist relativ einseitig, eindimensional und vorhersehbar, weil vom Prüfer eher größere Beträge oder auffällige Texte ausgewählt werden. Dadurch kann es sein, dass absichtliche Falschdarstellungen und Irrtümer bei betragsmäßig kleineren Belegen nicht in die Stichprobe einbezogen werden und somit ungeprüft bleiben.

Zufalls- sowie statistische Auswahlverfahren (u.a. Monetary Unit Sampling) können wegen der Schwächen der traditionellen Methode eine Alternative sein. Doch auch sie haben einen relevanten Nachteil. Der Umfang der Stichprobe ist oftmals sehr hoch, um ein hinreichendes Signifikanzniveau (Alpha 0,05) zu erreichen. Ein Grund für den Prüfer, sich möglicherweise doch für die bewusste Auswahl zu entscheiden, um die Zeit für Belegabstimmungen zu verkürzen.

Durch die Verbindung sämtlicher FiBu-Daten und der Darstellung weiterer Dimensionen – Referenz, Beleg Art, Erfassungsdatum, Debitor, etc. – ermöglicht auditbee dem Prüfer eine dritte Methode. Bei der strukturierten Belegauswahl fokussiert sich der Prüfer auf Auffälligkeiten und wählt seine Stichprobe aus einer deutlich kleineren Zahl an Belegen bewusst oder per Zufall aus.

Der Prüfer analysiert nicht alles auf einmal, sondern betrachtet nur solche Daten, die aus Sicht des Themas und der zu prüfenden Frage relevant sind. Beispiel: Es werden nur die Daten im Umsatzbereich betrachtet, die das Merkmal „nicht zeitnah erfasst“ aufweisen. Ausgehend von der Frage kategorisiert der Prüfer die Daten nach der Höhe des Fehlerrisikos (Risikobeurteilung nach IDW PS 261 n.F.). Beispielsweise können automatisierte Buchungen ein geringes Fehlerrisiko aufweisen, Sachbuchungen oder Buchungen bestimmter Mitarbeiter dagegen ein höheres. Nur noch Belege mit höherem Risiko sowie andere Auffälligkeiten ergründet der Prüfer weiter im Detail. Hierzu filtert er die Daten anhand der auffälligen Dimensionen (Erfasser, Debitor, Monat, etc.). Am Ende bleiben nur noch wenige auffällige Datensätze übrig, aus der der Prüfer seine Stichprobe auswählt.

Bezogen auf die Nadel im Heuhaufen zeigen die 3 Methoden folgendes Bild.

Methode 1: Der Prüfer trägt nur die großen Strohalme von der Oberfläche ab, um zu sehen, ob darunter die Nadel verborgen ist (traditionelle Belegauswahl anhand des Kontoblattes).

Methode 2: Der Prüfer greift an verschiedenen Stellen in den Heuhaufen hinein, um per Zufall die Nadel zu finden (statistische Zufallsauswahlverfahren).

Methode 3: Der Prüfer sieht sich den Heuhaufen erst genau an, ob irgendwelche Stellen durchgewühlt aussehen (Auffälligkeiten), hier trägt er den Teil ab (Filtern der auffälligen Daten) und durchsucht systematisch den kleinen Haufen (strukturierte Auswahl).

Dies ist Teil 2/2 des Artikels, lesen Sie hier den zweiten Artikel Wie Wirtschaftsprüfer mit auditbee die Nadel im Heuhaufen finden – Teil 2/2.