Sicherung des Unternehmenswertes durch Wechsel der E-Commerce-Plattform

Für Ihr Unternehmen ist die Zeit gekommen, sich zu überlegen, zu einer neuen E-Commerce-Plattform zu wechseln. Vielleicht erzielt Ihre aktuelle Plattform weniger Rendite als früher. Vielleicht wird Ihre Fähigkeit zur Innovation durch die Einschränkungen Ihrer bestehenden Plattform gehemmt. Oder vielleicht können sich Ihre Konkurrenten den Veränderungen des Marktes rascher anpassen als Sie.

Was auch immer Ihre Gründe sein mögen, stellen Sie sicher, dass Ihre Entscheidung den Unternehmenswert steigert.

Wechsel sind riskant

Plattformwechsel sind immer riskante Projekte. Sie berühren unweigerlich Systeme, die von kritischer Bedeutung für die Firma sind, sowie wichtige Kontaktpunkte zu den Kunden – innerhalb und außerhalb des Unternehmens. Ihre bestehende Plattform ist vermutlich mit Ihrer Firma gewachsen, so dass viele Ihrer aktuellen Verfahren und Geschäftsabläufe fest darin verankert sind. Das kann es besonders schwer machen, die Kosten und den potentiellen Nutzen Ihres Projekts präzise vorherzusagen. Aus diesen Gründen ist es immer nützlich, sich zu überlegen, ob es für Sie im Wettbewerb von Vorteil ist, Ihre bestehende Plattform zu erneuern und zu vergrößern, statt zu einer völlig neuen Plattform umzuziehen.

Jedoch wollen wir im Rahmen dieses Artikels annehmen, dass Sie bereits ein durchschlagendes Geschäftsmodell entwickelt haben, welches den Umzug zu einer neuen Plattform rechtfertigt. Nun sollten wir einen Blick werfen auf die Wege, mittels derer Sie den Umzug angehen können, um Risiken abzumildern und das Potential einer hohen Investitionsrendite voll auszuschöpfen.

Vergessen Sie „Umheben und Umschalten“

Einen Umzug einfach als Transport aller Funktionen einer bestehenden Plattform zu einer neuen Plattform zu interpretieren, wird häufig von sowohl Kunden als auch Agenturen als eine Option mit geringem Risiko betrachtet. Diese Methode wird manchmal als „Umheben und Umschalten“ bezeichnet.

In Wirklichkeit kann es für Sie das Risiko einer geringen Investitionsrendite vergrößern, den Umzug mittels „Umheben und Umschalten“ anzugehen.

Indem Sie sich auf den „Gleich-zu-Gleich“-Umzug von Funktionen konzentrieren, verpassen Sie womöglich die Chance, die Vorteile der neuen Plattform zu nutzen. Falls die Nachahmung einer Funktion Ihrer alten Website Ihnen keinen echten und messbaren Vorteil gegenüber Ihren Mitbewerbern verschafft, dann kann es besser sein, diese Funktion für den Rahmen Ihrer neuen Plattform zu modifizieren, was Finanzmittel spart und Ihnen ermöglicht, Innovationen in anderen Bereichen durchzuführen.

Genauso bietet sich vielleicht die Gelegenheit, auf Ihrer künftigen Plattform auf einige bisherige Funktionen völlig zu verzichten, falls diese nicht mehr den geschäftlichen Wert besitzen, den sie bei ihrer ursprünglichen Einführung noch besaßen.

Eine neue Plattform individuell anzupassen, damit sie bestehende Backend-Prozesse unterstützt, kann auch sehr kostspielig sein. Deshalb kann es günstiger und weniger riskant sein, so viel wie möglich über die Plattform herauszufinden, und die Bereiche zu identifizieren, in denen Sie die geschäftlichen Abläufe in Ihrer Organisation so gestalten können, dass sie zur neuen Technik passen.

Hier kommt es wiederum darauf an, jene Prozesse zu identifizieren, welche den Wert Ihres Unternehmens am stärksten steigern, und dem Vollzug dieser Prozesse mit Priorität zu behandeln, durch Anpassung Ihrer gegenwärtigen Einstellungen, um Kosten zu sparen und um Finanzmittel für Innovationen in anderen Bereichen übrig zu haben.

Anstatt über „Umheben und Umschalten“ nachzudenken, d. h. über den Transport von Funktionen zur neuen Plattform, ist es für Sie besser, sich die zentralen Geschäftsprozesse und geschäftlichen Werte zu überlegen, welche Sie in der neuen Plattform haben möchten.

Vergessen Sie MoSCoW

