E-Business

Leitfaden für die Auswahl von E-Shop-Systemen

Grundlagen zum Auswahlprozess

Um eine möglichst strukturierte und sachliche Auswahl eines Shop-Systems zu ermöglichen, sollte das Vorgehen einem im Vorhinein festgelegten Ablauf folgen. Dies erlaubt es insbesondere im Nachgang, den Entscheidungsprozess anhand einer Dokumentation der einzelnen Ergebnisse überprüfbar zu halten und diesen bei geänderten Rahmenbedingungen noch einmal zu revidieren.

Im Folgenden sind die relevanten Schritte beschrieben. Je nach Ausgangssituation können sich hierbei Szenarien ergeben, bei denen spätere Schritte ausgelassen oder erst unmittelbar innerhalb der Umsetzung berücksichtigt werden können. Hier sollte mit kritischem Blick der notwendige Aufwand im Verhältnis zur erzielten Verbesserung der Entscheidungsgrundlage betrachtet werden.

Ebenso ist zu entscheiden, inwieweit der Prozess in Eigenregie durchgeführt werden soll, oder eine Unterstützung durch eine externe Agentur erfolgen soll. Dies kann dabei sowohl im Vorfeld eines konkreten Umsetzungsprojektes als auch als eigenständiges Projekt erfolgen. Aufgrund des hohen Abstimmungsbedarfs findet sich häufig eine Mischform beider Varianten, bei der bestimmte Aufgaben ausgelagert werden, während andere in Eigenregie durchgeführt oder zumindest vorbereitet werden können.

1. Anforderungserfassung

Zu Beginn einer jeden Systemauswahl steht die systematische Erfassung der Anforderungen an das neue System. Häufig beginnt dies mit einer vagen Vorstellung des benötigten Shop-Systems . Aufgrund der Vielfalt von Produkten am Markt sollten diese Anforderungen allerdings noch einmal in einzelne Komponenten zerlegt werden. Mit der Sorgfalt bei der Erstellung eines Anforderungskataloges steigt und fällt die gesamte Qualität des Auswahlprozesses. Er stellt das Herzstück einer Systemauswahl dar.

Zur Erfassung bietet sich eine tabellarische Struktur an, in welcher die einzelnen Anforderungskriterien in Verbindung mit einer kurzen Erläuterung dargestellt werden. Zusätzlich sollte jedes Kriterium mit einer Gewichtung versehen werden. Hier hat sich eine Unterteilung in Muss-, Kann- und Soll-Kriterien bewährt.

Bei der Festlegung der Gewichtung ist darauf zu achten, mit einem Muss-Kriterium nur wirklich absolut unabdingbare Funktionalitäten zu markieren, da sich ansonsten häufig kein System finden lässt, das wirklich jedes einzelne Kriterium erfüllt. Häufig lassen sich für Soll-Kriterien auch innovative Alternativen finden, die dann auch mit einem System, welches diese nicht direkt erfüllt, umgesetzt werden können.

In den Prozess der Anforderungsdefinition sollten möglichst alle am geplanten System beteiligten Parteien eingebunden werden, um eine spätere Akzeptanz des gewählten Systems weiter zu unterstützen. Die Erfassung der Anforderungen kann entweder in der Gruppe geschehen oder durch einzelne durchgeführte Interviews. Im letzten Fall werden die Ergebnisse dann in ein einzelnes Dokument überführt und allen Beteiligten zur Abnahme vorgelegt.

Meist bietet es sich während der Anforderungsdefinition an, einen Blick auf vergleichbare Shop-Angebote zu werfen. Gerade zwischen verschiedenen Branchen sind die Erwartungen der Nutzer an die Verfügbarkeit bestimmter Funktionen im Frontend sehr unterschiedlich.

Üblicherweise bilden sich im Zuge der Anforderungsdefinition die folgenden Themenfelder heraus:

1.1 Frontend-Funktionalitäten zur Darstellung des Produktkataloges

