2015-06-03

Self-Service BI - eine Aufgabe für die IT Abteilung

Frage: Was müssen Sie tun, um Self-Service BI im Unternehmen zu einem Misserfolg zu machen?
Antwort: Überlassen Sie dieses Thema den Endanwendern

Mit Produkten wie PowerPivot, Power Query, Power View, SharePoint und Report Builder bietet Microsoft eine ganze Palette von Werkzeugen an, die den Fachabteilungen mehr Flexibilität und Unabhängigkeit von IT Spezialisten geben sollen. Im Rahmen meiner Arbeit habe ich nun schon mehrere Unternehmen erlebt, die diese Möglichkeiten einsetzen. Einige Initiativen waren sehr erfolgreich, andere sind weitgehend gescheitert.

Warum Self-Service BI ohne die IT Spezialisten nicht funktioniert

Der größte Irrtum in Bezug auf Self-Service BI ist, dass die Fachanwender nun auf einmal die Arbeit der IT Abteilung übernehmen könnten. Dies ist übrigens auch eine gelegentlich geäußerte Befürchtung von IT Spezialisten - ob sie denn nun arbeitslos werden, weil ihre Kenntnisse nicht mehr benötigt werden.

Das Gegenteil ist der Fall.

Aus den Augen der Fachanwender betrachtet ist das Versprechen der neuen Werkzeuge, nämlich mit ihren "eigenen Leuten" den Bedarf an Reporting und Datenanalyse abzudecken, die Befreiung von vielen lästigen Restriktionen der Unternehmens-IT:
  • fehlende Daten
  • langwierige, aufwändige Prozesse bis neue Daten in Reports erscheinen
  • unflexible Lösungen, die am tatsächlichen Bedarf vorbei gehen
  • hohe Kosten
Verlockende Aussichten. Ein Heer von Vertriebsleuten schürt diese Vision.

So kommt es, dass eine "ganz normale" Mitarbeiterin in einer Fachabteilung zunächst Rechnungs-Informationen in einer Excel Datei zusammenstellt, darauf ein PowerPivot Modell baut und erste Erfolge publiziert. Hoch motiviert bindet sie eine weitere Datenquelle ein, sagen wir eine CSV-Datei mit SAP Daten. Und eine weitere, nun eine Datenbank mit Abrechnungsinformationen. Hier unterstützt ein Access-erfahrener Kollege. Beide zusammen polieren das PowerPivot Modell auf, fügen ein paar DAX Ausdrücke hinzu und publizieren das Ergebnis in SharePoint. Ein großer Erfolg! Die Abteilung hat ihr eigenes Abrechnungs-Reporting unabhängig von der geschmähten IT Abteilung hinbekommen.

Noch etwas warten, dann ist der Punkt erreicht, wo ich für gewöhnlich ins Spiel komme. Denn im nächsten, spätestens im übernächsten Monat sind die selbst gebauten Reports nicht mehr so ganz korrekt. Unbeherrschbare DAX Ausdrücke, Fehler nach dem Aktualisieren der Daten, nur halb funktionierende Kennzahlen. Jetzt beginnt die eigentliche Arbeit: Fragen nach den Datenquellen, Aufräumen des PowerPivot Modells, Konsolidieren der Daten.

Was ist hier schief gelaufen?

Eigentlich haben die Anwender alles richtig gemacht. Nur haben sie die Komplexität der Aufgabe unterschätzt. Solange der überwiegende Anteil der Daten für ein PowerPivot Modell aus einer Datenbank kommt, ist alles überschaubar. Aber die Informationen aus Textdateien oder Excel Dateien abzurufen, aufzubereiten und mit den anderen Datenquellen zu harmonisieren, das wird mit jeder zusätzlichen Datei um ein Vielfaches aufwändiger. Die Fachabteilung findet sich auf einmal in der Modellierung von ETL-Prozessen wieder - etwas, worauf sie nicht vorbereitet waren und wofür sie auch keine Methodik kennen.

Die richtige Mischung macht's

