Geschriebene Artikel über Big Data Analytics

Interview Benjamin Aunkofer - Business Intelligence und Process Mining ohne Vendor-Lock-In
Redaktion

Interview – Business Intelligence und Process Mining ohne Vendor Lock-in!

/in , , , , /by

Das Format Business Talk am Kudamm in Berlin führte ein Interview mit Benjamin Aunkofer zum Thema “Business Intelligence und Process Mining nachhaltig umsetzen”.

In dem Interview erklärt Benjamin Aunkofer, was gute Business Intelligence und Process Mining ausmacht und warum Unternehmen in jedem Fall daran arbeiten sollten, den gefürchteten Vendor Lock-In zu vermeiden, der gerade insbesondere bei Process Mining droht, jedoch leicht vermeidbar ist.

Nachfolgend das Interview auf Youtube sowie die schriftliche Form zum Nachlesen:


Interview – Process Mining, Business Intelligence und Vendor Lock

1 – Herr Aunkofer, wir wollen uns heute über Best Practice bei der Verarbeitung von Daten unterhalten. Welche Fehler sollten Unternehmen unbedingt vermeiden, wenn sie ihre Daten zur Modellierung aufbereiten?

Mittlerweile weiß ja bereits jeder Laie, dass die Datenaufbereitung und -Modellierung einen Großteil des Arbeitsaufwandes in der Datenanalyse einnehmen, sei es nun für Business Intelligence, also Reporting, oder für Process Mining. Für Data Science ja sowieso. Vor einen Jahrzehnt war es immer noch recht üblich, sich einfach ein BI Tool zu nehmen, sowas wie QlikView, Tableau oder PowerBI, mittlerweile gibt es ja noch einige mehr, und da direkt die Daten reinzuladen und dann halt loszulegen mit dem Aufbau der Reports.

Schon damals in Ansätzen, aber spätestens heute gilt es zu recht als Best Practise, die Datenanbindung an ein Data Warehouse zu machen und in diesem die Daten für die Reports aufzubereiten. Ein Data Warehouse ist eine oder eine Menge von Datenbanken.

Das hat den großen Vorteil, dass die Daten auf einer Ebene modelliert werden, für die es viele Experten gibt und die technologisch auch sehr mächtig ist, nicht auf ein Reporting Tool beschränkt ist.
Außerdem veraltet die Datenbanktechnologie nur sehr viel langsamer als die ganzen Tools, in denen Analysen stattfinden.

Im Process Mining sind ja nun noch viele Erstinitiativen aktiv und da kommen die Unternehmen nun erst so langsam auf den Trichter, dass so ein Data Warehouse hier ebenfalls sinnvoll ist. Und sie liegen damit natürlich vollkommen richtig.

2 – Warum ist es so wichtig einen Vendor Lock zu umgehen?

Na die ganze zuvor genannte Arbeit für die Datenaufbereitung möchte man keinesfalls in so einem Tool haben, das vor allem für die visuelle Analyse gemacht wird und viel schnelleren Entwicklungszyklen sowie einem spannenden Wettbewerb unterliegt. Sind die ganzen Anbindungen der Datenquellen, also z. B. dem ERP, CRM usw., sowie die Datenmodelle für BI oder Process Mining direkt an das Tool gebunden, dann fällt es schwer z. B. von PowerBI nach Tableau oder SuperSet zu wechseln, von Celonis nach Signavio oder welches Tool auch immer. Die Migrationsaufwände sind dann ein ziemlicher Showstopper.

Bei Datenbanken sind Migrationen auch nicht immer ein Spaß, die Aufwände jedoch absehbarer und vor allem besteht selten die Notwendigkeit dazu, die Datenbanktechnologie zu wechseln. Das ist quasi die neutrale Zone.

3 – Bei der Nutzung von Daten fallen oft die Begriffe „Process Mining“ und „Business Intelligence“. Was ist darunter zu verstehen und was sind die Unterschiede zwischen PM und BI?

Business Intelligence, oder BI, geht letztendlich um die zur Verfügungstellung von guten Reports für das Management bis hin zu jeden Mitarbeiter des Unternehmens, manchmal aber sogar bis zum Kunden oder Lieferanten, die in Unternehmensprozesse inkludiert werden sollen. BI ist gewissermaßen schon seit zwei Jahrzehnten ein Trend, entwickelt sich aber auch immer weiter, mit immer größeren Datenmengen, in Echtzeit usw.

Process Mining ist im Grunde eng mit der BI verwandt, man kann auch sagen, dass es ein BI für Prozessanalysen ist. Bei Process Mining nehmen wir uns die Log-Daten von operativen IT-Systemen vor, in denen Unternehmensprozesse erfasst sind. Vornehmlich ERP-Systeme, CRM-Systeme, Dokumentenmangement-Systeme usw.
Die Daten bereiten wir in sogenannte Event Logs, also Prozessprotokolle, auf und laden sie dann ein eines der vielen Process Mining Tools, egal in welches. In diesen Tools kann man dann Prozess wirklich visuell betrachten, filtern und analysieren, rekonstruiert aus den Daten, spiegeln sie die tatsächlichen operativen Vorgänge wieder.

Auch bei Process Mining tut sich gerade viel, Machine Learning hält Einzug ins Process Mining, Prozesse können immer granularer analysiert werden, auch unstrukturierte Daten können unter Einsatz von AI mit in die Analyse einbezogen werden usw.
Der Markt bereinigt sich übrigens auch dadurch, dass Tool für Tool von größeren Software-Häusern aufgekauft werden. Also der Tool-Markt ist gerade ganz krass im Wandel und das wird die nächsten Jahre auch so bleiben.

4 – Wie ist denn die Best Practice bei der Speicherung, Aufbereitung und Modellierung von Daten?

BI und Process Mining sind eigentlich eher Methoden der Datenanalytik als einfach nur Tools. Es ist ein komplexes System. Ganz klar hierfür ist der Aufbau eines Data Warehouses, dass aus Datensicht quasi so eine Art Middleware ist und Daten zentral allen Tools bereitstellt. Viele Unternehmen haben ja um einiges mehr als nur ein Tool im Haus, die kann man dann auch alle weiterhin nutzen.

Was gerade zum Trend wird, ist der Aufbau eines Data Lakehouses. Ein Lakehouse inkludiert auch clevere Art und Weise auch einen Data Lake.

Den Unterschied kann man sich wie folgt vorstellen: Ein Data Warehouse ist wie das Regel zu Hause mit den Ordnern zum Abheften aller wichtigen Dokumente, geordnet nach … Ordner, Rubrik, Sortierung nach Datum oder alphabetisch. Allerdings macht es auch große Mühe, diese Struktur zu verwalten, alles ordentlich abzuheften und sich überhaupt erstmal eine Logik dafür zu erarbeiten. Ein Data Lake ist dann sowas wie die eine böse Schublade, die man eigentlich gar nicht haben möchte, aber in die man dann alle Briefe, Dokumente usw. reinwirft, bei denen man nicht weiß, ob man diese noch braucht. Die Inhalte des Data Lakes sind bestenfalls etwas vorsortiert, aber eigentlich hofft man ja nicht, da wieder irgendwas drin wiederfinden zu müssen.

5 – Sie haben ja einen guten Marktüberblick: Wie gut sind deutsche Unternehmen in diesen Bereichen aufgestellt?

Grundsätzlich schon mal gar nicht so schlecht, wie oft propagiert wird. In beinahe jedem deutschen Unternehmen existiert mittlerweile ein Data Warehouse sowie Initiativen zur Einführung von BI, Process Mining und Data Science bzw. KI, in Konzernen natürlich stets mehrere. Was ich oft vermisse, ist so eine gesamtheitliche Sicht auf die Dinge, es gibt ja viele Nischenexperten, die sich auf eines dieser Themen stürzen, es aber nicht in Verbindung zu den anderen Themen betrachten. Z. B. steht auch KI nicht für sich alleine, sondern kann sowohl der Business Intelligence als auch Process Mining über den Querverweis befähigen, z. B. zur Berücksichtigung von unstrukturierten Daten, oder ausbauen mit Vorhersagen, z. B. Umsatz-Forecasts. Das ist alles eine Datenevolution, vom ersten Report von Unternehmenskennzahlen über die Analyse von Prozessen bis hin zu KI-getriebenen Vorhersagesystemen.

6 – Wo sehen Sie den größten Nachholbedarf?

Da mache ich es kurz: Unternehmen brauchen Datenstrategien und ein Big Picture, wie sie Daten richtig nutzen, dabei dann auch die unterschiedlichen Methoden der Nutzung dieser Daten richtig kombinieren.

Sehen Sie die zwei anderen Video-Interviews von Benjamin Aunkofer:

Interview Benjamin Aunkofer – Datenstrategien und Data Teams entwickeln!

 

 

 

 

 

 

 

Cloud Data Platform for Shopfloor Management
Benjamin Aunkofer

How Cloud Data Platforms improve Shopfloor Management

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

In the era of Industry 4.0, linking data from MES (Manufacturing Execution System) with that from ERP, CRM and PLM systems plays an important role in creating integrated monitoring and control of business processes.

ERP (Enterprise Resource Planning) systems contain information about finance, supplier management, human resources and other operational processes, while CRM (Customer Relationship Management) systems provide data about customer relationships, marketing and sales activities. PLM (Product Lifecycle Management) systems contain information about products, development, design and engineering.

