Business Intelligence mit Open Source

von Peter Soth

In diesem Blogbeitrag möchte ich über ein Projekt berichten, in dem wir für einen deutschen Generikahersteller das auf Excel basierende Management-Reporting durch eine Business Intelligence Lösung abgelöst haben. In diesem Projekt haben wir - meiner Meinung nach - eine sehr pragmatische Lösung gefunden.

 

Warum sollte der Excel-Prozess ersetzt werden?

Excel, ursprünglich als Tabellenkalkulationssoftware gedacht, wird gerne als Schweizer Taschenmesser verstanden, um die unterschiedlichsten Aufgaben zu lösen. Wir sehen dieses Problem oft bei unseren Kunden. Hieraus entstand schließlich die Idee, eine Dienstleistung (Excel2Web) zu diesem Thema anzubieten. Wir sehen bei unserem Excel2Web Service folgende Vorteile:

  • Keine Installation auf dem Client-Rechner des End-Users nötig. Ein Web-Browser reicht aus
  • Mehrere Benutzer können gleichzeitig Informationen lesen und bearbeiten
  • Keine Verteilung (per Mail oder File-Server) von MS Excel Sheets mehr nötig
  • Die Web-Applikation ist unabhängig vom Betriebssystem (Linux/Windows)
  • Die Web-Applikation kann Drittsysteme wie SAP oder Datenbanken integrieren
  • Keine Viren im Vergleich zu MS Excel Sheets
  • Informations- und Prozesssicherheit, da Eingaben validiert und historisiert werden können
  • Über ein RSS-Feed können Informationen jederzeit aktuell bereitgestellt werden
  • Unterstützung von mobilen Clients wie iPad, iPhone, Android oder Blackberry ist möglich.


Beim Berichtswesen ist hier als besonders kritisch die fehlende Informations- bzw. Prozesssicherheit von Excel anzusehen. So fand ebenso in diesem Projekt eine manuelle Aggregation der von verschiedenen Datenanbietern gelieferten Marktdaten statt. Dies war zum einen ein aufwändiger Prozess und zum anderen wusste niemand genau, ob die Daten - bspw. bedingt durch einen Eingabefehler - korrekt waren.

Mehrere Quellen - mehrere Definitionen

Für den Pharma Markt stehen umfangreiche Marktdaten von verschiedenen Anbietern [2, 3, 4] zur Verfügung. Dabei sind nicht alle Datenelemente standardisiert, beispielsweise unterscheiden sich Bezeichnungen und Schreibweisen für Substanzen, Produkte oder Fachgruppen. Will man Daten aus  mehreren Quellen nutzen, sind Zuordnungen für ein einheitliches Reporting notwendig. Ebenso weichen Marktdefinitionen der einzelnen Datenanbieter voneinander ab, die bei der Nutzung zu berücksichtigen sind.

Unterschiedliche Steuerungsebenen

Ein Konzern steuert sein Geschäft nicht zwangsweise nach den nach außen sichtbaren Strukturen. Durch Unternehmenszukäufe gibt es bspw. mehrere rechtliche Einheiten, nach innen wird aber nach anderen Strukturen (beispielsweise Unternehmens-übergreifende Business Units) gesteuert. Entsprechend müssen die allgemeinen Marktdaten auf die interne Struktur abgebildet werden - ein Unterfangen, das bei manuellen Vorgehen erheblichen Aufwand und Fehlerquellen provoziert.

Muss es immer gleich das SAP Business Warehouse sein?

Um es vorwegzunehmen, der Königsweg ist es, alle Berichte zentral mit einem System zur Verfügung zu stellen. Nachteilig hierbei ist allerdings, dass SAP BW Projekte langwierig und teuer sind. Deshalb greifen Fachabteilungen gerne auf Excel zurück, um lange Wartezeiten - bis die IT-Abteilung Zeit findet sich ihrem Problem anzunehmen - zu umgehen. Der Einsatz von Excel verursacht jedoch die oben beschriebenen Probleme.

Der QlikView Weg

Neben dem SAP BW ist im BI Markt immer öfters die QlikView Lösung von QlikTech zu finden. Das Produkt wirbt damit, dass sich Reports ohne Programmieraufwand - nur mit einem graphischen Editor - erstellen lassen. Falls die Lizenzkosten kein Problem darstellen, ist dies eine gute Option. Ich möchte hier jedoch darauf hinweisen, dass bei diesen Tools das maschinelle Testen nicht trivial ist. Hierzu gibt es einen interessanten Artikel in der QlikCommunity [1] mit Ideen, wie Überprüfungen automatisiert durchgeführt werden können. Besonders hilfreich, wenn auf eine neue Version migriert wird und im Anschluss daran bspw. mehrere hundert Reports auf ihre Nachprüfung warten.

Unser Open Source Ansatz

Bei diesem Projekt wählten wir schließlich einen anderen Lösungsansatz. Excel musste auf jeden Fall abgelöst werden, der SAP BW Weg hätte zu lange gedauert und es sollten keine Lizenzkosten anfallen. Somit blieb nur Open Source als Alternative. Hier gibt es die bekannten Platzhirsche Jaspersoft und Pentaho. Ausführlich haben wir diese Lösungen evaluiert, uns danach jedoch gegen diese Anbieter entschieden, vor allem deshalb, weil wir nicht sicher sein konnten, doch noch während des Projekts auf eine Kaufversion umsteigen zu müssen. Unser Lösungsansatz bestand letztendlich darin, das Grails Framework zu benutzen. Ein zusätzlicher Vorteil ist dadurch gegeben, dass wir automatisierte Tests durchführen können, einer der Nachteile, wenn bspw. der ETL-Prozess grafisch zusammengeklickt wird. Im nächsten Abschnitt werde ich kurz auf die technische Umsetzung eingehen. Mein Kollege Tobias Kraft wird noch einen Blog-Post mit weiteren Fakten schreiben.

 

Die technische Umsetzung unserer Business Intelligence Lösung

Wie bereits erwähnt, kam auch in diesem Projekt das Grails-Framework zum Einsatz. Der ETL-Prozess basiert auf dem Grails-Batch-Plugin, dass das Laden der Informationen steuert. Die anschließende Transformation ist mit einer Art DSL (Domain-Specific-Language) realisiert und schließlich werden die Daten in ein Star-Schema geladen. Die Fakten- und Dimensionstabellen sind mit Hilfe von GORM modelliert worden. Oder anders formuliert - das Resultat ist ein Datawarehouse, basierend auf dem Grails-Framework.

Fazit

Es muss in jedem Projekt von Neuem entschieden werden, welche Vorgehensweise die beste ist. Ist das SAP BW aus verschiedenen Gründen keine Option, so ist der Open Source Ansatz durchaus praktikabel. Selbst als Interimslösung ist die in diesem Blog -Post beschriebene Herangehensweise allesamt besser als eine Excel-Lösung.

Kategorien: Business IntelligenceGrailsIT-ConsultingPortale

Zurück