Offen statt monolithisch: Wie Headless POS Ihren Alltag wirklich verändert

Im letzten Artikel meiner kleinen (Kopflos-)Serie habe ich erklärt, warum nicht mehr „die Kasse“ das Zentrum ist, sondern die Transaktion. Heute drehen wir die Kamera ein Stück weiter weg: Es geht um Offenheit. Genauer: darum, was eine Headless, UI-agnostische Architektur außerhalb der Technikfolien verändert. Und das im Tagesgeschäft, in Projekten, bei Kosten, in der Art, wie Teams arbeiten und Innovation entsteht. Kein Buzzword-Gedöns, sondern die Perspektive aus echten Rollouts.

Offen heißt nicht nur „UI vom Backend trennen“

„Headless“ wird oft mit einem Satz erklärt: Frontend und Backend werden entkoppelt. Das stimmt, aber die Konsequenzen sind viel größer. Offenheit bedeutet, dass Sie pro Format das passende Interface wählen können (klassische Kasse, Self-Checkout, Verkäufer-Tablet, Webshop, App, Automat), ohne den Transaktionskern anzufassen. Es bedeutet auch, dass Tempo plötzlich wieder Ihr Freund wird: Änderungen am Flow oder Layout gehen als UI-Update in Tagen live, während der stabile Kern für Regeln, Steuern, Belege und Zahlarten sorgt. Offenheit heißt außerdem Partnerfähigkeit. Agenturen oder Integratoren können auf einer sauberen, abgesicherten Schnittstelle eigene Oberflächen bauen. Und Offenheit bricht Abhängigkeiten: keine Zwangshardware, kein UI-Lock-in. Schließlich wird Skalierung fairer und planbarer: Sie schalten Touchpoints nach Bedarf zu oder wieder ab; lizenzseitig zählt nur das aktive UI.

So ist KORONA POS Next gedacht und gebaut: als robuster, transaktionszentrierter Core (Kotlin/JVM), der ereignisorientiert über WebSockets mit den UIs spricht und dank SQLite (oder wahlweise PostGreSQL) auch dann weiterarbeitet, wenn die Leitung stolpert. Welche Oberfläche davor sitzt, entscheiden Sie: Web/JavaScript, Compose Multiplatform (unsere Beispiel-Demo), Flutter, native iOS/Android, oder auch etwas Eigenes. Über die KORONA Cloud hängen Backoffice und Drittsysteme dran; administriert wird das alles bequem im Web über KORONA Studio. Ein Mischbetrieb mit klassischer KORONA POS und KORONA POS Express (Android) im gleichen Account ist ausdrücklich vorgesehen.

Was sich wirklich ändert, vom Projektalltag bis zur Filiale

Der größte Bruch mit „dem Alten“ ist spürbar, nicht sichtbar. UI-Anpassungen werden von der Großaktion zur Routine. Eine Saisonaktion braucht einen neuen Bildschirm, ein anderer Checkout-Flow soll getestet werden, die Filialen wünschen sich einen gestrafften Retourenablauf: In einem monolithischen System zieht das einen Rattenschwanz nach sich: Regressionstests, Release-Fenster, Wochen der Unsicherheit. In einem headless Setup bleibt der Core stabil, und das UI iteriert schnell. Feature-Flags helfen, Varianten gezielt auszurollen oder auf kleine Gruppen zu begrenzen. Das Ergebnis ist simpel: Dinge gehen rechtzeitig live.

Zweitens verschwinden „Sonderwege“. Wenn City-Store, Flagship, Stadion-Kiosk, E-Ladesäule und Warenausgabe-Automat alle denselben Transaktionskern nutzen, haben Sie ein Regelwerk für Promotions, Steuern und Belege, aber verschiedene Oberflächen und Prozesse, die zum Format passen. Die Erfahrung für Kundinnen und Kunden ist konsistent, die Arbeit für Teams wird planbarer.

Drittens können Sie experimentieren, ohne Angst, in eine Sackgasse zu steuern. Zwei Checkout-Varianten parallel? Eine zusätzliche Fast-Lane? Ein Self-Order-Terminal nur für die Snack-Theke? All das ist möglich, ohne dass Sie die Transaktionslogik verbiegen. Entscheidungen basieren wieder auf Daten: Abschlussquoten, Wartezeiten, Fehlerquoten (statt Bauchgefühl oder „so haben wir’s immer gemacht“).

