Tag Archive for: Data Warehousing

Continuous Integration and Continuous Delivery (CI/CD) for Data Pipelines
Benjamin Aunkofer

CI/CD für Datenpipelines – Ein Game-Changer mit AnalyticsCreator

/in , , , /by

Continuous Integration und Continuous Delivery (CI/CD) für Datenpipelines: Ein Game-Changer mit AnalyticsCreator!

Die Bedeutung effizienter und zuverlässiger Datenpipelines in den Bereichen Data Science und Data Engineering ist enorm. CI/CD, als Teil von DevOps, unterstützt Softwareentwicklungsteams dabei, Codeänderungen häufiger und zuverlässiger bereitzustellen. Dieser Ansatz ermöglicht es Entwicklern, an einem gemeinsamen Code-Repository zu arbeiten, automatisierte Buildprozesse zu nutzen und so einen schnelleren Entwicklungszyklus mit geringerer Fehlerquote zu erreichen.

Einsatz von CI/CD in Datenpipelines

Datenpipelines fördern Konsistenz, reduzieren Fehler und steigern die Effizienz, indem sie Daten in ein nutzbares Format umwandeln. Automatisierung hilft dabei, menschliche Fehler zu vermeiden und ermöglicht es Datenexperten, sich auf das Wesentliche zu konzentrieren: das Gewinnen von Erkenntnissen und die Unterstützung von Unternehmen bei der Entscheidungsfindung.

Die Rolle von AnalyticsCreator

AnalyticsCreator erweist sich als leistungsstarkes Werkzeug zur Steigerung von Effizienz und Zuverlässigkeit in CI/CD-Prozessen. Es bietet vollständige Automatisierung des BI-Stacks und unterstützt ein breites Spektrum an Data Warehouses, analytischen Datenbanken und Frontends.

Hauptmerkmale von AnalyticsCreator:

  • Ganzheitliches Datenmodell: Ermöglicht schnelles Prototyping verschiedener Datenmodelle.
  • Automatisierung: Erstellt SQL-Code, DACPAC-Dateien, SSIS-Pakete, Data Factory-ARM-Vorlagen und XMLA-Dateien.
  • Vielfältige Unterstützung: Kompatibel mit verschiedenen Datenbankmanagementsystemen wie MS SQL Server und Azure Synapse Analytics.
  • Data Lakes: Unterstützt MS Azure Blob Storage.
  • Frontends: Kompatibel mit Tools wie Power BI, Qlik Sense und Tableau.
  • Pipelines/ETL: Unterstützt Technologien wie SQL Server Integration Services und Azure Data Factory.
  • Bereitstellungsoptionen: Bietet verschiedene Methoden zur Bereitstellung und Verwaltung von Datenpipelines.
  • Modellierungsansätze: Unterstützt diverse Modellierungsmethoden, einschließlich Dimensional/Kimball und Data Vault 2.0.

Versionierung: Ermöglicht die Nachverfolgung von Änderungen und die Sicherstellung der Data Governance.

Schlussfolgerung

Die Integration von CI/CD in Datenpipelines, verstärkt durch die Fähigkeiten von AnalyticsCreator, kann die Effizienz und Zuverlässigkeit im Datenmanagement signifikant erhöhen. Dies führt zu schnelleren und verlässlicheren Updates und stellt eine wesentliche Verbesserung im Bereich der Datenwi

Process Mining / Process Analytics
Benjamin Aunkofer

Ist Process Mining in Summe zu teuer?

/in , , , , , , /by

Celonis, Signavio (SAP). UiPath, Microsoft, Software AG, Mehrwerk, process.science und viele weitere Process Mining Tool-Anbieter mehr… der Markt rund um Process Mining ist stark umkämpft. Trotz der hohen Vielfalt an Tools, gilt Process Mining in der Einführung und Durchführung als teuer. Viele Unternehmen verzeichnen zwar erste Erfolge mit dieser Analysemethodik und den dafür geschaffenen Tools, hadern jedoch mit den hohen Kosten für Lizensierung und Betrieb.

Process Mining / Process AnalyticsDabei gibt es viele Hebel für Unternehmen, die Kosten für diese Analysen deutlich zu reduzieren, dabei gesamtheitlicher analysieren zu können und sich von einzelnen Tool-Anbietern unabhängiger zu machen. Denn die Herausforderung beginnt bereits mit denen eigentlichen Zielen von Process Mining für ein Unternehmen, und diese sind oft nicht einmal direkt finanziell messbar.

Process Mining bitte nicht nur auf Prozesskosten reduzieren

Tool-Anbieter werben tendenziell besonders mit der potenziellen Reduktion von Prozesskosten und und mit der Working Capital Optimierung. Bei hohen Lizenzierungskosten für die Tools, insbesondere für die Cloud-Lösungen der Marktführer, ist dies die erfolgversprechendste Marketing-Strategie. Typische Beispiele für die Identifikation von Kostensenkungspotenzialen sind Doppelarbeiten und unnötige Prozessschleifen sowie Wartezeiten in Prozessen. Working Capital- und Cash- Kosten sind in den Standardprozessen Order-to-Cash (z. B. Verspätete Zahlungen) und Procure-to-Pay (z. B. zu späte Zahlungen, nicht realisierte Rabatte) zu finden.

Diese Anwendungsfälle sind jedoch analytisch recht trivial und bereits mit einfacher BI (Business Intelligence) oder dedizierten Analysen ganz ohne Process Mining bereits viel schneller aufzuspüren. Oft bieten bereits ERP-Systeme eine eigene Erkennung hierfür an, die sich mit einfach gestrikter BI leicht erweitern lässt.

Richtige Wirkung, die so eigentlich nur Process Mining mit der visuellen Prozessanalyse erzeugen kann, zeigt sich vor allem bei der qualitativen Verbesserung von Prozessen, denn oft frustrieren eingefahrene Unternehmensprozesse nicht nur Mitarbeiter, Lieferanten und Partner, sondern auch Kunden. Dabei geht es z. B. um die Verbesserung von Prozessen in der Fertigung und Montage, in der Logistik, dem Einkauf, Sales und After Sales. Diese Anwendungszwecke dienen zur zeitlichen Beschleunigung oder Absicherung (Stabilisierung) von Prozessen, und damit zur Erhöhung des Kundennutzens. Jede qualitative Verbesserung wird sich letztendlich auch im quantitativen, finanziellen Maße auswirken, wenn auch nicht so einfach messbar.

Die Absicherung von Prozessen aus der Compliance-Perspektive ist eines der typischen Einsatzgebiete, für die Process Mining prädestiniert ist. Audit Analytics und Betrugserkennung gehören zu den häufigsten Anwendungsgebieten. Das senkt zwar grundsätzlich keine Prozesskosten, ist jedoch in Anbetracht immer komplexerer Prozessketten bittere Notwendigkeit.

Prozess Mining kann ferner auch zur Dokumentation von Geschäftsprozessen genutzt werden, als Vorlage für Sollprozesse. Die Analyse von bestehenden Prozessen kann dann dabei helfen, den aktuellen Zustand eines Prozesses zu dokumentieren und Unternehmen können diese Informationen nutzen, um Prozessdokumentationen zu aktualisieren und zu verbessern. Mit Process Mining können Vor- und Nachher-Vergleiche durchgeführt sowie situative Worst- und Best-Practise herausextrahiert werden. Dies bietet sich insbesondere vor und nach Migrationen von ERP-Systemen an.

Process Mining muss nicht (zu) teuer sein

Bei hohen Kosten für Process Mining ist der Druck einer Organisation sehr hoch, diese Kosten irgendwie mit hohen potenziellen (!) Einsparungen zu rechtfertigen. Die Prozesse mit dem höchsten Kostensenkungsversprechen erhalten dadurch den Vorzug, oft auch dann, obwohl andere Prozesse die nötige Prozesstransparenz eigentlich noch viel nötiger hätten.

Zumindest der Einstieg in Process Mining kann mit den richtigen Tools sehr leichtfüßig und günstig erfolgen, aber auch die Etablierung dieser Analysemethodik im weltweiten Konzern kann mit einigen Stellhebeln erheblich günstiger und (in Anbetracht der hohen Dynamik unter den Tool-Anbietern) nachhaltiger realisiert werden, als wie es von den größeren Anbietern vorgeschlagen wird.

Unabhängiges und Nachhaltiges Data Engineering

Die Arbeit hinter Process Mining kann man sich wie einen Eisberg vorstellen. Die sichtbare Spitze des Eisbergs sind die Reports und Analysen im Process Mining Tool. Das ist der Teil, den die meisten Analysten und sonstigen Benutzer des Tools zu Gesicht bekommen. Der andere Teil des Process Minings ist jedoch noch viel wesentlicher, denn es handelt sich dabei um das Fundament der Analyse: Die Datenmodellierung des Event Logs. Diese Arbeit ist der größere, jedoch unter der Oberfläche verborgene Teil des Eisbergs.

