(openPR) “Ja nee, wir kaufen eCommerce-Plattform, ERP, CRM, Kasse und Marketing-Systeme von der Stange – aber unsere BI-Anforderungen sind so höchst individuell, dass wir unbedingt selbst eine Lösung bauen müssen, die exakt auf unsere Bedarfe zugeschnitten ist.” Ja, schon klar. Eure Prozesse könnt ihr im Standard abwickeln, aber auswerten müsst ihr hoch spezifisch. Macht Sinn.
Versteht mich nicht falsch: In den meisten Handelsunternehmen gibt es individuelle Prämissen zur Datenauswertung, na klar – z.B. eine unternehmensspezifische Kennzahlenterminologie oder bestimmte Teile des Geschäftsmodells, die analyseseitig eine besondere Behandlung erfordern. Doch die Wahrheit ist: Der allerkleinste Teil davon rechtfertigt tatsächlich den Bau einer individuellen BI-Lösung – mindestens 80% der Anforderungen können nichtsdestotrotz vom Standard abgedeckt werden, die restlichen maximal 20% werden dann entweder innerhalb der Standardlösung individuell angepasst bzw. erweitert (wie bei minubo) oder durch einzelne Eigenbaukomponenten ergänzt.
Um diesen Sachverhalt besser zu durchdringen, lasst uns einen näheren Blick darauf werfen, was “Individualisierung” in der Business Intelligence eigentlich bedeutet.
Ebenen der Individualisierung von Business Intelligence
Im Großen und Ganzen gibt es in der BI vier Ebenen, auf denen die Individualisierungswünsche der Unternehmen angesiedelt sind:
1. Frontend-Tools: Operativ, Visualisierung und Analyse
Fragestellungen | Stehen meinen Usern die Tools zur Verfügung, die sie brauchen? Kann ich die Art der Datenvisualisierung in Reports, Dashboards & Co meinen Anforderungen anpassen? Kann ich flexibel analysieren?
Das ist der Sachverhalt | Frontend-Tools, die über reines Reporting, Dashboarding und klassische Analyse-Werkzeuge hinausgehen, sind eine Schlüsselanforderung moderner BI, denn in diese Kategorie gehören operative Tools wie z.B. Kunden- oder Produktsegmentierung oder proaktives Alerting, die den größten Teil der User-Basis (nämlich die operativen Abteilungen) in die Lage versetzen, datengetrieben zu arbeiten. Fakt ist aber, dass der bei weitem größte Teil der Unternehmen niemals in der Lage sein wird, solche Tools für ihre Eigenbau-BI tatsächlich selbst zu entwickeln – weshalb der Schrei nach Individualisierung hier gar keine Gültigkeit hat, zumindest nicht als Argument für eine Eigenbau-BI. Im Gegenteil: Anbieter professioneller BI-Softwares sind sehr viel eher in der Lage, dem Wunsch nach individuellen Tools auch als Teil ihrer Standard-Software gerecht zu werden. Alle anderen, “klassischen” Frontend-Tools (Reporting, Dashboarding, Werkzeuge zur Ad-hoc-Analyse) lassen sich anders als operative Daten-Tools für jede Eigenbau-BI ganz einfach dazu kaufen und individuell einrichten (z.B. Visualisierungs-Tools wie Tableau oder Qlik View oder Analyse-Tools wie Excel) – was dazu führt, dass der Wunsch nach Individualisierung im Bereich von Visualisierung und Analyse meist als starkes Argument für eine Eigenbau-BI empfunden wird. Doch tatsächlich ist auch jede gute eingekaufte BI-Software in der Lage, individuelle Anforderungen in diesen Bereichen abzudecken, z.B. durch frei gestaltbare Dashboards, konfigurierbares Reporting und flexible Analyse-Tools auf Rohdatenbasis. Gibt es hier Limitierungen, ist eine gute BI-Software zumindest in der Lage, Daten aus dem konsolidierten Data Warehouse über ausgehende APIs an Drittsysteme zu liefern, die die nicht erfüllten Anforderungen ergänzen können – ein “Aufwand”, der einen Bruchteil dessen darstellt, was die Entwicklung eines rundum individuellen Setups bedeuten würde.
Fazit | 1) Der Schrei nach individuellen operativen Tools als Argument für individuelle Eigenbau-Lösungen hat keine Gültigkeit, da eine Eigenentwicklung in der Regel keine realisierbare Alternative ist – zudem können professionelle Softwares wie minubo Tools für einzelne Kunden auch als individuelle Ergänzung zu ihrem Standard-Frontend entwickeln (s. z.B. die Geschichte von Curated-Shopping-Startup SugarShape). 2) Die Forderung nach individueller Visualisierung und flexibler Analyse hingegen ist valide, wird aber durch jede gute Standard-Software in der einen oder anderen Weise abgedeckt.
2. Datenmodell: Kennzahlen, Entitäten, Attribute, Logiken
Fragestellungen | Welche Kennzahlen, Entitäten und Attribute gibt es? Wie werden sie definiert bzw. berechnet – und wie hängen sie logisch zusammen? Passt die genutzte Terminologie zu meiner eigenen?
Der Sachverhalt | Ohne Frage: Mit dem Datenmodell steht und fällt ein Großteil dessen, was eine BI-Lösung leisten kann. Indem es die Struktur für Kennzahlen, Entitäten, Attribute und Logiken definiert, bestimmt es darüber, was eigentlich analysiert werden kann und wie. Doch wer jetzt denkt: “Ha, mein Reden, genau deshalb brauche ich eine individuelle Lösung mit individuellem Datenmodell!”, der liegt trotzdem falsch, denn innerhalb einer Domäne wie z.B. dem Handel sind die Strukturen dessen, was die Tätigkeitsfelder einzelner Unternehmen ausmacht, einander so ähnlich, dass eine Standardlösung eben doch die bessere Alternative ist – wenn sie denn auf die entsprechende Domäne spezialisiert und keine generische Analyselösung ist. Am Beispiel illustriert: Die wichtigsten Entitäten im Handel sind Kunden, Produkte und Bestellungen – flankiert von ergänzenden Entitäten wie z.B. Kampagnen, Einkaufsbestellungen und Vertriebskanälen. Aus der Erfolgsbewertung für diese Entitäten ergeben sich die benötigten Kennzahlen (rund um den Kern der Transaktionskennzahlen als das Herzstück jeder Analyse von Handelsmodellen) sowie die benötigten Attribute als Merkmalskategorien der strukturellen Entitäten. Aus alledem ergeben sich die (mindestens) 80% Schnittmenge der Anforderungen von Handelsunternehmen an Business Intelligence. Lediglich die verbleibenden 20% ergeben sich aus a) speziellen Geschäftsmodellen wie z.B. Marktplatzmodellen oder Curated Shopping, b) speziellen Prozessen wie z.B. unterschiedlichen Logistikmodellen und/oder c) individueller Kennzahlenterminologie. Tatsächlich deckt eine gute, etablierte BI-Software wie minubo große Teile aus a) und b) trotz Standardisierungsansatz ab, da ihr breites Kundenportfolio über die Zeit für entsprechende Erweiterungen am Datenmodell gesorgt hat – und was nicht bereits abgedeckt wird, kann als individuelle oder auch allgemeine Erweiterung am Datenmodell ergänzend vorgenommen werden. c) ist ein Thema für sich, das ich hier im Blog demnächst separat behandeln werde; zusammengefasst kann ich sagen: Ja, eine eigene Kennzahlenterminologie realisieren zu wollen ist schön und gut, aber die traurige Wahrheit ist, dass es mit derlei unternehmensinternen Terminologien meist nicht weit her ist. Meist pflegt jede Abteilung ihre eigenen begrifflichen Gepflogenheiten und kann sich abteilungsübergreifend kaum verständigen, oft fehlen entsprechende Systematiken sogar ganz. (Dieses Problems nehmen wir uns mit dem “Commerce Reporting Standard”-Projekt an – schaut doch mal rein.) De facto ist es deshalb so, dass eine wirklich konsistente Terminologie, die eine professionelle BI-Software mitbringt, Unternehmen eigentlich nur nach vorne bringen kann; in den seltenen Fällen, in denen Unternehmen tatsächlich selbst über eine umfassend konsistente Terminologie verfügen, können in vielen BI-Softwares Alias-Namen für Kennzahlen und Attribute eingerichtet werden.
Fazit | Ja, die tatsächlichen Individualisierungsanforderungen verbergen sich meist genau hier – doch domänenspezifische BI-Software kann diese in der Regel gut mit abdecken, sei es im durch breite Kundenportfolios entsprechend gewachsenen Standard oder als individuelle Anpassung bzw. Erweiterung.
3. ETL: Datentransformation
Fragestellungen | Wie werden meine Daten auf dem Weg vom Quellsystem zum Data Warehouse verarbeitet? Habe ich Zugriff und kann die Verarbeitungslogiken anpassen?
Der Sachverhalt | Tatsache ist: Je besser (und damit stabiler in Hinblick auf langfristige Nutzbarkeit) das Datenmodell einer Lösung ist, desto weniger müssen ETL-Strecken nach dem initialen Setup überhaupt noch angepasst werden. Klar, Quellsysteme können sich verändern und Anpassungen am ETL-Prozess erforderlich machen, doch das ist ein reines Wartungsthema, nicht anforderungsbedingt. Der Fall auf dieser Ebene liegt deshalb sehr einfach: Ja, Unternehmen haben häufig das Bedürfnis, selbst auf die Datenverarbeitung zugreifen zu können, doch bei guten Lösungen mit durchdachten Datenmodellen ist das im Prinzip nicht nötig. Alles, was hier an Individualisierungsanforderungen aufkommen kann, sollte fachlich eher eine Frage auf Datenmodellebene sein und nur in der Folge Anpassungen an der ETL-Strecke erforderlich machen. Dass das Bedürfnis auf den direkten Zugriff in den Köpfen vieler Leute trotzdem besteht, scheint mir vor allem der Gewohnheit geschuldet bzw. der Tatsache, dass BI-Eigenbau-Projekte häufig als reine Sammlung von ETL-Strecken enden, sodass auf diesem Lösungsbestandteil ein ungerechtfertigt starker Fokus liegt, der eigentlich nur aus technischer Sicht begründet ist, nicht aus fachlicher.
Fazit | Rein fachlich sind Individualisierungsansprüche innerhalb guter BI-Lösungen auf dieser Ebene kaum zu rechtfertigen; technisch sind diese nur für diejenigen begründet, die die Lösung hosten und warten müssen – und das ist bei gekauften Lösungen nicht das Kundenunternehmen selbst.
4. Integration: Datenquellen und Drittsysteme
Fragestellungen | Welche Datenquellen kann ich an meine Business Intelligence anbinden – kriege ich alle Datenpunkte ins DWH, die ich brauche? Kann ich meine in der BI konsolidierten Daten für meine Prozesse in Drittsystemen (z.B. Email-Marketing) nutzbar machen?
Der Sachverhalt | Die Frage nach integrierbaren Datenquellen ist tatsächlich ebenfalls primär eine Frage des Lösungs-Scopes auf Datenmodellebene. Was hier an Datensatztypen vorgesehen ist, lässt sich in der Regel auch quellseitig integrieren – wenn nicht über eine Standardschnittstelle zum spezifischen System, dann über generische Schnittstellen, die einmalig die Einrichtung von Datenexporten in einem bestimmten Format erfordern. Eine solche Schnittstelle ist Bestandteil einer jeden guten BI-Software. Somit verweist uns auch dieser Aspekt zurück zu den Ausführungen von Punkt 2. Bezüglich ausgehender Schnittstellen für die Nutzbarmachung der konsolidierten Daten in Drittsystemen möchte ich wiederum konstatieren, dass wir es hier mit einer Grundanforderung moderner Business Intelligence zu tun haben, denn deren Zweck besteht nicht wie noch in früheren Zeiten primär darin, bunte Pie-Charts zu produzieren, sondern zu einem großen Teil auch darin, operative Prozesse intelligent zu machen und nach Möglichkeit zu automatisieren. Dafür sind ausgehende Schnittstellen, die auf die gesamte Datenbasis auf Rohdatenebene zugreifen und flexibel konfiguriert werden können, zwingend erforderlich. Wer also eine moderne BI-Software kauft, der sollte hier nicht auf Probleme stoßen und kann mit derlei flexiblen Schnittstellen ebenso flexible Datentransfers für individuelle Prozesse einrichten (lassen), wohin er oder sie will. Individualisierungsanforderungen haben also auch in diesem Bereich keinen Bestand und liefern damit kein Argument für eine Eigenbau-BI.
Fazit | Ähnlich wie unter Punkt 3 gibt es auch auf dieser Ebene keine echten Individualisierungswünsche zu stellen. Wieder führen sie uns zurück zu Punkt 2 oder werden nichtig, soweit der Vertriebsdialog mit Anbietern tatsächlich zeitgemäßer BI-Lösungen stattfindet.
Zusammengefasst
Aus den Ausführungen der vorhergehenden Abschnitte wird ersichtlich, dass Individualisierungsanforderungen in der Business Intelligence (anders als die entsprechende Kommunikation mit Unternehmen häufig nahelegt) bei näherem Hinsehen nur auf zwei Ebenen Bestand haben:
Zum allergrößten Teil auf Datenmodellebene, was wiederum (rein technische!) Auswirkungen hat auf Quellsystemanbindung und ETL-Strecken. Diesen individuellen Anforderungen kann durch domänenspezifische Lösungen wie z.B. minubo für den Handel) jedoch in der Regel gut begegnet werden – entweder schon mit dem durch breite Kundenportfolios entsprechend gewachsenen Lösungs-Standard oder durch individuelle Anpassungen bzw. Erweiterungen am Standard-Setup.
Zum kleineren Teil auf der Ebene individueller Frontend-Tools jenseits von Visualisierung und Analyse. Da Unternehmen in Eigenbau-Szenarien jedoch so gut wie nie in der Lage sind, derlei Frontends überhaupt selbst zu bauen, ist dies alles andere als ein Argument für den Eigenbau, sondern erst Recht Veranlassung, die Lösung eines professionellen Anbieters zu kaufen, der in der Lage ist, sein Standard-Frontend um individuelle Tools zu erweitern – z.B. wie minubo mittels einer Plugin-Technologie.
Der einzige k.o.-Case im Kontext von Individualisierungswünschen in der BI (immer vorausgesetzt, wir sprechen von einer tatsächlich leistungsfähigen, zeitgemäßen BI-Software) ist das “Out of Scope”-Szenario: Primär auf Datenmodellebene, in manchen Fällen auch auf Frontend-Ebene, kann ein Lösungsanbieter argumentieren müssen, dass die Anforderungen eines Unternehmens ganz einfach nicht mehr in dem fachlichen Bereich liegen, den er mit seiner Lösung abdecken möchte. In diesem Szenario gibt es nur noch drei gangbare Wege: 1) Der Anbieter wird durch ein sehr gutes finanzielles Angebot doch noch überzeugt, den vorgeschlagenen Weg mitzugehen; 2) die eingekaufte Lösung wird durch Eigenbaukomponenten ergänzt; 3) die “Out of Scope”-Anforderungen sind so umfangreich, dass sich der Aufwand für eine Eigenbau-Lösung tatsächlich lohnt.
Trotz dieses möglichen Cases bleibt das Fazit dieses Artikels bestehen: Da sich die meist überproportional stark empfundenen (und kommunizierten) Individualisierungswünsche von Unternehmen an ihre Business Intelligence in Wahrheit nur auf den genannten zwei Ebenen abspielen und durch eine gute BI-Software auf beiden Ebenen in der Regel gut abgedeckt werden können, sollte jedes Unternehmen sich gut überlegen, ob aus dem Individualisierungsgedanken heraus der immense monetäre und zeitliche Aufwand für eine Eigenbau-BI tatsächlich lohnend ist – denn diese Schlussfolgerung aus dem, wie wir gesehen haben, ziemlich instabilen Prämissengerüst der Individualisierungswünsche wird leider noch immer viel zu schnell gezogen.
