Software-Auswahl im E-Commerce: Wie aus 60 Seiten Lastenheft die falsche Plattform wird

Es ist Dienstag, 9:15 Uhr. Konferenzraum drei, vierter Stock. Auf dem Tisch liegt ein Dokument mit 64 Seiten. Drei Anbieter haben es ausgefüllt zurückgeschickt. Das Auswertungsteam ist seit vier Monaten dran. Heute fällt die Entscheidung.

Eigentlich fällt sie nicht. Sie ist längst gefallen. Irgendwo zwischen dem zweiten Demo-Termin und der dritten Folie mit zufriedenen Kundenlogos. Niemand im Raum würde das so formulieren. Aber alle spüren es.

Sechs Monate nach Go-live trifft sich dieselbe Runde wieder. Diesmal fällt das Wort "Customizing" oft. Auch das Wort "eigentlich". Und am Ende die unausgesprochene Frage: Wie sind wir hier gelandet?

Diese Geschichte hat einen Namen. Sie heißt Request for Proposal, kurz RFP. Und sie funktioniert genau so, wie sie gebaut wurde. Schlecht.

Laut dem 2024er Future-Commerce-Report The Honest Truth: Unmasking the Software Selection Rate rechnen 82 Prozent der befragten Online-Händler schon beim Vertragsabschluss damit, dass die spätere Lieferung kaum noch etwas mit dem zu tun hat, was im Angebot steht. Anders gesagt: Wir wissen, dass wir uns belügen lassen. Wir machen trotzdem mit.

Dieser Artikel zerlegt warum. Fünf Mechanismen sorgen dafür, dass selbst der gewissenhafteste Auswahlprozess die falsche Plattform produziert. Und am Ende: was stattdessen funktioniert.

Was ist ein RFP im E-Commerce-Kontext?

Ein Request for Proposal (RFP), im deutschen Sprachgebrauch oft als Lastenheft oder Ausschreibung bezeichnet, ist ein strukturiertes Dokument, mit dem ihr mehrere Anbieter zur Abgabe eines vergleichbaren Angebots auffordert. Im E-Commerce typischerweise mit funktionalen Anforderungen, technischen Spezifikationen, Integrationsbedarfen, Mengengerüsten und kommerziellen Rahmenbedingungen.

Zur Abgrenzung: Ein RFI (Request for Information) ist die Vorstufe und dient nur der Marktsichtung. Ein RFQ (Request for Quote) ist die reine Preisanfrage bei klar definiertem Scope. Der RFP liegt dazwischen. Er ist zu spezifisch, um wirklich offen zu sein, und zu unspezifisch, um valide Vergleiche zu ermöglichen. Genau das ist sein eingebauter Konstruktionsfehler.

Falle 1: Das Lastenheft, das niemand mehr versteht

Die wenigsten Ausschreibungen entstehen aus einer ehrlichen Analyse des heutigen Geschäftsmodells. Sie entstehen aus Resten. Eine Vorlage aus dem Magento-Projekt von 2019, ergänzt um Bullet-Points aus einer Shopware-Roadshow, garniert mit Anforderungen, die jemand aus dem Sales-Team mal aufgeschrieben hat. Das Ergebnis ist ein Dokument, das auf den ersten Blick vollständig wirkt und auf den zweiten Blick zeigt, dass niemand mehr weiß, warum was drinsteht.

Hier greift dann Conway's Law. Die These ist alt, stimmt aber unverändert: Jedes System, das eine Organisation baut, wird die Kommunikationsstruktur dieser Organisation widerspiegeln. Übersetzt auf eure Plattformwahl bedeutet das: Wenn euer Auswahlprozess in Silos läuft, Marketing und IT seit zwei Jahren nicht mehr in einem Raum waren und die Geschäftsführung Entscheidungen per E-Mail trifft, bekommt ihr am Ende eine Software, die genau diese Silos abbildet. Ihr kauft euch keine moderne Plattform. Ihr betoniert eure internen Reibungspunkte in einem teureren Setup.

Best Practice: Bevor jemand ein Word-Dokument öffnet, klärt in einem zweitägigen Workshop, welche drei bis fünf Geschäftsfähigkeiten ihr in den nächsten 24 Monaten aufbauen müsst. Formuliert die Anforderungen aus diesen Capabilities heraus, nicht aus der Vorlage von 2019. Wir bei datrycs starten Auswahlprozesse genau hier: mit einer Capability-Map statt einer Feature-Liste. Das halbiert das Lastenheft und verdoppelt die Aussagekraft.

