Joane ist eine erfolgreiche Unternehmerin. Ihr Startup hat mit einer bahnbrechenden KI-Technologie die Finanzbranche revolutioniert. Jetzt, nachdem sie ihr Unternehmen für einen Millionenbetrag verkauft hat, erfüllt sie sich einen lang gehegten Traum: ein eigenes Flugzeug.
Sie entscheidet sich für ein hochmodernes Business Jet-Modell eines renommierten Herstellers. Aber anders als bei einem Online-Shop, wo man mit ein paar Klicks bestellt, läuft das hier anders:👉 Sie arbeitet eng mit einem Sales-Experten des Unternehmens zusammen. Gemeinsam konfigurieren sie das Flugzeug nach ihren individuellen Wünschen – von der Lederausstattung über die Galley bis zur Satellitenkommunikation.
Nach der Abstimmung gibt sie schließlich ihre Bestellung frei. Ein perfekt auf sie zugeschnittener Jet, designed für Produktivität, Komfort und Luxus in der Luft. Doch dann passiert es.

Die späte Erkenntnis – Eine Kaffeemaschine fehlt!

Drei Wochen nach der Bestellung sitzt Joane in ihrem Büro und genießt einen Cappuccino aus ihrer Lieblings-Siebträgermaschine. Da trifft es sie wie ein Blitz:☕ „Ich habe vergessen, eine Kaffeemaschine zu bestellen!“

Für jemanden, der gewohnt ist, dass sich Dinge mit einem Knopfdruck in Sekunden ändern, scheint das kein Problem zu sein. Also ruft sie ihren Sales-Ansprechpartner an.„Kein Thema, das bekommen wir hin!“, sagt er.

Doch dann beginnt die digitale Reise beim Lieferanten:

Das Problem: Ein System, das nur CRUD kennt

Der Sales-Experte loggt sich ins System ein. Die Bestellung ist eingetragen, fest in der Datenbank gespeichert:

🛑 Er kann sie nicht einfach „bearbeiten“.
🛑 Er kann sie auch nicht löschen und neu anlegen.
🛑 Es gibt keine Funktion für nachträgliche Änderungen.

Das liegt daran, dass das System nach einer simplen CRUD-Logik aufgebaut ist:

• Create: Bestellung anlegen
• Read: Bestellung anzeigen
• Update: Bestellung ändern (aber nur in bestimmten Status)
• Delete: Bestellung stornieren

Das funktioniert bei einfachen Bestellungen im E-Commerce. Aber in der Aviatik? Da sind Prozesse hochkomplex!
Eine nachträgliche Änderung bedeutet:

✅ Technische Machbarkeit prüfen
✅ Produktionsplanung anpassen
✅ Lieferanten für die Kaffeemaschine einbinden
✅ Neue Dokumentation für die Zertifizierung erstellen

All das kann ein einfaches UPDATE Bestellung SET Ausstattung = ‚Kaffeemaschine‘ nicht abbilden.

Die Lösung: Fachlich modellieren statt nur CRUD nutzen

Das Team erkennt: Die Bestellung ist kein statischer Datensatz – sie ist ein Prozess!
Ein Flugzeug ist keine Kaffeetasse, die man einfach austauschen kann. Änderungen müssen strukturiert erfasst, geprüft und kommuniziert werden.
Wie setzt man das um? Das neue System wird umgestellt auf eine echte Fachlogik.

Fachsprache und reale Prozesse abbilden

✅ Statt einfach „Bestellung ändern“, gibt es jetzt definierte Änderungsanträge.
✅ Der Kunde kann keine Bestellung „überschreiben“, sondern stellt eine Change Request.
✅ APIs heißen nicht mehr PUT /bestellung/{id}, sondern:

• POST /bestellung/{id}/change-request
• GET /bestellung/{id}/change-status

📌 Warum? Weil das System nachvollziehbar bleibt und echte Geschäftsprozesse widerspiegelt.

Trennung von Fachlogik und Datenbank

✅ Die Software entscheidet nicht einfach „ändern erlaubt oder nicht“.
✅ Sie prüft die Machbarkeit basierend auf:ProduktionsstatusLieferzeitenZertifizierung
✅ Der Sales-Experte bekommt eine automatische Rückmeldung, ob der Änderungswunsch realistisch ist.

📌 Warum? Damit wird sichergestellt, dass alle Abhängigkeiten berücksichtigt werden.

Ereignisse statt reine Datenmanipulation

✅ Statt UPDATE Bestellung SET status = ‚geändert‘, werden Events gespeichert:

• BestellungAufgegeben
• ChangeRequestErstellt
• ChangeRequestGenehmigt
• ÄnderungInProduktionEingeleitet

📌 Warum? Weil so eine vollständige Historie entsteht. Jeder kann später nachvollziehen, wer was wann warum geändert hat.

Iteratives Feedback mit Kunden und Sales

✅ Statt chaotischem Hin und Her gibt es festgelegte Feedback-Loops:

• Der Kunde sieht transparente Statusupdates.
• Sales kann aktiv mit dem Produktions- und Engineering-Team kommunizieren.
• Es gibt klare Deadlines, bis wann Änderungen möglich sind.

📌 Warum? Weil Kunden in der Aviatik oft spät entscheiden – aber Prozesse trotzdem planbar bleiben müssen.

Das Ergebnis: Ein System, das mit der Realität arbeitet

Joane erhält eine Bestätigung:

• „Ihr Änderungswunsch wurde geprüft und ist umsetzbar. Die Kaffeemaschine wird in die Produktion eingeplant.“
• „Sie erhalten ein Update, sobald die Änderung in die Dokumentation übernommen wurde.“
• „Falls Sie weitere Anpassungen wünschen, können Sie bis zum Stichtag X neue Change Requests stellen.“

🔹 Keine Panik beim Sales-Team.
🔹 Kein Chaos in der Produktion.
🔹 Kein manuelles Tracking in Excel-Tabellen.

Stattdessen eine klare, fachliche Struktur, die echten Geschäftsprozessen folgt.

Fazit: Das Playbook für eine bessere Modellierung in der Aviatik

Wer in der Aviatik Software entwickelt, muss erkennen:

✈ Flugzeugbestellungen sind Prozesse, keine simplen CRUD-Datensätze.
✈ Änderungen müssen als Change Requests behandelt werden.
✈ Geschäftsereignisse müssen nachvollziehbar gespeichert werden.
✈ Systeme müssen iterativ entwickelt und an Fachlogik angepasst werden.

Sind eure IT-Systeme noch in der CRUD-Welt oder schon in der echten Aviatik-Realität?