Hier werden Themen wie die Navigationsmöglichkeiten, automatische und manuelle Querverlinkung, Such- und Vorschlagsfunktionen und zielgruppenspezifische Ansprache behandelt. Es muss darauf geachtet werden, konkrete Projektanforderungen an ein späteres Umsetzungsprojekt von für die Wahl des Systems relevanten Anforderungen zu trennen.

Die Anpassbarkeit des Systems in Bezug auf das Aussehen der einzelnen Komponenten sollte hier ebenfalls berücksichtigt werden.

Ist eine Darstellung der Warenverfügbarkeit gewünscht, so sollte hier bereits die bevorzugte Datenherkunft für diese Information festgelegt werden. Prinzipiell bieten sich die folgenden Alternativen: Manuelle Pflege im Shop-System, zeitlich gesteuerter Abgleich mit einem Warenwirtschaftssystem oder exakter Abgleich mit dem Warenwirtschaftssystem zum Zeitpunkt des Aufrufs.

Ebenso sind hier konfigurierbare Produkte oder geplante Produktabonnements zu berücksichtigen.

1.2 Interaktive Frontendfunktionen

Dieses Themenfeld behandelt Frontend-Funktionalitäten, welche es dem Besucher erlauben, sein Shop-Erlebnis individuell zu gestalten. Hierzu zählen zum Beispiel Funktionen wie Merkzettel oder Wunschliste, automatisierte Benachrichtigungen, Individualisierung von Produkten.

1.3 Bestellvorgang

Der Bestellvorgang ein wichtiger Bestandteil des Shops und führt bei unzureichender Umsetzung zu einem Verlust eines kaufbereiten Kunden. Besonderes Augenmerk sollte hier auf die eventuell vom System vorgegebene Abfolge der einzelnen Schritte gelegt werden. Ebenso können hier, sofern gewünscht, Up-Selling-Funktionen behandelt werden.

In Abhängigkeit davon, inwieweit die Abwicklung der Bestellung bereits von anderen Systemen unterstützt wird, stellt sich hier die Frage, wie die Bestellung nach Durchführung durch den Besucher weiterverarbeitet wird. Die einfachste Lösung ist die Benachrichtigung eines Sachbearbeiters via E-Mail sowie die Speicherung der Bestellung im Shop-System. Diese Variante kommt häufig bei Einstiegsprojekten zum Einsatz.

Bei vorhandenen Fulfillment-Systemen, müssen diese angebunden werden. Insbesondere falls eine spätere Übersicht über den Bestellstatus im Shop-Frontend gewünscht ist, muss hier ein Rückkanal berücksichtigt werden, über den Statusänderungen an das Shop-System gemeldet werden. Auch die Frage nach dem Versand von Statusmeldungen an den Besucher sollte geklärt werden. Werden diese im Fulfillment-System erzeugt oder direkt im Shop? Sollen Produktabonnements unterstützt werden ist der Prozess der wiederkehrenden Bestellung ebenfalls zu berücksichtigen.

1.4 Zahlungsvorgang

Die eigentliche Zahlungsabwicklung erfolgt üblicherweise außerhalb des Shop-Systems, so dass hier der Schnittstellenthematik eine besondere Bedeutung zukommt. Mit Blick auf die geplanten Zielgruppen sollte eine Auswahl der anzubietenden Zahlungsmöglichkeiten getroffen werden. Dabei sind Themen wie Benutzerkomfort, Sicherheit der Zahlung und Verbreitung des Zahlungsdienstes zu berücksichtigen.

Handelt es sich um einen Shop mit beschränktem Nutzerkreis kommt häufig auch eine Abrechnung über Kostenstellen, o.Ä. zum Einsatz. Hier erfolgt die Anbindung dann weniger zu einem externen Anbieter von Abrechnungssystemen, sondern an die interne Buchhaltung. Auch in diesem Fall kann bei einem Einstiegsprojekt mit geringem Bestellaufkommen durchaus in einem ersten Schritt ein manueller Prozess mit Versand von E-Mails in Betracht gezogen werden.

