5 Probleme mit Ihrem Datenmanagement – und wie Sie sie lösen können.
Der SQL Server ist der Motor unseres Datenmanagements. Damit dieser Motor jedoch richtig läuft, muss man ihm die Daten in klar definierten Strömen zuführen. Viele Anwender nutzen Excel, SharePoint und BI falsch oder zu wenig. So ist der Datenzufluss nicht optimal aufgebaut und sie verschwenden Zeit. Wir beleuchten fünf Fallstricke, über die Sie beim Aufbau einer Daten-Infrastruktur stolpern können.
Problem Nummer 1: Sie nutzen kein Enterprise BI
Für jeden, der bereits Microsoft-Produkte wie Dynamics CRM, Dynamics Navision, Dynamics AX oder SharePoint im Einsatz hat, sollte ein Designziel für die Enterprise BI sein, sich soweit wie möglich vom ERP-System unabhängig zu machen. Lassen Sie die Daten an den Quellen, versuchen Sie nicht alles abzulösen und in SharePoint neu aufzubauen. Nutzen Sie den SharePoint dazu, worin seine Stärke liegt: Informationen an einem Punkt zu teilen. Im Bereich Enterprise BI spielt der SharePoint Server zusammen mit dem SQL Server eine wichtige Rolle.
Die Performance Point Services, Power View, der Dashboard Designer, all das sind wichtige Services bzw. Tools, mit denen Sie dem jeweiligen Zielgruppen-Controller, dem IT-Leiter, der Vertriebsleitung oder dem Vorstand die richtige Sicht auf Ihre Daten ermöglichen können.
Der SQL Server mit seinem BI Stack im multidimensionalen oder tabularen Modell bietet gerade hier technisch ausgereifte professionelle Möglichkeiten. Setzen Sie auf Enterprise und Self-Service-BI gemeinsam, nutzen Sie in Zukunft das gesamte Potenzial des SQL Servers und nicht nur einzelne Segmente für Ihre BI. Denn wenn Sie dieses erste Problem beheben, ergeben sich zahlreiche andere Probleme gar nicht erst.
Ignoriert man die Probleme seines Datenmanagements, gleicht der SQL Server bald einem rostigen Motor.
Problem Nummer 2: Ihr Datenmanagement-System ist Excel
In vielen Firmen ist Excel für das Datenmanagement zuständig. Die Schwachstellen dieser klassischen Tabellenanwendung werden schnell deutlich. Daten werden aus den unterschiedlichsten Quellen in Excel eingespielt: Maschinen, ERP-Systeme, CRM, Web und Shops produzieren laufend Daten, die nicht verloren gehen dürfen. Auch aus der Produktion und dem Controlling kommen Datenmengen, aus denen sich sinnvolle Informationen gewinnen lassen. In den letzten Jahren kommen dann noch unstrukturierte Daten dazu: der Trend-Begriff Big Data verdeutlicht, dass automatisierte Prozesse Unmengen an Daten sammeln, die jedoch noch strukturiert werden müssen, bevor man sie nutzen kann. Die Komplexität erhöht sich um ein Vielfaches.
Excel erfüllt seinen tatsächlichen Zweck als Frontend sehr gut – man muss sich jedoch immer wieder klarmachen, dass es keine Datenbank ist. Setzt man Excel dennoch ein um Daten auszutauschen, müssen viele Dinge manuell erledigt werden, die sich ansonsten automatisieren ließen. Dadurch verliert der Anwender Zeit – und alles, was Menschen statt Maschinen erledigen, ist fehleranfällig. Beispielsweise werden in Excel Formate nicht validiert und Fehler bleiben unentdeckt. Um dies zu umgehen, ließe sich beispielsweise die XML-Schema-Validierung einsetzen, oder eine Stufe davor im Bereich der ETL-Prozesse reguläre Ausdrücke verwenden.
Excel kann seine volle Stärke ausspielen, weil es als Frontend fast überall vertreten ist. Diese universelle Vertrautheit im Umgang und die einfache Formelsyntax sind nicht zu unterschätzende Vorteile. Interessant ist vor allem, dass noch nicht jeder den Unterschied zwischen Pivot-Tabellen und dem Begriff Power Pivot kennt. Hier wird es jetzt richtig interessant, da sich daraus völlig neue, professionelle BI-Lösungen mit Excel aufbauen lassen.
Microsoft bietet hier mit Power Query, Power Pivot, Power Map und Power View einen Self-Service BI Stack an, der auch den letzten Excel-Kritiker überzeugen dürfte und das Herz eines Controllers höherschlagen lässt.
Führt man ein solches Self-Service BI Tool ein, gewinnt man Zeit und Produktivität. Nutzer können auch komplexere Abfragen dank der einfachen Syntax von DAX selbst ausführen, ohne MDX lernen zu müssen, auf einen Consultant angewiesen zu sein, oder die IT-Abteilung einbeziehen zu müssen. Die letzteren wird’s freuen, dass sie sich wieder auf ihre Kernaufgaben konzentrieren können und das Thema Berichte wieder dort angesiedelt ist wo es hingehört.
Problem Nummer 3: Sie planen mit Excel
Plant man mit Excel, wird es spätestens dann problematisch, wenn die entstandenen Daten in SharePoint-Listen ausgewertet werden sollen. Nicht dass es hierfür keinen Lösungsansatz gäbe, doch wenn Listen nur aus dem Gesichtspunkt der Ablage von Informationen erstellt werden, weil es in SharePoint ja so schön einfach ist, kann man später etwas auf die Nase fallen.
Welchen Bezug haben dann die Daten zu meinen Stammdaten? Kann ich die Informationen zu meinen einzelnen Projekten aggregieren und der BI zugänglich machen? Verfüge ich über eine saubere, gut automatisierbare Infrastruktur? Frieren mir Workflows die Projektstände zum Monatsende automatisch ein, machen diese aggregierbar und das laufende Projekt geht ungestört weiter?
Genau hier passieren im Zusammenspiel von Excel und SharePoint häufig Fehler, die sich mit Weitblick und Kompetenz in den Bereichen SQL Server, Excel, SharePoint, Performance Point Services und Workflows hätten vermeiden lassen.
Die Planungsdaten in Excel sollen für Soll-Ist-Vergleiche zur Verfügung stehen und in das gesamte Szenario eingebunden werden: Ist-Daten kommen aus Prozessen im CRM, aus dem ERP-System oder durch Maschinen. Diese müssen automatisiert eingebunden werden, um dann im zentralen Enterprise-BI zur Verfügung zu stehen.
Plant man mit Excel, müssen diese Planungsdaten mit den restlichen Unternehmensdaten zusammengeführt werden. Bezieht man von Anfang an die Self-Service BI-Tools von Excel mit ein und berücksichtigt das in der gesamten Architektur, vereinfacht das das Ganze wesentlich.
Sonst kommen auf jeden Fall zusätzliche Schritte ins Spiel, weil die Daten zunächst zusammengeführt werden müssen, damit sie auswertbar sind. Dies kann auf zwei Wegen geschehen.
Die traditionelle Methode ist es, dass man die Daten aus Excel nimmt und sie in relationale Datenbanksysteme überführt, wodurch sie dann im Data Warehouse (DWH) landen. Hier werden überwiegend ETL-Prozesse eingesetzt, die diesen Vorgang automatisieren und auch gleich die Aufbereitung für das DWH und den CUBE übernehmen.
Bezieht man jedoch stattdessen von Anfang an die Self-Service BI Technologien von Excel und dem SQL Server ein, ist es nicht zwingend notwendig diese ETL-Prozesse überhaupt durchzuführen – sodass die Daten für eine Adhoc-Abfrage sofort verfügbar sind.
Jeder Infrastruktur- oder Softwarearchitekt, Controller oder IT-Leiter, der Excel, SQL Server oder beides im Einsatz hat, sollte sich den gesamten Microsoft BI Stack einmal genau ansehen. Setzt man ihn ein, spart man schnell Zeit und Geld ein.
Problem Nummer 4: Sie bauen alles im SharePoint neu auf
Sobald man zu SharePoint wechselt, ist die Versuchung groß alle bestehenden Prozesse im SharePoint neu aufzubauen. Es handelt sich jedoch bei SharePoint, wie der Name bereits andeutet, um ein Produkt, in dem vordergründig Informationen aus den unterschiedlichsten Unternehmensbereichen an einem zentralen Punkt für den Anwender geteilt werden sollen.
Ein Vergleich mit dem Meer bietet sich an: Der Grund des Meeres ist uneben, besteht aus verschiedensten Materialien und Schluchten bzw. Ebenen. Das spiegelt sich in einer typischen IT-Landschaft, bei der verschiedenste Systeme, Technologien, Anwendungen und Produkte zum Einsatz kommen.
SharePoint legt sich hier glättend wie der Wasserspiegel ohne Wind und Wellen als Oberfläche darüber, beschert also dem Anwender das Erlebnis IT.
Soweit die Theorie, doch da SharePoint etwa 80 Prozent Organisation ist, ist es nur mit einem sehr guten Verständnis für das Produkt selbst, den SQL Server darunter und die große Weite der Unternehmensanwendungen sowie guter Planung ein solches Erlebnis.
Viele Entwickler bauen Anwendungen über Listen und Bibliotheken neu auf; diese sollen dann später konsolidiert, und ein Berichtswesen aufgebaut werden. An diesem Punkt taucht oft die Frage auf, wie Anwender die Daten aus ihren unterschiedlichen Systemen in den SharePoint bekommen – Beispiele sind hier unter anderem externe Bibliotheken, ETL-Prozesse und Reporting Services.
Sie haben hier zwei Möglichkeiten: SharePoint als reines Frontend zu nutzen, oder auf Basis der SharePoint Apps neue Anwendungen zu entwickeln, die Ihren Bedürfnissen entsprechen. Welcher Weg für den jeweiligen Anwender der richtige ist, muss von Fall zu Fall entschieden werden. Es muss jedoch immer klar sein: Ein Workflow ist anders als der SQL Server kein transaktionales System, und Massenladevorgänge gehören eher in den Bereich der ETL-Prozesse, auch wenn Sie hier Timer Jobs von SharePoint durchaus sinnvoll nutzen können und Microsoft das im gewissen Sinne auch propagiert.
Alle Methoden haben ihren Sinn – es sollte nur vorher genau geprüft werden, was es sich lohnt umzusetzen. Man sollte immer die jeweils beste Technologie für den richtigen Anwendungsfall einsetzen, und nicht alles in relationale Datenbanken oder einfach nur SharePoint packen, weil man sich weiter nichts vorstellen kann oder bessere Technologien bzw. Alternativen nicht bekannt sind.
Problem Nummer 5: Ihre Stammdaten sind verstreut
Haben Sie eigentlich schon mal etwas von den Master Data Services im Zusammenhang mit dem SQL Server gehört? Haben auch Sie Stammdaten im CRM, im ERP-System, im SQL Server, im SharePoint, in weiteren Unternehmensanwendungen? Vermutlich – denn das ist in fast allen Unternehmen Realität.
Das Dynamics CRM beherbergt Ihre Stammdaten – das gibt Ihnen zwei Optionen diese für reine Vertriebsaktivitäten zu nutzen: über den Angebots- und Rechnungsprozess im CRM oder den des ERP-Systems Navision.
Auch im Dynamics Navision oder AX finden sich Stammdaten – hier gibt es die Option diese im Bereich ERP zu nutzen. Konnektoren zwischen den beiden Systemen ermöglichen es mittlerweile von einem System aus die Daten des jeweils anderen zu nutzen. Solche Konnektoren gibt es für Dynamics CRM, Dynamics Navision, Dynamics Marketing, den TFS, SharePoint und weitere Microsoft-Produkte.
Um eine effiziente Umgebung in Ihrem Unternehmen aufzubauen, ja eine fundierte Entscheidung überhaupt treffen zu können, müssen noch einige weitere Dinge abgeklopft werden: Setzen Sie Office 365 ein? Haben Sie OnPremise-Lösungen oder Hybrid-Szenarien im Einsatz, oder wie ist Ihre Unternehmensstruktur aufgebaut?
Wenn Sie SharePoint bzw. Office365 einsetzen und von dort aus auf Ihre Stammdaten im Unternehmen zugreifen möchten, gibt es Gateways, die Ihnen das ermöglichen. Wenn Sie Ihre Stammdaten nicht zentralisiert haben und aus externen Systemen einbinden, könnten im SharePoint Dubletten entstehen.
All diese Technologien machen es unter Berücksichtigung von Zusammenhängen und fachlichem Wissen möglich, ein effizientes Datenmanagement aufzubauen.
Fazit:
Der SQL Server ist der Motor Ihrer Unternehmensanwendungen. So wie er mit allen wichtigen Komponenten Ihres Wagens verbunden ist, so verbinden Konnektoren den SQL Server mit Ihren Unternehmensanwendungen Dynamics CRM, Dynamics Navision, Dynamics AX, SharePoint, Excel und Ihren eigenen Anwendungen. Alles, was Sie tun müssen, ist Ihre Anwendungen durch intelligente Schnittstellen miteinander zu verbinden – so wird Ihr Datenmanagement zu einem effizienten System.
Geschrieben von: Daniel Caesar