„MoSCoW“ (englisches Akronym für Muss ich haben, Sollte ich haben, Könnte ich haben und Will ich nicht haben) wurde zu einer häufig verwendeten Priorisierungstechnik, welche viele Unternehmen verwenden, wenn sie das Projekt eines Plattform-Umzugs starten.

Wenn Unternehmen mit einer großen Zahl von Anforderungen konfrontiert sind, kann „MoSCoW“ ein effizientes Verfahren sein, um die vordringlichen Bedürfnisse in der Organisation zu identifizieren und aufzuzeichnen. Unterstrichen wird dabei auch die Notwendigkeit, die Erwartungen dem anzupassen, was realisierbar ist und was nicht.

Jedoch glaube ich, dass „MoSCoW“ nicht dazu geeignet ist, einem Unternehmen über den wirklichen Wert einer Funktion Aufschluss zu verschaffen. Es ist überdies ein Werkzeug, das zu Diskrepanzen zwischen den Teilhabern des Unternehmens und den mit der Durchführung betrauten Mitarbeitern führen kann. Die Gründe hierfür basieren auf der Verwendung von „MoSCoW“ in der realen Welt.

Bei der Niederschrift von „MoSCoW“ denkt man in der Regel eher an Funktionen als an Ziele. Das Festhalten der Anforderungen in einem „MoSCoW“-Dokument ist eine abteilungsübergreifende Anstrengung; außerdem ist es unvermeidlich simplifizierend, die Interaktionen einer ganzen Firma mit einer Plattform auf diese Weise zusammenzufassen.

Dies kann zur Konkurrenz zwischen den Abteilungen führen, die alle sicherstellen möchten, dass die für sie wichtigen Funktionen berücksichtigt werden. „MoSCoW“ fordert das Unternehmen auch zu einer sehr frühen Festlegung im Anforderungsprozess heraus, was tendenziell dazu führt, dass die „Muss“-Anforderungen zusammengefasst werden, um ihre Berücksichtigung als oberste Priorität zu gewährleisten.

Was ich beispielsweise häufig zu sehen bekomme, das sind „Werbeaktionen“, die als prioritäre und eigenständige Elemente betrachtet werden. Damit einher geht oftmals eine nur minimale Erläuterung der Ziele dieser Werbeaktionen oder der dafür nötigen Vorgehensweisen. So lässt man Sie zurück mit einer zu erbringenden Leistung, aber ohne Ihnen die strategischen Ziele dieser Werbeaktionen mitzuteilen noch die Details der individuellen Werbeverfahren.

Das kann zu starken Diskrepanzen zwischen den Teilhabern und dem Umsetzungsteam bezüglich der Zielsetzung führen, mit potentiell negativen Auswirkungen auf die Finanzen und den Zeitplan.

Wie ich beobachten konnte, machen Unternehmen bei der Verwendung von „MoSCoW“ auch nicht selten den Fehler, die beschriebenen Funktionen entweder aus der Perspektive der alten Plattform zu präsentieren oder aber in der Sprache des neuen Systems, falls es eine bevorzugte neue Plattform gibt. Was in beiden Fällen fehlt, ist das „Warum“, d.h. die Begründung durch die spezifischen Bedürfnisse des Unternehmens.

Das Ergebnis hiervon ist wiederum eine Diskrepanz in der Aufbauphase, mit bereitgestellten Funktionen, welche nicht den Bedürfnissen des Unternehmens entsprechen.

„MoSCoW“ kann ein nützliches Werkzeug bei der Auswahl einer Plattform sein, aber aufgrund seiner simplifizierenden Natur und seiner Tendenz, Erwartungen frühzeitig mit Erbringungen zu verknüpfen, sollte es behutsam verwendet werden.

Es gibt es andere Verfahren der Priorisierung und der Festlegung von Anforderungen. Diese listen noch effizienter die Funktionen auf, die am meisten zur Wertsteigerung Ihres Unternehmens beitragen, zusammen mit der Anstrengung, die nötig ist, um den Umzug zu vollziehen.

Aufdecken von Werten mit Story-Mapping

Bei der Agile Projektlieferung dienen User Stories häufig dazu, auf hohem Niveau festzuhalten, was das System leisten sollte, welchen Wert eine bestimmte Funktion besitzt und wem diese Funktion nutzt. Ein einfaches Beispiel für eine E-Commerce-Website könnte etwa so aussehen:

• Um leicht das spezifische Produkt zu finden, nach dem ich suche (Wert)
• Als Kunde von myecommercesite.com (wer hat Nutzen davon)
• Ich würde die Website gerne nach Produktnamen durchsuchen können (Verhalten des Systems)

