POINT OF view

Navigator fr den OnlineshopTechnologiedschungel

Ein Leitfaden fr die Auswahl der richtigen Onlineshop-Software
Uwe Tben, Director Digital Commerce bei SapientNitro

Die Auswahl einer Technologieplattform fr den Onlineshop ist zu einer echten Herausforderung
geworden: Einerseits haben die Anbieter der fhrenden Lsungen ihre Produkte ber die letzten Jahre
hinweg immer besser ausgestattet, was zu einer gewissen Homogenisierung des Wettbewerbsfeldes
gefhrt hat. Andererseits hat sich auch der E-Commerce weiterentwickelt: immer mehr Onlinehndler
interagieren mit ihren Kunden heute ber die unterschiedlichsten Kanle und mssen diese konsistent
verknpfen aus E-Commerce wird schlicht Commerce. Auch das Thema Customer Experience
gewinnt in Zeiten sich verschrfenden Wettbewerbs eine immer grere Bedeutung. Markentreue
hngt zunehmend vom Begeisterungs- und Zufriedenheits-Faktor ab. Daraus entstehen ganz neue
Anforderungen an das Betriebssystem des Onlineshops, die Shopsoftware.
Aus Multi Channel resultieren beispielsweise komplexe Anforderungen an die Integration mit
Backendsystemen. In der Folge fhlen sich viele Entscheider inzwischen bei der Auswahl einer
Onlineshop-Lsung verloren im unbersichtlichen Dschungel unterschiedlicher Technologien und
Geschftsmodelle.

Abbildung 1: Der klassische Technologieauswahlprozess

Etablierte Ausschreibungsverfahren wie in Abbildung 1 dargestellt helfen da wenig. Vermutlich kennen

Sie das Dilemma: Fr einen Request for Proposal (RFP) mssen Sie Ihre Bedrfnisse vorab genau
kennen und hier wird es schwierig so detailliert wie mglich dokumentieren.
Das weitere Vorgehen erscheint auf den ersten Blick einfach: Sie versenden den RFP an die
vielversprechendsten Anbieter, Ihre Shortlist. Die Anbieter fllen dann das meist umfangreiche
Tabellarium aus und senden es Ihnen zurck. Sie wiederum werten die Antworten systematisch aus,
bereiten die Ergebnisse auf und entscheiden anschlieend, welchem Anbieter Sie Ihren Onlineumsatz
fr die nchsten fnf bis zehn Jahre anvertrauen wollen. Hufig beinhaltet der Prozess ausserdem
einen so genannten Proof of Concept, also eine Live-Demonstration des zu bewertenden Produkts
bzw. der Lsung.
Ziel dieses Schrittes sollte es sein, die Umsetzung besonders kritischer Anforderungen mit dem
jeweiligen Produkt zu veranschaulichen. Oft verkommt dieser Schritt aber zu einer reinen ProduktDemo, deren Wertbeitrag zum Auswahlprozess als grenzwertig zu bezeichnen ist.

Sapient Corporation 2011

POINT OF view
So weit, so gut. Hier sind die Grnde, warum der Entscheidungsprozess so heute nicht mehr
funktioniert:
Technologieanbieter, Systemintegratoren und Agenturen sind auf die Beantwortung von RFPs
konditioniert
Genau so systematisch wie der RFP verfasst wurde wird er auch beantwortet. Oft durch
gewissenhaftes Copy & Paste aus Produktbeschreibungen und Prsentationen. Das wie bzw.
wie gut gert dabei in den Hintergrund. Am Ende mssen viele Entscheider feststellen, dass nach
Aktenlage alle Wettbewerber alle Anforderungen erfllen. Wie gro der Produktanpassungsaufwand
ist, um einzelne, komplexe Anforderungen zu erfllen und wofr ein Produkt besser, wofr es weniger
gut geeignet ist, gert dann aus dem Fokus.
Die ausschliesslich systematische Dokumentation der Anforderungen im RFP fhrt zur
bertreibung
Wenn eine Anforderung nicht im RFP dokumentiert ist, dann wird sie auch nicht erfllt! Wegen
dieser populren Befrchtung werden erst einmal alle nur denkbaren Anforderungen erfasst
und dokumentiert lschen oder de-priorisieren kann man ja spter. Diese oft allzu strikte
Vorgehensweise wird dem tatschlichen Wert vieler Anforderungen nicht gerecht und verstellt den
Blick auf das Wesentliche.
Shopsoftware wird heute in vielen Formfaktoren angeboten
Zu den klassischen Modellen Lizenzkauf und Software-as-a-Service (SaaS) haben sich ganz neue
Modelle und viele Variationen der klassischen Modelle gesellt. Auch wenn eine kommerzielle
Shopsoftware nur durch den Kauf einer Lizenz nutzbar ist, gibt es Dienstleister, die die Lizenz kaufen
und zu einem Service veredeln, den sie dann auf Basis einer monatlichen Servicepauschale anbieten.
Traditionelle Ausschreibungsverfahren reichen nicht aus, um diesen Aspekt mit in die Betrachtung
einzubeziehen, denn die Varianz der kommerziellen Modelle reduziert die Vergleichbarkeit von
Angeboten. Als Folge liegt den meisten Ausschreibungen ein bestimmtes Geschftsmodell als
Arbeitsannahme zugrunde, das nicht in Frage gestellt wird, was die Perspektive unntig einschrnkt.
Zur Auflsung des Dilemmas hat der Marketing- und Technologiedienstleister SapientNitro ein
5-Schritte-Programm entwickelt, das im Entscheidungsprozess auf das Wesentliche fokussiert ist: den
greif- und messbaren Nutzen der zu bewertenden Lsungen fr das Geschft.
Die vorgeschlagene Vorgehensweise basiert auf einer szenarienbasierten Produktevaluierung anstelle
des klassischen RFP-basierten Ansatzes und macht sich die folgenden Kernideen zunutze:
Szenarien-Evaluierung anstelle detaillierter Anforderungen
In einem homogenisierten Wettbewerbsumfeld ist es wichtig, die Entscheidungskriterien an sich
mglichst stark zu fokussieren, um dann jedes Kriterium ausfhrlich bewerten zu knnen.
Unser Tipp 1: Die aus Sicht der Fachseite wichtigsten Anforderungen in einer geringen Zahl von
Szenarien zu dokumentieren und diese dann durch die eingeladenen Anbieter bearbeiten zu lassen.
Gemeinsame Sprache
Technologen, Vertriebler und Marketiers sprechen selten dieselbe Sprache. Im Falle einer
E-Commerce-Produktauswahl mssen diese drei Gruppen aber eng und kollaborativ
2

