Typische Fehler bei der Shop-Auswahl und wie man sie vermeidet
Kurz gesagt
Fehler in der Shop-Auswahl lassen sich fünf Stationen zuordnen: Anforderungen, Bewertung, Test, Vertrag und Abnahme. Unsere redaktionelle Auswahl nennt dazu neun Punkte mit Symptom, Ursache und Gegenmaßnahme, von Anforderungen erst nach der Demo bis zum ungeklärten Ausstieg; prüfen Sie jeden Punkt mit einer Probe statt mit einer Zusage. Die Liste gilt in Deutschland, Österreich und der Schweiz gleich; Pflichten Ihres Landes stehen in den Rechtsartikeln.
Das Wichtigste
- Eine Anforderungsliste mit Muss, Soll und Kann gehört vor die erste Demo.
- Klären Sie je Position im Angebot, was der Monatspreis enthält und was getrennt berechnet wird: Einrichtung, Erweiterungen, Zahlungsgebühren, Betrieb und Ausstieg.
- Ein Datenexport lässt sich vor der Unterschrift prüfen: Artikel, Kundenkonten und Bestellungen ausleiten.
- Der BSI-Baustein CON.3 nennt regelmäßige Tests der Datensicherung als Basis-Anforderung; er ist ein Standard, kein Gesetz.
- Für Cloud-Dienste nennt der BSI-Grundschutz die geordnete Beendigung als Standard-Anforderung (OPS.2.2.A14).
- Die WCAG 2.2 des W3C sind eine Empfehlung, kein Gesetz (Fassung vom 12. Dezember 2024).
Ein Shopsystem auszuwählen heißt, Entscheidungen über Anforderungen, Vertrag und Betrieb zu treffen. Die Folgen zeigen sich nicht am Auswahltag, sondern später in der Werkstatt: eine Funktion, die im Alltag fehlt, ein Export, der Handarbeit kostet, ein Vertrag, der den Wechsel bremst.
Woran Fehler in der Auswahl entstehen
Fünf Stationen bestimmen das Ergebnis: Anforderungen, Bewertung, Test, Vertrag und Abnahme. Ein Fehler an einer früheren Station wirkt nicht zwangsläufig länger als einer an einer späteren: Eine unklare Anforderung lässt sich noch im Test nachrüsten, sofern der Anbieter sie anbietet; ein ungeprüfter Datenexport und eine lange Laufzeit wirken dagegen bis zum Ausstieg.
Deshalb gehört jede Station auf dieselbe Prüfliste: Was erwarten Sie (Anforderung), wie bewerten Sie die Antworten (Bewertung), was haben Sie mit eigenen Daten gesehen (Test), was steht schriftlich (Vertrag), und was haben Sie am Ende geprüft (Abnahme)? Die Kriterien für den Vergleich selbst stehen im Artikel Shopsystem auswählen: Kriterien und Vorgehen.
Die folgende Liste ist unsere Auswahl aus Prüflisten und Projektabnahmen. Sie ist keine Erhebung, nennt keine Häufigkeiten und sagt nichts über einzelne Anbieter aus; die Reihenfolge folgt den Stationen, nicht ihrer Verbreitung.
Fehler mit Symptom, Ursache und Gegenmaßnahme
| Fehler | Symptom | Ursache | Gegenmaßnahme |
|---|---|---|---|
| Anforderungen erst nach der Demo festgelegt | Im Test überzeugt die Oberfläche; nach dem Start fehlt eine Funktion im Tagesgeschäft | Verglichen wird über Funktionslisten der Anbieter statt über Ihre Abläufe | Vor der ersten Demo eine Liste mit Muss-, Soll- und Kann-Zeilen aufstellen und je Zeile ein Akzeptanzkriterium festlegen (Anforderungsliste erstellen) |
| Nur der Monatspreis verglichen | Das Budget wird im laufenden Betrieb überschritten | Der Vergleich stützt sich auf den Monatspreis, ohne je Position zu klären, was dieser enthält und was getrennt berechnet wird | Kostenblatt über die geplante Laufzeit, getrennt nach einmalig und laufend (Gesamtkosten berechnen) |
| Test mit Demo-Daten | Grenzen bei Varianten, Steuersätzen und Versandregeln zeigen sich erst nach dem Start | Das Testkonto ist mit vorbereiteten Beispielen gefüllt, nicht mit Ihren Fällen | Testzugang mit 20 eigenen Artikeln und den drei schwierigsten Regeln, Testfälle vorher aufschreiben (Pilotbetrieb) |
| Datenexport nie ausgeführt | Der spätere Wechsel kostet Wochen Handarbeit oder ist nicht möglich | Der Export ist im Vertrag nicht beschrieben und wurde vorher nie geprüft | Probeexport vor der Unterschrift; Format, Umfang, Frist und Kosten festhalten (Anbieterbindung und Datenexport) |
| Schnittstellen nur auf dem Papier | Buchungen werden doppelt erfasst, Bestände laufen auseinander | Getestet wurde das Frontend, nicht der Datenaustausch mit Warenwirtschaft und Versand | Je Schnittstelle Richtung, Takt, Fehlerfall und Zuständigkeit klären und mit echten Buchungen testen (Schnittstellen prüfen) |
| Abnahme ohne Wiederherstellungstest | Eine Sicherung ist vorhanden, das Rückspielen dauert Tage oder scheitert | Für den Test gab es keinen Termin und keine Zuständigkeit | Das Rückspielen üben und protokollieren lassen; der BSI-Baustein CON.3 nennt dafür Basis-Anforderungen, vor allem einwandfreies Rückspielen in angemessener Zeit (CON.3.A15) |
| Barrierefreiheit erst nach dem Start | Das fertige Template wird nachgebessert, der Aufwand war nicht eingeplant | Das Kriterium fehlt in der Anforderungsliste | Eine Konformitätsstufe als Kriterium aufnehmen und im Testshop prüfen (Barrierefreiheit als Auswahlkriterium) |
| Ausstieg nicht geregelt | Die Kündigung stockt, weil Frist und Datenübernahme unklar sind | Gelesen wurde nur der Preis, nicht der Vertrag | Laufzeit, Kündigungsfrist, Datenübernahme und Verantwortlichkeiten schriftlich regeln; für Cloud-Dienste sieht der BSI-Grundschutz eine Regelung zur geordneten Beendigung vor (OPS.2.2.A14) |
| Niemand ist nach dem Start zuständig | Sicherheitsupdates und Änderungen bleiben liegen, Fragen erreichen nur eine Person | Die Übergabe fehlt, das Wissen steckt bei einer Agentur oder einer Person im Team | Übergabe mit Zugängen, Aufgaben, Zeitfenstern und Vertretung; ein Name je Aufgabe |
Drei Zeilen der Liste stützen sich auf Standards statt auf Erfahrung. Das IT-Grundschutz-Kompendium des BSI beschreibt in Baustein CON.3 eine Basis-Anforderung: Datensicherungen sind regelmäßig zu testen, vor allem daraufhin, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können (CON.3.A15, Edition 2023). Im Baustein OPS.2.2 ist die geordnete Beendigung eines Cloud-Nutzungs-Verhältnisses eine Standard-Anforderung; die Verträge sollen regeln, wie das Verhältnis aufgelöst werden kann (OPS.2.2.A14), und bei erhöhtem Schutzbedarf gehört die Portabilität samt Tests dazu (OPS.2.2.A15). Das Kompendium ist ein Standard des BSI und kein Gesetz; verpflichtend wird es, wenn Recht oder Vertrag darauf verweisen.
Für Barrierefreiheit gilt: Die Web Content Accessibility Guidelines in der Fassung 2.2 sind eine Empfehlung des W3C vom 12. Dezember 2024 und ebenfalls ein Standard, kein Gesetz. Die Empfehlung kennt drei Konformitätsstufen; für Stufe AA müssen alle Kriterien der Stufen A und AA erfüllt sein (Abschnitt 5.2.1). Ob und für wen Barrierefreiheit verpflichtend ist, hängt vom Land, von der Kundschaft und von der Größe des Betriebs ab.
Ein Rechenbeispiel: fehlende Schnittstelle
Die folgende Beispielrechnung nutzt erfundene Werte. Sie zeigt, was eine ungetestete Schnittstelle zwischen Shop und Warenwirtschaft im Betrieb kostet, wenn jede Bestellung von Hand nachgetragen wird.
| Größe | Annahme |
|---|---|
| Bestellungen je Monat | 2.000 |
| Handarbeit je Bestellung | 4 Minuten |
| Aufwand je Monat | 2.000 × 4 = 8.000 Minuten, also 133,3 Stunden |
| Aufwand bei angenommenem Stundensatz von 40 Euro | 133,3 × 40 = 5.333 Euro je Monat |
Rechnung: 2.000 Bestellungen mit je 4 Minuten ergeben 8.000 Minuten oder 133,3 Stunden im Monat. Bei einem angenommenen Stundensatz von 40 Euro sind das 5.333 Euro im Monat. Bestellzahl, Minuten und Stundensatz sind Annahmen, keine Messwerte und keine Preise. Die Rechnung erklärt, warum der Datenaustausch ein Muss-Kriterium ist und im Test mit echten Buchungen geprüft wird, statt in der Funktionsliste zu bleiben.
So gehen Sie vor
- Beschreiben Sie Ihren Shop vor dem ersten Gespräch: Artikel und Varianten, Bestellungen je Tag, Länder, Sprachen, vorhandene Programme.
- Schreiben Sie Anforderungen mit Muss, Soll und Kann und je Zeile ein Akzeptanzkriterium, bevor Sie eine Demo ansehen; die nötigen Rechtstexte und Angaben sammelt Rechtstexte beim Shopstart.
- Legen Sie für jede Zeile die Prüfmethode fest (Test, Vertragstext, Probeexport) und schicken Sie allen Anbietern dieselben Fragen schriftlich (Vergleich selbst durchführen).
- Testen Sie die zwei besten Systeme mit eigenen Daten und führen Sie den Export in der Testphase aus.
- Regeln Sie vor der Unterschrift Laufzeit, Kündigung, Verfügbarkeit, Support-Zeiten, Datenübernahme und Ausstieg (Support bewerten).
- Nehmen Sie mit einem Wiederherstellungstest ab und halten Sie die Entscheidung mit Datum, Gründen und offenen Punkten fest. Dieses Protokoll ist später die Grundlage, wenn Sie prüfen, ob ein Wechsel ansteht (Anzeichen für einen Wechsel).