White Paper


Risky Business: How to Succeed in Building Digital Platforms


Wir teilen unsere Projekt-Insights, Erfahrungen und Empfehlungen vom Anforderungskatalog bis hin zur Systemintegration. Unsere Plattform-Expertise, Ihr Vorteil.

Dieser Artikel ist ein Auszug aus einem umfassenden White Paper. Um das gesamte Paper zu lesen, bitte hier entlang.

Introduction

Welcome to the land of risk and high reward.

Der Aufbau einer digitalen Plattform kann oft zur tückischen Reise werden – wie jedes große, komplexe Technologieprojekt. Vom Auftraggeber über die Agentur, die das Projekt entwickelt, bis hin zum Unternehmensberater irgendwo in der Mitte: Jeder hat etwas zu verlieren. Das Risikopotenzial ist vielschichtig.

Scheinbar aus dem Nichts wird die Implementierung bestimmter Funktionen komplexer als ursprünglich gedacht. Bestehende Systemlandschaften offenbaren plötzlich Hürden für die Integration, die niemand hat kommen sehen. Agenturpartner entpuppen sich als überfordert, weil sie zwar eingangs viel versprochen haben, aber wenig davon halten können. All das ist schon passiert, schwer zum Nachteil des geplanten Projektumfangs und seines Budgets. Ein Projekt, das auf einem wackeligen Fundament aufgebaut ist, führt zu einem mangelhaften Ergebnis – wenn am Ende überhaupt etwas dabei herauskommt.

Und dennoch gibt es Hoffnung. Auch wenn viele digitale Projekte zum Scheitern verurteilt sind, ist klar: es muss es nicht auf diese Weise enden. Projekte scheitern entlang dreier Dimensionen: Zeit, Budget und Erwartungen. Die Entwicklung kann länger dauern als geplant, die Kosten können aus dem Ruder laufen und das Endergebnis kann nicht wie erwartet ausfallen. Häufig treten alle drei gleichzeitig auf. Im Allgemeinen bedeutet ein gelungenes Plattformprojekt: Sein Ergebnis generiert einen echten Business Value für den Auftraggeber und beweist damit, dass das Marktkonzept tragfähig ist – alles innerhalb des vorgegebenen Budgetrahmens, versteht sich.

Es ist oft gerade nicht die technologische Komplexität, die ein Projekt zum Scheitern bringt – obwohl die Technologie natürlich eine immense Rolle spielt. Die Hauptrisikofaktoren liegen in Fehlkommunikation, unzureichender Vorbereitung und unzulänglichem Controlling. Tauchen wir in die wichtigsten Problembereiche ein und schauen uns an, wie sie vermieden werden können – um Plattformen aufzubauen, die zum Erfolg führen.

Requirements Engineering

The devil is in the details.

Jedes Plattformprojekt beginnt damit zu definieren, was überhaupt getan werden muss: die technischen Anforderungen, also Requirements Engineering. Welche Eigenschaften sollte die Plattform aufweisen, um ihren Zweck zu erfüllen und den beabsichtigten Business Impact zu erzielen? Von dieser Frage hängt ab, welche Technologien implementiert werden müssen, welches Fachwissen von den Entwicklern verlangt wird, und welche Entwicklungszeiten bzw. Kosten zu erwarten sind. Sie ist entscheidend – und wirklich schwer eindeutig zu beantworten.

Die meisten Unternehmen versuchen ihre Antwort dadurch zu finden, dass sie granular Features auflisten und die jeweiligen Funktionalitäten bis ins letzte Detail beschreiben. An sich ist das keine schlechte Sache; schließlich ist es gut zu wissen, was man will. Was dieses Vorgehen aber so gefährlich macht, ist das, was es nahelegt: dass ein Projekt nur dann erfolgreich ist, wenn das Ergebnis genau so ist, wie es ursprünglich im detaillierten, fein abgestimmten Konzept beschrieben wurde. Das ist ein Problem.

Die aus einem Projekt resultierende Plattform muss zum Geschäftsmodell und zum Marktansatz passen – und nicht jede Feature-Idee abbilden. Tut man letzteres, schließt man nämlich die Möglichkeit aus, zu verifizieren, dass all die Dinge, die man sich ursprünglich ausgedacht hat, tatsächlich einen Mehrwert bringen. In der Praxis zeigt sich erst bei der Umsetzung, wie wertvoll bestimmte Funktionen sind – oder ob sie schlicht zu teuer sind für Wert, den sie versprechen.

