// Fallstudie
Ein Ökosystem für KMU: vom Telefonzettel zum geteilten Kundenstamm
Kleine Betriebe brauchen keine grosse Software, sondern Werkzeuge, die weniger Arbeit machen als Papier. Wie aus einem Auftrag für eine Bestell-App eine Familie von Apps mit gemeinsamem Datenmodell wurde.
Ausgangslage
Befreundete Gärtnerinnen und Gärtner führen zu dritt eine Gärtnerei mit mehreren Gewächshäusern und einen Gartenbau. Bestellungen kamen per Telefon oder direkt in der Gärtnerei und landeten auf Papier. Das hatte drei Folgen:
- Bestellungen gingen verloren oder wurden erst spät wiedergefunden.
- Der Lieferant hat selten alles vorrätig. Aufträge werden geteilt und teilweise geliefert, und auf Papier weiss niemand mehr, welche Bestellung welche Pflanzen schon bekommen hat.
- Streit über das, was bestellt war. Während eines Besuchs bei ihnen bestand eine Kundin darauf, eine frühere Lieferzeit vereinbart zu haben, als unsere Freunde notiert hatten. Beweisen konnte es niemand.
Die Idee, Offerten, Verträge und Rechnungen zu automatisieren, hatte ich schon vorher, weil ich den Papierkram bei meinen eigenen Aufträgen genauso wenig mag. Mangels Zeit hatte ich sie zurückgestellt. Dann kam der konkrete Auftrag: eine App für die Bestellungen.
Die Rahmenbedingungen:
- Gegen Papier gewinnen: Die App muss sofort einleuchten und darf keine Arbeit hinzufügen, die das Papier nicht hatte. Sonst liegt nach zwei Wochen wieder der Notizblock neben dem Telefon.
- Keine festen Abläufe: Jedes Telefonat verläuft anders. Mal kommt zuerst der Name, mal die Pflanze, mal ein Wunsch zur Lieferung. Die App muss sich dem Gespräch anpassen, nicht umgekehrt.
- Bestellungen entstehen am Desktop während eines Telefonats, Abholungen beim Lieferanten am Handy.
- Schlank bleiben: Die App löst genau dieses Problem, nicht mehr. Pflegehinweise oder Bodenarten zu jeder Pflanze wären erst nützlich, wenn auch die Kundschaft die App sieht.
Meine Rolle
Die Apps in diesem Ökosystem liegen vollständig bei mir: Anforderungen mit den Gärtnern klären, UX und Gestaltung, Datenmodell, Entwicklung, Betrieb. Beim Programmieren arbeite ich mit KI-Agents, die Architektur und die Entscheide sind meine.
Die Domäne ins Modell übersetzen: Vorgaben oder feste Begriffe gab es nicht. Die Gärtner beschrieben, was ihnen helfen würde, und ich habe daraus Abläufe und Begriffe gemacht: Bestellung, Markt, Zuteilung, Abschluss. In der Graph-Datenbank sind die Beziehungen Kanten: Eine Kundin platziert eine Bestellung, eine Bestellung enthält Pflanzen, eine Bestellung löst eine Nachricht aus. Eine Bestellung führt drei Listen: bestellt, zugeteilt, geliefert. So bleibt eine Teillieferung sichtbar, ohne dass jemand rechnen muss.
Zusammenarbeit: Die Gärtner testen im Betrieb und melden, was stört. Formale Nutzertests gab es nicht. Meine UX-Entscheide stützen sich auf das, was ich bei ihnen in der Gärtnerei und am Telefon gesehen habe, und auf ihre Rückmeldungen.
Deep Dives
// UX und Bestätigungen
Eine Bestell-App, die gegen Papier gewinnen muss
Der Massstab ist nicht eine andere App, sondern ein Notizblock. Jeder Schritt muss schneller oder sicherer sein als Stift und Papier.
Anruf oder Kundin in der Gärtnerei
- Bestellung Am Desktop, während des Telefonats. Kunde und Pflanzen per unscharfer Suche
- Bestätigung SMS-Entwurf mit Bestellliste und Notizen, vor dem Versand bearbeitbar
- Markt Am Handy beim Lieferanten: Was ist verfügbar, was wurde abgeholt?
- Zuteilung Nach einer Regel als Vorschau oder von Hand, mit Übersicht über Bestand und Bestellungen
- Abholbereit Zweite SMS, optional, dann Abschluss
Bestellung abgeschlossen
Was die App schneller macht als Papier:
- Alle Eingaben nebeneinander. Kunde, Pflanzen und Notizen stehen auf einem Bildschirm, in beliebiger Reihenfolge ausfüllbar. Das Gespräch bestimmt den Ablauf, nicht ein Formular mit festen Schritten.
- Unscharfe Suche für Kunden und Pflanzen. Tippfehler und halbe Namen während eines Gesprächs finden trotzdem den richtigen Eintrag. Doppelte Einträge werden beim Erfassen abgefangen.
- Zwei Oberflächen für zwei Situationen. Am Desktop eine Erfassung neben dem Telefon, am Handy beim Lieferanten grosse Listen und Akkordeons.
- Farben statt Zahlen. In der Zuteilung ist Fehlendes rot und Zugeteiltes blau. Wer beim Lieferanten steht, sieht auf einen Blick, was noch fehlt.
Die Bestätigung per SMS entstand aus dem Streit um die Lieferzeit. Mit einer schriftlichen Bestätigung hätte es ihn nicht gegeben. Ich habe Mail, WhatsApp und SMS abgewogen: Ein Teil der Kundschaft ist älter und nicht technikaffin, aber fast alle haben ein Handy. SMS ist der kleinste gemeinsame Nenner.
Die Bestätigung wird bewusst nicht automatisch verschickt. Die App füllt eine Vorlage mit der Bestellliste und allen Notizen, die während des Gesprächs dazukamen. Vor dem Versand lässt sich der Text bearbeiten, und der Versand ist optional. Technisch wird die Nachricht zuerst als Entwurf gespeichert und mit der Bestellung verknüpft, erst dann geht sie an den SMS-Anbieter. Scheitert der Versand, bleibt der Entwurf erhalten und die App meldet den Fehler.
// Ein kleiner Algorithmus mit grosser Wirkung
Zuteilung: Wer bekommt die knappen Pflanzen?
Wenn der Lieferant zu wenig hat, braucht es einen Überblick und einen Vorschlag. Die Entscheidung bleibt beim Menschen: nach einer Regel oder von Hand.
Nach dem Einkauf beim Lieferanten stellt sich jedes Mal dieselbe Frage: Welche Bestellung bekommt welche Pflanzen? Auf Papier war das Kopfrechnen.
Die Übersicht zuerst. Die Zuteilungsansicht hat drei Spalten. Links steht jede Pflanze mit einem kleinen Feld pro bestellter Einheit, farbig nach Zustand: verfügbar, zugeteilt oder fehlend. Senkrechte Striche trennen die Bestellungen. So sieht man auf einen Blick, wie viel fehlt und wen es trifft. In der Mitte stehen die Bestellungen, rechts die gewählte Bestellung mit Kontaktdaten, Notizen und den Knöpfen zum Benachrichtigen und Abschliessen. Wer will, teilt von Hand zu: Ein Klick auf ein fehlendes Feld weist die Pflanze zu.
Regeln als Vorschau. Zwei Regeln lassen sich wählen. Die Bestellungen, die eine Regel vollständig bedienen würde, bekommen einen farbigen Rand. Erst ein Klick auf «Anwenden» übernimmt den Vorschlag.
Die naheliegende Regel ist die Reihenfolge (FIFO): Die älteste Bestellung nimmt, so viel sie braucht, dann die nächste. Das ist fair, hat aber einen Haken. Eine einzige grosse Bestellung, die sich ohnehin nicht vollständig erfüllen lässt, blockiert alle kleinen dahinter.
Die zweite Regel ist hybrid und die Voreinstellung, in zwei Durchgängen: Zuerst bekommt jede Bestellung, die sich vollständig erfüllen lässt, ihre Pflanzen, in der Reihenfolge des Eingangs. Danach wird der Rest nach Reihenfolge auf die übrigen Bestellungen verteilt.
Ein Beispiel mit erfundenen Zahlen: Vorrätig sind 5 Lavendel und 2 Rosmarin.
| Bestellung | FIFO | Hybrid |
|---|---|---|
| A, Mo: 5 Lavendel, 3 Rosmarin | 7/8 | 3/8 |
| B, Di: 2 Lavendel | 0/2 | komplett |
| C, Mi: 2 Rosmarin | 0/2 | komplett |
Mit FIFO kann niemand abholen. Mit der hybriden Regel sind zwei Kunden sofort bedient, und nur die grosse Bestellung wartet, die ohnehin gewartet hätte.
Der Preis: Die älteste Bestellung bekommt weniger als bei FIFO. Deshalb ist keine Regel Pflicht, und jeder Vorschlag ist nur eine Vorschau. Die Entscheidung trifft der Mensch, der die Kundschaft kennt.
// Vom Einzelauftrag zum Ökosystem
// adr
Ein gemeinsamer Kundenstamm in der Datenbank statt einer API
finalcontext
Zwei Apps, ein Betrieb, eine Person, die alles betreibt. Beide Apps brauchen dieselben Kunden, und in der Graph-Datenbank hängen an jedem Kunden Kanten aus beiden.
decision
Beide Apps nutzen dieselbe Tabelle, geregelt durch einen schriftlichen Vertrag in beiden Repos: nie hart löschen, nur zusammenführen, Änderungen am Vertrag immer in beiden zugleich.
gains
- Kein zusätzlicher Dienst, den ein Kleinbetrieb betreiben müsste.
- Eine Kundin, die telefonisch bestellt, ist in der Offerte schon erfasst.
costs
- Enge Kopplung über das Schema. Eingehalten wird der Vertrag durch Disziplin, noch nicht durch eine automatische Prüfung.
consequences
- Eine dritte App, etwa das Diktat, muss denselben Vertrag übernehmen oder über eine der beiden Apps schreiben.
Stand & Ausblick
Bestell-App: im Testbetrieb beim Gartenbaubetrieb. Offen sind längere Bestellungen, die heute an die Längengrenze einer einzelnen SMS stossen, und automatische Tests über den Nachrichtenfluss hinaus.
Dokumenten-App: läuft auf meinem Server, die erste echte Rechnung steht noch aus. Eine eigene Instanz für den Gartenbaubetrieb ist geplant. Details in der Fallstudie zu den Dokumenten.
Diktat beim Rundgang: Die Idee: Der Landschaftsgärtner geht mit der Kundschaft durch den Garten, spricht ins Handy, und aus dem Gesagten werden Positionen für eine Offerte, die die Dokumenten-App direkt ausgeben kann. Der erste Prototyp in Swift nutzt die Spracherkennung von iOS auf Hochdeutsch und einen regelbasierten Parser, der Zahlwörter, Einheiten und mehrere Positionen in einem Satz erkennt, abgesichert mit 15 Unit-Tests. Er ist noch an nichts angebunden.
Der nächste Schritt ist eine Entscheidung, keine Funktion: Wie gut versteht eine Spracherkennung Schweizerdeutsch? Ich will ein Schweizerdeutsch-Modell selbst gehostet testen und prüfen, ob es dafür überhaupt GPUs braucht. Davon hängt ab, ob die Verarbeitung während des Rundgangs geschieht oder im Hintergrund danach. Ist die Lösung nicht an Apple gebunden, schreibe ich den Prototyp als Web-App in SvelteKit neu. Das spart App Store und Signierung, und das Diktat nutzt dann denselben Stack wie die anderen Apps. Ob das Diktat dann über eine API oder direkt in die Datenbank schreibt, ist ebenfalls noch offen.
Lessons Learned
Was ich in ein Team mitbringe
- Domänen in Modelle übersetzen: Ich höre zu, wie Menschen über ihre Arbeit reden, und baue Datenmodelle und Oberflächen mit ihren Begriffen.
- Architektur im richtigen Massstab: Ein Vertrag für eine geteilte Tabelle statt eines Microservices, eigene Instanzen statt Mandantenfähigkeit. Ich wähle die einfachste Lösung, die die Risiken abdeckt, und schreibe die Kosten dazu.
- Ende-zu-Ende-Verantwortung: von der Anforderung am Küchentisch über Datenmodell und UX bis zum Betrieb auf eigenen Servern.
- Ehrlichkeit über den Stand: Was im Testbetrieb ist, nenne ich Testbetrieb, und was ein Prototyp ist, nenne ich Prototyp.