Softwarewartung und Betrieb mit festen Reaktionszeiten

Eine Software ist am Tag der Abnahme fertig, ihr Umfeld nicht: Betriebssysteme, Bibliotheken, App-Stores und Browser ändern sich weiter, und jede dieser Änderungen kann ein laufendes Werkzeug treffen. Softwarewartung und Betrieb halten eine Anwendung über Jahre lauffähig und sicher: mit Sicherheits-Updates, täglichen Sicherungen, Überwachung und einem Ansprechpartner, der bei einer Störung in vereinbarter Zeit reagiert.

in2bit übernimmt auf Wunsch Softwarewartung und Betrieb: Reaktion nach Störungsklasse in 4, 8 oder 24 Stunden, tägliche verschlüsselte Backups 60 Tage mit Restore-Tests, getrennte Staging- und Produktivumgebung, gehostet auf ISO-27001-zertifizierten Servern in Deutschland, auch für Software, die ein anderer Anbieter, ein früherer Mitarbeiter oder ein schnell aufgesetztes Werkzeug hinterlassen hat, nach einer Prüfung auf Schadcode und offene Schwachstellen. Die Auftragsverarbeitung nach Art. 28 DSGVO gehört zum Vertrag.

Warum schnell gebaute Werkzeuge ohne Wartung zum Risiko werden

Ein Werkzeug zu bauen ist heute schnell erledigt: Ein Formular, eine kleine Datenbank, ein Dashboard entstehen in Tagen, oft mit KI-Unterstützung und ohne dass jemand aus der IT beteiligt war. Das ist zunächst ein Gewinn. Das Problem beginnt danach. Solche Werkzeuge bestehen zu einem großen Teil aus fremden Bausteinen: Bibliotheken, Frameworks, Anmeldediensten, Server-Software. Jeder dieser Bausteine bekommt Sicherheits-Updates, läuft irgendwann aus oder ändert sein Verhalten. Wird nichts nachgezogen, bleiben bekannte Lücken offen, und die Anwendung steht mit Kundendaten im Netz, ohne dass es jemand bemerkt.

Dazu kommt der Wissensverlust: Wer das Werkzeug gebaut hat, ist nach zwei Jahren vielleicht nicht mehr im Haus, und eine Dokumentation gab es nie. Und ohne geprüfte Sicherung lässt sich nach einem Serverausfall nichts wiederherstellen. Keines dieser Probleme spricht gegen schnelle Werkzeuge. Es spricht dafür, von Anfang an zu klären, wer sie betreibt, wer Updates einspielt und wer im Störfall erreichbar ist.

Ein Beispiel: Ein Ingenieurbüro lässt sich von einem Mitarbeiter ein Werkzeug für die Projektzeiten bauen, in wenigen Wochen, mit KI-Unterstützung, auf einem gemieteten Server. Es funktioniert, alle gewöhnen sich daran, der Mitarbeiter wechselt den Arbeitgeber. Ein Jahr später kündigt der Anbieter einer verwendeten Bibliothek den Support auf, ein Server-Update schlägt fehl, die Anmeldung geht nicht mehr, und eine Sicherung gibt es nur vom ersten Tag. Der Weg heraus: Code und Zugänge werden gesichtet, das System wird auf Schadcode und offene Lücken geprüft, danach läuft es in einem Wartungsvertrag mit täglichen Sicherungen, planbaren Updates über eine Staging-Umgebung und einem Ansprechpartner für Störungen. Das Werkzeug bleibt im Einsatz, die Daten liegen gesichert, und die nächste Änderung an Server oder Bibliothek ist ein geplanter Schritt statt eines Ausfalls.

Was Softwarewartung und Betrieb umfassen

Wartung und Betrieb stehen bei in2bit in einem eigenen Wartungsvertrag mit festen Leistungspaketen. Je nach Paket gehören dazu:

• Hosting auf ISO-27001-zertifizierten Servern in Deutschland, mit Auftragsverarbeitung nach Art. 28 DSGVO.
• Überwachung von Erreichbarkeit und Sicherheit, damit eine Störung auffällt, bevor sie jemand meldet.
• Sicherheits-Updates für Server, Frameworks und Bibliotheken, einschließlich der Beobachtung, wann ein Baustein ausläuft.
• Tägliche verschlüsselte Backups, 60 Tage vorgehalten, mit regelmäßigen Restore-Tests.
• Getrennte Staging- und Produktivumgebung, damit jede Änderung geprüft ist, bevor sie Ihre Mitarbeiter erreicht.
• Pflege der Store-Einträge und Anpassung an neue iOS- und Android-Versionen bei Apps.
• Weiterentwicklung im vereinbarten Kontingent, wenn der Bedarf wächst, und Skalierung der Server, wenn Nutzer oder Standorte dazukommen.

Auf Wunsch gibt es außerdem Schulungen für Ihr Team, auch für neue Kollegen, und telefonischen Support für Sie und Ihre Mitarbeiter bei Fragen zur Software oder zu den Geräten. Welche Pakete Sie brauchen, hängt davon ab, wie wichtig die Anwendung im Alltag ist. Ein internes Werkzeug für eine Abteilung braucht anderes als ein System, mit dem mehrere Standorte täglich arbeiten. Beides lässt sich abbilden, und beides steht mit Umfang und Preis im Angebot.

Störungsklassen und Reaktionszeiten