Eine User Story ist vor allem eine Erinnerung, ein Gespräch zu führen. Anfangs müssen Sie nicht alle Akzeptanzkriterien erfassen; Sie müssen nur herausfinden, was die Funktion leistet und wieso sie benötigt wird. Erst wenn ein Team von Developern kurz davor steht, sich um die Entwicklung der Funktion zu kümmern, beginnen Sie ein Gespräch zwischen dem Entwicklerteam und den betrieblichen Nutzern, um die Details sowie die Geschäftslogik festzulegen, die zur Fertigstellung der Funktion nötig sind.

Das Story-Mapping wurde 2008 von Jeff Patton beschrieben. Um seine Beschreibung zusammenzufassen, müssen Sie zunächst für das System brauchbare Nutzerergebnisse identifizieren. Davon leiten Sie dann Aktivitäten, Aufgaben und User Story ab, welche zu diesen Ergebnissen führen.

Falls Sie diese Übung dazu verwenden würden, das Beispiel mit der Search-History auszubauen, das oben erwähnt wurde, würden Sie etwa Folgendes erhalten:

Falls Sie dann beginnen, diese Vorgabe für ein einfaches E-Commerce-System mit Inhalten zu füllen, könnten Sie anfangs etwa Folgendes zu sehen bekommen:

Story-Maps werden in Workshops erstellt, an denen sich das gesamte Unternehmen beteiligen sollte. Da die Story-Mapping-Workshops Zusammenarbeit erfordern und über Abteilungen und betriebliche Funktionen hinwegreichen, sind sie ein effektiverer Weg, um ein gemeinsames Verständnis zu schaffen von dem, was die Datenmigration leisten soll.

Es lohnt sich, zu wiederholen, dass die User Story als Erinnerung dienen sollten, ein Gespräch zu führen, sowie um weitere Details herauszuarbeiten, während die Lieferung weiter fortschreitet. Auf diese Weise wird die Vorgabe zu einem dynamischen Werkzeug, das während des Entwicklung einer neuen Plattform durchgängig genutzt werden kann.

Eine der wirksamsten Funktionen einer Story-Map besteht darin, dass sie dabei hilft, zu verstehen, wie die minimale einsatzfähige Fassung Ihrer neuen Plattform aussehen wird, was Sie verwenden können, um die Einführung zu planen. Dies erfolgt durch einen Blick auf die gesamte Story-Map und deren horizontale Unterteilung, damit Sie sehen können, was in jedem Veröffentlichungsschritt enthalten sein muss. Zum Beispiel:

Deshalb sind Story-Maps nicht nur ein effizienter Weg, um die Anforderungen Ihres neuen Systems festzuhalten und zu verstehen; sie sind überdies ein Werkzeug, das Ihnen hilft, auch noch während der eigentlichen Datenmigration alle Bedürfnisse zu erkennen und die Auslieferung zu planen.

Minimales Risiko, maximale Erträge

Jetzt besitzen Sie eine Story-Map, welche Ihnen einen Überblick Ihres Systems verschafft, und nun gilt es Entscheidungen zu treffen, auf welche Weise der geschäftliche Wert am besten ausgeliefert werden kann.

An jeder Stelle der Map sollten Sie sich fragen:

• Bietet die neue Plattform diesen Wert, ohne speziell angepasst zu werden:
• Falls die Plattform den Wert nicht bietet, ohne speziell angepasst zu werden, kann ich dann die Vorgänge in meinem Unternehmen so umstellen, dass ihre Funktionsweise zur neuen Plattform passt?
• Falls die Vorgänge nicht umgestellt werden können und eine spezielle Anpassung nötig ist: Ist die Investition dann durch den Ertrag dieser Funktion gerechtfertigt?

Unternehmen sollten Finanzmittel bereit halten für die Lieferung von maßgeschneiderten Funktionen, die ihnen einen Vorteil gegenüber ihren Konkurrenten verschaffen. Das Ziel beim Stellen dieser Fragen besteht darin, den Umfang der individuellen Anpassung für die Installation von Standardfunktionen möglichst gering zu halten. Die maßgeschneiderte Entwicklung von Plattformen kann sowohl riskant als auch teuer sein. Um dieses Risiko möglichst gering zu halten, sollte Ihr Unternehmen Ausschau halten nach der kostengünstigsten und einfachsten Art, den Wert zu liefern, und nicht nach der Funktion.