Jedes Process Mining Tool benötigt pro Use Case mindestens ein Event Log. Dabei handelt es sich um ein Prozessprotokoll mit universeller Mindestanforderung: Case, Activity, Timestamp

Diese Event Logs in einem Process Mining Tool zu modellieren und individuell anzupassen, ist langfristig keine gute Idee und erinnert an die Anfänge der Business Intelligence, als BI-Analysten Daten direkt in Tools wie Qlik Sense oder Power BI luden und für sich individuell modellierten.

Wie anfangs erwähnt, haben Unternehmen bei der Einführung von Process Mining die Qual der Wahl. Oft werden langwierige und kostenintensive Auswahlprozesse für die jeweiligen Tools angestoßen, damit die Wahl auf der augenscheinlich richtige Tool fällt.

Eine bessere Idee ist es daher, Event Logs nicht in einzelnen Process Mining Tools aufzubereiten, sondern zentral in einem dafür vorgesehenen Data Warehouse zu erstellen, zu katalogisieren und darüber auch die grundsätzliche Data Governance abzusichern. Die modellierten Daten können dann jedem Process Mining Tool zur Verfügung gestellt werden. Während sich Process Mining Tools über die Jahre stark verändern, bleiben Datenbanktechnologien für Data Warehousing über Jahrzehnte kompatibel und können in ihnen aufbereitete Event Logs allen Tools zur Verfügung stellen. Und übrigens lässt sich mit diesem Ansatz auch sehr gut eine gesamtheitlichere Verknüpfung realisieren und die Perspektive dynamisch verändern, was neuerdings als Object-centric Process Mining beworben wird, mit der richtigen Datenmoedellierung in einem Process Mining Data Warehouse für jedes Tool zu erreichen ist.

Nicht alles um jeden Preis in die Public Cloud

Unter der häufigen Prämisse, dass alle ERP-Rohdaten in eine Cloud geladen werden müssen, entstehen Kosten, die durchaus als überhöht und unnötig angesehen werden können. Daten-Uploads in eine Cloud-Lösung für Process Mining sollten nach Möglichkeit minimal ausfallen und lassen sich durch genaueres Anforderungsmanagement in den meisten Fällen deutlich reduzieren, verbunden mit Einsparungen bei Cloud-Kosten. Idealerweise werden nur fertige Event-Logs bzw. objekt-zentrische Datenmodelle in die Cloud geladen, nicht jedoch die dafür notwendigen Rohdaten.

Für besonders kritische Anwendungsfälle kann es von besonderem Stellenwert sein, einen Hybrid-Cloud-Ansatz anzustreben. Dabei werden besonders kritische Daten in ihrer granularen Form in einer Private Cloud (i.d.R. kundeneigenes Rechenzentrum) gehalten und nur die fertigen Event Logs in die Public Cloud (z. B. Celonis Process Mining) übertragen.

Mit AI ist mehr möglich als oft vermutet

Neben den einfachen Anwendungsfällen, die einige Tool-Anbieter bereits eingebaut haben (z. B. Matching von Zahlungsdaten zur Doppelzahlungserkennung oder die Vorhersage von Prozesszeiten), können mit Machine Learning bzw. Deep Learning auch anspruchsvollere Varianten-Cluster und Anomalien erkannt werden.

Unstrukturierte Daten können dank AI in Process Mining mit einbezogen werden, dazu werden mit Named Entity Recognition (NER, ein Teilgebiet des NLP) Vorgänge und Aktivitäten innerhalb von Dokumenten (z. B. Mails, Jira-Tickets) extrahiert und gemeinsam mit den Meta-Daten (z. B. Zeitstempel aus dem Dokument) in ein strukturiertes Event Log für Process Mining transformiert. Ähnliches lässt sich mit AI für Computer Vision übrigens auch auf Abläufe aus Videoaufnahmen durchführen. Dank AI werden damit noch viel verborgenere Prozesse sichtbar. Diese AI ist in noch keiner Process Mining Software zu finden, kann jedoch bausteinartig dem Process Mining Data Warehouse vorgeschaltet werden.

Fazit

Nicht all zu selten ist Process Mining den anwenden Unternehmen in Summe zu teuer, denn bereits einige Unternehmen sind über die Kosten gestolpert. Andere Unternehmen begrenzen die Kosten mit dem restriktiven Umgang mit Benuter-Lizenzen oder Anwendungsfällen, begrenzen damit jedoch auch den Analyseumfang und schöpfen nicht das volle Potenzial aus. Dies muss jedoch nicht sein, denn Kosten für Data Loads, Cloud-Hosting und Benutzerlizenzen für Process Mining lassen sich deutlich senken, wenn Process Mining als die tatsächliche Analyse-Methode verstanden und nicht auf ein bestimmtes Tool reduziert wird.

Zu Beginn kann es notwendig sein, Process Mining in einer Organisation überhaupt erst an den Start zu bringen und erste Erfolge zu erzielen. Unternehmen, die Process Mining und die damit verbundene Wirkung in Sachen Daten- und Prozesstransparenz, erstmals erlebt haben, werden auf diese Analysemethodik so schnell nicht mehr verzichten wollen. Schnelle erste Erfolge lassen sich mit nahezu jedem Tool erzielen. Nach Pilot-Projekten sollte der konzernweite Rollout jedoch in Sachen Performance, Kosten-Leistungsverhältnis und spätere Unabhängigkeit überdacht werden, damit Process Mining Initiativen langfristig mehr wirken als sie kosten und damit Process Mining auch bedenkenlos und ohne Budget-Engpässe qualitative Faktoren der Unternehmensprozesse verbessern kann.

Mit den richtigen Überlegungen fahren Sie die Kosten für Process Mining runter und den Nutzen hoch.

Benjamin Aunkofer

6 Faktoren, wie Process Mining Projekte zum Erfolg werden

/in , , , , /by

Zuerst wollte ich diesen Artikel mit “6 Gründe, warum Process Mining Projekt scheitern” betiteln, das würde dann aber doch etwas zu negativ klingen. Kein Process Mining Projekt muss scheitern oder überhaupt in Verzögerungen geraten, denn das lässt sich mit etwas Erfahrung und der richtigen Einstellung zum Projekt immer verhindern.

Process Mining - Process Flow ChartNach dutzenden Process Mining Projekten mit unterschiedlichen Rahmenbedingungen gebe ich hier nun sechs handfeste Hinweise, wie Process Mining Projekte generell zum Erfolg werden:

1. Richtige Erwartungshaltung setzen und kommunizieren

Dieser Punkt mag banal klingen, das ist jedoch nicht der Fall. Ich habe schon einige Process Mining Projekte gesehen, die deswegen gescheitert sind, weil dem Vorstand oder anderen Entscheidern gegenüber falsche Versprechungen abgegeben wurden. Tatsächlich werden Process Mining Projekte oft mit ambitionierten Zielen gestartet, wie dem Herabsenken von Prozesskosten um konkrete 10% oder dem Reduzieren der Durchlaufzeit eines bestimmten Prozesses um 20%. Es sei den Entscheidern nicht zu verübeln, dass Budgets gestrichen und Projekte eingestampft werden, wenn diese konkreten Versprechen nicht realisiert werden können.

Dabei können exakt diese Ziele oftmals doch erreicht werden, nur nicht gleich bei den ersten Projektiterationen, denn oft fehlen Datenpunkte, die wichtige Prozessaktivitäten in operativen Prozessketten dokumentieren. Das Event Log kann anfangs – gerade für exotischere Prozesse in weniger verbreiteten IT-Systemen – oft noch nicht sofort vollständig erstellt werden.

Aber eben genau diese Lücken in der Prozessdatenerfassung sind ein “Finding”, denn sie zeigen erst auf, an welchen Stellen es blinde Flecken in der Daten- und Prozesstransparenz noch gibt. Somit ist im Process Mining auch der Weg der datenbasierten Prozesstransparenz ein oder sogar DAS große Ziel.

Konkretes Beispiel: Eine Krankenversicherung wollte die Prozesse der Reha-Bewilligung für ihre Versicherte analysieren. Unter Einsatz eines umfangreichen Process Mining Tools sollten die Prozesse tiefgehend analysiert und unnötige Prozessschleifen identifizieren, aber auch den Prozess abkürzen, indem Ausschlusspunkte frühzeitig im Prozess entdeckt werden. Das war das Versprechen an den Vorstand, der das Budget einfror, auf Grund nicht erreichter Ziele.

In der Tat gab es bei der Rekonstruktion der Prozesse aus den Legacy-Systemen, die über Jahrzehnte von der IT der Krankenkasse selbst entwickelt wurden, viele Lücken in den Daten und somit blinde Flecken in der Prozessen. Die Aufdeckung aber genau dieser Lücken führt dazu, dass diese geschlossen werden können und die vollständige Transparenz über Daten damit erst hergestellt wird. Erst dann, im zweiten Schritt, können die Prozesse ausführlich genug auf Optimierungspotenziale untersucht werden.