By linking this data with the data from MES, companies can obtain a more complete picture of their business operations and thus achieve better monitoring and control of their business processes. Of central importance here are the OEE (Overall Equipment Effectiveness) KPIs that are so important in production, as well as the key figures from financial controlling, such as contribution margins. The fusion of data in a central platform enables smooth analysis to optimize processes and increase business efficiency in the world of Industry 4.0 using methods from business intelligence, process mining and data science. Companies also significantly increase their enterprise value with the linking of this data, thanks to the data and information transparency gained.

Cloud Data Platform for shopfloor management and data sources such like MES, ERP, PLM and machine data.

Cloud Data Platform for shopfloor management and data sources such like MES, ERP, PLM and machine data. Copyright by DATANOMIQ.

If the data sources are additionally expanded to include the machines of production and logistics, much more in-depth analyses for error detection and prevention as well as for optimizing the factory in its dynamic environment become possible. The machine sensor data can be monitored directly in real time via respective data pipelines (real-time stream analytics) or brought into an overall picture of aggregated key figures (reporting). The readers of this data are not only people, but also individual machines or entire production plants that can react to this data.

As a central data architecture there are dozens of analytical applications which can be fed with data:

– OEE key figures for Shopfloor reporting
– Process Mining (e.g. material flow analysis) for manufacturing and supply chain.
– Detection of anomalies on the shopfloor or on individual machines.
– Predictive maintenance for individual machines or entire production lines.

This solution scales completely automatically in terms of both performance and cost. It looks beyond individual problems since it offers universal and flexible scope for action. In other words, it will result in a “god mode” for the management being able to drill-down from a specific client project to insights into single machines involved into each project.

Are you interested in scalable data architectures for your shopfloor management? Or would you like to discuss a specific problem with us? Or maybe you are interested in an individual data strategy? Then get in touch with me! 🙂

Edward Huskin

Phishing: An Overlooked Threat to Business and Data

/in /by

Data is the lifeblood of an organization and businesses that fail to embrace this fundamental concept risk losing future business opportunities or the company itself. The value of business and consumer data hasn’t been lost on cybercriminals, which is why phishing attacks and other data security threats have been more rampant through the years. As data technology becomes more advanced, reliance on data becomes a more significant opportunity for exploitation as even the most advanced data systems have their vulnerabilities. Businesses collect and process large amounts of data from several sources, making the protection of this data one of their main challenges.

The Threat to Business and Data

Today’s businesses demand a lot from the data they collect, and as such, also look for solutions that will help transform data into more tangible bits and pieces that will help promote business success. The role of AI in cybersecurity has been gaining mainstream attention because it helps automate the detection of security threats and other malicious activities within a company’s systems. 

Looking to more advanced solutions for cybersecurity is a prudent approach, and is highly recommended, especially for businesses that handle large amounts of data daily. Cybersecurity threats are no laughing matter, and they’re becoming more advanced and difficult to identify and address. The end goal remains the same, however—to gain unauthorized access to data and use it to harm a business or for personal gain. The threats come in many forms, including DDoS attacks, malware, and phishing attacks.

Cybersecurity threats are serious not only due to the potential loss of data but also because a data breach can cause irreparable harm to a business. Give cybercriminals access to sensitive data and there’s no telling what damage they’ll cause. Even a simple phishing scam can lead to a full-blown data breach, and these breaches rely on users making mistakes. 

Recognizing Phishing Scams

Before businesses can combat scams, they must train their employees on the detection and proper ways of addressing or preventing them altogether. Below are the most common types of phishing attacks done against businesses.

Phishing Emails

Phishing emails are common in a business email inbox—typically categorized together with spam emails. The difference is that they are not simply unsolicited marketing messages; they are designed to trick you into opening a malicious attachment or clicking on a link to a fraudulent website. Scammers often use an email address that resembles a legitimate business email address to confuse users into thinking that the email came from someone within the organization or a trusted partner or a third party.

Company Impersonation

This method is a type of phishing scam in which scammers try to impersonate your brand. This is often done via “domain spoofing” or using a fake but similar website or email domain designed to confuse the recipients of the email. It can be difficult to detect as a source of a data breach because it’s often unreported. Victims of these scams often aren’t aware that they’ve been duped until it’s too late.

Phone Phishing/Voice Phishing

This is similar to company impersonation but uses a different medium—Voice over Internet Protocol (VoIP). Most scammers who use this method go so far as to imitate the tone of voice and spiels of the brands they’re trying to impersonate. This is usually done in conjunction with other phishing scams to increase the chances of success.

Spear phishing

This is similar to phishing emails but with a more targeted approach. It involves more effort on the scammers’ part because it entails getting key information about a target. Using this method, the scammers send an email containing the name of a company officer and other personalizations to make the recipient believe that the email is legitimate. Unsuspecting users will be duped into sending money, pertinent information, or making payments to a fake vendor or partner. It’s a sophisticated scam that can often trick even tech-savvy individuals, depending on how skillfully the fake email message is crafted.

Email Account Takeover

It’s one thing to have scammers send fake emails and try to make them look legitimate, but it’s another when they get access to a legitimate email account and use it to get money from unsuspecting users, gain access to sensitive information, or cause harm to a business. It’s typically done as part of a cross-account takeover, in which a scammer gains access to a user’s email account, changes the password, and proceeds to make fund transfers from the compromised user’s bank and other financial accounts.

Why Cyberattackers Resort to Phishing Scams

Phishing scams are one of the most common cyberattacks that threaten the security of the company and personal data, with spear phishing being one of the main infection vectors. It’s a common scam because phishing is as easy; anyone can execute a phishing attack and be relatively successful with little to no investment. The flexibility of a phishing scam also makes it an infection vector of choice. With it, a scammer can steal sensitive data and gain access to user accounts.

The simplicity-to-value ratio is also a tempting draw of phishing. Despite how simple its execution is, it can help cybercriminals get their hands on large sums of money. $17,700 is lost every minute because of a phishing scam.

Lastly, users aren’t good at putting a stop to scams—even large companies face the threat of phishing today. Because of how sophisticated these phishing emails have become and the large number of emails people have to go through each day, it can distinguish a fake email from a real one. 

Fighting the Good Fight

Despite the evolving threats to data security, there are still ways you can fight them. Just like cybercriminals always find vulnerabilities to exploit, you can always find ways to mitigate or even counteract these measures. The key is in keeping an open eye and mind and keeping abreast of the available solutions that can help you keep your data and business secure. Protecting your digital assets often requires “digital measures.” It won’t hurt to let digital tools help you, but you and your organization should be at the heart of your data security. Educate yourself and your employees so your security isn’t only as good as the tool you choose to use.

Benjamin Aunkofer - Interview über AI as a Service
Redaktion

Interview – Daten vermarkten, nicht verkaufen!

/in , , , , , /by

Das Format Business Talk am Kudamm in Berlin führte ein Interview mit Benjamin Aunkofer zu den Themen “Daten vermarkten, nicht verkaufen!”.

In dem Interview erklärt Benjamin Aunkofer, warum der Datenschutz für die meisten Anwendungsfälle keine Rolle spielt und wie Unternehmen mit Data as a Service oder AI as a Service Ihre Daten zu Geld machen, selbst dann, wenn diese Daten nicht herausgegeben werden können.

Nachfolgend das Interview auf Youtube sowie die schriftliche Form zum Nachlesen:


Nachfolgend das Transkript zum Interview:

1 – Herr Aunkofer, Daten gelten als der wichtigste Rohstoff des 22. Jahrhunderts. Bei der Vermarktung datengestützter Dienstleistung tun sich deutsche Unternehmen im Vergleich zur Konkurrenz aus den USA oder Asien aber deutlich schwerer. Woran liegt das?

Ach da will ich keinen Hehl draus machen. Die Unterschiede liegen in den verschiedenen Kulturen begründet. In den USA herrscht in der Gesellschaft ein sehr freiheitlicher Gedanke, der wohl eher darauf hinausläuft, dass wer Daten sammelt, über diese dann eben auch weitgehend verfügt.

In Asien ist die Kultur eher kollektiv ausgerichtet, um den Einzelnen geht es dort ja eher nicht so.

In Deutschland herrscht auch ein freiheitlicher Gedanke – Gott sei Dank – jedoch eher um den Schutz der personenbezogenen Daten.

Das muss nun aber gar nicht schlimm sein. Zwar mag es in Deutschland etwas umständlicher und so einen Hauch langsamer sein, Daten nutzen zu dürfen. Bei vielen Anwendungsfällen kann man jedoch sehr gut mit korrekt anonymisierten Massendaten arbeiten und bei gesellschaftsfördernen Anwendungsfällen, man denke z. B. an medizinische Vorhersagen von Diagnosen oder Behandlungserfolgen oder aber auch bei der Optimierung des öffentlichen Verkehrs, sind ja viele Menschen durchaus bereit, ihre Daten zu teilen.

 Gesellschaftlichen Nutzen haben wir aber auch im B2B Geschäft, bei dem wir in Unternehmen und Institutionen die Prozesse kundenorientierter und schneller machen, Maschinen ausfallsicherer machen usw.. Da haben wir meistens sogar mit gar keinen personenbezogenen Daten zu tun.

2 – Sind die Bedenken im Zusammenhang mit Datenschutz und dem Schutz von Geschäftsgeheimnissen nicht berechtigt?

