Von BI zu PI: Der nächste Schritt auf dem Weg zu datengetriebenen Entscheidungen

„Alles ist stetig und fortlaufend im Wandel.“ „Das Tempo der Veränderungen nimmt zu.“ „Die Welt wird immer komplexer und Unternehmen müssen Schritt halten.“ Unternehmen jeder Art und Größe haben diese Sätze schon oft gehört – vielleicht zu oft! Und dennoch ist es für den Erfolg eines Unternehmens von entscheidender Bedeutung, sich den Veränderungen anzupassen.


Read this article in English: 
“From BI to PI: The Next Step in the Evolution of Data-Driven Decisions”


Sie müssen die zugrunde liegenden organisatorischen Bausteine verstehen, um sicherzustellen, dass die von Ihnen getroffenen Entscheidungen sich auch in die richtige Richtung entwickeln. Es geht sozusagen um die DNA Ihres Unternehmens: die Geschäftsprozesse, auf denen Ihre Arbeitsweise basiert, und die alles zu einer harmonischen Einheit miteinander verbinden. Zu verstehen, wie diese Prozesse verlaufen und an welcher Stelle es Verbesserungsmöglichkeiten gibt, kann den Unterschied zwischen Erfolg und Misserfolg ausmachen.

Unternehmen, die ihren Fokus auf Wachstum gesetzt haben, haben dies bereits erkannt. In der Vergangenheit wurde Business Intelligence als die Lösung für diese Herausforderung betrachtet. In jüngerer Zeit sehen sich zukunftsorientierte Unternehmen damit konfrontiert, Lösungen zu überwachen, die mit dem heutigen Tempo der Veränderungen Schritt halten können. Gleichzeitig erkennen diese Unternehmen, dass die zunehmende Komplexität der Geschäftsprozesse dazu führt, dass herkömmliche Methoden nicht mehr ausreichen.

Anpassung an ein sich änderndes Umfeld? Die Herausforderungen von BI

Business Intelligence ist nicht notwendigerweise überholt oder unnötig. In einer schnelllebigen und sich ständig verändernden Welt stehen die BI-Tools und -Lösungen jedoch vor einer Reihe von Herausforderungen. Hierzu können zählen:

  • Hohe Datenlatenz – Die Datenlatenz gibt an, wie lange ein Benutzer benötigt, um Daten beispielsweise über ein Business-Intelligence-Dashboard abzurufen. In vielen Fällen kann dies mehr als 24 Stunden dauern. Ein geschäftskritischer Zeitraum, da Unternehmen Geschäftschancen für sich nutzen möchten, die möglicherweise ein begrenztes Zeitfenster haben.
  • Unvollständige Datensätze – Business Intelligence verfolgt einen breiten Ansatz, sodass Prüfungen möglicherweise zwar umfassend, aber nicht tief greifend sind. Dies erhöht die Wahrscheinlichkeit, dass Daten übersehen werden; insbesondere in Fällen, in denen die Prüfungsparameter durch die Tools selbst nur schwer geändert werden können.
  • Erkennung statt Analyse – Business-Intelligence-Tools sind in erster Linie darauf ausgelegt, Daten zu finden. Der Fokus hierbei liegt vor allem auf Daten, die für ihre Benutzer nützlich sein können. An dieser Stelle endet jedoch häufig die Leistungsfähigkeit der Tools, da sie Benutzern keine einfachen Optionen bieten, die Daten tatsächlich zu analysieren. Die Möglichkeit, umsetzbare Erkenntnisse zu gewinnen, verringert sich somit.
  • Eingeschränkte Skalierbarkeit – Im Allgemeinen bleibt Business Intelligence ein Bereich für Spezialisten und Experten mit dem entsprechenden Know-how, über das Mitarbeiter im operativen Bereich oftmals nicht verfügen. Ohne umfangreiches Verständnis für die geschäftlichen Prozesse und deren Analyse innerhalb des Unternehmens bleibt die optimierte Anwendung eines bestimmten Business-Intelligence-Tools aber eingeschränkt.
  • Nicht nachvollziehbare Metriken – Werden Metriken verwendet, die nicht mit den Geschäftsprozessen verknüpft sind, kann Business Intelligence kaum positive Veränderungen innerhalb eines Unternehmens unterstützen. Für Benutzer ist es schwierig, Ergebnisse richtig auszuwerten und zu verstehen und diese Ergebnisse zweckdienlich zu nutzen.

Process Intelligence: der nächste wegweisende Schritt

Es bedarf einer effektiveren Methode zur Prozessanalyse, um eine effiziente Arbeitsweise und fundierte Entscheidungsfindung sicherzustellen. An dieser Stelle kommt Process Intelligence (PI) ins Spiel. PI bietet die entscheidenden Hintergrundinformationen für die Beantwortung von Fragen, die mit Business-Intelligence-Tools unbeantwortet bleiben.

Process Intelligence ermöglicht die durchgehende Visualisierung von Prozessabläufen mithilfe von Rohdaten. Mit dem richtigen Process-Intelligence-Tool können diese Rohdaten sofort analysiert werden, sodass Prozesse präzise angezeigt werden. Der Endbenutzer kann diese Informationen nach Bedarf einsehen und bearbeiten, ohne eine Vorauswahl für die Analyse treffen zu müssen.

Zum Vergleich: Da Business Intelligence vordefinierte Analysekriterien benötigt, kann BI nur dann wirklich nützlich sein, wenn diese Kriterien auch definiert sind. Unternehmen können verzögerte Analysen vermeiden, indem sie Process Intelligence zur Ermittlung der Hauptursache von Prozessproblemen nutzen, und dann die richtigen Kriterien zur Bestimmung des Analyserahmens auswählen.

Anschließend können Sie Ihre Systemprozesse analysieren und erkennen die Diskrepanzen und Varianten zwischen dem angestrebten Geschäftsprozess und dem tatsächlichen Verlauf Ihrer Prozesse. Und je schneller Sie Echtzeit-Einblicke in Ihre Prozesse gewinnen, desto schneller können Sie in Ihrem Unternehmen positive Veränderungen auf den Weg bringen.

Kurz gesagt: Business Intelligence eignet sich dafür, ein breites Verständnis über die Abläufe in einem Unternehmen zu gewinnen. Für einige Unternehmen kann dies ausreichend sein. Für andere hingegen ist ein Überblick nicht genug.

Sie suchen nach einer Möglichkeit um festzustellen, wie jeder Prozess in Ihrer Organisation tatsächlich funktioniert? Die Antwort hierauf lautet Software. Software, die Prozesserkennung, Prozessanalyse und Konformitätsprüfung miteinander kombiniert.

Mit den richtigen Process-Intelligence-Tools können Sie nicht nur Daten aus den verschiedenen IT-Systemen in Ihrem Unternehmen gewinnen, sondern auch Ihre End-to-End-Prozesse kontinuierlich überwachen. So erhalten Sie Erkenntnisse über mögliche Risiken und Verbesserungspotenziale. PI steht für einen kollaborativen Ansatz zur Prozessverbesserung, der zu einem bahnbrechenden Verständnis über die Abläufe in Ihrem Unternehmen führt, und wie diese optimiert werden können.

Erhöhtes Potenzial mit Signavio Process Intelligence

Mit Signavio Process Intelligence erhalten Sie wegweisende Erkenntnisse über Ihre Prozesse, auf deren Basis Sie bessere Geschäftsentscheidungen treffen können. Erlangen Sie eine vollständige Sicht auf Ihre Abläufe und ein Verständnis dafür, was in Ihrer Organisation tatsächlich geschieht.

Als Teil der Signavio Business Transformation Suite lässt sich Signavio Process Intelligence perfekt mit der Prozessmodellierung und -automatisierung kombinieren. Als eine vollständig cloudbasierte Process-Mining-Lösung erleichtert es die Software, organisationsweit zusammenzuarbeiten und Wissen zu teilen.

Generieren Sie neue Ideen, sparen Sie Aufwand und Kosten ein und optimieren Sie Ihre Prozesse. Erfahren Sie mehr über Signavio Process Intelligence.

Allgemeines über Geodaten

Dieser Artikel ist der Auftakt in einer Artikelserie zum Thema “Geodatenanalyse”.

Von den vielen Arten an Datensätzen, die öffentlich im Internet verfügbar sind, bin ich in letzter Zeit vermehrt über eine besonders interessante Gruppe gestolpert, die sich gleich für mehrere Zwecke nutzen lassen: Geodaten.

Gerade in wirtschaftlicher Hinsicht bieten sich eine ganze Reihe von Anwendungsfällen, bei denen Geodaten helfen können, Einblicke in Tatsachen zu erlangen, die ohne nicht möglich wären. Der wohl bekannteste Fall hierfür ist vermutlich die einfache Navigation zwischen zwei Punkten, die jeder kennt, der bereits ein Navigationssystem genutzt oder sich eine Route von Google Maps berechnen lassen hat.
Hiermit können nicht nur Fragen nach dem schnellsten oder Energie einsparensten (und damit gleichermaßen auch witschaftlichsten) Weg z. B. von Berlin nach Hamburg beantwortet werden, sondern auch die bestmögliche Lösung für Ausnahmesituationen wie Stau oder Vollsperrungen berechnet werden (ja, Stau ist, zumindest in der Theorie immer noch eine “Ausnahmesituation” ;-)).
Neben dieser beliebten Art Geodaten zu nutzen, gibt es eine ganze Reihe weiterer Situationen in denen deren Nutzung hilfreich bis essentiell sein kann. Als Beispiel sei hier der Einzugsbereich von in Konkurrenz stehenden Einheiten, wie z. B. Supermärkten genannt. Ohne an dieser Stelle statistische Nachweise vorlegen zu können, kaufen (zumindest meiner persönlichen Beobachtung nach) die meisten Menschen fast immer bei dem Supermarkt ein, der am bequemsten zu erreichen ist und dies ist in der Regel der am nächsten gelegene. Besitzt man nun eine Datenbank mit der Information, wo welcher Supermarkt bzw. welche Supermarktkette liegt, kann man mit so genannten Voronidiagrammen recht einfach den jeweiligen Einzugsbereich der jeweiligen Supermärkte berechnen.
Entsprechende Karten können auch von beliebigen anderen Entitäten mit fester geographischer Position gezeichnet werden: Geldautomaten, Funkmasten, öffentlicher Nahverkehr, …

Ein anderes Beispiel, das für die Datenauswertung interessant ist, ist die kartographische Auswertung von Postleitzahlen. Diese sind in fast jedem Datensatz zu Kunden, Lieferanten, ect. vorhanden, bilden jedoch weder eine ordinale, noch eine sinnvolle kategorische Größe, da es viele tausend verschiedene gibt. Zudem ist auch eine einfache Gruppierung in gröbere Kategorien wie beispielsweise Postleitzahlen des Schemas 1xxxx oft kaum sinnvoll, da diese in aller Regel kein sinnvolles Mapping auf z. B. politische Gebiete – wie beispielsweise Bundesländer – zulassen. Ein Ausweg aus diesem Dilemma ist eine einfache kartographische Übersicht, welche die einzelnen Postleitzahlengebiete in einer Farbskala zeigt.

Im gezeigten Beispiel ist die Bevölkerungsdichte Deutschlands als Karte zu sehen. Hiermit wird schnell und übersichtlich deutlich, wo in Deutschland die Bevölkerung lokalisiert ist. Ähnliche Karten können beispielsweise erstellt werden, um Fragen wie “Wie ist meine Kundschaft verteilt?” oder “Wo hat die Werbekampange XYZ besonders gut funktioniert?” zu beantworten. Bezieht man weitere Daten wie die absolute Bevölkerung oder die Bevölkerungsdichte mit ein, können auch Antworten auf Fragen wie “Welchen Anteil der Bevölkerung habe ich bereits erreicht und wo ist noch nicht genutztes Potential?” oder “Ist mein Produkt eher in städtischen oder ländlichen Gebieten gefragt?” einfach und schnell gefunden werden.
Ohne die entsprechende geographische Zusatzinformation bleiben insbesondere Postleitzahlen leider oft als “nicht sinnvoll auswertbar” bei der Datenauswertung links liegen.
Eine ganz andere Art von Vorteil der Geodaten ist der educational point of view:
  • Wer erst anfängt, sich mit Datenbanken zu beschäftigen, findet mit Straßen, Postleitzahlen und Ländern einen deutlich einfacheren und vor allem besser verständlichen Zugang zu SQL als mit abstrakten Größen und Nummern wie ProductID, CustomerID und AdressID. Zudem lassen sich Geodaten nebenbei bemerkt mittels so genannter GeoInformationSystems (*gis-Programme), erstaunlich einfach und ansprechend plotten.
  • Wer sich mit SQL bereits ein wenig auskennt, kann mit den (beispielsweise von Spatialite oder PostGIS) bereitgestellten SQL-Funktionen eine ganze Menge über Datenbanken sowie deren Möglichkeiten – aber auch über deren Grenzen – erfahren.
  • Für wen relationale Datenbanken sowie deren Funktionen schon lange nichts Neues mehr darstellen, kann sich hier (selbst mit dem eigenen Notebook) erstaunlich einfach in das Thema “Bug Data” einarbeiten, da die Menge an öffentlich vorhandenen Geodaten z.B. des OpenStreetMaps-Projektes selbst in optimal gepackten Format vielen Dutzend GB entsprechen. Gerade die Möglichkeit, die viele *gis-Programme wie beispielsweise QGIS bieten, nämlich Straßen-, Schienen- und Stromnetze “on-the-fly” zu plotten, macht die Bedeutung von richtig oder falsch gesetzten Indices in verschiedenen Datenbanken allein anhand der Geschwindigkeit mit der sich die Plots aufbauen sehr eindrucksvoll deutlich.
Um an Datensätze zu kommen, reicht es in der Regel Google mit den entsprechenden Schlagworten zu versorgen.
Neben – um einen Vergleich zu nutzen – dem Brockhaus der Karten GoogleMaps gibt es beispielsweise mit dem OpenStreetMaps-Projekt einen freien Geodatensatz, welcher in diesem Kontext etwa als das Wikipedia der Karten zu verstehen ist.
Hier findet man zum Beispiel Daten wie Straßen-, Schienen- oder dem Stromnetz, aber auch die im obigen Voronidiagramm eingezeichneten Gebäude und Supermärkte stammen aus diesem Datensatz. Hiermit lassen sich recht einfach just for fun interessante Dinge herausfinden, wie z. B., dass es in Deutschland ca. 28 Mio Gebäude gibt (ein SQL-Einzeiler), dass der Berliner Osten auch ca. 30 Jahre nach der Wende noch immer vorwiegend von der Tram versorgt wird, während im Westen hauptsächlich die U-Bahn fährt. Oder über welche Trassen der in der Nordsee von Windkraftanlagen erzeugte Strom auf das Festland kommt und von da aus weiter verteilt wird.
Eher grundlegende aber deswegen nicht weniger nützliche Datensätze lassen sich unter dem Stichwort “natural earth” finden. Hier sind Daten wie globale Küstenlinien, mittels Echolot ausgemessene Meerestiefen, aber auch von Menschen geschaffene Dinge wie Landesgrenzen und Städte sehr übersichtlich zu finden.
Im Grunde sind der Vorstellung aber keinerlei Grenzen gesetzt und fast alle denkbaren geographischen Fakten können, manchmal sogar live via Sattelit, mitverfolgt werden. So kann man sich beispielsweise neben aktueller Wolkenbedekung, Regenradar und globaler Oberflächentemperatur des Planeten auch das Abschmelzen der Polkappen seit 1970 ansehen (NSIDC) oder sich live die Blitzeinschläge auf dem gesamten Planeten anschauen – mit Vorhersage darüber, wann und wo der Donner zu hören ist (das funktioniert wirklich! Beispielsweise auf lightningmaps).
Kurzum Geodaten sind neben ihrer wirtschaftlichen Relevanz – vor allem für die Logistik – auch für angehende Data Scientists sehr aufschlussreich und ein wunderbares Spielzeug, mit dem man sich lange beschäftigen und eine Menge interessanter Dinge herausfinden kann.

OLAP-Würfel

Der OLAP-Würfel

Alles ist relativ! So auch die Anforderungen an Datenbanksysteme. Je nachdem welche Arbeitskollegen/innen dazu gefragt werden, können unterschiedliche Wünschen und Anforderungen an Datenbanksysteme dabei zu Tage kommen.

Die optimale Ausrichtung des Datenbanksystems auf seine spezielle Anwendung hin, setzt den Grundstein für eine performante und effizientes Informationssystem und sollte daher wohl überlegt sein. Eine klassische Unterscheidung für die Anwendung von Datenbanksystemen lässt sich hierbei zwischen OLTP (Online Transaction Processing) und OLAP (Online Analytical Processing) machen.

OLTP-Datenbanksysteme zeichnen sich insbesondere durch die direkte Verarbeitung bei hohem Durchsatz von Transaktionen, sowie den parallelen Zugriff auf Informationen aus und werden daher vor allem für die Erfassung von operativen Geschäftsfällen eingesetzt. Im Gegensatz zu OLTP-Systemen steht bei OLAP-Systemen die analytische Verarbeitung von großen Datenbeständen im Vordergrund. Die folgende Grafik veranschaulicht das Zusammenwirken von OLTP und OLAP.

Da OLAP-Systeme eine mehrdimensionale und subjektbezogen Datenstruktur aufweisen, können statistisch-analytische Verarbeitungen auf diese Datenmengen effizient angewandt werden. Basierend auf dem Sternen-Schema, werden in diesem Zusammenhang häufig sogenannte OLAP-Würfel (engl. „Cube“) verwendet, welcher die Grundlage für multidimensionale Analysen bildet. Im Folgenden werden wir den OLAP-Würfel etwas näher beleuchten.