1.5 Kundenbindung

Zur Kundenbindung oder Unterstützung von Marketingaktionen werden häufig Gutscheinsysteme eingesetzt. Sofern gefordert, ist auf eine entsprechende Unterstützung im Shop-System zu achten. Dabei müssen sowohl das Thema Gutscheingenerierung als auch Gutschrift und Validierung behandelt werden. Findet die Generierung in einem externen System statt, so ist eine Schnittstelle zur Validierung vorzusehen.

1.6 Marketingunterstützung

Wenn der geplante Shop für Marketingaktivitäten wie Newsletter, Banner oder Kampagnen auf der Website eingebunden werden soll, sollte die Möglichkeit bestehen, innerhalb des Shops Affiliate-Parameter weiterzuleiten und eventuell gefilterte Listen registrierter Nutzer für den Newsletter zu exportieren.

1.7 Pflegemöglichkeiten im Backend

Hier empfiehlt sich die Definition der Anforderungen zur Bearbeitung des Produktkatalogs. Ebenso ist die Bearbeitung von E-Mail- und sonstigen Vorlagen sowie Bestätigungsmeldungen meist wünschenswert. Dadurch entfällt eine Entwicklungsleistung, um beispielsweise Ansprechpartner zu ändern.

Ist keine Anbindung an ein Warenwirtschaftssystem geplant oder soll eine umfangreiche Produktveredelung innerhalb des Shop-Backends stattfinden, sollte ein Massen-Upload für Mediadaten vorgesehen werden. Auch die Überprüfung eines Rechte- und Rollensystems ist, je nach Projektanforderungen, sinnvoll.

1.8 Sprach- und Währungsunterstützung

Sowohl bei der Bedienung des Backends, als auch bei der Darstellung des Frontends ist das Thema Mehrsprachigkeit zu berücksichtigen. Gerade im Backend finden sich im Open-Source Bereich immer noch rein englischsprachige Interfaces (was nicht immer ein Hinderungsgrund sein muss, aber entsprechend berücksichtigt werden sollte). Im Frontend stellt sich die Frage, inwieweit das System es erlaubt, mehrere Sprachversionen eines Produktes zu pflegen und wie sich diese in Bezug auf ihre Attribute unterscheiden können. Ebenso zieht sich das Thema Mehrsprachigkeit natürlich durch die Bereiche E-Mail-Versand und Nachrichtenausgabe im System.

Soll der Shop in mehreren Ländern verfügbar sein, ist die Unterstützung mehrerer Währungen in einem System ein zu behandelndes Kriterium.

1.9 Statistik

Der Bereich Statistik sollte immer ausgehend der von verschiedenen Stakeholdern benötigten Zahlen geplant werden. Aus diesen lassen sich häufig Auswertungen definieren, die dann entweder vom Shop-System selbst oder durch Verwendung einer externen Tracking-Software erstellt werden müssen.

1.10 Technische Basis

Häufig besteht aufgrund vorhandener Systeme bereits eine Präferenz für eine bestimmte technische Basis. Sei es, um beispielsweise bereits vorhandene Lizenzen möglichst gut nutzen zu können oder um auf bestehende Kompetenzen zurückzugreifen. Meist bietet es sich hier an, zwar eine Präferenz auszusprechen, allerdings noch keine konkrete Festlegung vorzunehmen.

1.11 Schnittstellen

Wie sich bereits auf den vorhergehenden Punkten ergibt, erhält das Thema Schnittstellen bei Shop-Systemen normalerweise einen recht hohen Stellenwert. Dies liegt insbesondere daran, dass mit einer Vielzahl spezialisierter Systeme zur Abwicklung der verschiedenen Aufgaben kommuniziert wird.

