case studies.

Ein Angebotsprozess, der früher aus Excel-Dateien, E-Mail-Freigaben und manuellen Versionsständen bestand, wurde zu einer rollenbasierten Angebotsplattform mit auditierbarem Workflow. Ergebnis: schnellere Angebotserstellung, weniger Preis-/Freigabefehler und klare Nachvollziehbarkeit im Vertrieb – ohne die Fachbereiche mit „Tool-Komplexität“ zu belasten.

Mehrere Standorte arbeiten parallel an Angeboten mit komplexer Produkt- und Preislogik. Vertriebsmitarbeitende nutzen Vorlagen, Excel und E-Mail, um Varianten, Rabatte und Freigaben abzustimmen. Technische Rückfragen laufen asynchron, Änderungen werden als neue Dateien verschickt. In Spitzenzeiten entsteht Wartezeit durch Freigabeschleifen und fehlende Transparenz.

Preislogik und Rabattrichtlinien waren nicht konsistent durchsetzbar, weil Validierungen fehlten und Wissen in Köpfen steckte. Freigaben waren nicht revisionssicher (wer hat wann wofür zugestimmt). Angebotsänderungen führten zu Versionskonflikten. Im Fehlerfall war unklar, ob ein falscher Preis, ein veralteter Textbaustein oder eine falsche Variante ausgeliefert wurde.

Wir haben den Angebotsprozess als Zustandsmaschine modelliert (Entwurf → Prüfung → Freigabe → Versand) und die Domänenregeln (Preislogik, Rabatte, Pflichtfelder) an einer Stelle zentral implementiert. Rollen und Berechtigungen (RBAC) trennen Bearbeitung, Prüfung und Freigabe. Ein Audit-Trail protokolliert Zustandswechsel und relevante Änderungen. Integrationen (z. B. Stammdaten/ERP) werden über klar definierte Adapter angebunden, damit sich externe Änderungen nicht durch die Domäne fressen.

Umsetzungszeit: 10 Wochen. Woche 1–2: Prozessaufnahme mit Vertrieb/Technik, Definition der Freigabe- und Preisregeln, Risikofälle. Woche 3–6: Domänenmodell, API, UI-Flows, RBAC, Audit-Events. Woche 7–8: Datenübernahme (Vorlagen/Artikel), Rechte-Mapping, Smoke-Tests mit echten Angebotsfällen. Woche 9: Pilot mit einem Standort inkl. Training und begleiteter Nutzung. Woche 10: Rollout auf alle Teams, Monitoring (Fehlerquoten, Durchlaufzeiten) und Stabilisierung.

Durchlaufzeit pro Angebot sank von 1–2 Arbeitstagen auf typischerweise 2–4 Stunden, weil Freigaben sichtbar und standardisiert wurden. Preis- und Variantenfehler wurden durch Validierungen vor dem Versand deutlich reduziert. Rückfragen gingen zurück, weil der Status und die Verantwortlichkeit pro Schritt klar waren. Bei Reklamationen konnte nachvollzogen werden, welche Änderung wann erfolgt ist.

Pro: weniger Reibung im Vertrieb, nachvollziehbare Freigaben, geringeres Fehlerrisiko. Contra: initialer Modellierungsaufwand und strengere Regeln erfordern Disziplin in der Datenerfassung. ROI: Bei 30 Angeboten/Monat, 3 Stunden weniger Aufwand pro Angebot und 85 € interner Stunde ergibt das 7.650 € monatliche Einsparung. Projektaufwand 48.000 € → Amortisation nach rund 6 Monaten. Im Vergleich zu einem „klassischen“ Systemhaus-Ansatz (CRM-Formulare + E-Mail-Freigabe ohne Domänenregeln) bleiben Fehlerfälle und Nacharbeit typischerweise bestehen, wodurch die Einsparung deutlich geringer ausfällt und die Amortisation sich spürbar nach hinten verschiebt.

Ein historisch gewachsenes VB6/Access-System mit Import/Export-Logiken und INI-basierten Übersetzungen wurde nicht „hart ersetzt“, sondern schrittweise in ein modernes Backend (.NET/ASP.NET Core, REST) und ein React-SPA-Frontend überführt. Kernprinzip: erst verstehen, dann verändern – mit Parallelbetrieb, kontrollierten Schnittstellen und messbarer Risikoreduktion.

Das Bestandssystem war über Jahre organisch gewachsen: VB6-Clients, Access-Datenbanken, Cronjobs/Automatisierungen ohne saubere Dokumentation, Import-/Export-Pipelines und Übersetzungen über INI-Dateien. Das System lief produktionskritisch; gleichzeitig wuchsen Anforderungen an Sicherheit, Stabilität und Integration in andere Systeme.

Eine „Big Bang“-Ablösung war zu riskant: zu viele implizite Abhängigkeiten, unklare Nutzungspfade und Datenlogiken, die nur stabil waren, weil sie niemand anfässt. Parallel mussten Import/Export sowie bestehende Prozesse weiterlaufen. Jede Änderung konnte direkte Auswirkungen auf Betrieb, Datenqualität und Fachbereiche haben.

