Service Level Agreement für Software und Web-Apps: was ein Wartungsvertrag regeln muss

Ein Service Level Agreement (SLA) ist die Vereinbarung, die festhält, welche Leistung ein Anbieter beim Betrieb und bei der Wartung einer Software schuldet, und zwar so, dass man sie nachmessen kann: Wie schnell wird auf eine Störung reagiert? Wie viele Stunden darf das System im Monat ausfallen? Wer spielt Sicherheitsupdates ein, wer macht Backups, und wie schnell ist nach einem Datenverlust alles wieder da? Und was passiert mit Quellcode und Daten, wenn die Zusammenarbeit endet?

Für eine einfache Website ist das meist überschaubar; was dort an Wartung anfällt, haben wir in WordPress-Wartung: was sie pro Jahr wirklich kostet aufgeschlüsselt. Dieser Artikel geht einen Schritt weiter: Er richtet sich an KMU, bei denen eine eigene Web-App, ein Kundenportal oder eine Betriebssoftware im Alltag mitläuft. Dort hängt am Betrieb nicht nur die Sichtbarkeit, sondern der Umsatz.

Warum Individualsoftware ein SLA braucht

Standardsoftware bringt ihr SLA mit. Wer ein Abo bei einem grossen Anbieter abschliesst, akzeptiert dessen Bedingungen, ob er sie liest oder nicht. Bei Individualsoftware ist es umgekehrt: Es gibt nichts Vorgefertigtes. Wenn niemand etwas vereinbart, gilt im Ernstfall das, was beide Seiten aus der Erinnerung an ein Gespräch rekonstruieren.

Dazu kommt ein zweiter Punkt. Software altert, auch wenn niemand an ihr arbeitet. Bibliotheken bekommen Sicherheitslücken, Browser ändern ihr Verhalten, Zahlungsanbieter und Schnittstellen stellen alte Versionen ab. Wer nichts tut, sammelt technische Schuld an, und die wird irgendwann auf einen Schlag fällig, meist in einem ungünstigen Moment. Ein SLA macht diese laufende Arbeit sichtbar und planbar, statt sie dem Zufall zu überlassen.

Und schliesslich geht es um Ehrlichkeit bei den Kosten. Die Entwicklung ist nur ein Teil dessen, was eine Software über ihre Lebensdauer kostet. Wer eine Offerte ohne Betriebs- und Wartungsteil vergleicht, vergleicht nicht die Gesamtkosten. Mehr dazu, welche Posten bei Software in der Schweiz anfallen, steht auf unserer Seite Software-Kosten Schweiz.

Die Checkliste: was ein Wartungsvertrag regeln muss

1. Reaktionszeiten nach Schweregrad

Nicht jede Störung ist gleich dringend. Ein Tippfehler im Footer ist etwas anderes als ein Kundenportal, in das sich niemand mehr einloggen kann. Ein brauchbares SLA teilt Störungen deshalb in Stufen ein und hängt an jede Stufe eine eigene Frist.

Wichtig sind drei Begriffe, die oft vermischt werden. Die Reaktionszeit ist die Frist, bis jemand die Störung bestätigt und anfängt. Die Lösungszeit ist die Frist, bis das Problem behoben oder umgangen ist. Die Servicezeit legt fest, wann die Uhr überhaupt läuft, etwa werktags von 8 bis 18 Uhr. Eine Reaktionszeit von vier Stunden mit Servicezeit «werktags» heisst: Eine Störung am Freitagabend wird frühestens am Montagmorgen bearbeitet. Das kann völlig in Ordnung sein, man sollte es aber wissen.

Ebenfalls in den Vertrag gehört, wer eine Störung melden darf und wie. Eine Telefonnummer für kritische Fälle und ein Ticketsystem für alles andere sind ein bewährtes Muster. Wer per WhatsApp an eine Privatnummer meldet, hat im Streitfall keinen Beleg.

2. Verfügbarkeit: was die Prozente wirklich bedeuten

Verfügbarkeit wird fast immer in Prozent angegeben. Die Zahlen liegen nahe beieinander, die erlaubten Ausfälle nicht.

Die Werte sind reine Rechnung auf Basis eines durchschnittlichen Monats von gut 730 Stunden. Welcher Wert sinnvoll ist, hängt am Geschäft: Für ein internes Planungstool, das nur zu Bürozeiten genutzt wird, reichen andere Werte als für eine Buchungsstrecke, über die nachts Anfragen hereinkommen. Höhere Verfügbarkeit kostet mehr, weil sie Redundanz, Überwachung und Bereitschaft voraussetzt.

Mindestens so wichtig wie die Zahl ist die Messregel:

• Was zählt als Ausfall? Nur «Seite lädt nicht» oder auch «Login funktioniert nicht»?
• Wo wird gemessen? Ein externer Monitoring-Dienst, der die Anwendung regelmässig aufruft, ist neutraler als die Logdateien des Anbieters.
• Sind Wartungsfenster ausgenommen? Das ist üblich, sollte aber begrenzt sein, etwa auf angekündigte Fenster ausserhalb der Kernzeiten.
• Über welchen Zeitraum? Monatlich oder jährlich gerechnet ergibt bei gleichem Prozentwert sehr unterschiedliche Spielräume.

Leicht übersehen wird: Die Verfügbarkeit einer Web-App hängt auch am Hosting. Wenn Entwickler und Hoster zwei verschiedene Firmen sind, braucht es zwei abgestimmte Zusagen oder eine Seite, die die Verantwortung für beide übernimmt.

3. Updates und Sicherheit

Software besteht zum grössten Teil aus fremden Bausteinen: Frameworks, Bibliotheken, Datenbanktreiber. Für jeden davon erscheinen laufend Updates, einige davon sicherheitsrelevant. Das SLA sollte klären:

• Wie oft werden reguläre Updates eingespielt, zum Beispiel monatlich oder quartalsweise?
• Wie schnell werden kritische Sicherheitslücken geschlossen, sobald sie bekannt sind?
• Wer testet nach einem Update, ob die wichtigsten Abläufe noch funktionieren, und wie ist das dokumentiert?
• Was ist im Pauschalbetrag enthalten und was nicht? Ein Update auf eine neue Hauptversion eines Frameworks kann tagelange Arbeit bedeuten. Viele Verträge rechnen das separat ab, was legitim ist, solange es vorher klar ist.

Eine gute Faustregel: Kleine Updates gehören in die Pauschale, grosse Umbauten werden offeriert. Wer das nicht trennt, streitet spätestens beim ersten Versionssprung.

4. Backups und Wiederherstellung

Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Backup. Im SLA gehören deshalb nicht nur die Sicherung, sondern die Wiederherstellung und ihre Fristen geregelt. Zwei Fachbegriffe helfen dabei:

• RPO (Recovery Point Objective): Wie viele Daten dürfen im schlimmsten Fall verloren gehen? Bei täglicher Sicherung sind es bis zu 24 Stunden.
• RTO (Recovery Time Objective): Wie lange darf es dauern, bis das System nach einem Totalausfall wieder läuft?

Dazu gehören der Speicherort der Backups (getrennt vom Produktivsystem, idealerweise bei einem anderen Anbieter), die Aufbewahrungsdauer und ein regelmässiger Wiederherstellungstest mit kurzem Protokoll. Wie man Backups und Ausfallsicherheit grundsätzlich aufbaut, beschreibt der Artikel Backups und Ausfallsicherheit. Wo personenbezogene Daten liegen, spielt zudem das Datenschutzgesetz hinein: Der Vertrag sollte festhalten, in welchem Land Daten und Backups gespeichert werden.

5. Exit: Quellcode, Daten und Übergabe

Das ist der Punkt, der beim Vertragsabschluss am wenigsten Beachtung bekommt und im Ernstfall am meisten zählt. Irgendwann endet jede Zusammenarbeit, freundschaftlich oder nicht. Dann muss klar sein:

• Wem gehört der Quellcode, und wo liegt er? Ein Repository auf dem Konto des Kunden, auf das der Anbieter Zugriff hat, ist sauberer als umgekehrt.
• Welche Zugänge gehören dem Kunden: Domain, Hosting, Datenbank, E-Mail-Versand, Zahlungsanbieter, App-Store-Konten?
• In welchem Format werden die Daten übergeben, und innerhalb welcher Frist?
• Welche Dokumentation gehört zur Übergabe, damit ein neues Team weiterarbeiten kann?
• Wie lange unterstützt der bisherige Anbieter den Übergang, und zu welchem Satz?

Ohne diese Regelung entsteht Vendor-Lock-in nicht durch böse Absicht, sondern durch Bequemlichkeit: Alles läuft auf den Konten des Anbieters, weil das beim Start schneller ging. Wie man Eigentum an Code und Daten von Anfang an richtig aufsetzt, beschreibt Wem gehört eigentlich die Website?.

Was sonst noch hineingehört

Neben den fünf Kernpunkten tauchen in guten Wartungsverträgen regelmässig diese Themen auf:

• Monitoring und Berichte: Bekommt der Kunde regelmässig einen kurzen Bericht über Verfügbarkeit, eingespielte Updates und offene Störungen? Ein Bericht pro Quartal reicht oft.
• Kontingent für Anpassungen: Kleine Änderungen fallen immer an. Ein festes Stundenkontingent pro Monat oder Quartal verhindert, dass jede Kleinigkeit einzeln offeriert werden muss.
• Konsequenzen bei Nichteinhaltung: Gutschriften auf die Pauschale, Sonderkündigungsrecht oder ein Eskalationsweg. Bei kleinen Verträgen ist eine klare Eskalation oft nützlicher als komplizierte Gutschriftmodelle.
• Mitwirkungspflichten des Kunden: Ein SLA gilt in beide Richtungen. Wer Zugänge nicht liefert oder Störungen nicht meldet, kann keine Fristen einfordern.
• Laufzeit und Kündigung: Mindestlaufzeit, Kündigungsfrist und was mit dem Exit-Prozess passiert, wenn gekündigt wird.

Ein Beispiel: die Reservations-App eines Restaurants

Ein konkretes Szenario macht die Abwägung greifbar. Nehmen wir ein Restaurant, das Reservationen über die eigene Website annimmt und sie per Push-Benachrichtigung aufs Handy bekommt, so wie wir es für Han Kitchen in Zürich-Oerlikon gebaut haben. Dort kommt jede Reservation und jede Kontaktnachricht sofort als Push aufs Handy, zusätzlich geht eine E-Mail ans Restaurant, und der Gast wird mit einem Tipp per WhatsApp bestätigt.

Welche Punkte würde man für ein solches System im SLA besonders gewichten?

• Kritisch ist alles, was verhindert, dass Reservationen ankommen: Formular defekt, Push und E-Mail fallen beide aus. Hier zählt eine schnelle Reaktion auch am Abend und am Wochenende, weil dann der meiste Betrieb ist.
• Hoch ist ein Ausfall nur der Push-Benachrichtigung, solange die E-Mail weiterläuft. Der doppelte Weg ist hier bereits Teil der Ausfallsicherheit.
• Backups betreffen vor allem die gespeicherten Reservationen und Kontaktdaten. Ein Tag Datenverlust wäre ärgerlich, aber verkraftbar, ein RPO von 24 Stunden kann also reichen.
• Exit heisst: Domain, Hosting und Code liegen auf Konten, die dem Restaurant gehören.

Die Gewichtung wäre bei einem internen Planungstool, das nur werktags genutzt wird, eine völlig andere. Genau deshalb gibt es kein Standard-SLA, das für alle passt.

Häufige Fehler in Wartungsverträgen

• Nur Prozent, keine Messregel. 99,9 Prozent ohne Definition von Ausfall und Messpunkt sind kaum durchsetzbar.
• Reaktionszeit verwechselt mit Lösungszeit. «Wir reagieren innerhalb von zwei Stunden» heisst nicht, dass das Problem in zwei Stunden gelöst ist.
• Backups ohne Wiederherstellungstest. Das Problem zeigt sich erst, wenn es zu spät ist.
• Alle Zugänge beim Anbieter. Bequem beim Start, teuer beim Wechsel.
• Pauschale ohne Leistungsbeschreibung. Wer «Wartung pauschal» bezahlt, weiss nicht, was er bekommt, und der Anbieter weiss nicht, was er schuldet.
• SLA für den Code, aber nicht für die Abhängigkeiten. Externe Dienste wie Zahlungsanbieter, E-Mail-Versand oder Karten haben eigene Bedingungen. Das SLA sollte klarstellen, wofür der Anbieter einsteht und wofür nicht.

Wie wir das bei DLM Digital handhaben

Den Unterhalt rechnen wir nach effektivem Aufwand oder über ein monatliches Stundenkontingent ab, getrennt von der Entwicklung, damit beide Teile einzeln verglichen werden können. Repository, Datenbank und Hosting laufen von Anfang an auf den Konten des Kunden, wir arbeiten darin als Eingeladene. Welche Reaktionszeiten und welche Verfügbarkeit sinnvoll sind, besprechen wir am konkreten System, weil ein Kundenportal mit Rechnungen andere Anforderungen hat als ein internes Werkzeug. Wer gerade eine Eigenentwicklung plant, findet die Grundlagen auf unserer Seite zu Individualsoftware in der Schweiz; wer erst prüfen will, ob sich die Software überhaupt lohnt, beginnt besser mit einem Prototyp zur Validierung ab CHF 10'000.

Fazit

Ein Service Level Agreement für Software muss nicht lang sein, aber messbar. Reaktionszeiten nach Schweregrad, eine Verfügbarkeit mit klarer Messregel, geregelte Updates, Backups mit getesteter Wiederherstellung und ein durchdachter Exit decken das Wesentliche ab. Wer diese fünf Punkte vor der Unterschrift klärt, vermeidet die meisten Konflikte, die im Betrieb von Individualsoftware entstehen, und behält die Kontrolle über ein System, an dem das eigene Geschäft hängt.