Allgemein Archive

Archiv für die Kategorie Allgemein

W. & L. Jordan auf dem Weg zur unternehmensweiten Datenkultur

Erstellt am: Montag, 13. Januar 2025 von Anja Gorbach

Das Unternehmen W. & L. Jordan will mehr Erkenntnisse aus seinen Daten für die Unternehmenssteuerung generieren. Kompakte Workshops von QUNIS haben den Entscheidern im Unternehmen einen Überblick über moderne Analytics-Anwendungen gegeben und Möglichkeiten für erste Maßnahmen aufgezeigt.

Ich sehe QUNIS als Partner, der einen sehr
strategischen, langfristigen Ansatz zum strukturierten Umgang mit Daten verfolgt.

Patrick Adler,
Leiter Controlling, W & L Jordan

Zentrales Datenmanagement für die Unternehmenssteuerung

Das Familienunternehmen Jordan mit seiner Eigenmarke JOKA gehört mittlerweile zu den führenden Anbietern für Bodenbeläge, Türen, Holz und Holzwerkstoffe in Mitteleuropa. Bei rund 1.500 Mitarbeitenden und mehreren Tochtergesellschaften sah das Controlling eine Größenordnung erreicht, um ein zentrales Datenmanagement als Grundlage für die Unternehmenssteuerung im Konzern zu etablieren.

Gestartet wurde die Dateninitiative vom Leiter Controlling Patrick Adler. Er hatte QUNIS auf Veranstaltungen im Controlling-Umfeld kennengelernt und holte die Data & Analytics-Experten wegen ihres strategisch weitblickenden und zugleich pragmatischen Ansatzes mit großem Marktüberblick als Berater ins Haus.

Die Beratung durch QUNIS sollte den Entscheidern im Unternehmen einen Einblick in die Rahmenbedingungen einer unternehmensweiten Datenstrategie geben und mögliche Potenziale für Jordan ausloten.

Zunehmende Digitalisierung erfordert konzernweite Datenstrategie

Im Finanzbereich arbeitet Jordan bereits mit einem zentralen Datenpool. Das Controlling und die Prozesse im Kostenmanagement und Reporting wurden in den letzten Jahren neu aufgestellt. Dazu gehörte auch die Implementierung eines Data Warehouse für die interne Ergebnisberichterstattung (GuV) mit Power BI als Frontend.

Beim Aufbau des Data Warehouse traten allerdings Schwachstellen im Stammdatenmanagement zutage, die im Warenwirtschaftssystem zuvor nicht aufgefallen waren. Historisch gewachsene, nicht harmonisierte Prozesse führten zu strukturell mangelhaften Stammdaten. Da die Einführung weiterer datengetriebener Systeme geplant ist, sah der Controllingleiter Patrick Adler den Zeitpunkt für eine konzernweite Datenstrategie gekommen.

Sein Anliegen hinsichtlich der Zusammenarbeit mit QUNIS war, alle Datenthemen systemübergreifend zu durchdenken und im Unternehmen die klare Notwendigkeit einer Datenkultur aufzuzeigen. Eine wesentliche Frage war dabei, wie das Data Warehouse des Controllings fachübergreifend skaliert oder erweitert werden kann.

Kompakte Wissensvermittlung in drei Workshops

Die Beratung fand im Rahmen von drei Workshops statt, an denen neben dem Controlling und der Geschäftsführung auch die IT-Experten und die Vertreter der Fachabteilungen von Jordan teilnahmen.

Im ersten Workshop wurden die Themenblöcke von Data & Analytics im Überblick dargestellt und Querschnittsfunktionen wie Cloud-Services oder ein zentraler Data Catalogue besprochen.
Im zweiten Workshop ging es um IT-Themen wie IT-Architekturen oder Technologien.
Das Thema Governance stand im Mittelpunkt des dritten Workshops.

In einer Abschlusspräsentation zeigte QUNIS dann erste Handlungsfelder für Jordan auf und gab Empfehlungen zum Einstieg in das unternehmensweite Datenmanagement.

Innerhalb kürzester Zeit brachte QUNIS damit alle Stakeholder durch kompakte Informationen auf einen aktuellen Wissensstand zu Technologien, Tools und Organisationsmodellen.

Erkenntnisse mit hohem Praxisbezug

Patrick Adler hebt besonders die strukturierte und gut verständliche Darstellung auch für Nicht-Techniker hervor. Statt technischer Details stand die Business-Sicht von Jordan im Vordergrund. Ein Thema war beispielsweise, wie Datenobjekte im Rahmen der fachlichen Geschäftsprozesse definiert und gepflegt oder wie kausale Zusammenhänge hergestellt werden.

Wichtige Fragen für Jordan waren hier u. a., wie der 360-Grad-Blick auf Handwerker als Direktkunden und darüber hinaus auf den Endkunden hergestellt werden kann oder wie Daten aus dem Online-Shop für gezielte Kampagnen genutzt werden können. Mit diesen Ansätzen konnte QUNIS auch die Produkt- und Vertriebsmanager begeistern. Patrick Adler bestätigt:

Alle Workshops waren geprägt von sehr guter Zusammenarbeit.

Hinsichtlich der technologischen Basis waren die Bewertungskriterien für verschiedene IT-Architekturen hilfreich für das Team von Jordan. Wichtig war auch die Erkenntnis, dass organisatorische Grundlagen wie die Data Governance mit zugehörigen Rollenkonzepten entscheidende Erfolgsfaktoren von Analytics-Projekten sind.

Die umfangreiche Projekterfahrung von QUNIS liefert hier wertvolle Hinweise aus der Praxis. Ein Beispiel ist die prozess- und abteilungsübergreifende Entstehung und Nutzung von Daten, die zur Folge hat, dass ein datenorientierter Zuschnitt von Rollen und Gremien für Datenaufgaben sich nicht unbedingt mit der klassischen funktionalen oder regionalen Organisationsstruktur deckt.

Diese Querschnittsfunktion entlang der Datenprozesse ist bei geplanten organisatorischen Maßnahmen unbedingt zu beachten.

Veränderungsprozesse sind angestoßen

Die Workshops haben die Herausforderungen der datengetriebenen Transformation einer Organisation umrissen und damit die Erwartungen des Controllingleiters erfüllt. Laut Patrick Adler war die Beratung ein Augenöffner für den strategischen Ansatz zum Umgang mit Daten:

Nicht nur ein Tool ist entscheidend, sondern die am Geschäftsmodell ausgerichtete strukturierte Verwendung von Daten, von der operativen Ebene bis hin zur Unternehmenssteuerung. Grundlage dafür ist das Verständnis einer Data & Analytics-Plattform als orchestriertes Zusammenspiel mehrerer Tools für unterschiedliche Unternehmensanforderungen.

Die Workshops haben bei Jordan die hohe Bedeutung der Datenorientierung aufgezeigt und interne Veränderungsprozesse angestoßen. Auch die Tatsache, dass Vorbehalte gegenüber dem Cloud-Betrieb abgebaut werden konnten, war ein entscheidender Schritt nach vorne.

Patrick Adler hält fest: „Die Frage ist jetzt nicht mehr, ob eine Data & Analytics-Plattform benötigt wird, sondern nur wie und zu welchem Zeitpunkt.

Die Empfehlungen aus den Workshops befinden sich derzeit noch in der internen Bewertung, um sie mit weiteren Digitalisierungsprojekten in Einklang zu bringen.“ Patrick Adler wird den internen Aufbau von Know-how währenddessen weiter vorantreiben. Sein Fazit lautet:

QUNIS ist für mich Ansprechpartner Nummer eins,
wenn es darum geht, die nächsten Schritte zu gehen.

Mehr zur Jordan Gruppe: Die W. & L. Jordan GmbH gehört zu den führenden Anbietern von Bodenbelägen, Türen, Holz, Holzwerkstoffen, Sonnenschutz und Wohnstoffen für den gehobenen Wohn- und Objektbereich. Als zuverlässiger Partner bietet Jordan seinen Kunden aus Handwerk und Fachhandel das Komplettsortiment im Bereich Inneneinrichtung. Mit seinen Marken JOKA und INKU (für Österreich) steht W. & L. Jordan international für Produkte der Innenausstattung, die modernes Design, Funktionalität und Nachhaltigkeit vereinen. www.joka.de

Mehr zur QUNIS Strategie

Data Mesh als soziotechnischer Ansatz zur Erstellung einer dezentralen Datenarchitektur

Erstellt am: Mittwoch, 20. März 2024 von chaydl

An die Datenauswertung im Unternehmen werden heute immer größere Anforderungen gestellt. Das zentral angesiedelte BI Competence Center, das bislang die Entwicklung und das Datenmanagement rund um ein Data Warehouse erledigt hat, kommt damit aber immer mehr an seine Grenzen. Das Prinzip des Data Mesh bietet hier einen passenden Lösungsansatz.

Data Mesh macht Analytics agiler

Data Mesh stellt die Daten als Wertschöpfungsfaktor in den Mittelpunkt der Architekturkonzeption. Daten sollen als „Datenprodukte“ prozess- und systemübergreifend im Unternehmen zur Verfügung gestellt werden.

Die Grundidee besteht darin, Daten als Asset für die Organisation zu begreifen und Business Usern hochwertige Datenprodukte für ihre Zwecke zugänglich zu machen, damit sie diese optimal nutzen können. Diesen Ansatz verfolgt auch die Self-Service BI bereits seit Jahren.

Neu ist bei Data Mesh allerdings die konsequente Delegation der Verantwortung und Kompetenzen in die dezentrale Organisation:

Entwicklungsteams erhalten die Verantwortung für die Entwicklung und den Betrieb von Datenprodukten ihrer fachlichen Domäne.
Die Verlagerung in fachlich geschnittenen Domänenteams löst das Engpass-Problem eines einzelnen zentralen Analytic-Teams.
Zugleich vervielfacht sie die Entwicklungsressourcen, erhöht damit das mögliche Umsetzungstempo neuer Use Cases und gewährleistet darüber hinaus die geforderte fachliche Expertise in der jeweiligen Domäne.

Die Dateninfrastruktur für die Domänenteams wird in Form einer Datenplattform nach dem Self-Service-Gedanken bereitgestellt. Im Gegensatz zur klassischen Data-Warehouse-Architektur mit zentralisierten Datenströmen handelt es sich hier um eine domänenorientierte dezentrale Architektur für analytische Daten.

Die Definition von Data Mesh zielt eher auf die Governance und Organisation des datengetriebenen Unternehmens ab als auf technologische Aspekte. Es gibt aber eine Kernarchitektur, die sich zur Umsetzung von Data Mesh besonders eignet, das Data Lakehouse.

Data Lakehouse unterstützt Data Mesh

Das Data Lakehouse unterstützt die dezentrale Arbeit mit Datenprodukten. Durch die Trennung von Storage und Computing bietet es eine hohe Flexibilität zur Einrichtung verschiedener Domänen mit jeweils eigenen Datenprodukten auf einem gemeinsamen Datenlayer. Ein heterogener Technologie-Stack greift dabei über Open Table Format auf Daten aus verschiedenen Quellen zu und bereitet sie für Use Cases wie BI, ML, Data Science oder Data Engineering in diversen Domänen auf.

Unter Berücksichtigung einer stringenten Access Control lassen sich die Datenquellen auf diese Weise verschiedenen Teams für ihre Auswertungen zugänglich machen. Datensilos werden vermieden und domänenübergreifende Datenabfragen unterstützt. Das verteilte Computing ermöglicht es zudem, unvorhergesehene Lastspitzen aus anderen Domänen abzufangen.

Reifegrad der dezentralen Governance als Erfolgsfaktor

Gemäß Definition basiert Data Mesh auf den vier Grundprinzipien Domain Ownership, Data Products, Self-Service und Federated Governance. Die verteilte Governance ist dabei der wesentliche Erfolgsfaktor für die Etablierung von Data Mesh. Im Rahmen der Governance legen die beteiligten Teams gemeinsame Standards und Regeln fest, um ihre Zusammenarbeit, die Harmonisierung der Daten und Sicherheitsanforderungen zu gewährleisten.

Aufgaben wie das Qualitätsmanagement und die Klassifikation von Daten, Security, Schnittstellen-Verwaltung oder die Definition und Verwaltung von Datenprodukten sind über die gesamte Organisation verteilt. Die Verantwortlichkeiten müssen hier klar geregelt sein.