Process Mining nicht zu betreiben, weil die Prozesse nicht lückenlos getrackt werden, ist im Grunde unterlassene Hilfeleistung gegenüber des Unternehmens.

2. Process Mining als Methode, nicht als Tool verstehen

Viele Process Mining Projekte drehen sich vor allem um die Auswahl und die Einführung der richtigen Process Mining Tools. Auf das richtige Tool zu setzen, ist natürlich ein wichtiger Aspekt im Process Mining Projekt. Abhängig davon, ob es sich beim Vorhaben der Prozessanalyse um eine einmalige Angelegenheit oder ein tägliches Monitoring von Prozessen handelt, kommen unterschiedliche Tools in die Vorauswahl. Auch ob beispielsweise bereits ein BI-System etabliert ist und ob ein ausgeklügeltes Berechtigungskonzept für die Prozessanalysen notwendig ist, spielen für die Auswahl eine Rolle, sowie viele weitere Faktoren.

Dennoch sollte nicht vergessen werden, dass Process Mining in erster Linie kein Tool, sondern eine Analysemethodik ist, bei der es im ersten Abschnitt um die Rekonstruktion der Prozesse aus operativen IT-Systemen in ein resultierendes Prozessprotokoell (Event Log) geht, im zweiten Schritt um eine (im Kern) Graphenanalyse zur Visualisierung der Prozessflüsse mit weiteren Analyse-/Reporting-Elementen. Wird diese Perspektive auf Process Mining nicht aus den Augen verloren, können Unternehmen viele Kosten sparen, denn es erlaubt die Konzentration auf lösungsorientierte Konzepte.

Konkretes Beispiel: Ein Unternehmen plante die Einführung von Process Mining über einen marktführenden Tool-Anbieter. Nahezu alle Ressourcen wurden für die Tool-Einführung allokiert, das eigentliche Vorhaben schien rein in der Tool-Einführung aufgehen zu müssen, bis Projektanforderungen sogar zu Gunsten des auserwählten Tools angepasst wurden, um es realisieren zu können.
Zudem kann das Unternehmen noch vor der umfangreichen Tool-Einführung, erste Schritte oder Zumindest erste Machbarkeitstests mit einem günstigeren Tool durchführen, oder sogar gänzlich kostenlos z. B. mit PM4Py (Python Package für Process Mining).

Oftmals sind die Tools der Marktführer auf Grund der Preismodelle schädlich für die Durchdringung von Process Mining im Unternehmen, denn nicht alle Abteilungen verfügen über die notwendigen Budgets und gerade experimentelle Projekte finden keinen Sponsor. Umso wichtiger ist es, diese Analysetechnik als Methodik zu verstehen, die auch mit einem Tool-Mix funktionieren kann. Ich kenne mehrere Unternehmen, die aus verschiedenen Gründen nicht ein, nicht zwei, sondern gleich mehrere Tools im Unternehmen im Einsatz haben.

3. Auf Unabhängigkeit und Wiederverwendbarkeit setzen

Wie zuvor bereits erwähnt, kann für ein Unternehmen ein Mix aus mehreren Tools infrage kommen und eigentlich sollte dieser Punkt sich um die richtige Tool-Auswahl drehen. Der Markt für Process Mining Software Tools in einem turbulenten Umfeld, die Tools, Funktionsumfänge und Konditionen ändern sich häufig und sind noch nicht vollends ausgereift. Viele der höherpreisigen Process Mining Tools wollen die Erstellung des Event Logs übernehmen und setzen dabei meistens auf vorgefertigte SQL-Skripte, die in der Plattform (also dem Tool) laufen und dort an kundenindividuelle Prozesse (z. B. durch ERP-Customizing) angepasst werden können.

Wie bereits erwähnt, besteht das Verfahren für Process Mining aus zwei Abschnitten, der erste ist die Erstellung des Event Logs, der zweite die eigentliche Analyse im Process Mining Tool, in welches das Event Log geladen wird. Soll das Tool auch den ersten Abschnitt übernehmen, steckt viel unternehmensindividuelles Prozess-Know-How im Tool, welches nicht für andere Tools verwendet werden kann. Es entsteht eine Abhängigkeit vom Tool, eine Migration zu einem anderen Tool wird schwieriger.

Konkretes Beispiel: Ein Unternehmen starten einen Proof of Concept für die Einführung eines Process Mining Tools, dabei wird ein Budget i.H.v. hundertausenden bereit gestellt, um drei Tools von unterschiedlichen Software-Herstellern gegeneinander antreten zu lassen. Die Tools sollen jeweils eine Gesamtlösung darstellen und Process Mining komplett liefern können, inklusive Event Logs.

Das Unternehmen könnte sich den Proof of Concept zum überwiegenden Teil sparen, wenn der erste Abschnitt des Process Minings – die Erstellung der Event Logs – vom Unternehmen selbst durchgeführt werden würde. Die Tools der Anbieter würden dann nur noch der eigentlichen Analyse der Event Logs dienen, die Anforderungen verringern sich und die Tools werden austauschbarer.

Unternehmen können Event Logs selbst herstellen und in ein Data Warehouse speisen, die dann alle Process Mining Tools mit Prozessdaten versorgen können. Die investierten Aufwände in Process Mining würden somit nachhaltiger (weil länger nutzbar) werden und die Abhängigkeit von bestimmter Software würde sich auf ein Minimum reduzieren, wir riskieren keinen neuen Aufwand für Migration von einem Anbieter zum nächsten. Übrigens können die Event Logs dann auch in andere Tools z. B. für Business Intelligence (BI) geladen und anderweitig analysiert werden.

4. Den richtigen Fokus setzen

Für Process Mining sollte nicht nur im Generellen eine realistische Erwartungshaltung kommuniziert werden, sondern auch im Speziellen, durch Selektion der besten Prozesse für den Start der Process Mining Vorhaben. Auf den ersten Blick sind das sicherlich die Prozesse, die aus Führungssicht als besonders kritisch betrachtet werden, für manche Unternehmen mögen das besondere Prozesse der Logistik sein, der Wareneinkauf bzw. die Materialbereitstellung, bei anderen Unternehmen vielleicht bestimmte Verwaltungs- oder Genehmigungsprozesse. Es sind meistens Prozesse, die entweder eine besondere Kostenbedeutung für das Unternehmen haben oder für die Kundenbindung wichtig sind. Da ist es verständlich, dass erste Projekte sich exakt diesen Prozessen widmen.

Konkretes Beispiel: Ein Unternehmen der Werkzeugmaschinen-Branche plant einen erstmaligen Einsatz von Process Mining. Der für das Unternehmen besonders kritische Prozess ist die Fertigung und Montage von Maschinen, denn hier liegen die größten Potenziale verborgen. Das Vorhaben gerät jedoch schnell ins Stocken, denn die Erhebung der Daten nicht nur aus ERP- und MES-Systemen, sondern auch von Machinen und Arbeitsplätzen erweist sich als zeitaufwändig.

Das Unternehmen startet eine zweite Kampagne zur Untersuchung eines Einkaufsprozesses, das zwar geringere Potenziale bietet, jedoch schneller und reibungsloser durchführbar ist. Das Projekt wird zum Erfolg und motiviert die Geschäftsführung, mehr Aufwände für Process Mining auch für schwieriger zu untersuchende Prozesse freizugeben.

Sofern Process Mining noch nicht im Unternehmen etabliert ist, sollten Sie die “low hanging Fruits” finden, damit Ihre Initiative zu einem nachhaltigen Erfolg für das ganze Unternehmen werden kann, beginnen Sie möglichst nicht gleich mit der größten “Baustelle”.

5. Datenanforderung und Datenrestriktionen frühzeitig klären

Dass der Erfolg Ihrer Process Mining Initiative auch vom zu analysierenden Prozess abhängt und damit auch die Datenverfügbarkeit vorab untersucht worden sein sollte, hatten wir schon erörtert. Aber selbst für gängigere Prozesse verzögern sich Process Mining Vorhaben auf eigentlich vermeidbarer Weise, weil die Anforderung an die Daten nicht vorab festgelegt worden sind. In der Tat ist die Definition der Datenanforderung, also welche Datentabellen mit Filterung auf Spalten und Zeilen für das Event Log benötigt werden, vorab manchmal gar nicht so einfach, besonders bei exotischeren Quellsystemen. Es sollte zumindest jedoch die grobe Anforderung beschrieben werden, unter Nennung der Datenbanken und einer Metabeschreibung, um welche Daten es geht. Auch deswegen, um den Datenschutzbeauftragten und sonstige Genehmiger frühzeitig einbinden zu können. Bei gängigen Quellsystemen und Standardprozessen (z. B. Procure to Pay oder Order to Cash eines SAP ERPs) kann die Anforderung bereits früh auf hohem Detaillevel vorab geschehen.

