Startseite > Blog-Artikel > 10 Anmerkungen zu externen Software-Support-Konstellationen

10 Anmerkungen zu externen Software-Support-Konstellationen

Eine typische Konstellation beim Betrieb komplexer, ganz oder teilweise individualisierter Software-Systeme sieht folgendermaßen aus: Der Software-Hersteller oder ein zwischengeschalteter Integrator übernimmt die Installation des Systems (oder der Systeme) und der Kunde sorgt für den Normal-Betrieb und kümmert sich um bekannte sowie Umgebungs-Probleme. Die vom Betriebs-Team des Kunden nicht behebbaren Fehler werden an den Software-Hersteller oder Integrator zur Behebung weitergegeben.
Diese dafür vom Kunden eingekaufte Dienstleistung wird in Software-Support-Verträgen, einer spezielle Form von Service Level Agreements (SLA) bzw. von Underpinning Contracts (UC), beschrieben.

Zur Erstellung eines entsprechenden Vertrages können die üblichen, im Service Level Management beschriebenen, Aspekte herangezogen werden. Es gibt jedoch einige Punkte, auf die dabei und bei der Zusammenarbeit in dieser Konstellation besonderes Augenmerk gelegt werden sollte:

  1. Trennung von Incident und Problem Management – Der nach meinem Eindruck häufigste Fehler in der o.g. Konstellation ist, Incidents und Problems zu vermischen. Sie werden in der Kommunikation zwischen Kunde und Dienstleister irrtümlich als eins behandelt (Incidents werden nach der Beseitigung der Störung und Wiederherstellung des Betriebs als Problem oder gar Bug-Meldung weiterverwendet). Dies erschwert die korrekte Priorisierung und sonstige Attributierung der Vorgänge, die nicht ohne Grund laut ITIL unterschieden werden. Hatte ein Incident beispielsweise allerhöchste Priorität, hat die Behebung des zugrundeliegenden Fehlers möglicherweise niedrige Priorität, da ein Workaround bekannt ist und der Fehler nur sehr selten auftritt. Zudem sind die zu einer Bug-Meldung benötigten Informationen andere als die eines Incidents oder Problems. Eine Bündelung von mehreren Incidents mit gemeinsamer Ursache ist so nicht möglich.
    Der Vertrag sollte daher auch in dieser Konstellation klar zwischen Incidents und Problems unterscheiden und die Service Levels getrennt beschreiben.
    Manche Kunden sind der Meinung, dass es zu jedem Incident eine Root Cause Analysis und damit ein Problem geben muss. Der Vertrag sollte dies möglichst ausschließen, Problem-Ticket-Zombies sowie Diskussionen und Schwierigkeiten bei der Bewertung der SLA-Erfüllung sind sonst die Folge.
  2. Verantworlichkeit bei der Incident-Analyse – Gibt es einen Second Level Support für die Anwendung im Haus des Kunden, so muss der Vertrag klar und detailliert beschreiben, welche Verantwortlichkeit diesem bei der Incident-Analyse zufallen. Diese Beschreibung, z.B. in Form einer Checkliste, kann auch aus dem Vertrag ausgegliedert und darauf verwiesen werden.
    Eine solche Checkliste enthält die bei Incidents zu sammelnden Informationen und kann sich je nach Incident-Kategorie unterscheiden. Typische Punkte darauf sind: Log-Dateien (ggf. nach Höhersetzen des Log-Levels), Configurations-Dateien, Status-Berichte von Datenbanken, Beispiel-Daten zur Reproduktion des Fehlers.
    Der Vertrag sollte klar festhalten, welche beteiligte Partei für das Sammeln der Informationen zuständig ist (Hol- oder Bringschuld). Dies kann je nach Priorität des Tickets unterschiedlich geregelt sein.
    Ist der Dienstleister für das Sammeln zuständig, muss klar sein und festgehalten werden, dass dazu für ihn ein entsprechender (Remote-)Zugang zu den produktiven Systemen vom Kunden bereitgestellt sein muss.
  3. Ticket-Priorität und Änderungen – Die Kriterien zur Ermittlung der Priorität eines Tickets sollen möglichst klar und eindeutig beschrieben werden und die dabei verwendeten Begriffe müssen selbstsprechend sein. Verwenden Sie statt Formulierungen wie „Ausfall eines Systems“ oder „Ausfall eines Service“ besser spezifische, zu der betroffenen Software passende Definitionen (z.B. „Schnittstelle XY nicht erreichbar“ oder „Funktion XY nicht verfügbar“). Sie können natürlich auch „System“ und „Service“ eindeutig definieren.
    Neben dieser Beschreibung ist festzulegen, wer die Priorität bestimmt („nur der Kunde“ oder „Kunde und Dienstleister gemeinsam“) und ob und wie diese Priorität ggf. geändert werden kann (wer darf ändern, wer muss zustimmen, zu welchem Zeitpunkt im Leben des Tickets darf geändert werden).
  4. Kennzahlen, Reporting und Dashboards – Bei der Festlegung der SLA-relevanten Kennzahlen und der vertraglich notwendigen Berichte gilt es zu beachten, dass die zugrundeliegenden Daten im gewählten Ticket-System erfasst und auch entsprechend ausgewertet werden können. Sind die Daten vorhanden und können die Kennzahlen automatisch berechnet werden, so lässt sich oft ein Teil der zu liefernden Berichte einsparen, indem der Kunde zugriff auf ein Dashboard erhält, welches ihm auf Wunsch stets die relevanten Werte anzeigt.
    Achten Sie auf einfache, nachvollziehbare Berichts-Definitionen. Klären Sie, wann Tickets in den SLA-Auswertungen auftauchen: wenn sie geschlossen wurden oder wenn sie ihre Ziel-Zeiten erreicht oder verfehlt haben. Letzteres führt zu Problemen, wenn sich die Priorität eines Tickets ändert oder sich z.B. bei Problem-Tickets erst in der späteren Ursachen-Analyse herausstellt, dass dieses Problem gar nicht vom Vertrag abgedeckt ist.
    Achten Sie bei der Definition der Kennwerte für Vertrags-Strafen darauf, dass diese eindeutig ermittelt werden können und die Werte und Formeln zu den erwarteten oder sich verändernden Ticket-Zahlen passen.
  5. System-Abnahmen oder Voraussetzungen für den Support – Welchen Bedingungen hinsichtlich Hardware, Betriebssystem, Anbindung, sonstiger Software etc. müssen Systeme genügen, die unter diesen Support-Vertrag fallen? Gibt es klare Kriterien, „zertifizierte“ Standard-Konfigurationen oder Abnahme-Verfahren? Betreibt der Kunde Systeme mit stark unterschiedlicher Auslastung und gibt es für diese verschiedenen System-Größen unterschiedliche Anforderungen? Sind die Kriterien, anhand derer eine System-Größe bestimmt wird, klar definiert und allen bekannt? Was passiert, wenn mit neueren bzw. zukünftigen Versionen der eingesetzten Software die Anforderungen wachsen?
    All diese Fragen sollten möglichst im Vorfeld einer Software-Support-Beziehung geklärt und bei Bedarf im Vertrag oder in verwiesenen Dokumenten (z.B. einem Sizing Guide) festgehalten werden.
  6. Anzahl unterstützter Anwendungs-Versionen – Gibt es mehrere Installationen der Software im Haus des Kunden, so passiert es häufig, dass es auch viele unterschiedliche Versionen und Patch-Level gibt. Für die zugehörige Code-Basis ist es schwer einen guten und stabilen Support zu bieten. Je weniger unterschiedliche Installationen es gibt, desto einfacher ist deren Betrieb und Pflege.
    Der Vertrag sollte auf dieses Problem eingehen und beispielsweise eine Höchstzahl an unterstützten Versionen nennen. Zudem ist es wichtig festzuhalten, ob Patches auf allen Systemen installiert werden müssen, um die Voraussetzung für den Support zu erhalten.
  7. Patch oder nächste Version – Aus Sicht des Problem Management gilt ein Problem als gelöst, wenn die Ursache erkannt und behoben ist. Im Zusammenhang mit Software-Support kann nun die Lösung in einen Patch oder eine neue Version einfließen. Aus Sicht des Kunden ist der Patch meist interessanter, da er eine schnellere Verfügbarkeit bedeutet. Ein Patch bedeutet jedoch eine weitere Verzweigung der Code-Basis und damit höheren Aufwand beim Software-Lieferanten.
    Klären Sie diesen Punkt im Vorfeld der Support-Beziehung. Meist lassen sich unterschiedliche Anforderungen (also ob ein Patch nötig ist oder auf eine neue Software-Version gewartet werden kann) über die unterschiedliche Priorisierung von Problem Tickets abbilden und regeln.
  8. Eindeutige Zeitangaben – Die Angaben für die Zeiten, z.B. zur Wiederherstellung eines Service oder zur Lösung eines Problems, sollten eindeutig und frei von Interpretations-Möglichkeiten sein.
    Achten Sie darauf, dass aus dem Vertragstext klar hervorgeht, was gemeint ist: „Kalendertage“ ist eindeutiger als einfach nur „Tage“. Wird der Begriff „Arbeitstage“ verwendet, so muss klar definiert werden, was als Arbeitstag anzusehen ist. Auch die Einheit von „Monat“ ist mehrdeutig, „60 Kalendertage“ ist klarer als „2 Monate“.
    Steht bereits ein Ticket-System fest oder wird ein solches evaluiert, ist es wichtig, dass die im Vertrag verwendeten Angaben von dem System berechnet und nachvollzogen werden können.
  9. Ein Vertrag kann nicht alles regeln! – Bei jedem Punkt eine Vertrages sollten Sie überlegen, ob der Aufwand zur Erstellung einer möglichst eindeutigen, gegebenenfalls sogar rechtssicheren Formulierung lohnt oder ob man den Punkt offen lässt und darauf baut, dass dies in der Zusammenarbeit geklärt wird. Der Vertrag sollte möglichst viele Punkte erwähnen, kann aber zu einzelnen eine Formulierung wie „wird bei Bedarf zwischen den Vertragspartnern verhandelt“ enthalten.
    Letzteres funktioniert natürlich nur, wenn das Klima zwischen den Parteien während der Vertragslaufzeit stimmt. Stimmt es nicht, würde dies jedoch auch ein besser formulierter Vertrag nicht ändern, dann wird ohnehin gestritten.
    Und das führt zu meinem letzten Punkt…
  10. Kommunikation – Auch in der hier beschriebenen Konstellation ist das entscheidende Moment die Kommunikation. Achten Sie darauf, dass – unabhängig vom Vertrag – ein möglichst konstruktiver und partnerschaftlicher Austausch zwischen den beteiligten Support-Teams stattfindet. Gegebenenfalls muss dieser Austausch moderiert oder durch regelmäßige Treffen unterstützt werden.
    Ziel sollte sein, dass die Parteien sich gegenseitig als hilfreiche Partner ansehen und Schwierigkeiten gemeinsam angehen anstatt sich gegenseitiges Verschulden vorzuwerfen und Verantwortung wegzuschieben.
    Hier greifen je nach Situation diverse Team-Unterstützungs- oder Moderations-Methoden über die ich hier in meinem Blog berichte(t habe).
Advertisements
  1. Es gibt noch keine Kommentare.
  1. No trackbacks yet.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: