Self-Service-Projekte scheitern selten daran, dass die eingesetzte Technik grundsätzlich nicht funktioniert. Scanner lesen Barcodes, Terminals verarbeiten Transaktionen, Zahlungssysteme autorisieren Zahlungen und Software steuert die einzelnen Prozessschritte.
Trotzdem erreichen viele Projekte im Alltag nicht das Ergebnis, das ursprünglich erwartet wurde.
Die Ursache liegt häufig früher im Projekt: Entscheidungen wurden getroffen, bevor klar war, wie das gesamte System funktionieren soll. Welche Technologie soll eingesetzt werden? Wie viele Geräte werden benötigt? Welcher Anbieter kommt infrage?
Das sind wichtige Fragen. Aber sie kommen zu früh.
Denn bei Self-Checkout, Self-Scanning oder anderen Self-Service-Terminals (SST) geht es nicht um ein einzelnes Gerät. Es geht auch nicht nur um Software oder IT-Infrastruktur.
Self-Service ist ein System – keine Einzellösung.
Self-Service neu denken: Die Technik ist nur ein Teil des Systems
Ein Self-Service-System verbindet unterschiedliche Anforderungen miteinander. Kunden müssen verstehen, was sie tun sollen. Geräte benötigen Fläche, Strom und Datenanbindung. Waren- und Kundenströme müssen funktionieren. Mitarbeitende müssen Prozesse betreuen und bei Bedarf eingreifen können. Gleichzeitig müssen wirtschaftliche Ziele erreicht und Risiken kontrolliert werden. Auch aktuelle Untersuchungen des EHI zeigen, dass sich der Checkout zunehmend von einzelnen Terminals hin zu vernetzten Plattformen entwickelt (siehe EHI: Checkout im Umbruch).
Eine Entscheidung an einer Stelle verändert deshalb fast immer auch andere Bereiche.
Wird beispielsweise die Anzahl der Self-Checkout-Terminals erhöht, betrifft das nicht nur die Investitionssumme. Die verfügbare Fläche verändert sich. Laufwege und Kundenführung müssen angepasst werden. Möglicherweise ändern sich Anforderungen an die Betreuung. Netzwerk und Stromversorgung müssen ausreichend dimensioniert sein. Und auch das Sicherheits- und Kontrollkonzept muss zur neuen Situation passen.
Wer nur das Gerät betrachtet, sieht deshalb lediglich einen kleinen Ausschnitt des eigentlichen Projekts. Welche Self-Service-Lösung für welchen Markt geeignet ist, hängt deshalb nicht allein von der Technologie ab (siehe auch Retail Engineering: Welche Self-Service-Lösung für welchen Markt?).
Self-Service neu denken heißt Zusammenhänge verstehen
Genau hier entsteht in vielen Projekten ein grundlegendes Problem: Einzelne Entscheidungen sind für sich betrachtet durchaus nachvollziehbar, ergeben zusammen aber noch kein funktionierendes Gesamtsystem.
Das kann sich später sehr unterschiedlich bemerkbar machen. Prozesse werden unnötig kompliziert. Kunden verstehen einzelne Schritte nicht. Mitarbeitende müssen häufiger eingreifen als erwartet. Flächen funktionieren im Tagesgeschäft anders als auf dem Plan. Daten werden zwar erzeugt, aber nicht konsequent genutzt. Sicherheitsmaßnahmen werden nachträglich ergänzt, anstatt von Beginn an Bestandteil des Systems zu sein.
Das Ergebnis ist häufig ein technisch funktionierendes, aber operativ nicht ausreichend abgestimmtes Self-Service-Konzept.
Der entscheidende Perspektivwechsel lautet deshalb:
Nicht zuerst nach der Lösung fragen. Zuerst die Zusammenhänge verstehen.
Der Multi-Level-Approach: fünf Ebenen, eine Logik
Der Multi-Level-Approach (MLA) strukturiert Projekte rund um Self-Service-Terminals in fünf miteinander verbundenen Ebenen:
- Level 1 – Entscheidung: Ziele, Business Case und grundlegende Investitionsentscheidung
- Level 2 – Struktur: Fläche, Dimensionierung, Platzierung, Kundenführung und Betreuung
- Level 3 – Vernetzung: Infrastruktur, Daten und Analyse
- Level 4 – Nutzung: Bedienbarkeit, Kundenerlebnis und Zugänglichkeit
- Level 5 – Risikosteuerung: Fraud Detection, Loss Prevention und Risikomanagement
Diese fünf Ebenen sind keine Checkliste, die nacheinander abgearbeitet wird.
Sie bilden eine gemeinsame Projektlogik.
Denn Entscheidungen auf einer Ebene wirken sich auf die anderen Ebenen aus. Ein Layout beeinflusst die Bedienbarkeit und die Betreuung. Die Bedienung beeinflusst Prozesszeiten und Eingriffe. Diese wiederum liefern Daten, die für die Bewertung des Systems relevant sind. Sicherheitsmaßnahmen können Kundenführung und Nutzung verändern. Und all das wirkt am Ende auf den Business Case zurück.
Genau deshalb müssen die Ebenen gemeinsam gedacht werden.
SCO-Zonen sind kein IT-Projekt
Self-Checkout wird häufig stark aus technischer Perspektive betrachtet. Das ist nachvollziehbar, weil Hardware, Software, Schnittstellen und Netzwerkinfrastruktur sichtbar und messbar sind.
Für den Projekterfolg reicht diese Perspektive jedoch nicht aus.
Eine SCO-Zone verbindet Investition, Ladenlayout, operative Prozesse, Kundenverhalten, Personal, Technik, Daten und Loss Prevention. Entsprechend viele Funktionen sind an Entscheidungen beteiligt.
Damit wird Self-Service zu einer unternehmerischen Aufgabe.
SCO-Zonen sind kein IT-Projekt. Sie sind Chefsache.
Nicht, weil jede Detailentscheidung auf Managementebene getroffen werden sollte. Sondern weil Ziele, Verantwortlichkeiten und Prioritäten über mehrere Unternehmensbereiche hinweg abgestimmt werden müssen.
Hohe Investitionen, langfristige Auswirkungen auf den Betrieb und klare Ergebnisverantwortung verlangen eine übergreifende Sicht.
Der Erfolg entsteht vor dem Roll-out
Ob ein Self-Service-System im täglichen Betrieb funktioniert, entscheidet sich nicht erst nach der Installation.
Viele Voraussetzungen werden wesentlich früher geschaffen: bei der Zieldefinition, der Analyse der Ausgangslage, der Festlegung des Projektumfangs und bei der Frage, welche Zusammenhänge bereits in der Planung berücksichtigt werden.
Je später strukturelle Schwächen erkannt werden, desto schwieriger und teurer werden Korrekturen.
Deshalb steht am Anfang eines MLA-Projekts nicht die Frage:
Welche Technologie wollen wir einsetzen?
Sondern:
Was wollen wir erreichen – und welche Struktur benötigen wir dafür?
Daraus ergibt sich der zentrale Grundsatz des Multi-Level-Approachs:
Struktur vor Investition.
Die folgenden Beiträge dieser Reihe zeigen, wie sich diese Logik Schritt für Schritt auf ein Self-Service-Projekt übertragen lässt – von den ersten Zielen und dem Business Case über Struktur, Daten und Nutzung bis hin zu Risikomanagement und durchgängiger Projektverantwortung.
