Posts mit dem Label Business Intelligence werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Business Intelligence werden angezeigt. Alle Posts anzeigen

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!

2014-08-30

Business Analyse: Entscheidender Erfolgsfaktor in BI Projekten

Es ist ein unschätzbarer Vorteil meines Berufs, dass ich viele unterschiedliche BI Projekte erlebe. Interessanterweise sehe ich dabei einige Unternehmen, in denen BI Projekte fast immer sehr erfolgreich sind und andere Unternehmen, wo BI Projekte regelmäßig katastrophenähnliche Zustände annehmen. Unter "erfolgreich" verstehe ich Projekte, die im geplanten Zeitrahmen alle vorgesehenen Berichte und Analysen zur vollen Zufriedenheit der Anwender liefern und dabei mit dem veranschlagten Budget auskommen. Die nicht erfolgreichen Projekte hingegen liefern Ergebnisse nur verspätet und die Anwender sind damit dann auch noch unzufrieden. Wegen der wiederholten Terminverschiebungen und unerwarteten Arbeiten sieht sich der Auftraggeber gezwungen, das Budget immer wieder aufzustocken oder irgendwann das Projekt abzubrechen.

Wenn aber doch alle Verantwortlichen den Erfolg wollen, warum sind dann nicht alle Projekte erfolgreich? Was machen die erfolgreichen Unternehmen besser?

Es gibt eine augenfällige Gemeinsamkeit: Bei allen erfolgreichen  Projekten erhebt ein Business Analyst die Anforderungen und pflegt diese während des gesamten Projektverlaufs. In diesen Unternehmen ist es üblich, dass erst wenn die Anforderungen hinreichend geklärt sind (hinreichend mit Blick auf die Vorgehensweise wie plangesteuert oder agil), mit der Umsetzung begonnen wird. Alle Projektverantworlichen haben diese Regel verinnerlicht.
In den anderen  Unternehmen sind Aussagen wie diese an der Tagesordnung:
  • Für Analysen haben wir jetzt keine Zeit
  • Für Analysen steht kein Budget bereit
  • Wir wissen sowieso, was die Anwender brauchen
  • Das Projekt ist so klein, dass der Aufwand für eine Analyse sich nicht lohnt
  • Wir haben das immer so gemacht
Das Interessante ist, dass bei ALLEN so durchgeführten Projekten der Misserfolg gewiss ist.
 
Inzwischen hat sich in Bezug auf die Business Analyse weltweit bei immer mehr Unternehmen die Erkenntnis durchgesetzt, dass sie ein wesentlicher Erfolgsfaktor bei allen Projekten ist. Das International Institute for Business Analysis (IIBA) hat eine umfassende Herangehensweise erarbeitet mit zwei Zertifizierungen (hier finden Sie mehr) und kürzlich hat das Project Management Institute (PMI) ebenfalls eine entsprechende Zertifizierung herausgegeben (hier mehr).
 
Zum Schluss noch mein Lieblingsargument gegen den Einsatz von Business Analyse in BI Projekten: "Dieses Vorgehen schränkt das Team in seiner Kreativität ein." Seien Sie versichert, das Gegenteil ist der Fall! Immer wenn ich in einem Projekt mitarbeite, das aus dem Krisenmodus nicht herauskommt, sehne ich mich nach den gut analysierten Projekten, in denen wir unsere Energie nicht in die Bewältigung vorhersehbarer Probleme stecken mussten, sondern uns ganz dem Erarbeiten der fachlich, wirtschaftlich und technisch besten Lösung widmen konnten.
 

Webinar-Tipp

Am Donnerstag, den 4. September 2014, biete ich von 10:00 bis 11:00 Uhr ein Webinar "Anforderungsanalyse für Business Intelligence Projekte" an.

2014-06-05

Data Tools für Business Intelligence

Die Installations-DVD von SQL Server 2012 enthält - wie die vorherigen Versionen auch - als Entwicklungsumgebung für die BI-Komponenten eine Version von Visual Studio. Diese trägt zwar aus Marketing-Gründen die Bezeichnung "SQL Server Data Tools", ist aber nichts anderes als Visual Studio 2010 mit den Projektvorlagen für Business Intelligence Projekte (Reporting Services, Integration Services, Analysis Services).

