TL;DR

Aspekt Beschreibung
Annahme Zugangsbeschränkungen zu Geschäften sind verpflichtent - lange Schlangen entstehen
Motivation Stupides Schlange-Stehen ist 2020 nicht State-of-the-Art
Challenge Schnell einführbares, skalierbares, einfaches und möglichst niedrigschwelliges Konzept/System zur Reduktion von Warteschlangen vor Geschäften entwerfen und auf Praxistauglichkeit untersuchen
Benefits Geringere Wartezeiten und Reduktion der Ansteckungsgefahr
Lösung Neuentwicklung einer Container-basierte #MobileFirst WebApp mit REST-Backend
Vorteile Markt-Akzeptanz, schlank, keine spezielle Hardware, keine externen Schnittstellen, skalierbar

Motivation

Im Rahmen der aktuellen Situation nehmen wir an, dass Einkaufen in absehbarer Zukunft in Deutschland (ähnlich wie Italien) reglementiert wird, so dass sich nur eine gewisse Anzahl von Personen gleichzeitig im und vor dem Supermarkt befinden darf, um Ansteckungsgefahren zu reduzieren.

Die Herausforderung dabei ist, dass ein reines "Ihr müsst warten, bis ihr dran seid" schlecht skaliert und unglaublich lange Warteschlangen zu erwarten sind - mit sehr großem Frustpotential für die Bevölkerung. Lange Warteschlange sind unserer Meinung nicht state-of-the-Art im Jahre 2020.

Lösungsansatz

Unsere Idee: Eine über Smartphones und PC nutzbare Web-Applikation, die es ermöglicht, ohne Speicherung von sensiblen/persönlichen Daten - Zeitslots im Supermarkt zu reservieren. Neben einem Web-Formular könnte zusätzlich eine Reservierung über einen Telefon-Computer für Ältere Menschen erfolgen. Diesen Service haben wir für das Minimum Viable Product außen vor gelassen.

Wir finden es wichtig, dass diese Lösung parallel zu der "klassischen Warteschlange" umgesetzt wird, so dass jeder auch ohne Reservierung mit ausreichend Warten ebenfalls in den Supermarkt kommt. Dies macht die Integration in die heutige Alltagssituation gut und einfach möglich.

Die "Kundenkapazität eines Supermarkts pro Stunde" müsste beispielsweise über 60% Reservierung und 40% Anstehen und Warten genutzt werden.

Wer einen Slot reserviert zeigt einen QR-Code oder nennt seine Nummer und darf damit zur angegeben Zeit an der Schlange vorbei. Der Code wird von der Person, die den Einlass kontrolliert, z.b. als QR Code abgescannt und somit validiert. Die Reservierung verfällt 15min nach Ablauf des Termins. Freie Slots werden mit der Warteschlange genutzt. Das heißt unsere Nutzer der Anwendung sollten bevorzugt Zutritt zum Geschäft erhalten.

Vorgehensweise während des Hackathons

  • Aufteilung des 10 Personen Teams in Subteams zu den Themen
    • Konzept
    • Analyse
    • Entwicklung und
    • Voice of Customer
  • Gemeinsame Brainstromings und regelmässige Videocalls zur Abstimmung
  • Interviews mit Experten für verschiedene Perspektiven
  • Simulation zur Überprüfung der Effektivität
  • Theoretische Betrachtigung: Skalierbarbeit, Effektivität und Akzeptanz
  • MVP Version 1.0; Ziel: Fertiger Prototyp am Ende
  • Version 2.0 (theoretisch)

Unser Ziel war es, innerhalb der Zeit einen lauffähigen Prototypen zu erstellen, der die Grundfunktionalität abbildet (MVP Version). Weiterführende Aspekte, an der eine reale Umsetzung scheitern könnte, sind wir auf konzeptioneller Ebene angegangen (Experteninterviews, Simulationen, UX Komfortfunktionen). Seitens der Entwicklung des Prototyps wurde sie aber von Anfang an bewusst ausgeklammert.

Großer Vorteil unsere Teamzusammenstellung: Ein divers aufgestelltes Team von Anfang an mit Entwicklern, Analysten, Ideengebern, agilen Projekt Manager und Design und UX Expertise. Besonders hilfreich war, dass wir eine UX Designerin von Anfang an im Team hatten. So konnten wir ihr Wissen von Anfang an in die Gestaltung unseres MVP einfließen lassen.

Abgrenzung zu anderen ähnlichen Beiträgen

Die von uns prototypisch umgesetzte und auf Praxistauglichkeit untersuchte Idee zeichnet sich durch ihre Einfachheit aus:

  • einfach zugängliches Web-Interface für Kunden und Zugangskontrolleure
    • über PC, Tablet und Smartphone nutzbar
    • keine Installation einer App nötig (aber optional vorstellbar)
  • keine spezifische Hardware oder Anbindung komplexer Schnittstellen nötig
  • einfache Skalierung
  • Minimierung der Speicherung von personen-bezogenen Daten

