Blog

Um die Herausforderungen im Internet of Things zu bewältigen, müssen Unternehmen vor allem ihren IoT-Reifegrad kennen. Verfügt es über eine große Anzahl an Connected Devices und verborgenen Datenschätzen? Wird bereits erfolgreich IoT Data Analytics umgesetzt, sodass daraus Mehrwert für Prozesse generiert wird? Ist genug Know-how zu Data Storage und dem Umgang mit hoch performanten Datenbanken in der Cloud vorhanden? Alle diese Fragen haben Einfluss auf Euren Weg ins Internet of Things.

Herzlichen Glückwunsch, Du hast es geschafft und die bisherigen Ausführungen zu unserem Referenzarchitekturmodell unbeschadet überstanden! Der mühsamste und lästigste Teil liegt damit schon hinter uns. Falls Du gerade erst mit Teil 3 in unsere Blogserie einsteigst, kein Problem! Klicke einfach auf die Links zu Teil 1 und Teil 2. Dort erfährst Du mehr zu Ingestion und Data Lakes sowie der gesamten Referenzarchitektur.

Zu Teil 1 und Teil 2 der Blogserie.

Wie im ersten Teil erwähnt, werden wir in dieser Blogserie zunächst verschiedene Teile unserer Referenzarchitektur einer Cloud Data Platform vorstellen. Im Anschluss adaptieren wir diese auf die drei großen Cloud-Anbieter – Google Cloud Platform, AWS und Azure. Falls Du den ersten Blogbeitrag, der sich mit dem Ingestion-Teil unseres Modells beschäftigt, noch nicht gelesen hast, kannst Du das noch nachholen. Für alle anderen geht es nun mit dem Data-Lake-Teil der b.telligent Referenzarchitektur weiter, bevor wir uns in Teil 3 ausführlicher mit der Analytical Platform beschäftigen.

Hast Du schon mal darüber nachgedacht, wie die ideale Cloud-Data-Platform-Architektur aussehen sollte? Wir schon! In unserer kostenlosen Online-Event-Reihe Data Firework Days haben wir die b.telligent Referenzarchitektur für Cloud-Datenplattformen vorgestellt, einen Blueprint für den Aufbau einer erfolgreichen Datenplattform für Deine Analytics-, KI-/ML- oder DWH-Anwendungsfälle. Und wir sind noch einen Schritt weiter gegangen. Da wir alle wissen, dass es da draußen nicht die „eine“ Cloud gibt, haben wir unser Modell auch für die drei großen Cloud-Anbieter – Google Cloud Platform, AWS und Azure – adaptiert. In dieser Blogserie wollen wir in den ersten beiden Beiträgen zunächst unsere Referenzarchitektur beschreiben und uns dann, in den Teilen 4 bis 6, mit den Implementierungsmöglichkeiten für die einzelnen Anbieter beschäftigen. Los geht‘s, begleite uns auf unserer Reise durch die Cloud.

Ich: neu bei b.telligent, Promotion in reiner Mathematik, Programmier- und IT-Kenntnisse eine bunte Mischung. Das Ziel: innerhalb von 4 Monaten zertifizierter Azure Architect werden. Der Weg: ein Fortbildungsprogramm von Microsoft und viel Unterstützung von b.telligent.

In unserer Reihe „The next generation of CRM – Möge die MarTech mit dir sein“ haben wir bereits geklärt, was der Trend rund um Marketing-Technologie wirklich halten kann, welche Dos und Donʼts es bei der Einführung gibt und wie man den eigenen MarTech-Reifegrad identifiziert.

In diesem Beitrag wollen wir im nächsten Schritt einen Blick auf die MarTech-Architektur werfen – sie ist unsere Landkarte auf der Mission durch das MarTech-Universum. Denn: Genau das wird immer technischer, komplizierter und unübersichtlicher. Dem Kunden stehen in unserer digitalen Welt zahlreiche Möglichkeiten zur Verfügung – und seine Ansprüche an die Customer Experience steigen. Aber auch für Marketer bringt die Digitalisierung Veränderungen. Die Spuren, die der Kunde entlang der digitalen Kontaktkanäle wie Onlineshop, App oder Website hinterlässt, sind sehr vielseitig nutzbar – erhöhen aber auch die Komplexität im Marketing.