Zwei Versionen der SQL Server Data Tools: VS2010 und VS2012

Seit März 2013 ist die Situation etwas komplizierter geworden, da es zusätzlich möglich ist, Visual Studio 2012 als BI Entwicklungsumgebung einzusetzen. Der korrekte Name für diese Version ist "SQL Server Data Tools – Business Intelligence for Visual Studio 2012". Diese neuere Version der Data Tools steht hier zum Herunterladen bereit:
http://www.microsoft.com/en-us/download/details.aspx?id=36843

Wenn zwei Versionen verfügbar sind, welche sollten Sie dann einsetzen? Glücklicherweise vertragen sich beide Versionen sehr gut, so dass ein Projektteam sogar beide gleichzeitig einsetzen kann:
  • Beide Versionen lassen sich nebeneinander auf einem Rechner installieren
  • Projekte können abwechselnd mal mit der neueren und dann wieder mit der älteren Version bearbeitet werden - es findet keine Konvertierung der Dateien statt
Sie haben also die freie Wahl, mit welcher Version Sie arbeiten.

Und was ist mit Visual Studio 2013?

Die Produktzyklen bei Microsoft werden kürzer, so ist bereits Visual Studio 2013 verfügbar und auch SQL Server 2014 ist bereits seit April auf dem Markt. Die gute Nachricht ist: Da es an den BI Komponenten von SQL Server 2014 keine Veränderungen gegenüber SQL Server 2014 gegeben hat, können Sie problemlos mit den "alten" Data Tools für SQL Server 2012 auch für SQL Server 2014 entwickeln.
Falls Sie die letzte verfügbare Entwicklungsumgebung einsetzen möchten, können Sie hier die "Microsoft SQL Server Data Tools - Business Intelligence for Visual Studio 2013 " herunterladen:
http://www.microsoft.com/en-us/download/details.aspx?id=42313

Zusammenfassung

Diese Matrix stellt das vorher Beschriebene in kompakter Form dar:

  Visual Studio 2010 Visual Studio 2012 Visual Studio 2013
SQL Server 2012 auf Installations-DVD SSTD-BI für SQL Server 2012 --
SQL Server 2014 -- SSTD-BI für SQL Server 2012 SSTD-BI für SQL Server 2014

Einfache Installation

Die Installation ist unkompliziert. Nach dem Download und Start der Installationsdatei sollten Sie die Standardeinstellung "Perform a new Installation..." belassen, wie das folgende Bild zeigt (die andere Option führt zu einem Abbruch der Installation).

Diese Standardeinstellung sollten Sie nicht ändern

Danach stehen die Data Tools als Shared Feature für die Installation zur Verfügung.

Außer dem Setzen dieses Hakens gibt es keine weiteren Auswahlmöglichkeiten




Quelle:
http://blogs.msdn.com/b/mattm/archive/2013/03/07/sql-server-data-tools-business-intelligence-for-visual-studio-2012-released-online.aspx

2014-05-20

Freigegebene Datenquellen und Datasets richtig einsetzen

Reporting Services (SSRS) bieten ja die Möglichkeit, zwei unterschiedliche Entwicklungsumgebungen für Berichte zu verwenden:
  • Report Designer in Visual Studio (bzw. "Business Intelligence Studio" oder "Data Tools", wie es aus Marketinggründen heißt, wenn es mit SQL Server installiert wird)
  • Report Builder, den berechtigte Anwender selbst von SharePoint oder vom Report Manager herunterladen und nutzen können
Report Builder mit seiner an Office Anwendungen angelehnten Oberfläche für Fachanwender

Während Report Designer eher das Werkzeug für IT-Profis ist, soll der Office-ähnlich aufgemachte Report Builder Mitarbeitern in den Fachabteilungen die Möglichkeit geben, selbständig Berichte zu erstellen. Eine gute Ergänzung, die gleichermaßen der Forderung nach qualitätsgesicherten Standard-Berichten von der IT-Abteilung und dem Bedürfnis nach hoher Flexibilität für die Fachanwender gerecht wird.