Falle 2: Wenn der Berater einen Partner hat

"Wir beraten neutral." Diesen Satz hörst du in jedem Vorgespräch mit einer beratenden Agentur. Schöner Satz. Stimmt selten. Sobald ein Provisionsmodell oder ein Partnervertrag im Spiel ist, kippt die Neutralität.

Der Future-Commerce-Report beziffert das ungewöhnlich klar: 58 Prozent der befragten Entscheider lassen sich in ihrer Plattformwahl davon beeinflussen, ob die beratende Agentur zertifizierter Partner einer bestimmten Plattform ist. Plötzlich werden innovative Alternativen "nicht enterprise-ready", weil sie eben nicht im Partnernetzwerk des Beraters auftauchen. Das ist nicht zwingend böser Wille. Es ist Selektionsbias, der durch ökonomische Anreize verstärkt wird. Und er wirkt sich exakt dort aus, wo es am teuersten ist: bei der Grundsatzentscheidung.

Best Practice: Lass dir von jeder Agentur im Auswahlprozess transparent zeigen, mit welchen Plattformen sie Partnerschaften unterhält und welche Margen oder Boni daran hängen. Wer ausweicht, ist raus. datrycs ist bewusst Partner mehrerer Plattformen. Genau deshalb können wir plattformunabhängig empfehlen, ohne dass die Rechnung am Monatsende von einer einzigen Lösung abhängt.

Falle 3: Wenn jeder Anbieter "ja" sagt

Stand 2026 ist die funktionale Differenz zwischen den großen Enterprise-Plattformen weitgehend eingeebnet. Shopify Plus, Shopware 6, Salesforce Commerce Cloud, BigCommerce, commercetools, SAP Commerce. Alle haben Warenkorb, Checkout, Promotion-Engines, Multi-Storefront, B2B-Modul, Headless-APIs. Die Funktionsüberlappung liegt geschätzt bei rund 90 Prozent. Wer im Lastenheft fragt "Unterstützt eure Plattform Gutscheincodes?", bekommt von allen ein höfliches Ja. Diese Information ist wertlos.

Worauf es wirklich ankommt, sind die 10 Prozent Differenz. Und vor allem das Wie. Beispiel: "Gutscheincodes konfigurieren" kann fünf Klicks bedeuten oder ein Plugin von einem Drittanbieter, dessen Maintenance-Status fragwürdig ist. Diese Differenz fragt aber kein klassisches Lastenheft ab. Genauso wenig fragt es nach Developer Experience, technischer Schuld pro Release, Update-Frequenz, Breaking Changes der letzten 24 Monate, Patch-Verhalten bei Sicherheitslücken. Also nach allem, was später Geld kostet.

Best Practice: Streicht alle Fragen, die mit "Habt ihr…?" oder "Bietet ihr…?" beginnen. Ersetzt sie durch Aufgaben: "Bitte zeigt uns in der Standardimplementierung, wie ein B2B-Kunde einen Mengenrabatt mit drei Staffelpreisen für ein Sortiment von 50 Artikeln konfiguriert. Wie viele Klicks? Welche Rolle? Welche Risiken bei Änderungen?" Erst solche Aufgaben zeigen, was wirklich im Karton ist.

Falle 4: Wenn die investierte Zeit die Entscheidung übernimmt

Nach vier Monaten Vorbereitung, drei Stakeholder-Workshops, zwei Demo-Tagen und einem Scoring-Sheet mit 312 Kriterien ist euer Team emotional und politisch an den Prozess gebunden. Selbst wenn in der finalen Demo offensichtlich wird, dass die favorisierte Lösung architektonische Probleme hat oder der Anbieter eure Branche kaum kennt, wird sie häufig trotzdem gewählt. Weil ein Abbruch bedeuten würde, die investierten Monate als verloren zu deklarieren. Und das macht in einer Organisation politisch niemand gern.

In der Psychologie heißt das Sunk Cost Fallacy. Das Phänomen ist gut belegt, in Auswahlprozessen aber selten benannt. Die Entscheidung wird dann nicht mehr für die nächsten drei Jahre getroffen, sondern um die letzten vier Monate zu legitimieren. Eine ehrliche Bilanz wäre billiger. Sie wird aber selten gezogen.

