Zweifelsohne ist SAP auch heute das meist eingesetzte ERP System in mittelständischen und vor allem grossen Unternehmen, gefolgt von Oracle und Sage. Dabei ist das ERP-System aus dem Hause SAP nicht als in sich geschlossenes System zu verstehen. Unzählige Module, die in die modulare Architektur des Basissystems nach Bedarf und Nutzen integriert werden können, ermöglichen den geschäfts- und branchenbezogenen Einsatz des Systems mit einer hohen Customizing-Maturität. Die meist eingesetzten Module sollten nach meiner Einschätzung neben dem Platzhirsch FI & CO, das MM und PP sowie SD sein. Eine Statistik hierzu habe ich jedoch nicht.

Wer aus dem für das eigene Unternehmen aufgebaute und betriebene System bestimmte logische, zusammenhängende oder berechnete Informationen ausserhalb der vorgegebenen Reporting-Templates  on-demand rausziehen möchte, wird jedoch relativ schnell feststellen, dass entweder eine tiefergehendes Know-How, welches über typische Anwenderkenntnisse hinausgeht, vorgewiesen werden muss, oder einen Experte zurate gezogen werden muss. Letzteres ist dann wohl mit weiteren Kosten verbunden. In der Realität interessiert sich kaum ein CFO oder dessen Assistent(in) für diese produktspezifische, tiefe Expertise, noch sind sie in der Lage und haben nicht die erforderlichen Berechtigungen, ihre eigenen Berichtsmasken mithilfe der SAP eigenen Programmiersprache ABAP zu implementieren. Die Konsequenz daraus sind teure SAP Berater, die nach entsprechenden Business-Anforderungen die notwendigen Berichtsvorlagen erstellen könnten. Doch am Ende sind diese neuen Routinen dann selbst statisch oder zumindest eingeschränkt und müssen bei jeder neuen Anforderung entsprechend angepasst werden.

Eine mächtigere Alternative und zugleich flexiblere Möglichkeit bieten hierbei sogenannte Business Intelligence Tools (“BI-Tools”), die u.a. in Hinsicht auf die gesetzten Unternehmensziele bessere operative oder strategische Entscheidungen anhand komplexer Auswertungen ermöglichen. Die Mechanismen dahinter nennt man in der Regel “Data Mining”. Mit dem neuen Hype “BIG DATA” sind klassische Analyse- und Prognostizierverfahren in Richtung Cloud-Dienste gewandert, da man u.a. von den Vorteilen des High Performance Computings (HPC) in der Cloud in Verbindung mit sehr grossen Datenmengen unterschiedlichster Form und Natur profitieren will. BIG-BI-IN-THE-CLOUD hört sich dabei natürlich nicht so schön an wie die einfache aber intransparente Variante “BIG DATA”. Natürlich sind mit den wachsenden Daten und der Möglichkeiten in der Cloud in Verbindung mit dem “extended BI” in Verbindung mit neuerdings besserer künstlicher Intelligenz (AI) und neuen strategischen Zielen enorm gewachsen (Profiling, Product & Content Marketing, Knowledge on Demand, Verhaltensanalysen und ja, wie seit eh und je auch Lauschangriffe und Spionage 😉 )

Mit Hilfe analytischer Konzepte entsprechender BI-Software wird das Ziel der Gewinnung von Erkenntnissen erlangt. Das von SAP selbst entwickelte und für SAP ERP angebotene, bekannteste Lösung dürfte dabei das SAP BW (“SAP Business Warehouse” oder “SAP BW”) sein. Das mittlerweile in “SAP NetWeaver Business Intelligence” umgetaufte Produkt BW wird insbesondere für das analytische Reporting im SAP ERP-Umfeld eingesetzt, da SAP BW im so genannten Business Content, vorgefertigte ERP-Extraktoren sowie zugehörige, mehrdimensionale Datenelemente (“OLAP-Würfel” oder “OLAP Cubes”) und Berichte enthält. Mit dieser Architektur soll eine schnellere Entwicklung von “Data Warehouse Applcations” möglich werden.