Nun haben IT-Verantwortliche naturgemäß Schwierigkeiten damit, allen Anwender direkten Zugriff auf die Unternehmensdatenbanken zu gewähren. Das ist ja auch nachvollziehbar, denn in diesem Fall könnten einzelne Berichtsautoren durch (ungewollt) massive Datenbankabfragen die Verfügbarkeit für alle Anwender gefährden. Hier kommen freigegebene Datenquellen (shared data sources) und freigegebene Datasets (shared datasets) ins Spiel. Datenquellen enthalten die Verbindungszeichenfolge zu einer Datenbank (Server, Datenbank, Benutzername und Passwort), während Datasets die SQL Abfrage enthalten. Das ermöglicht eine klare Rollenverteilung:
  • Alle Anwender, die direkten Zugriff auf eine Datenbank haben, dürfen freigegebene Datenquellen und freigegebene Datasets hierfür erstellen und modifizieren.
  • Anwender, die keinen Zugriff auf eine Datenbank haben, können dennoch die freigegebenen Datenquellen und die freigegebenen Datasets in eigenen Berichten nutzen.
  • Wenn Anwender ohne Zugriff auf eine Datenbank versuchen, eine Datenquelle oder ein Dataset zu verändern, erhalten sie die Aufforderung, einen Datenbankbenutzer samt Passwort anzugeben.
Auf diese Weise ist sichergestellt, dass nur eingewiesene Programmierer die SQL Abfragen erstellen. Die IT Verantwortlichen behalten so die Kontrolle über die Art des Zugriffs auf die Datenbank. Gleichzeitig können Fachanwender auf Basis dieser Datasets ihre eigenen Berichte erstellen.

Wäre noch zu klären wie es sein kann, dass Fachanwender ohne direkten Datenbankzugriff dennoch über die vorhandenen Datenquellen und Datasets die Berichtsdaten abrufen können. Dazu muss ein Mitglied der Rolle "Content Manager" auf dem Report Manager den Eigenschaften-Dialog der Datenquelle öffnen.

Hier erhält die Datenquelle Zugriff auf die Datenbank

Der Benutzername und das Kennwort des hier angegebenen Benutzerkontos werden verschlüsselt auf dem Berichtsserver gespeichert. Bitte achten Sie darauf, hier einen technischen Benutzer und nicht die Anmeldeinformationen eines echten Mitarbeiters anzugeben, denn wenn dieser sein Kennwort ändert, dann funktioniert die Datenquelle nicht mehr.
Diese Funktionsweise von freigegebenen Datenquellen und Datasets ist unabhängig davon, ob Reporting Services im nativen Modus ("stand-alone") oder im SharePoint integrierten Modus laufen. Einziger Unterschied ist, dass im ersten Fall die Webanwendung "Berichts-Manager" den Speicherort für Quellen, Datasets und Berichte bereitstellt und im zweiten Fall SharePoint Bibliotheken diese Aufgabe übernehmen.

2013-06-09

Kostenloses Webinar: Anforderungsanalyse in BI-Projekten

Nicht nur um BI-Projekte erfolgreich umzusetzen, ist die Erhebung, die Analyse, die Nachverfolgung und schließlich die Umsetzung der Anforderungen in der richtigen Reihenfolge unabdingbar. Das BABOK® bietet eine Sammlung der Methoden und Techniken, mit denen dies erreicht werden kann. Im Vergleich zu anderen Arten von Projekten gibt es jedoch bei BI-Projekten ein paar Besonderheiten zu beachten.

Das Gratis-Webinar liefert einen Überblick zum richtigen Vorgehen, so dass Sie die typischen Stolperfallen vermeiden können.

Referenten

Rainer Wendt, Geschäftsführer von masVenta, und ich werden in knapp einer Stunde das Wichtigste zu diesem Thema anschaulich vermitteln.

Für alle, die tiefer einsteigen möchten, bietet masVenta ein tiefer gehendes zweitägiges Seminar an, in dem die Teilnehmer anhand eines praxisnahen Beispiels ihr Wissen ausbauen können.

