Data Analytics: Build vs. Buy

Vor- und Nachteile bei Kauf und Eigenentwicklung von Data-Analytics-Lösungen

25.06.2020, Autor: Tom Cahill

Warum bauen oder kaufen?

Wenn sie mit der Notwendigkeit konfrontiert werden, Data Analytics in eine Anwendung einzubetten, stehen die meisten Softwarehersteller am Scheideweg der "Build versus Buy"-Entscheidung.

Warum bauen (oder eher "coden")?

Viele Anwendungsentwickler würden als ersten Reflex auf die Anfrage nach einer Analytics-Lösung versuchen, mit Hilfe von Codebibliotheken oder Charting-Komponenten die erforderliche Berichtsfunktionalität zu erstellen. Dies funktioniert für viele Entwickler, insbesondere bei neuen Software-Anwendungen mit einfachen Anforderungen. Der Hauptgrund für diesen Coding-intensiven Ansatz ist die vollständige Kontrolle über das Aussehen und die Bedienung der Anwendung.

Im laufenden Betrieb verlangern dann die Anwender oft mehr Funktionalität, mehr Flexibilität bei der Analyse und mehr Methoden zur eigenständigen ("Self-Service") Gewinnung von Erkenntnissen. Einige dieser Anfragen können eventuell gelöst werden, indem Daten in eine Tabellenkalkulation exportiert oder Daten programmatisch über eine API extrahiert werden. Hier wird aber nur das Problem eines einzelnen Nutzers gelöst, und das auch nicht skalierbar. Der "Build"-Ansatz bindet also oft beträchtliche interne Ressourcen für Entwicklung und Support. Geichzeitig muss der Entwickler auf der Höhe der Zeit bleiben, was neue technologische Entwicklungen im Bereich Business Intelligence und Data Analytics betrifft.

Warum kaufen?

Viele Softwarehersteller bekommen Druck von Kunden oder Wettbewerbern, ihre Analytics-Funktionen zu verbessern, und oft haben sie weder die Zeit noch die Ressourcen, um diese selber zu bauen. Tatsächlich sind bei Umfragen, die wir bei Software-Anbietern durchgeführt haben, die Hauptgründe für die Einbettung eines Fremdproduktes:

Kosten für den Aufbau und die Pflege der eigenen Kapazitäten - Die anfängliche Entwicklung, der laufende Support und die kontinuierliche Verbesserung der Analyticsfunktionen können sehr aufwendig sein.
Notwendigkeit, schnell auf den Markt zu kommen - In der Regel steht nur ein kleines Zeitfenster zur Verfügung, um Kunden zufrieden zu stellen, ein Produktangebot zu differenzieren und sich auf dem Markt abzuheben.
Wunsch nach internen Ressourcen, die sich auf die Kernfunktionalität der Anwendung konzentrieren - Die Bereitstellung von Funktionalität mit einem Drittanbieter macht das Entwicklungsteam effizienter und setzt Ressourcen für Ihr Kernprodukt frei.

Diejenigen, die auf der "Buy"-Spur sind, sollten verstehen, dass für die Einbettung eines Drittanbieterprodukts immer ein gewisses Maß an Integration erforderlich sein wird. Aber die kürzere Markteinführungszeit für die Bereitstellung einer Fülle von Funktionen rechtfertigt diese Investition. Die Bewertung von "Build vs Buy" erfordert ein Verständnis der zu implementierenden Zielfunktionalität, des für Drittprodukte erforderlichen Integrationsgrades und eine Kosten-Nutzen-Analyse.

Der erste Schritt zur Beantwortung der Frage "Build or Buy" besteht darin, Ihre Anforderungen zu verstehen. Bestimmen Sie die gewünschte Endbenutzerfunktionalität, priorisieren Sie Ihre Bedürfnisse und bewerten Sie dann die Durchführbarkeit des Aufbaus solcher Fähigkeiten.

1. Identifizieren Sie die Kernfunktionalität

Es ist also extrem wichtig, Funktionslücken, die Sie füllen möchten, zu verstehen. So können Sie eine Capability Map erstellen, die Benutzer und benötigte Funktionen zusammenbringt. Hier sind die Funktionen, die Softwareanbieter häufig implementieren möchten.