Aufbau des OLAP-Würfels

Der OLAP-Würfel ist eine Zusammensetzung aus multidimensionale Datenarrays. Die logische Anordnung der Daten über mehrere Dimensionen erlaubt dem Benutzer verschiedene Ansichten auf die Daten in gleicher Weise zu erlangen. Der Begriff „Würfel“ („Cube“) referenziert hierbei auf die Darstellung eines OLAP-Würfels mit drei Dimensionen. OLAP-Würfel mit mehr als drei Dimensionen werden daher auch „Hypercubes“ genannt.

Die Achsen des Würfels entsprechen den Dimensionen, also den Attributen/ Eigenschaften des Würfels, welche den Würfel aufspannen. Typische Dimensionen sind: Produkt, Ort und Zeit.

Die Zellen im Schnittpunkt der Koordinaten entsprechen den Kennzahlen auch Maßzahlen (engl. „measures“) genannt. Die Kennzahlen stehen im Mittelpunkt der Datenanalyse und können sowohl Basisgrößen (atomare Werte) als auch abgeleitete Zahlen (berechnete Werte) sein. Oftmals handelt es sich bei den Kennzahlen um numerische Werte wie z.B.: Umsatz, Kosten und Gewinn.

Hierarchien beschreiben eine logische Struktur einzelner Elemente in den Dimensionen und nehmen dabei meist ein hierarchisches Schema an z.B.:  Tag -> Monat -> Jahr ->TOP. Die Werte der jeweils übergeordneten Elemente ergeben sich meistens aus einer Konsolidierung aller untergeordneten Elemente. Das größte Element „TOP“ steht dabei für „alles“ und fasst somit die gesamten Elemente der Dimension zusammen.

Je nachdem in welcher Detailstufe, auch Granularität genannt, die Kennzahlen der einzelnen Dimensionen vorliegen, können verschiedene Würfel-Operationen für Daten bis auf der kleinsten Ebenen ausgeführt werden wie z.B.: einzelne Transaktionen in einer Geschäftsstellen für einen bestimmten Tag betrachten. Bei der Wahl der Granularität ist jedoch unbedingt der Zweck sowie die Leistungsfähigkeit der Datenbank mit zu Berücksichtigen.

 

 

 

 

 

Operationen des OLAP-Würfels

Für die Auswertung von OLAP-Würfeln haben sich spezielle Operationsbezeichnungen durchgesetzt, welche im Folgenden mit grafischen Beispielen vorgestellt werden.

Die Slice Operation wird durch die Selektion bzw. Einschränkung einer Dimension auf ein Dimensionselement erwirkt. In dem hier aufgezeigten Beispiel wird durch das Selektieren auf die Produktsparte „Anzüge“,die entsprechende Scheibe aus dem Würfel „herausgeschnitten“.

 

 

 

 

 

 

 


Bei der Dice-Operation wird der Würfel auf mehreren Dimensionen, durch eine Menge von Dimensionselementen eingeschränkt. Als Resultat ergibt sich ein neuer verkleinerter, mehrdimensionaler Datenraum. Das Beispiel zeigt, wie der Würfel auf die Zeit-Dimensionselemente: „Q1 „und „Q2“ sowie die Produkt- Dimensionselemente: „Anzüge“ und „Hosen“ beschränkt wird.

 

 

 

 

 


Mit der Pivotiting/Rotation-Operation wird der Würfel um die eigene Achse rotiert. Diese Operation ermöglicht dem Benutzer unterschiedliche Sichten auf die Daten zu erhalten, da neue Kombinationen von Dimensionen sichtbar werden.

Im abgebildeten Beispiel wird der Datenwürfel nach rechts und um die Zeitachse gedreht. Die dadurch sichtbar gewordene Kombination von Ländern und Zeit ermöglicht dem Benutzer eine neue Sicht auf den Datenwürfel.


Die Operationen: Drill-down oder Drill-up werden benutzt, um durch die Hierarchien der Dimensionen zu navigieren. Je nach Anwendung verdichten sich die Daten bei der Drill-up Operation, während die Drill-down Operation einen höheren Detailgrad ermöglicht.

Beispiel werden die Dimensionen auf die jeweils höchste Klassifikationsstufe verdichtet. Das Ergebnis zeigt das TOP-Element der aggregierten Daten, mit einem Wert von 9267 €.


Technische Umsetzung

In den meisten Fällen werden OLAP-Systeme oberhalb des Data Warehouses platziert und nutzen dieses als Datenquelle.  Für die Datenspeicherung wird vor allem zwischen den klassischen Konzepten „MOLAP“ und „ROLAP“ unterschieden. Die folgende Gegenüberstellung, zeigt die wesentlichen Unterschiede der beiden Konzepte auf.

ROLAP

MOLAP

Bedeutung
Relationales-OLAP Multidimensionales-OLAP
Datenspeicherung
Daten liegen in relationalen Datenbanken vor. Daten werden in multidimensionalen Datenbanken als Datenwürfel gespeichert
Daten Form
Relationale Tabellen Multidimensionale Arrays
Datenvolumen
Hohes Datenvolumen und hohe Nutzerzahl Mittleres Datenvolum, da Detaildaten in komprimiertem Format vorliegen
Technologie
Benötigt Komplexe SQL Abfragen, um Daten zu beziehen Vorberechneter Datenwürfel hält Aggregationen vor
Skalierbarkeit
Beliebig Eingeschränkt
Antwortgeschwindigkeit
Langsam Schnell

Fazit

OLAP Würfel können effizient dafür genutzt werden, Informationen in logische Strukturen zu speichern. Die Dimensionierung sowie der Aufbau von logischen Hierarchien, erlauben dem Benutzer ein intuitives Navigieren und Betrachten des Datenbestandes. Durch die Vorberechnung der Aggregationen bei MOLAP-Systemen, können sehr komplexe Analyseabfragen mit hoher Geschwindigkeit und unabhängig von der Datenquelle durchgeführt werden. Für die betriebliche Datenanalyse ist die Nutzung des Datenwürfels insbesondere für fortgeschrittene Datenanalyse, daher eine enorme Bereicherung.

Dem Wettbewerb voraus mit Künstlicher Intelligenz

Was KI schon heute kann und was bis 2020 auf deutsche Unternehmen zukommt

Künstliche Intelligenz ist für die Menschheit wichtiger als die Erfindung von Elektrizität oder die Beherrschung des Feuers – davon sind der Google-CEO Sundar Pichai und viele weitere Experten überzeugt. Doch was steckt wirklich dahinter? Welche Anwendungsfälle funktionieren schon heute? Und was kommt bis 2020 auf deutsche Unternehmen zu?

Big Data war das Buzzword der vergangenen Jahre und war – trotz mittlerweile etablierter Tools wie SAP Hana, Hadoop und weitere – betriebswirtschaftlich zum Scheitern verurteilt. Denn Big Data ist ein passiver Begriff und löst keinesfalls alltägliche Probleme in den Unternehmen.

Dabei wird völlig verkannt, dass Big Data die Vorstufe für den eigentlichen Problemlöser ist, der gemeinhin als Künstliche Intelligenz (KI) bezeichnet wird. KI ist ein Buzzword, dessen langfristiger Erfolg und Aktivismus selbst von skeptischen Experten nicht infrage gestellt wird. Daten-Ingenieure sprechen im Kontext von KI hier aktuell bevorzugt von Deep Learning; wissenschaftlich betrachtet ein Teilgebiet der KI.

Was KI schon heute kann

Deep Learning Algorithmen laufen bereits heute in Nischen-Anwendungen produktiv, beispielsweise im Bereich der Chatbots oder bei der Suche nach Informationen. Sie übernehmen ferner das Rating für die Kreditwürdigkeit und sperren Finanzkonten, wenn sie erlernte Betrugsmuster erkennen. Im Handel findet Deep Learning bereits die optimalen Einkaufsparameter sowie den besten Verkaufspreis.

Getrieben wird Deep Learning insbesondere durch prestigeträchtige Vorhaben wie das autonome Fahren, dabei werden die vielfältigen Anwendungen im Geschäftsbereich oft vergessen.

Die Grenzen von Deep Learning

Und Big Data ist das Futter für Deep Learning. Daraus resultiert auch die Grenze des Möglichen, denn für strategische Entscheidungen eignet sich KI bestenfalls für das Vorbereitung einer Datengrundlage, aus denen menschliche Entscheider eine Strategie entwickeln. KI wird zumindest in dieser Dekade nur auf operativer Ebene Entscheidungen treffen können, insbesondere in der Disposition, Instandhaltung, Logistik und im Handel auch im Vertrieb – anfänglich jeweils vor allem als Assistenzsystem für die Menschen.

Genau wie das autonome Fahren mit Assistenzsystemen beginnt, wird auch im Unternehmen immer mehr die KI das Steuer übernehmen.

Was sich hinsichtlich KI bis 2020 tun wird