Also mit Datenschutz ist ja der gesetzliche Datenschutz gemeint, der sich nur auf personenbezogene Daten bezieht. Für Anwendungsfälle z. B. im Customer Analytics, also da, wo man Kundendaten analysieren möchte, geht das nur über die direkte Einwilligung oder eben durch anonymisierte Massendaten. Bei betrieblicher Prozessoptimierung, Anlagenoptimierung hat man mit personenbezogenen Daten aber fast nicht zu tun bzw. kann diese einfach vorher wegfiltern.

Ein ganz anderes Thema ist die Datensicherheit. Diese schließt die Sicherheit von personenbezogenen Daten mit ein, betrifft aber auch interne betriebliche Angelegenheiten, so wie etwas Lieferanten, Verträge, Preise… vielleicht Produktions- und Maschinendaten, natürlich auch Konstruktionsdaten in der Industrie.

Dieser Schutz ist jedoch einfach zu gewährleisten, wenn man einige Prinzipien der Datensicherheit verfolgt. Wir haben dafür Checklisten, quasi wie in der Luftfahrt. Bevor der Flieger abhebt, gehen wir die Checks durch… da stehen so Sachen drauf wie Passwortsicherheit, Identity Management, Zero Trust, Hybrid Cloud usw.

3 – Das Rückgrat der deutschen Wirtschaft sind die vielen hochspezialisierten KMU. Warum sollte sich beispielsweise ein Maschinenbauer darüber Gedanken machen, datengestützte Geschäftsmodelle zu entwickeln?

Nun da möchte ich dringend betonen, dass das nicht nur für Maschinenbauer gilt, aber es stimmt schon, dass Unternehmen im Maschinenbau, in der Automatisierungstechnik und natürlich der Werkzeugmaschinen richtig viel Potenzial haben, ihre Geschäftsmodelle mit Daten auszubauen oder sogar Datenbestände aufzubauen, die dann auch vermarktet werden können, und das so, dass diese Daten das Unternehmen gar nicht verlassen und dabei geheim bleiben.

4 – Daten verkaufen, ohne diese quasi zu verkaufen? Wie kann das funktionieren?

Das verrate ich gleich, aber reden wir vielleicht kurz einmal über das Verkaufen von Daten, die man sogar gerne verkauft. Das Verkaufen von Daten ist nämlich gerade so ein Trend. Das Konzept dafür heißt Data as a Service und bezieht sich dabei auf öffentliche Daten aus Quellen der Kategorie Open Data und Public Data. Diese Daten können aus dem Internet quasi gesammelt, als Datenbasis dann im Unternehmen aufgebaut werden und haben durch die Zusammenführung, Bereinigung und Aufbereitung einen Wert, der in die Millionen gehen kann. Denn andere Unternehmen brauchen vielleicht auch diese Daten, wollen aber nicht mehr warten, bis sie diese selbst aufbauen. Beispiele dafür sind Daten über den öffentlichen Verkehr, Infrastruktur, Marktpreise oder wir erheben z. B. für einen Industriekonzern Wasserqualitätsdaten beinahe weltweit aus den vielen vielen regionalen Veröffentlichungen der Daten über das Trinkwasser. Das sind zwar hohe Aufwände, aber der Wert der zusammengetragenen Daten ist ebenfalls enorm und kann an andere Unternehmen weiterverkauft werden. Und nur an jene Unternehmen, an die man das eben zu tun bereit ist.

5 – Okay, das sind öffentliche Daten, die von Unternehmen nutzbar gemacht werden. Aber wie ist es nun mit Daten aus internen Prozessen?

Interne Daten sind Geschäftsgeheimnisse und dürfen keinesfalls an Dritte weitergegeben werden. Dazu gehören beispielsweise im Handel die Umsatzkurven für bestimmte Produktkategorien sowie aber auch die Retouren und andere Muster des Kundenverhaltens, z. B. die Reaktion auf die Konfiguration von Online-Marketingkampagnen. Die Unternehmen möchten daraus jedoch Vorhersagemodelle oder auch komplexere Anomalie-Erkennung auf diese Daten trainieren, um sie für sich in ihren operativen Prozessen nutzbar zu machen. Machine Learning, übrigens ein Teilgebiet der KI (Künstlichen Intelligenz), funktioniert ja so, dass man zwei Algorithmen hat. Der erste Algorithmus ist ein Lern-Algorithmus. Diesen muss man richtig parametrisieren und überhaupt erstmal den richtigen auswählen, es gibt nämlich viele zur Auswahl und ja, die sind auch miteinander kombinierbar, um gegenseitige Schwächen auszugleichen und in eine Stärke zu verwandeln. Der Lernalgorithmus erstellt dann, über das Training mit den Daten, ein Vorhersagemodell, im Grunde eine Formel. Das ist dann der zweite Algorithmus. Dieser Algorithmus entstand aus den Daten und reflektiert auch das in den Daten eingelagerte Wissen, kanalisiert als Vorhersagemodell. Und dieses kann dann nicht nur intern genutzt werden, sondern auch anderen Unternehmen zur Nutzung zur Verfügung gestellt werden.

6 – Welche Arten von Problemen sind denn geeignet, um aus Daten ein neues Geschäftsmodell entwickeln zu können?

Alle operativen Geschäftsprozesse und deren Unterformen, also z. B. Handels-, Finanz-, Produktions- oder Logistikprozesse generieren haufenweise Daten. Das Problem für ein Unternehmen wie meines ist ja, dass wir zwar Analysemethodik kennen, aber keine Daten. Die Daten sind quasi wie der Inhalt einer Flasche oder eines Ballons, und der Inhalt bestimmt die Form mit. Unternehmen mit vielen operativen Prozessen haben genau diese Datenmengen.Ein Anwendungsfallgebiet sind z. B. Diagnosen. Das können neben medizinischen Diagnosen für Menschen auch ganz andere Diagnosen sein, z. B. über den Zustand einer Maschine, eines Prozesses oder eines ganzen Unternehmens. Die Einsatzgebiete reichen von der medizinischen Diagnose bis hin zu der Diagnose einer Prozesseffizienz oder eines Zustandes in der Wirtschaftsprüfung.Eine andere Kategorie von Anwendungsfällen sind die Prädiktionen durch Text- oder Bild-Erkennung. In der Versicherungsindustrie oder in der Immobilienbranche B. gibt es das Geschäftsmodell, dass KI-Modelle mit Dokumenten trainiert werden, so dass diese automatisiert, maschinell ausgelesen werden können. Die KI lernt dadurch, welche Textstellen im Dokument oder welche Objekte im Bild eine Rolle spielen und verwandelt diese in klare Aussagen.

Die Industrie benutzt KI zur generellen Objekterkennung z. B. in der Qualitätsprüfung. Hersteller von landwirtschaftlichen Maschinen trainieren KI, um Unkraut über auf Videobildern zu erkennen. Oder ein Algorithmus, der gelernt hat, wie Ultraschalldaten von Mirkochips zu interpretieren sind, um daraus Beschädigungen zu erkennen, so als Beispiel, den kann man weiterverkaufen.

Das Verkaufen erfolgt dabei idealerweise hinter einer technischen Wand, abgeschirmt über eine API. Eine API ist eine Schnittstelle, über die man die KI verwenden kann. Daraus wird dann AI as a Service, also KI als ein Service, den man Dritten gegen Bezahlung nutzen lassen kann.

7 – Gehen wir mal in die Praxis: Wie lassen sich aus erhobenen Daten Modelle entwickeln, die intern genutzt oder als Datenmodell an Kunden verkauft werden können?

Zuerst müssen wir die Idee natürlich richtig auseinander nehmen. Nach einer kurzen Euphorie-Phase, wie toll die Idee ist, kommt ja dann oft die Ernüchterung. Oft überwinden wir aber eben diese Ernüchterung und können starten. Der einzige Knackpunkt sind meistens fehlende Daten, denn ja, wir reden hier von großen Datenhistorien, die zum Einen überhaupt erstmal vorliegen müssen, zum anderen aber auch fast immer aufbereitet werden müssen.Wenn das erledigt ist, können wir den Algorithmus trainieren, ihn damit auf eine bestimmte Problemlösung sozusagen abrichten.Übrigens können Kunden oder Partner die KI selbst nachtrainieren, um sie für eigene besondere Zwecke besser vorzubereiten. Nehmen wir das einfache Beispiel mit der Unkrauterkennung via Bilddaten für landwirtschaftliche Maschinen. Nun sieht Unkraut in fernen Ländern sicherlich ähnlich, aber doch eben anders aus als hier in Mitteleuropa. Der Algorithmus kann jedoch nachtrainiert werden und sich der neuen Situation damit anpassen. Hierfür sind sehr viel weniger Daten nötig als es für das erstmalige Anlernen der Fall war.

8 – Viele Unternehmen haben Bedenken wegen des Zeitaufwands und der hohen Kosten für Spezialisten. Wie hoch ist denn der Zeit- und Kostenaufwand für die Implementierung solcher KI-Modelle in der Realität?

Das hängt sehr stark von der eigentlichen Aufgabenstellung ab, ob die Daten dafür bereits vorliegen oder erst noch generiert werden müssen und wie schnell das alles passieren soll. So ein Projekt dauert pauschal geschätzt gerne mal 5 bis 8 Monate bis zur ersten nutzbaren Version.