QUNIS hat dafür ein dezidiertes Rollenmodell entwickelt, das sich seit Jahren in Data & Analytics-Projekten bewährt.

Das Rollenmodell legt unter anderem das Ownership für Domänen, Datenprodukte oder Datenobjekte wie „Kunden“, „Artikel“ oder „Partner“ fest.
Datenexperten wie Data Owner, Data Steward und das Data Governance Board arbeiten dabei mit Funktionen eines BI- oder erweiterten Analytics-Rollenmodells zusammen.
Dazu gehören zum Beispiel die Rollen End User, Power User, Solution Architect, Data Engineer mit DataOps, Data Architect sowie Data Scientist mit MLOps.

Über das Rollenmodell kann der Data-Mesh-Gedanke bis hin zu den DevOps etabliert werden. Die Verankerung und Durchsetzung der Rollen und einer starken Governance sind die Voraussetzung dafür, dass die verschiedenen Teams orchestriert zusammenarbeiten, qualitativ hochwertige Datenprodukte geliefert werden und der weitgehende Self-Service im Rahmen zuverlässiger Standards funktioniert.

Die Umsetzung von Data Mesh steht und fällt mit dem Reifegrad dieser Datenorganisation. Diese Organisation ist funktionsübergreifend und deckt sich damit nicht unbedingt mit der üblichen Einteilung in Geschäfts- oder Fachbereichen. Daher ist die Mitwirkung des Management Boards bei der Kontrolle und Etablierung der datengesteuerten Organisation und Architektur unbedingt notwendig.

Data Mesh setzt sich durch

Unternehmen verstehen, dass Daten immer mehr zur Wertschöpfung beitragen. Die kluge Nutzung und Auswertung der Daten bringen den entscheidenden Wettbewerbsvorteil. Für größere Konzerne und auch für viele mittelständische Unternehmen ist erweiterte Analytics daher inzwischen selbstverständlich. Data Mesh bietet die Möglichkeit, sich in diesem Bereich agiler aufzustellen.

QUNIS sieht daher derzeit eine große Dynamik und viel Kraft am Markt, das verteilte Organisations- und Architekturkonzept im Unternehmen umzusetzen. In den Projekten zeigt sich, dass das Data Lakehouse hierbei eine große Hilfe ist, weil die Technologie das flexible Splitten von Datenräumen erlaubt und die Verteilung von Verantwortung für Datenprodukte unterstützt.

Mein Tipp: Wenn Sie mehr über Data Mesh wissen wollen, folgen Sie uns auf LinkedIn und Xing oder abonnieren Sie einfach unseren Newsletter. Oder kontaktieren Sie uns und schreiben Sie mir direkt über KONTAKT ich freue mich über den Austausch mit Ihnen!

Digitale Innovation braucht eine Datenstrategie

Erstellt am: Montag, 11. März 2024 von Anja Gorbach

Unternehmen investieren massiv in Digitalisierungsprojekte und die datengetriebene Wertschöpfung. Neue ERP-Systeme, Prozessvereinheitlichung oder die Ertüchtigung der internen IT-Infrastruktur stehen hier auf der Agenda. Dazu kommen immer mehr innovative Use Cases wie AI- und ML-Anwendungen, Bilderkennungsverfahren oder IoT-Plattformen. Als Cloud-Lösungen sind mächtige Speicher- und Analysesysteme selbst für mittelständische Unternehmen erschwinglich und kommen dort auch rege zum Einsatz.

Ohne ein fortgeschrittenes Datenmanagement werden die digitalen Innovationen jedoch nicht funktionieren, denn nach wie vor gilt die alte Weisheit: Die neuen Technologien können die Erwartungen nur erfüllen, wenn die Datenbasis stimmt. Und hier liegt in der Unternehmenspraxis oft das Problem.

Unkoordinierte Dateninitiativen kosten Geld und gefährden die Wertschöpfung

Im Zusammenhang mit der Systemadministration sind meist auch Datenmanagement-Initiativen etabliert. Diese laufen aber oft unkoordiniert im Unternehmen nebeneinander – und jede einzelne Disziplin für sich ist eine Mammutaufgabe.

Stamm- und Metadatenmanagement, Schnittstellen-Verwaltung, Datenqualität, Initiativen rund um BI und ML sind verschiedenste Ansätze, in denen sich einzelne Teams um ihr jeweiliges Datenthema kümmern.

So setzt man beispielsweise das Stammdatenmanagement oft nur Tool-basiert auf.
Oder es kommt vor, dass in der IT eine MDM-Implementierung läuft und parallel eine unternehmensweite Data-Governance-Initiative gestartet wird.
Oder eine ERP-Migration von SAP R/3 auf S/4 läuft unabgestimmt mit der Data & Analytics-Welt.

Entscheidungen im Rahmen von nicht abgestimmten Einzelinitiativen verursachen jedoch unnötige Kosten und gefährden die unternehmensweite Wertschöpfung von Daten. Da hilft nur eins: die unternehmensspezifischen Ziele des Datenmanagements zu definieren und die Umsetzung dementsprechend zu planen.

Es gilt, eine umfassende Datenstrategie zu entwickeln

Die Ziele des Datenmanagements sollten sich an der Unternehmensstrategie ausrichten. In diesem Rahmen können Dateninitiativen dann sinnvoll priorisiert und eingeordnet werden, so dass Transparenz geschaffen wird und alle Maßnahmen auf ein gemeinsames Ziel hinauslaufen. QUNIS hat ein Framework für die Datenstrategie entwickelt, die mit den folgenden drei Säulen bei der Entwicklung einer ausbalancierten Strategie hilft:

Scope
Architektur & Technologie
Organisation & Data Governance

Scope

Hier werden die datenorientierten Ziele des Unternehmens abgesteckt. Ansatzpunkte sind dabei datengestützte Prozessabläufe, Informationsbedarfe sowie digitale Produkte und Services des Unternehmens. Die Ziele, die derzeit in den Projekten am häufigsten genannt werden, sind effiziente Prozessketten, verlässliche Auswertungen durch hohe Datenqualität, Automatisierung im Datenmanagement oder die Entwicklung wettbewerbsfähiger Produkte und Services auf Basis hochwertiger Daten.