»Wir haben festgestellt, dass es nicht so sehr darauf ankommt, wie gut oder schnell Entwickler sind – sie sollten beides sein, keine Frage. Trotzdem ist es eigentlich wichtiger, sich zu fokussieren und die richtigen Prioritäten zu setzen«, sagt Matthias Gronwald, Technical Director.

In der Tat geht es in der Anforderungsphase um Fokussierung. Wenn Wunschdenken auf die Realität trifft, was ist dann machbar und was ist sinnvoll? Zu Beginn hat oft alles die höchste Priorität. Die Aufgabe einer Agentur ist es, zu kommunizieren, was innerhalb eines vorgegebenen Zeitrahmens und Budgets realistisch ist. Dann ist es entscheidend, festzulegen, was zuerst erledigt werden muss und was warten kann.

»Hier ist Erfahrung wirklich wichtig. Die Übersetzung der Anforderungen in die technologische Umsetzung ist der einfache Teil. Der schwierige Teil besteht darin, Auftraggeber davon zu überzeugen, dass die Funktionen, die sie gerne hätten, unrealistisch oder weniger entscheidend sind, als sie denken«, sagt Matthias Gronwald.

Wenn Feature-Listen so furchtbar sind, warum ist es dann so schwer, sie loszuwerden? Die Antwort liegt in einem Wort: Sicherheit – oder besser gesagt, in der wahrgenommenen Sicherheit. Wenn sich alle auf eine Liste von zu implementierenden Features einigen, dann suggeriert das, dass sie am Ende auch wirklich genau diese Features bekommen.

»Häufig werden detaillierte Feature-Spezifikationen Teil des Vertrags zwischen Auftraggeber und Agentur, um die eigene Position für den Fall zu sichern, dass das Projekt nicht wie geplant verläuft. Aber diese Sicherheit ist vollkommen fiktiv. So vorzugehen führt nicht automatisch dazu, dass sich im Laufe des Projekts verändernde Bedingungen oder neue Informationen in Luft auflösen«, sagt Christopher Möhle, CEO.

Anstatt sich zu sehr auf Features zu konzentrieren, sollten Unternehmen so klar wie möglich in ihrer Gesamtvision und ihren Zielen – sein und für alles andere einen anpassungsfähigen Plan haben. Software-Projekte sind agile Projekte. Der richtige Weg bei der Plattform-Entwicklung besteht darin, dreißig bis vierzig High-Level-Anforderungen zu definieren und sie zu konkretisieren. Nicht darin, sie in sechshundert Unterfunktionen zu zerlegen.

Ein gutes Projekt baut nicht nur auf einer soliden Strategie auf – es geht auch darum, die richtigen taktischen Manöver anzuwenden. High-Level-Anforderungen machen taktische Entscheidungen möglich, da sie im Licht neuer Fakten, Zahlen und Entwicklungen ständig neu interpretiert werden können.

Ganz nach Ihrem Geschmack?


Jetzt das komplette White Paper herunterladen (Englisch).

Technology Selection

Using standard software is smart. Unless custom software is smarter.

Wenn die erste und wichtigste Frage ist, welchem Zweck eine Plattform dienen soll, dann ist zweite, mit welchem Tool-Set sie tatsächlich implementiert werden soll. Welche Technologien sind geeignet, um die Plattform zu entwickeln und zu betreiben? Noch so eine Frage, die nicht allgemein, sondern nur für jeden Einzelfall spezifisch beantwortet werden kann. Klar ist: Die Auswahl der richtigen Technologie-Stacks ist aufgrund der hohen Lizenzkosten für Unternehmenssoftware ziemlich riskant – und zu diesem Zeitpunkt hat man noch nicht einmal mit der Implementierung begonnen. Es gilt also, sicherzugehen, dass man für die jeweilige Aufgabe auf die richtigen Tools setzt.