Viertens werden Partner schnell anschlussfähig. Ein Spezialist baut ein individuelles Kiosk-UI? Eine Agentur liefert die App? Solange die Verträge für WebSocket/API sauber definiert sind, ist das kein Risiko, sondern Beschleunigung. Und fünftens fällt ein Stück Nervosität aus dem Betrieb: Lokale Persistenz mit SQLite puffert, wenn die Leitung zickt. Peaks lassen sich mit zusätzlichen mobilen UIs abfedern. Keine Angst, in unserem Modell zahlen Sie nur für aktive Interfaces, nicht für Kisten, die im Lager stehen.

Drei Szenarien, die heute mal über die Klassiker hinausgehen

Erlebnispark & Veranstalter.
Ein Core, viele Gesichter: Ticketautomat und Drehkreuz vorn, Self-Order-Terminals und Gastro-Kassen auf dem Gelände, Webshop zu Hause. Online gekauftes Ticket wird am Drehkreuz per QR verbucht, Snacks sind vorbestellt und zur Abholung getaktet. Für den Besucher fühlt es sich wie ein zusammenhängender Tag an und für Sie bleibt es eine regelkonforme Transaktionswelt mit stimmigen Belegen.

E-Ladesäulen.
Am Terminal startet die Ladung, auf dem Smartphone läuft der begleitende Flow; der Core rechnet ab und erstellt den fiskalisierten Beleg. Sie brauchen dafür kein zweites Abrechnungssystem, denn die POS-Engine kann Retail und Service in einem, inklusive Flotten-Usecases. Das Beste ist, auch an Ladesäulen können Sie die gesamte Promotion- und Marketingklaviatur spielen.

Warenausgabe-Automat (BOPIS/Click&Collect).
Die Bestellung passiert online, die Abholung am Automaten. Ein QR genügt, die Ausgabe läuft, der Beleg kommt aus demselben Core wie an der Theke. 24/7-Komfort für Kundinnen und Kunden und eine durchgängige Transaktionshistorie für Ihr Team. Auch hier: Promotion oder dynamische Preise inklusive.

Architektur mit Haltung: Stabil im Kern und super lebendig am Rand

Ein offener Ansatz ist kein Freifahrtschein. Er braucht Leitplanken, damit Geschwindigkeit nicht in Wildwuchs kippt. In der Praxis haben sich drei Dinge bewährt:

• Design-System & UX-Guidelines, die über alle UIs hinweg Begriffe, Muster und Fehlermeldungen einheitlich halten.
• API-Verträge als Produkte, natürlich mit Versionierung, Deprecation-Policy, Beispielpayloads und klaren Fehlertypen.
• Observability, die technische Sicht (Latenz, Fehlerraten) mit Business-Signalen (Abbruchquote pro Schritt, Wartezeit pro Touchpoint) verbindet.

Security ist „by design“ gelöst, nicht „by Hoffnung“: TLS, sauberes Secrets-Handling, Gerätehärtung, Rollen und Rechte und vor allem: die heiklen Dinge (Fiskalisierung, Belege, steuerliche Regeln) liegen im Core, nicht in der UI.

Technologie, die den Alltag trägt

KORONA POS Next setzt auf Kotlin (ganz modern, robust, pragmatisch) und auf einen WebSocket-Server, der UI-Ereignisse in Echtzeit verarbeitet. Das ist nicht nur „schnell“, sondern auch zustandssicher: Gerade bei mehreren UIs pro Instanz ist Konsistenz entscheidend. SQLite (bzw. PostGreSQL) sorgt für lokale Resilienz, wenn Netzwerkpfade einmal holpern. Über die KORONA Cloud integrieren Sie ERP, FiBu, WaWi, CRM und weitere Systeme; administriert wird das alles im Browser über KORONA Sttudio. Wichtig: Eine KORONA POS Next-Instanz darf eine oder viele UIs bedienen; jede UI gilt fiskalisch/organisatorisch als eigenständiger POS, natürlich sauber getrennt, zentral gesteuert.

Migration ohne Big-Bang >> wie man klug startet (ja, können auch Sie)