Derzeit stehen wir erst am Anfang der Möglichkeiten, die Künstliche Intelligenz uns bietet. Das Markt-Wachstum für KI-Systeme und auch die Anwendungen erfolgt exponentiell. Entsprechend wird sich auch die Arbeitsweise für KI-Entwickler ändern müssen. Mit etablierten Deep Learning Frameworks, die mehrheitlich aus dem Silicon Valley stammen, zeichnet sich der Trend ab, der für die Zukunft noch weiter professionalisiert werden wird: KI-Frameworks werden Enterprise-fähig und Distributionen dieser Plattformen werden es ermöglichen, dass KI-Anwendungen als universelle Kernintelligenz für das operative Geschäft für fast alle Unternehmen binnen weniger Monate implementierbar sein werden.

Wir können bis 2020 also mit einer Alexa oder Cortana für das Unternehmen rechnen, die Unternehmensprozesse optimiert, Risiken berichtet und alle alltäglichen Fragen des Geschäftsführers beantwortet – in menschlich-verbal formulierten Sätzen.

Der Einsatz von Künstlicher Intelligenz zur Auswertung von Geschäfts- oder Maschinendaten ist auch das Leit-Thema der zweitägigen Data Leader Days 2018 in Berlin. Am 14. November 2018 sprechen renommierte Data Leader über Anwendungsfälle, Erfolge und Chancen mit Geschäfts- und Finanzdaten. Der 15. November 2018 konzentriert sich auf Automotive- und Maschinendaten mit hochrangigen Anwendern aus der produzierenden Industrie und der Automobilzuliefererindustrie. Seien Sie dabei und nutzen Sie die Chance, sich mit führenden KI-Anwendern auszutauschen.

Einstieg in Natural Language Processing – Teil 2: Preprocessing von Rohtext mit Python

Dies ist der zweite Artikel der Artikelserie Einstieg in Natural Language Processing.

In diesem Artikel wird das so genannte Preprocessing von Texten behandelt, also Schritte die im Bereich des NLP in der Regel vor eigentlichen Textanalyse durchgeführt werden.

Tokenizing

Um eingelesenen Rohtext in ein Format zu überführen, welches in der späteren Analyse einfacher ausgewertet werden kann, sind eine ganze Reihe von Schritten notwendig. Ganz allgemein besteht der erste Schritt darin, den auszuwertenden Text in einzelne kurze Abschnitte – so genannte Tokens – zu zerlegen (außer man bastelt sich völlig eigene Analyseansätze, wie zum Beispiel eine Spracherkennung anhand von Buchstabenhäufigkeiten ect.).

Was genau ein Token ist, hängt vom verwendeten Tokenizer ab. So bringt NLTK bereits standardmäßig unter anderem BlankLine-, Line-, Sentence-, Word-, Wordpunkt- und SpaceTokenizer mit, welche Text entsprechend in Paragraphen, Zeilen, Sätze, Worte usw. aufsplitten. Weiterhin ist mit dem RegexTokenizer ein Tool vorhanden, mit welchem durch Wahl eines entsprechenden Regulären Ausdrucks beliebig komplexe eigene Tokenizer erstellt werden können.

Üblicherweise wird ein Text (evtl. nach vorherigem Aufsplitten in Paragraphen oder Sätze) schließlich in einzelne Worte und Interpunktionen (Satzzeichen) aufgeteilt. Hierfür kann, wie im folgenden Beispiel z. B. der WordTokenizer oder die diesem entsprechende Funktion word_tokenize() verwendet werden.

rawtext = 'This is a short example text that needs to be cleaned.'

tokens = nltk.word_tokenize(rawtext)

tokens
['This', 'is', 'a', 'short', 'example', 'text', 'that', 'needs', 'to',  'be',  'cleaned',  '.']

Stemming & Lemmatizing