Abgesehen von SAP BW gibt es noch weitere markante Player, die mit ihren BI-Tools auf dem Markt versuchen durch ihre Basis und spezifische Merkmale, Plattformen und Technologien im strengen Wettbewerb zu bestehen oder Land gutzumachen. Einige von Ihnen bieten ausgeklügelte Werkzeuge, möglichst intuitive und einfache Bedienung und technologisch gesehen hohe Integrationsmöglichkeiten, gepaart mit “Best Pratice” Ansätzen in der Plattformbereitstellung. Einen guten Vergleich der bekanntesten und populärsten BI-Tools stellt die Seite http://www.softwareadvice.com/bi/ dar.

Doch mit jeder Zweit- oder Drittsoftware dieser Grössenordnung sind auch in den Entscheidungs- und Auswahlprozessen, Begriffe wie Lizenzierung, Support, Integration, Customizing, KnowHow-Transfer, Trainings oder Eingliederung in die IT-Betriebsprozesse unvermeidbare Hürden, die es zu nehmen gilt. Ob nun diese Hürden kaum spürbare, kleine, oder doch eher grosse sind, hängt einerseits vom Unternehmen selbst ab, andererseits werden wichtige Herausforderungen nicht immer gleich zu Beginn erkannt. Man lässt sich auch von der Portfolio-Vielfalt der Produkte gerne mal verleiten und der tatsächliche Fokus eine Lösung genau nach eigenen Bedürfnissen einzuführen, versandet nicht selten in unübersichtlicher werdenden Integrationsprojekten, deren Ende leider von einem ordentlichen Projektabschluss dann meist in “Phase Out” umgetauft werden.Für mich sind Projekte mit dieser End-Bezeichnung dann nur noch Projekte, die man so hätte nie angehen und durchführen wollen/dürfen, deren PNR (Point of No Return) oftmals durch ein schlechtes Management oder durch Inkonsequenz verpasst werden.

Aber was ist, wenn all diese überdimensionierten, nach zig Varianten und Analysealgorithmen und Multi-Plattform fähigen Anwendungen für die Bedürfnisse und Zwecke eines Konzerns oder KMUs gar nicht von Nöten sind? Was ist, wenn die Entscheider ohnehin nur aus der Kernapplikation kommenden Informationen zwar dynamisch, jedoch nach überwiegend gleich bleibenden Analysemustern verarbeiten müssen? Ist es nicht über das Ziel hinausgeschossen, bei einem Optimierungsziel mittelfristiger Strategie zusätzliche Langzeitinvestitionen zu tätigen? Wäre es nicht übertrieben, einen Hoovercraft anzuschaffen, um die Kuh vom Eis zu holen?

Ich vergleiche solche Fälle oft mit einem Unternehmen, welches sich sinngemäss Offroad bewegt, dafür aber einen Ferrari kauft. Das Unternehmen muss nicht auf die Autobahn um bis aufs Letzte, jegliche Ist-Zustände und Prognosen zu berechnen und Korrekturen einzuleiten, um möglichst dauerhaft auf High-Speed zu bleiben. In diesem Fall wäre ein Ferrari dann wohl ein überdimensionierter Fehlkauf mit hohen Folgekosten im Unterhalt. Da würde wohlmöglich eher ein einfacher SUV mit Allrad Antrieb das Unternehmen insgesamt kosteneffizienter vorantreiben, ohne auf die Vorzüge einer Datenanalyse verzichten zu müssen. Vergleichen sie es mit ihren täglichen Applikationen: Wieviel Prozent von allen Funktionen und Möglichkeiten können sie täglich nutzen, geschweige denn, kennen diese?

Bevor ich über eine mögliche, technische Referenzarchitektur einer hauseigenen BI-Lösung berichte (wobei mir das Wort “Data Mining” an dieser Stelle lieber ist), sollten noch mögliche Vorteile einer Implementierung mit eigenen Boardmitteln genannt werden. Ebenfalls werde ich die aus meiner Sicht wichtigsten Beweggründe aus der Risikosicht zum Einsatz solcher Tools nennen. Zum Schluss möchte ich noch die typischen Anwendungsgebiete und die typischen Teilanforderung im Gesamtprozess zur Datenerhebung und Auswertung nennen.

Die Vorteile der eigenen Implementierung mit Boardmitteln

• Keine teuren Software-Lizenzen
  
• Keine kostspieligen Support-Verträge mit Dienstleistern
• Keine teures Customizing von eingekaufter Software
• Zeitersparnis durch automatisierte oder dynamische Routinen und Reports auf Abruf (schnelle Informationsverfügbarkeit)
• Aktualität der Auswertung
• Hohe Verlässlichkeit der Angaben durch direkte Informationen (höhere Datenqualität)
• Unterstützung von Controlling- und Management (Erleichterung von Steuerung und Entscheidungen durch kurzfristig erhältliche präzise zusätzliche Informationen)
• Vermeidung von Übertragungs- und Interpretationsfehlern (höhere Datenqualität)
• Ressourceneffizienz durch zeitliche Entlastung der Mitarbeiter (Kosteneinsparungen)
• Nutzung bereits vorhandener Informationstechnologie und bestehender Systeme (Nutzenmehrung der vorhandenen Infrastruktur)
• Einbindung visualisierter Auswertungen in Business Reports, Statistiken, Veröffentlichungen etc. mit eigenen Anwendungen (schnelle Nutzbarmachung)
• Pass- und maßgenauer Informationszuschnitt  (Bedarfsgerechte Informationsnutzung)

Die täglichen Herausforderungen aus strategischer und risikoorientierter Sichtweise

• Unternehmen haben heterogene Daten und ggf. auch heterogene Systemlandschaften
• Sie haben Daten unterschiedlicher Herkunft und Natur (interne, externe Daten sowie unterschiedliche Datenformate)
• Sie haben keinen Überblick mehr durch große bis sehr große Datenmengen (mehrere Gigabyte an Daten sind heutzutage üblich)
• Fehlende Zusammenhänge erschweren die Übersicht (Unsicherheiten durch das Risiko „Informationsverlust“)
• Keine Strategische Anpassung/Ausrichtung durch fehlende Intime-Prognosen (wo steht Ihr Unternehmen gerade jetzt)

Die Notwendigkeit – Warum Data Mining in einer komplexen Welt und der Datenflut so wichtig ist

• Ausreißererkennung: Identifizieren Sie ungewöhnliche Abweichungen, Prognosen die auf Risiken hinweisen
• Clusteranalyse: Gruppierungen Sie ihre Informationen, bestimmen Sie Ähnlichkeiten
• Klassifikation: Ordnen Sie ihre bestehenden Elemente ihrer Klassifizierung zu
• Assoziationsanalyse: Identifizieren Sie Zusammenhänge und Abhängigkeiten
• Regressionsanalyse:  Identifizieren Sie Beziehungen zwischen abhängigen und unabhängigen Werten
• Zusammenfassung: Reduzieren Sie Ihren täglichen Datenvolumen in eine kompaktere Beschreibung ohne wesentlichen Informationsverlust

Typische Anwendungsgebiete in Unternehmen

Entscheidungsunterstützungssysteme

• Im Finanzsektor:
  • Rechnungsprüfung zur Betrugserkennung
• Im Marketing
  • Marktsegmentierung
  • Warenkorbanalyse zur Preisoptimierung und Produktplatzierung
  • Zielgruppen-Auswahl für Werbezwecke
  • Angriffserkennung
  • Empfehlungsdienste für Produkte wie beispielsweise Filme und Musik
  • Netzwerkanalyse in sozialen Netzwerken
  • Web-Usage-Mining um das Nutzerverhalten zu Analysieren
  • kampagnen
  • Kundenprofil-Erstellung zum Management von Kundenbeziehungen
  • Business Intelligence in vollem Umfang
    
• Im Internet:
  • Angriffserkennung
  • Empfehlungsdienste für Produkte wie beispielsweise Filme und Musik
  • Netzwerkanalyse in sozialen Netzwerken
  • Web-Usage-Mining um das Nutzerverhalten zu Analysieren
• Arzneimittelüberwachung
• Bibliometrie
• Explorative Datenanalyse
• etc.

Typische Teilanforderung im Gesamtprozess der Datenerhebung und Auswertung

• Die Datenakquisition:
  Bestimmen der Datenquellen- und der Arten, Analysieren der Inhalte und konsolidieren der Daten
• Datenaufbereitung:
  Vereinheitlichen der Strukturen, bereinigen der Nutzdaten (nutzbare Rohdaten) von den überflüssigen Daten
• Kennzahlenberechung:
  Bestimmen des Zwecks und der Ziele der Reporting-Artefakte und identifizieren der Eingangskennzahlen sowie  erzeugen der Zusammenhänge durch Berechnungen
• Darstellen und Visualisieren des Reportings (bzw. der Reporting-Artefakte)

Diese Funktionen sind untrennbar mit ihren spezifischen nicht funktionalen Merkmalen verbunden. Das Spezifikationsniveau ist hier noch relativ hoch und abstrakt. Es gibt viele Arten von Schnittstellen Für die Akquisition, zahlreiche Kennzahlen unterschiedlicher Komplexität sowie verschiedene Typen von Reporting-Artefakten. Daher sind Spezialisierungen durch die Basisanforderung unverzichtbar.

 

Eine mögliche Self-Made-Architektur (entsprechend des Data Minings) mit eigenen Boardmitteln

Der Titel dieses Themas lässt bereits verlauten, dass es sich um eine, für ein Unternehmen eigene BI Lösung mit einfachen und mittleren Prozessen handelt, welche als Datenbasis bzw. Kernapplikation SAP ERP zugrunde legt. Die als Beispiel dienende Architektur kann jedoch auf beliebige Weise aufgebaut und auf andere Software angewendet werden, die entsprechende Schnittstellen zur Erhebung notwendiger Unternehmensdaten bereitstellen.

In SAP werden wie in den allermeisten Softwarelösungen der gleichen Art die Unternehmensdaten in (relationalen oder objektrelationalen) Datenbanken gespeichert. Abgesehen der statischen Tabellenstrukturen, werden views und temporäre Tabellen und so einige Prozeduren, Routinen  und Trigger angelegt. Die notwendigen Datenobjekte werden jedoch nicht aus der Datenbank direkt extrahiert. Dies ist erstens sehr aufwändig, da der gewünschte Effekt, bereits aus der Kernapplikation heraus prozessierte Daten über den Weg der Extraktion (Rohdaten) erneut in die gewünschte Güte bringen zu müssen ineffizient erscheint, zum anderen es aufgrund der Komplexität der Tabellenstruktur ein enormes Wissen über das Datenbankschema benötigt.

Stattdessen werden die gewünschten Datenobjekte über so genannte Schnittstellenprogramme innerhalb der Kernapplikation selektiert und über Batch-Prozesse in vorgefertigter Güte in “Flatfiles” rausgeschrieben. Hierzu bieten sich einige Möglichkeiten an: Nebst RFC (Remote Function Call), XML, HTML, EDI Adapter oder File Adapter, bietet SAP das ABAP als OLE2 Automation Controller an, um z.B. Daten als CSV Dateien zu extrahieren. Anleitungen zu den unterschiedlichen Möglichkeiten liefert SAP in seinem Online-Help. Natürlich wäre es eine leichte Übung zu sagen, wir nehmen die CSV Dateien und laden sie direkt in Excel oder Access um dort bestimmte logische Verknüpfungen und zusätzlichen Berechnungen entsprechende Analysen zu betreiben oder dem Chef abstrahierte Charts vorzulegen. Das ist durchaus sinnvoll und ist auch Ziel der hauseigenen Lösung, aber nicht auf diese Weise. Man muss bedenken, dass wir es im Laufe der Zeit mit sehr sehr vielen Daten zu tun haben werden, die nicht nur quantitativ wachsen, sondern auch zusammengehalten werden müssen, beispielsweise aus der Intension heraus auch mögliche historische Zusammenhänge für eine Vorhersage auswerten zu können. Nicht zuletzt aus technischen Gründen würde ein Unternehmen sehr schnell an die Grenzen solch eines (zu)einfachen Weges stossen. Grosse Datenmengen mag sowohl Excel nicht, als auch Access. Aber sie sind zweifelsohne mächtige Werkzeuge, die man auch sehr wohl im Bereich Datenanalysen und BI einsetzen kann, weshalb sie in der hier vorgestellten Beispielarchitektur das Frontend und die Logikwerkzeuge bilden werden.

Bei den zu extrahierenden/exportierenden Daten ist es noch zu erwähnen, dass die Daten zwar die Basis zu späteren Analysen und Berechnungen, somit ggf. auch zur Entscheidungsfindung dienen, jedoch abgesehen davon, dass sie aufgrund ihres Inhaltes ggf. stark schützenswert sind, keine rechnungslegungsrelevanz haben sollten. Dennoch bilden jegliche Daten, die eine mögliche Entscheidung herbei führen sollen oder Massnahmenerlass im Unternehmen hervorrufen, eine nicht unbeträchtliche Sensitivität hinsichtlich ihrer Integrität und Sicherheit. Daher sind solche Extrakte bestmöglich vor Manipulationsversuchen und unerlaubten Zugriffen zu schützen. Auch hierbei sollten die Prinzipien “Bussines Need To Know” und “Segregation of Duties” eingehalten und nach klaren Regeln durchgesetzt werden. Ebenfalls ist der Einsatz von Verschlüsselungstechnologien stark empfehlenswert.

Ist erst einmal eine Datenbasisstruktur definiert und die einzelnen Objekte samt ihres Types beschrieben, können diese aus der Kernapplikation extrahiert und für die weitere Verarbeitung abgelegt werden. Da es keinen Sinn macht ein “Data Mining” innerhalb der extrahierten Daten anzustreben und dies auch nicht das Ziel sein sollte, müssen die Daten zur sinnvollen Auswertung in ein Zweitsystem überführt und dort geladen werden. Damit wir dem Grundsatz eine Analyse-Umgebung (Unsere BI Lösung)  mit eigenen Mitteln aufzubauen auch Folgeleisten können, wird die Datenstruktur der Extrakte (nutzbare Rohdaten) genutzt um eine Tabellenstruktur bzw. das notwendige Datenmodell zu definieren und innerhalb einer relationalen Datenbank (DBMS) aufzubauen, worin die Daten später importiert werden sollen. Es bietet sich an die Namensgebung nach den Bezeichnern aus dem Kernsystem abzubilden, um bei einer Fehlersuche oder bei einem Vergleich die entsprechenden Objekte einfacher zu finden.Eine relationales Datenmodell ist in diesem Beispiel insbesondere deswegen sinnvoll, weil wir in dieser Architektur keine multidimensionale OLAP Strukturen implementieren müssen, sondern auf relationales OLAP setzen, wobei wir mit entsprechender Modellierung auch aus einer 2-dimensionalen Basis zumindest 3-dimensionale Aussagen erzielen können. Je komplexer die Aufgaben werden, umso mehr sollte die Architektur auf die Dimensions-Anforderungen angepasst werden, da ansonsten der Implementierungsaufwand sich mehr in die obere Schichten der Entwicklungsebenen verschieben und ggf. Mehrkosten verursachen kann.