Nicht jede Störung ist gleich dringend. Im Wartungsvertrag sind deshalb Störungsklassen vereinbart, und für jede Klasse eine Reaktionszeit: Reagiert wird je nach Klasse in 4, 8 oder 24 Stunden. Dazu kann der Vertrag ein Verfügbarkeitsziel festlegen. Ein Ausfall, der die Arbeit im Betrieb stoppt, hat Vorrang vor einem Darstellungsfehler, der nur stört. Die Reihenfolge im Störfall ist festgelegt: Zuerst läuft Ihr System wieder, danach wird die Ursache geklärt und dauerhaft behoben. Für Fehler, die auf die Entwicklung von in2bit zurückgehen, gilt das ohnehin.

Gemeldet wird eine Störung bei einem Ansprechpartner, der Ihr Projekt kennt. Was eine Störungsklasse ist und welche Reaktionszeit dazugehört, steht im Vertrag, damit beide Seiten im Ernstfall nicht diskutieren, sondern handeln. Beim Vergleich von Angeboten lohnt ein Blick auf den Unterschied zwischen Reaktionszeit und Behebungszeit: Die erste sagt, wann sich jemand kümmert, die zweite, wann das System wieder läuft. Beides gehört benannt.

Der Wartungslauf: Sicherung, Update, Funktionsprüfung

Updates werden nicht eingespielt, sobald sie erscheinen, sondern in einem festen Lauf mit fester Reihenfolge. Am Anfang steht die Sicherung des aktuellen Stands. Dann wird das Update auf der Staging-Umgebung eingespielt, einer Kopie des Produktivsystems, die kein Mitarbeiter benutzt. Dort wird geprüft, ob Anmeldung, Schnittstellen und die wichtigsten Abläufe noch funktionieren. Erst wenn diese Prüfung bestanden ist, geht die Änderung auf das Produktivsystem. Schlägt sie fehl, bleibt das Produktivsystem unverändert, und die Sicherung ist der Rückweg. Dieser Lauf gilt für Sicherheits-Updates ebenso wie für neue Versionen von Framework oder Datenbank und, bei Apps, für die Anpassung an neue Betriebssystem-Versionen. Für Sie bedeutet das: Updates sind planbar, ein fehlgeschlagenes Update erreicht Ihre Mitarbeiter nicht, und der Stand vor jeder Änderung ist jederzeit wiederherstellbar.

Bestehende Software übernehmen, weiterentwickeln oder ablösen

Viele Anfragen beginnen nicht mit einer neuen Software, sondern mit einer vorhandenen, um die sich niemand mehr kümmert. Typische Fälle:

• Die Agentur, die das System oder die Website samt Webserver gebaut hat, gibt es nicht mehr oder sie antwortet nicht.
• Der Entwickler, der es allein betreut hat, geht in Rente oder verlässt das Unternehmen.
• Eine App oder ein Prototyp ist halbfertig, und das Team, das ihn begonnen hat, kommt nicht weiter.
• Eine über Jahre gewachsene Access- oder Excel-Anwendung ist am Limit und trägt trotzdem einen Kernprozess.

Am Ende einer Übernahmeprüfung steht eine von drei Aussagen: unverändert weiterbetreiben, schrittweise modernisieren oder ganz ablösen und die Bestandsdaten in ein neues System übernehmen. Davor liegen drei Schritte: die Sichtung von Quellcode, Dokumentation und Zugängen, wenn möglich im Gespräch mit dem bisherigen Entwickler, danach ein Scan auf Schadcode und offene Schwachstellen und zuletzt die Einarbeitung in das, was gefunden wurde. Ob eine Übernahme gelingt, entscheidet sich an dieser Prüfung, nicht an einer Zusage davor. Deshalb gibt es sie nur unter Voraussetzungen, und der Preis für den Betrieb folgt erst danach.

Was kostet der laufende Betrieb einer Software?

Der Betrieb hat einen festen Monatspreis. Er ergibt sich aus den gewählten Paketen: Hosting, Überwachung, Sicherungen und Sicherheits-Updates bilden den Sockel, dazu kommt das Kontingent für Support und Weiterentwicklung. Jeder Posten steht einzeln im Angebot. Nachforderungen für Leistungen, die dort nicht stehen, gibt es nicht. Wer eine Software von einem anderen Anbieter betreiben lassen will, bekommt den Preis nach der Prüfung, weil erst dann klar ist, wie viel Pflege das System braucht. Welche Kostenblöcke im Betrieb typischerweise anfallen und welche Faustregel Orientierung gibt, steht im Beitrag über die laufenden Kosten einer Software.

Wie der Wartungsvertrag zustande kommt

Bei einer Software aus eigener Entwicklung liegt das Angebot für den Betrieb zur Abnahme vor. Ob Sie es annehmen, entscheiden Sie. Bei fremder Software geht die Prüfung voraus, danach folgt das Angebot. Der Vertrag selbst regelt die Leistungspakete, die Störungsklassen mit ihren Reaktionszeiten, die Auftragsverarbeitung nach Art. 28 DSGVO und den Fall, dass die Zusammenarbeit endet: Dokumentation und Datenexport in offenen Formaten werden vorab im Wartungsvertrag vereinbart, damit Ihre Software auch ohne in2bit betreibbar bleibt. Für öffentliche Auftraggeber ist Vertragsgestaltung auf EVB-IT-Grundlage möglich.

Wie das im Alltag aussieht, zeigt ein laufendes Projekt: Die mehrsprachige Verwaltungs-App eines sozialen Trägers läuft für mehrere Standorte im Betrieb auf ISO-27001-zertifizierten Servern in Deutschland, angebunden an Behördensysteme. Was im laufenden Betrieb für den Zugriffsschutz gilt, steht auf der Seite Sicherheit und Compliance.