Empfehlung: Lassen Sie den ermittelten Scope vom Management bestätigen. Die Umsetzung der Strategie wird Kapazitäten erfordern und organisatorische Veränderungen bis in die operative Prozessebene mit sich bringen. Das Committent der Unternehmensleitung ist daher unabdingbar für die erfolgreiche Umsetzung.

Architektur & Technologie

Hier werden die Themenblöcke Stamm- und Metadatenmanagement, Backbone & Middle Layer sowie der Bereich Data & Analytics diskutiert. Besonders beim Stamm- und Metadatenmanagement gibt es immer wieder gewaltige Überraschungen beim Start der strukturierten Analyse. Die Fragen, wie man an bestimmte Daten herankommt, wer die Datenhoheit hat oder wo die Lücken in der Datenpflege liegen, können viele Unternehmen nicht klar beantworten. Von unternehmensweiter Transparenz sind die meisten Organisationen hier weit entfernt.

Im Bereich Backbone & Middle Layer geht es um Infrastruktur- und Technologie-Entscheidungen zur Verknüpfung von Systemen zu durchgehenden Datenplattformen. Ein wichtiger Themenblock in einer Datenstrategie ist natürlich der Bereich Data & Analytics mit seiner originären Aufgabe, Daten zu Analysezwecken in einer zentralen Plattform zu sammeln, aufzubereiten und zu verteilen.

Data & Analytics-Plattformen verarbeiten heute nicht mehr nur strukturierte Daten in klassischen BI-Analysen, sondern auch IoT-, GPS- oder Webdaten. Der Output können Reports zur internen Steuerung oder als Service für Partner, Lieferanten oder Kunden sein, aber auch Daten zur Speisung von ML-Cases und weiteren Systemen.

Organisation & Governance

Um eine standardisierte und skalierbare Data & Analytics-Plattform aufzubauen, ist die Etablierung einer strukturierten Data Governance zum geregelten Umgang mit den verschiedensten Datenformaten unverzichtbar. Data Governance versteht sich hier als integraler Bestandteil einer ganzheitlichen Datenstrategie, der den organisatorischen Handlungsrahmen für Einzeldisziplinen des Datenmanagements stellt. Wesentlicher Baustein ist das klassische Rollenmodell mit den Funktionen Data Owner und Data Steward auf operativer Ebene sowie den Leitungsfunktionen Data Board auf Teilkonzern-Ebene und dem Head of Global Data Governance auf Konzernebene.

In diesem Themenbereich liegt wahrscheinlich die höchste Sprengkraft, wenn das Datenmanagement in der Organisation verankert wird. Der Hauptgrund ist, dass die datenorientierte Organisation nicht der klassischen Linienorganisation der Fachbereiche entspricht. Der Einsatz von Business-Daten endet nicht an der Abteilungsgrenze von Sales, Finance oder HR. Die Daten werden vielmehr bereichsübergreifend in End-to-End-digitalisierten Prozessen genutzt und sollten daher auch von crossfunktional angesiedelten Datenexperten in einer Enterprise-Organisation verwaltet werden.

In einer mittleren bis großen Organisation lassen sich dabei heute nicht mehr alle Datenprozesse von einem einzigen zentralen Bereich stemmen. Datenexperten müssen stattdessen im gesamten Unternehmen verteilt sein und eng mit den Fachbereichen zusammenarbeiten. Deren Fachexpertise ist unbedingt nötig, um Daten hinsichtlich ihrer Wertschöpfung im Business und aus legaler Sicht korrekt zu beurteilen und sie optimal im Geschäftsprozess einzusetzen. Tatsächlich kann man bei vielen Unternehmen derzeit beobachten, dass vorhandene zentralisierte BI- oder Governance-Organisationen aufgebrochen werden, um sie breiter im Unternehmen anzulegen.

Orchestrierte Umsetzung auf Basis der Datenstrategie

Die operative Verankerung dieser Querschnittsfunktionen erfordert Durchsetzungskraft und Schulungen im gesamten Unternehmen, um ein unternehmensweites Bewusstsein für Daten als Wertschöpfungsfaktur aufzubauen und die nötige Akzeptanz für die datengetriebene Organisation im Tagesgeschäft zu erreichen. Hier geht es um nichts weniger als um einen echten Kulturwandel mit Blick auf die Daten, der am besten durch ein gezieltes Change Management begleitet wird.

Die datengetriebene Organisation ist nicht von heute auf morgen zu erreichen und Widerstände im Unternehmen sind absehbar. Die Datenstrategie ist jedoch ein sicheres Gerüst, zudem gibt sie die Roadmap für die schrittweise Umsetzung vor.

Im Rahmen der Datenstrategie können Unternehmen kleine Projekte angehen, in überschaubaren Schritten immer wieder Win-Effekte erzeugen und Mehrwerte liefern. Einzelinitiativen laufen auf dieser Basis orchestriert und ohne Redundanzen im Rahmen des entworfenen Big Picture.

Mein Tipp: Wenn Sie mehr über Datengetriebene Wertschöpfung und Datenstrategie wissen wollen, folgen Sie uns auf LinkedIn und Xing oder abonnieren Sie einfach unseren Newsletter. Oder kontaktieren Sie uns und schreiben Sie mir direkt über KONTAKT ich freue mich über den Austausch mit Ihnen!

Massive Parallelität und das Lakehouse

Erstellt am: Mittwoch, 27. September 2023 von Anja Gorbach

Hinter einer massiv parallelen Architektur steckt das Prinzip, dass Daten nicht mehr nur auf einer Maschine liegen, sondern auf beliebig vielen.

Die Idee dahinter: Wollen mehrere Klienten auf die selben Daten zugreifen, werden die Daten entsprechend repliziert. Eine aktuelle massiv parallele Architektur ist das Lakehouse. Es verteilt die Daten nicht nur auf mehreren Maschinen, sondern erlaubt auch den direkten Zugriff auf die Daten. Voraussetzung dafür ist, dass die Klienten ihre eigene Rechenleistung beitragen.

Jeder bringt seine Rechenleistung mit