Sapient Corporation 2011

POINT OF view
zusammenarbeiten, um gemeinsam eine Entscheidung zu treffen.
Unser Tipp 2: Ein geeignetes Kommunikationsvehikel einsetzen, das von allen beteiligten Gruppen
gleichermaen verstanden wird.
Balanced Scorecard
Die Entscheidung fr eine E-Commerce-Plattform hat einen Zeithorizont von fnf bis zehn Jahren
eine konstruktive Zusammenarbeit zwischen Auftraggeber und Auftragnehmer erleichtert dabei vieles.
Und die Kosten von unzhligen Abstimmungsmeetings sind inzwischen ja hinlnglich bekannt.
Unser Tipp 3: Die Evaluierung sollte holistisch erfolgen und auch weiche Faktoren bercksichtigen
wie z. B. die Kompatiblitt der Unternehmenskulturen.

Abbildung 2: Die 5 Schritte des szenarienbasierten Evaluation

Das in Abbildung 2 dargestellte Vorgehen im Detail:

Schritt 1 Projektziele dokumentieren und messbar machen. Die Projektziele knnen berwiegend
vertrieblicher Natur sein (z.B. mehr Umsatz, hhere Konversionsrate) oder berwiegend operativer
Natur (z.B. geringere Betriebskosten) oder aber eine balancierte Mischung. Bereits an dieser Stelle
sollten Sie sich Gedanken darber machen, wie Sie die Plattform nach dem Marktstart betreiben
mchten, denn diese Entscheidung hat erheblichen Einfluss auf das Vertragsmodell: Zhlt der Betrieb
von Webplattformen nicht zu Ihren Kernkompetenzen macht es z.B. Sinn, ber ein Software-as-aService-Modell oder einen Fremdbetrieb in einem Dienstleister-Rechenzentrum nachzudenken.
Schritt 2 Szenarien ableiten. Aus den Projektzielen werden dann maximal fnf Szenarien abgeleitet.
Die Szenarien sollten hinreichend detailliert beschrieben werden, den Anbietern aber ausreichend
Freiraum bei der Bearbeitung einrumen. Wichtig ist, dass die Szenarien holistisch im Sinne der
Geschftsprozesse formuliert werden. Wenn beispielsweise die Optimierung des durchschnittlichen
Warenkorbs ein wichtiges Projektziel ist, dann sollte es ein Cross-Sell-, Up-Sell-Szenario geben.
Dieses Szenario sollte mit der Einstellung der jeweiligen Produkte in den Katalog beginnen und erst
mit der vollstndig durchgefhrten Bestellung enden. Die Szenarien haben somit groe hnlichkeit mit
den in der Softwareentwicklung gebruchlichen Use Cases, sind aber weniger granular und somit
umfassender formuliert.
Schritt 3a Evaluierung der Szenarien. Die ausformulierten Szenarien werden den Anbietern nun
zur Verfgung gestellt- idealerweise zusammen mit den bentigten Produktdaten und den sonstigen
Marken-Assets. Die Anbieter erhalten einen definierten Zeitraum, um die Szenarien auf Basis ihrer
Produkte und Lsungen umzusetzen. Der Zeitraum sollte berschaubar aber nicht zu kurz sein
zwei Wochen haben sich bewhrt. Die Spielregeln mssen den Anbietern vorab bekannt gemacht
werden. Eine wichtige Regel ist, dass Slideware bei der Ergebnisprsentation nicht anerkannt wird,
sondern nur demonstrierte Plattformfunktionalitt. Aus Auftraggebersicht ist es empfehlenswert die
Umsetzung der Szenarien mit eigenen Mitarbeitern zur Evaluierung kultureller Aspekte zu begleiten.

