OrderSprinter ist ein relativ junges Projekt und die Anzahl der Betriebe, die meine Software produktiv einsetzen, ist (noch) überschaubar. Daher bin ich besonders an Feedback von Power-Usern interessiert, die OrderSprinter nutzen, auch wenn regelmäßig die Hütte brennt. Das Alpendörfchen auf dem Wolfsburger Weihnachtsmarkt ist ein solcher Fall: Seit einigen Wochen im Dauerbetrieb wird der komplette gastronomische Ablauf auf mehreren Etagen, einem Innen- und einem Außenbereich, mit geschätzt jeweils 20 Tischen, mit OrderSprinter erledigt. Etwa 4 Kellner sind parallel im Einsatz, zu Spitzenzeiten auch mehr.

Am 12. Dezember 2015 bin ich nach Wolfsburg gefahren, um OrderSprinter life und in Farbe bei der Arbeit zu beobachten und Feedback von den Kellnern einzuholen. An dieser Stelle erst einmal ein ganz tolles Dankeschön an das sympathische Team, das sich sehr viel Zeit für mich genommen haben, obwohl ich den laufenden Betrieb durch meine vielen Fragen sicherlich nicht unterstützt habe...

(Außenansicht der Almhütte vom Alpendörfchen)

Das Set-Up im Alpendörfchen sieht so aus: Es ist ein nicht-digitaler Workflow konfiguriert, d.h. statt Nutzung der digitalen Workflow-Ansichten Küche, Bar und Bereitstellung werden Arbeitsbons gedruckt - und zwar mit dem Windows-Printserver. Die Basisinstallation besteht aus zwei OrderSprinter-Serverinstanzen, die sich den gleichen Apache und die Datenbanken einer xampp-Umgebung teilten. Grund für zwei Serverinstanzen: es ist noch nicht möglich, Räumen oder Tischbereichen unterschiedliche Arbeitsbondrucker zuzuweisen (das geht nur für Speisen/Getränke), die die räumliche Trennung der Gastronomiebereiche eigentlich erfordern.

Die Kellner nehmen die Bestellung mit einem 60-Euro-Billig-Smartphone direkt am Tisch auf. Am Tresen wird die Bestellung zubereitet und vom Kellner später abgeholt und zum Tisch gebracht.

Die Kellner waren mit dem System grundsätzlich zufrieden, hatten aber auch handfeste Kritikpunkte. Ich bin in der glücklichen Position, dass ich das Feedback ehrlich und nicht geschönt veröffentlichen kann, da ich bekanntermaßen OrderSprinter nicht vermarkte. Die negativen Erfahrungen interessierten mich am meisten, damit ich diese Punkte aufgreifen und durch eine verbesserte Implementierung in neuen Versionen beheben kann. Zudem kann ich potenziellen Anwendern erzählen, welche Probleme sie möglicherweise erwartet (ich möchte ja keine unzufriedenen Anwender haben):

Am Besuchstag war die Version 1.0.42 installiert.

Die ersten Anmerkungen sind Punkte, die ich am kritischsten einschätze und die ich dringend verbessern möchte:

• Kellner müssen sich häufig wieder einloggen. Meine Anmerkung: Die Bestellansicht besteht aus mehreren Unterseiten. War eine Unterseite der Bestellansicht aktiv, während das Smartphone in den Sleep-Modus gewechselt hat, so wird beim Aufwachen die Unterseite durch das Android-Betriebssystem wieder geladen. Ein Ladevorgang beginnend mit einer Unterseite ist jedoch nicht vorgesehen, so dass OrderSprinter einen Auslogvorgang vornimmt. Dieses Vorgehen ist suboptimal und führt natürlich zu Frust, wenn's mal hektisch wird und der Kellner dann die Einlogseite sieht. Ein möglicher Workaround: Das Smartphone so einstellen, dass es selten in den Sleep-Modus wechselt.
   Anmerkung 21.12.2015: Mit der Version 1.0.43 ist der Workaround nicht mehr nötig. Der Benutzer wird in der Bestellansicht nicht mehr ausgeloggt, wenn er eine Unterseite aktualisiert.
  
  