Sehen Sie die zwei anderen Video-Interviews von Benjamin Aunkofer:

 

 

 

 

 

 

 

Benjamin Aunkofer

Jobprofil des Data Engineers

/in , , , , /by

Warum Data Engineering der Data Science in Bedeutung und Berufschancen längst die Show stiehlt, dabei selbst ebenso einem stetigen Wandel unterliegt.

Was ein Data Engineer wirklich können muss

Der Data Scientist als sexiest Job des 21. Jahrhunderts? Mag sein, denn der Job hat seinen ganz speziellen Reiz, auch auf Grund seiner Schnittstellenfunktion zwischen Technik und Fachexpertise. Doch das Spotlight der kommenden Jahre gehört längst einem anderen Berufsbild aus der Datenwertschöpfungskette – das zeigt sich auch bei den Gehältern.

Viele Unternehmen sind gerade auf dem Weg zum Data-Driven Business, einer Unternehmensführung, die für ihre Entscheidungen auf transparente Datengrundlagen setzt und unter Einsatz von Business Intelligence, Data Science sowie der Automatisierung mit Deep Learning und RPA operative Prozesse so weit wie möglich automatisiert. Die Lösung für diese Aufgabenstellungen werden oft vor allem bei den Experten für Prozessautomatisierung und Data Science gesucht, dabei hängt der Erfolg jedoch gerade viel eher von der Beschaffung valider Datengrundlagen ab, und damit von einer ganz anderen entscheidenden Position im Workflow datengetriebener Entscheidungsprozesse, dem Data Engineer.

Data Engineer, der gefragteste Job des 21sten Jahrhunderts?

Der Job des Data Scientists hingegen ist nach wie vor unter Studenten und Absolventen der MINT-Fächer gerade so gefragt wie nie, das beweist der tägliche Ansturm der vielen Absolventen aus Studiengängen rund um die Data Science auf derartige Stellenausschreibungen. Auch mangelt es gerade gar nicht mehr so sehr an internationalen Bewerben mit Schwerpunkt auf Statistik und Machine Learning. Der solide ausgebildete und bestenfalls noch deutschsprachige Data Scientist findet sich zwar nach wie vor kaum im Angebot, doch insgesamt gute Kandidaten sind nicht mehr allzu schwer zu finden. Seit Jahren sind viele Qualifizierungsangebote für Studenten sowie Arbeitskräfte am Markt auch günstig und ganz flexibel online verfügbar, ohne dabei Abstriche bei beim Ansehen dieser Aus- und Fortbildungsmaßnahmen in Kauf nehmen zu müssen.

Was ein Data Scientist fachlich in Sachen Expertise alles abdecken muss, hatten wir ganz ausführlich über Betrachtung des Data Science Knowledge Stack besprochen.

Doch was bringt ein Data Scientist, wenn dieser gar nicht über die Daten verfügt, die für seine Aufgaben benötigt werden? Sicherlich ist die Aufgabe eines jeden Data Scientists auch die Vorbereitung und Präsentation seiner Vorhaben. Die Heranschaffung und Verwaltung großer Datenmengen in einer Enterprise-fähigen Architektur ist jedoch grundsätzlich nicht sein Schwerpunkt und oft fehlen ihm dafür auch die Berechtigungen in einer Enterprise-IT. Noch konkreter wird der Bedarf an Datenbeschaffung und -aufbereitung in der Business Intelligence, denn diese benötigt für nachhaltiges Reporting feste Strukturen wie etwa ein Data Warehouse.

Das Profil des Data Engineers: Big Data High-Tech

Auch wenn Data Engineering von Hochschulen und Fortbildungsanbietern gerade noch etwas stiefmütterlich behandelt werden, werden der Einsatz und das daraus resultierende Anforderungsprofil eines Data Engineers am Markt recht eindeutig skizziert. Einsatzszenarien für diese Dateningenieure – auch auf Deutsch eine annehmbare Benennung – sind im Kern die Erstellung von Data Warehouse und Data Lake Systeme, mittlerweile vor allem auf Cloud-Plattformen. Sie entwickeln diese für das Anzapfen von unternehmensinternen sowie -externen Datenquellen und bereiten die gewonnenen Datenmengen strukturell und inhaltlich so auf, dass diese von anderen Mitarbeitern des Unternehmens zweckmäßig genutzt werden können.

Enabler für Business Intelligence, Process Mining und Data Science

Kein Data Engineer darf den eigentlichen Verbraucher der Daten aus den Augen verlieren, für den die Daten nach allen Regeln der Kunst zusammengeführt, bereinigt und in das Zielformat gebracht werden sollen. Klassischerweise arbeiten die Engineers am Data Warehousing für Business Intelligence oder Process Mining, wofür immer mehr Event Logs benötigt werden. Ein Data Warehouse ist der unter Wasser liegende, viel größere Teil des Eisbergs der Business Intelligence (BI), der die Reports mit qualifizierten Daten versorgt. Diese Eisberg-Analogie lässt sich auch insgesamt auf das Data Engineering übertragen, der für die Endanwender am oberen Ende der Daten-Nahrungskette meistens kaum sichtbar ist, denn diese sehen nur die fertigen Analysen und nicht die dafür vorbereiteten Datentöpfe.

Abbildung 1 - Data Engineering ist der Mittelpunkt einer jeden Datenplattform. Egal ob für Data Science, BI, Process Mining oder sogar RPA, die Datenanlieferung bedingt gute Dateningenieure, die bis hin zur Cloud Infrastructure abtauchen können.

Abbildung 1 – Data Engineering ist der Mittelpunkt einer jeden Datenplattform. Egal ob für Data Science, BI, Process Mining oder sogar RPA, die Datenanlieferung bedingt gute Dateningenieure, die bis hin zur Cloud Infrastructure abtauchen können.

Datenbanken sind Quelle und Ziel der Data Engineers

Daten liegen selten direkt in einer einzigen CSV-Datei strukturiert vor, sondern entstammen einer oder mehreren Datenbanken, die ihren eigenen Regeln unterliegen. Geschäftsdaten, beispielsweise aus ERP- oder CRM-Systemen, liegen in relationalen Datenbanken vor, oftmals von Microsoft, Oracle, SAP oder als eine Open-Source-Alternative. Besonders im Trend liegen derzeitig die Cloud-nativen Datenbanken BigQuery von Google, Redshift von Amazon und Synapse von Microsoft sowie die cloud-unabhängige Datenbank snowflake. Dazu gesellen sich Datenbanken wie der PostgreSQL, Maria DB oder Microsoft SQL Server sowie CosmosDB oder einfachere Cloud-Speicher wie der Microsoft Blobstorage, Amazon S3 oder Google Cloud Storage. Welche Datenbank auch immer die passende Wahl für das Unternehmen sein mag, ohne SQL und Verständnis für normalisierte Daten läuft im Data Engineering nichts.

Andere Arten von Datenbanken, sogenannte NoSQL-Datenbanken beruhen auf Dateiformaten, einer Spalten- oder einer Graphenorientiertheit. Beispiele für verbreitete NoSQL-Datenbanken sind MongoDB, CouchDB, Cassandra oder Neo4J. Diese Datenbanken exisiteren nicht nur als Unterhaltungswert gelangweilter Nerds, sondern haben ganz konkrete Einsatzgebiete, in denen sie jeweils die beste Performance im Lesen oder Schreiben der Daten bieten.

Ein Data Engineer muss demnach mit unterschiedlichen Datenbanksystemen zurechtkommen, die teilweise auf unterschiedlichen Cloud Plattformen heimisch sind.

Data Engineers brauchen Hacker-Qualitäten

Liegen Daten in einer Datenbank vor, können Analysten mit Zugriff einfache Analysen bereits direkt auf der Datenbank ausführen. Doch wie bekommen wir die Daten in unsere speziellen Analyse-Tools? Hier muss der Engineer seinen Dienst leisten und die Daten aus der Datenbank exportieren können. Bei direkten Datenanbindungen kommen APIs, also Schnittstellen wie REST, ODBC oder JDBC ins Spiel und ein guter Data Engineer benötigt Programmierkenntnisse, bevorzugt in Python, diese APIs ansprechen zu können. Etwas Kenntnis über Socket-Verbindungen und Client-Server-Architekturen zahlt sich dabei manchmal aus. Ferner sollte jeder Data Engineer mit synchronen und asynchronen Verschlüsselungsverfahren vertraut sein, denn in der Regel wird mit vertraulichen Daten gearbeitet. Ein Mindeststandard an Sicherheit gehört zum Data Engineering und darf keinesfalls nur Datensicherheitsexperten überlassen werden, eine Affinität zu Netzwerksicherheit oder gar Penetration-Testing ist positiv zu bewerten, mindestens aber ein sauberes Berechtigungsmanagement gehört zu den Grundfähigkeiten. Viele Daten liegen nicht strukturiert in einer Datenbank vor, sondern sind sogenannte unstrukturierte oder semi-strukturierte Daten aus Dokumenten oder aus Internetquellen. Mit Methoden wie Data Web Scrapping und Data Crawling sowie der Automatisierung von Datenabrufen beweisen herausragende Data Engineers sogar echte Hacker-Qualitäten.

Dirigent der Daten: Orchestrierung von Datenflüssen