Andere häufig durchgeführte Schritte sind Stemming sowie Lemmatizing. Hierbei werden die Suffixe der einzelnen Tokens des Textes mit Hilfe eines Stemmers in eine Form überführt, welche nur den Wortstamm zurücklässt. Dies hat den Zweck verschiedene grammatikalische Formen des selben Wortes (welche sich oft in ihrer Endung unterscheiden (ich gehe, du gehst, er geht, wir gehen, …) ununterscheidbar zu machen. Diese würden sonst als mehrere unabhängige Worte in die darauf folgende Analyse eingehen.

Neben bereits fertigen Stemmern bietet NLTK auch für diesen Schritt die Möglichkeit sich eigene Stemmer zu programmieren. Da verschiedene Stemmer Suffixe nach unterschiedlichen Regeln entfernen, sind nur die Wortstämme miteinander vergleichbar, welche mit dem selben Stemmer generiert wurden!

Im forlgenden Beispiel werden verschiedene vordefinierte Stemmer aus dem Paket NLTK auf den bereits oben verwendeten Beispielsatz angewendet und die Ergebnisse der gestemmten Tokens in einer Art einfachen Tabelle ausgegeben:

# Ready-to-use stemmers in nltk
porter = nltk.PorterStemmer()
lancaster = nltk.LancasterStemmer()
snowball = nltk.SnowballStemmer(language='english')

# Printing a table to compare the different stemmers
header = 'Token\tPorter\tLancas.\tSnowball'
print(header + '\n' + len(header) * '-')
for token in tokens:
    print('\t'.join([token, porter.stem(token), lancaster.stem(token), snowball.stem(token)]))


Token	Porter	Lancas.	Snowball
-----------------------------
This	thi 	thi 	this
is  	is  	is  	is
a    	a    	a    	a
short	short	short	short
example	exampl	exampl	exampl
text	text	text	text
that	that	that	that
needs	need	nee	need
to  	to  	to  	to
be  	be  	be  	be
cleaned	clean	cle 	clean
.   	.   	.   	.

Sehr ähnlich den Stemmern arbeiten Lemmatizer: Auch ihre Aufgabe ist es aus verschiedenen Formen eines Wortes die jeweilige Grundform zu bilden. Im Unterschied zu den Stemmern ist das Lemma eines Wortes jedoch klar als dessen Grundform definiert.

from nltk.stem import WordNetLemmatizer

lemmatizer = WordNetLemmatizer()

lemmas = [lemmatizer.lemmatize(t) for t in tokens()]

Vokabular

Auch das Vokabular, also die Menge aller verschiedenen Worte eines Textes, ist eine informative Kennzahl. Bezieht man die Größe des Vokabulars eines Textes auf seine gesamte Anzahl verwendeter Worte, so lassen sich hiermit Aussagen zu der Diversität des Textes machen.

Außerdem kann das auftreten bestimmter Worte später bei der automatischen Einordnung in Kategorien wichtig werden: Will man beispielsweise Nachrichtenmeldungen nach Themen kategorisieren und in einem Text tritt das Wort „DAX“ auf, so ist es deutlich wahrscheinlicher, dass es sich bei diesem Text um eine Meldung aus dem Finanzbereich handelt, als z. B. um das „Kochrezept des Tages“.

Dies mag auf den ersten Blick trivial erscheinen, allerdings können auch mit einfachen Modellen, wie dem so genannten „Bag-of-Words-Modell“, welches nur die Anzahl des Auftretens von Worten prüft, bereits eine Vielzahl von Informationen aus Texten gewonnen werden.

Das reine Vokabular eines Textes, welcher in der Variable “rawtext” gespeichert ist, kann wie folgt in der Variable “vocab” gespeichert werden. Auf die Ausgabe wurde in diesem Fall verzichtet, da diese im Falle des oben als Beispiel gewählten Satzes den einzelnen Tokens entspricht, da kein Wort öfter als ein Mal vorkommt.

from nltk import wordpunct_tokenizer
from nltk.stem import WordNetLemmatizer

lemma = WordNetLemmatizer()

vocab = set([WordNetLemmatizer().lemmatize(t) for t in wordpunct_tokenize(text.lower())])

Stopwords

Unter Stopwords werden Worte verstanden, welche zwar sehr häufig vorkommen, jedoch nur wenig Information zu einem Text beitragen. Beispiele in der beutschen Sprache sind: der, und, aber, mit, …

Sowohl NLTK als auch cpaCy bringen vorgefertigte Stopwordsets mit. 

from nltk.corpus import stopwords
stoplist = stopwords.words('english')
stopset = set(stopwords.words('english'))

[t for t in tokens if not t in stoplist]
['This', 'short', 'example', 'text', 'needs', 'cleaned', '.']

Vorsicht: NLTK besitzt eine Stopwordliste, welche erst in ein Set umgewandelt werden sollte um die lookup-Zeiten kurz zu halten – schließlich muss jedes einzelne Token des Textes auf das vorhanden sein in der Stopworditerable getestet werden!

%timeit [w for w in tokens if not w in stopset] # 1.11 ms
%timeit [w for w in tokens if not w in stoplist] # 26.6 ms

POS-Tagging

POS-Tagging steht für „Part of Speech Tagging“ und entspricht ungefähr den Aufgaben, die man noch aus dem Deutschunterricht kennt: „Unterstreiche alle Subjekte rot, alle Objekte blau…“. Wichtig ist diese Art von Tagging insbesondere, wenn man später tatsächlich strukturiert Informationen aus dem Text extrahieren möchte, da man hierfür wissen muss wer oder was als Subjekt mit wem oder was als Objekt interagiert.

Obwohl genau die selben Worte vorkommen, bedeutet der Satz „Die Katze frisst die Maus.“ etwas anderes als „Die Maus frisst die Katze.“, da hier Subjekt und Objekt aufgrund ihrer Reihenfolge vertauscht sind (Stichwort: Subjekt – Prädikat – Objekt ).

Weniger wichtig ist dieser Schritt bei der Kategorisierung von Dokumenten. Insbesondere bei dem bereits oben erwähnten Bag-of-Words-Modell, fließen POS-Tags überhaupt nicht mit ein.

Und weil es so schön einfach ist: Die obigen Schritte mit spaCy

Die obigen Methoden und Arbeitsschritte, welche Texte die in natürlicher Sprache geschrieben sind, allgemein computerzugänglicher und einfacher auswertbar machen, können beliebig genau den eigenen Wünschen angepasst, einzeln mit dem Paket NLTK durchgeführt werden. Dies zumindest einmal gemacht zu haben, erweitert das Verständnis für die funktionsweise einzelnen Schritte und insbesondere deren manchmal etwas versteckten Komplexität. (Wie muss beispielsweise ein Tokenizer funktionieren der den Satz “Schwierig ist z. B. dieser Satz.” korrekt in nur einen Satz aufspaltet, anstatt ihn an jedem Punkt welcher an einem Wortende auftritt in insgesamt vier Sätze aufzuspalten, von denen einer nur aus einem Leerzeichen besteht?) Hier soll nun aber, weil es so schön einfach ist, auch das analoge Vorgehen mit dem Paket spaCy beschrieben werden:

import spacy

nlp = spacy.load('en')
doc = nlp(rawtext)

Dieser kurze Codeabschnitt liest den an spaCy übergebenen Rohtext in ein spaCy Doc-Object ein und führt dabei automatisch bereits alle oben beschriebenen sowie noch eine Reihe weitere Operationen aus. So stehen neben dem immer noch vollständig gespeicherten Originaltext, die einzelnen Sätze, Worte, Lemmas, Noun-Chunks, Named Entities, Part-of-Speech-Tags, ect. direkt zur Verfügung und können.über die Methoden des Doc-Objektes erreicht werden. Des weiteren liegen auch verschiedene weitere Objekte wie beispielsweise Vektoren zur Bestimmung von Dokumentenähnlichkeiten bereits fertig vor.

Die Folgende Übersicht soll eine kurze (aber noch lange nicht vollständige) Übersicht über die automatisch von spaCy generierten Objekte und Methoden zur Textanalyse geben:

# Textabschnitte
doc.text                                 # Originaltext
sents = doc.sents                        # Sätze des Dokuments
tokens = [token for token in doc]        # Tokens/Worte des Dokuments
parags = doc.text_with_ws.split('\n\n')  # Absätze des Dokuments

# Eigenschaften einzelner Tokens
[t.lemma_ for t in doc]                  # Lemmata der einzelnen Tokens
[t.tag_ for t in doc]                    # POS-Tags der einzelnen Tokens

# Objekte zur Textanalyse
doc.vocab                                # Vokabular des Dokuments
doc.sentiment                            # Sentiment des Dokuments
doc.noun_chunks                          # NounChunks des Dokuments
entities = [ent for ent in doc.ents]     # Named Entities (Persons, Locations, Countrys)

# Objekte zur Dokumentenklassifikation
doc.vector                               # Vektor
doc.tensor                               # Tensor

Diese „Vollautomatisierung“ der Vorabschritte zur Textanalyse hat jedoch auch seinen Preis: spaCy geht nicht gerade sparsam mit Ressourcen wie Rechenleistung und Arbeitsspeicher um. Will man einen oder einige Texte untersuchen so ist spaCy oft die einfachste und schnellste Lösung für das Preprocessing. Anders sieht es aber beispielsweise aus, wenn eine bestimmte Analyse wie zum Beispiel die Einteilung in verschiedene Textkategorien auf eine sehr große Anzahl von Texten angewendet werden soll. In diesem Fall, sollte man in Erwägung ziehen auf ressourcenschonendere Alternativen wie zum Beispiel gensim auszuweichen.

Wer beim lesen genau aufgepasst hat, wird festgestellt haben, dass ich im Abschnitt POS-Tagging im Gegensatz zu den anderen Abschnitten auf ein kurzes Codebeispiel verzichtet habe. Dies möchte ich an dieser Stelle nachholen und dabei gleich eine Erweiterung des Pakets spaCy vorstellen: displaCy.

Displacy bietet die Möglichkeit, sich Zusammenhänge und Eigenschaften von Texten wie Named Entities oder eben POS-Tagging graphisch im Browser anzeigen zu lassen.

import spacy
from spacy import displacy

rawtext = 'This is a short example sentence that needs to be cleaned.'

nlp = spacy.load('en')
doc = nlp(rawtext)
displacy.serve(doc, style='dep')

Nach ausführen des obigen Codes erhält man eine Ausgabe die wie folgt aussieht:

Serving on port 5000...
Using the 'dep' visualizer

Nun öffnet man einen Browser und ruft die URL ‘http://127.0.0.1:5000’ auf (Achtung: localhost anstatt der IP funktioniert – warum auch immer – mit displacy nicht). Im Browser sollte nun eine Seite mit einem SVG-Bild geladen werden, welches wie folgt aussieht

Die Abbildung macht deutlich was POS-Tagging genau ist und warum es von Nutzen sein kann wenn man Informationen aus einem Text extrahieren will. Jedem Word (Token) ist eine Wortart zugeordnet und die Beziehung der einzelnen Worte durch Pfeile dargestellt. Dies ermöglicht es dem Computer zum Beispiel in dem Satzteil “der grüne Apfel”, das Adjektiv “grün” auf das Nomen “Apfel” zu beziehen und diesem somit als Eigenschaft zuzuordnen.

Nachdem dieser Artikel wichtige Schritte des Preprocessing von Texten beschrieben hat, geht es im nächsten Artikel darum was man an Texten eigentlich analysieren kann und welche Analysemöglichkeiten die verschiedenen für Python vorhandenen Module bieten.

Einstieg in Natural Language Processing – Artikelserie

Unter Natural Language Processing (NLP) versteht man ein Teilgebiet der Informatik bzw. der Datenwissenschaft, welches sich mit der Analyse und Auswertung , aber auch der Synthese natürlicher Sprache befasst. Mit natürlichen Sprachen werden Sprachen wie zum Beispiel Deutsch, Englisch oder Spanisch bezeichnet, welche nicht geplant entworfen wurden, sondern sich über lange Zeit allein durch ihre Benutzung entwickelt haben. Anders ausgedrückt geht es um die Schnittstelle zwischen unserer im Alltag verwendeten und für uns Menschen verständlichen Sprache auf der einen, und um deren computergestützte Auswertung auf der anderen Seite.

Diese Artikelserie soll eine Einführung in die Thematik des Natural Language Processing sein, dessen Methoden, Möglichkeiten, aber auch der Grenzen . Im einzelnen werden folgende Themen näher behandelt:

1. Artikel – Natürliche vs. Formale Sprachen
2. Artikel – Preprocessing von Rohtext mit Python (erscheint demnächst…)
3. Artikel – Möglichkeiten/Methoden der Textanalyse an Beispielen (erscheint demnächst…)
4. Artikel – NLP, was kann es? Und was nicht? (erscheint demnächst…)

Zur Verdeutlichung der beschriebenen Zusammenhänge und Methoden und um Interessierten einige Ideen für mögliche Startpunkte aufzuzeigen, werden im Verlauf der Artikelserie an verschiedenen Stellen Codebeispiele in der Programmiersprache Python vorgestellt.
Von den vielen im Internet zur Verfügung stehenden Python-Paketen zum Thema NLP, werden in diesem Artikel insbesondere die drei Pakete NLTK, Gensim und Spacy verwendet.

R oder Python – Die Sprache der Wahl in einem Data Science Weiterbildungskurs

Die KDnuggets, ein einflussreicher Newletter zu Data Mining und inzwischen auch zu Data Science, überraschte kürzlich mit der Meldung „Python eats away at R: Top Software for Analytics, Data Science, Machine Learning in 2018. Trends and Analysis“.[1] Grundlage war eine Befragung, an der mehr als 2300 KDNuggets Leser teilnahmen. Nach Bereinigung um die sogenannten „Lone Voters“, gingen insgesamt 2052 Stimmen in die Auswertung ein.

Demnach stieg der Anteil der Python-Nutzer von 2017 bis 2018 um 11% auf 65%, während mit 48% weniger als die Hälfte der Befragungsteilnehmer noch R nannten. Gegenüber 2017 ging der Anteil von R um 14% zurück. Dies ist umso bemerkenswerter, als dass bei keinem der übrigen Top Tools eine Verminderung des Anteils gemessen wurde.

Wir verzichten an dieser Stelle darauf, die Befragungsergebnisse selbst in Frage zu stellen oder andere Daten herbeizuziehen. Stattdessen nehmen wir erst einmal die Zahlen wie sie sind und konzedieren einen gewissen Python Hype. Das Python Konjunktur hat, zeigt sich z.B. in der wachsenden Zahl von Buchtiteln zu Python und Data Science oder in einem Machine Learning Tutorial der Zeitschrift iX, das ebenfalls auf Python fußt. Damit stellt sich die Frage, ob ein Weiterbildungskurs zu Data Science noch guten Gewissens auf R als Erstsprache setzen kann.

Der Beantwortung dieser Frage seien zwei Bemerkungen vorangestellt:

  1. Ob die eine Sprache „besser“ als die andere ist, lässt sich nicht abschließend beantworten. Mit Blick auf die Teilarbeitsgebiete des Data Scientists, also Datenzugriff, Datenmanipulation und Transformation, statistische Analysen und visuelle Aufbereitung zeigt sich jedenfalls keine prinzipielle Überlegenheit der einen über die andere Sprache.
  2. Beide Sprachen sind quicklebendig und werden bei insgesamt steigenden Nutzerzahlen dynamisch weiterentwickelt.

Das Beispiel der kürzlich gegründeten Ursa Labs[2] zeigt überdies, dass es zukünftig weniger darum gehen wird „Werkzeuge für eine einzelne Sprache zu bauen…“ als darum „…portable Bibliotheken zu entwickeln, die in vielen Programmiersprachen verwendet werden können“[3].

Die zunehmende Anwendung von Python in den Bereichen Data Science und Machine Learning hängt auch damit zusammen, dass Python ursprünglich als Allzweck-Programmiersprache konzipiert wurde. Viele Entwickler und Ingenieure arbeiteten also bereits mit Python ohne dabei mit analytischen Anwendungen in Kontakt zu kommen. Wenn diese Gruppen gegenwärtig mehr und mehr in den Bereichen Datenanalyse, Statistik und Machine Learning aktiv werden, dann greifen sie naturgemäß zu einem bekannten Werkzeug, in diesem Fall zu einer bereits vorhandenen Python Implementation.

Auf der anderen Seite sind Marketingfachleute, Psychologen, Controller und andere Analytiker eher mit SPSS und Excel vertraut. In diesen Fällen kann die Wahl der Data Science Sprache freier erfolgen. Für R spricht dann zunächst einmal seine Kompaktheit. Obwohl inzwischen mehr als 10.000 Erweiterungspakete existieren, gibt es mit www.r-project.org immer noch eine zentrale Anlaufstelle, von der über einen einzigen Link der Download eines monolithischen Basispakets erreichbar ist.

Demgegenüber existieren für Python mit Python 2.7 und Python 3.x zwei nach wie vor aktive Entwicklungszweige. Fällt die Wahl z.B. auf Python 3.x, dann stehen mit Python3 und Ipython3 wiederum verschiedene Interpreter zur Auswahl. Schließlich gibt es noch Python Distributionen wie Anaconda. Anaconda selbst ist in zwei „Geschmacksrichtungen“ (flavors) verfügbar als Miniconda und eben als Anaconda.

R war von Anfang an als statistische Programmiersprache konzipiert. Nach allen subjektiven Erfahrungen eignet es sich allein schon deshalb besser zur Erläuterung statistischer Methoden. Noch vor wenigen Jahren galt R als „schwierig“ und Statistikern vorbehalten. In dem Maße, in dem wissenschaftlich fundierte Software Tools in den Geschäftsalltag vordringen wird klar, dass viele der zunächst als „schwierig“ empfundenen Konzepte letztlich auf Rationalität und Arbeitsersparnis abzielen. Fehler, Bugs und Widersprüche finden sich in R so selbstverständlich wie in allen anderen Programmiersprachen. Bei der raschen Beseitigung dieser Schwächen kann R aber auf eine große und wache Gemeinschaft zurückgreifen.

Die Popularisierung von R erhielt durch die Gründung des R Consortiums zu Beginn des Jahres 2015 einen deutlichen Schub. Zu den Initiatoren dieser Interessengruppe gehörte auch Microsoft. Tatsächlich unterstützt Microsoft R auf vielfältige Weise unter anderem durch eine eigene Distribution unter der Bezeichnung „Microsoft R Open“, die Möglichkeit R Code in SQL Anweisungen des SQL Servers absetzen zu können oder die (angekündigte) Weitergabe von in Power BI erzeugten R Visualisierungen an Excel.

Der Vergleich von R und Python in einem fiktiven Big Data Anwendungsszenario liefert kein Kriterium für die Auswahl der Unterrichtssprache in einem Weiterbildungskurs. Aussagen wie x ist „schneller“, „performanter“ oder „besser“ als y sind nahezu inhaltsleer. In der Praxis werden geschäftskritische Big Data Anwendungen in einem Umfeld mit vielen unterschiedlichen Softwaresystemen abgewickelt und daher von vielen Parametern beeinflusst. Wo es um Höchstleistungen geht, tragen R und Python häufig gemeinsam zum Ergebnis bei.

Der Zertifikatskurs „Data Science“ der AWW e. V. und der Technischen Hochschule Brandenburg war schon bisher nicht auf R beschränkt. Im ersten Modul geben wir z.B. auch eine Einführung in SQL und arbeiten mit ETL-Tools. Im gerade zu Ende gegangenen Kurs wurde Feature Engineering auf der Grundlage eines Python Lehrbuchs[4] behandelt und die Anweisungen in R übersetzt. In den kommenden Durchgängen werden wir dieses parallele Vorgehen verstärken und wann immer sinnvoll auch auf Lösungen in Python hinweisen.

Im Vertiefungsmodul „Machine Learning mit Python“ schließlich ist Python die Sprache der Wahl. Damit tragen wir der Tatsache Rechnung, dass es zwar Sinn macht in die grundlegenden Konzepte mit einer Sprache einzuführen, in der Praxis aber Mehrsprachigkeit anzutreffen ist.

[1] https://www.kdnuggets.com/2018/05/poll-tools-analytics-data-science-machine-learning-results.html

[2] https://ursalabs.org/

[3] Statement auf der Ursa Labs Startseite, eigene Übersetzung.

[4] Sarkar, D et al. Practical Machine Learning with Python, S. 177ff.

Datenmodell: Sternschema 0.2

Ob es unsere Schritte während des Sports sind, Klicks auf Websiten oder auch Geschäftszahlen eines Unternehmens – all diese Informationen werden in Form von Daten gespeichert. Dabei fallen große Mengen an Daten an, die in der Regel in einer relationalen Datenbank gespeichert werden, um sie besonders gut administrieren zu können.
Gerade in einem Unternehmen ist es wichtig, dass mehrere Benutzer parallel und mit wenig Verzögerung Anfragen und Änderungen in den Daten durchführen können. Daher werden viele Datenbanken in Unternehmen als OLTP-Datenbank-Systeme ausgelegt. OLTP steht für Online Transaction Processing, auch Echtzeit-Transaktionsverarbeitung ist dafür optimiert, schnelle und parallele Zugriffe auf Daten in der Datenbank zu gewährleisten.
Möchte man hingegen Daten auswerten und analysieren, sind OLTP-Datenbanken-Systeme weniger geeignet, da sie nicht für diese Art von Anfragen konzipiert worden sind. Um effektiv analytische Befehle an eine Datenbank stellen zu können, werden daher Datenbanken genutzt, die mit einer OLAP-Verarbeitung arbeiten. OLAP ist die Abkürzung für Online Analytical Processing. Im Gegensatz zu OLTP, in welchen die Daten in einem zweidimensionalen Modell gespeichert werden, sind Daten in einem OLAP-System in einer multidimensionalen Struktur untergebracht, welche für die Durchführung komplexer Analysebefehle optimiert ist.
Für Analysen werden oft Daten aus mehreren Datenbanken benötigt, weswegen sie in einem Datenlager – oder auch Data Warehouse genannt – zusammengefasst und gespeichert werden. Ein Data Warehouse, welche auf der OLAP-Verarbeitung basiert, ist somit eine für Analysezwecke optimierte Datenbank.
Es gibt verschiedene Datenmodelle um die Daten in einem Data Warehouse anzulegen. Das verbreiteste Datenmodell für diese Zwecke ist das sogenannte Sternen-Schema (Star Schema). Neben dem Sternen-Schema gibt es auch die sogenannten Galaxy- und Snowflake-Schemen, die wiederum eine Erweiterung des zuerst genannten Datenmodells sind. In diesem Artikel werden wir das Sternschema näher beleuchten.

Aufbau und Funktionsweise

Bei einem Sternschema werden die Daten grundlegend in zwei Gruppen unterteilt:

  • Fakten, manchmal auch Metriken, Messwerte oder Kennzahlen genannt, sind die zu verwaltenden bzw. die zu analysierenden Daten und werden fortlaufend in der Faktentabelle gespeichert. Beispielhaft für Fakten sind Umsätze sowie Verkaufszahlen eines Unternehmens. Sie haben stets eine numerische Form.
  • Dimensionen sind die Attribute bzw. Eigenschaften der Fakten und beschreiben sozusagen die Fakten im Detail. Diese werden in Dimensionstabellen gelistet. Jeder Dimensionsdatensatz bzw. jede Zeile einer Dimensionstabelle wird durch Primärschlüssel eindeutig identifiziert. Diese Schlüssel werden in der Faktentabelle als Fremdschlüssel gespeichert und somit sind Dimensions- und Faktentabelle miteinander verknüpft.

Beispiel: Max Mustermann, 25 Jahre alt, wohnhaft in Musterstadt hat eine Kaffeemaschine mit dem Namen ‘Musterpresso’ am 01.01.2018 um 15:00:00 gekauft.

Wie in der Abbildung dargestellt, werden die Details, als Attribute dargestellt, vom Kunden wie Namen, Alter oder Wohnort in der Dimensionstabelle “Kunde” gespeichert und mit dem Primärschlüssel (in diesem Beispiel “1111”) gekennzeichnet. Dieser wird in der Faktentabelle als Fremdschlüssel gespeichert. Analog zu den Daten vom Kunden werden auch Dimensionstabellen für die Größen

  • Bestellung,
  • Produkt,
  • Produktkategorie und
  • Zeit gebildet.

Die Fakten, welche in diesem Beispiel der Umsatz von Max Mustermann ein Fakt wäre, können nun mithilfe der Fremdschlüssel

  • Kunden ID,
  • Bestellung ID,
  • Produkt ID,
  • Produktkategorie ID und
  • Zeit

aus der Faktentabelle aufgerufen werden.

Bei der Bildung von Tabellen ist es möglich, dass identische Werte mehrfach gespeichert werden. Dabei können Redundanzen und Anomalien in der Datenbank enstehen, welche zusätzlich einen erhöhten Speicherbedarf erfordern. Um dies zu verhindern werden Tabellen normalisiert. Bei einer Normalisierung einer Tabelle bzw. einer Tabellenstruktur wird es angestrebt, Redundanzen bis auf ein Maximum zu reduzieren. Je nach Grad der Normalisierung können diese in verschiedene Normalformen (1NF -2NF-3NF-BCNF-4NF-5NF) unterteilt werden.

Die Normalisierung in eine höhere Normalform hat jedoch zur Folge, dass die Abfrage-Performance abnimmt. Da das Sternschema-Modell darauf ausgelegt ist Leseoperationen effizient durchzuführen, sind Faktentabellen in der dritten Normalform (3NF) abgespeichert, da alle Redundanzen in dieser Form beseitigt worden sind und dennoch eine hohe Performance gewährleistet. Dimensionstabellen sind hingegen nur bis zur zweiten Normalform (2NF) optimiert. Es werden also bewusst Redundanzen und ein erhöhter Speicherbedarf in den Dimensionstabellen für eine schnelle Abfrage der Daten in Kauf genommen.

Vor- und Nachteile

Wie bereits erwähnt, sind Dimensionstabellen im Sternschema nicht vollständig normalisiert. Damit nimmt man zugunsten höherer Performance mögliche Anomalien und auch einen erhöhten Speicherbedarf in Kauf. Durch das einfache Modell ist dafür jedoch eine intuitive Bedienung möglich und auch Veränderungen sowie Erweiterungen des Modell sind leicht realisierbar.

Vorteile Nachteile
Einfaches Modell ermöglicht eine intuitive Bedienung. Durch mehrfaches Speichern identischer Werte steigt die Redundanz in den Dimenionstabellen
Veränderungen und Erweiterungen können leicht umgesetzt werden. Bei häufigen Abfragen sehr großer Dimensionstabellen verschlechtern sich die Antwortzeiten
Durch Verzicht der Normalisierung in den Dimensionstabellen ist die hierarchische Beziehung innerhalb einer Dimension leicht darstellbar Erhöhter Speicherbedarf durch Nicht-Normalisierung der Dimensionstabellen

Zusammenfassung

Das Sternschema ist ein Datenmodell, welches für analytische Zwecke im Data Warehouse und bei OLAP-Anwendungen zum Einsatz kommt. Es ist darauf optimiert, effiziente Leseoperationen zu gewährleisten.
Der Name des Modells beruht auf der sternförmigen Anordnung von Dimensionstabellen um die Faktentabelle, wobei die Dimensionstabellen die Attribute der Fakten beinhalten und in den Faktentabellen die zu analysierenden Größen gespeichert sind. Charakteristisch ist dabei, dass die Dimensionstabellen nicht bis zur dritten Normalform normalisiert sind. Der sich daraus ergebende Vorteil ist die schnelle Verarbeitung von Abfragen. Auch ist die intuitive Bedienung ein positiver Aspekt des einfachen Datenmodells. Jedoch können durch den Verzicht der Normalisierung Redundanzen innerhalb der Dimensionstabellen durch mehrfache Speicherung von identischen Werten entstehen. Ebenfalls ist bei häufigen Anfragen von großen Dimensionstabellen ein verschlechtertes Antwortverhalten feststellbar.
Daher sind sie vor allem dann effektiv, wenn

  • schnelle Anfrageverarbeitungen notwendig sind,
  • sich schnell ändernde Datenstrukturen (der Original-Daten) vorliegen,
  • Dimensionstabellen in ihrer Größe überschaubar bleiben,
  • und ein breites Spektrum an Benutzern Zugriff auf die Daten benötigt.

Ständig wachsende Datenflut – Muss nun jeder zum Data Scientist werden?

Weltweit rund 163 Zettabyte – so lautet die Schätzung von IDC für die Datenmenge weltweit im Jahr 2025. Angesichts dieser kaum noch vorstellbaren Zahl ist es kein Wunder, wenn Anwender in Unternehmen sich überfordert fühlen. Denn auch hier muss vieles analysiert werden – eigene Daten aus vielen Bereichen laufen zusammen mit Daten Dritter, seien es Dienstleister, Partner oder gekaufter Content. Und all das wird noch ergänzt um Social Content – und soll dann zu sinnvollen Auswertungen zusammengeführt werden. Das ist schon für ausgesprochene Data Scientists keine leichte Aufgabe, von normalen Usern ganz zu schweigen. Doch es gibt eine gute Nachricht dabei: den Umgang mit Daten kann man lernen.

Echtes Datenverständnis – Was ist das?

Unternehmen versuchen heute, möglichst viel Kapital aus den vorhandenen Daten zu ziehen und erlauben ihren Mitarbeitern kontrollierten, aber recht weit gehenden Zugriff. Das hat denn auch etliche Vorteile, denn nur wer Zugang zu Daten hat, kann Prozesse beurteilen und effizienter gestalten. Er kann mehr Informationen zu Einsichten verwandeln, Entwicklungen an den realen Bedarf anpassen und sogar auf neue Ideen kommen. Natürlich muss der Zugriff auf Informationen gesteuert und kontrolliert sein, denn schließlich muss man nicht nur Regelwerken wie Datenschutzgrundverordnung gehorchen, man will auch nicht mit den eigenen Daten dem Wettbewerb weiterhelfen.

Aber davon abgesehen, liegt in der umfassenden Auswertung auch die Gefahr, von scheinbaren Erkenntnissen aufs Glatteis geführt zu werden. Was ist wahr, was ist Fake, was ein Trugschluss? Es braucht einige Routine um den Unsinn in den Daten erkennen zu können – und es braucht zuverlässige Datenquellen. Überlässt man dies den wenigen Spezialisten im Haus, so steigt das Risiko, dass nicht alles geprüft wird oder auf der anderen Seite Wichtiges in der Datenflut untergeht. Also brauchen auch solche Anwender ein gewisses Maß an Datenkompetenz, die nicht unbedingt Power User oder professionelle Analytiker sind. Aber in welchem Umfang? So weit, dass sie fähig sind, Nützliches von Falschem zu unterscheiden und eine zielführende Systematik auf Datenanalyse anzuwenden.

Leider aber weiß das noch nicht jeder, der mit Daten umgeht: Nur 17 Prozent von über 5.000 Berufstätigen in Europa fühlen sich der Aufgabe gewachsen – das sagt die Data-Equality-Studie von Qlik. Und für Deutschland sieht es sogar noch schlechter aus, hier sind es nur 14 Prozent, die glauben, souverän mit Daten umgehen zu können. Das ist auch nicht wirklich ein Wunder, denn gerade einmal 49 Prozent sind (in Europa) der Ansicht, ausreichenden Zugriff auf Daten zu haben – und das, obwohl 85 Prozent glauben, mit höherem Datenzugriff auch einen besseren Job machen zu können.

Mit Wissens-Hubs die ersten Schritte begleiten

Aber wie lernt man denn nun, mit Daten richtig oder wenigstens besser umzugehen? Den Datenwust mit allen Devices zu beherrschen? An der Uni offensichtlich nicht, denn in der Data-Equality-Studie sehen sich nur 10 Prozent der Absolventen kompetent im Umgang mit Daten. Bis der Gedanke der Datenkompetenz Eingang in die Lehrpläne gefunden hat, bleibt Unternehmen nur die Eigenregie  – ein „Learning by Doing“ mit Unterstützung. Wie viel dabei Eigeninitiative ist oder anders herum, wieviel Weiterbildung notwendig ist, scheint von Unternehmen zu Unternehmen unterschiedlich zu sein. Einige Ansätze haben sich jedoch schon bewährt:

  • Informationsveranstaltungen mit darauf aufbauenden internen und externen Schulungen
  • Die Etablierung von internen Wissens-Hubs: Data Scientists und Power-User, die ihr Know-how gezielt weitergeben: ein einzelne Ansprechpartner in Abteilungen, die wiederum ihren Kollegen helfen können. Dieses Schneeball-Prinzip spart viel Zeit.
  • Eine Dokumentation, die gerne auch informell wie ein Wiki oder ein Tutorial aufgebaut sein darf – mit der Möglichkeit zu kommentieren und zu verlinken. Nützlich ist auch ein Ratgeber, wie man Daten hinterfragt oder wie man Datenquellen hinter einer Grafik bewertet.
  • Management-Support und Daten-Incentives, die eine zusätzliche Motivation schaffen können. Dazu gehört auch, Freiräume zu schaffen, in denen sich Mitarbeiter mit Daten befassen können – Zeit, aber auch die Möglichkeit, mit (Test-)Daten zu spielen.

Darüber hinaus aber braucht es eine Grundhaltung, die sich im Unternehmen etablieren muss: Datenkompetenz muss zur Selbstverständlichkeit werden. Wird sie zudem noch spannend gemacht, so werden sich viele Mitarbeiter auch privat mit der Bewertung und Auswertung von Daten beschäftigen. Denn nützliches Know-how hat keine Nutzungsgrenzen – und Begeisterung steckt an.

Process-Mining: Es werde Licht

Anzeige

Nur wer seine Prozesse kennt, kann sie optimieren

Gewachsene und in verschiedenen Systemen umgesetzte Prozesse sind meist nicht definiert und dokumentiert. Wer hat einen Prozess wann, warum und wofür angelegt? Nach welchem Schema verläuft er? Gibt es verschiedene Prozessvarianten, die durch unterschiedliche Parameter gesteuert sind? Diese Fragen können viele Unternehmen nicht beantworten und ihre betrieblichen Abläufe nicht optimieren – mit der Folge, dass sie weder ihre Transparenz steigern noch die Kosten senken und von Wettbewerbsvorteilen profitieren können.

Ohne transparente, aktuelle und einheitliche Prozessdokumentation ist der Aufwand zur Aneignung des Prozesswissens unnötig hoch – zumal die Intransparenz sehr teuer ist. Insbesondere für Unternehmen im Finance-Umfeld ist eine transparente, aktuelle Dokumentation Pflicht. Nur so können Wirtschaftsprüfer oder Revisionsabteilungen Unregelmäßigkeiten und Verstöße gegen Compliance-Richtlinien in Prozessen identifizieren und nachweisen, dass Firmen normative Vorgaben wie die Mindestanforderungen an das Risikomanagement (MaRisk) der BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht) einhalten.