Im Rahmen des Hackathons haben wir uns nicht nur auf die Technik konzentriert, sondern insbesondere die Praxistauglichkeit durch theoretischen Überlegungen, Simulationen sowie Interviews mit Branchenvertretern untersucht.

Design Mockup

Auf Basis der im Team diskutierten Userflows und dem in den Interviews gewonnenen Insights konnten wir aus ersten gescribbelten Skizzen ein umfängliches Design Mockup erstellen, das zu nutzen einlädt.

Vom Scribble

Zum Design

Unser Logo von Geplant Einkaufen!

So könnte die Implementierung in Supermärkten aussehen

Technologie und MVP

geplant-einkaufen.de besteht aus drei wesentlichen Komponenten: das Frontend, das Backend mit API und der Datenbank.

Frontend

Entscheidend für unsere Idee ist es, sovielen Menschen wie möglich Zugang zum Buchungssystem zu ermöglichen. Aus diesem Grund fiel die Wahl auf das Ionic Framework. Dieses erlaubt die Nutzung von Smartphones (Android als auch iOS), aber auch Buchungen per Desktop. Die Oberfläche selbst ist in Angular.Js geschrieben. Sie ist responsiv, passt sich also den Maßen des Browsers an.

Die Verwendung einer Webanwendung ermöglicht den Kunden einen direkten Einstieg und bietet damit eine sehr niedrige Einstiegshürde.

Eine weitere Anforderung ist, dass das System einfach zu benutzen ist. In unserem Prototyp war es deshalb das Ziel, die Oberfläche möglichst intuitiv zu halten:

Backend

Das Backend ist in Python geschrieben und benutzt django um eine REST-API für das Frontend zur Verfügung zu stellen. Die Datenbank wird ebenfalls vom Backend mit Hilfe des Django ORM verwaltet.

Django bietet eine Adminoberfläche, um die Objekte die in der Datenbank gespeichert sind zu verwalten. Dies erlaubt es einem Administrator im laufenden Betrieb die Daten der Anwendung übersichtlich einzusehen und gegebenenfalls Fehler zu korrigieren.

Alle Datenmodelle, mit denen das Backend arbeitet, sind in der Adminansicht registriert.

Das Backend besteht aus zwei Containern: app beinhaltet die Django Applikation und proxy liefert notwendige statische Dateien.

Datenbank

Als Datenbank kommt Postgres 11 zum Einsatz. Da die Datenbank durch das Django ORM verwaltet wird, ist hier keine tiefgreifende Konfiguration nötig. Es muss lediglich ein Nutzer für das Backend und eine Datenbank angelegt werden.

Hosting

Alle Komponenten von geplant-einkaufen.de sind in eigenen Docker Images abgebildet. Dies ermöglicht ein einfaches Hosting, reproduzierbare Entwicklungsumgebungen und Skalierbarkeit.

Skalierung

Das Frontend und Backend haben selber keinen Zustand, sie sind stateless. Aus diesem Grund kann geplant-einkaufen.de leicht skalieren, indem mehrere Instanzen von Front- und Backend via Loadbalancing angeboten werden.

Diese Skalierbarkeit ist nur begrenzt durch die zentrale Datenbank.

Source Code und Build Pipeline

Das Frontend ist Open Source unter MIT Lizenz und kann in Github eingesehen werden.

Der Source Code für das Backend ist Open Source unter GPL Version 3 und kann in Gitlab eingesehen werden.

Das Frontend und das Backend sind öffentlich als Docker Images über folgende Tags abrufbar:

  • registry.gitlab.com/shop_scheduler/shop_scheduler_frontend/ionic
  • registry.gitlab.com/shop_scheduler/shop_sheduler_backend/app
  • registry.gitlab.com/shop_scheduler/shop_sheduler_backend/proxy

Validierung und Zielgruppenanalyse mittels Experteninterviews

Die Zielgruppe der Anwendung definiert sich in drei Hauptgruppen:

  • einkaufende Menschen mit Internetzugang (eine Erweiterung für Personen ohne Internetzugang ist in Planung, war für den Hackathon jedoch Out of Scope)
  • Personen, die den Einlass am EIngang eines Geschäfts regeln, mit ihren Smartphones
  • (Einzel)händler, besonders Interesse zu den Themen Planbarkeit bzgl. zu erwartendem Kundenstrom, Unterstützung der Akzeptanz im Händlernetz sowie bei dederen Endkunden

Um unsere Idee zu Validieren und Feedback vom Markt einzuholen, haben wir Interviews mit unterschiedlichen Branchenexperten durchgeführt. Die meisten Interviewpartner fanden wird dank der Mentorinnen und Mentoren innerhalb des Projekts sowie unseres privaten Netzwerks. Dank der Interviews waren wir in der Lage nicht nur positives Feedback, sondern auch interessante Gedankenanstösse seitens der Interviewpartner zu bekommen. So wurden wir im Interview mit einem Experten aus der Sicherheitsbranche auf zusätzliche Herausforderung in der kritischen Phase der Kontrolle der Codes vor Eintritt in das Geschäft aufmerksam gemacht. Zusammenfassend können wir so sicherstellen, dass die Bedürfnisser dieser verschiedenen Gruppen getroffen werden und am Ende nicht ein tolles Produkt ohne Praxisrelevanz entsteht.