In einem massiv parallelen System gibt es statt einer Datenbank, über die die gesamte Arbeit komplett mit teurer Rechenleistung abgewickelt wird, nur noch einen Data Lake als reinen und äußerst kostengünstigen Speicherplatz. In dieser neuen Architektur kann jeder Klient selbst in einem zentralen Register nach seinen Daten suchen und bringt die jeweils für die Abfrage notwendige Rechenleitung einfach mit. Daher verkraftet es das System sogar, wenn mehrere hundert Data Scientisten gleichzeitig darauf zugreifen.

In einem solchen Lakehouse können zudem problemlos polystrukturierte Daten gespeichert werden. Es stellt darüber hinaus mithilfe von Analytischen Tabellenformaten wie beispielsweise Apache Iceberg durchgängig sicher, dass diese stets konsistent sind. Auch wenn mehrere Klienten gleichzeitig auf dieselben Daten zugreifen, sie lesen oder ändern, besteht somit keine Gefahr eines korrupten Datenbestands. Zum Vergleich: Dies konnte der Bibliothekar nur garantieren, indem er darauf achtete, dass erst der eine liest und danach erst der andere eine Änderung vornimmt.

Für den Fall, dass ein Anwender nicht in der Lage ist, eigene Rechenleistung mitzubringen, oder Unterstützung für die Datenabfrage braucht, gibt es Dienste wie der des QUNIS-Partners Dremio. Sie stellen über eine Data Lake Engine bereits fertige Cluster zur Verfügung. Darüber kann beispielsweise ein Controller in seiner gewohnten Umgebung und auf einer anwenderfreundlichen Oberfläche so arbeiten, als würde er direkt auf die Datenbank zugreifen. Da diese Struktur ebenfalls massiv parallel aufgebaut ist, sind auch hier mehrere Zugriffe gleichzeitig möglich, ohne dass es zu Konflikten kommen kann.

Aus homogen wird heterogen

Die massive Parallelität geht unbestritten mit einer gewissen Komplexität einher. Vorher war die Welt homogen und dadurch relativ einfach: Es gab eine Lösung, eine Technologie, eine Datenbank und darüber ließen sich alle Probleme lösen. In massiv parallelen Strukturen hingegen muss sich jeder selbst um den Data Lake kümmern und zudem jedes Mal eigene Rechenleistung beisteuern.

Das kann man natürlich grundsätzlich als Nachteil ansehen. Heterogenität und Offenheit für unterschiedliche Technologien bieten aber auch Vorteile, wenn etwa mehrere Anwender im Zugriff auf dieselbe Datenbank problemlos völlig verschiedene Programmiersprachen nutzen können. In modernen datengetriebenen Unternehmen, in denen möglichst jeder Mitarbeiter mit Daten arbeiten soll, die in großer Zahl vorliegen, kommt man an einer solch hochskalierbaren Architektur ohnehin kaum mehr vorbei.

Die Cloud macht‘s erschwinglich

Massiv parallele Datenarchitekturen und Datenbanken gibt es übrigens schon seit den 1990er Jahren. Allerdings handelte es sich damals noch um rein proprietäre und dadurch sehr teure Technologien. Als Gamechanger zeigte sich die Mitte der 2010er Jahre die Entwicklung nichtproprietärer Technologien mit offeneren Architekturen. Jedoch waren diese für die meisten Unternehmen damals noch nicht so wichtig, weil häufig nur eine kleine Abteilung überhaupt mit Daten gearbeitet hat und auch die Datenmenge noch nicht annähernd so hoch war wie heute.

In den letzten Jahren hat sich dies enorm gewandelt: Mittlerweile will nahezu jeder Unternehmensbereich permanent Zugriff auf alle Daten sowie eigene Datenprodukte erstellen, selbstständig veröffentlichen und mit anderen teilen. Durch den stetig steigenden Bedarf waren die alten Architekturen daher ab einem gewissen Punkt nicht mehr tragfähig. Mit der Ablösung der teuren proprietären Systeme durch moderne Cloud-Architekturen, ist die Einstiegshürde naturgemäß deutlich niedriger.

So kann man zum Beispiel über ein Cloud-basiertes Pay-as-you-go-Modell sehr komfortabel und dazu kostengünstig mächtige Technologien nutzen und muss nicht erst Millionen-Euro-Beträge in technologisch aufgerüstete Serverschränke investieren. Stattdessen greifen die Anwender einfach on-demand auf die Daten zu, wenn sie sie brauchen, fahren dann entsprechend die Rechenleistung hoch und zahlen auch nur genau dafür.

Mag die massive Parallelität als Konzept relativ statisch sein, ist doch der Markt überaus dynamisch. Das Konzept wird in allen Bereichen kontinuierlich weiterentwickelt – so entstehen immer wieder neue Angebote und damit spannende Möglichkeiten, die es bislang nicht gab und die die Unternehmen in Zeiten von Big Data gewinnbringend nutzen können.

Data Lakehouse mit dem Modern Data Stack

Auch SENEC als einer der führenden Solarstromspeicheranbieter in Deutschland setzt auf einen Modern Data Stack und hat zusammen mit QUNIS ein Data Lakehouse aufgesetzt.

Die IT-Architektur ist ein Data Lakehouse auf Basis von Azure Databricks, das Elemente eines Data Warehouse mit einem Data Lake in der zentralen Plattform kombiniert. Die mit einer Staging und Cleansing Area, dem Core und einem Data Mart angelegte Lakehouse-Architektur ist in der Lage, Funktionen von Streaming Analytics, BI und maschinellem Lernen auf einer einzigen Plattform bereitzustellen.
Als Datenquellen sind u.a. eine Time Series Datenbank, eine Log-Datenbank, diverse relationale Datenbanken, SharePoint und klassische Business Systeme wie ERP, CRM usw. eingebunden. Zur Integration und Orchestrierung der Daten sind die Open-Source-Lösungen Airbyte und Airflow auf Kubernetes im Einsatz, zur Transformation von Daten im Lakehouse die Open-Source-Software dbt. Mit der kontinuierlichen Umsetzung neuer Use Cases werden schrittweise weitere Datenquellen angebunden. Die Anwender greifen über Microsoft Power BI auf die aufbereiteten Daten zu.
Power BI ist als strategisches Frontend für alle User im Einsatz. Das vielseitige Frontend unterstützt und visualisiert verschiedenste Use Cases in den Bereichen Unternehmens- und Marktinformationen sowie Produkt- und Qualitätskontrolle. Derzeit arbeiten von rund 550 Mitarbeitenden in Leipzig ca. 150 Konsumenten und Power User mit der BI-Lösung. Die Anzahl von aktuell 10 Designern soll kontinuierlich erhöht werden.

