Managed Application Support und Wartung
Software, die bereits live ist, am Laufen halten, innerhalb Ihres SLA und Ihrer Ticket-Warteschlange: Triage, Fixes an der Ursache, Patch-Releases, Upgrades von Abhängigkeiten und Plattformen, Sicherheitsreaktion und Incident-Bearbeitung. Second- und Third-Level-Support durch Entwickler, die auch bauen, sodass ein wiederkehrender Fehler behoben statt neu gestartet wird.
Warum das ein Partnerproblem ist
Support ist der Teil eines Managed Service, der sich leicht verkaufen und schwer besetzen lässt. Er fällt ungleichmäßig an, er braucht Menschen, die unter Zeitdruck unbekannten Code lesen können, und sobald Sie Ihre besten Entwickler darauf setzen, stehen sie für die besser bezahlte Arbeit nicht mehr zur Verfügung. Die übliche Antwort ist eine separate, billigere Stufe, die Tickets schließt, ohne je etwas zu beheben, und der Kunde bemerkt es innerhalb eines Quartals.
Unsere Antwort ist, dass die Personen im Support Entwickler sind. Sie können das System ändern und nicht nur beschreiben, und nur so hört ein wiederkehrender Incident je auf, wiederzukehren.
Was wir tragen
Triage und Diagnose
Aufnehmen, was der First-Level-Support nicht beantworten kann, es reproduzieren und sagen, was tatsächlich falsch ist, statt es als nicht reproduzierbar zu schließen.
Fixes, die halten
Defekte, an der Ursache behoben, mit einem Regressionstest gegen die ganze Fehlerklasse statt gegen das eine Ticket, sodass derselbe Incident nicht im nächsten Quartal wiederkommt.
Releases und Patching
Patch-Releases, über Ihre Pipeline und nach Ihrem Change-Prozess ausgeliefert, mit Abhängigkeiten, Framework-Versionen und Plattform-Laufzeiten, die aktuell gehalten werden, statt in eine Upgrade-Krise zu driften.
Sicherheitsreaktion
Eine veröffentlichte Sicherheitswarnung zu etwas, wovon Sie abhängen, ist ein unbedingter Grund zum Upgrade und kein Backlog-Eintrag. Wir verfolgen sie, patchen sie und sagen Ihnen, wie hoch das Risiko war.
Monitoring und Incidents
Die bereits vorhandenen Alerts beobachten, die ergänzen, die es geben sollte, und Incidents bearbeiten, mit einem schriftlichen Bericht danach, was passiert ist und was verhindert, dass es wieder passiert.
Kleine Änderungen
Der stetige Strom kleiner Verbesserungen, der einen Kunden zufrieden hält und nie ein Projekt rechtfertigt: innerhalb derselben Kapazität und zu denselben Bedingungen erledigt.
Ihr SLA, ehrlich bewertet
Wir veröffentlichen keine Reaktions- und Lösungsziele, denn eine Zahl, die erfunden wurde, bevor jemand Ihr System gesehen hat, ist für Sie und Ihren Kunden wertlos. Stattdessen lesen wir das SLA, das Sie bereits schulden, sagen Ihnen, welche Teile wir tatsächlich tragen können und welche Abdeckung das erfordert, und legen uns dann schriftlich darauf fest.
Dasselbe gilt für die Abdeckung außerhalb der Arbeitszeiten. Wo ein Auftrag sie braucht und wir sie vorab vereinbart haben, wird sie von Menschen besetzt, die für diese Zeiten rekrutiert oder eingesetzt wurden, statt jemanden aufzuwecken und zu hoffen. Wir arbeiten in anderen Aufträgen bereits zu europäischen, australischen und US-pazifischen Zeiten, die Frage ist also, welches Zeitfenster Sie brauchen, nicht ob es möglich ist.
Ein System übernehmen, das wir nicht gebaut haben
Das ist der Normalfall. Bisher neun Übernahmen, die älteste geschrieben im Jahr 2008.
Zuerst eine rein lesende Prüfung
Wir erhalten Zugang zum Code, zur Infrastruktur und zur Ticket-Historie, bevor wir für irgendetwas davon verantwortlich sind, und wir schauen, statt zu ändern.
Eine schriftliche Risikoliste
Was fragil ist, was ungepatcht ist, was undokumentiert ist und was nachts jemanden aufweckt, geordnet nach Auswirkung auf die Produktion. Gehört Ihnen, ob wir weitermachen oder nicht.
Das Gespräch über die Abdeckung
Wir lesen das SLA, das Sie Ihrem Kunden schulden, und sagen Ihnen ehrlich, welche Teile wir tragen können, welche Zeiten das erfordert und was es kostet, bevor eine Seite etwas unterzeichnet.
Übergabe, dann live
Eine festgelegte Einarbeitungsphase mit demjenigen, der das Wissen jetzt hat, dann übernehmen wir die Warteschlange. Hat niemand mehr das Wissen, beginnen wir stattdessen mit der Risikoprüfung.
Unter Ihrem Namen, wenn das die Vereinbarung ist
Support ist meist der sichtbarste Teil eines Managed Service, deshalb ist er auch der Ort, an dem White-Label am meisten zählt. Unsere Entwickler können aus Postfächern und Konten arbeiten, die Sie ausstellen, in Ihrem Ticketsystem antworten und Incident-Berichte schreiben, die Sie unverändert weiterleiten; Ihr Kunde hat durchgehend mit Ihnen zu tun. Die White-Label-Entwicklung beschreibt, wie das gestaltet wird, und sie gilt für den Support in genau derselben Weise.
Wie Support kalkuliert wird
Pro Person, monatlich, sodass Ihre eigenen Kosten planbar sind und Sie Ihrem Kunden einen Supportvertrag dagegen kalkulieren können. Alle erfassen ihre Zeit in unserem eigenen Portal, Sie sehen die Stunden den ganzen Monat über, und dieselben Zahlen erzeugen die Rechnung, sodass es einen Nachweis gibt, gegen den beide Seiten abstimmen.
Wo Support neben der Neuentwicklung steht, bilden die beiden meist einen Delivery Pod statt zweier Verträge, sodass ruhige Wochen auf der einen Seite die arbeitsreichen auf der anderen bezahlen.
Fragen zu Support-Vereinbarungen
Was umfasst Managed Application Support?
Software, die bereits produktiv läuft, am Laufen halten: Eingänge in der Queue triagieren, Fehler reproduzieren und beheben, technische Fragen beantworten, die der First Level nicht klären kann, Patch-Releases ausliefern, Abhängigkeiten und Plattformversionen aktuell halten, Alarme beobachten und Störungen bearbeiten, wenn etwas ausfällt. Das ist Arbeit im Second und Third Level; Ihr First Level bleibt, wo er ist.
Arbeiten Sie nach unserem SLA?
Ja. Wir veröffentlichen keine Reaktions- und Lösungszeiten, weil eine Zahl, die erfunden wird, bevor man Ihr System kennt, nichts wert ist. Wir lesen das SLA, das Sie Ihrem Kunden bereits schulden, sagen Ihnen ehrlich, welche Teile wir tragen können und welche Abdeckung dafür nötig wäre, und sagen das dann schriftlich zu.
Können Sie Support außerhalb der Geschäftszeiten oder Rufbereitschaft leisten?
Ja. Support außerhalb der Geschäftszeiten und Rufbereitschaft werden vorab vereinbart, in den Supportbedingungen festgehalten und von Personen besetzt, deren Arbeitszeiten dazu passen, sodass eine nächtliche Störung jemanden in der Schicht erreicht und nicht jemanden, der aus dem Schlaf geholt wird.
Können Sie ein System betreuen, das Sie nicht gebaut haben?
Das ist der Normalfall. Bisher gab es neun Übernahmen, die älteste wurde 2008 geschrieben. Der Support eines übernommenen Systems beginnt mit einer Prüfung ohne Schreibzugriff und einer schriftlichen Liste von Risiken, geordnet nach Auswirkung auf die Produktion. Die ersten Wochen dienen also dazu zu verstehen, wofür Sie tatsächlich verantwortlich sind, statt unter Druck zu raten.
Werden dieselben Personen, die das System betreuen, es auch weiterentwickeln?
Ja, und genau das ist der Punkt. Die Ingenieure im Support sind Ingenieure und keine separate Ebene, die Tickets schließt, sodass ein wiederkehrender Vorfall an seiner Ursache behoben werden kann, statt jeden Montag neu gestartet zu werden. Wo Sie bei uns sowohl einen Build- als auch einen Support-Strang haben, teilen sich beide Code-Reviews und Architekturentscheidungen.
Wie wird Support berechnet?
Pro Person und Monat, sodass Ihre eigenen Kosten planbar sind und Sie einen Supportvertrag für Ihren Kunden dagegen kalkulieren können. Die Stunden werden in unserem Portal erfasst und sind für Sie den ganzen Monat über sichtbar, und dieselben Zahlen erzeugen die Rechnung, sodass es für beide Seiten eine einzige Quelle gibt.
Sie haben Systeme am Laufen zu halten?
Nennen Sie uns, welche Systeme es sind, was Ihr SLA verspricht und wo der Support derzeit wehtut. Wir lesen es und sagen Ihnen, welche Teile wir tragen können, auch die, die wir nicht tragen können.