Bereitstellung von Informationen:
Dashboards und Datenvisualisierungen
Berichte
Mobile BI
Terminierung und Exporte
Interaktivität:
Verlinkungen
Personalisierung
Erstellung von Dashboards und Berichten
Workflow, Write-Backs und Prozesse
Analyse:
Visuelle Analyse
Benchmarking
Advanced Analytics
Externe Daten

2. Wählen Sie eine integrierte Benutzererfahrung

Neben der Implementierung von analytischen Kernfunktionen ist es wichtig zu planen, wie diese Funktionen in den Kontext der gesamten Anwendungserfahrung eingebettet oder integriert werden.

Analysemodul - häufig erstellen Anbieter von Anwendungen ein Berichtsmodul oder "Register", das im Rahmen der Anwendung erscheint.
Inline-Analyse - zur Schaffung einer besseren Benutzererfahrung werden analytische Inhalte in bestehende Anwendungsseiten eingebettet, um die Benutzer bei ihrer Arbeit innerhalb der Anwendung zu unterstützen.
Analyse-Workflows - um die beste und effizienteste Benutzererfahrung zu schaffen, werden Analysefunktionen zunehmend in die Kernworkflows von Anwendungen integriert: Wenn Benutzer mit analytischen Inhalten interagieren, werden sie entweder zu einem bestimmten Teil der Anwendung geführt oder initiieren Backend-Prozesse, die es den Benutzern ermöglichen, im gleichen Kontext ihrer Analyse auf die Daten einzuwirken.

3. Prioritäten setzen

Als nächstes priorisieren Sie die gewünschte Funktionalität auf der Grundlage der Geschäftstreiber.

Zeit - Welche Funktionen benötigen Sie jetzt? Welche Funktionen können warten?
Auswirkungen auf den Umsatz - Welche Funktionen ermöglichen es Ihnen, ein separates Angebot zu schnüren und Daten und Analysen zu monetarisieren? Welche Funktionen haben Ihre Kunden nachgefragt? Welche Funktionalität würde es ihnen erleichtern, ihr Geschäft zu behalten?
Wettbewerbsdifferenzierung - Wodurch heben Sie sich von der Masse ab und können Sie leichter neue Kunden gewinnen?

4. Bestimmen Sie die Durchführbarkeit der Codierung selbst

Bestimmen Sie schließlich die Durchführbarkeit der Bereitstellung der von den Kunden benötigten Funktionalität innerhalb Ihrer Zeitvorgaben. Die meisten Anwendungsanbieter können grundlegende Funktionen selbst entwickeln, z. B. gefilterte Berichte, statische Diagramme und Datenexporte. Für höherwertige und hochgradig interaktive Funktionen setzen Unternehmen in der Regel Produkte von Drittanbietern ein, um wettbewerbsfähig zu bleiben und gleichzeitig die Funktionen zeitnah und ressourceneffizient zu implementieren.

Um Ihre Implementierungsoptionen richtig zu bewerten, ist es wichtig, den Nutzen und die Kosten jeder Option qualitativ, wenn nicht gar quantitativ zu bewerten und den ROI für jede Option zu vergleichen.

Definition des Zeitrahmens

Es ist wichtig, einen Zeitrahmen für eine solche Analyse festzulegen. Diese Dauer sollte Ihnen genügend Zeit geben, um den künftigen Nutzen und die Kosten zu verstehen, bevor sich die Bedingungen in einer Weise ändern, die Sie zwingen könnte, Ihre Optionen erneut zu überdenken. Für Technologieinvestitionen wird oft ein Zeitrahmen von 3-5 Jahren verwendet.

Vorteile

Im Vergleich zur eigenen Programmierung erhalten Sie durch die Verwendung eines Drittanbieterprodukts mehr Möglichkeiten in kürzerer Zeit. Der schnellere Weg zur Wertschöpfung ist in der Regel ausschlaggebend für die "Kaufentscheidung". Wenn Sie quantitative ROI-Modelle erstellen, wird sich dieser Zeitunterschied als Erreichen der Gewinnschwelle zu einem früheren Zeitpunkt im Projektlebenszyklus bemerkbar machen.

White Paper Build vs. Buy:
10 versteckte Kosten beim Bauen von Analytics mit UI-Komponenten

Verwandte News

Out-of-the-Box- Entwicklungsplattform für Embedded Analytics

11.06.2020

Alle News

	Build	Buy