Mein Tipp: Wenn Sie mehr über Data Lakehouse und Parallele Architekturen wissen wollen, folgen Sie uns auf LinkedIn und Xing oder abonnieren Sie einfach unseren Newsletter. Oder kontaktieren Sie uns und schreiben Sie mir direkt über KONTAKT ich freue mich über den Austausch mit Ihnen!

QUNIS ist Top-Arbeitgeber bei Great Place to Work: Wir freuen uns und sind mächtig stolz!

Erstellt am: Montag, 6. April 2020 von Monika Düsterhöft

Platz 3 der besten Arbeitgeber in der ITK, Platz 4 der besten Arbeitgeber in Bayern, Platz 8 im kleinen Mittelstand

Das unabhängige Forschungsinstitut Great Place to Work (GPTW) setzt QUNIS in der Kategorie ‘Unternehmen mit 1 bis 49 Mitarbeitende‘ durchweg auf Top-Plätze und verleiht uns damit gleich drei tolle Auszeichnungen auf einmal. Wir sind stolz, glücklich und überwältigt über unsere hervorragenden Platzierungen. Sie belegen, dass unsere Werte „Qualität, Teamgeist, Spaß, Leidenschaft, Fairness und Vertrauen“ von innen heraus leben und bei unseren Mitarbeitern hoch angesehen sind.

Mit einem Trust-Index von 93 Prozent bestätigt unser Team eine äußerst hohe Zufriedenheit mit seinem Arbeitsumfeld

In der anonymen Online-Umfrage durch GPTW wurden verschiedenste Faktoren wie Glaubwürdigkeit, Respekt, Fairness, Stolz und Teamgeist bewertet. Unser Team wurde gefragt, in welchem Maß die Führungskräfte bei QUNIS auf sie eingehen und sie inspirieren, wie Work-Life-Balance, Gesundheit und Weiterentwicklung gefördert werden oder inwiefern und mit welchem Angebot das Unternehmen soziales Engagement und Diversität unterstützt. Zudem konnten die Mitarbeiter die Recruiting- und Start-Prozesse sowie das tägliche Arbeitsleben bei QUNIS beurteilen. In allen Kategorien lagen die Ergebnisse, zu unserer Freude, weit über dem Durchschnitt.

Super Klima. Wir wollen, dass das so bleibt und tun alles dafür!

Das unabhängige Kulturaudit des GPTW-Expertengremiums beschert unseren Unternehmenswerten und Maßnahmen zudem sehr gute und exzellente Bewertungen. Dies bestärkt uns darin, ganz besonders auch im Zuge unseres steten Wachstums, daran festzuhalten und unsere QUNIS-Werte weiter fest im Auge zu halten.

So haben wir im letzten Jahr auch ganz bewusst eine ausschließlich auf das Thema Personalentwicklung fokussierte, zusätzliche Ressource im HR-Bereich aufgebaut und unsere Maßnahmen und Programme weiterentwickelt. Im Bereich Gesundheit und Fitness zählen dazu beispielsweise das Angebot eines veganen Mittagsservices, die Anschaffung von E-Scootern an unserer Zentrale in Brannenburg oder gemeinsame Tabata-Sessions, abgehalten durch den Chef höchstpersönlich.

Darüber hinaus haben wir noch viele weitere Ideen im Kopf, die wir hoffen, bald umsetzen zu können. Für meinen Mit-Geschäftsführer Steffen Vierkorn und mich ist es regelmäßig ein Gänsehaut-Moment zu sehen, wie alle mitmachen und zusammenhalten und so dafür sorgen, dass hochtechnologisches Know-how und Menschlichkeit perfekt harmonieren.

Was es konkret bedeutet, ein so tolles Team zu haben, zeigte sich beispielsweise bei unserem Umzug in das neue Head Office in Brannenburg, bei dem ausnahmslos alle Hand anlegten. Und auch die ganz aktuelle Situation zeigt den großartigen Zusammenhalt: Wir arbeiten alle vom Homeoffice aus. Voll engagiert, technisch unabhängig und flexibel im Hinblick auf Kinderbetreuung oder Schichtsharing mit dem Partner.

Fokussiert, fachlich, hochkarätig und mit viel Spaß.

Das über zwanzig Standorte in Deutschland und Österreich verteilte QUNIS-Team arbeitet vor allem beim Kunden vor Ort, im Homeoffice oder im Rahmen thematischer Units und Thinktanks ohne die Notwendigkeit einer festen Standortbindung. In diesem Zusammenspiel ist es zudem wertvoll, einen zentralen Firmensitz zu haben, als „Come together“-Fixpunkt für unsere Service-Einheiten und das Backoffice-Team, für Meetings, Bootcamps und die regelmäßig stattfindenden Campus-Events.

Bei der Gestaltung unseres Head Offices haben wir daher auch viel Wert auf eine flexible Raumeinteilung mit offenen Bereichen, Mottoräumen im Feel-good-Ambiente für kreatives Wirken sowie Rückzugsecken für Telefonate oder Ruhe fordernde Tätigkeiten gelegt. Die Umgebung bis hin zum Mobiliar reflektiert den klaren Wunsch, für „Kopf und Körper“ ausreichend Freiräume zu schaffen. Ausgestattet mit einer großen Dachterrasse und Blick auf das idyllische Inntal und die umliegenden Berge, bietet das Office viel Platz für das QUNIS-typische Arbeiten. Über einen Besuch von Kunden, Partnern, Freunden und Familienangehörigen freuen wir uns jederzeit sehr.

Auch Lust auf QUNIS bekommen?

Wir begleiten Sie gerne bei allen Anforderungen rund um Data & Analytics. Nehmen Sie einfach KONTAKT mit uns auf. Oder möchten Sie ein Teil unseres Consulting-Teams werden? Dann werfen Sie doch gerne einen Blick auf unsere AKTUELLEN JOB-ANGEBOTE

Self Service Business Intelligence will gelernt sein

Erstellt am: Donnerstag, 7. Dezember 2017 von Monika Düsterhöft

