11 Tipps, wie man ein E-Commerce-Projekt auf jeden Fall mit Wucht an die Wand fährt

Oder: Wie der Perspektivwechsel hilft, im Gegenteil die bessere Lösung zu entdecken.

In der Kreativitätstechnik gibt es eine Methode, die sich “Flipflop-Technik” nennt. Diese hat nichts mit Badelatschen zu tun, sondern trägt dem Umstand Rechnung, dass die Psychologie der meisten Menschen im Umgang mit negativen Gedanken deutlich kreativer ist als im Umgang mit positiven Vorstellungen. Heißt konkret: Man sammelt alle Punkte, die dazu beitragen könnten, dass ein Vorhaben misslingt, “flipflopt” diese anschließend ins Gegenteil und kommt so sehr schnell zu neuen kreativen Lösungsansätzen – jenseits der üblichen Denk- und Handlungsmuster.

Regel Nummer 1:
Vertraut auf die Marketing-Versprechen der Software-Hersteller.

In unserer lustigen kleinen Gegenteil-Welt gehen wir davon aus, dass Marketing nie lügt und übertreibt. Entsprechend verlassen wir uns getrost darauf, dass alle Verkaufsargumente stimmen und eine Software (wie versprochen) ALLES kann. Im Fall der Commerce-Software bedeutet das: Sie steigert die Conversion, reduziert Prozesskosten, ist einfach zu bedienen, natürlich modular, individuell anpassbar, flexibel bei den Konditionen, zukunftsorientiert usw. KI, Cloud und SaaS sind natürlich auch am Start. Ob es sich dabei um ein Shopsystem, eine Middleware, ein PIM, einen Payment-Provider, eine Recommendation-Lösung oder sonst was handelt, spielt erst mal gar keine Rolle. Es ist praktisch immer alles drin in der Suppe, was der erfahrene IT-Koch als Bullshit-Bingo an Gewürzen in seiner Küche stehen hat. 

Natürlich lassen wir uns in unserer Gegenteil-Logik auch irgendwelche Cases zeigen, die am besten gar nichts mit der eigenen Situation zu tun haben. Wenn man sieht, dass die Software anderswo funktioniert, ist doch egal, ob die Lösung zu den eigenen Anforderungen passt. Am Ende lässt sich ja jede Software so verbiegen, wie man sie benötigt. Customizing for the Win. 

Stellt sich nun die Frage, WER denn am besten entscheiden sollte, welche Lösung passt … damit am Ende gar nichts passt. Damit wären wir schon bei der nächsten Regel:

Regel Nummer 2:
Lass die IT entscheiden, welche Software eingesetzt werden soll. 

Um maximalen Misserfolg zu provozieren, sollte die interne IT – oft auch noch liebevoll EDV genannt – die Software auswählen. Vielleicht sogar in Zusammenarbeit mit einem sehr konservativen Datenschutzbeauftragten. Denn wen interessiert schon, ob die Anwender nachher gut damit arbeiten können? Hauptsache, die richtige ISO-Zertifizierung liegt vor. 

Zweite Option: Sollte es eigene Entwickler im Haus geben, können auch die einfach die Software auswählen. Und zwar auf Basis eigener Interessen. Wer hat Lust auf welche Programmiersprache? Wer hat was von einem Kumpel gehört? Der coole neue Kram ist ja zum Glück schon lange erprobt, Kinderkrankheiten gibt es nicht, und die Trends sind sicherlich auch lange von Bestand – kennt man ja … hier in der Gegenteil-Welt. Wer in den letzten Jahren erste Erfahrungen mit Kubernetes-Lösungen für E-Commerce oder PaaS gemacht hat, mag ahnen, was wir meinen. 

Womit wir direkt beim nächsten Thema sind …

Regel Nummer 3:
Übertragt die Projektverantwortung einer Person, die NICHT die Software ausgewählt hat.

Sehr weit verbreitet und einfach großartig, wenn alles scheitern soll: Nachdem der IT-Silberrücken den heißesten Scheiß ausgewählt hat, den außer ihm keiner versteht, ist es ein “Killer-Move”, die Verantwortung für das gesamte Implementierungsprojekt z. B. in die Marketing-Abteilung zu geben. 

Das knallt dann auf jeden Fall. Hurrah! Die IT hat für “so was” gar keine Zeit. Die müssen sich tagtäglich um das veraltete ERP kümmern, damit der Laden läuft. Die großen Weichen sind nach 2 Workshops gestellt. “Und das bisschen Shop kann doch wohl das Marketing machen”, denkt es sich voller Selbstüberzeugung im Scheiterland. Schließlich müssen die Marketeers ja später auch Aktionen pflegen und Kampagnen fahren. Dann kann dieses Team der Agentur einfach direkt sagen, wie das alles so werden soll. Die IT hält sich da raus. Wirklich ganz wichtig, wenn man vor der Wand landen möchte: Entscheidungen der IT und des Marketings maximal voneinander trennen. 

