Archiv für die Kategorie Allgemein

Self Service Business Intelligence will gelernt sein

Erstellt am: Donnerstag, 7. Dezember 2017 von Sascha

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 Sascha

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

Weitere Beiträge zum Thema:

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

Erstellt am: Freitag, 9. Dezember 2016 von Sascha

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!