Zwecks Standardisierung wäre dies zudem wahrscheinlich sinnvoll, eine Alias-Tabelle würde jedoch auch helfen. Es muss aber nicht unbedingt eine relationale Datenbank sein. Dokumentenbasierte Datenbanken haben ihre eigenen Vorteile, was schnellen Datenzugriff betrifft. Sie sind schemafreie, dokumentenorientierte NoSQL-Datenbanken, worin die Daten auf natürlichere Weise modelliert werden können. Das bekannteste Beispiel in diesem Bereich als NoSQL-Produkt ist “MongoDB”.

Es gibt zudem sehr viele Möglichkeiten, vorhandene DBMS Software auf dem Markt auch kommerziell und völlig kostenlos nutzen zu können. Allen voran denkt man dabei oft an die jahrzehntelang etablierte und im OLAP und Web-Bereich am meisten eingesetzte, relationale DBMS: MySQL.

MySQL
Seit dem der Markenname von Oracle aufgekauft wurde, ist die für Unternehmen angedachte Enterprise Variante nicht mehr kostenlos, obwohl der Kern der Anwendung weiterhin als OpenSource deklariert wird. Deswegen gibt es die Community Edition, welche auch für kommerzielle Einsätze kostenlos ist, aber für weitreichende Einsatzgebiete nicht ausreichend ausgestattet sein dürfte. Für den hier erörterten Zweck reicht die Community Edition jedoch völlig aus.

MariaDB
Zitat Wikipedia:
“MariaDB ist ein freies, relationales Open-Source-Datenbankverwaltungssystem, das durch eine Abspaltung (Fork) aus MySQL entstanden ist. Das Projekt wurde von MySQLs früherem Hauptentwickler Ulf Michael Widenius initiiert, der auch die Storage-Engine Aria (diejenige Software-Schicht, welche die Basisfunktionalität der Datenbank enthält, d. h. das Erstellen, Lesen, Ändern, Löschen von Daten) entwickelte, auf welcher MariaDB aufbaut. Da Oracle die Markenrechte an MySQL hält, mussten neue Namen für das Datenbanksystem und dessen Storage-Engines gefunden werden… “

PostgreSQL
Als würdige Konkurrenz zu MySQL stellt sich die absolute OpenSource DBMS PostgreSQL in den Weg. Zweifelsohne mit einem sehr hohen Maturitätslevel (15 Jahre Entwicklung), kommt PostgreSQL mit Onboard-Werkzeugen bereits viel länger daher, die wir uns bei MySQL zumindest in der freien Edition noch lange wünschen werden.

MSSQL Standard Edition
Zweifelsohne auch ein interessanter Kandidat, wenn das Unternehmen ohnehin schon strategisch auf Microsoft-Produkte setzt und entsprechende Lizenzen für weitere DB-Instanzen vorhanden sind, ohne zusätzlich investieren zu müssen.

Einen guten Überblick über mögliche DBMS, welche je nach IT Strategie oder internes KnowHow zum Einsatz kommen könnte, liefert z.B. die Webseite: webscripts.softpedia.com oder blog.capterra.com

---

Bei unserer Beispielarchitektur fällt die Wahl für das zentrale DBMS der eigenen BI-Umgebung auf die “MySQL Community Edition”. Die Vorteile sind, dass es sich einfach in eine Systemlandschaft integrieren lässt, durch seine Performance ausgezeichnet ist und die notwendigen Features in der kommerziell frei nutzbaren Edition ebenfalls mitbringt.

Doch so toll es klingt: Eine BI-Lösung mit Onboard-Mitteln auf die Beine zu stellen ist nicht nur mit Datenexport einfacher DBMS Installation getan. Spätestens nachdem wir die Datenbank und die Tabellenstruktur erstellt, die Tabellen kreiert und die ersten Daten versucht haben in die neue Datenbank zu laden, werden wir feststellen, dass es ohne weiteres so nicht klappen kann. Der Grund ist, dass zwar die einzelnen Records eines Datenextrakts aus SAP allesamt wie konfiguriert den gleichen Aufbau mitbringen, jedoch der Inhalt bei einem Import in ein Fremdsystem ggf. grössere Probleme bereiten könnte. Ursache hierfür sind oftmals die in den Textabschnitten eingegebenen Sonderzeichen, oder der exportierte Zahlenformat, welche eine DBMS beim Import nicht ohne weiteres richtig interpretiert, trotz definierter Separatoren zwischen den Spalten.