Jetzt haben wir uns also schon erklärt, wie wir eine Short List der Systeme erhalten und wer hier auswählen sollte. Aber woher weiß man eigentlich welche Anforderungen an ein System gestellt werden sollten?

Regel Nummer 4:
Erstelle über einen langen Zeitraum einen möglichst genauen RFP und nehme möglichst viele Stakeholder und Abteilungen, die das Wort eCommerce schon einmal gehört haben, mit hinzu.

Es ist super hilfreich fürs Scheitern, möglichst alle Beteiligten mit ins Boot zu holen und deren Use Cases zu berücksichtigen. Hierbei könnte man auch den Erfahrungsgrad der verschiedenen Personen in Betracht ziehen. Denn nichts ist gefährlicher als Unknown Unkowns. 

Wichtig ist dabei, keine Profis dazuzuholen und einfach nur runter zu schreiben, was man bereits kennt. Am besten versucht man Prozesse, die historisch gewachsen sind, gar nicht erst zu hinterfragen, sondern wieder genau so abzubilden. 

Das ist super für den Misserfolg – denn je genauer alles im Vorfeld geplant wird, desto größer wird das Chaos später, wenn das wahre Leben auf der Matte steht. Und hier scheitert es sich dann sogar doppelt. Denn zuerst verbrennt man unendlich viel Zeit im Pflichtenheft und dann, wenn alles anders kommt, investiert man halt nochmal mindestens genauso viel Zeit. Doppelte Verschwendung also. Yipieeh! 

Optional: Gar nichts selber machen. Sondern rumfragen, ob jemand jemanden kennt, der schon mal sowas gemacht hat. 

Um die Verwirrung zu maximieren, schlagen wir als nächstes dies vor:

Regel Nummer 5:
Ignoriere angrenzende Systeme.

Hier gibt es beim weiteren Scheitern 2 Möglichkeiten: 

1. Bitte nur einzelne RFPs, damit keiner weiß, was der andere tut. So hat jeder die Möglichkeit, schön in verschiedene Projekte reinzugrätschen und die Blame Games können beginnen.
2. Ein Monster-Projekt aufsetzen, indem einfach alle Systeme gleichzeitig durch moderne Lösungen ersetzt werden. Wer braucht schon Schritt-für-Schrit -Pläne? Ist doch viel besser, wenn die Überforderungen gleich alle Abteilungen betrifft.

Wenn Tipp 1 beherzigt wird – also andere Systeme ignoriert werden – dann kracht es in der Regel sehr schnell, weil bei der exakten Planung am Anfang (s. vorheriger Tipp) z. B. gar nicht klar war, dass die Schnittstelle vom modernen Shopsystem zum alten ERP komplett neu geschrieben werden muss. Denn: Das vom Shop-Hersteller empfohlene Plugin ist gar nicht kompatibel mit dem ERP – upps! – und die Auftragsdaten sind nicht sauber übergeben worden. Dafür kann man schön einfach den Implementierungspartner verantwortlich machen und verlangen, dass er die zusätzlichen 80 Personentage für die Schnittstellenentwicklung (die ursprünglich nicht zum Projektscope gehörte) on top, ohne Nachberechnung und ohne Impact auf den Zeitplan erledigt. Damit hat man schon sehr früh eine vergiftete Stimmung im Projektteam und das ist in jedem Fall förderlich fürs Scheitern. 

Wird Tipp 2 beachtet – also werden möglichst viele Systeme in einem Monster-Projekt getauscht – dann erreicht dies, dass die Projektbeteiligten mit der Zeit den Fokus verlieren. Es entsteht eine Planungssituation wie früher im Mathe-Unterricht, wenn man eine Formel mit zu vielen Variablen hatte: Man kann es nicht mehr ausrechnen, sondern muss verschiedene Zahlen einsetzen und gucken, ob was Vernünftiges rauskommt. Trial und Error halt. Ist doch eh gerade hipp in der Arbeitswelt – fail often and fail fast. 

Da wir schon bei der Erhebung der Anforderungen sind: 

Regel Nummer 6:
Erwähnt immer wieder, dass ihr alles im Standard machen wollt und alles State of the Art sein muss.