Es war um das Jahr 2010 als das Schlagwort Self Service im Markt für Business Intelligence die Runde machte. Das Thema wurde zunächst stark von Herstellern wie Microsoft, Tableau oder QlikView getrieben, während diese Anforderung in Anwenderunternehmen noch selten formuliert wurde. So mussten wir denn auch in der Beratung häufig zunächst ein Grundverständnis für Self Service BI (SSBI) schaffen, welche Vorzüge SSBI bieten könnte. Vielen Anwendern war gar nicht bewusst, wo SSBI anfängt und wo es endet. Seitdem hat es sich mehr und mehr etabliert und ist aus keinem Projekt mehr wegzudenken.

Selbst wenn es zu Beginn nicht explizit vom Kunden gefordert wird, zeigt sich bei der Ausarbeitung der Anforderungen, dass hier Bedarf besteht. Anwender, meist so genannte Power User, wollen sich ihre Daten immer häufiger selber erschließen und Analysen und Reports erstellen – eigenständig und unabhängig von der IT. Entsprechend wird erwartet, dass eine Business-Intelligence-Lösung und Technologie diese Nutzer bestmöglich unterstützt.

SSBI erfordert Erfahrung im Umgang mit Daten

Doch Self Service Business Intelligence ist kein Selbstläufer, sondern bedeutet für alle Betroffenen ein Umdenken. Man kann dem Anwender nicht ohne Anleitung einfach Werkzeuge an die Hand gegeben, damit er sich seine Daten selbst erschließt oder Reports erstellt. Es ist für ihn ungewohnt oder neu, sich jetzt mit den Tools sowie Fragen auseinandersetzen zu müssen, die Ihm sonst die IT abgenommen hat. Hilfe bei der Nutzung des BI-Frontends als auch die Datenintegration sind daher bei SSBI vonnöten.

Die gilt im noch stärkeren Maße bei der Datenexploration. Diese ist dann sinnvoll, wenn wenig über die Daten bekannt ist und die Explorationsziele nicht genau spezifiziert sind. Der Nutzer muss dann mit Hilfe von Methoden und Verfahren aus dem Gebiet der Advanced Analytics diese Daten selbstständig erforschen und Schlussfolgerungen ziehen können. Ebenso muss er im Explorationsprozess in der Lage sein, die Explorationsziele bei Bedarf verändern und anpassen zu können. Dies setzt viel Erfahrung mit Advanced Analytics voraus.

Ebenso mussten und müssen BI-Software-Hersteller lernen, wie sie SSBI in ihren Produkten am besten unterstützen. Manche Produkte konnten sich am Markt durchsetzen, andere verschwanden wieder. So konnte beispielsweise Microsoft in seinem BI-Stack anfangs nur wenige Tools für SSBI vorweisen: Excel, Power-Pivot, PerformancePointServices und die ReportingServices. Mit der Zeit gesellten sich zu diesen weitere Möglichkeiten hinzu durch MobileReports, PowerBI, PowerView, PowerQuery, AS-Tabular und DAX. PowerBI hat mittlerweile in seiner aktuellen Version sogar Künstliche Intelligenz integriert, um die Datenexploration zu vereinfachen (mehr zu PowerBI finden Sie hier).

IT muss Tools und Infrastruktur harmonisieren

Neben dem Anwender galt es auch für die IT umzudenken. Sie konnte nun nicht mehr einfach einen Cube entwickeln, dem nur mit Spezial-Wissen und als MDX-Experte die richtigen Zahlen zu entlocken waren. Nein, Cubes mussten auf einmal anwenderfreundlich sein! Dies setzte unter anderem voraus, dass man verstand, wie SSBI-Tools mit einem Cube umgehen, denn diese arbeiten eher per Drag-and-Drop mit Measures und Dimension auf den verschiedenen Achsen. Für selbstgeschriebene MDX-Abfragen war da kein Platz. Die IT muss daher Infrastruktur und Tools bestmöglich aufeinander abstimmen, soll SSBI in der Praxis funktioniere. In diesem Zusammenhang hört man gelegentlich auch von Self Service Data Integration (SSDI). Power-Pivot und AS-Tabular waren im Microsoft-BI-Stack die ersten Gehversuche, um den Anwendern die Integration von Daten aus verschiedenen Datenquellen zu einem Datenmodel zu ermöglichen. Dem Thema wird aber bislang noch zu wenig Aufmerksamkeit geschenkt, vielleicht auch weil die Tools dafür noch nicht die notwendige Flexibilität und Leichtigkeit bieten.

SSBI für den Power User

Selbst wenn alle genannten Voraussetzungen und Anpassungen gegeben sind, wird SSBI wohl auch künftig eine Domäne für Power User bleiben. Man muss schon ein gutes Verständnis über die eigenen Daten und Datenmodelle haben, um selbstständig arbeiten zu können. In den Projekten läuft es daher für gewöhnlich darauf hinaus, dass Power-User aus den Daten neue Erkenntnisse gewinnen und diese dann als Report den übrigen Endanwendern (Report-Konsumenten) zur Verfügung stellen.

Weitere Beiträge zu Entwicklungen in der Business Intelligence:

Vom guten Sinn eines Data Warehouse

Erstellt am: Freitag, 13. Oktober 2017 von Monika Düsterhöft

Natürlich kann ich meine Business Intelligence Reports, Ad-hoc-Abfragen und Analysen, ja sogar Self Service BI direkt auf Basis meines ERP-Systems erstellen bzw. durchführen. Dass diese Praxis jedoch ihre natürlichen Grenzen hat, merke ich spätestens, wenn die ERP-Anwender in Scharen zu mir strömen, um sich über fehlende Performance bei ihren Erfassungsarbeiten zu beschweren.
Oder aber dann, wenn ich – da ich ja für meine Reports nicht nur Daten aus einem System benötige, sondern auch diverse Ergänzungen und Zusatzberechnungen in meinen Reports unterbringen muss – mir ein nahezu unentwirrbares System aus zusätzlicher Logik gebastelt habe, welches ich mir für weitere Auswertungen im schlimmsten Fall immer wieder neu konstruieren muss.

Steigender Aufwand im Reporting ohne ein Data Warehouse

