Managed Support & MaintenanceApplication Support & MaintenanceApp Modernisation

Die 80 %, die niemand einplant: Software nach dem Launch

Die meisten Softwarebudgets behandeln den Launch als Ziellinie. Tatsächlich ist die Entwicklung der kleinere Teil — die Jahre danach tragen den größten Aufwand und den größten Wert.

Foto: Google Gemini · AI-generated

Die meisten Softwarebudgets haben dieselbe Form: eine große Zahl für die Entwicklung, eine kleine Zahl für “Support” — und dazwischen ein Launch-Termin, der wie eine Ziellinie aussieht.

Die tatsächliche Form ist fast das Gegenteil. Bei Unternehmenssoftware, die über Jahre im Einsatz bleibt, ist die erste Entwicklung der kleinere Teil des Gesamtaufwands. Alles nach dem Launch — patchen, anpassen, erweitern, kompatibel halten mit einer Umgebung, die sich weiterbewegt — ist der größere. Zu budgetieren, als wäre der Launch das Ende, ist kein Optimismus. Es ist ein Plan, überrascht zu werden.

Der Boden bewegt sich unter laufender Software

Der Punkt, der Teams regelmäßig kalt erwischt: Software zerfällt nicht von selbst. Ihre Umgebung verändert sich um sie herum, und die Software muss mitgehen.

Betriebssysteme bekommen neue Versionen mit neuen Regeln. App Stores ändern, was sie akzeptieren. Abhängigkeiten bekommen Sicherheitshinweise, die in Tagen gepatcht werden müssen, nicht in Quartalen. Browser streichen Funktionen, auf die man sich verlassen hat. Und die Frameworks selbst bewegen sich — manchmal endgültig. Unser Nachunternehmerportal betreibt native Apps für iOS, Android und Windows, gebaut mit Xamarin und MAUI. Wer in diesem Ökosystem liefert, weiß, was in diesem Satz steckt: Xamarin hat sein Lebensende erreicht, MAUI ist der Nachfolger. Anwendungen darauf mussten umziehen — nicht weil jemand ein neues Feature wollte, sondern weil Stehenbleiben keine Option war.

Nichts davon steht in einem Launch-Budget. Alles davon ist Pflicht.

Die zweite Hälfte: Anforderungen, die man vorher nicht kennen konnte

Der zweite Treiber ist der erfreulichere. Software, die wirklich genutzt wird, erzeugt Änderungswünsche — weil die Nutzung dem Unternehmen erst zeigt, was es tatsächlich braucht.

Das Nachunternehmerportal ist auch dafür ein gutes Beispiel: ein Bauunternehmen koordiniert Hunderte Nachunternehmer über Web und drei native Plattformen, offline-fähig im Feld, mit einer Auslieferung über Azure DevOps und getrennten Umgebungen für Dev, QA, Test und Live. Ein System mit dieser Oberfläche steht kein Jahr still. Baustellen ändern ihre Arbeitsweise, und das Portal folgt ihnen. Das ist kein ausuferndes Projekt. Das ist ein System, das nützlich bleibt — der einzige Grund, aus dem es gebaut wurde.

Support heißt nicht “warten, bis etwas kaputtgeht”

Das Wort “Wartung” verkauft die Sache deutlich unter Wert. Es klingt nach einem Helpdesk mit Posteingang. Tatsächlich ist laufende Verantwortung aktive Arbeit: Monitoring, das Probleme vor den Nutzern bemerkt; Abhängigkeits- und Plattform-Updates nach Plan; Regressionstests vor jedem Release; und jemand, der den Kontext hält, warum das System so gebaut ist, wie es gebaut ist.

ReportSync zeigt, warum diese Kontinuität zählt. Das System überträgt Wasserqualitätsberichte aus dem Feld in ein Firmen-CRM, mit vollständigem Sync-Protokoll, damit die Zustellung nachweisbar ist. Diese Zusage ist keine einmalige Leistung — sie hängt daran, dass eine Kette beweglicher Teile intakt bleibt: Geräte, Zertifikate, das CRM, der Tunnel dazwischen. Deshalb läuft es unter Managed Support & Wartung: Das Versprechen ist ein dauerhaftes, also muss auch jemand dauerhaft dafür verantwortlich sein.

Was man stattdessen budgetieren sollte

Drei praktische Änderungen:

  • Die Lebensdauer planen, nicht den Launch. Fragen Sie, was das System über fünf Jahre im Besitz kostet — und machen Sie diese Zahl zu Beginn sichtbar, statt sie im zweiten Jahr zu entdecken.
  • Plattformpflege getrennt von Features finanzieren. Framework-Migrationen und Sicherheitspatches verlieren jeden Vergleich mit sichtbaren neuen Funktionen. Geben Sie ihnen eine eigene Position, sonst verlieren sie jedes Quartal — bis etwas bricht.
  • Die Menschen halten, die das System kennen. Kontext ist Ihr günstigstes Kapital und das teuerste im Wiederaufbau. Ein Team, das Ihre Architektur jedes Jahr neu lernen muss, bezahlt dasselbe Wissen mehrfach.

Der Punkt ist einfach: Die Entwicklung liefert Ihnen ein funktionierendes System an Tag eins. Applikationssupport und Wartung sorgen dafür, dass es an Tag eintausend immer noch funktioniert — und immer noch wertvoll ist.

Wenn Sie Software im Einsatz haben und keine ehrliche Zahl dafür, was ihr gesunder Betrieb kostet: Darüber sollten wir sprechen.