Konkretes Beispiel: Ein Unternehmen hat gerade sein Process Mining Projekt gestartet, steckt jedoch seit Tagen in der Datenbeschaffung fest. Die IT-Systemintegratoren weigern sich, Daten ohne genaue Anforderung aus den Quellsystemen zu exportieren oder einen API-Zugang bereit zu stellen und die Freigabe des Datenschutzbeauftragten sowie der IT-Sicherheit fehlen.

Neben der Anforderungsdefinition sollte also auch die Kommunikation mit den Administratoren der Quellsysteme frühzeitig erfolgen.

6. Das Big Picture vor Augen haben

Insbesondere wenn Process Mining nicht nur eine einmalige Ad-Hoc Analyse bleiben, sondern unternehmensweit eingeführt werden soll, sollte eine verlässliche, integrative und nachhaltige Architektur überlegt werden. Process Mining ist – wir wiederholen uns – eine Methodik, die mit Business Intelligence, Data Science (Machine Learning) und RPA in Verbindung gebracht werden kann.

Konkretes Beispiel: Eine Fachabteilung eines Unternehmens führte ein Process Mining Tool als eigenständige Lösung ein, um Prozesse hinsichtlich ihrer Automatisierbarkeit zu untersuchen. Dabei werden NLP-Algorithmen aus dem Machine Learning bei der Datenextraktion aus Texten eine Rolle spielen. Das ausgewählte Process Mining Tool wurde auch auf Grund seiner inhouse-Lösung für Machine Learning ausgesucht. In einer benachbarten Abteilung ist bereits ein RPA-Tool im Einsatz und auf der globalen Unternehmensebene ist ein bestimmtes BI-Tool der Standard für Reporting und Datenanalysen.

Statt vieler Einzellösungen, könnte die Fachabteilung das konzernweite BI-Tool mit Process Mining Erweiterung (Plugin zum BI-Tool, z. B. für Qlik Sense oder Power BI erhältlich) nutzen und dabei auch die RPA-Lösung mit dieser verbinden. Ein Data Warehouse für BI ist ebenfalls vorhanden und könnte ggf. zu einem für Process Mining erweitert werden. Für den Einsatz von Machine Learning können Data Scientists die Daten im Process Mining Data Warehouse zum Training verwenden und Prädiktionsergebnisse direkt in dieses zurückspielen.

Achten Sie auf die Gesamtarchitektur. Process Mining kann für sich alleine stehen, es kann jedoch auch sinnvoll sein, eine Datenstrategie zu entwickeln, die das Projekt im Kontext vorhandener Daten-Initiativen betrachtet und einen integrativen Ansatz erlaubt.

Paula Selleng

Data Vault 2.0 – Flexible Datenmodellierung

/in , , , , , /by

Was ist Data Vault 2.0?

Data Vault 2.0 ist ein im Jahr 2000 von Dan Linstedt veröffentlichtes und seitdem immer weiter entwickeltes Modellierungssystem für Enterprise Data Warehouses.

Im Unterschied zum normalisierten Data Warehouse – Definition von Inmon [1] ist ein Data Vault Modell funktionsorientiert über alle Geschäftsbereiche hinweg und nicht themenorientiert (subject-oriented)[2]. Ein und dasselbe Produkt beispielsweise ist mit demselben Business Key sichtbar für Vertrieb, Marketing, Buchhaltung und Produktion.

Data Vault ist eine Kombination aus Sternschema und dritter Normalform[3] mit dem Ziel, Geschäftsprozesse als Datenmodell abzubilden. Dies erfordert eine enge Zusammenarbeit mit den jeweiligen Fachbereichen und ein gutes Verständnis für die Geschäftsvorgänge.

Die Schichten des Data Warehouses:

Data Warehouse mit Data Vault und Data Marts

Data Warehouse mit Data Vault und Data Marts

Die Daten werden zunächst über eine Staging – Area in den Raw Vault geladen.

Bis hierher werden sie nur strukturell verändert, das heißt, von ihrer ursprünglichen Form in die Data Vault Struktur gebracht. Inhaltliche Veränderungen finden erst im Business Vault statt; wo die Geschäftslogiken auf den Daten angewandt werden.

Die Information Marts bilden die Basis für die Reporting-Schicht. Hier müssen nicht unbedingt Tabellen erstellt werden, Views können hier auch ausreichend sein. Hier werden Hubs zu Dimensionen und Links zu Faktentabellen, jeweils angereichert mit Informationen aus den zugehörigen Satelliten.

Die Grundelemente des Data Vault Modells:

Daten werden aus den Quellsystemen in sogenannte Hubs, Links und Satelliten im Raw Vault geladen:

Data Vault 2.0 Schema

Data Vault 2.0 Schema

Hub:

Hub-Tabellen beschreiben ein Geschäftsobjekt, beispielsweise einen Kunden, ein Produkt oder eine Rechnung. Sie enthalten einen Business Key (eine oder mehrere Spalten, die einen Eintrag eindeutig identifizieren), einen Hashkey – eine Verschlüsselung der Business Keys – sowie Datenquelle und Ladezeitstempel.

Link:

Ein Link beschreibt eine Interaktion oder Transaktion zwischen zwei Hubs. Beispielsweise eine Rechnungszeile als Kombination aus Rechnung, Kunde und Produkt. Auch ein Eintrag einer Linktabelle ist über einen Hashkey eindeutig identifizierbar.

Satellit:

Ein Satellit enthält zusätzliche Informationen über einen Hub oder einen Link. Ein Kundensatellit enthält beispielsweise Name und Anschrift des Kunden sowie Hashdiff (Verschlüsselung der Attribute zur eindeutigen Identifikation eines Eintrags) und Ladezeitstempel.

Herausforderungen bei der Modellierung

Die Erstellung des vollständigen Data Vault Modells erfordert nicht nur eine enge Zusammenarbeit mit den Fachbereichen, sondern auch eine gute Planung im Vorfeld. Es stehen oftmals mehrere zulässige Modellierungsoptionen zur Auswahl, aus denen die für das jeweilige Unternehmen am besten passende Option gewählt werden muss.

Es ist zudem wichtig, sich im Vorfeld Gedanken um die Handhabbarkeit des Modells zu machen, da die Zahl der Tabellen leicht explodieren kann und viele eventuell vermeidbare Joins notwendig werden.

Obwohl Data Vault als Konzept schon viele Jahre besteht, sind online nicht viele Informationen frei verfügbar – gerade für komplexere Modellierungs- und Performanceprobleme.

Zusätzliche Elemente:

Über die Kernelemente hinaus sind weitere Tabellen notwendig, um die volle Funktionalität des Data Vault Konzeptes auszuschöpfen:

PIT Tabelle

Point-in-Time Tabellen zeigen einen Snapshot der Daten zu einem bestimmten Zeitpunkt. Sie enthalten die Hashkeys und Hashdiffs der Hubs bzw. Links und deren zugehörigen Satelliten. So kann man schnell den jeweils aktuellsten Satelliteneintrag zu einem Hashkey herausfinden.

Referenztabellen

Zusätzliche, weitgehend feststehende Tabellen, beispielsweise Kalendertabellen.

Effektivitätssatellit

Diese Satelliten verfolgen die Gültigkeit von Satelliteneinträgen und markieren gelöschte Datensätze mit einem Zeitstempel. Sie können in den PIT Tabellen verarbeitet werden, um ungültige Datensätze herauszufiltern.

Bridge Tabelle

Bridge Tabellen sind Teil des Business Vaults und enthalten nur Hub- und Linkhashkeys. Sie ähneln Faktentabellen und dienen dazu, von Endanwender*innen benötigte Schlüsselkombinationen vorzubereiten.

Vorteile und Nachteile von Data Vault 2.0

Vorteile:

  • Da Hubs, Links und Satelliten jeweils unabhängig voneinander sind, können sie schnell parallel geladen werden.
  • Durch die Modularität des Systems können erste Projekte schnell umgesetzt werden.
  • Vollständige Historisierung aller Daten, denn es werden niemals Daten gelöscht.
  • Nachverfolgbarkeit der Daten
  • Handling personenbezogener Daten in speziellen Satelliten
  • Einfache Erweiterung des Datenmodells möglich
  • Zusammenführung von Daten aus unterschiedlichen Quellen grundsätzlich möglich
  • Eine fast vollständige Automatisierung der Raw Vault Ladeprozesse ist möglich, da das Grundkonzept immer gleich ist.