Eine der Kernaufgaben des Data Engineers ist die Entwicklung von ETL-Strecken, um Daten aus Quellen zu Extrahieren, zu in das gewünschte Zielformat zu Transformieren und schließlich in die Zieldatenbank zu Laden. Dies mag erstmal einfach klingen, wird jedoch zur echten Herausforderung, wenn viele ETL-Prozesse sich zu ganzen ETL-Ketten und -Netzwerken zusammenfügen, diese dabei trotz hochfrequentierter Datenabfrage performant laufen müssen. Die Orchestrierung der Datenflüsse kann in der Regel in mehrere Etappen unterschieden werden, von der Quelle ins Data Warehouse, zwischen den Ebenen im Data Warehouse sowie vom Data Warehouse in weiterführende Systeme, bis hin zum Zurückfließen verarbeiteter Daten in das Data Warehouse (Reverse ETL).

Hart an der Grenze zu DevOp: Automatisierung in Cloud-Architekturen

In den letzten Jahren sind Anforderungen an Data Engineers deutlich gestiegen, denn neben dem eigentlichen Verwalten von Datenbeständen und -strömen für Analysezwecke wird zunehmend erwartet, dass ein Data Engineer auch Ressourcen in der Cloud managen, mindestens jedoch die Datenbanken und ETL-Ressourcen. Darüber hinaus wird zunehmend jedoch verlangt, IT-Netzwerke zu verstehen und das ganze Zusammenspiel der Ressourcen auch als Infrastructure as Code zu automatisieren. Auch das automatisierte Deployment von Datenarchitekturen über CI/CD-Pipelines macht einen Data Engineer immer mehr zum DevOp.

Zukunfts- und Gehaltsaussichten

Im Vergleich zum Data Scientist, der besonders viel Methodenverständnis für Datenanalyse, Statistik und auch für das zu untersuchende Fachgebiet benötigt, sind Data Engineers mehr an Tools und Plattformen orientiert. Ein Data Scientist, der Deep Learning verstanden hat, kann sein Wissen zügig sowohl mit TensorFlow als auch mit PyTorch anwenden. Ein Data Engineer hingegen arbeitet intensiver mit den Tools, die sich über die Jahre viel zügiger weiterentwickeln. Ein Data Engineer für die Google Cloud wird mehr Einarbeitung benötigen, sollte er plötzlich auf AWS oder Azure arbeiten müssen.

Ein Data Engineer kann in Deutschland als Einsteiger mit guten Vorkenntnissen und erster Erfahrung mit einem Bruttojahresgehalt zwischen 45.000 und 55.000 EUR rechnen. Mehr als zwei Jahre konkrete Erfahrung im Data Engineering wird von Unternehmen gerne mit Gehältern zwischen 50.000 und 80.000 EUR revanchiert. Darüber liegen in der Regel nur die Data Architects / Datenarchitekten, die eher in großen Unternehmen zu finden sind und besonders viel Erfahrung voraussetzen. Weitere Aufstiegschancen für Data Engineers sind Berater-Karrieren oder Führungspositionen.

Wer einen Data Engineer in Festanstellung gebracht hat, darf sich jedoch nicht all zu sicher fühlen, denn Personalvermittler lauern diesen qualifizierten Fachkräften an jeder Ecke des Social Media auf. Gerade in den Metropolen wie Berlin schaffen es längst nicht alle Unternehmen, jeden Data Engineer über Jahre hinweg zu beschäftigen. Bei der großen Auswahl an Jobs und Herausforderungen fällt diesen Datenexperten nicht schwer, seine Gehaltssteigerungen durch Jobwechsel proaktiv voranzutreiben.

Hybrid Cloud
Shannon Flynn

The Cloud or Hybrid Cloud – Pros & Cons

/in , , /by

Big data and artificial intelligence (AI) are some of today’s most disruptive technologies, and both rely on data storage. How organizations store and manage their digital information has a considerable impact on these tools’ efficacy. One increasingly popular solution is the hybrid cloud.

Cloud computing has become the norm across many organizations as the on-premise solutions struggle to meet modern demands for uptime and scalability. Within that movement, hybrid cloud setups have gained momentum, with 80% of cloud users taking this approach in 2022. Businesses noticing that trend and considering joining should carefully weigh the hybrid cloud’s pros and cons. Here’s a closer look.

The Cloud

To understand the advantages and disadvantages of hybrid cloud setups, organizations must contrast them against conventional cloud systems. These fall into two categories: public, where multiple clients share servers and resources, and private, where a single party uses dedicated cloud infrastructure. In either case, using a single cloud presents unique opportunities and challenges.

Advantages of the Cloud

The most prominent advantage of traditional cloud setups is their affordability. Because both public and private clouds entirely remove the need for on-premise infrastructure, users pay only for what they need. Considering how 31% of users unsatisfied with their network infrastructure cite insufficient budgets as the leading reason, that can be an important advantage.

The conventional cloud also offers high scalability thanks to its reduced hardware needs. It can also help prevent user errors like misconfiguration because third-party vendors manage much of the management side. Avoiding those mistakes makes it easier to use tools like big data and AI to their full potential.

Disadvantages of the Cloud

While outsourcing management and security workloads can be an advantage in some cases, it comes with risks, too. Most notably, single-cloud or single-type multi-cloud users must give up control and visibility. That poses functionality and regulatory concerns when using these services to train AI models or analyze big data.

Storing an entire organization’s data in just one system also makes it harder to implement a reliable backup system to prevent data loss in a breach. That may be too risky in a world where 96% of IT decision-makers have experienced at least one outage in the last three years.

Hybrid Cloud

The hybrid cloud combines public and private clouds so users can experience some of the benefits of both. In many instances, it also combines on-premise and cloud environments, letting businesses use both in a cohesive data ecosystem. Here’s a closer look at the hybrid cloud’s pros and cons.

Advantages of Hybrid Cloud

One of the biggest advantages of hybrid cloud setups is flexibility. Businesses can distribute workloads across public, private and on-premise infrastructure to maximize performance with different processes. That control and adaptability also let organizations use different systems for different data sets to meet the unique security needs of each.

While hybrid environments may be less affordable than traditional clouds because of their on-premise parts, they offer more cost-efficiency than purely on-prem solutions. Having multiple data storage technologies provides more disaster recovery options. With 75% of small businesses being unable to recover from a ransomware attack, that’s hard to ignore.

Hybrid cloud systems are also ideal for companies transitioning to the cloud from purely on-premise solutions. The mixture of both sides enables an easier, smoother and less costly shift than moving everything simultaneously.

Disadvantages of Hybrid Cloud

By contrast, the most prominent disadvantage of hybrid cloud setups is their complexity. Creating a system that works efficiently between public, private and on-prem setups is challenging, making these systems error-prone and difficult to manage. Misconfigurations are the biggest threat to cloud security, so that complexity can limit big data and AI’s safety.

Finding compatible public and private clouds to work with each other and on-prem infrastructure can also pose a challenge. Vendor lock-in could limit businesses’ options in this regard. Even when they get things working, they may lack transparency, making it difficult to engage in effective big data analytics.

Which Is the Best Option?

Given the advantages and disadvantages of hybrid cloud setups and their conventional counterparts, it’s clear that no single one emerges as the optimal solution for every situation. Instead, which is best depends on an organization’s specific needs.

The hybrid cloud is ideal for companies facing multiple security, regulatory or performance needs. If the business has varying data sets that must meet different regulations, some information that’s far more sensitive than others or has highly diverse workflows, they need the hybrid cloud’s flexibility and control. Companies that want to move slowly into the cloud may prefer these setups, too.

On the other hand, the conventional cloud is best for companies with tighter budgets, limited IT resources or a higher need for scalability. Smaller businesses with an aggressive digitization timeline, for example, may prefer a public multi-cloud setup over a hybrid solution.

Find the Optimal Data Storage Technology

To make the most of AI and big data, organizations must consider where they store the related data. For some companies, the hybrid cloud is the ideal solution, while for others, a more conventional setup is best. Making the right decision begins with understanding what each has to offer.

Data Science im Vertrieb
Haufe Akademie

Data Science im Vertrieb – Praxisbeispiel

/in , , , , , /by

Wie Sie mit einer automatisierten Lead-Priorisierung zu erfolgreichen Geschäftsabschlüssen kommen.

Die Fragestellung:

Ein Softwareunternehmen generierte durch Marketing- und Sales-Aktivitäten eine große Anzahl potenzieller Leads, die nicht alle gleichzeitig bearbeitet werden konnten. Die zentrale Frage war nun: Wie kann eine Priorisierung der Leads erfolgen, sodass erfolgsversprechende Leads zuerst bearbeitet werden können?

Definition: Ein Lead bezeichnet einen Kontakt zu einem/einer potenziellen Kund:in, die/der sich für ein Produkt oder eine Dienstleistung eines Unternehmens interessiert und deren/dessen Kontaktdaten dem Unternehmen vorliegen. Solche Leads können durch Online- und Offline-Werbemaßnahmen gewonnen werden.

In der Vergangenheit beruhte die Priorisierung und somit auch die Bearbeitung der Leads in dem Unternehmen häufig auf der persönlichen Erfahrung der zuständigen Vertriebsmitarbeiter:innen. Diese Vorgehensweise ist  jedoch sehr ressourcenintensiv und stark abhängig von der Erfahrung einzelner Vertriebsmitarbeiter:innen.