Sapient Corporation 2011

POINT OF view
Nehmen Sie sich abschlieend ausreichend Zeit, um die Anbieter ihre umgesetzten Szenarien
prsentieren zu lassen ein Tag pro Anbieter ist angemessen. Fokussieren Sie bei der
Ergebnisprsentation darauf, zu verstehen, wie die prsentierten Ergebnisse erreicht wurden.
Produktanpassungen (Customization) sind dabei nicht grundstzlich negativ zu bewerten.
Entscheidend ist aber, auf welche Art und in welchem Umfang das jeweilige Produkt angepasst
werden musste, um die prsentierten Ergebnisse zu erzielen.
Whrend der Ergebnisprsentation ergibt sich fast zwangslufig eine lebhafte Diskussion zu den
Lsungsanstzen und ihrer Abbildung auf Produktkomponenten. An dieser Stelle kommt nun
das Kommunikationsvehikel ins Spiel: Es hat sich bewhrt, die Anwendungsdomne vorab in
einem Business Context-Diagramm wie in Abbildung 3 dargestellt zu dokumentieren und als
groformatiges Poster whrend der Ergebnisprsentation zu nutzen.

Abbildung 3: Ein Business Context-Diagramm fr E-Commerce, hervorgehoben der funktionale Bereich Path to Purchase

Dieses Diagramm stellt die bentigte Plattformfunktionalitt in geschachtelten Blcken dar, wird
blicherweise von Technologen und Marketiers gleich interpretiert und eignet sich hervorragend, um
funktionale Blcke auf konkrete Systemkomponenten abzubilden. Diese Abbildung der konzeptionellen
Welt auf die Welt der Bits & Bytes knnen Sie whrend der Ergebnisprsentation interaktiv mit dem
jeweiligen Anbieter mit Hilfe des Diagramm-Posters erarbeiten. Durch den dazu notwendigen Dialog
schlieen Sie Missverstndnisse weitgehend aus.
Unser Tipp 4: Achten Sie auch auf realistische Rahmenbedingungen. Im spteren Betrieb werden Sie
nicht mit Administratorrechten arbeiten, also sollte das whrend der Evaluierung auch nicht passieren.
Schritt 3b Request for Information (RFI). Die Szenarien-Evaluierung wird insbesondere die
kommerziellen Bewertungskriterien offen lassen. Wir empfehlen deshalb, diese Aspekte mit einem
Request for Information (RFI) abzufragen. Der RFI hnelt in vielen Punkten dem RFP, verlangt aber
vom Anbieter nicht die Darstellung einer spezifischen Lsung sondern beschrnkt sich auf generische
Fragen nach Unternehmensumstzen, Produktroadmaps, etc.

Sapient Corporation 2011

POINT OF view

Schritt 4 Balanced Scorecard. Das Evaluierungsteam muss seine Erkenntnisse zeitnah

dokumentieren. Erstellen Sie hierzu vorab z.B. auf Basis der in Abbildung 4 dargestellten Kategorien
einen gewichteten Bewertungsbogen mit einem definierten Wertesystem (bspw. auf einer Skala von
1 bis 5). Direkt im Anschluss an die Anbieterprsentationen in Schritt 3a muss das Team im Konsens
bewerten, wie gut die Anbieter die Szenarien umgesetzt haben. Auch die RFI-Antworten aus Schritt

Abbildung 4: Die vorgeschlagenen Bewertungskategorien im Navigator dargestellt

3b mssen mit Hilfe des Bewertungsbogens ausgewertet werden. Aus den Bewertungsbgen sollte
sich nun eine Rangfolge des Wettbewerbsfeldes kristallisieren lassen.
Schritt 5 Verhandlung. Abschlieend empfehlen wir, das kommerzielle Angebot mit den beiden
bestplatzierten Anbietern zu verhandeln und die finale Entscheidung unter Einbeziehung der
Verhandlungsergebnisse zu treffen.
Der hier vorgestellte Ansatz erfordert vom Evaluierungsteam einiges Umdenken, verspricht aber eine
nachhaltige und belastbare Entscheidung, die mit einem guten Bauchgefhl getroffen wurde.

Uwe Tueben ist ein eCommerce-Veteran: Er startete seine Karriere im

Einzelhandel bei der Tengelmann-Gruppe und und baute dann zu Zeiten
des ersten E-Commerce Booms in den frhen 2000er Jahren eines der
ersten deutschen Sportportale samt Onlineshop mit auf.
Seit 2002 arbeitet er fr SapientNitro, wo er heute als Idea Engineer
das Produkt- und Serviceangebot im Bereich Digital Commerce
mageblich mitgestaltet.

Sapient Corporation 2011