Wir müssen die vom Kernsystem angelieferten Daten also auf die Kompatibilität bzw. Importfähigkeit im Zielsystem hin überprüfen und ggf. die Fehler durch eine Transformation der Rohdaten bzw. Datenextrakte des Kernsystems aufbereiten. Dies geschieht in der Regel durch Transformations-Scripte, welche nach definierten Regeln aufgebaut sind und genau wissen, in welcher Form die DBMS die zu importierenden Inhalte erwartet und entsprechend Zeile für Zeile, Spalte für Spalte die Inhalte überprüft und ggf. in eine importierbare Form überträgt sowie neu abspeichert. In der Datawarehouse-Welt ist dieser Vorgang der Transformationsprozess. Der Import der nun nach der Transformation konformen Daten ist der Ladevorgang, auch Load Prozess genannt.

Es ist hierbei deutlich zu erkennen, dass wir im Grunde den Prinzipien eines Data Warehousings folgen. Wir extrahieren, wir transformieren, wir laden (ETL Prozesse).

Beispiel:

Nach einem SAP Export, haben wir eine Datenzeile im Flatfile (Unser Extrakt), welche u.A. folgende Informationen beinhalten könnte (illustrativ):

0001#   100.000.000,00#€#Schulden an das Finanzamt/ Zu bezahlen bis Ende 08\2016#0.000#Finanzamt Musterstadt, Musterstrasse 1

Die Raute-Zeichen sind in diesem File klar zu erkennen als vorher im Kernsystem ausgewählte Separator-Zeichen.
Die Zahl 100.000.000,00 kommt mit entsprechenden Blocktrennzeichen daher und im Textfeld sind ebenfalls Sonderzeichen wie ein Slash Zeichen (/) oder ein Backslash-Zeichen zu erkennen (\). Diese Zahlenformate oder Sonderzeichen können ggf. entweder durch den Import-Interpreter der DBMS ungewollt verfälscht werden, oder den Vorgang mit einem Abbruch des Imports beenden. Daher müssen sie entweder in “unkritische” Zeichen umgewandelt bzw. ersetzt werden, oder entfernt werden. Diese Aufgabe erledigt das Transformations-Script, welches in einer beliebigen Programmiersprache erstellt werden kann. Zu empfehlen sind jedoch Interpretersprachen, welche eine starke Basis für reguläre Ausdrücke mitbringen. Interpretersprachen wie Perl, PHP oder Ruby sind hierfür sehr gut geeignet. Natürlich geht es auch mit Java oder C++.

Wir haben nun unsere Datenobjekte im Kernsystem selektiert, extrahiert, transformiert und endlich in die Datenbank geladen. Wir können diesen Vorgang für unterschiedliche Zeitintervalle beliebig oft anwenden, um die BI relevante DBMS mit möglichst vielen Daten anzureichern. Daten können Stündlich, Täglich oder einfach nur Monatlich in die Datenbank geladen und dort durch entsprechende Primärmerkmale oder Zeitstempel voneinander differenziert werden.

Aber so wie das Papier geduldig ist, sind auch Daten in einer Datenbank sehr geduldig. Der CFO kann zudem mit diesen Massendaten noch nichts anfangen. Es muss eine Instanz her, welche die entsprechende Analyse-Logik und die Front für die Benutzerinteraktion mitbringt. Weiter oben wurde bereits erwähnt, dass für die hauseigene BI-Lösung in diesem Beispiel die Microsoft Office Lösungen verwendet werden. MS Access sowie Excel lassen sich ohne grosse Aufwände mit allen oben genannten DBMS verbinden. Die Hersteller der genannten Datenbanklösungen bringen alle entsprechende Connectoren (DBMS Connectors) für unterschiedliche Architekturen und Programmiersprachen mit. Ebenfalls werden native Connectoren angeboten (Native ODBC Driver). Dies ermöglicht, dass andere Frontends ebenfalls an das DBMS angebunden werden können. Durch entsprechende Loadbalancer könnte die Last zudem auf replizierende Datenbanken verteilt werden, welche über ein DMBS-Proxy  an ein Web-Frontend angebunden werden könnten. Dies würde eine Ortsunabhängigkeit beim Zugriff auf das Frontend begünstigen und die Verarbeitung der Analysen durch verteilte Systeme wesentlich beschleunigen.