Aus diesem Grund beschloss das Unternehmen, ein KI-gestütztes System zu entwickeln, welches zum einen erfolgsversprechende Leads datenbasiert priorisiert und zum anderen Handlungsempfehlungen für die Vertriebsmitarbeiter:innen bereitstellt.

Das Vorgehen: 

Grundlage dieses Projektes waren bereits vorhandene Daten zu früheren Leads sowie CRM-Daten zu bereits geschlossenen Aufträgen und Deals mit diesen früheren Leads. Dazu gehörten beispielsweise:

  • Firma des Leads
  • Firmengröße des Leads
  • Branche des Leads
  • Akquisekanal, über den der Lead generiert wurde
  • Dauer bis Antwort durch Vertriebsmitarbeiter:in
  • Wochentag der Antwort
  • Kanal der Antwort

Diese Daten aus der Vergangenheit konnten zunächst einer explorativen Datenanalyse unterzogen werden, bei der untersucht wurde, inwiefern die Eigenschaften der Leads und das Verhalten der Vertriebsmitarbeiter:innen in der Vergangenheit einen Einfluss darauf hatten, ob es mit einem Lead zu einem Geschäftsabschluss kam oder nicht.

Diese Erkenntnisse aus den vergangenen Leads sollten jedoch nun auch auf aktuelle bzw. zukünftige Leads und die damit verbundenen Vertriebsaktivitäten übertragen werden. Deshalb ergaben sich aus der explorativen Datenanalyse zwei weiterführende Fragen:

  • Durch welche Merkmale zeichnen sich Leads aus, die mit einer hohen Wahrscheinlichkeit zu einem Geschäftsabschluss führen?
  • Welche Aktivitäten der Vertriebsmitarbeiter:innen führen zu einem Geschäftsabschluss?

Leads priorisieren

Durch die explorative Datenanalyse konnte das Unternehmen bereits erste Einblicke in die verschiedenen Eigenschaften der Leads erlangen. Bei einigen dieser Eigenschaften ist anzunehmen, dass sie die Wahrscheinlichkeit erhöhen, dass ein:e potenzielle:r Kund:in Interesse am Produkt des Unternehmens zeigt. Es gibt mehrere Wege, um die Erkenntnisse aus der explorativen Datenanalyse nun für zukünftiges Verhalten der Vertriebsmitarbeiter:innen zu nutzen.

Regelbasiertes Vorgehen

Auf Grundlage der explorativen Datenanalyse und der dort gewonnenen Erkenntnisse könnte das Unternehmen, z. B. dessen Vertriebsleitung, bestimmte Regeln oder Kriterien definieren, wie beispielsweise die Unternehmensgröße des Kunden oder die Branche. So könnte die Vertriebsleitung anordnen, dass Leads aus größeren Unternehmen oder aus Unternehmen aus dem Energiesektor priorisiert behandelt werden sollten, weil diese Leads auch in der Vergangenheit zu erfolgreichen Geschäftsabschlüssen geführt haben.

Der Vorteil eines solchen regelbasierten Vorgehens ist, dass es einfach zu definieren und schnell umzusetzen ist.

Der Nachteil ist jedoch, dass die hier definierten Regeln sehr starr sind und dass Menschen meist nicht in der Lage sind, mehr als zwei oder drei der Eigenschaften gleichzeitig zu betrachten. Obwohl sich die Regeln dann zwar grundsätzlich an den Erkenntnissen aus den Daten orientieren, hängen sie doch immer noch stark vom Bauchgefühl der Vertriebsleitung ab.

Clustering

Ein besserer Ansatz war es, die vergangenen Leads anhand aller verfügbaren Eigenschaften in Gruppen einzuteilen, innerhalb derer die Leads sich einander stark ähneln. Hierfür kommt ein maschinelles Lernverfahren namens Clustering zum Einsatz, welches genau dieses Ziel verfolgt: Beim Clustering werden Datenpunkte, also in diesem Falle die Leads, anhand ihrer Eigenschaften, also beispielsweise die Unternehmensgröße oder die Branche, aber auch ob es zu einem Geschäftsabschluss kam oder nicht, zusammengefasst.

Beispiel: Leads aus Unternehmen zwischen 500 und 999 Mitarbeitern aus der Energiebranche kauften 250 Lizenzen der Software A.

Kommt nun ein neuer Lead hinzu, kann er anhand seiner bereits bekannten Eigenschaften einem Cluster zugeordnet werden. Anschließend können die Vertriebsmitarbeiter:innen jene Leads priorisieren, die einem Cluster zugeordnet worden sind, in dem in der Vergangenheit bereits häufig erfolgreich Geschäfte abgeschlossen worden sind.

Der Vorteil eines solchen datenbasierten Vorgehens ist, dass eine Vielzahl an Kriterien gleichzeitig in die Priorisierung einbezogen werden kann.

Erfolgsführende Aktivitäten identifizieren

Process Mining

Im zweiten Schritt wurde eine weitere Frage gestellt: Welche Aktivitäten der Vertriebsmitarbeiter:innen führen zu einem erfolgreichen Geschäftsabschluss mit einem Lead? Dabei standen nicht nur die Leistungen einzelner Mitarbeiter:innen im Fokus, sondern auch die übergreifenden Muster, die beim Vergleich der verschiedenen Mitarbeiter:innen deutlich wurden. Mithilfe von Process Mining konnte festgestellt werden, welche Maßnahmen und Aktivitäten der Vertriebler:innen im Umgang mit einem Lead zum Erfolg bzw. zu einem Misserfolg geführt hatten. Weniger erfolgsversprechende Maßnahmen konnten somit in der Zukunft vermieden werden.

Vor allem zeitliche Aspekte spielten hierbei eine Rolle: Parameter, die aussagten, wie schnell oder an welchem Wochentag Leads eine Antwort erhielten, waren entscheidend für erfolgreiche Geschäftsabschlüsse. Diese Erkenntnisse konnte das Unternehmen dann in zukünftige Sales Trainings sowie die Sales-Strategie einfließen lassen.

Die Ergebnisse

In diesem Projekt konnte die Sales-Abteilung des Softwareunternehmens durch zwei verschiedene Ansätze die Priorisierung der Leads und damit die Geschäftsabschlüsse deutlich verbessern:

  • Priorisierung der Leads

Mithilfe des Clustering war es möglich, Leads in Gruppen einzuteilen, die sich in ihren Eigenschaften ähneln, u.a. auch in der Eigenschaft, ob es zu einem Geschäftsabschluss kommt oder nicht. Neue Leads wurden den verschiedenen Clustern zuordnen. Leads, die einem Cluster mit hoher Erfolgswahrscheinlichkeit zugeordnet wurden, konnten nun priorisiert bearbeitet werden.

  • Erfolgsversprechende Aktivitäten identifizieren

Mithilfe von Process Mining wurden erfolgsversprechende Aktivitäten der Sales-Mitarbeiter:innen identifiziert und skaliert. Umgekehrt wurden wenig erfolgsversprechende Aktivitäten erkannt und eliminiert, um Ressourcen zu sparen.

Infolgedessen konnte das Softwareunternehmen Leads erfolgreicher bearbeiten und höhere Umsätze erzielen. 

Accident-caused car damage cost estimation by AI / Deep LearningDATANOMIQ
Benjamin Aunkofer

How to speed up claims processing with automated car damage detection

/in , , , , , , /by

AI drives automation, not only in industrial production or for autonomous driving, but above all in dealing with bureaucracy. It is an realy enabler for lean management!

One example is the use of Deep Learning (as part of Artificial Intelligence) for image object detection. A car insurance company checks the amount of the damage by a damage report after car accidents. This process is actually performed by human professionals. With AI, we can partially automate this process using image data (photos of car damages). After an AI training with millions of photos in relation to real costs for repair or replacement, the cost estimation gets suprising accurate and supports the process in speed and quality.

AI drives automation and DATANOMIQ drives this automation with you! You can download the Infographic as PDF.

How to speed up claims processing with automated car damage detection

How to speed up claims processing
with automated car damage detection

Download this Infographic as PDF now by clicking here!

We wrote this article in cooperation with pixolution, a company for computer vision and AI-bases visual search. Interested in introducing AI / Deep Learning to your organization? Do not hesitate to get in touch with us!

DATANOMIQ is the independent consulting and service partner for business intelligence, process mining and data science. We are opening up the diverse possibilities offered by big data and artificial intelligence in all areas of the value chain. We rely on the best minds and the most comprehensive method and technology portfolio for the use of data for business optimization.

Haufe Akademie

Interview – Mehr Business-Nerds, bitte!

/in , , /by

Die Haufe Akademie im Gespräch mit Prof. Dr. Stephan Matzka, Hochschulprofessor an der HTW Berlin und Trainer der Haufe Akademie darüber, wie Data Science und KI verdaulich vermittelt werden können und was eigentlich passiert, wenn man es nicht tut.

Sie beschäftigen sich mit Data Science, Algorithmen und Machine Learning – Hand aufs Herz: Sind Sie ein Nerd, Herr Prof. Matzka?   

Stephan Matzka: (lacht) Ich bin ein neugieriger Mensch und möchte gerne mehr über die Menschen und Dinge erfahren, die mich umgeben. Dafür benötige ich Informationen, die ich einordnen und bewerten kann und nichts anderes macht Data Science. Wenn Neugier also einen Nerd ausmacht, bin ich gerne ein Nerd.