Zusätzlich konnten wir wertvolles Wissen für die Vermarktung der Anwedung generieren. Out of Home Werbung mittels klassischer Plakataufsteller rund um die Geschäfte sowie Plakate und Flyer innerhalb der Geschäfte, an Einkaufswagen und in Kassenbereichen stellen die Ansprache der Zielgruppe sicher. Zusätzlich wäre Werbung mittels Promotionen, beispielweise in Verkaufsprospekten zielführend. Alle Interviewpartner waren sich über die schnelle Verbreitung innerhalb aller Zielgruppen einig, sodass Push- und Pull-Strategien erfolgreich angesetzt werden können.

Betrachtung einer Simulation

Es wurde ein Simulationstool programmiert, welches uns ermöglicht unterschiedliche Zustände und Rahmenbedingungen der Märkte selektiv auszuwerten. Damit konnten wir die Schwellwerte darstellen, wie sich die Online-Buchungen direkt auf die Warteschlangen vor dem Markt auswirken. Dieser Ansatz war uns besonders wichtig um auch ein real nachvollziehbares Ergebnis visuell darstellen zu können.

Anbei ein kleines Video mit Beschreibung und Durchführung einer Simulation:

Video der Simulation

Ziel der Simulation war die Darstellung der Benefits der Online-Reservierung von Zeitfenstern im Vergleich zu reinen Offline-Warteschlangen.

Folgende Rahmenbedingungen können bei der Simulation variiert werden:

  • Expected Person: Durchschnittlich erwartete Anzahl an Personen pro Stunde

  • Shop Restriction: Anzahl an maximal erlaubten Personen im Markt

  • % Online Booking: Wieviel % der „Expected Person´s“ buchen online über geplant-Einkaufen.de

  • AVG Shop duration (min): Durchschnittliche Aufenthaltsdauer pro Person im Markt

Herausforderungen bei der tatsächlichen Einführung

Zur Bewertung der Praxistauglichkeit gehört auch, das "Labor" gedanklich zu verlassen und sich den Herausforderung einer tatsächlichen Einführung zu stellen. Folgende Aspekte wurden untersucht, Ergebnisse werden zusammenfassend dargestellt.

Aspekt Relevanz Bewertung
Akzeptanz in der Bevölkerung No users, no need Das Feedback aus Supermarkt-Kundensicht war durchweg positiv
Akzeptanz in der Security-Branche Zentraler Nutzer des Systems Auch hier haben wir positives Feedback bekommen
Skalierbarkeit Das System muss mit sehr vielen Nutzern umgehen können Als Web-App ohne spezifische Anforderungen an die User beliebig skalierbar
TimeToMarket Wir brauchen eine schnelle Lösung, die Anschaffung spezifischer Harware erscheint uns praxis-fern Als zentraler Ansatz (Web-App) mit sehr wenigen Funktionen blitzschnell ausrollbar
Kosten Teure Lösungen sind schwerer durchsetzbar Durch den Web-App bedingten BringYourOwnDevice Ansatz geringe Kosten
Technik Komplexe Technik lässt sich schwieriger in der Breite ausrollen Unsere Lösung als einfache Web-App minimiert Komplexität und verzichtet auf spezische externe Schnittstellen
Umgang mit personen-bezogenen Daten Der Schutz personen-bezogener Daten hat oberstes Gebot Aus diesem Grund verzichtet unser Ansatz prinziell vollständig auf die Verarbeitung personen-bezogener Daten. Hinweis: Ggf. kann es notwendig sein, die Identität des Buchenden zu erfassen. Siehe Sicherheit im Folgenden.
Sicherheit: Schutz vor Überbuchungen Das System sollte nicht ausgenutzt werden können, um übermäßig viele Parallel-Buchungen zu tätigen. Die Lösung wäre, die Identität des Buchenden zu erfassen: Hier erscheint uns entweder eine Mobilfunk-Nummer oder eine Email-Adresse als geeignet.
Sicherheit: Schutz vor Missbrauch der Code-Validierungsschnittstelle Diebstahl von Reservierungs-Codes Zum Schutz könnte eine Authorisierung beim Schnittstellenaufruf sinnvoll sein

Nächste Schritte und Offene Punkte

  • Selbstregistrierung und Login für die Kunden
  • Adminoberfläche für Einzelhändler
  • Verifizierung von Einzelhändlern
  • Stornierungsmöglichkeiten
  • Telefonische Hotline und Erinnerungsservice mit twillio.com. Somit können auch ältere Menschen ohne Smartphone, als Risikogruppe, erreicht werden.
+ 2 more
Share this project:

Updates