Zusammenfassung	Für die Bereitstellung einer umfangreichen Funktionspalette benötigen "Build"-Optionen im Vergleich zu "Buy"-Optionen in der Regel mehr Zeit, was sich in einer längeren "Time to Value" niederschlägt - langsamere Kundenakquise und -akzeptanz, geringere Fähigkeit zur Kundenbindung und niedrigere Verkaufspreise für Ihr Produkt.	Kauf-Optionen bringen Sie im Vergleich zu "Build"-Optionen früher auf den Markt, was sich in einer schnelleren Time-to-Value niederschlägt - Kundenakquisition und -akzeptanz, höhere Kundenzufriedenheit und Kundenbindung sowie höhere durchschnittliche Verkaufspreise für Ihr Produkt. Wenn Sie sich auf einen Drittanbieter mit einer Reihe von Funktionalitäten verlassen, verbessert sich die Klarheit Ihrer Roadmap und Ihre Fähigkeit, der sich ändernden Kundennachfrage gerecht zu werden.
Zeit bis zur Markteinführung	Bei umfangreicher Funktionalität dauert die codeintensive Entwicklung sowohl für die erste Version als auch für nachfolgende Versionen länger. Das bedeutet, dass es länger dauert, die Vorteile Ihres Analyseprojekts zu realisieren und Ihre potenzielle Kapitalrendite zu verzögern.	Wenn Sie früher auf den Markt kommen, werden Sie die Vorteile Ihres Analyseprojekts erkennen und Ihre Chance auf eine positive Rendite Ihrer Investition deutlich erhöhen.
Mehrwert	Wenn neue eingebettete Analysefunktionen schneller auf den Markt kommen, wird sich die Entwicklung beschleunigen: Benutzerakzeptanz Kundenzufriedenheit Neue Verkäufe und Kundengewinnung Produkt-Differenzierung
Operative Effizienz	Analysefähigkeiten bieten operative Vorteile: Weniger Ad-hoc-Berichtsanforderungen Schaffung von Vertriebs- und Marketingeffizienz für Anbieter kommerzieller Anwendungen
Zeit bis zur Markteinführung	Die Abhängigkeit von internen Entwicklungsressourcen für die Implementierung neuer Funktionen schränkt die Vorhersehbarkeit der langfristigen Bereitstellung ein, insbesondere wenn zusätzliche Entwickler erforderlich sind.	Mit einer breiten Palette von Funktionen, die von einem Fremdprodukt bereitgestellt werden, haben Sie einen besseren Einblick in Ihre Produkt-Roadmap und eine größere Flexibilität im Produktbereitstellungsprozess.

Vergleich der Kosten für "Build" und Buy"

Im Vergleich zur Eigenentwicklung erhöht die Verwendung eines Produkts eines Drittanbieters Ihre Kosten für die Software-Lizenzierung, senkt jedoch Ihre Entwicklungskosten, sowohl anfänglich als auch im laufenden Betrieb. Ihre Analyse sollte auch die Opportunitätskosten und Projektrisiken einschließen.

	Build	Buy