Nachteile:

  • Es sind verhältnismäßig wenige Informationen, Hilfestellungen und Praxisbeispiele online zu finden und das Handbuch von Dan Linstedt ist unübersichtlich gestaltet.
    • Zusammenführung unterschiedlicher Quellsysteme kaum in der verfügbaren Literatur dokumentiert und in der Praxis aufwendig.
  • Hoher Rechercheaufwand im Vorfeld und eine gewisse Anlauf- und Experimentierphase auch was die Toolauswahl angeht sind empfehlenswert.
  • Es wird mit PIT- und Bridge Tabellen und Effektivitätssatelliten noch viel zusätzlicher Overhead geschaffen, der verwaltet werden muss.
  • Business Logiken können die Komplexität des Datemodells stark erhöhen.
  • Eine Automatisierung des Business Vaults ist nur begrenzt möglich.

Praxisbeispiel Raw Vault Bestellung:

Das Design eines Raw Vault Modells funktioniert in mehreren Schritten:

  1. Business Keys identifizieren und Hubs definieren
  2. Verbindungen (Links) zwischen den Hubs identifizieren
  3. Zusätzliche Informationen zu den Hubs in Satelliten hinzufügen

Angenommen, man möchte eine Bestellung inklusive Rechnung und Versand als Data Vault modellieren.

Hubs sind alle Entitäten, die sich mit einer eindeutigen ID – einem Business Key – identifizieren lassen. So erstellt man beispielsweise einen Hub für den Kunden, das Produkt, den Kanal, über den die Bestellung hereinkommt (online / telefonisch), die Bestellung an sich, die dazugehörige Rechnung, eine zu bebuchende Kostenstelle, Zahlungen und Lieferung. Diese Liste ließe sich beliebig ergänzen.

Jeder Eintrag in einem dieser Hubs ist durch einen Schlüssel eindeutig identifizierbar. Die Rechnung durch die Rechnungsnummer, das Produkt durch eine SKU, der Kunde durch die Kundennummer etc.

Eine Zeile einer Bestellung kann nun modelliert werden als ein Link aus Bestellung (im Sinne von Bestellkopf), Kunde, Rechnung, Kanal, Produkt, Lieferung, Kostenstelle und Bestellzeilennummer.

Analog dazu können Rechnung und Lieferung ebenso als Kombination aus mehreren Hubs modelliert werden.

Allen Hubs werden anschließend ein oder mehrere Satelliten zugeordnet, die zusätzliche Informationen zu ihrem jeweiligen Hub enthalten.

Personenbezogene Daten, beispielsweise Namen und Adressen von Kunden, werden in separaten Satelliten gespeichert. Dies ermöglicht einen einfachen Umgang mit der DSGVO.

Data Vault 2.0 Beispiel Bestelldatenmodell

Data Vault 2.0 Beispiel Bestelldatenmodell

Fazit

Data Vault ist ein Modellierungsansatz, der vor allem für Organisationen mit vielen Quellsystemen und sich häufig ändernden Daten sinnvoll ist. Hier lohnt sich der nötige Aufwand für Design und Einrichtung eines Data Vaults und die Benefits in Form von Flexibilität, Historisierung und Nachverfolgbarkeit der Daten kommen wirklich zum Tragen.

Quellen

[1] W. H. Inmon, What is a Data Warehouse?. Volume 1, Number 1, 1995

[2] Dan Linstedt, Super Charge Your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault. CreateSpace Independent Publishing Platform 2011

[3] Vgl. Linstedt 2011

Weiterführende Links und

Blogartikel von Analytics Today

Häufig gestellte Fragen

Einführung in Data Vault von Kent Graziano: pdf

Website von Dan Linstedt mit vielen Informationen und Artikeln

„Building a Scalable Data Warehouse with Data Vault 2.0“ von Dan Linstedt (Amazon Link)

Benjamin Aunkofer

Sechs Eigenschaften einer modernen Business Intelligence

/in , , , , , , , , , , , , /by

Völlig unabhängig von der Branche, in der Sie tätig sind, benötigen Sie Informationssysteme, die Ihre geschäftlichen Daten auswerten, um Ihnen Entscheidungsgrundlagen zu liefern. Diese Systeme werden gemeinläufig als sogenannte Business Intelligence (BI) bezeichnet. Tatsächlich leiden die meisten BI-Systeme an Mängeln, die abstellbar sind. Darüber hinaus kann moderne BI Entscheidungen teilweise automatisieren und umfassende Analysen bei hoher Flexibilität in der Nutzung ermöglichen.

english-flagRead this article in English:
“Six properties of modern Business Intelligence”

Lassen Sie uns die sechs Eigenschaften besprechen, die moderne Business Intelligence auszeichnet, die Berücksichtigungen von technischen Kniffen im Detail bedeuten, jedoch immer im Kontext einer großen Vision für die eigene Unternehmen-BI stehen:

1.      Einheitliche Datenbasis von hoher Qualität (Single Source of Truth)

Sicherlich kennt jeder Geschäftsführer die Situation, dass sich seine Manager nicht einig sind, wie viele Kosten und Umsätze tatsächlich im Detail entstehen und wie die Margen pro Kategorie genau aussehen. Und wenn doch, stehen diese Information oft erst Monate zu spät zur Verfügung.

In jedem Unternehmen sind täglich hunderte oder gar tausende Entscheidungen auf operative Ebene zu treffen, die bei guter Informationslage in der Masse sehr viel fundierter getroffen werden können und somit Umsätze steigern und Kosten sparen. Demgegenüber stehen jedoch viele Quellsysteme aus der unternehmensinternen IT-Systemlandschaft sowie weitere externe Datenquellen. Die Informationsbeschaffung und -konsolidierung nimmt oft ganze Mitarbeitergruppen in Anspruch und bietet viel Raum für menschliche Fehler.

Ein System, das zumindest die relevantesten Daten zur Geschäftssteuerung zur richtigen Zeit in guter Qualität in einer Trusted Data Zone als Single Source of Truth (SPOT) zur Verfügung stellt. SPOT ist das Kernstück moderner Business Intelligence.

Darüber hinaus dürfen auch weitere Daten über die BI verfügbar gemacht werden, die z. B. für qualifizierte Analysen und Data Scientists nützlich sein können. Die besonders vertrauenswürdige Zone ist jedoch für alle Entscheider diejenige, über die sich alle Entscheider unternehmensweit synchronisieren können.

2.      Flexible Nutzung durch unterschiedliche Stakeholder

Auch wenn alle Mitarbeiter unternehmensweit auf zentrale, vertrauenswürdige Daten zugreifen können sollen, schließt das bei einer cleveren Architektur nicht aus, dass sowohl jede Abteilung ihre eigenen Sichten auf diese Daten erhält, als auch, dass sogar jeder einzelne, hierfür qualifizierte Mitarbeiter seine eigene Sicht auf Daten erhalten und sich diese sogar selbst erstellen kann.

Viele BI-Systeme scheitern an der unternehmensweiten Akzeptanz, da bestimmte Abteilungen oder fachlich-definierte Mitarbeitergruppen aus der BI weitgehend ausgeschlossen werden.

Moderne BI-Systeme ermöglichen Sichten und die dafür notwendige Datenintegration für alle Stakeholder im Unternehmen, die auf Informationen angewiesen sind und profitieren gleichermaßen von dem SPOT-Ansatz.

3.      Effiziente Möglichkeiten zur Erweiterung (Time to Market)

Bei den Kernbenutzern eines BI-Systems stellt sich die Unzufriedenheit vor allem dann ein, wenn der Ausbau oder auch die teilweise Neugestaltung des Informationssystems einen langen Atem voraussetzt. Historisch gewachsene, falsch ausgelegte und nicht besonders wandlungsfähige BI-Systeme beschäftigen nicht selten eine ganze Mannschaft an IT-Mitarbeitern und Tickets mit Anfragen zu Änderungswünschen.

Gute BI versteht sich als Service für die Stakeholder mit kurzer Time to Market. Die richtige Ausgestaltung, Auswahl von Software und der Implementierung von Datenflüssen/-modellen sorgt für wesentlich kürzere Entwicklungs- und Implementierungszeiten für Verbesserungen und neue Features.

Des Weiteren ist nicht nur die Technik, sondern auch die Wahl der Organisationsform entscheidend, inklusive der Ausgestaltung der Rollen und Verantwortlichkeiten – von der technischen Systemanbindung über die Datenbereitstellung und -aufbereitung bis zur Analyse und dem Support für die Endbenutzer.

4.      Integrierte Fähigkeiten für Data Science und AI

Business Intelligence und Data Science werden oftmals als getrennt voneinander betrachtet und geführt. Zum einen, weil Data Scientists vielfach nur ungern mit – aus ihrer Sicht – langweiligen Datenmodellen und vorbereiteten Daten arbeiten möchten. Und zum anderen, weil die BI in der Regel bereits als traditionelles System im Unternehmen etabliert ist, trotz der vielen Kinderkrankheiten, die BI noch heute hat.

