← Wissen & Praxis
Softwareplanung

Nach dem Go-live: Wer bei Störungen, Updates und Datenverlust handelt

Eine neue Anwendung läuft, die Projektphase endet. Wenige Wochen später schlägt ein Datenimport fehl. Der Hoster sieht keinen Serverausfall, der Softwaredienstleister vermutet ein geändertes Fremdsystem und der Kunde weiß nicht, wer die Untersuchung koordiniert. Technisch kann jede einzelne Aussage stimmen. Für den Betrieb fehlt trotzdem eine klare Verantwortung.

Vor der Einführung sollte deshalb feststehen, wie ein Problem vom ersten Hinweis bis zum überprüften Ergebnis bearbeitet wird. Ein allgemeiner Verweis auf „Wartung“ beantwortet diese Frage selten ausreichend.

Die Aufgaben getrennt benennen

Hosting hält eine technische Umgebung bereit. Anwendungsbetreuung untersucht das Verhalten der Software. Fachliche Verantwortung entscheidet, ob ein Vorgang richtig verarbeitet wurde. Weitere Beteiligte betreuen möglicherweise Datenbank, Identitätsverwaltung oder angebundene Systeme. Keine dieser Aufgaben schließt automatisch die anderen ein.

Ordnen Sie die relevanten Aufgaben jeweils einer verantwortlichen Stelle zu: Überwachung, Entgegennahme von Störungen, erste Eingrenzung, technische Korrektur, Freigabe von Änderungen, Datensicherung und Wiederherstellung. Benennen Sie zusätzlich, wer bei unklarer Ursache die Beteiligten zusammenbringt. Der Kunde sollte nicht selbst zwischen mehreren technischen Zuständigkeiten vermitteln müssen, ohne dafür einen vereinbarten Ansprechpartner zu haben.

Ein fiktives Beispiel: Der Import hat keine neuen Daten geliefert

Eine Fachanwendung erhält nachts Produktdaten aus einem anderen System. Am Morgen fällt auf, dass neue Artikel fehlen. Der Server ist erreichbar und die Startseite funktioniert. Eine reine Erreichbarkeitsprüfung hätte daher keinen Fehler erkannt.

Ein brauchbarer Betriebsablauf prüft zusätzlich den fachlich relevanten Importstatus. Bei einer Störung wird festgehalten, wann zuletzt Daten vollständig übernommen wurden, welche Lieferung betroffen ist und ob bereits Teilmengen verarbeitet wurden. Vor einer Wiederholung muss geklärt sein, ob dadurch Dubletten oder widersprüchliche Änderungen entstehen können.

Die verantwortliche Stelle koordiniert die Prüfung mit dem Betreiber des Quellsystems. Nach der Korrektur reicht ein grüner technischer Status nicht: Die erwarteten Daten müssen in der Anwendung angekommen sein und für den vorgesehenen Vorgang nutzbar werden. Erst dann ist die konkrete Störung fachlich erledigt.

Eine kleine Verantwortungsmatrix vorbereiten

Nutzen Sie vorhandene Betriebsunterlagen und halten Sie für jede wesentliche Aufgabe fest: verantwortliche Stelle, Meldeweg, benötigte Zugänge, vereinbarte Betreuungszeit und nächste Eskalationsstelle. Unbesetzte Felder bleiben sichtbare offene Punkte vor dem Start.

  • Wer bemerkt, dass die Anwendung oder ein wichtiger Hintergrundprozess ausgefallen ist?
  • Wo meldet der Anwender eine Störung, und welche Angaben helfen bei der Eingrenzung?
  • Wer entscheidet über eine Unterbrechung, eine Rücknahme oder eine Notlösung?
  • Wer darf Daten korrigieren oder aus einer Sicherung wiederherstellen?
  • Wer prüft anschließend das fachliche Ergebnis und informiert die betroffenen Nutzer?

Reaktionszeit, Wiederanlauf und vollständige Fehlerbehebung sind unterschiedliche Größen. Vereinbaren Sie sie passend zur Bedeutung des Systems. Ein kleiner Betreuungsumfang kann angemessen sein, solange die daraus folgenden Grenzen bewusst akzeptiert werden.

Eine Sicherung ist erst mit einer Wiederherstellungsprobe überzeugend

Die Meldung „Backup erfolgreich“ zeigt zunächst, dass ein Sicherungsvorgang abgeschlossen wurde. Ob die Daten verwendbar sind und die Anwendung damit wieder startet, ist eine weitere Frage. Prüfen Sie die Wiederherstellung in einer isolierten, abgesicherten Umgebung mit geeigneten Daten und berechtigten Personen.

Zur Probe gehören die passende Anwendungsversion, Datenbank, notwendige Dateien und Konfiguration. Eine aktuelle Datenbanksicherung kann mit einer falschen Softwareversion unbrauchbar sein. Dokumentieren Sie den verwendeten Sicherungsstand, die tatsächliche Dauer, das Ergebnis eines wichtigen Geschäftsablaufs und offene Einschränkungen.

Wie viel Datenverlust und Unterbrechung vertretbar sind, muss der Auftraggeber fachlich bewerten. Daraus ergeben sich Anforderungen an Sicherung und Wiederanlauf. Eine einzelne erfolgreiche Probe garantiert keine beliebige spätere Wiederherstellung; sie liefert aber konkrete Hinweise darauf, was heute funktioniert.

Wartung braucht einen sichtbaren Arbeitsumfang

Klären Sie, welche Aktualisierungen beobachtet und eingespielt werden, wer deren Auswirkungen prüft und wie Änderungen freigegeben werden. Dazu können Betriebssystem, Laufzeitumgebung, Bibliotheken und Fremdsystemanbindungen gehören. Nicht jede Aktualisierung ist risikolos; dauerhaftes Nichtstun kann ebenso Risiken vergrößern.

Planen Sie deshalb passende Prüfungen, einen Rückweg und einen verantwortlichen Termin. Sicherheitsrelevante Fragen gehören an die dafür zuständigen Fachleute. Ein Blogartikel oder eine allgemeine Wartungsbezeichnung ersetzt keine konkrete technische und vertragliche Abstimmung.

Bei einem Umzug der Anwendung müssen diese Zuständigkeiten erneut betrachtet werden. Für den normalen Projektabschluss verbinden Sie sie mit der technischen Übergabe und einer handlungsfähigen Vertretung. So bleibt auch nach dem Go-live klar, wer aus einer Störungsmeldung einen überprüften nächsten Schritt macht.

Eine nützliche Trennung aus unserer Projektarbeit

In einem aktuellen Bestandsprojekt dokumentieren wir Entwicklungsstand, freigegebene Produktionsbasis und tatsächlich installierten Stand getrennt. Bei der Vorbereitung eines Anwendungsumzugs werden außerdem der einmalige Umzug und der laufende Betrieb als eigene Leistungen behandelt. Diese Trennung erleichtert die Abstimmung: Eine erfolgreiche Entwicklung oder ein Umzug beantwortet noch nicht, wer anschließend welche Betriebsaufgabe übernimmt.

Die Reihe: Softwareprojekte verlässlich beauftragen

Zur Übersicht der fünf Projektrisiken und Entscheidungshilfen

Verbinden Sie die fachliche Einordnung mit konkreten Projekten und dem passenden Leistungsbereich.

Themen, Projekte und Praxiswissen