Ein Beispiel hierfür im Rahmen des E-Commerce sind die Sonderangebote. Ein Unternehmen kann auf seinem aktuellen System ein bestimmtes 3-für2-Sonderangebot laufen haben, das auf der neuen Plattform nicht mehr möglich ist. Es kann internen Widerstand gegen einen Wechsel des Verfahrens geben und dies könnte bedeuten, dass auf dem neuen System eine individuell angepasste Entwicklung nötig ist. Die individuelle Anpassung der Gestaltung von Sonderangeboten kann jedoch kostspielig sein und es besteht die Gefahr, dass die maßgeschneiderte Entwicklung nicht die erforderliche Investitionsrendite bietet.

Bei diesem Beispiel ist es wichtig, sich daran zu erinnern, dass der Wert, den ein Sonderangebot für ein Unternehmen besitzt, nicht im eigentlichen Angebot begründet ist. Der Wert ergibt sich durch die Wirkung auf das Verhalten des Endverbrauchers und den daraus entstehenden Zuwachs bei der Konversion oder der Größe des Einkaufskorbes. Ist es somit in dieser Situation besser, Finanzmittel für den Systemwechsel einzusetzen, um die Unternehmensprozesse bei Sonderangeboten der neuen Plattform anzupassen?

Die Antwort darauf wird vom individuellen Unternehmen abhängen, aber die Entscheidung zwischen individueller Anpassung der Plattform und Veränderung der Unternehmensprozesse sollte bewusst erfolgen, auf der Basis des Verständnisses des wahren Werts, den eine bestimmte Funktion bieten soll.

Reduziertes Risiko, frühere Freigabe

Wenn ein Unternehmen den Wechsel der Plattform durchführt, besteht die Versuchung, die Inbetriebnahme der neuen Plattform mit so vielen Funktionen wie möglich erfolgen zu lassen. In dieser Situation besteht die Gefahr, dass das Budget für die Entwicklung durch die Lieferung einer Freigabe mit allen Funktionen aufgebraucht wird, und dass das Unternehmen dann nicht mehr dazu in der Lage ist, Funktionen zu verbessern, die sich nach der Inbetriebnahme als wichtig erweisen.

Durch die Analyse der Datenmigration mit den oben erwähnten Planungsverfahren sollten Sie nun einen Überblick besitzen, welche Funktionen für Ihr Unternehmen am wichtigsten sind. Die sollte zu einem Verständnis der Funktionen führen, die nachweislich eine individuell angepasste Entwicklung benötigen, sowie der Bereiche, in denen Veränderungen der Unternehmensprozesse nötig sind, um die gebrauchsfertigen Funktionen der neuen Plattform zu unterstützen.

Um weiterhin die Risiken des Plattformwechsels möglichst gering zu halten, sollte Ihr Unternehmen in Erwägung ziehen, die neue Plattform mit so wenig Funktionen wie möglich in Betrieb zu nehmen. Dies könnte bedeuten, bei der Inbetriebnahme entweder die Zahl der Funktionen zu beschränken oder eine größere Zahl von Funktionen zum Start nur teilweise zu verwenden.

Letzten Endes können Sie erst dann, wenn die Benutzer aus dem Unternehmen und die Kunden mit der neuen Plattform zu interagieren beginnen, wirklich erkennen, welche Funktionen am nützlichsten sind und wo die individuell angepasste Entwicklung zwecks Modifizierung von Funktionen zur stärksten Wertschöpfung führt.

Natürlich muss dies geschehen, ohne die Benutzer des Systems zu enttäuschen. Sie müssen dafür sorgen, dass die von der Plattform erwarteten Basisfunktionen verfügbar sind und dass der Service für die Benutzer nicht unterbrochen wird.

Sehr häufig bieten derartige Funktionen den Unternehmen aber keinen Wettbewerbsvorteil; sie sind Standardfunktionen und sollten deshalb so sparsam wie möglich ausgeliefert werden.

Durch den Versuch einer frühen Freigabe bei gleichzeitiger Beschränkung der Ausgaben können Sie dann von Benutzern aus dem Unternehmen und von Kunden echtes Feedback und Analysen erhalten. Dies ermöglicht anschließend dem Unternehmen die Identifizierung von Funktionen, welche voraussichtlich sehr wirkungsvoll sein werden und bei denen die vorhandenen Daten weitere Investitionen rechtfertigen.