Data Science, häufig auch als Advanced Analytics bezeichnet, befasst sich mit dem tiefen Eintauchen in Daten über explorative Statistik und Methoden des Data Mining (unüberwachtes maschinelles Lernen) sowie mit Predictive Analytics (überwachtes maschinelles Lernen). Deep Learning ist ein Teilbereich des maschinellen Lernens (Machine Learning) und wird ebenfalls für Data Mining oder Predictvie Analytics angewendet. Bei Machine Learning handelt es sich um einen Teilbereich der Artificial Intelligence (AI).

In der Zukunft werden BI und Data Science bzw. AI weiter zusammenwachsen, denn spätestens nach der Inbetriebnahme fließen die Prädiktionsergebnisse und auch deren Modelle wieder in die Business Intelligence zurück. Vermutlich wird sich die BI zur ABI (Artificial Business Intelligence) weiterentwickeln. Jedoch schon heute setzen viele Unternehmen Data Mining und Predictive Analytics im Unternehmen ein und setzen dabei auf einheitliche oder unterschiedliche Plattformen mit oder ohne Integration zur BI.

Moderne BI-Systeme bieten dabei auch Data Scientists eine Plattform, um auf qualitativ hochwertige sowie auf granularere Rohdaten zugreifen zu können.

5.      Ausreichend hohe Performance

Vermutlich werden die meisten Leser dieser sechs Punkte schon einmal Erfahrung mit langsamer BI gemacht haben. So dauert das Laden eines täglich zu nutzenden Reports in vielen klassischen BI-Systemen mehrere Minuten. Wenn sich das Laden eines Dashboards mit einer kleinen Kaffee-Pause kombinieren lässt, mag das hin und wieder für bestimmte Berichte noch hinnehmbar sein. Spätestens jedoch bei der häufigen Nutzung sind lange Ladezeiten und unzuverlässige Reports nicht mehr hinnehmbar.

Ein Grund für mangelhafte Performance ist die Hardware, die sich unter Einsatz von Cloud-Systemen bereits beinahe linear skalierbar an höhere Datenmengen und mehr Analysekomplexität anpassen lässt. Der Einsatz von Cloud ermöglicht auch die modulartige Trennung von Speicher und Rechenleistung von den Daten und Applikationen und ist damit grundsätzlich zu empfehlen, jedoch nicht für alle Unternehmen unbedingt die richtige Wahl und muss zur Unternehmensphilosophie passen.

Tatsächlich ist die Performance nicht nur von der Hardware abhängig, auch die richtige Auswahl an Software und die richtige Wahl der Gestaltung von Datenmodellen und Datenflüssen spielt eine noch viel entscheidender Rolle. Denn während sich Hardware relativ einfach wechseln oder aufrüsten lässt, ist ein Wechsel der Architektur mit sehr viel mehr Aufwand und BI-Kompetenz verbunden. Dabei zwingen unpassende Datenmodelle oder Datenflüsse ganz sicher auch die neueste Hardware in maximaler Konfiguration in die Knie.

6.      Kosteneffizienter Einsatz und Fazit

Professionelle Cloud-Systeme, die für BI-Systeme eingesetzt werden können, bieten Gesamtkostenrechner an, beispielsweise Microsoft Azure, Amazon Web Services und Google Cloud. Mit diesen Rechnern – unter Einweisung eines erfahrenen BI-Experten – können nicht nur Kosten für die Nutzung von Hardware abgeschätzt, sondern auch Ideen zur Kostenoptimierung kalkuliert werden. Dennoch ist die Cloud immer noch nicht für jedes Unternehmen die richtige Lösung und klassische Kalkulationen für On-Premise-Lösungen sind notwendig und zudem besser planbar als Kosten für die Cloud.

Kosteneffizienz lässt sich übrigens auch mit einer guten Auswahl der passenden Software steigern. Denn proprietäre Lösungen sind an unterschiedliche Lizenzmodelle gebunden und können nur über Anwendungsszenarien miteinander verglichen werden. Davon abgesehen gibt es jedoch auch gute Open Source Lösungen, die weitgehend kostenfrei genutzt werden dürfen und für viele Anwendungsfälle ohne Abstriche einsetzbar sind.

Die Total Cost of Ownership (TCO) gehören zum BI-Management mit dazu und sollten stets im Fokus sein. Falsch wäre es jedoch, die Kosten einer BI nur nach der Kosten für Hardware und Software zu bewerten. Ein wesentlicher Teil der Kosteneffizienz ist komplementär mit den Aspekten für die Performance des BI-Systems, denn suboptimale Architekturen arbeiten verschwenderisch und benötigen mehr und teurere Hardware als sauber abgestimmte Architekturen. Die Herstellung der zentralen Datenbereitstellung in adäquater Qualität kann viele unnötige Prozesse der Datenaufbereitung ersparen und viele flexible Analysemöglichkeiten auch redundante Systeme direkt unnötig machen und somit zu Einsparungen führen.

In jedem Fall ist ein BI für Unternehmen mit vielen operativen Prozessen grundsätzlich immer günstiger als kein BI zu haben. Heutzutage könnte für ein Unternehmen nichts teurer sein, als nur nach Bauchgefühl gesteuert zu werden, denn der Markt tut es nicht und bietet sehr viel Transparenz.

Dennoch sind bestehende BI-Architekturen hin und wieder zu hinterfragen. Bei genauerem Hinsehen mit BI-Expertise ist die Kosteneffizienz und Datentransparenz häufig möglich.

Jurek Dörner

Process Mining Tools – Artikelserie

/in , , , , , , , , , , /by

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 aus: 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
  2. PAFnow
  3. MEHRWERK
  4. Fluxicon Disco
  5. Lana Labs (erscheint demnächst)
  6. Signavio (erscheint demnächst)
  7. Process Gold (erscheint demnächst)
  8. Aris Process Mining der Software AG (erscheint demnächst)
Bob Muglia

Was der BREXIT für die Cloud-Strategie bedeutet

/in , , , , , /by

Datensouveränität wird nach dem Brexit eine der größten Herausforderungen für Unternehmen sein. Geschäftsführer sind sich der Bedeutung dessen bewusst und fürchten die Gefahr eines „Data cliff edge“, wenn die Trennung Großbritanniens von der EU endgültig beschlossene Sache sein wird.

Ohne ein klares Gespür dafür zu haben, welche Vorschriften und Compliance-Anforderungen bald gelten werden, versuchen britische Unternehmen herauszufinden, wie sie ihre Daten bestmöglich schützen, Geschäftsverzögerungen verhindern und kostspielige Fehler vermeiden können. Die Vieldeutigkeit rund um den Brexit wirft mehr Fragen als Antworten auf, darunter: Wo sollten britische Unternehmen ihre Daten speichern? Sollten sie alle ihre Rechenzentren nach Großbritannien verlegen? Wie wirkt sich der Besitz von Rechenzentren auf den Datenschutz aus? Welche Bedrohungen bestehen, wenn nach Abschluss des Brexit Daten innerhalb oder außerhalb des Vereinigten Königreichs gespeichert werden?

Für Führungskräfte sind der Mangel an Antworten und die Angst vor dem Unbekannten frustrierend. In dieser ungewissen Zeit können smarte Geschäftsführer aber den Brexit für ihre Zwecke lenken, indem sie ihn als Chance und nicht als Hindernis für sich nutzen.

Die unsicher regulierte Zukunft

Für Unternehmen mit Sitz in Großbritannien, die Datenspeicherung und private Cloud-Dienste anbieten, ist vor allem der Ort, an dem sich die Daten befinden, von Belang. Die Gewährleistung der Sicherheit und Kontrolle über eigene Daten ist von zentraler Bedeutung. Gleichzeitig ist jedoch auch die Einhaltung unbekannter zukünftiger Vorschriften und Gesetze zum Datenschutz und zum Datentransfer ein Muss.

Grundlage ist die Einhaltung der Datenschutzverordnung (DSGVO) vom 25. Mai 2018, da das Vereinigte Königreich zu diesem Zeitpunkt noch immer Teil der EU war. Nach Angaben des Information Commissioner’s Office (ICO) des Vereinigten Königreichs – einer unabhängigen Behörde, die sich für die Wahrung von Informations- und Datenschutzrechten von Einzelpersonen einsetzt – bestätigte die britische Regierung, dass ein Austritt aus der EU keine Auswirkungen auf die DSGVO haben wird. Was in diesem Jahr, wenn sich Großbritannien und die EU endgültig voneinander trennen, passieren wird, kann man nur vermuten. Die Ratschläge von ICO sind richtungsweisend: „Bereiten Sie sich darauf vor, die Bestimmungen der DSGVO zu erfüllen und voranzukommen.“

Bemerkenswerterweise schreibt die DSGVO nicht vor, wo Unternehmen ihre Daten aufbewahren müssen. Es ist lediglich erforderlich, dass die EU-Organisationen ihre Daten innerhalb der EU speichern und außerhalb der EU unzugänglich machen müssen. Ausnahme: die Daten betreffen eine DSGVO-konforme Organisation. Wie sich dieses Mandat auf das Vereinigte Königreich auswirkt, muss noch gesehen werden. Denn das Vereinigte Königreich war ja zum Zeitpunkt der Ausarbeitung der Verordnung Teil der EU. Es ist unklar, ob das Vereinigte Königreich am Ende mit der DSGVO konform sein wird.