Aber all die Buzzwords, die Sie gerade genannt haben, wie Machine Learning oder Algorithmen, blenden mehr als sie helfen. Ich spreche lieber von menschlicher und künstlicher Intelligenz. Deren Gemeinsamkeiten und Unterschiede sind gut zu erklären und dieses Verständnis ist der Schlüssel für alles Weitere.

Ist das Verständnis für Data Science und Machine Learning auch der Schlüssel für den Zukunftserfolg von Unternehmen oder wird die Businessrelevanz von Data Science überschätzt?

Stephan Matzka: Zunächst mal ist Machine Learning größtenteils einfach Statistik, die sehr clever angewandt wird. Damit wir Benutzer:innen nicht wie in der Schule mit der Hand rechnen müssen, gibt es Algorithmen, die uns die Arbeit abnehmen. Die Theorie ist also altbekannt. Aber die technischen Möglichkeiten haben sich geändert.

Sie können das mit Strom vergleichen, den gibt es schon länger. Aber erst mit einem Elektromotor können Sie Power auf die Straße bringen. Daten sind also altbekannte Rohstoffe, die Algorithmen und Rechenleistung von heute aber ein völlig neuer Motor.

Wenn Sie sehen, wie radikal die Dampfmaschine und der Elektromotor die Wirtschaft beeinflusst haben, dann gewinnen Sie einen Eindruck, was gerade im Bereich künstliche Intelligenz abgeht, und das über alle Unternehmensgrößen und Branchen hinweg.

So eine Dampfmaschine ist für viele wahrscheinlich deutlich einfacher zu greifen als das tech-lastige Universum Data Science. Das ist schon sehr abstrakt. Ist es so schwierig, wie es aussieht?

Stephan Matzka: Data Science kann man, wie alle Dinge im Leben, kompliziert oder einfach machen. Und es gibt auch auf diesem Feld Menschen, die Schwieriges einfach aussehen lassen. Das sind die Vorbilder, von denen wir alle lernen können.

Künstliche Intelligenz, oder kurz KI, bietet Menschen und Unternehmen große Chancen, wenn Sie sich rechtzeitig damit beschäftigen. Dabei geht es um nicht weniger als die Frage, ob wir in unserer Arbeitswelt zukünftig KI für uns arbeiten lassen oder abwarten, bis uns ein Algorithmus vorgibt, was wir als Nächstes tun sollen. Mit der richtigen Unterstützung ist der Aufwand jedoch überschaubar und der Nutzen für Unternehmen und Organisationen enorm.

Viele Mitarbeiter:innen hören nach „Wir sind jetzt agil“ neuerdings „Mach‘ mal KI“ – was raten Sie den Kolleg:innen und Entscheider:innen in mittelständischen Unternehmen für den Umgang mit dem Thema?

Stephan Matzka: Es braucht zum einen Impulse „von außen“, um sich mit diesem wichtigen Thema auseinanderzusetzen und einen Start zu finden. Und zum anderen braucht es Mitarbeiter:innen, die datenaffin sind, sich mit dem Thema bereits auseinandergesetzt haben und Use Cases entwickeln sowie hinterfragen können. Meine Berufserfahrung zeigt: Gerade am Anfang ist es noch sehr leicht, bei den klassischen „Low Hanging Fruits“ Erfolge zu erzielen. Das motiviert für das nächste Projekt und schon ist das Momentum im Unternehmen.

Was sind die Minimalanforderungen in einem Unternehmen, um mit Data Science und Machine Learning einen echten Mehrwert zu schaffen und die „Low Hanging Fruits“ zu ernten?  

Stephan Matzka: Der Rohstoff sind Daten in digitaler Form, ob in Excel-Listen, in SAP oder einer Datenbank ist erst mal zweitrangig. Für die Auswertung brauchen Sie passende Software und Menschen, die diese Software bedienen können.

In jedem Unternehmen gibt es solche Daten, die Software ist häufig kostenlos, der eigentliche Engpass sind aktuell die Expert:innen.

Könnte ich mir nicht die Arbeit sparen und Beratungsunternehmen einsetzen?

Stephan Matzka: Das könnten Sie, und Beratungsunternehmen können Ihnen oft auch die richtigen Themen aufzeigen. Gleichzeitig wirft dies zwei wesentliche Fragen auf: Wie können Sie die Qualität und den Preis einer Lösung beurteilen, die Ihnen ein externer Dienstleister anbietet? Und zweitens, wie verankern Sie nachhaltig das Wissen in Ihrem Unternehmen?

Damit die Beratungsleistung Ihnen also wirklich weiterhilft, benötigen Sie Beurteilungskompetenz auf dem Gebiet der künstlichen Intelligenz im eigenen Unternehmen. Diese Beurteilungskompetenz im Businesskontext zu schaffen ist aus meiner Sicht ein wesentlicher Erfolgsfaktor für Unternehmen und sollte eher kurz- als mittelfristig angegangen werden.

Haufe Akademie: Nochmal zurück zu den Daten: Woher weiß ich, ob ich genug Daten habe? Sonst bilde ich jemanden aus oder stelle jemanden ein, der mich Geld kostet, aber nichts zu tun hat.

Stephan Matzka: Mit den Daten ist es ein wenig so wie mit den Finanzen, kann ich jemals „genug Budget“ im Unternehmen haben? Natürlich ist es mit großen Datenmengen leichter möglich, bessere Resultate zu erzielen, genauso wie mit mehr Projektbudget. Aber wir alle haben schon erlebt, wie kleine Projekte Erstaunliches bewegt haben und Großprojekte spektakulär gescheitert sind.

Genau wie Budgets sind Daten meist in dem Umfang vorhanden, in dem sie eben verfügbar sind. Die vorhandenen Daten klug zu nutzen: Das ist das Ziel.

Ein Beispiel aus der Praxis: Es gibt sehr große Firmen mit riesigen Datenmengen, die mir, nachdem ich bei ihnen einen Drucker gekauft habe, weiter Werbung für andere Drucker zeigen anstatt Werbung für passende Toner. So eine KI würde mir kein mittelständisches Unternehmen abnehmen.

Gleichzeitig werden Sie sich wundern, welches Wissen oft schon in einfachen Excel-Tabellen schlummert. Wissen Sie zum Beispiel, was Ihnen der höchste Umsatz eines Kunden in den letzten zwölf Monaten und die Zeitabstände der letzten drei Bestellungen schon jetzt über die nächste Bestellung verraten?

In meinen Recherchen zum Thema bin ich oft an hohen Einstiegshürden gescheitert. Trotzdem habe ich gespürt, dass das Thema wichtig ist. Das war mitunter frustrierend. Welche Fragen sollte ich mir als Mitarbeiter:in stellen, wenn ich mich für Data Science interessiere, aber keine Vorkenntnisse habe?

Stephan Matzka: Das Wichtigste ist erstmal, sich nicht abschrecken zu lassen. 80% der Themen lassen sich zum Beispiel komplett ohne Mathematik erklären. Nochmal 15% sind Stoff der Sekundarstufe, bleiben noch 5% übrig. Die haben es tatsächlich in sich und dann können Sie sich immer noch entscheiden: Finde ich das Thema so spannend (und habe ich die Zeit), dass ich mich auch da noch reinarbeite. Oder reichen mir die 95% Verständnis für die zuverlässige Lösung meiner Business-Fragestellungen aus. Viel entscheidender ist für mich, sich dem Thema mutig anzunehmen, die ersten Erfolge zu feiern und mit diesem Rückenwind die nächsten Schritte zu tun.

Vielen Dank für das Gespräch, Herr Prof. Matzka!

Google Cloud run with Infrastructure by Code using Terraform
Otrek Wilke

Google Cloud Run – Tutorial

/in , , , , /by

Es gibt Gelegenheiten, da ist eine oder mehrere serverlose Funktionen nicht ausreichend, um einen Service darzustellen. Für diese Fälle gibt es auf der Google Cloud Plattform Google Cloud Run. Cloud Run bietet zwei Möglichkeiten Container auszuführen. Services und Jobs. In diesem Beispiel wird ein Google Cloud Run Service mittels Terraform definiert, welcher auf Basis eines Scheduler Jobs regelmäßig aufgerufen wird. Cloud Build wird dazu genutzt den aktuellen Code auf den Service zu veröffentlichen.

Der nachfolgende Quellcode ist in GitHub verfügbar: https://github.com/fingineering/GCPCloudRunDemo

tl;dr

Mittels Terraform können alle notwendigen Komponenten erstellt werden, um einen Cloud Run Services aus einem Github Repository kontinuierlich zu aktualisieren. Als Beispiel wird ein stark vereinfachter Flask Webservice verwendet. Durch den Cloud Scheduler wird dieser Service regelmäßig aufgerufen.

Voraussetzungen