Ein weiterer Aspekt ist es, dass es bei dieser Lösung ebenfalls keineswegs notwendig und gar unerwünscht ist, die Tabellen samt ihrer Daten in das Frontend zu importieren. Spätestens, wenn die Obergrenze der möglichen, verarbeitbaren Datenmenge z.B. bei Excel oder Access erreicht wird, quittieren diese Anwendungen ihren Dienst entweder mit entsprechenden Meldungen oder in den meisten Fällen sogar vorher mit Abstürzen. Zudem muss man bei grossen Datenmengen innerhalb MS Office Anwendungen, bedingt durch weniger Performance der Desktop-Systeme mit langen Rechenzeichen leben. Wir wollen die Daten ohnehin nicht lokal auf dem PC des Benutzers analysieren und verarbeiten oder für weitere Berechnungen oder Statistiken laden.

Durch entsprechende Tabellenverknüpfungen, z.B. in Access oder Excel, kann die Abbildung der Analytik und folglich der Abfragelogik bequem in der Frontendapplikation erfolgen, während die Daten im DBMS beleiben. Ebenfalls können die Daten aus der Datenbank nach Bedarf geladen werden, ohne dass das Netzwerk unnötig überlastet wird und die Applikation “gequält”. Einen weiteren Vorteil hat die Tabellenverknüpfungstechnik insofern, da die Logik zwar im Frontend besteht, die für die Analysen notwendige Operationen aber an die wesentlich leistungsstärkere DBMS-Systeme übergeben werden, um die gewünschten Ergebnisse nach entsprechender Berechnung wieder zurück zu bekommen. Ausserdem können durch entsprechende Berechtigungen in der DBMS z.B. lediglich das Leserecht gewährt werden, während z.B. der CFO oder dessen Assistenz keinerlei Befugnis hat, die Daten über das Backend zu verändern oder zu löschen.

 

Fazit:

Wenn ein Unternehmen nicht gerade aus Geschäftsgründen, Prestige-Gründen, strategischen Gründen oder aus dem fehlenden IT KnowHow heraus eine handelsübliche BI-Lösung benötigt, kann es ggf. durch einfache Methodik und überschaubaren Kosten seine eigene Lösung implementieren. Die Frage, die ein Unternehmen sich dabei stellen sollte, wie tiefgreifend und komplex die benötigten Analysen sein müssen und was den Kern der erforderlichen Informationen aus diesen Analysen darstellen soll. Ein weiteres Kriterium ist die Kosten-Nutzen Frage beim Einsatz von gekauften BI Lösungen.

Ich kann aufgrund der fehlenden Information bezüglich der Impelementierungskosten von Drittsoftware, insbesondere die eines SAP BW keinen Vergleich durchführen.

Eine interne BI-Lösung würde jedoch so wie sie in diesem Beitrag als Beispiel vorgestellt wurde, zum Zeitpunkt dieses Beitrags einmalige Investitionskosten von ca. 10.000 bis 20.000 Euro verursachen. Betriebskosten von Hardware sind nicht inbegriffen, jedoch fallen bei dieser Lösung keine weiteren Lizenzkosten für Software an. Dabei spielt die Grösse des Unternehmens keine Rolle.

Solch eine interne Umgebung wurde bereits in einem namhaften Konzern implementiert und hat sich seither insbesondere für das Controlling des Finanzvorstands als effektiv erwiesen, bei gleichzeitigem ROI nach nur wenigen Monaten.

(orkix)