Nur selten wird ein System gefunden, das die Schnittstellen an die diversen Systeme bereits für alle notwendigen Anbindungen mitbringt. Vielmehr sollte hier, neben der konkreten Unterstützung des anzubindenden Systems (inkl. Versionsnummer) auch die Flexibilität einer generischen Schnittstelle und die Verwendung offener Standards aufgenommen werden.

Alternativ zu einer meist aufwändigen Schnittstellenentwicklung kann häufig, besonders bei Einstiegsprojekten mit geringem Transaktionsvolumen, in einem ersten Schritt eine manuelle Lösung gewählt werden. In diesem Fall ist eine Überprüfung ratsam, inwieweit die dafür notwendigen Reports und Eingaben über das Backend des Shop-Systems abgebildet werden können.

1.12 Anbieterkriterien

Neben den rein funktionalen Kriterien sollten auch die Themen Verbreitung (und damit Zukunftssicherheit) des Systems, vorhandene Neu-Referenzen im letzten Jahr und geplante Roadmap sowie Lizenzkosten und verfügbarer Support berücksichtigt werden.

Gerade beim Thema Support bietet es sich an, verschiedenen Lizenz- und Support-Szenarien zu erstellen, die sich im Bezug auf Nutzerzahlen und Reaktionszeiten unterscheiden.

2. Systembewertung

Ist der Anforderungskatalog einmal erstellt, sollte dieser für die in Frage kommenden Systeme ausgewertet werden. Dabei wird die Zahl der betrachteten Systeme zuerst anhand prominenter Muss-Kriterien reduziert, um eine überschaubare Anzahl von Systemen zu erhalten. Für diese wird der Aufwand einer vollständigen Beantwortung des Anforderungskatalogs durchgeführt.

Die Beantwortung kann dabei zum einen durch Versand des Anforderungskatalogs an die Anbieter mit der Bitte um Beantwortung erfolgen. Hierzu ist meist ein ausreichend konkretes und großes Umsetzungsprojekt notwendig. Wird dieser Weg gewählt, so sollte neben einer reinen Ja/Nein Beantwortung immer auch eine kurze Erläuterung gefordert werden, um bewerten zu können, auf welche Art und in welchem Detailgrad die Anforderung erfüllt wird.

Als Alternative, und gerade bei einer Betrachtung von Open-Source-Systemen bleibt die eigenständige Beantwortung der Fragen durch Analyse vorhandener Dokumentation oder Installation einer Demoversion. Hier kann auch häufig auf die Unterstützung einer Agentur zurückgegriffen werden.

Im Falle von Open-Source-Software stehen auch die diversen Community-Plattformen wie Mailinglisten oder Foren zur Verfügung Hier ist allerdings zu beachten, dass eine Anfrage einer ganzen Liste von Kriterien ohne konkreten Bezug zum Produkt der Community selten zum Erfolg führt. Vielmehr helfen konkrete Fragen zu einzelnen Punkte, die sich aus vorhandener Dokumentation oder Beschäftigung mit einer Test-Installation nicht beantworten ließen. In diesem Falle wird zumeist eine schnelle und detaillierte Beantwortung der Frage erfolgen.

Liegt eine Beantwortung des Kriterienkatalogs für die einzelnen Systeme vor, können diese ausgewertet werden. Besonderes Augenmerk kommt dabei den Muss-Kriterien zu, mittels derer die Kandidatenliste auf einfache Weise weiter eingeschränkt werden kann. Zeigt sich hier, dass der Kreis möglicher Systeme zu weit eingeschränkt wird, muss eventuell eine erneute Abstimmungsrunde erfolgen, um Alternativen zur gewünschten Funktionalität aufdecken zu können.

Soll- und Kann-Kriterien werden anschließend meist in einer nach Funktionsgruppen getrennten Auswertung gewichtet und je System aggregiert. Die sich daraus ergebenden Muster zeigen meist auf recht anschauliche Weise die Schwerpunkte der einzelnen Systeme auf, und dienen als Grundlage für die Erstellung der Shortlist und Systemsteckbriefe des nächsten Schritts.

