Nico Kotsapanajotou
11. Februar 2022
6 min
Eine strukturierte Evaluation von Software ist grundlegend für den Erfolg eines jeden E-Commerce Projektes. Dabei werden auch heute noch zahlreiche Fehler begangen, die vollkommen unnötig sind. Die folgenden Tipps helfen dabei, sich bei der Evaluation von E-Commerce Projekten zu orientieren.
Die Form und Qualität der bekannten Anforderungen definieren maßgeblich den Prozess der Software-Evaluation. Das Auslassen wichtiger Erkenntnisse kann weitereichende Folgen bis in die Umsetzung des Projektes haben und teilweise sogar zum Scheitern eines Projektes führen. Daher ist es wichtig, dass möglichst viele der Anforderungen vorab in einem detaillierten aber übersichtlichen Format bereitgestellt werden. Auf garkeinen Fall User-Stories in der Evaluationsphase verwenden, diese sollten (wenn überhaupt) später in der Umsetzung zum Tragen kommen. Übersichtlich heißt: Am besten tabellarisch in einer Excel-Datei. Ein schwammiges Anforderungsdokument in einem undefinierten Format führt unter anderem dazu, dass das Feedback der Lösungsanbieter oder Agenturen nicht vergleichbar ist. Daher unbedingt die Form zum Feedback vorgeben, damit die Vergleichbarkeit gewährleistet ist!
E-Commerce Systeme kommunizieren über Schnittstellen Daten zwischen verschiedenen Datenbanken. Das zentrale Medium von Software sind immer Daten. Zu einer gelungenen Evaluation gehört neben Features und den Rahmenbedingungen auch das erstellen der Datenmodelle. Dazu gehören in der Regel mindestens Produktdaten, Kundendaten und Bestelldaten. Diese Datenmodelle sollten grundlegend beleuchtet und Herausforderungen in der Umsetzung mit Dienstleistern besprochen werden. Nicht zuletzt dienen sie als Grundlage für die Erstellung von Schnittstellenbeschreibungen.
Wer sich gleich vom erstbesten Anbieter (am besten noch per Kaltakquise) einfangen lässt, ist selbst schuld. Hochkomplexe Enterprise-Software ist kein vorgefertigtes Produkt was ich mir mit ein paar Klicks konfiguriere und dann exakt so kaufe, wie zum Beispiel ein Auto. Software muss an vielen Stellen individuell angepasst werden, so dass sie zu Deinen Prozessen passt. Daher ist es wichtig verschiedene Anbieter (Agenturen oder Software-Anbieter) zu kontaktieren und diese mit den relevanten Fragestellungen zu konfrontieren. Am besten auf Basis des Anforderungskatalogs Feedback von mehreren Anbietern einholen und gewissenhaft vergleichen.
Viele Sales-Mitarbeiter (vor allem im E-Commerce Umfeld) haben heute weitreichende technische Verständnisse. Dennoch ist es essentiell Software Projekte auch auf einer technischen Ebene zu evaluieren. Dazu gehören auch grundlegende Fragestellungen rund um Hosting, Schnittstellen und Microservices. Deswegen ist es unabdingbar sein eigenes IT-Team (wenn vorhanden, ansonsten den eigenen Dienstleister) sowie Techies auf der Anbieter-Seite mit an den Tisch zu holen. Vor allem die technische Kompetenz auf der Gegenseite sollte unbedingt geprüft werden. Bei Agenturen empfiehlt es sich auch die verantwortlichen Software-Architekten / Entwickler kennenzulernen und deren Background und Kompetenzen zu beleuchten. Viele Software-Projekte geraten in Schieflage, weil die Teams auf Agenturseite überfordert sind (qualitativ oder quantitativ).
Es ist wichtig, dass man vor dem Start eines Projektes auch die involvierten Fachabteilungen abholt. Nicht nur im Sinne eines gelungen Change-Managements, sondern auch um zentrale Fragestellungen mit dem jeweiligen Fachwissen zu beleuchten. So ist es z.B. bei der Auswahl eines neuen E-Commerce Systems äußerst relevant auch die verschiedenen Anforderungen aus Marketing, Logistik, IT und anderen involvierten Bereichen zu kennen und Lösungsvorschläge intern zu diskutieren. Nur so kann verhindert werden, dass es im Projektablauf zu großen blockierenden Hürden kommt.
Wie auch in der Umsetzung sind Deadlines, vor allem fiktive, oft der Treiber für falsche Entscheidungen. Viele C-Level Verantwortliche schauen aus der Vogelperspektive auf essentielle Projekte und verstehen nicht, dass es weitreichende Folgen haben kann eine Entscheidung nur wegen eines Stichtages zu treffen. Lieber mit viel Einsatz um eine erweiterte Deadline kämpfen als mit einem mulmigen Gefühl in ein Projekt zu starten!
Auch die Vergabe von Budgets erfolgt oft ohne jegliche Begründung. Wer im Jahr 2022 noch ein Software-Projekt in ein starres Budget-Korsett presst, der hat etwas falsch verstanden. Vielmehr werden die Budgets ohnehin über einen Zeitraum abgerufen, der meistens auch länger ist, als erwartet. Daher lieber eine Lösung evaluieren, die zum groben Budget-Rahmen passt, wenn sich dieser aber begründet erhöht, unbedingt Kosten und Nutzen miteinander abgleichen und ggf. das Budget erhöhen, bevor man ein Flugzeug ohne Sitze baut.
Es macht immer Sinn sich frühzeitig mit dem gewünschten Design zu beschäftigen. So sollte man schnellstmöglich an einer Designrichtlinie oder einem digitalen CI-Guide arbeiten. Dennoch sollte man berücksichtigen, dass die Lösung und vor allem der Lösungsweg oft auch Implikationen auf die Designs mit sich bringen. Wenn ich mich zum Beispiel für ein Frontend-Framework (wie z.B. Vue Storefront) entscheide und den Wunsch äußere nah am Standard zu bleiben, um die Kosten nicht explodieren zu lassen. Dann muss ich zunächst den Standard kennen, um dies zu gewährleisten. Oft werden in den Designs auch Features verarbeitet, die es gar nicht gibt, oder die individualisiert werden müssen. Daher sollte das Design-Thema in der Frühphase sich eher auf Farben, Schriften, Button-Styles und grundlegende Dinge kümmern und dann nach der Entscheidung für ein System mit konkreten Layouts angereichert werden.
Es ist essentiell, dass während der Evaluation möglichst viele Anforderungen bekannt und auch die zukünftige Ausrichtung klar ist. ABER: Es macht in der Regel Sinn für die erste Umsetzungsphase nur einen Teil der Anforderungen im Rahmen eines gut strukturierten MVPs zu nutzen. Das sorgt dafür, dass die Projektgröße überschaubar bleibt und man schnell an den Markt gehen kann. Auch könnte man, sofern es Probleme mit dem Dienstleister gibt noch einmal den Umsetzungspartner wechseln. Nichtsdestotrotz müssen natürlich Anforderungen für weitere Iterationen auf Machbarkeit geprüft werden. Bei einer Migration von einem Alt-System sollte der erste Wurf mindestens die gleiche Funktionalität mit sich bringen sowie einige nicht zu aufwändige Verbesserungen. Alle weiteren umfangreichen Anforderungen werden dann direkt ins das neue Produktiv-System gespielt. So ist man früh am Markt und nutzt schnellstmöglich das Potential der neuen Software.
Jedes ambitionierte Projekt benötigt auf beiden Seiten (Kunde und Agentur) ein fähiges Projekt-Team. Es ist essentiell, dass genügend Zeit eingeplant wird und Ansprechpartner nicht zu sehr in andere Themen (wie z.B. Tagesgeschäft) eingebunden sind, um sich auf das Projekt zu konzentrieren. Ein zügiges und gut durchdachtes Feedback auf offene Fragen ist äußerst relevant für den Projekt-Erfolg. Müssen Product-Owner zu viel Rücksprache mit zögerlichen Vorgesetzten halten, die dann nur schwammige Aussagen treffen, sinkt die Erfolgschance drastisch. Die verantwortlichen Personen müssen unbedingt in der Lage sein Entscheidungen auch selbst zu treffen und der Gegenseite auch alle relevanten Informationen zur Verfügung zu stellen.
Wenn der NDA (Vertraulichkeitsvereinbarung) für die ersten Gespräche zehn Mal hin und her geht und dabei zwei Wochen Zeit verlorengehen, dann läuft was schief. Es ist essentiell grundlegende Themen abzuklären, gerade für große Corperates, wenn aber Rechtsthemen für den 100. Edgecase den Austausch und das Vorankommen im Projekt blockieren, dann muss man auf Unternehmensseite darüber nachdenken, ob das nicht zu viel des Guten ist. Gerade bei der Zusammenarbeit mit kleineren Dienstleistern muss man sich im Klaren sein, dass wenn man Compliance Themen zu den zentralen Fragestellungen erklärt, man nur noch schleppend vorankommt.