Aus globaler Sicht muss Großbritannien herausfinden, wie der Datenaustausch und der grenzüberschreitende Datenfluss reguliert werden können. Der freie Datenfluss ist wichtig für Unternehmen und Innovation, was bedeutet, dass das Vereinigte Königreich Vereinbarungen, wie die EU sie mit den USA getroffen haben, benötigt. Ein Privacy Shield, das den Austausch personenbezogener Daten zu gewerblichen Zwecken ermöglicht. Ob das Vereinigte Königreich Vereinbarungen wie den Privacy Shield umsetzen kann, oder neue Vereinbarungen mit Ländern wie den USA treffen muss, ist etwas, was nur die Zeit zeigen wird.

Wo sind die Daten?

Rechenzentren können heute durch freien Datenfluss, sowohl im Vereinigten Königreich als auch in der EU betrieben werden. Das Vereinigte Königreich unterliegt gleichem Schutz und gleichen Vorschriften wie die EU. Viele Spekulationen beinhalten allerdings, dass in naher Zukunft britische Kunden von einem in Großbritannien ansässigen Rechenzentrum bedient werden müssen, ebenso wie europäische Kunden ein EU-Rechenzentrum benötigen. Es gibt keine Garantien. Unklar ist auch, ob diese Situation die Anbieter von Rechenzentren dazu veranlassen wird, den Umzug aus Großbritannien in Betracht zu ziehen, um sich stärker auf den Kontinent zu konzentrieren, oder ob sie sich an beiden Standorten gleichzeitig niederlassen werden. Das Wahrscheinlichste: Die Anbieter tendieren zu letzterem, wie auch Amazon Web Services (AWS). Selbst nach dem Brexit-Votum hielt Amazon an seinem Wort fest und eröffnete Ende letzten Jahres sein erstes AWS-Rechenzentrum in London. Dies unterstreicht sowohl sein Engagement für Großbritannien als auch das unternehmerische Engagement.

Aus dem Brexit eine Geschäftsmöglichkeit machen

Die Automatisierung des IT-Betriebs und die Einführung einer Cloud-Strategie könnten die ersten Schritte sein, um die unbeantworteten Fragen des Brexit zu lösen und daraus einen Vorteil zu machen. Es ist an der Zeit, die Vorteile dessen zu erkennen, teure Hardware und Software von Unternehmen vor Ort durch den Umstieg auf die öffentliche Cloud zu ersetzen. Dies ist nicht nur die kostengünstigere Option. Cloud-Anbieter wie AWS, Microsoft Azure und Google Cloud Platform (GCP) ersparen in diesem politischen Umfeld sogar Unternehmen die Verwaltung und Wartung von Rechenzentren. Einige Unternehmen sind möglicherweise besorgt über die steigenden Raten von Public-Cloud-Anbietern, ihre Preisanpassungen scheinen jedoch an den relativen Wertverlust des Sterlings gebunden zu sein. Selbst bei geringen Erhöhungen sind die Preise einiger Anbieter, wie AWS, noch immer deutlich niedriger als die Kosten, die mit dem Betrieb von Rechenzentren und privaten Clouds vor Ort verbunden sind, insbesondere wenn Wartungskosten einbezogen werden. Wenn man diesen Gedanken noch einen Schritt weiterführt, wie kann der Brexit als eine Chance für Unternehmen betrachtet werden?Organisationen sammeln alle Arten von Daten. Aber nur eine Handvoll von ihnen verwendet effektive Datenanalysen, die Geschäftsentscheidungen unterstützen. Nur wenige Unternehmen tun mehr, als ihre Daten zu speichern, da ihnen die Tools und Ressourcen fehlen, um nahtlos auf ihre Daten zuzugreifen, oder weil Abfragen teuer sind. Ohne ein für die Cloud konstruiertes Data Warehouse ist dieser Prozess bestenfalls eine Herausforderung, und der wahre Wert der Daten geht dabei verloren. Ironischerweise bietet der Brexit die Möglichkeit, dies zu ändern, da Unternehmen ihre IT-Abläufe neu bewerten und alternative, kostengünstigere Methoden zum Speichern von Daten suchen müssen. Durch den Wechsel zu einer öffentlichen Cloud und die Nutzung eines Data Warehouses für die Cloud können Unternehmen Beschränkungen und Einschränkungen ihrer Daten aufheben und diese für die Entscheidungsfindung zugänglich machen.

Der Brexit dient also als Katalysator einer datengesteuerten Organisation, die Daten verwendet, anstatt sie für schlechte Zeiten zu speichern. Am Ende scheint die Prognose der Verhandlungen in Brüssel doch eine ziemlich stürmische zu sein.

Thomas Scholz

DS-GVO: Wie das moderne Data-Warehouse Unternehmen entlastet

/in , , , , /by

Artikel des Blog-Sponsors: Snowflake

Viele Aktivitäten, die zur Einhaltung der DS-GVO-Anforderungen beitragen, liegen in den Händen der Unternehmen selbst. Deren IT-Anbieter sollten dazu beitragen, die Compliance-Anforderungen dieser Unternehmen zu erfüllen. Die SaaS-Anbieter eines Unternehmens sollten zumindest die IT-Sicherheitsanforderungen erfüllen, die sich vollständig in ihrem Bereich befinden und sich auf die Geschäfts- und Datensicherheit ihrer Kunden auswirken.

Snowflake wurde von Grund auf so gestaltet, dass die Einhaltung der DS-GVO erleichtert wird – und von Beginn darauf ausgelegt, enorme Mengen strukturierter und semistrukturierter Daten mit der Leichtigkeit von Standard-SQL zu verarbeiten. Die Zugänglichkeit und Einfachheit von SQL gibt Organisationen die Flexibilität, alle unter der DS-GVO erforderlichen Aktualisierungen, Änderungen oder Löschungen nahtlos vorzunehmen. Snowflakes Unterstützung für semistrukturierte Daten kann die Anpassung an neue Felder und andere Änderungen der Datensätze erleichtern. Darüber hinaus war die Sicherheit von Anfang an von grundlegender Bedeutung für Architektur, Implementierung und Betrieb von Snowflakes Data-Warehouse-as-a-Service.

Ein Grundprinzip der DS-GVO

Ein wichtiger Faktor für die Einhaltung der DS-GVO ist, zu verstehen, welche Daten eine Organisation besitzt und auf wen sie sich beziehen. Diese Anforderung macht es nötig, dass Daten strukturiert, organisiert und einfach zu suchen sind.

Die relationale SQL-Datenbankarchitektur von Snowflake bietet eine erheblich vereinfachte Struktur und Organisation, was sicherstellt, dass jeder Datensatz einen eindeutigen und leicht identifizierbaren Speicherort innerhalb der Datenbank besitzt. Snowflake-Kunden können auch relationalen Speicher mit dem Variant-Spaltentyp von Snowflake für semistrukturierte Daten kombinieren. Dieser Ansatz erweitert die Einfachheit des relationalen Formats auf die Schema-Flexibilität semistrukturierter Daten.

Snowflake ist noch leistungsfähiger durch seine Fähigkeit, massive Nebenläufigkeit zu unterstützen. Bei größeren Organisationen können Dutzende oder sogar Hunderte nebenläufiger Datenänderungen, -abfragen und -suchvorgänge zu einem bestimmten Zeitpunkt auftreten. Herkömmliche Data-Warehouses können nicht zu einem bestimmten Zeitpunkt über einen einzelnen Rechen-Cluster hinaus skaliert werden, was zu langen Warteschlangen und verzögerter Compliance führt. Snowflakes Multi-Cluster-Architektur für gemeinsam genutzte Daten löst dieses Problem, indem sie so viele einzigartige Rechen-Cluster bereitstellen kann, wie für einen beliebigen Zweck nötig sind, was zu einer effizienteren Workload-Isolierung und höherem Abfragedurchsatz führt. Jeder Mitarbeiter kann sehr große Datenmengen mit so vielen nebenläufigen Benutzern oder Operationen wie nötig speichern, organisieren, ändern, suchen und abfragen.

Rechte von Personen, deren Daten verarbeitet werden („Datensubjekte“)

Organisationen, die von der DS-GVO betroffen sind, müssen sicherstellen, dass sie Anfragen betroffener Personen nachkommen können. Einzelpersonen haben jetzt erheblich erweiterte Rechte, um zu erfahren, welche Art von Daten eine Organisation über sie besitzt, und das Recht, den Zugriff und/oder die Korrektur ihrer Daten anzufordern, die Daten zu löschen und/oder die Daten an einen neuen Provider zu übertragen. Bei der Bereitstellung dieser Dienste müssen Organisationen ziemlich schnell reagieren, in der Regel innerhalb von 30 Tagen. Daher müssen sie ihre Geschäftssysteme und ihr Data-Warehouse schnell durchsuchen können, um alle personenbezogenen Daten zu finden, die mit einer Person in Verbindung stehen, und entsprechende Maßnahmen ergreifen.