Aber vorher bitte nicht genau definieren, was das konkret bedeutet. Wir alle wissen doch, wenn man unterschiedliche Personen bittet, ein Haus mit Baum und Sonne zu malen, dann sieht das am Ende bei allen genau gleich aus. Oder etwa nicht? Was soll also dieses gemeinsame Verständnis und Vom-gleichen-reden? 

Besser ist es, in den Disput zu gehen … so von wegen, dass doch alles ganz anders gemeint war. Und dass doch wohl klar ist, was State of the Art bedeutet. Schafft zusätzlich eine total angenehme Atmosphäre in der Zusammenarbeit. Aber Schwamm drüber. Irgendwann ist das Projekt ja auch beendet und dann kann man sich endlich um offene Rechnungen streiten und sich gegenseitig die Schuld für Verzögerungen und Mehraufwände geben. Friede, Freude, Schlammschlacht im Misserfolg-Land!

Regel Nummer 7:
Klärt die Verantwortlichkeiten niemals im Vorfeld.

In der Regel ist ein IT-Projekt, wie z. B. eine Shop-Implementierung, kein im Unternehmen isoliertes Projekt, sondern steht in Wechselwirkung mit anderen IT-Systemen und ist daher in einen größeren Zusammenhang eingebunden. Ein Shop-Projekt ist da oftmals ein Teilprojekt – meist ein sehr großes – des Gesamtprojektes “Ausbau der IT-Architektur”. 

Ein erster Schritt in Richtung Scheitern wäre, diese unterschiedlichen Dimensionen außer Acht zu lassen und die Verantwortlichkeiten nicht zu klären. Auch sehr hilfreich fürs Scheitern: Diese unterschiedlichen Verantwortlichkeiten an ein und dieselbe Person vergeben. Die verliert dann irgendwann ziemlich sicher den Fokus und verirrt sich in den unterschiedlichen Anforderungen. Bitte also nichts auf zwei Leute mit klarem Fokus verteilen. Sonst könnte das Projekt klappen … aber das wollen wir ja nicht. 

Richtig sicher wird das Scheitern übrigens, wenn man ohne explizite Klärung z. B. von der Projektleitung der Shop-Agentur – praktisch unausgesprochen – erwartet, dass sie nebenbei auch noch die Verantwortung für das gesamte IT-Projekt übernimmt. Inklusive Koordination aller intern und extern Beteiligten. Das kann sie gar nicht und deswegen geht es auf jeden Fall schief. Wunderbar!

Wichtig dabei ist auch, dass unterschiedliche Dienstleister und Parteien niemals gemeinsam an einen Tisch geholt werden, um miteinander zu sprechen. Im Idealfall bastelt jeder erst einmal selbst vor sich hin. Schaut, was kann ich und was hab ich? 

Wenn Sie das gut vorbereiten, können Sie später bei Schwierigkeiten einfach wahllos die Projektleiter der Teilprojekte verantwortlich machen. So erreicht man wirklich Chaos einer ganz besonderen Größenordnung.

Aufgepasst! Wir starten jetzt also endlich – nach einer halben Ewigkeit – mit unserem Projekt. Aber wie fängt man hier am besten an? 

Regel Nummer 8:
Ein bis ins Detail ausgefeiltes Design ist viel wichtiger als gute Prozesse. 

Wir alle wissen doch, wie wichtig es ist, dass so ein Onlineshop “schön” ist. Deshalb sollte man sicherheitshalber gar nicht das Feedback vom Markt abwarten, sondern erstmal ein teures Design in Auftrag geben. Bei der Umsetzung also auch entsprechend damit beginnen und über jeden Pixel so lange wie möglich diskutieren. 

Wenn nach hinten raus dann zeitliche Probleme beim Testen der Prozesse auftreten, ist das halt so. Wen interessiert schon, ob die Bestellung in allen Systemen sauber ankommt? Wichtig ist doch, dass der Banner in jeder erdenklichen Größe topp aussieht. Und seien wir mal ehrlich – wir wissen doch, dass der Kunde sonst erst gar nicht bestellt. 

Außerdem ist es doch viel besser, wenn die Fehleranalyse während des Live-Betriebs läuft. Vor allem, wenn im Checkout irgendetwas nicht funktioniert. Ist doch viel besser, wenn alle mit Schweiß auf der Stirn unter explosivem Druck den Fehler suchen. Vielleicht gibt es auch noch die Möglichkeit, freitags nachmittags zu deployen. Wenn dann was umfällt, haben noch alle am Wochenende was davon. Und vielleicht entstehen sogar noch extra Kosten für SLA Zeiten. 