Das Webinar

Hier können Sie sich anmelden: https://attendee.gotowebinar.com/rt/2552418737743036672
Und hier finden Sie das masVenta Seminar: http://www.masventa.eu/academia/anforderungsanalyse-fuer-business-intelligence-projekte/

2013-03-17

SSIS: Cubes als Datenquelle

Mit Integration Services lassen sich Daten aus unterschiedlichsten Quellen zusammenführen - klar. Aber wie sieht es eigentlich mit Daten aus, die aus SSAS Cubes kommen?

Das Problem

Eigentlich sollte es kein Problem geben: Sie erstellen einen OLE DB Connection Manager zu der SSAS Datenbank und verwenden diesen in einer OLE DB Datenquelle. Das sieht zunächst auch gut aus, sieht man von der Warnung ab, die darauf hinweist, dass alle Spalten in den Datentyp DT_WSTR umgewandelt werden.
OLE DB Datenquelle (Analysis Services)

Ein MDX Statement anstelle eines SQL Statements geht auch
Der Button "Preview" liefert (nach einer Warnung wegen der Typumwandlung) auch die Vorschau der Daten wie erwartet. Wenn Sie jedoch den Datenfluss ausführen, dann gibt es einen Laufzeitfehler, dessen Ursache nicht klar im Protokoll zu erkennen ist.

Lösung (1)

Connection Manager haben eine Reihe von Eigenschaften, die man erst dann sieht, wenn man nach einem Doppelklick auf den Connection Manager die Schaltfläche "Data Links" anklickt.
Der Button "Data Links" führt zu den Eigenschaften der Verbindung
Dort wählen Sie den Reiter "Alle", um alle Eigenschaften zu sehen und wählen Sie dann die Eigenschaft "Extended Properties" aus. Geben Sie hier den Text "Format=Tabular" ein, wie auf dem nachfolgenden Bild zu sehen.
Für die Eigenschaft "Extended Properties" muss der Wert "Format=Tabular" eingestellt werden, damit die OLE DB Datenquelle MDX Abfragen fehlerfrei ausführt.
Wenn sie nun den Datenflusstask ausführen, gibt es keinen Laufzeitfehler mehr.
Diesen wertvollen Tipp verdanke ich Sherry Lis Blog.

Lösung (2)

Eine überraschend einfache Alternative ist die Verwendung einer ADO.NET Datenquelle anstelle der OLE DB Datenquelle. Dort tritt der Fehler gar nicht erst auf.

2013-02-04

PowerView für Cubes

Power View ist ein schicker Berichtsgenerator für Endanwender, den Sie verwenden können, wenn Sie SharePoint Enterprise 2010 oder 2013 in Verbindung mit SQL Server 2012 einsetzen.
Mit der aktuellen Version von PowerView gibt es allerdings eine schmerzhafte Einschränkung: Als Datenquelle können ausschließlich tabulare Modelle verwendet werden - also PowerPivot für SharePoint oder SSAS Tabular. Daten aus multidimensionalen Cubes (SSAS Multidimensional) kann Power View nicht darstellen. Das ist eine schmerzhafte Einschränkung, da zum jetzigen Zeitpunkt (und sicher noch viele Jahre) die meisten Unternehmensdaten in Cubes aufbereitet sind.

Aber Abhilfe ist in Sicht:
Inzwischen stellt Microsoft die CTP (common technology preview) eines neuen Produkts für Testzwecke zum kostenlosen Download bereit.
Power View for Multidimensional Models - Preview

Zwar wird ausdrücklich kein Termin für die Veröffentlichung des endgültigen Produkts oder einer SQL Server Release genannt, aber die wichtige Botschaft ist damit offiziell: Wir werden Power View zukünftig auch für Berichte mit Daten aus multidimensionalen Quellen einsetzen können.

2012-11-19

BI Vortragsreihe bei den Access/SQL Kompetenztagen