Organisationen können in großem Umfang von der Speicherung aller Daten in einem Data-Warehouse-as-a-Service mit vollen DML- und SQL-Fähigkeiten profitieren. Dies erleichtert das (mühevolle) Durchsuchen getrennter Geschäftssysteme und Datenspeicher, um die relevanten Daten zu finden. Und das wiederum hilft sicherzustellen, dass einzelne Datensätze durchsucht, gelöscht, eingeschränkt, aktualisiert, aufgeteilt und auf andere Weise manipuliert werden können, um sie an entsprechende Anfragen betroffener Personen anzupassen. Außerdem können Daten so verschoben werden, dass sie der Anforderung einer Anfrage zum „Recht auf Datenübertragbarkeit“ entsprechen. Von Anfang an wurde Snowflake mit ANSI-Standard-SQL und vollständiger DML-Unterstützung entwickelt, um sicherzustellen, dass diese Arten von Operationen möglich sind.

Sicherheit

Leider erfordern es viele herkömmliche Data-Warehouses, dass sich Unternehmen selbst um die IT-Sicherheit kümmern und diese mit anderen Services außerhalb des Kernangebots kombiniert wird. Außerdem bieten sie manchmal noch nicht einmal standardmäßige Verschlüsselung.

Als Data-Warehouse, das speziell für die Cloud entwickelt wurde und das Sicherheit als zentrales Element bietet, umfasst Snowflake unter anderem folgende integrierte Schutzfunktionen:

  • Minimaler Betriebsaufwand: Weniger Komplexität durch automatische Performance, Sicherheit und Hochverfügbarkeit, sodass die Infrastruktur nicht optimiert werden muss und kein Tuning nötig ist.
  • Durchgängige Verschlüsselung: Automatische Verschlüsselung aller Daten jederzeit (in ruhendem und bewegtem Zustand).
  • Umfassender Schutz: Zu den Sicherheitsfunktionen zählen Multi-Faktor-Authentifizierung, rollenbasierte Zugriffskontrolle, IP-Adressen-Whitelisting, zentralisierte Authentifizierung und jährliche Neuverschlüsselung verschlüsselter Daten.
  • Tri-Secret Secure: Kundenkontrolle und Datenschutz durch die Kombination aus einem vom Kunden, einem von Snowflake bereitgestellten Verschlüsselungsschlüssel und Benutzerzugangsdaten.
  • Unterstützung für AWS Private Link: Kunden können Daten zwischen ihrem virtuellen privaten Netzwerk und Snowflake übertragen, ohne über das Internet gehen zu müssen. Dadurch ist die Konnektivität zwischen den Netzwerken sicher und einfacher zu verwalten.
  • Stärkere unternehmensinterne Datenabgrenzung dank Snowflake Data Sharing: Organisationen können die Datenfreigabefunktionen von Snowflake nutzen, um nicht personenbezogene Daten mit anderen Abteilungen zu teilen, die keinen Zugriff benötigen – indem sie strengere Sicherheits- und DS-GVO-Kontrollen durchsetzen.
  • Private Umgebung: Unternehmen können eine dedizierte, verwaltete Snowflake- Instanz in einer separaten AWS Virtual Private Cloud (VPC) abrufen.

Rechenschaftspflicht

Was die Komplexität weiter erhöht: Organisationen müssen auch sicherstellen, dass sie und die Organisationen und Tools, mit denen sie arbeiten, Compliance nachweisen können. Snowflake prüft und verfeinert seine IT-Sicherheitspraxis regelmäßig mit peniblen Penetrationstests. Snowflakes Data-Warehouse-as-a-Service ist zertifiziert nach SOC 2 Type II, ist PCI-DSS-konform und unterstützt HIPAA-Compliance. Um Anfragen von Personen, deren Daten verarbeitet werden („Datensubjekte“), zu entsprechen, können Kunden genutzte Daten überprüfen.

Zusätzlich zu diesen Standardfunktionen und -validierungen schützt Snowflake seine Kunden auch durch den Datenschutznachtrag („Data Protection Addendum“), der genau auf die Anforderungen der DS-GVO abgestimmt ist. Snowflake hält sich außerdem an penibel vertraglich festgelegte Sicherheitsverpflichtungen („contractual security commitments“), um effizientere Transaktionen und eine vereinfachte Sorgfaltspflicht zu ermöglichen.

Fazit

Im Rahmen der Europäischen Datenschutz-Grundverordnung müssen Unternehmen technische Maßnahmen ergreifen, mit deren Hilfe sie den Anforderungen ihrer Kunden in Bezug auf Datenschutz und Schutz der Privatsphäre gerecht werden können. Snowflake bietet hier nicht nur den Vorteil, alle wichtigen Kundendaten an einem einzigen Ort zu speichern, sondern ermöglicht auch das schnelle Auffinden und Abrufen dieser Daten, sodass Unternehmen im Bedarfsfall schnell aktiv werden können.

Dr. Dietrich Wettschereck

Kontrolle und Steuerung von Spark Applikationen über REST

/in , , /by

Apache Spark erfreut sich zunehmender Beliebtheit in der Data Science Szene da es in Geschwindigkeit und Funktionalität eine immense Verbesserung bzw. Erweiterung des reinen Hadoop MapReduce Programmiermodells ist. Jedoch bleibt Spark ebenso wie Hadoop eine Technologie für Experten. Es erfordert zumindest Kenntnisse von Unix-Skripten und muss über die Command-Line gesteuert werden. Die vorhandenen Weboberflächen bieten nur sehr rudimentäre Einblicke in den Status von Spark Applikationen:

spark basic ui

Der Spark JobServer ist ein Open-Source Projekt, das eine REST-Schnittstelle (Representational State Transfer) für Spark anbietet. (In diesem YouTube Video wird anschaulich erläutert, was ein REST API ist und wozu es verwendet werden kann.) Vereinfacht gesagt, ermöglicht es der JobServer, Spark über diese REST-Schnittstelle als Webservice zu nutzen. Es ist möglich, über den JobServer Spark Kontexte und Applikationen (Jobs) zu managen und Kontexte über verschiedene Aufrufe der REST-Schnittstelle hinweg wiederzuverwenden. Jar Files mit Job Implementierungen können vorab über die gleiche Schnittstelle installiert werden, so dass es z.B. möglich ist, auch sehr feingranulare Jobs über die Schnittstelle zu steuern (vollständige Liste der Features).

Der Spark JobServer ist bereits bei verschiedenen Organisationen (u.a. Netflix, Zed Worldwide, KNIME, Azavea und Maana) im Einsatz. Diese Nutzer des JobServers verwenden ihn meist versteckt „unter der Haube“, um so ihre jeweiligen Werkzeuge Big-Data tauglich zu machen. So nutzt KNIME ab dem nächsten Release (Oktober 2015) den JobServer. Anwendern können dann Spark Jobs über eine grafische Oberfläche bequem von ihrem lokalen Rechner aus starten, monitoren und stoppen. In der folgenden Abbildung sehen Sie, wie Trainingsdaten auf den Server hochgeladen werden, um daraus verschiedene Machine Learning Modelle zu erstellen. Diese Modelle können dann auf Testdaten angewandt werden, die z.B. aus einer HIVE-Tabelle nach Spark importiert werden:

spark knime hive jobs

Jeder der dargestellten Knoten mit der Überschrift „Spark ***“, wie z.B. „Spark Decision Tree“, ist ein Spark Job im Sinne des JobServers. Weitere Beispiele für Spark Jobs sind verschiedene Vorverarbeitungsaufgaben wie das Sampling einer Tabelle oder ein Join über mehrere Tabellen.

Spark kann über den JobServer im Standalone-, Mesos- oder im Yarn-Client-Modus angesteuert werden. Eine sehr hilfreiche Erweiterung der eigentlichen Spark-Funktionalität bietet der JobServer über die sogenannten „Named RDDs“ an. Ein Resilient Distributed Dataset (RDD) ist im Prinzip ein Datensatz bzw. eine Tabelle in Spark. „Named RDDs“ erlauben die Weiterverwendung von RDDs über einzelne Jobs hinweg. So kann man Jobs modularer aufbauen und leichter Zwischenergebnisse inspizieren.

Ich kann aus eigener Erfahrung sagen, dass der JobServer die geeignete Middleware zwischen einer benutzerfreundlichen Oberfläche und Spark ist. Die Open-Source Community ist hier sehr aktiv und der JobServer lässt sich bei Bedarf gut erweitern.