Hinter jeder Bestellung steckt eine ganze Welt. Lagerbestände werden geprüft, Zahlungen verbucht, Pakete gepackt, Zusteller losgeschickt. In der E2E Simulation siehst du jeden Schritt, testest ihn und darfst ihn gezielt kaputt machen.
Gebaut nach den Standardprozessen von Microsoft Dynamics 365. Sechs Services, über 240 REST-Endpoints, echte Geschäftsregeln.
6 E2E-Prozesse 5 Abteilungen 20 Rollen 150 Produkte über 240 Endpoints
Die Reise einer Bestellung
Anna bestellt eine Smartwatch. Folge ihrer Bestellung durch das ganze System.
Anna stöbert im Shop, legt die Smartwatch in den Warenkorb und geht zur Kasse. Der Bestand wird für 30 Minuten reserviert. Die Bestellung entsteht.
Die Zahlung wird autorisiert und verbucht. Die Rechnung entsteht mit Schweizer Mehrwertsteuer. Schlägt die Zahlung fehl, greift der Fehlerpfad.
Das Lager kommissioniert die Bestellung. Der Bestand sinkt, das Paket wird gepackt und für die Zustellung übergeben. Bei zu wenig Ware entsteht eine Teillieferung.
Der Zusteller übernimmt. Tracking-Events laufen zurück ins System, Anna sieht den Status live. Auch eine fehlgeschlagene Zustellung ist eingebaut.
Die Bestellung ist zugestellt. Innerhalb von 14 Tagen kann Anna sie zurückgeben. Dann läuft der Prozess rückwärts: Retoure, Prüfung, Wiedereinlagerung, Gutschrift.
Sechs Geschäftsprozesse wie U-Bahn-Linien. Jede Station ist ein Arbeitsschritt mit eigenem API-Endpunkt. Klick auf eine Station — und sieh, wohin die Daten fliessen. Wo sich Linien kreuzen, teilen sich Prozesse einen Schritt: das sind die Umsteigepunkte.
Ein Schweizer Online-Retailer verkauft 150 Produkte über 6 Lagerstandorte. Sechs End-to-End-Prozesse decken den gesamten Lebenszyklus ab: vom Kundenkauf (O2C) über Retouren (RMA), Lagerhaltung (I2D), Einkauf (S2P) und Buchhaltung (R2R) bis zum Kundenservice (C2R). Jeder Schritt erzeugt Events, die den nächsten auslösen.
Die 6 Prozesse laufen nicht isoliert — sie teilen sich 7 Interchange-Hubs. Wenn O2C eine Bestellung auslöst, reserviert I2D den Bestand, FIN verarbeitet die Zahlung, LOG kommissioniert und POST liefert. Die Netzplan-Anordnung zeigt, welche Abteilung welchen Schritt verantwortet und wo Prozesse sich treffen.
6 FastAPI-Services (Python 3.12) hinter einem Gateway-Proxy. Jeder Service hat eigene PostgreSQL-DB, eigene REST-API unter /api/v1/{service}/. Redis für Session-Caching. Event-Hooks statt direkter Imports — Services kommunizieren über synchrone HTTP-Calls, nicht über Message Queues.
·
Die fünf Abteilungen
Jede Abteilung hat ein eigenes Backoffice mit Dashboard, Masken und Rollen. Du kannst in jede hineinschauen. Vom Kunden zum Lageristen, vom Controller zum Zusteller.
Schaufenster und Schaltzentrale. Katalog, Bestellungen, Aktionen, Reklamationen. Koordiniert alle anderen Abteilungen.
Zahlungen, Rechnungen, Mahnwesen bis Inkasso, Gutschriften und Monatsabschluss. Mit Schweizer Mehrwertsteuersätzen.
Bestände über 6 Lagerstandorte, Kommissionierung, Wareneingang, Inventur und Retourenprüfung.
Die letzte Meile. Zustelltouren, Tracking-Events, fehlgeschlagene Zustellungen und Abholung von Retouren.
Einkauf mit Lieferanten, Anfragen und Bestellungen. Freigaberegeln nach Betrag, bis zum Vier-Augen-Prinzip.
Dazu PAY als interner Zahlungsdienst und ein Gateway davor.
6 Services + GatewayWas du hier testen kannst
Die Fehlerfälle sind fest in die Prozesse eingebaut. Du kannst sie gezielt auslösen und das Verhalten des Systems prüfen.
Der Bestand reicht nicht. Wie reagiert der Checkout, was passiert mit der Reservierung?
Die Autorisierung scheitert. Die Bestellung darf nicht ins Lager laufen.
Niemand öffnet die Tür. Zweiter Versuch, Abholung oder Rücktransport?
Nach 30 Minuten wird reservierter Bestand automatisch freigegeben. Mitten im Checkout?
Nur ein Teil ist lieferbar. Die Bestellung teilt sich in zwei Sendungen.
Der Prozess rückwärts: Rückgabe innerhalb von 14 Tagen, Prüfung, Wiedereinlagerung, Gutschrift.
Das System läuft weiter
Im Hintergrund läuft ein Betrieb. Kunden bestellen, das Lager kommissioniert, die Post stellt zu, der Einkauf bestellt nach. Und weil ein Betrieb nie schnurgerade läuft, kommt dazwischen, was in jedem Unternehmen dazwischenkommt.
Kunden stornieren, ziehen um, sind nicht zu Hause. Die Inventur findet eine Differenz, eine Zahlung wird von Hand gebucht. Keine Programmfehler — gewöhnliche Vorgänge, die deine Testfälle trotzdem treffen.
Ein Paket liegt Tage im Transport, ein Lieferant braucht seine Frist. Die Dauer ist gestreut: meist zügig, manchmal wochenlang. Sendungen stehen deshalb wirklich auf «unterwegs» — nicht nur eine Sekunde lang.
Neben den Prozessen läuft die Arbeit an den Stammdaten: Produkte, Lieferanten, Aktionen, Meldebestände. Gepflegt wird nach Bedarf — es entsteht nur, was fachlich fehlt.
Jede dieser Häufigkeiten lässt sich einstellen, je Abteilung und je Aufgabe getrennt. Wer eine ruhige Umgebung braucht, dreht sie herunter; wer Ausnahmen provozieren will, herauf. Wie die virtuelle Zeit auch: vorspulen, und aus Wochen werden Minuten.
Alles ist dokumentiert
Das Wiki beschreibt das System wie in einem echten Projekt. Damit wird aus Ausprobieren richtiges, anforderungsbasiertes Testen.
Alle sechs Prozesse mit Happy Path, Fehlerfällen und Status-Flows.
Im Wiki lesen →20 Rollen mit Verantwortungs-Matrix. Wer macht was in welchem Prozess?
Im Wiki lesen →Mehrwertsteuer, Mahnlauf, Fristen, Freigaben. Die Regeln, die das System einhalten muss.
Im Wiki lesen →Die Matrix verbindet Oberfläche, Prozesse und Daten. Grundlage für Anforderungsverfolgung.
Im Wiki lesen →Blick unter die Haube gefällig? Die System-Architektur ist im Wiki vollständig beschrieben.
Starte die Simulation und folge deiner eigenen Bestellung durch das System.