Der Einsatz von Marketing Clouds wächst rasant. Ursache sind veränderte Kundenbedürfnisse und das Ziel, mit den Kunden – datenbasiert – effektiver und effizienter kommunizieren zu können. Gleichzeitig werden Marketing Clouds immer komplexer – nicht selten führen deshalb Unsicherheit und ein Mangel an Erfahrung bei der Auswahl und Implementierung einer Marketing-Cloud-Lösung zu unerwünschten Effekten oder gar zum Scheitern des Projekts. Dieser Blogbeitrag unserer Themenreihe „Next Generation of CRM - Möge die MarTech mit Dir sein“ zeigt deshalb Stolpersteine beim Einsatz einer Marketing Cloud und wie Du sie umschiffen kannst.

Die digitale Transformation im Internet of Things stellt viele Unternehmen vor eine große Herausforderung. Unser b.telligent IoT Adoption Framework unterstützt Dich bei der Transformation durch ein strukturiertes und technologieunabhängiges Vorgehen:

MarTech – was ist das eigentlich? Und wie unterscheidet es sich von CRM, KMS & Co.? Antworten darauf haben wir bereits in Teil 1 unserer Reihe „The Next Generation of CRM – möge MarTech mit Dir sein“ beantwortet. In diesem Beitrag stellen wir uns die Frage: Welches Setup brauche ich, um meinen MarTech Stack auch tatsächlich auf die Straße zu bringen?

Diese Frage wird uns als Beratung sehr häufig gestellt. Zugegeben, bei der Auswahl an Marketingtechnologien mag man sich als Marketer schnell vorkommen wie ein Kind im Süßwarenladen: Am liebsten hätte man von allem etwas! Aber auch im Ergebnis sind beide Situationen ähnlich. Sind die Augen größer als der Magen, endet das meist mit Bauchschmerzen. Denn am Ende des Tages sollte es nicht darum gehen, mit dem eingesetzten Budget möglichst viele Features zu erhalten oder das nächste „angesagte“ Tool, sondern darum, möglichst großen Mehrwert zu erzielen, oder nicht? Woher aber weiß ich, wie ich den für mich optimalen MarTech Stack „bauen“ soll?

Microsoft Power BI ist eines der beliebtesten BI-Tools am Markt und bietet zahlreiche Möglichkeiten, Daten aufzubereiten und zu visualisieren. Um noch mehr Flexibilität zu schaffen, kannst Du zusätzlich durch die Nutzung von Python- und R-Skripten die Standardfunktionen umfangreich erweitern. Wie Du Python-Skripte einbindest, was damit möglich und was zu beachten ist, zeigen wir Dir in diesem Beitrag.

Bei Business Intelligence steht das Thema „Qualität“ immer wieder an zentraler Stelle, wird dabei aber auf die unterschiedlichsten Weisen behandelt. Das liegt daran, dass es bisher kein einheitliches Verständnis und damit auch kein standardisiertes Vorgehen zur BI-Qualität gibt.

Dass dies mehr und mehr zum Problem wird, verdeutlicht auch die Umbenennung des aktuellen Gartner Quadrant. Statt Data Quality „Tools“ heißt dieser nun Data Quality „Solutions“. Denn: Während sich viele Hersteller mittlerweile „was mit Qualität“ auf die Fahne schreiben, eint sie meist lediglich ein verschwindend kleiner gemeinsamer Nenner: Probleme zu finden, zu verstehen und zu lösen. Zwar ist dies, das muss man ihnen zugutehalten, nach dem Philosophen Karl Popper immerhin die Quelle allen technischen Fortschritts. Mit Datenqualität per se hat das aber noch nicht zwingend etwas zu tun. In diesem Beitrag werde ich deshalb das Thema BI-Qualität etwas ordnen und strukturieren und nenne das Ganze deshalb „BI Quality Management“. So bleibt noch eine Menge Luft zum „Total BI Quality Management“, wie es schon seit geraumer Zeit in den Ingenieursdisziplinen angewendet und gelehrt wird

‍

Bei der Erstellung von Berichten stehen wir immer wieder vor der Herausforderung, große Mengen oder komplexe Informationen für die Berichtskonsumenten übersichtlich und verständlich aufzubereiten. Ein effektives Mittel hierfür können Visualisierungen, d. h. Diagramme oder Charts, sein. In diesem Beitrag möchte ich einige wichtige Aspekte aufzeigen, die bei der Erstellung von Visualisierungen in Berichten zu beachten bzw. bedenken sind, wenn man aussagekräftig mit ihnen kommunizieren möchte.