Best Practice: Definiert vor dem Start des Prozesses ein klares Abbruchkriterium. Beispiel: Wenn nach der ersten Demo-Runde keine der drei Lösungen mindestens 80 Prozent der Top-5-Capabilities ohne Anpassung abbildet, wird der Prozess gestoppt und der Scope neu bewertet. Schriftlich, von der Geschäftsführung freigegeben. Das senkt die politische Hemmschwelle, später wirklich auszusteigen.

Falle 5: Wenn "einfach per API" der teuerste Satz im Projekt wird

In jedem Vendor-Pitch fällt der Satz "alles per API integrierbar". In jedem zweiten Pitch zusätzlich "out of the box". Die Realität in eurem Unternehmen sieht meistens anders aus: ein SAP- oder Microsoft-Dynamics-ERP mit historisch gewachsenen Custom-Feldern, ein PIM aus zwei Akquisitionen, ein WMS, das nur SOAP spricht, plus drei Excel-Tabellen, die niemand löschen darf, weil "der Vertrieb das so macht".

Wenn diese Realität auf "Standard-Integration" trifft, wird eine Anpassungsrunde notwendig, deren Aufwand selten ehrlich kalkuliert wird. Der Future-Commerce-Report liefert dazu die andere bittere Zahl: 86 Prozent der Entscheider bereuen die Tiefe der Anpassungen, die nach Go-live nötig wurden. Jedes größere Update wird zur Mehrmonats-Aufgabe. Statt einer modernen Plattform habt ihr dann eine Sonderlocke gebaut, die euch genauso bindet wie das Altsystem, nur teurer.

Best Practice: Definiert vor dem Lastenheft, welche eurer aktuellen Prozesse ihr bewusst aufgeben würdet, um näher am Standard der neuen Plattform zu bleiben. Wer hier kein einziges Zugeständnis machen will, sollte den Auswahlprozess abbrechen und stattdessen den Bestand modernisieren. Das ist oft günstiger als eine teilangepasste neue Plattform.

Klassisches Lastenheft vs. moderner Auswahlprozess im Vergleich

Was die Tabelle nicht zeigt: Die wahre Differenz liegt nicht in den Prozesskosten. Sie liegt in der Qualität der Entscheidung. Ein klassischer RFP optimiert auf Auditierbarkeit und formale Vergleichbarkeit der Anbieter. Ein moderner Auswahlprozess optimiert darauf, die richtige Plattform zu finden. Das sind zwei verschiedene Ziele. In stark regulierten Umfeldern (öffentliche Hand, Banken, Pharma) führt am formalen RFP kein Weg vorbei. Für alle anderen gibt es bessere Optionen, sie werden nur selten genutzt.

Was wirklich funktioniert

Drei Verschiebungen ändern die Qualität der Entscheidung substantiell:

Erstens: von Checklisten zu Geschäftsszenarien. Statt 312 Kriterien definiert ihr fünf bis sieben unbequeme, realitätsnahe Szenarien aus eurem Alltag. "Ein B2B-Kunde mit drei Lieferadressen bestellt einen kundenspezifisch konfigurierbaren Artikel mit individuellem Vertragspreis. Ein Teil ist auf Lager, ein Teil kommt im Streckengeschäft direkt vom Lieferanten. Bitte umsetzen." Die Anbieter bauen das in einem Prototyp. Innerhalb von 48 Stunden trennt sich Marketing-Versprechen von technischer Realität.

Zweitens: Endnutzer ins Boot. Die Menschen, die später täglich mit der Software arbeiten, fehlen in klassischen Auswahlprozessen meistens komplett. Lagerverwaltung, Kundenservice, Online-Marketing, Content-Redaktion. Wenn diese Gruppen das System hassen, ist es egal, was die Hochglanzbroschüre verspricht. Holt sie in Demo-Runden, lasst sie unter Aufsicht echte Aufgaben durchklicken und nehmt Reibungspunkte ernst, statt sie wegzuargumentieren.

Drittens: Total Cost of Ownership ehrlich rechnen. Die Lizenzkosten machen oft nur 20 bis 30 Prozent der Drei-Jahres-Kosten aus. Den Rest produzieren Implementierung, Integration, Schulung, Wartung, Anpassungsschulden und Opportunitätskosten verzögerter Releases. Wer im Auswahlprozess nur Lizenzpreise vergleicht, vergleicht die Spitze des Eisbergs.

Häufige Fragen zu RFP und Software-Auswahl im E-Commerce

Brauchen wir überhaupt einen formalen RFP-Prozess?