Prozesse sichtbar machen

Durchblick gewährt das Process-Mining. Es macht die in Technik verborgenen Prozesse sichtbar. Als Bestandteil des Business-Process-Managements (BPM) ermöglicht es, Prozesse aus ihren digitalen Spuren in ERP-, CRM- oder proprietären Systemen zu rekonstruieren und auszuwerten. Viele Unternehmen wissen nicht, wie viele digitale Abläufe es gibt, wie sie chronologisch vonstattengehen, wie sie zusammenhängen, welche Prozessvariante wie viele Anwender wie häufig durchlaufen – und was das kostet. Ausgangspunkt des Process-Minings ist eine Sammlung der Prozessschritte. Mit statistischen Modellen lässt sich dann der Kernprozess ermitteln, der als Basis für alle Prozessabläufe Abweichungen offenbart.

Beispiel: Bestellanforderung in SAP anlegen

Der Standardprozess ist einfach: Bestellanforderung ins SAP-System eingeben, an Prozessfreigeber senden, von ihm prüfen und freigeben lassen. Die Realität könnte aber so sein: Mitarbeiter A bittet Mitarbeiter B per E-Mail, den Prozess einer Bestellanforderung in SAP anzulegen. Also sammelt Mitarbeiter B Informationen in einer Excel-Liste und legt sie auf dem Server ab – und weicht damit vom Standard ab. Da Mitarbeiter B die Freigabe des Vorgesetzten von A benötigt, fragt er ihn per E-Mail, ob er die Bestellung auslösen darf – eine weitere Abweichung. Nach Freigabe schickt Mitarbeiter B die Bestellung an den Lieferanten, ohne den Prozess in SAP anzulegen – schließlich drängt die Zeit. Die Folge: Im ERP-System fehlen Bestellanforderung und Freigabe. Wieso und warum, ist im Nachhinein nicht mehr nachvollziehbar.