Diese Vorgehensweise ist vor allem dann angezeigt, wenn Plattformen ausgeliefert werden, bei denen weitreichende Erfahrungen von Frontend-Benutzern eine Rolle spielen. Wenn Unternehmen planen, User Experience und Design im Rahmen eines Plattformwechsels zu aktualisieren, dann sind die vor der Freigabe getroffenen Design-Entscheidungen häufig subjektiv und basieren nicht auf echten Benutzerdaten. Ein Benutzererlebnis zu entwerfen und zu errichten, kann kostspielig sein, so dass die Freigabe ‚abgespeckter‘ Versionen, die es Ihnen ermöglichen, Annahmen zu testen und Benutzerdaten in Echtzeit zu sammeln, hilfreich sein kann, um später eine maximale Investitionsrendite zu erzielen.

Sorgen Sie für Innovation

Wie ich bereits unterstrichen habe, können viele Funktionen Ihrer neuen Plattform als Standardfunktionen gelten. Standardfunktionen sind solche, deren Anwesenheit von Ihren Kunden oder Benutzern einfach erwartet wird. Das könnte beispielsweise eine Wunschliste oder ein Ladenfinder auf einer E-Commerce-Plattform sein, oder das Kennzeichnen von beliebten Inhalten in einem Content Management System (CMS).

Falls derartige Funktionen fehlen oder schlecht umgesetzt sind, wird dies zu enttäuschten Kunden führen. Wenn ein großer Teil der für die Auslieferung zur Verfügung stehenden Finanzmittel für die üppige Umsetzung derartiger Funktionen verwandt wird, so wird dies den Unternehmen aber kaum einen echten Wettbewerbsvorteil verschaffen.

Während und nach dem Plattformwechsel sollte ein Unternehmen immer versuchen, Wege zur Innovation zu finden sowie Funktionen zu entdecken, die ihm einen Wettbewerbsvorteil verschaffen.

Wie im Kano-Modell zur Produktentwicklung beschrieben, „freut sich der Kunde, wenn derartige Funktionen vorhanden sind, aber ihr Fehlen verursacht keine Unzufriedenheit, weil der Kunde sie ursprünglich nicht erwartet hat“.

Innovation often requires experimentation, so the business should be looking to retain budget and resources to test and validate innovative ideas against real users, and must be prepared to develop, adjust, or drop these ideas once feedback is gathered

Innovation erfordert häufig Experimentieren, weshalb das Unternehmen Finanz- und Personalmittel bereithalten sollte, um innovative Ideen an echten Benutzern zu testen und zu überprüfen; auch sollte es dazu bereit sein, nach dem Erhalt dieses Feedbacks die Ideen weiterzuentwickeln, anzupassen oder sie fallen zu lassen. Damit ein Unternehmen vollen Nutzen aus seinem Plattformwechsel ziehen kann, muss es Wege finden, die Anstrengung für Funktionen, die es nicht von der Konkurrenz differenzieren, möglichst gering zu halten, und gleichzeitig genug Finanzmittel bereit halten für Experimente und Innovationen in Bereichen, die ihm einen Wettbewerbsvorteil verschaffen.

Fazit

Wenn wir zu unserem ursprünglichen Ausgangspunkt zurückkehren, so kann es schwerwiegende Auswirkungen auf den Erfolg eines Datenmigrations-Projekts haben, dieses nur als „Umheben und Umschalten“ aufzufassen. Wenn Sie als Unternehmen möglichst großen Nutzen aus diesem potentiell kostspieligen und riskanten Vorgang ziehen möchten, dann rate ich Ihnen Folgendes:

• Vermeiden Sie es, Ihr Wechselvorhaben auf eine Liste fester Anforderungen zu reduzieren (z.B. eine Tabelle oder ein „MoSCoW“-Dokument).
• Zeichnen Sie das Navigieren von Benutzern durch Ihr System auf, um die Funktionen zu entdecken, die am wertvollsten sind.
• Identifizieren Sie in den User Stories das „Was, für wen und warum“ und verwenden Sie dies, um während der Auslieferung Gespräche zu führen.
• Reduzieren Sie das Risiko, indem Sie technische Umsetzung im Vergleich mit Veränderungen in den Geschäftsabläufen sorgfältig gegeneinander abwiegen.
• Finden Sie einen Weg, um Ihre neue Plattform so früh wie möglich freizugeben, und lernen Sie aus dem, was Ihnen die echten Benutzer mitteilen.
• Reduzieren Sie die Ausgaben für Standardfunktionen, damit Sie später noch Möglichkeiten zu Innovationen haben.

Über den Autor

Stephen ist ein Projektmanager und Coach mit einer Erfolgsgeschichte in der Durchführung komplexer E-Commerce-, Content- und Innovationsprojekte für globale Marken. Als leidenschaftlicher Verfechter kontinuierlicher Verbesserung und Selbstorganisation trainiert Stephen auch Delivery-Teams und Geschäftsinteressenten in agilen und schlanken Ansätzen.