Bevor der Service aufgesetzt werden kann, müssen einige Voraussetzungen erfüllt sein. Es wird ein Google Cloud Project benötigt, sowie ein Github Account. Auf dem Computer, welcher zur Entwicklung verwendet werden soll, müssen Terraform, Google Cloud SDK, git, Docker und Python installiert sein. In diesem Beispiel wird Python verwendet, es ist aber mit jeder Sprache möglich, mit der ein WebServer erstellt werden kann.

  • Ein Google Cloud Projekt kann bei Google Cloud Plattform erstellt werden. Es wird nur ein Google Account benötigt, Neukunden erhalten ein kostenloses Guthaben von 300€ für 90 Tage.
  • Wenn noch nicht vorhanden sollte ein kostenloser Github Account auf Github erstellt werden. Das Beispiel kann auch mittels Google Cloud Source Repositories umgesetzt werden. Als Alternative zu Cloud Build kann Github Actions eingesetzt werden.
  • Terraform, Google Cloud SDK, Docker und Python müssen auf dem verwendeten Computer installiert werden, hierzu empfiehlt sich ein Paketmanager wie Homebrew oder Chocolatey. Linux Nutzer verwenden am besten den in ihrer Distribution mitgelieferten.
  • Soll nichts installiert werden, dann kann auch die Google Cloud Shell verwendet werden, diese findet sich im in der Cloud Console

APIs die in Google Cloud aktiviert werden müssen

Neben den Voraussetzungen zur Software müssen auf der Google Cloud Plattform einige APIs aktiviert werden:

  • Cloud Run API
  • Cloud Build API
  • Artifact Registry API
  • Cloud Scheduler API
  • Cloud Logging API
  • Identity and Access Management API

Die Cloud Run API wird benötigt um einen Cloud Run Service zu erstellen, die Artifact Registry wird benötigt, um die Container Abbilder zu speichern. Die Cloud Build API und die Identity and Access Management API werden benötigt, um eine CI/CD Pipeline zu implementieren. Cloud Scheduler wird in diesem Beispiel verwendet, um den Service regelmäßig aufzurufen. Da alle Services via Terraform erstellt und verwaltet werden, werden die APIs benötigt.

Infrastruktur

Das Erstellen der Infrastruktur läuft in mehreren Schritten ab, nur wenn App Code und Container bereits vorhanden sind, kann der gesamte Prozess automatisiert werden. Für die Definition der Infrastruktur wird ein Ordner “Infrastructure” erstellt und darin die Dateien main.tf, variables.tfund  terraform.tfvars.

Insgesamt werden vier Komponenten erstellt, das Artifact Registry Repository, ein Cloud Run Service, ein Cloud Build Trigger und ein Cloud Scheduler Job. Bevor die eigentliche Infrastruktur erzeugt werden kann, müssen einige Service Accounts definiert werden. Ziel ist es, das jedes Asset eine eigene Identität zugewiesen werden kann. Daher werden drei Service Accounts erstellt, für den Run Service, den Build Trigger und den Scheduler Job.

Da der erste Schritt die Einrichtung der Artifact Registry für den Cloud Run Service ist, wird dieser wie folgt hinzugefügt:

Nun kann der erste Schritt zum Aufsetzen der Infrastruktur mittels des Terraform Dreiklangs durchgeführt werden:

Die Beispiel Flask Anwendung

Als Beispielanwendung wird hier eine sehr simple Flask Webapp verwendet. Die Webapp beinhaltet eine einzige Route, es wird Hello World bei einem GET Request zurück gegeben und mittels POST kann die Nachricht personalisiert werden. Die Anwendung dient nur der Demonstration, es können fast beliebige Funktionalitäten umgesetzt werden.

Es ist auch nur zwingend notwendig flask oder Python zu verwenden, es kann jede Sprache und jedes Framework eingesetzt werden, welches einen Webserver implementieren kann und auf HTTP Anfragen reagieren kann. Flask selbst ist ein sogenanntes Micro Framework und kann flexibel eingesetzt werden, für mehr Informationen empfiehlt sich z.b. das Flask Mega Tutorial

Im Projektverzeichnis muss ein neuer Ordner App erzeugt werden, in diesem Ordner wird die Python Datei main.py, sowie die requirements.txt Datei erzeugt.

Dieser minimale Webservice kann local ausgeführt werden indem ein virtual environment erzeugt und die in requirements.txt spezifizierten Pakete installiert werden.

Die App kann nun local ausgeführt werden mittels:

Zum Testen kann im Browser die Adresse localhost:8080 aufgerufen werden oder mittels curl ein POST Request an den Service gesendet werden.

Der mit flask mitgelieferte Web Server sollte nur zu Entwicklungszwecken verwendet werden, in produktiven Umgebungen kann z.b. gunicorn eingesetzt werden. Gunicorn wird in diesem Beispiel später auch im Container verwendet werden.

Docker Container erstellen, ausführen und deployen

Um einen Service in Cloud Run auszuführen, muss dieser in einem Docker Container vorliegen. Dazu wird zunächst ein Dockerfile im App Ordner erstellt. Diese ist einfach gehalten, es basiert auf einem Python Container, kopiert die Dateien aus dem App Ordner und definiert das Start Kommando für Gunicorn.

In vielen Fällen sind im lokalen Entwicklungsordner Dateien vorhanden die nicht in den Container veröffentlicht werden sollten, damit Dateien explizit aus der Containererzeugung ausgeschlossen werden können kann eine .dockerignore Datei hinzugefügt werden. Diese funktioniert analog der .gitignore Dateien.

Um das Veröffentlichen auf die Artifact Registry zu vereinfachen, kann es eine gute Idee sein dem Namensschema der Registry zu folgen: location—docker.pkg.dev/your-project-id/registryname/containername:latest. Mittels docker build kann das Container Image erstellt werden:

Um das erstellt Image local zu testen, kann dieses mittels docker run auch lokal ausgeführt werden. Wichtig ist dabei zu beachten die notwendigen Umgebungsvariablen mit zugeben und den Port zu exponieren.

Werden im Webservice Google Identitäten verwendet, dann müssen Informationen über den zu verwendenden Google Account mitgegeben werden. Wie dies im Detail funktioniert findet sich unter Cloud Run lokal testen.

Den ersten Container manuell deployen

Bevor es möglich ist den Cloud Run Service zu erstellen muss das Container Abbild einmal manuell in die Artifact Registry veröffentlicht werden.

Erstellen und veröffentlichen des Container Abbilds kann auch in einem Kommando erfolgen:

Cloud Run Service aufsetzen

Da der initiale Container nun in der Aritfact Registry vorhanden ist, kann der Cloud Run Service daraus erstellt werden. Für den Cloud Run Service wird eine neue Resource im main.tf erstellt.

Dieser Service ist zunächst privat, alle Identitäten die diesen Service aufrufen wollen benötigen die Rolle roles/run.invoker. Da der Cloud Scheduler den Service regelmäßig aufrufen soll, muss die Identität des Schedulers Mitglied der Rolle sein.

Nun kann der Terraform Dreiklang verwendet werden den Service und den Scheduler Job zu erstellen.

Cloud Build Trigger erstellen

Der finale Schritt um ein kontinuierliches deployment des Services zu erreichen ist einen Cloud Build Trigger einzurichten. Der Cloud Build Trigger beobachtet Veränderungen am GitHub Repository und erstellt bei jedem neuen Commit auf dem main branch eine neue Version des Cloud Run Services. Die hier vorgestellte Pipeline beinhaltet nur das Erstellen und Veröffentlichen des Containers. Für eine produktive Implementation ist unbedingt zu empfehlen auch noch ein Testschritt mit einzufügen. Mit dem folgenden Code wird der Trigger mittels Terraform erstellt:

Der Cloud Build Trigger nutzt zur Definition des Deployment Processes die Datei cloudbuild.yaml, diese enthält die drei Schritte zum Erstellen des Container Abbilds, Veröffentlichen des Abbilds und Erzeugen einer neuen Version des Cloud Run Services.

  1. Erstellen des Container Abbilds mittels des Docker build Tools. Das erste Argument ist die Aktion build, das zweite und dritte beziehen sich auf den Tag des Images und das vierte gibt den Ort vor an dem nach dem Dockerfile gesucht wird
  2. Veröffentlichen des Container Images in die Artifact Registry mittels des Cloud Build Docker Tools. Als Argumente werden die Aktion push und das Ziel mitgegeben.
  3. Veröffentlichen der neuen Version des Images im Cloud Run Service mittels des Google Cloud SDK Tools gcloud

Alle drei Schritte nutzen Variablen, um Projektziel, Image Tag und Ort flexibel durch den Build Trigger zu steuern. Diese Variable werden bei der Erstellung des Triggers mit definiert, d.h. dieser finden sich in der Definition des Cloud Build Triggers in der Terraform Datei. Die Variablen werden substitutions genannt, es ist zu beachten, das nutzerdefinierte Variablen mit einem Unterstrich beginnen müssen, nur Systemvariablen, wie die PROJECT_ID.

Das Erstellen des Cloud Build Triggers kann versagen, in diesem Falle sollten die Einstellungen von Cloud Build in der Cloud Console geprüft werden. Die Service Account Berechtigungen für Cloud Run und Service Accounts müssen aktiviert sein, wie im Bild unten.

Service Account Berechtigungen für Cloud Run und Service Accounts

Service Account Berechtigungen für Cloud Run und Service Accounts

Zusammenfassung

Mit Hilfe von Terraform ist es möglich ein vollständig in Code definierten, kontinuierlich veröffentlichten Google Cloud Run Service zu erstellen. Dazu werden GCP Services verwendet, eine Flask Webapp in einem Container zu verpacken und diesen auf Cloud Run zu veröffentlichen.

Für Fragen erstellt gerne ein Issue oder ihr findet mich auf LinkedIn.

Der Quellcode ist in GitHub verfügbar: https://github.com/fingineering/GCPCloudRunDemo