Technologienauswahl bedeutet in erster Linie einen genauer Realitätscheck. Häufig entscheiden sich Unternehmen für Standard-Software – Hybris oder Spryker für Commerce, Salesforce als CRM, S/4Hana als ERP. Was man sich davon verspricht, etablierte, bewährte und in der Regel vertrauenswürdige Produkte zu verwenden, liegt auf der Hand: Jeder nutzt sie (daher auch der Standard), sie verfügen über solide Ökosysteme, und es ist viel Erfahrung vorhanden. Sobald die Entscheidung für eine Technologie gefallen ist, bedeutet das, dass sich der Kreis an möglichen Dienstleistern schon vorweg verkleinert hat. Unternehmen mappen ihre Anforderungen mit den Feature-Katalogen der Softwareprodukte, treffen eine Entscheidung und suchen dann eine Agentur.

»Wenn wir in Projekte starten, dann ist die Technologiefrage häufig schon beantwortet. Im besten Fall war während des Entscheidungsprozesses ein gewisses Maß an Erfahrung im Spiel. Es gibt jedoch Fälle, in denen wir überhaupt nicht davon überzeugt sind, dass die gewählte Software für das Projekt geeignet ist. Oder es hätte auf einem anderen Weg gelöst werden können. Aber die Lizenzen sind bereits eingekauft, sodass ein Rückzieher keine große Option mehr ist«, sagt Sarah Hoidn, Senior Consultant.

Im Allgemeinen ist es eine gute Idee, zumindest eine zweite Meinung einzuholen vor der endgültigen Entscheidung. Um zu vermeiden, dass Geld für ein Tool ausgegeben wird, obwohl ein anderes vielleicht besser geeignet ist, kann die frühzeitige Einbeziehung der ausführenden Agentur in den Entscheidungsprozess ausschlaggebend sein.

Standard-Softwareprodukte haben auch ihre Nachteile. Der wichtigste liegt in der umfangreichen Anpassung, die notwendig ist, um die Software für jeden einzelnen Anwendungsfall zu adaptieren. Meistens bedeutet das, einige Module herauszulösen und andere anzupassen. Das kostet Zeit und Geld – zusätzlich zu den Lizenzgebühren.

»Wenn es zum Anwendungsfall passt, würden vor allem größere Firmen gut daran tun, etwas mutiger zu sein und stattdessen Dinge von Grund auf selbst zu entwickeln. Ich würde lieber in ein eigenes Developer-Team investieren oder ein kleines Agenturteam einsetzen und mir über zwei Jahre hinweg meine Anforderungen selbst abbilden«, sagt Matthias Gronwald.

Wird Eigenentwicklung gut gemacht, vor allem entlang etablierter Entwicklungsstandards, dann kann es die Folgekosten erheblich senken. Darüber hinaus ermöglicht es den Aufbau eigener technologischer Expertise. Das ist entscheidend – schließlich ist eine Plattform mehr als nur ein neuer Vertriebskanal: Unternehmen, die Plattformen bauen und betreiben, müssen Technologie in ihrem Kern verstehen.

Controlling

Controlling ensures more than a clean project. It keeps you flexible.

Kein Projekt kann jemals ohne ein qualitativ hochwertiges Controlling erfolgreich sein. Software-Projekte sind riskant; Risiken müssen gemanagt werden. Vereinfacht sieht das meiste Controlling so aus: Wissen, wie viel Gesamtbudget zur Verfügung steht, die Ausgaben im Auge behalten und die Differenz ermitteln, um die verbleibenden Aufwände richtig zu kalkulieren. Controlling erfolgt in regelmäßigen Abständen, z.B. monatlich, zweiwöchentlich oder um Projekt-Meilensteine herum. Die Account-Manager teilen und diskutieren die Ergebnisse mit Projekt-Stakeholdern, um das weitere Vorgehen abzustimmen. So weit so einfach.

Das ist aber nur die halbe Wahrheit: Wenn es um Controlling geht, ist der agile Ansatz passé. Während man in der Planungsphase flexibel bleiben und sich auf hohe Anforderungen konzentrieren sollte, muss man bei der Steuerung des eigentlichen Entwicklungsprozesses sehr viel detaillierter vorgehen. Es ist entscheidend zu wissen, wie viel Zeit nicht nur für jede Aufgabe, sondern auch für jede Unteraufgabe und Unter-Unteraufgabe aufgewendet wurde. Wie weit ist deren Entwicklung fortgeschritten und wie viel mehr Zeit wird benötigt, um sie abzuschließen? Zeit ist schließlich Geld – und Geld ist endlich.