Prozesse visualisieren und modellieren

Licht ins Dunkel bringt die Prozessvisualisierung. Sind Prozesse in Dashboards, Diagrammen, Tabellen und Tachoelementen dargestellt, können Unternehmen einfach nachvollziehen, wie Prozesse samt Varianten ablaufen und wie sie verknüpft sind. Auf Basis der Visualisierung ist es möglich, einzelne Abläufe zu modellieren: Man überträgt Prozessabläufe in ein standardisiertes Modell, das Prozessinformationen wie In- und Outputs, beteiligte Rollen, Dokumente und IT-Systeme beinhaltet. Umfangreiche Analysen und Simulationen erlauben dann, Prozesse zu bewerten und Optimierungspotenziale aufzudecken. Ist nachvollziehbar, wie ein Gesamtprozess mit allen Varianten abläuft, können Unternehmen Modifikationen abbauen und einen effizienten Prozess definieren.

Prozesse freigeben, versionieren und publizieren

Neben der Prozessvisualisierung sollte die Process-Mining-Lösung auch die Prozessfreigabe unter Berücksichtigung der Governance-Vorgaben unterstützen. Das erlaubt, Mitarbeitern Rollen wie Prozesseigner, -freigeber oder -prüfer zuzuweisen und eine automatisierte Freigabe zu etablieren. Sind die Daten sauber versioniert und zentral abgelegt, ist für eine lückenlose Dokumentation gesorgt. Um die Mitarbeiter entsprechend zu informieren, sollte das Tool eine einfache Publizierung unterstützen und Informationen zu Risiken, Kennzahlen und IT-Systemen bereitstellen. Außerdem sollten sich Mitarbeiter in die Prozessgestaltung einbringen können.