3. Shortlist und Systemsteckbriefe

Basierend auf den Auswertungen der Anforderungskataloge ergibt sich eine Shortlist mit den in die engere Betrachtung kommenden Systemen. Zu jedem dieser Systeme sollte nun ein kurzer Steckbrief erstellt werden, der die Stärken und Schwächen des Systems in Bezug auf die Anforderungen aufzeigt. Ebenso findet hier eine Aufführung der Anbieterkriterien wie Referenzlage, Zukunftssicherheit, Lizenz- und Supportkosten Platz.

Diese Steckbriefe dienen dann als Grundlage für die Auswahl eines konkreten Systems. Stellt sich hier eine klare Konkurrenzsituation zwischen zwei Systemen heraus, so kann die nachfolgende Teststellung auch mit zwei Systemen durchgeführt werden, allerdings ist auch hier wieder der notwendige Aufwand im Verhältnis zur Qualitätsverbesserung bei der Entscheidung zu betrachten.

Die getroffene Auswahl sollte immer an alle Stakeholder kommuniziert und insbesondere begründet werden, da die dadurch geschaffene Transparenz des Prozesses für eine bessere Akzeptanz des Systems im Zuge der Einführung sorgt.

4. Teststellung

Der Schritt Teststellung bietet mit die größte Spanne an Detaillierungsgraden. So kann sie auf der einen Seite bereits als Teil des folgenden Umsetzungsprojektes betrachtet werden und somit kaum zusätzlichen Aufwand bedeuten. In einem anderen Extrem findet die Teststellung unabhängig von einem nachfolgenden Projekt statt und erfordert einen erheblichen Zusatzaufwand bei der Umsetzung.

Ebenso sollte der Umfang der in einer Teststellung betrachteten Funktionen mit Bedacht gewählt werden. Relevant sind hier insbesondere diejenigen Kriterien, welche in der Anforderungskatalogauswertung noch Zweifel aufwarfen, oder für den Erfolg des Systems kritische Schnittstellen.

Ist die Konzeption des folgenden Umsetzungsprojektes schon ausreichend fortgeschritten, sollte auf jeden Fall die Frage nach der späteren Wiederverwendbarkeit der im Zuge einer Teststellung geleisteten Arbeiten gestellt werden.

5. Projektbeginn

Je nach Gestaltung der Teststellung findet der Projektbeginn des eigentlichen Umsetzungsprojektes entweder im Anschluss oder direkt zu Beginn der Teststellung statt. Handelt es sich bei dem gewünschten System um ein kommerzielles System, so müssen spätestens zu diesem Zeitpunkt die Vertragsverhandlungen und der Bezug der Lizenzen abgeschlossen werden.

Ebenso sollte eine Fein-Konzeption des konkreten Shop-Projektes erfolgen. Diese wird noch einmal mit dem ursprünglich erstellten Anforderungskatalog verglichen, um eventuell noch separat zu implementierende Funktionalitäten zu bestimmen und bei der Umsetzung zu beachten. Ebenso ist festzulegen, welche im Anforderungskatalog definierten Funktionen in der ersten Umsetzungsphase integriert werden sollen, und welche zwar aus Gründen der Zukunftssicherheit vom Shop-System bereitgestellt werden sollen, aber erst zu einem späteren Zeitpunkt in den konkreten Online-Shop integriert werden.


Jan Eickmann

Über den Autor Jan Eickmann

Jan Eickmann ist Diplom Wirtschafts-informatiker und als Leiter der Kundenberatung bei der kernpunkt GmbH für die Entwicklung von Konzepten und Software-Architekturen in den Bereichen CMS, Portale, Online-Anwendungen und E-Commerce zuständig.

0Kommentare

Es wurde bisher noch kein Kommentar verfasst. Starten Sie die Diskussion!