Darüber hinaus ist Controlling eine kontinuierliche Aufgabe, die während des gesamten Projekts und nicht nur periodisch durchgeführt wird. Agenturen sollten in der Lage sein, jeden Tag ein sehr detailliertes, granulares Status-Update zu geben – wenn schon nicht für jedes Ticket, so doch zumindest auf der Epic-Ebene. Kontinuierliches Micro-Controlling sollte niemals vernachlässigt werden, da man sonst Gefahr läuft, die Übersicht zu verlieren. Außerdem bleibt ein Projekt gerade dadurch wendig: Man behält die Möglichkeit, Ressourcen flexibel zu verschieben.

»Man sollte rote Lämpchen sehen, sobald sie anfangen zu blinken, nicht erst am Monatsende oder, im schlimmsten Fall, wenn ein Projekt fast abgeschlossen ist. Vereinfacht ausgedrückt, muss man zu jedem Zeitpunkt wissen, wie viele Entwicklungstage für jede Aufgabe übrig bleiben und bei Bedarf entsprechend umverteilen. Dinge, die vorher nicht offensichtlich waren und nicht Teil des Vertrages sind, werden plötzlich unvermeidbar und müssen erledigt werden«, erklärt Christopher Möhle.

Das bedeutet, dass man den Input der Developer einholt, um Restschätzungen vorzunehmen. Immer wieder müssen sie neu abschätzen, wie viel Aufwand in Zukunft erforderlich sein wird. Diese Variable ändert sich ständig, denn je länger Entwickler an einem Projekt arbeiten, desto mehr lernen sie, desto besser können sie vorhersehen, wie lange etwas dauern wird, und desto schneller werden sie in ihren Aufgaben.

Die Kommunikation mit Stakeholdern ist ein wichtiger Teil davon, man muss sie so transparent wie möglich auf dem Laufenden halten. Dies erfordert Aufwand und Ressourcen, die richtigen Leute für die Aufgabe sowie ein System, auf das sich alle einigen können.

»Wann Probleme in einem Projekt auftreten, hängt von zwei Dingen ab: Erfahrung und Qualität des Controllings. Erfahrung lässt einen von Anfang an wissen, wenn etwas zu komplex und zu teuer für das Budget ist, und abschätzen, was tatsächlich erforderlich wäre«, sagt Christopher Möhle.

»Gutes Controlling ermöglicht es, so früh wie möglich "positiv zu enttäuschen", das heißt auf Probleme hinzuweisen, bevor sie sich manifestieren, und sie sofort zu eskalieren. Wenn diese Dinge später unerwartet auftauchen, hat man seine Arbeit nicht gemacht.«

Zusammengefasst: Ein Projekt, das früh Risse offenbart, ist oft erfolgreicher als ein scheinbar glatt laufendes, ruhiges Projekt. Probleme, die während der Implementierungsphase auftauchen, können ein Zeichen von Unerfahrenheit sein. Wenn sie sich erst am Ende zeigen, hat das Controlling versagt.

Agency Selection - Communication - Integration

War's das schon?

Nein, ganz im Gegenteil: Es gibt noch einiges zu beachten bei der Entwicklung einer erfolgreichen Plattform. Im vollständigen Paper finden Sie weitere Insights zu Agentur-Auswahl, Kommunikation und Systemintegration. Jetzt herunterladen!

Bitte füllen Sie das Formular aus, um das Dokument herunterzuladen.


Fußnoten
 
Autoren
Thomas Weber, Brand Ambassador
thomas.weber@turbinekreuzberg.com

Samuel Krist, Consultant
samuel.krist@turbinekreuzberg.com

 
Mit Input von
Christopher Möhle, CEO
christopher.moehle@turbinekreuzberg.com

Sarah Hoidn, Senior Consultant
sarah.hoidn@turbinekreuzberg.com

Matthias Gronwald, Technical Director
matthias.gronwald@turbinekreuzberg.com