Der eleganteste Weg führt nicht über „alles neu“, sondern über das Strangler-Pattern: Sie stellen einem bestehenden Setup ein neues UI zur Seite, verschieben Lasten schrittweise und schalten alte Teile nacheinander ab. Praktisch sieht das so aus: In den ersten 30 Tagen schneiden Sie einen klaren Pilot (zum Beispiel Verkäufer-Tablet oder Warenausgabe-Automat), ziehen Promotions, Steuern und Belege in den Core und definieren KPIs (Wartezeit, Abschlussquote, Fehlerquote, NPS). In den Tagen 31 bis 60 iterieren Sie die UI, testen Varianten, schulen Teams und binden einen zweiten Touchpoint an (z.B. einen Self-Checkout). Zwischen Tag 61 und 90 bereiten Sie die Skalierung vor: Rollout-Plan nach Regionen, Playbooks für Support und Updates, Lizenzen pro aktivem UI. Und Sie behalten bewusst den Mischbetrieb mit KORONA POS Classic und/oder Express noch eine Weile bei. Big-Bangs sind selten mutig, sondern meistens nur teuer.

Woran Sie ganz realistisch und fair den Erfolg messen

Wenn Headless gut umgesetzt ist, bewegen sich zuerst die „kleinen“ Dinge, die große Wirkung entfalten: Time-to-Market für UI-Änderungen sinkt von Monaten auf Wochen oder Tage. Wartezeiten in Peaks gehen runter, weil Self-Checkout und mobile Kassen Schlangen brechen. Die Conversion am POS steigt, weil Beratung am Regal direkt abschließen kann und „nicht da“ zu „kommt morgen“ wird und zwar in derselben Transaktion. Promo-Compliance verbessert sich, weil Regeln einmal zentral definiert werden und dann überall gelten. Und die TCO fällt, weil Sie statt drei bis fünf Inselsystemen einen Kern betreiben. Zur Kostenseite gehört auch Transparenz: Die Lizenzierung erfolgt pro aktivem UI (z. B. pro Tablet, Kiosk, Webshop-Checkout) , aktuell nur 59 € pro Monat, unabhängig von der Anzahl der KORONA POS Next-Instanzen. Mehr Touchpoints bedeuten planbare Mehrkosten statt Überraschungen.

Und die häufigsten Fragen?

Brauchen wir dann für jedes Format ein eigenes UI?
Nicht zwingend. Viele starten mit ein bis zwei UI-Templates, die über Feature-Flags variiert werden. Wichtig ist die Freiheit, dort zu differenzieren, wo es dem Geschäft nützt.

Wie verhindern wir Wildwuchs?
Mit einem Design-System, klaren API-Verträgen und einem Change-Playbook (wer schaltet was, wann, wie live und wie rollen wir zurück?). Offenheit ist ein Werkzeugkasten, kein Durcheinander.

Was ist mit unserer vorhandenen Hardware?
Oft weiter nutzbar. Headless reduziert Abhängigkeiten. Entscheidend ist, dass Ihr UI sinnvoll auf dem Zielgerät läuft und nicht, von wem die Box stammt.

Was KORONA POS Next dafür konkret bereitstellt

Eine Transaktions-Engine (Kotlin/JVM, WebSockets, SQLite) mit Promotions, Steuerlogik, Beleg- und Zahlartenhandling im Kern. UIs nach Wahl, z.B. Web/JS, Compose Multiplatform (Demo verfügbar), Flutter oder auch native gebaut von Ihrem Team, Partnern oder uns. Die KORONA Cloud als verbindendes Rückgrat und KORONA Studio als Web-Backoffice; zahlreiche Integrationen (ERP, FiBu, WaWi, CRM) sind bereits vorhanden. Betrieb auf Edge, im Rechenzentrum oder in der Cloud; Mischbetrieb mit KORONA. POS (klassisch) und KORONA POS Express ist möglich. Lizensiert wird pro aktivem UI; die Zahl der Next-Instanzen spielt für die Kosten keine Rolle.

Fazit: Stabiler Motor, freie Gestaltung

„Offen statt monolithisch“ ist kein Luxus für Architekt:innen, sondern der Unterschied zwischen langsamer IT und beweglicher Organisation. Mit einem headless, transaktionszentrierten Ansatz bleibt das Komplexe (Fiskal, Sicherheit, Belege) verlässlich im Kern und vorn entsteht Raum, das passende Einkaufserlebnis zu gestalten. Genau dafür bauen wir KORONA POS Next.

Wenn Sie sehen möchten, wie das in Ihrem Setup aussieht vom Verkäufer-Tablet bis zur Kiosk-Flotte, vom Webshop-Checkout bis zum Automaten, zeigen wir es Ihnen gerne live: mit Pilot, Metriken, Rollout-Plan und Governance, die zu Ihrem Haus passt. Fragen Sie einfach unser jung-dynamisches Sales Team um Christan Jürs.