Und weiter geht’s mit der Umsetzung. Hier haben wir noch einiges an Potential beim Scheitern: 

Regel Nummer 9:
Mehr Workarounds sind immer besser. 

Man sollte von vornherein versuchen, die ausgewählte Software so zu verbiegen, dass sie sich an die gewünschten Prozesse anpasst. Wir hatten zwar ganz zu Anfang über Standards gesprochen – aber es war ja wohl klar, dass wir das anders gemeint haben. Man lasse sich auf keinen Fall dazu hinreißen, Basisarbeit intern zu leisten. 

Kaum auszudenken, was passieren würde, wenn zunächst die Produktdaten sauber aufbereitet und veredelt würden, sodass Personalisierung, Filterung und Suche optimal funktionieren können – und das auch noch in unterschiedlichen Kanälen. 

Nein, nein, diese Zeit hat niemand. Außerdem hat das vorher auch schon irgendwie geklappt, da fassen wir das lieber nicht an. So hat man außerdem die Möglichkeit, sich weiter über die unfähige Agentur, die nutzlose Technologie usw. aufzuregen. 

Außerdem stellt man sicher, dass neue Projekte ebenfalls nur so semi gut umgesetzt werden können, weil die Basis nicht stimmt. Workarounds sorgen auch für mehr Arbeit, so ist schon mal klar, dass man keine (Umsatz generierende) effiziente Arbeit leistet und weiterhin im alten Trott bleibt. Wie kann man sich auch sonst darüber echauffieren, dass man immer so viel zu tun hat und keiner zu seiner eigentlichen Arbeit kommt? 

Wer denkt, damit haben wir in der Umsetzung alles beachtet, der täuscht sich. 

Regel Nummer 10:
Sorgt von Beginn an dafür, dass ihr technische Schulden implementiert.

Es ist immer erstrebenswert, bewährte technische Praktiken wie Codequalität, Tests und Wartbarkeit zu übergehen, um Zeit zu sparen. Man kann sich ja später drum kümmern. Und der Spruch “Nichts hält länger als eine vorläufige Lösung” ist sowieso erstunken und erlogen. Vielleicht gilt doch: “Das Produkt reift ja eh beim Kunden”.

Das Schöne dabei ist, wenn das Team schon im Projekt dafür sorgt, dass Themen nicht sauber erarbeitet werden, gibt es bereits bei den ersten Updates und Anpassungen kleinere bis größere Herausforderungen. Jeder ärgert sich, weil niemand mehr weiß, wieso was so ist, wie es ist. Keiner mag mit dem System arbeiten. Perfekt!

Und wenn sich die Zuständigkeiten ändern, haben auch andere noch was davon. Super.

Wo befinden wir uns jetzt gerade? Die Software ist von den richtigen Menschen ausgewählt worden, niemand trägt die Verantwortung, Design wird bearbeitet, technische Schulden implementiert … fehlt eigentlich nur noch der Go Live, oder? 

Regel Nummer 11:
Geht erst live, wenn wirklich alles fertig ist.

Was ist schon dieses neumodische Gerede von MVPs wert? Wenn man wirklich sicherstellen will, dass jegliches Budget und jede Timeline hinfällig wird, dann immer erst live gehen, wenn wirklich jedes Feature, über das jemals nachgedacht wurde, live ist und jeder Pixel an der richtigen Stelle sitzt. 

Alle wissen ja: So eine Plattform ist irgendwann auch fertig und muss nicht mehr weiterentwickelt werden. Was soll auch dieses komische Marktfeedback sein? 

Und Software und Technik entwickeln sich ohnehin nicht weiter, richtig? 

Zielsetzung: Einfach das Projekt budgetär komplett ausufern lassen, erst im kommenden Jahr live gehen oder noch besser: das Scheitern auf die Spitze treiben und alles daran setzen, dass das Projekt komplett eingestampft wird.

Einatmen. Ausatmen. Sacken lassen. So langsam haben wir genug “gefloppt”? Richtig. Darum flippen wir zum Ende noch einmal zurück. Willkommen daheim, in der Erfolgswelt. Schluss mit den großen, bunten Scheiter-Fantasien. Wir sind uns sicher: Wer sich einmal mit der Logik des Scheiterns beschäftigt hat, kommt direkt auf eine Vielzahl von Ideen, die helfen, es besser zu machen. Und sollte es an der einen oder anderen Stelle doch noch hapern … gibt es ja auch noch uns. Wir Shopmacher haben schon so viele Projekte vor dem Fast-Crash gerettet, dass wir für jedes Problem eine Lösung haben. Versprochen.

Was wir auch noch können