Nur wenn ihr regulatorisch verpflichtet seid (öffentliche Hand, stark regulierte Branchen) oder ein internes Compliance-Setup habt, das vollständige Auditierbarkeit fordert. Für die meisten mittelständischen und größeren E-Commerce-Organisationen ist ein strukturierter, aber agilerer Discovery-Prozess die bessere Wahl. Weniger verlorene Zeit, bessere Entscheidung.

Wie lange sollte eine Plattformauswahl dauern?

Für einen mittelgroßen B2B- oder B2C-Shop realistisch sechs bis zwölf Wochen von Discovery bis zur Vendor-Entscheidung, wenn fokussiert gearbeitet wird. Klassische RFP-Prozesse ziehen sich auf vier bis neun Monate, ohne dass die Entscheidungsqualität dadurch steigt. Wer länger braucht, hat in der Regel ein Stakeholder-Problem, kein Methodenproblem.

Sollten wir einen externen Berater oder eine Agentur für die Auswahl beauftragen?

Sinnvoll, wenn der Berater nachweislich plattformunabhängig arbeitet und seine Partnerschaften offenlegt. Lasst euch die Provisionsstruktur zeigen. Wer nur eine Plattform "objektiv empfehlen" kann, ist kein Berater, sondern ein verlängerter Arm des Herstellervertriebs.

Welche drei Fragen entscheiden wirklich über die richtige Plattform?

Erstens: Welche unserer Geschäftsprozesse sind wir bereit, an den Standard der Plattform anzupassen? Zweitens: Wie viele Entwickler haben wir intern, und welche Technologien beherrschen sie? Drittens: Welche Roadmap-Themen müssen wir in den nächsten 18 Monaten ausliefern, und welche Plattform unterstützt das am besten? Alles andere ist Detailrauschen.

Lohnt sich der Einsatz von KI im RFP-Prozess?

Begrenzt. KI kann Vendor-Antworten strukturiert vergleichen und Inkonsistenzen markieren. Sie beschleunigt die Marktsichtung und Vorrecherche. Was sie nicht kann: beurteilen, ob die Lösung zu eurer Organisation passt. KI kennt eure politischen Dynamiken nicht, nicht euer IT-Setup, nicht eure Branche im Detail. KI ersetzt kein kritisches Denken. Im besten Fall verstärkt sie es.

Was kostet eine professionelle Plattformauswahl extern begleitet?

Für einen mittelgroßen Shop realistisch 10.000 bis 40.000 Euro, je nach Tiefe der Discovery, Anzahl der zu evaluierenden Plattformen und Umfang der Hands-on-Prototypen. Klassische Beratungen mit großen Strategiehäusern liegen schnell bei 80.000 bis 200.000 Euro, ohne dass die Entscheidungsqualität besser wäre.

Was sind die häufigsten Fehler nach der Plattformwahl?

Drei Klassiker. Erstens das Vernachlässigen von Change-Management und Schulung, weil "die Plattform ja selbsterklärend ist". Zweitens das 1:1-Übernehmen alter Prozesse in die neue Plattform, statt sie bei der Gelegenheit zu vereinfachen. Drittens der Sparzwang bei Tests und Staging-Umgebungen, der sich nach Go-live mit Faktor zehn rächt.

Nächste Schritte

Wenn ihr gerade in einem Auswahlprozess steckt und das Gefühl habt, dass etwas schief läuft, prüft drei Dinge:

1. Spiegelt euer Lastenheft tatsächlich eure heutige Geschäftsstrategie? Oder besteht es aus recycelten Anforderungen vergangener Projekte? Wenn Letzteres: eine Woche Workshop einlegen, neu ausrichten.
2. Sind eure Anforderungen szenariobasiert oder feature-basiert? Wenn feature-basiert: verwandelt die zehn wichtigsten Anforderungen in konkrete Geschäftsszenarien mit Akzeptanzkriterien.
3. Sind eure beratenden Partner transparent über ihre Plattform-Partnerschaften und ökonomischen Anreize? Wenn nicht: nachfragen. Schriftlich.

Falls ihr unsicher seid, ob euer Prozess gerade auf eine fundierte Entscheidung zuläuft oder auf eine teure Bestätigung dessen, was sowieso schon feststand, sprecht uns an. datrycs ist Partner mehrerer Plattformen und berät plattformunabhängig. Manchmal ist die ehrlichste Empfehlung, einen laufenden Prozess sauber zu stoppen und neu aufzusetzen. Das tut kurz weh und ist meistens deutlich günstiger als die Folgekosten einer Fehlentscheidung.