CCM (Teil 2) - 5 Dinge, die Sie wissen sollten - und 2 Dinge, die Sie besser nicht vergessen - beim Aufbau einer CCM Datenanalyseumgebung
Dieser Blogbeitrag ist der zweite aus einer mehrteiligen Serie, die betitelt ist mit „5 Dinge, die Sie wissen sollten - und 2 Dinge, die Sie besser nicht vergessen - beim Aufbau einer CCM Datenanalyseumgebung“. Es geht um Datenanalyse-Projekte im Allgemeinen, mit einem Fokus auf der Einführung komplexerer Lösungen, wie etwa einem CCM (Continuous Controls Monitoring) System.
Dieser Artikel besteht aus mehreren Teilen. Die ersten fünf Teile beschreiben Punkte, mit denen man im Zusammenhang mit Datenanalyseprojekten vertraut sein muss:
- Wissen, was man wissen möchte (Analytische Fragestellungen auflisten)
- Wissen, mit welchen Systemen man es zu tun hat? (Datenquelle(n) identifizieren)
- Wissen, wie die Daten strukturiert sind (Datenstruktur erarbeiten)
- Wissen, was die Analysetools können (Technische Möglichkeiten und Grenzen verstehen.
- Wissen, wer die “Internen Kunden” sind (Ergebnisempfänger, Umfang und Format festlegen)
Die Teile sechs und sieben beinhalten zwei Aspekte, die zwar bestimmt bekannt, aber so wichtig sind, dass wir sie hier nochmal ansprechen wollen:
- Es wird Geld kosten (Stichwort „Budget“)
- Man braucht jemanden, der dies alles umsetzen kann (Stichwort „Personelle Ressourcen“)
Der erste Artikel ist bereits erschienen (alle bereits veröffentlichten Teile sind oben verlinkt, so dass Sie jederzeit auch die Historie nachlesen können). Dies ist nun der zweite Teil „Wissen, mit welchen Systemen man es zu tun hat“:
Fünf Dinge, die Sie wissen sollten, Fortsetzung (2/5)
Wir fahren fort mit dem zweiten der fünf Punkte, die ich persönlich als „essentiell“ ansehe. Im letzten Teil wurde betont, dass Sie erst einmal „Wissen sollten, was Sie wissen möchten“, und eine Fragestellung detailliert beschrieben. Schritt eins war also, sich über ein klares Verständnis der Geschäftsprozesse möglichst detaillierte Fragestellungen zu erarbeiten, die mittels Datenanalyse auch wirklich konkret beantwortet werden können. 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.
Nun geht es darum, wie diese Fragen konkret beantwortet werden können.
Aspekt 2: Wissen, mit welchen Systemen man es zu tun hat
Wissen, mit welchen Systemen man es zu tun hat An dieser Stelle müssen wir uns etwas technischeren Aspekten zuwenden, und uns detaillierter mit IT und IT Infrastrukturen beschäftigen. Bevor man überhaupt den Versuch starten kann, Datenanalyse im Unternehmen zu etablieren, muss man die Frage stellen, ob die Daten überhaupt „im System“ sind, und falls ja, in welchem.
Wenn zum Beispiel der Freigabeprozess von Bestellungen mittels digitaler Datenanalyse analysiert werden soll, und Sie stellen fest, dass diese Freigaben durch eine Unterschrift des Managers auf den ausgedruckten Bestellanforderungen erfolgen, die in einem Aktenordner abgeheftet werden – nun, dann ist zu vermuten, dass Datenanalyse hier nicht der richtige Ansatz sein könnte. Offensichtlich bedarf es digitaler Daten, bestenfalls in strukturierter Form und auf eine Art und Weise gespeichert, so dass wir auch darauf zugreifen können.
Bezugnehmend auf unsere Fragestellung “Zahlungen in kritische Länder” zu identifizieren, gehen wir für unseren Artikel davon aus, dass die Daten sich *trommelwirbel* IM SYSTEM befinden. Zum Glück, könnte man meinen, sind die Daten IM SYSTEM. Aber von welchem System sprechen wir hier eigentlich? Nehmen Sie zum Beispiel SAP®. Man kann es als ERP (Enterprise Resource Planning) System beschreiben, in dem sich der Materialstamm, Kunden- und Lieferantendaten, Einkaufs- und Vertriebsbelege, Buchhaltung und Controlling Daten etc. zu finden sind. Als andere Beispiele wären Microsoft Dynamics AX® oder NAV (ehemals Navision) oder Oracle Finances® zu nennen. Geschäftsprozesse von Unternehmen erzeugen Tag für Tag Massen an Daten (Massendaten, Big Data), und diese Daten (– oder der überwiegende Großteil davon) wird durch solche Systeme erzeugt und in Ihnen gespeichert.
Bild 1 - Schichtenarchitektur
Bild 1 zeigt, dass „unter“ dem Benutzerinterface und der Anwendungslogik die Datenbank liegt, in der die Daten gespeichert werden. Wenn ein Benutzer Daten erfasst (zum Beispiel eine Bestellung),dann erfolgt dies in der Regel über das Benutzerinterface (auch GUI, Graphical User Interface oder Front end) genannt. Die Eingabe werden durch die Anwendungslogik („Mittelschicht“ oder „Middle tear“) weiter verarbeitet, zum Beispiel werden die Zahlungsbedingungen berechnet, Währungsumrechnungen vorgenommen, etc. Alle eingegebenen und ggf. auch berechneten Daten werden schließlich in der Datenbank (manchmal auch „Back end“ bezeichnet), abgespeichert.
Für Datenanalyse-Projekte, die auf diesen Daten basieren, ist das ein zentraler Punkt.
Wenn beispielsweise Daten der Finanzbuchhaltung analysiert werden sollen, welches Softwaresystem benutzt Ihre Firma für die Buchhaltung? Ist es SAP®, Oracle® oder ein anderes System?
Im Kontext unseres Beispiels „Zahlungen in kritische Länder“ brauchen wir Zugriff auf das System, auf dem die Zahlungstransaktionen abgewickelt werden – wir gehen hier davon aus, dass es sich um ein SAP® System handelt, etwa SAP® ERP ECC 6.0. Dies ist möglicherweise allerdings erst ein Teil des Puzzles, das zu lösen ist. Manche Unternehmen haben ein SAP® System implementiert, bei anderen sind es zwei, bei wieder anderen könnten es 200 sein. Gehen wir an dieser Stelle einmal von acht Stück aus – es stellt sich dann die Frage, ob auf jedem dieser Systeme das Buchhaltungsmodul genutzt wird?
Bild 2 - Wo liegen die Daten, die wir brauchen?
Die Fragen sind also grob gesagt “Welche Daten sind wo zu finden?” beziehungsweise “Welche Geschäftsprozesse sind auf welchen „Systemen“ abgebildet?“:
- Repräsentiert jedes der acht Systeme eine Region (etwa Westeuropa, Osteuropa, Nordamerika, Südamerika, Afrika, Naher Osten, Asien, APAC, EMEA, NAFTA, etc.)
- Oder sind die Geschäftsprozesse funktional über die verschiedenen Systeme verteilt, etwa Vertrieb auf System 1, Einkauf auf System 2, Buchhaltung auf System 3, und so fort?
Bild 3 - Funktionale Aufteilung der Systeme
Für unser Fallbeispiel gehen wir von Letzterem aus: Wir haben es mit einem einzigen SAP® System zu tun, auf dem die Finanzbuchhaltung für alle Buchungskreise weltweit durchgeführt wird. In obigem Bild ist es mit „SY2“ bezeichnet.
Bild 4 - Wo befinden sich die Daten, die wir brauchen? Auf System “SY2”!
Diese Erkenntnis ermöglicht uns, das richtige System zu identifizieren für unsere analytische Fragestellung. Indem wir wissen, wo sich die Daten befinden, kann auch der Datenzugriff erarbeitet werden. In der Regel bedarf es eines Benutzers mit entsprechenden Benutzerrechten, um auf die Daten lesend zuzugreifen (was, wie wir später sehen werden, auch im Zuge von Datenextraktionslösungen von großer Bedeutung sein wird).
Weitere Fragestellungen in diesem Zusammenhang können sein:
- Wer ist der Dateneigner (Data owner)?
- Wer ist aus technischer Sicht für das System zuständig, die interne IT oder ein externer Dienstleister?
- Wie läuft der Prozess, Datenzugriff für dieses System, also ein Benutzerkonto mit entsprechenden Rechten, zu beantragen?
- Welche (in unserem Beispiel) SAP® Version ist konkret implementiert, handelt es sich zum Beispiel um SAP® R/3™ 4.5, mySAP® ERP oder die aktuellste SAP® ERP ECC 6.0 Version?
Wenn wir unsere “5 Punkte” als Art Checkliste zu Grunde legen, haben wir damit die ersten beiden Punkte erfolgreich klären können:
Bild 5 - Die ersten beiden Punkte sind erfolgreich abgedeckt
Wir wissen, was wir wissen möchten, und haben das relevante System, auf dem die Daten zu finden sind, identifiziert. In dem Zusammenhang konnten auch die Hintergrundinformationen gesammelt werden, wer für Daten und Zugriffsberechtigungen verantwortlich ist. Um wirklich eine CCM Umgebung aufbauen zu können, reicht es jedoch nicht aus, das System zu identifizieren. In unserem Fall müssen wir die Information bezüglich der Geschäftspartner sowie die Zahlungstransaktionen für die Analyse heranziehen. Hier wird es noch einmal eine Spur technischer, denn nun müssen wir uns über Daten und Datenstrukturen unterhalten. Dies werden wir im dritten Teil unserer Serie besprechen – bleiben Sie also dran!
Ich hoffe, der zweite Teil unserer Serie „Start eines CCM-Projekts“ hat Ihnen gefallen! Für Fragen oder Kommentare können Sie sich gerne unter info@dab-gmbh.de an uns wenden.
Um den Autor zu kontaktieren, bieten sich auch LinkedIn oder XING an (möglicherweise müssen Sie sich erst einloggen in das entsprechende Social Network, bevor Sie die folgenden Links nutzen können):
LinkedIn: http://de.linkedin.com/pub/stefan-wenig/54/1b8/b30