Heute ein Hinweis in eigener Sache: Auf den Access/SQL Kompetenztagen darf ich drei Tage lang meine aktuellen Lieblingsthemen zu Business Intelligence präsentieren!
  • Der Microsoft BI-Stack im Überblick (SQL Server, SharePoint, Excel, PowerPivot und das Zusammenspiel dieser Komponenten)
  • Berichte mit Reporting Services erstellen
  • Mit PowerPivot große Datenmengen analysieren
Und das im Zusammenspiel mit vier weiteren erfahrenen, unterhaltsamen Trainern, die ein breites Spektrum von Themen zu Access und SQL Server vermitteln. Das Besondere an dieser Veranstaltung ist, dass alle Trainer bis in den Abend hinein für individuelle Fragen zur Verfügung stehen. Die Stimmung bei den Anwendertagen ist immer wieder ein Erlebnis.

Ist das interessant für Sie?
Vielleicht sehen wir uns dort?
Ich freu' mich drauf!

2012-10-14

Neues Seminar: Der Microsoft BI-Stack

Die Anfrage kam sehr kurzfristig und sehr nachdrücklich: Ein Kunde benötigte dringend eine kompakte Übersicht über den gesamten Microsoft BI-Stack. Das Unternehmen musste innerhalb kurzer Zeit den Prototypen einer spezialisierten BI-Anwendung erstellen und hatte sich für die Standard-Architektur von Microsoft SQL Server in Kombination mit SharePoint entschieden.
Nun brauchten alle Projektbeteiligten in kürzester Zeit einen Überblick. Der technisch Verantwortliche musste wissen, wie die Komponenten am besten kombiniert werden, der Projektleiter musste ein Gefühl für den Aufwand und den Ressourcenbedarf bekommen und die Entwickler wollten genauer verstehen, mit welchen Werkzeugen sie arbeiten würden und wie sie die Aufgaben verteilen sollten.
"Zufällig" hatte ich eine passende Trainingsumgebung bereit und so entstand übers Wochenende das Konzept für diese Schulung. Die Durchführung dieses Seminars hat mir so große Freude gemacht und wurde von den Teilnehmern so begeistert aufgenommen, dass ich es nun weiter ausgebaut habe und ganz offiziell anbieten möchte.

Dieses Seminar möchten Sie auch besuchen? Sprechen Sie mich an - die Planungen für 2013 laufen gerade an!

2012-08-31

Vergleich der Berichtslösungen im Microsoft BI Stack

SQL Server 2012, SharePoint 2010 und Office 2010 sind Microsofts Standard-Bausteine, mit denen wir unternehmensspezifische Business Intelligence Lösungen erstellen können. Im Lauf der Programmversionen ist diese Welt immer vielfältiger geworden.

Welche Anwendungen sind für welche Anforderungen besonders geeignet?

Die nachfolgende Tabelle zeigt einige wichtige Eigenschaften der Microsoft Berichtslösungen. Jede hat ihre Stärken und ihre Grenzen. Welche stehen für Ihre Endanwender im Vordergrund? Oft gibt es ja auch unterschiedliche Gruppen von Anwendern, die unterschiedliche Anforderungen stellen.


SSRS
Power View
Excel
Excel Services
Performance-Point Services
Klassischer Berichtsserver
X
Freie Gestaltungs-möglichkeit
X
(X)
Hochwertige Ausdrucke
X
X
X
(X)
Abonnements
X
Datenabhängige Alarme
X
Erkundung des Datenmodells
X
X
(X)
Gestaltungs-möglichkeiten für Endanwender
X
X
(X)
Zusammenstellen von Dashboards
X
Zugang mit Web Browser
X
X
X
X
Mobile Endgeräte
X
(X)
(X)
SharePoint Enterprise Lizenzen
X
X
X
SQL Server Enterprise oder
BI Edition
X
Exportformate
viele
Power
Point
viele
Excel
Excel


War das schon alles?

Gib es weitere Entscheidungskriterien, die Sie hier vermissen? Lassen Sie es mich wissen und ich nehme diese gerne in die Liste auf!

SharePoint 2010 und SQL Server 2012

Der Treiber macht's...