Wir IT Spezialisten sehen solche Aufgabenstellungen mit anderen Augen. Datenmodellierung, ETL und Datenqualität sind dank Ralph Kimball bestens erschlossene Gebiete. Aber wir haben ja nun auch viel Zeit in unsere Ausbildung und in die Umsetzung der best practices investiert. Die Fallstricke der Modellierung und das erforderliche akribische Vorgehen beim Extrahieren und Laden von Daten in ein Data Warehouse haben wir in hunderten Stunden Projektarbeit kennengelernt. Das sind Aufgaben, die eine genaue Klärung, eine routinierte Umsetzung und geplante Tests erfordern. Nichts, was man "nebenbei" erledigen könnte. Der Lohn der Arbeit sind stabile, automatisch ablaufende Daten-Aktualisierungen und eine hohe Datenqualität.

Wenn wir den Fachabteilungen solche Datenquellen liefern, dann können sie diese tatsächlich einfach verwenden, um darauf ihr eigenes Reporting und ihre eigenen Analysen aufzusetzen. Dann können sie die Berichte schnell so gestalten, wie es ihren Bedürfnissen am besten entspricht. Und sie können sich auf die Zahlen verlassen. In so einer Umgebung ist es auch einfach, noch die eine oder andere Information aus einer zusätzlichen Datei oder aus dem Internet hinzuzufügen.

Um es ganz deutlich zu sagen: Dies ist ein Plädoyer für das klassische Data Warehouse! Das Data Warehouse stellt hoch qualitative Daten bereit, so dass Fachanwender einfach darauf zugreifen und sie nach Herzenslust miteinander verknüpfen können. Gerade in Zeiten von Self-Service BI kommt dieser Vorteil so richtig zum Tragen.

Was Self-Service BI tatsächlich leisten kann

Die erfolgreichen Self-Service BI Initiativen, die ich kennenlernen durfte, zeichnen sich alle durch ein Merkmal aus: Entscheidungsträger aus dem obersten Management wollten, unterstützten und überwachten die Maßnahmen.
Die nicht erfolgreichen Initiativen waren allesamt dadurch gekennzeichnet, dass sie entweder ausschließlich technisch betrachtet wurden ("mit den richtigen Tools kommt der Erfolg von selbst") oder dass sie nur von wenigen Personen getragen wurden ("was interessiert mich dieser neumodische Kram").

Die positiven Effekte für die Fachanwender wie Flexibilität, Geschwindigkeit und passgenaue Lösungen können sich nur dann einstellen, wenn diese Bedingungen gegeben sind:
  1. die Self-Service BI Initiative hat die volle Unterstützung durch das oberste Management
  2. die Ziele der Initiative sind allen Betroffenen klar
  3. der Erfolg oder Misserfolg wird durch das oberste Management engagiert überwacht
  4. die Fachanwender haben Zugriff auf ein hervorragend gepflegtes Data Warehouse (das ist mit Abstand der kostenintensivste Teil)
  5. die Fachanwender haben im Rahmen von Schulungen ihre neuen Werkzeuge gründlich kennengelernt
  6. die Fachanwender erhalten Unterstützung durch Mitarbeiter, die sowohl die Self-Service Tools bestens kennen als auch mit der IT Landschaft vertraut sind. Anwenderunterstützung, End User Computing, Daten Analysten, Business Analysten - wie auch immer die Rollenbezeichnung lautet - Menschen mit solidem und umfangreichem IT Hintergrundwissen aber auch mit einem Verständnis für die Anforderungen der Fachabteilungen schlagen Brücken. Sie unterstützen die Anwender beim Auffinden der für sie besten Datenquellen, bei komplexeren SQL Statements, bei ausgefeilten DAX Ausdrücken und sie erkennen vor allem, wann die Grenzen der Self-Service Tools erreicht sind und wann eine professionelle ETL Lösung erforderlich ist.
Wenn diese Voraussetzungen gegeben sind, dann entfalten die anfangs aufgezählten Tools eine belebende Wirkung. Dann erstellen pfiffige Mitarbeiter in den Fachbereichen auf einmal neuartige Reports und Analysen, die ein Unternehmen effizienter, profitabler, schneller und kundenfreundlicher machen können. Dann lösen sie das Versprechen von Self-Service BI ein. An jede dieser Lösungen, die ich unterstützen durfte, denke ich mit großer Begeisterung zurück.

