Service Level Agree­ments

Betrieb, Wartung und Service für dein digitales Produkt

Individuell entwickelte Software sollte nicht nur stetig weiterentwickelt werden, sondern benötigt auch Wartung und in den meisten Fällen Support und Service. In einer sich laufend verändernden Welt, ändern sich die technischen Umgebungsvariablen, die Nutzungsanforderungen und die Erwartungen der User*innen. Betriebssysteme benötigen Backups, Zertifikate müssen erneuert werden - und unerwartete Probleme können immer wieder auftauchen. All das macht eine laufende Betreuung einer App oder Webseite zwingend. Der Umfang dieser Betreuung wird in einem Service Level Agreement definiert.

Hast du ein akutes Problem?

Hier geht’s zu unseren Kontaktinfos für Support und allgemeine Anfragen.

Die Bestandteile eines SLA

• Systemdefinition und Systemgrenzen: Um welches Produkt geht es und welche Komponenten davon werden im Agreement berücksichtigt? Z.B. Server X, Content Management System Y und Android App Z.

• Zuständigkeiten: Welche Aufgaben übernimmst du, dein Team oder deine Firma, und was macht Apps with love? Wo sind allenfalls Drittparteien zuständig? Klarheit über diese Fragen ist absolut zentral für einen effizienten Betrieb. Deshalb regeln wir das ausführlich und detailliert in einer sogenannten RACI Matrix. Diese definiert für unterschiedlichste Aspekte:

  • Wer etwas durchführt (Responsible)

  • Wer entscheidet (Accountable)

  • Wer gefragt wird (Consulted)

  • Wer informiert werden muss (Informed)

  Zusätzlich definiert diese Matrix auch, ob die zugehörigen Aufwände in einer Pauschale inkludiert sind, oder ob eine Verrechnung nach Zeit und Material (Time & Material, T&M) erfolgt.

• Reaktionszeiten im Supportfall oder bei einem sogenannten Incident: Wir definieren, wie schnell du eine Antwort von unserem Supportteam erwarten kannst und wie lange es dauert, bis wir an einer Lösung arbeiten können.

• Wie funktioniert der Supportprozess? Dazu gehört natürlich auch die Benennung von zuständigen Personen oder Teams und deren Kontaktangaben.

• Was sind die Kosten und welche zusätzlichen Optionen sind im Vertrag enthalten?

Wie wir Reaktionszeiten zusammen definieren

Im SLA wird festgehalten, welche grundsätzlichen Erwartungen in welchen Fällen gelten: Reaktionszeiten werden je nach Schweregrad einer Störung bestimmt.

Der Schweregrad setzt sich aus der Dringlichkeit und der Auswirkung der Störung auf unsere Kund*in zusammen. Die Reaktionszeiten definieren, wie viel Zeit für die jeweiligen Incidents maximal zur Verfügung steht.

Wenn sich beispielsweise eine App auf keinem Gerät mehr starten lässt, hat dies sowohl eine hohe Dringlichkeit wie auch eine hohe Auswirkung. Es handelt sich um einen Blocker Incident. Für einen Blocker wurde nun in diesem Beispiel SLA die Antwort- und Interventionszeit auf maximal 4 bzw. 8 Stunden festgelegt.

Kosten die im Betrieb, der Wartung und im Support einer digitalen Lösung entstehen

Was kostet nun also ein SLA? Die Antwort ist wie so oft: Es kommt drauf an.

Grundsätzlich hast du sehr wahrscheinlich die absolut berechtigte Erwartung, dass wir auch für dich und dein Produkt da sind, wenn die initiale Entwicklung erstmal abgeschlossen ist. Gleichzeitig ist es weder in unserem noch im Interesse unserer Kund*innen, dass ein ganzes Projektteam nur rumsitzt und darauf wartet, ein Problem in einem Produkt zu lösen, das ja hoffentlich gar nicht erst auftritt. Deshalb braucht es einen Mittelweg zwischen «nach Abschluss des letzten Entwicklungssprints sind alle weg» und «wir finanzieren ein Produktteam das den ganzen Tag nichts zu tun hat». Dieser Mittelweg heisst «Bereitschaft». 

Bereitschaft ist eine wesentliche (Kosten-) Komponente im SLA und stellt sicher, dass wir ein Supportteam beschäftigen können, das sich um alle Supportanliegen kümmern kann. In diesem Bereich kommt es auf die Zeit an: Sollen möglich alle Supportfälle innerhalb kürzester Zeit angegangen werden und das im Notfall auch am Wochenende, ist das teurer, als wenn es auch mal ein bisschen dauern kann.

Der zweite Kostenfaktor betrifft das System selbst. Ins Gewicht fallen:

• Welche Komponenten es gibt (Backend, APIs & Schnittstellen, CMS, Frontends, etc.)

• Wie umfangreich die Lösung ist. Stichworte dazu: Komplexität, Daten, Anzahl User*innen

• Welche Systeme eingesetzt werden und welche Kosten diese verursachen. Fast immer wird ein Server in der Cloud benötigt und für diesen braucht es dann wiederum einen Überwachungsdienst. Weitere externe Dienste, die oft im Einsatz sind, und etwas kosten: E-Mail-Versender, Authentifizierungs-Services, Spam- und Fraud-Prevention, Zahlungsdienstleister etc.

Der dritte Faktor, der mit dem zweiten zusammenhängt, sind die Erwartungen an unseren Service. Als Beispiel: In praktisch allen unseren SLAs für native Apps ist enthalten, dass wir im Sommer die App auf den Beta Versionen von Google’s Android und Apple’s iOS testen und identifizieren, was allenfalls angepasst werden muss, bevor die neuen Generationen der Betriebssysteme im Herbst veröffentlicht werden. Wenn du das selber machen kannst und willst: Go for it! Dein SLA wird günstiger, allerdings liegt die Verantwortung für das Funktionieren der App nach dem OS-Update dann natürlich bei dir.

Support und Optionen sind der letzte Faktor: Aufgrund unserer Erfahrung machen wir einen Vorschlag, mit wie viel Supportaufwand zu rechnen ist, und inkludieren ein entsprechendes Kontingent im Vertrag. Wie viel das ist, ist stark abhängig vom jeweiligen Produkt oder Projekt.

Nimmt man diese vier Faktoren zusammen, kann man als Faustregel mit einem jährlichen Aufwand von rund 5% bis 15% der ursprünglichen Entwicklungskosten rechnen. Konkretes Beispiel: Wenn die Entwicklung deiner App 100’000 Franken gekostet hat, kannst du davon ausgehen, dass sich die Kosten für Wartung, Betrieb und Support im Bereich von 5’000 bis 15’000 Franken jährlich bewegen.

Was einige unserer Kund*innen auch praktisch finden: Wir halten im Vertrag ein gewisses Budget frei für Optionen. Das gibt etwas Flexibilität, um auch einmal eine kleinere Änderung, im Software-Jargon «Change» genannt, pragmatisch umsetzen zu können, ohne dafür einen Offering- / Auftrags- / Einkaufs- / Bestellprozess starten zu müssen. Wir richten uns dabei ganz nach deinen Wünschen und besprechen diese gerne mit dir!

Kann Apps with love mein Produkt betreiben, auch wenn ich es woanders habe entwickeln lassen?

Jein. Um wirklich Verantwortung übernehmen zu können, müssen wir ein Produkt im Detail verstehen. Wir lernen dich und dein Produkt gerne kennen. Dafür ist ein Code-Review meistens der erste Schritt. 

Melde dich bei uns, wenn du mehr über Support und Betrieb durch Apps with love Wissen möchtest, oder wir dich unterstützen können!