• Vor einem Tag wurden beide Instanzen auf die neue Version 1.0.42 upgedatet. Der Updatevorgang war jedoch bei der Außenbereich-Instanz nicht erfolgreich, so dass Außenbereichs-Bestellungen derzeit wieder über die andere Instanz erfolgen müssen.
  Meine Anmerkung: Die Ursachenforschung war vor Ort nicht möglich, weil mir die Entwicklungswerkzeuge fehlten und ich im laufenden Betrieb keine Systemänderungen vornehmen wollte. Wie wir das lösen, steht noch aus.
   Anmerkung 21.12.2015: Die Ursache wurde gefunden. Beim Update wurde die neue Version in einen anderen Webbereich geschrieben, so dass die ursprüngliche Konfiguration vom Benutzer eingegeben werden musste. Dabei war dem Anwender ein Tippfehler beim Tabellenpräfix passiert. Nach Neustart der Update-Vorgangs mit korrigiertem Tabellenpräfix war die Instanz wieder benutzbar.
  
  
• Arbeitsbondruck nicht zuverlässig. Es wurde berichtet, dass es Fälle gibt, bei denen trotz Druck auf den Button Arbeitsbon der Arbeitsbon nicht gedruckt wird. Erst ein erneuter Druck auf den Button druckt den Arbeitsbon. Außerdem soll es vorkommen, dass Bons zweimal gedruckt werden und damit Posten überflüssigerweise zubereitet werden. Das Fehlverhalten soll sporadisch (etwa alle 2 Tage) auftreten.
  Meine Anmerkung: Der Prozess zum Drucken von Arbeitsbons ist intern unnötig komplex implementiert - es finden viele Interaktionen zwischen Client und Server statt. Ich kann mir den Fehler nur so erklären, dass der Server kurzzeitig nicht erreichbar ist und es zum Timeout kommt, der Bon daraufhin verworfen wird. Wenn ich hier den Code aufräume, sollte das beschriebene Verhalten nicht mehr auftreten.
   Anmerkung 21.12.2015: Das Kommunikationsprotokoll wurde in der Version 1.1.0 erheblich verschlankt. Mit einer Vorversion der 1.1.0 traten keine derartigen Druckprobleme mehr im Alpendörfchen auf.

(Ein Innenraum des gemütlichen Alpendörfchens)

Nun folgen die Wünsche, die an mich herangetragen wurden:

• Schnellere Bedienung. Die Aussage, das System bediene sich träger als vergleichbare Produkte kommerzieller Anbieter, musste ich leider im dortigen Fall bestätigen. In der Tat war die Bedienung auf den dortigen Smartphones nicht so flüssig, wie ich das in meiner heimischen Umgebung gewöhnt bin. Allerdings waren die eingesetzten Smartphones selbst sehr langsam (chinesisches Fabrikat, etwa 60 Euro). Außerdem war die WLAN-Erreichbarkeit an einigen Stellen des Gastronomiebreichs sehr schlecht. Wenn man beides verbessern würde, kann man da sicher noch etwas rausholen. Natürlich ist insbesondere in einem solchen Betrieb Geschwindigkeit das alles entscheidende Kriterium. Den Punkt nehme ich sehr ernst und prüfe, ob ich durch eine verbesserte Implementation die Performance noch verbessern kann.
   Anmerkung 21.12.2015: Insbesondere Verbesserungen für eine schnellere und flüssigere Bedienung sind in die Version 1.1.0 eingeflossen. Durch intelligentes Prefetchen der Speisekarte wurde ein großer Performancegewinn erreicht. Zusätzlich hat der Kellner nun mehr Möglichkeiten, mit wenigen Klicks eine passgenaue Bestellung aufzunehmen.
  
  