Wenn das Management und die IT die richtigen Rahmenbedingen schaffen, dann ermöglichen sie die Erfolgsgeschichte von Self-Service BI. Arbeiten wir daran!

2015-03-31

Liste der SQL Server Fehlercodes

Eine Liste der Fehlercodes, die der SQL Server ausgeben kann, findet sich in der Dokumentation. Wenn Sie jedoch gerade keinen Zugriff aufs Internet haben, können Sie auch den SQL Server direkt fragen:

select * from sys.messages

Das ist sehr praktisch, wenn Sie einen Fehlercode  haben und den vollständigen Text der Fehlermeldung nachschlagen möchten. Oder wenn Sie die deutsche Fehlermeldung kennen und den englischen Text wissen möchten um ihn zum Beispiel in einer Suchmaschine einzugeben. Das ist möglich, weil die Tabelle sys.messages alle Fehlermeldungen in 22 verschiedenen Sprachen enthält.


Tabelle sys.messages enthält jede Fehlermeldung in verschiedenen Sprachen
Welche language_id zu welcher Sprache gehört, können Sie in einer anderen Systemtabelle nachschlagen:

select *
from sys.syslanguages


In der Spalte msglangid dieser Tabelle finden Sie den zu language_id korrespondierenden Wert. In welcher Sprache Sie die Fehlermeldungen sehen, hängt von den Ländereinstellungen auf dem Betriebssystem des Clients ab, der die Verbindung zum SQL Server aufgebaut hat. Wenn Sie die Sprache für eine Verbindung umstellen möchten, können Sie das mit diesem Befehl machen:

SET LANGUAGE FRENCH; 

Mehr zur SET LANGUAGE Anweisung finden Sie in der MSDN.

2015-03-01

SQL Server Migration Assistant (SSMA) und die Sortierreihenfolge der Datenbanken

Bei der Migration einer größeren Oracle Datenbank nach MS SQL Server haben wir den SQL Server Migration Assistant (SSMA) for Oracle in der Version 6 eingesetzt. Wirklich ein sehr hilfreiches Tool!

Laufzeitprobleme nach Umzug der Datenbank


Ein größeres Problem trat auf, nachdem wir die migrierte SQL Server Datenbank gesichert und auf einer anderen SQL Server Instanz wiederhergestellt hatten. Beim Ausführen von gespeicherten Prozeduren, die der SSMA generiert hatte, gab es auf einmal diesen Laufzeitfehler:

Msg 217, Level 16, State 1, Line 1
Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32).

Auf dem alten SQL Server funktionierten dieselben Funktionsaufrufe weiterhin fehlerfrei. Die Ursache musste also irgend etwas mit dem neuen Server zu tun haben.

Sortierreihenfolge als Fehlerursache


Um es kurz zu machen: Die Sortierreihenfolge der neuen SQL Server Instanz (Server Collation) war eine andere als auf dem alten Server. Dadurch hatte auch die Systemdatenbank master eine andere Sortierreihenfolge (Database Collation) als die auf dem alten Server. Erst einmal ist nicht ersichtlich, warum das zu Problemen führen könnte. Der Hintergrund ist Folgender: In der master Datenbank werden durch das SSMA Extension Pack drei Extended Stored Procedures installiert. Der vom SSMA generierte T-SQL Code verwendet Kompatibilitätsfunktionen (das sind die im Schema ssma_oracle), welche ihrerseits wiederum diese Extended Stored Procedures in master aufrufen.

Wenn die master Datenbank und die Benutzerdatenbank mit vom SSMA generierten T-SQL Code unterschiedliche Sortierreihenfolgen aufweisen, dann tritt reproduzierbar dieser Fehler auf.

Das Aufspüren dieser Fehlerursache hat unser Team viel Zeit gekostet. Vielleicht hilft diese Erläuterung ja jemandem, der ebenfalls auf dieses etwas exotische Problem stößt. Wir haben es übrigens beseitigt, indem wir die Sortierreihenfolge der Benutzerdatenbank umgestellt haben. Das ist einen weiteren Blog-Post wert, den ich in den nächsten Tagen schreiben werde.