Heute möchte ich über ein Problem berichten, das auftritt, wenn man mit Power View oder PerformancePoint Services auf tabulare Modelle (PowerPivot auf SharePoint oder SSAS Tabular) zugreifen möchte.

Die Theorie

Tabulare Modelle lassen sich von außen mit MDX abfragen. Daher können "alte" MDX-Clients (z.B. Excel) problemlos auf Modelle zugreifen, die
  • mit PowerPivot erstellt und in einer SharePoint Bibliothek veröffentlicht wurden
  • oder mit den Data Tools in einem Projekt vom Typ "Analysis Services Projekt für tabellarische Modelle" erstellt und dann auf einer tabularen SSAS Instanz bereitgestellt wurden.
Besonders interessante Clients sind für mich zurzeit die SharePoint Komponenten Power View und PerformancePoint Services.

Die Praxis

Tatsächlich gibt es aber ein Problem, das mich heute viel Zeit gekostet hat. Es zeigt sich anhand unspezifischer Fehlermeldungen in diesen Situationen:
  • Beim Einrichten einer Datenverbindung in SharePoint vom Typ "BI Semantic Model Connection" (Fehlermeldung: "Cannot connect to the server or database")
  • In PerformancePoint Services beim Erstellen einer Datenverbindung (Fehlermeldung: "PerformancePoint Services was unable to connect to <Instanz>. Verify that the server name is correct and that the Unattended Service Account has permission to connect to the server.")
Mehrfaches Überprüfen der Verbindungsinformationen brachte mich nicht ein Stück weiter - diese waren offensichtlich korrekt.

Die Lösung

Nach einer Standardinstallation von SharePoint 2010 gibt es ein Kompatibilitätsproblem: Für den Zugriff auf eine SQL Server Analysis Services 2012 Instanz im tabularen Modus benötigt der SharePoint Frontend Server den ADOMD Treiber aus dem Feature Pack von SQL Server 2008 R2 SP1. Darauf muss man erst einmal kommen!
Sie können auf Ihren SharePoint Servern unter "Programs and Features" kontrollieren, welche Version des ADOMD Treibers installiert ist. Nach der SharePoint Installation hat der Treiber die Version 10.0x. Benötigt wird aber die Version 10.5x.

Liste der ADOMD Treiber auf einem SharePoint Frontend Server
Den richtigen ADOMD Treiber können Sie hier herunterladen:
http://www.microsoft.com/en-us/download/details.aspx?id=26728
Je nachdem, ob Sie SharePoint auf einer 32-Bit Plattform oder auf einer 64-Bit Plattform installiert haben, brauchen Sie die passende Variante
64-Bit: 1033\x64\SQLSERVER2008_ASADOMD10.msi
32-Bit: 1033\x86\SQLSERVER2008_ASADOMD10.msi

Bei der Installation gibt es eine Warnung (die ältere Version des Treibers wird überschrieben - das ist in Ordnung) und möglicherweise den Hinweis, dass eine Datei nicht ausgetauscht werden kann, weil sie in Benutzung ist. In diesem Fall stoppen Sie den Internet Information Server. Das geht am einfachsten mit dem Programm "Internet Information Services (IIS) Manager".
Nach Stoppen (falls nicht schon erfolgt) und Starten des IIS Dienstes ist das Problem beseitigt.
Das Stoppen und Starten des IIS Dienstes geht alternativ auch über den Kommandozeilenbefehl "iisreset /STOP" beziehungsweise "iisreset /START".

Anmerkung

Natürlich liegt es nahe, bei einem solchen Problem mal wieder über Microsoft zu schimpfen und sich zu fragen, warum "die" das denn nicht besser hinbekommen. Geht Ihnen das auch so? Dann empfehle ich die Lektüre dieses Artikels von Kevin Donovan. Danach wurde mir klar, welche Kompatibilitätsprobleme SharePoint zu bewältigen hat, schließlich soll SharePoint 2010 ja gleichermaßen mit PowerPivot 2008 R2 und mit PowerPivot 2012 funktionieren.
Mein Fazit war danach: Das ist sehr nachvollziehbar und die Microsoft Entwickler haben einen guten Job gemacht!