Informationen auslesen und auswerten – auch in der Cloud

Um eine Prozessdokumentation automatisiert zu erstellen, braucht es einen Algorithmus, der prozessrelevante Informationen aus allen IT-Systemen und Applikationen in das BPM-Tool einspielt. Über Konnektoren zu SAP ERP, Microsoft Dynamics CRM und proprietären IT-Lösungen lässt es sich an Bestandssysteme nahtlos anbinden. Das erlaubt, Informationen zielführend abzugleichen, bedarfsgerecht aufzubereiten und gewinnbringend zu nutzen. Idealerweise ist eine Process-Mining-Software fester Bestandteil eines BPM-Systems (BPMS), das die Prozessplanung, -ausführung, -analyse und -optimierung unterstützt. Eine Monitoring-Komponente sollte es gestatten, Kennzahlen zu erfassen, zu überwachen und auszuwerten. Für maximale Flexibilität ist gesorgt, wenn sich das BPM-System in der Cloud betreiben und bedarfsgerecht anpassen lässt. So können Anwender auf zyklische Lastspitzen mit einem individuellen Ressourcenmanagement reagieren.

Augen auf bei der Anbieter-Auswahl

Neben dem Funktionsumfang ist auch der IT-Dienstleister wichtig. Idealerweise bietet er eine BPM-Suite mit Process-Mining als Teilkomponente. Ein großer, internationaler IT-Systemintegrator mit Erfahrung in allen Branchen hat die nötige Manpower und Erfahrung für komplexe BPM-Projekte. Im Idealfall bietet er Unternehmen State-of-the-art-Technologie und stellt ihnen kompetente, erfahrene Prozessberater zur Seite, die sie in technischen Belangen wie Setup, Integration und Inbetriebnahme sowie dem Auslesen der Daten aus IT-Systemen unterstützen – für eine zielführende Prozessoptimierung und ein wirksames Change-Management. Wenn der Dienstleister über das BPM-Projekt hinaus wertvolle Hilfestellung leistet, können Unternehmen dank Process-Mining wettbewerbsfähiger, innovativer und damit langfristig erfolgreicher werden.