• Die Liste der Posten auf dem Arbeitsbon sollte nach Produktname gruppiert werden. Es ist weiterhin akzeptabel, dass die Produkte nicht kumuliert werden, um sie einzelnd bei Abarbeitung durchstreichen zu können.
 Anmerkung 21.12.2015: Auch das ist bereits in der Version 1.0.43 eingebaut worden.


• Unterstützung von Pfand. Zur Zeit sieht OrderSprinter nicht vor, dass Produkte mit Pfand verkauft werden und das Pfand später ausgezahlt wird. Diese Funktionalität ist insbesondere für Events wie den Weihnachtsmärkten relevant und lässt sich zur Zeit mit OrderSprinter nur über unschöne Workarounds abbilden. Leider ist es aber auch nicht so einfach einzubauen. Vielleicht schaffe ich es bis zum nächsten Weihnachtsmarkt...
• Schon in der Bestellansicht sollten die Tische farblich markiert sein, bei denen Produkte gebucht sind.
   Anmerkung 21.12.2015: Ab Version 1.1.0 ist es in der (textuellen) Tischanzeige innerhalb der Bestellansicht erkennbar, wenn Tische noch ausstehende Zahlbeträge besitzen. Ebenso wird in der Tischansicht nun angezeigt, wenn Produkte fertig zubereitet und fertig zum Servieren bereit stehen (digitaler Arbeitsablauf)

• In der Kassenansicht sollte auch beim Button Außer-Haus-Verkauf analog zu den Tischbuttons die zu zahlende Summe angezeigt werden. Wurde nichts gebucht, sollte der Button nicht zu sehen sein.
   Anmerkung 21.12.2015: In Version 1.1.0 wurde das korrigiert.
  
  
• Der Button Kasse sollte bei einem Tisch in der Bestellansicht nicht zu sehen sein, wenn noch keine Produkte gebucht wurden.
   Anmerkung 21.12.2015: In Version 1.1.0 wurde das korrigiert.
  
  
• In der Kassenansicht sollte die Gesamtsumme bereits vor Anwahl der Produkte oben bei der Tischanzeige angezeigt werden.
   Anmerkung 21.12.2015: In Version 1.1.0 wurde das Feature eingebaut.
  
  
• Arbeitsbons sollten den Namen des Kellners, der die Bestellung aufgenommen hat, enthalten (für den Fall wichtig, wenn zubereitete Speisen/Getränke am Tresen nicht abgeholt werden)
   Anmerkung 21.12.2015: Seit Version 1.0.43 ist das Feature eingebaut.
  
  
• Die Anzahl der Produkte sollte schon bei der Bestellung mit einem Klick eingebbar sein (im Moment muss der Kellner das Produkt buchen, dann das Produkt erneut auswählen und die Anzahl festlegen).
   Anmerkung 21.12.2015: Das Feature wurde in Version 1.1.0 eingebaut.
  
  
• Es sollte in der Bestellansicht bei der Produktauswahl einen Button geben, der nur eine Ebene zurückgeht. Im Moment kommt der Kellner direkt auf die oberste Auswahlebene zurück.
   Anmerkung 21.12.2015: Das Feature wurde in Version 1.1.0 eingebaut.
  
  
• Bei Reservierungen sollte der Tisch angebbar sein. In der Bestellansicht sollten die reservierten Tische (schon 1 Stunde vor der Buchung) erkennbar sein.

(Isi kümmert sich um den laufenden Betrieb des OrderSprinters vor Ort wie das Einrichten der Speisekarte und das Aufspielen von Updates.)

Ein ganz großer Dank nochmals an das gesamte Team vom Alpendörfchen für diese wertvollen Tipps!!! Ich werde versuchen, soweit es mir möglich ist, diese in neuen Versionen umzusetzen!

Stefan Pichel, Dezember 2015

PS: Der Caramel Macchiato war super lecker!