Wir haben die Migration als Zustand geplant, nicht als Schalter: stabile Interfaces statt „alles neu“. Kern war ein kontrollierter Parallelbetrieb mit klaren Domänen-Grenzen: (1) Systemverständnis aufbauen (Beobachtung, Analyse, Tests), (2) Backend-Fundament in ASP.NET Core + REST aufbauen, (3) Datenmodell schrittweise nach PostgreSQL überführen, (4) Frontend als React 18 SPA mit TypeScript/Vite aufsetzen, (5) Legacy-Funktionen in kleinen, überprüfbaren Inkrementen ersetzen – mit Rollback-Fähigkeit.

Phase 1: Reverse Engineering der kritischen Abläufe (Imports/Exporte, Übersetzungslogiken, Cronjobs) und Aufbau von Testfällen gegen reale Daten/Dateien. Phase 2: Einführung eines ASP.NET Core Backends mit REST-API als „saubere“ Integrationsschicht, ohne sofort die Legacy-UI zu brechen. Phase 3: Datenmigration nach PostgreSQL in Etappen (Mapping, Validierungen, parallele Writes/Reads, Abweichungsberichte). Phase 4: React 18 SPA (TypeScript 5, Vite 5) für neue/ersetzte Flows, während Alt- und Neu-Teile parallel betrieben wurden. Phase 5: Schrittweise Abschaltung von Legacy-Modulen nach Stabilitätsnachweis.

Die Migration verlief ohne „harten Cutover“: kritische Prozesse blieben laufend verfügbar, während neue Bausteine produktiv gingen. Fehlerquellen wurden sichtbar, weil Schnittstellen definiert und Datenbewegungen geprüft wurden. Neue Features konnten schneller implementiert werden, da Backend/Frontend klar getrennt und Erweiterungen planbar wurden.

Pro: weniger Risiko durch kontrollierten Parallelbetrieb, bessere Wartbarkeit, moderne Integrationsfähigkeit (REST), stabilere Datenbasis (PostgreSQL), schnelleres Delivery neuer Anforderungen. Contra: initialer Aufwand für Verständnis/Testabdeckung und längere Phase mit zwei Systemen. Entscheidend: Die Kosten werden nicht „wegoptimiert“, sondern in Sicherheit und Planbarkeit umgewandelt – und genau das verhindert teure Ausfälle im laufenden Betrieb.

Wir haben Release-Risiko reduziert, ohne Delivery zu verlangsamen: klare Qualitäts-Gates, gezielte Tests an kritischen Flows und Observability mit Runbooks. Ergebnis: weniger Regressionen, schnellere Diagnose im Incident und ein Release-Prozess, der auch mit wachsender Codebase stabil bleibt.

Das Team lieferte häufig aus, aber Releases waren riskant. Fehler wurden spät entdeckt, weil Tests nicht systematisch waren und die Pipeline wenig „frühe“ Signale lieferte. Im Incident fehlten Korrelation und Runbooks, sodass Debugging stark personenabhängig war.

Regressions waren schwer zu finden, weil API-Verträge und Datenmodelle nicht stabil abgesichert waren. Deployment-Zeit war hoch, Rollbacks nicht klar geübt. Alerts waren teilweise unkonkret. Dadurch entstanden vermeidbare Ausfallzeiten und hoher Support-Aufwand.

Wir haben typed boundaries an den wichtigsten Schnittstellen eingeführt, Smoke-Checks für geschäftskritische Flows definiert und Release-Gates in der Pipeline verankert (Lint/Typecheck, Build, Tests). Zusätzlich: Observability mit klaren SLOs, Error Budgets und Alerts, die eine Handlung auslösen (inkl. Runbook).

Umsetzungszeit: 4 Wochen. Woche 1: Critical Path definieren, Teststrategie und Pipeline-Gates festlegen. Woche 2–3: Contract-/Integration-Tests für Kernpfade, Build-Optimierungen, reproduzierbare Deployments, Rollback-Runbook. Woche 4: Observability (Tracing/Logging-Standards), Alerting mit Ownership, Übergabe in den Regelbetrieb.

Deployment-Zeit sank von 45 Minuten auf 12 Minuten, weil Builds reproduzierbar und Checks parallelisiert wurden. Kritische Regressionen wurden früher in PRs gefunden. Time-to-Diagnose im Incident sank deutlich, weil Request-Korrelation und klare Runbooks vorhanden waren.

Pro: weniger Risiko pro Release, schnelleres Recovery, weniger Support-Last. Contra: initiale Disziplin (Tests, Standards) kostet kurzfristig Fokus. ROI: Bei 2 Incidents/Monat à 2,5 Stunden schnellerer Stabilisierung und 6 beteiligten Personen à 95 €/h ergibt das 2.850 € monatliche Einsparung, plus vermiedene Kundenchurn-Kosten. Projektaufwand 28.000 € → Amortisation nach rund 10 Monaten. Ohne Prinzipien wie klare Grenzen und echte Observability bleibt ein Release-Prozess oft personengebunden; das kostet später mehr als die initiale Standardisierung.