Auch macht mich die stetig zunehmende Aktualisierungsdauer meiner Reports alles andere als glücklich. Dass meine Berichte zwangsläufig immer langsamer laufen, da die Komplexität meiner Abfragen darin stetig zunimmt und ich immer mehr zusätzliche Logik darin verbaut habe, ist mir sehr wohl bewusst. Indes sehe ich bei meiner über die Jahre gewachsenen Landschaft mittlerweile kein Entrinnen mehr. Heißt es nicht: Never change a running System?
Ein weiterer schlimmer Nebeneffekt ist, dass ich einmal erzeugte Reports auf ewig aufheben muss, da ich diese Auswertung im Bedarfsfall nicht mehr zu einem bestimmten Stichtag wiederholen kann, denn die Daten haben sich mittlerweile geändert. Einmal gültige Zuordnungen, beispielsweise von Vertretern zu Kunden, sind Schnee von gestern und heute nicht mehr gleichermaßen zugänglich.

Data Warehouse mit praxiserprobter Methode aufbauen

All dies und noch unzählige weitere gute Gründe sollten Anwender darüber nachdenken lassen, was ein solides Data Warehouse für einen Wert bedeutet. Insbesondere wenn es auf einem so wohldurchdachten und nachhaltigen Konzept wie bei der QUNIS basiert. Zeit also, die eigene Business-Intelligence-Landschaft endlich auf stabile und profitable Beine zu stellen!
Wir von der QUNIS haben aufgrund all dieser Erfahrungen aus unzähligen erfolgreichen Projekten ein „Data Warehouse Framework“ geschaffen, das all die beschriebenen Probleme und Stolpersteine beseitigt. Es umfasst alle notwendigen Strategien und Methoden, mit denen sich die Daten in einem Data Warehouse optimal strukturieren, die bestmögliche Verarbeitungs- und Abfrage-Performance sowie eine umfassende Datenversionierung erzielen lassen, um jederzeit historisch korrekte Reports und vieles mehr zu erzeugen.

Neugierig geworden? Dann lassen Sie sich von unserer ganzheitlichen Methodik überzeugen! Rufen Sie uns doch einfach einmal unverbindlich an oder schreiben Sie uns eine Email! Wir freuen uns auf Ihre Anfrage!

Phone +49 8035 95790 0,
E-Mail info@qunis.de

Partitionierung des MS SQL Servers für das Data Warehouse – Teil 1

Erstellt am: Freitag, 9. Dezember 2016 von Monika Düsterhöft

Im Rahmen der QUNIS Beratung für Data Warehousing geben wir unseren Kunden auch Tipps zur Performance-Optimierung ihres Microsoft SQL Servers. Dabei spielt die richtige Partitionierung eine wichtige Rolle. Grundsätzlich ist eine Partitionierung sowohl relational wie multidimensional möglich. Während Letzteres häufiger Einsatz findet, ist gerade die relationale Partitionierung bei zeitintensiven Data-Warehouse-Verarbeitungsroutinen ein effektvolles Mittel zur Laufzeitverbesserung. Die relationale Partitionierung findet auf Tabellen Anwendung und bedeutet faktisch, dass die Tabelle physisch in einzelne Fragmente aufgeteilt wird. Es handelt sich aber nach wie vor logisch und abfragetechnisch um eine (1!) Tabelle.

Die einzelnen Fragmente sind die Partitionen. Diese können auf unterschiedlichen Dateigruppen liegen, was durch das Partitionsschema definiert ist. Wichtiger für das Verständnis ist jedoch, dass jeder Datensatz eindeutig zu einer bestimmten Partition zugeordnet werden kann. Das ist über die Partitionsfunktion einzustellen. Dazu ist ein Feld der Tabelle festzulegen, dessen Inhalt dieses für jeden Datensatz bestimmt, beispielsweise ein Datum. So ließe sich in der Partitionsfunktion für Data-Warehouse-Fakten festlegen, dass historische Daten in Jahrespartitionen und aktuelle Daten in Monatspartitionen abgelegt werden.

Partition Swichting zur Performance-Steigerung
Um auf dieser Basis tatsächlich signifikante Performance-Verbesserungen in der Data-Warehouse-Verarbeitung erzielen zu können, ist ein weiterer Aspekt zu beachten. Die alleinige Partitionierung hat keinerlei Effekt, wenn SQL-Server die anzusprechenden Partitionen nicht auf Basis des entsprechenden SQL-Statements ableiten kann. Daher ist bei der Erstellung der SQL-Anweisungen besondere Acht geboten. Um diese Gefahr auszuschalten, sollte alternativ zum Mittel des Partition Switching gegriffen werden. Hierbei werden einzelne Partitionen aus der Data-Warehouse-Tabelle in eine Arbeitstabelle für die Verarbeitung (löschen, einfügen, aktualisieren) herausgelöst (Switch out). Bedenken Sie hierbei, dass keinerlei Daten physisch bewegt werden, sondern dass die einzelnen Datenseiten in den Metadaten als zugehörig zur Arbeitstabelle statt zur Data-Warerhouse-Tabelle deklariert werden. Dadurch ist ein solches Partition Switching auch eine Angelegenheit eines Bruchteils einer Sekunde, egal wie viele Datensätze betroffen sind. Nach der Verarbeitung erfolgt das Partition Switching in umgekehrter Richtung (Switch in).

Wann lohnt sich Partition Switching?
Ab wann lohnt sich der Aufwand der Partitionierung verbunden mit Partitionsschema, Partitionsfunktion, zusätzlicher Arbeitstabelle und Partition Switching? Zunächst muss ein gewisses Datenvolumen vorhanden sein, ab dem es sich überhaupt lohnt, über den Einsatz nachzudenken. Die Angaben hierzu schwanken zwischen 20 und 60 Millionen Datensätze pro Tabelle. In der Praxis beschränkt sich das folglich auf Faktendaten. Sollten Sie also eine oder mehrere Faktentabellen in dieser Größenordnung und gleichzeitig Laufzeitprobleme in der Verarbeitung haben, lohnt sich der Einsatz der Partitionierung, die allerdings ausschließlich in der Enterprise Edition (gilt für relationale Partitionierung) verfügbar ist.

Was ist also nötig für einen Einsatz der Partitionierung auf relationalen Fakten und OLAP-Measure Groups? Lesen Sie weiter im zweiten Teil des Beitrags!