Kosten	Zusammenfassung: "Build"-Optionen erfordern im Allgemeinen mehr Entwickler-Ressourcen und benötigen im Vergleich zu "Buy"-Optionen mehr Zeit für die Implementierung ähnlicher Funktionen. Die Abhängigkeit von den Entwicklern erhöht auch die Opportunitätskosten und Risiken für die langfristige Roadmap.	Zusammenfassung: Während "Kauf"-Optionen im Allgemeinen die Investitionen in Software erhöhen, benötigen sie im Vergleich zu "Build"-Optionen weniger Entwicklerressourcen und bringen Sie früher auf den Markt. Sich auf einen Drittanbieter mit einer Reihe von Funktionen zu verlassen, verringert die Opportunitätskosten und Risiken für die Roadmap.
Software-Lizenzierung	Code-intensive Ansätze nutzen häufig Diagrammbibliotheken oder Visualisierungs-Frameworks. Entwickler sollten eine ordnungsgemäße Lizenzierung für die Verwendung in Ihren kommerziellen Produkten sicherstellen.	Für den Erwerb umfangreicherer Funktionen sind die finanziellen Investitionen in Software höher, wenn Sie einen Drittanbieter von Business Intelligence und Analysen einsetzen. Stellen Sie sicher, dass für Ihre kommerziellen Produkte eine OEM-Vereinbarung besteht.
Services ( Training, Support)	Wenn Sie sich auf Ihr internes Entwicklungsteam verlassen, haben Sie weniger Kosten für externe Anbieter.	Softwarehersteller bieten eine Reihe von Self-Service- und Full-Service-Optionen an, die auf Ihre Markteinführungszeit und Ihren Personalbedarf zugeschnitten sind.
Interne Ressourcen (Entwicklung, Wartung und Erweiterung)	"Build" erfordert mehr Entwicklungsressourcen, nicht nur in Bezug auf die Anzahl der Ressourcen, sondern auch in Bezug auf hochqualifizierte Programmierer. Beachten Sie, dass diese Ressourcen kontinuierlich benötigt werden, um Ihre Analysefunktionalität im Laufe der Zeit aufrechtzuerhalten, zu unterstützen und zu verbessern.	Bei Software von Drittanbietern benötigen Sie in der Regel weniger Entwicklungsressourcen und weniger qualifizierte Ressourcen, die für Sie leichter zugänglich sein werden. Das Hinzufügen und Verbessern von Funktionen im Laufe der Zeit erfordert ebenfalls weniger Entwicklerressourcen.
Opportunitätskosten	Da sich Ihre Entwicklerressourcen auf Analysefunktionen konzentrieren, sind sie nicht für die Entwicklung Ihres Kernprodukts oder Ihres geistigen Eigentums zuständig. Infolgedessen wird sich dies auf die Roadmap Ihres Kernprodukts auswirken.	Bei einer monetären Investition in Software ist es wichtig, diese Investition mit geringeren Entwicklungskosten und einer schnelleren Markteinführung in Einklang zu bringen.
Risiken	Sie sind für die aktuelle Funktionalität und Ihre zukünftige Roadmap vollständig von internen Entwicklerressourcen abhängig. Obwohl dies für kleinere Organisationen ein Standardverfahren ist, ist es bei Ihrem Wachstum nicht ideal.	Bei einer monetären Investition in Software ist es wichtig, diese Investition mit geringeren Entwicklungskosten und einer schnelleren Markteinführung in Einklang zu bringen.

Return on Investment

Einigen mag "Build" als die offensichtliche Wahl für die Einbettung von Analysefunktionen in ihre Anwendung erscheinen. Doch selbst wenn es vom Investitionsstandpunkt aus betrachtet als die weniger kostspielige Option erscheint, ist es möglicherweise nicht die lohnendste Option.

Der Return-on-investment (ROI) ist das Endergebnis Ihrer 'Build'- vs. 'Buy'-Entscheidung. Das Schöne an einer ROI-Analyse ist, dass Sie im besten Fall ein eindeutiges Ergebnis haben, die Sie mit anderen Stakeholdern teilen können. Der Nachteil ist, dass diese Ergebnis nur so gut sein wird, wie Ihre Annahmen und Ihre Gründlichkeit. Dieser Text soll helfen, die primären Kosten und Amortisationsmöglichkeiten von "Build vs. Buy" zu ermitteln. Aber Sie sollten auf jeden Fall Nachforschungen anstellen, um die weniger offensichtlichen Faktoren aufzudecken, die für Ihre Organisation einzigartig sein könnten.

Eine der größten Variablen ist die Schätzung der eigenen Entwicklungskosten, die nie zu 100% ermittelt werden können. Verschiedene Scoping-, Prototyping- oder POC-Übungen können die Genauigkeit der Schätzungen verbessern, aber diese können selbst erhebliche Kosten und Aufwand verursachen. Auf der anderen Seite müssen Sie bei einer Kaufentscheidung Vertrauen in die Fähigkeit eines Herstellers haben, wie versprochen zu liefern.

Weiterführende Links:

> Build vs Buy Webinar (on demand)

> Build vs Buy White Paper

Über den Autor

Tom Cahill ist Vizepräsident EMEA | APAC bei Logi Analytics. Zuvor war Tom Vice President EMEA bei Jaspersoft (jetzt TIBCO) und bei Talend. Mit Sitz in Dublin, Irland, ist Tom ein anerkannter Vordenker in Analytics. Er hält einen gemeinsamen Abschluss von der Dublin City University und der Technischen Universität (Berlin) in International Marketing & Languages und besuchte die Freie Universität (Berlin, Deutschland). Kontakt: LinkedIn