Für mich als Projektleiter im Bereich Automatisierung und Integration ist der Kundensupport nur ein Teil meiner Aufgaben. Regelmäßig unterstütze ich unser insgesamt vier Personen umfassendes Support-Team bei größeren Aufgaben, zum Beispiel bei Release-Wechseln unserer verschiedenen Content Management Systeme, die wir für unsere Kunden und unsere eigenen Dokumentationsabteilungen betreiben. Hierbei werden Software-Komponenten – das können TANNER-Eigenentwicklungen sein, aber auch Third-Party-Tools und betriebssystemnahe Konfigurationen und Updates – auf eine neue Version aktualisiert. Kürzlich war das bei einem unserer größten Kunden der Fall. Wie wir dabei vorgegangen sind, schildere ich in diesem Beitrag.

Alles neu

Einen umfangreichen Support-Einsatz gab es letztens, als ein großer Teil der Basisserver eines Redaktionssystems unseres Hauptkunden erneuert wurde. Das bestehende und etablierte System war „in die Jahre gekommen“ (das Ende des Microsoft-Supports für das Server-Betriebssystem „Windows Server 2003“ hatte uns erreicht). Zusammen mit unserer IT-Abteilung und den Kollegen von der Software-Entwicklung bearbeiteten wir dieses Projekt über mehrere Monate. Vor der endgültigen Veröffentlichung testeten wir das neue System im Pilotbetrieb – unter Einbeziehung mehrerer Keyuser des Kunden – und schalteten es an einem Wochenende frei. Dutzende Anwender saßen dann am Montag vor der vertrauten Struktur ihres CMS, hatten jedoch aufgrund des Betriebssystem-Wechsels und der aktualisierten serverseitigen Citrix-Version die Hürde einer neuen Anmeldeprozedur zu nehmen. Hierfür mussten die Anwender auf ihrem eigenen System unter anderem ihren Citrix-Client aktualisieren. In Kenntnis der wenig homogenen IT-Infrastruktur auf Kundenseite (der Kunde ist weltweit tätig und wird außerdem von externen Dienstleistern unterstützt, die ebenfalls das hier erwähnte CMS nutzen) erstellten wir im Vorfeld möglichst „allumfassende“ Installationsanleitungen. Doch damit war es nicht getan.

Herr über die Ticket-Flut

Trotz der guten Vorbereitungen und der detaillierten schriftlichen Anleitungen gab es unzählige Support-Anfragen, zu deren Bewältigung ich unserem Support-Team unter die Arme griff. Die Systemanwender meldeten sich über verschiedene Wege mit ihren Zugriffsproblemen bei uns: Zum einen wurden Anfragen per E-Mail eingeschickt (was über unser Helpdesk-System in sogenannten „Tickets“ resultiert), zum anderen riefen Anwender auch direkt bei uns an. Wir verteilten dann diese verschiedenen Support-Tickets innerhalb des Teams. In solchen „Hoch-Zeiten“ ist es eine regelrechte Ticket-Flut, der wir Herr werden müssen.

Zur Bewältigung versuchen wir, konkrete Prioritäten und Verantwortlichkeiten zu definieren, um nicht den Überblick über die verschiedenen Anfragen zu verlieren. Die Anfragesteller werden möglichst rasch über den Bearbeitungsstatus informiert – zu wissen, dass sich jemand „kümmert“, ist in vielen Fällen das A und O für den Hilfesuchenden. Weiterhin versuchen wir, ähnliche Fehlerfälle zu bündeln, um nach einer exemplarischen Lösung (und sei es nur durch einen vorübergehenden Work-Around) alle derart betroffenen Anwender schnellstmöglich informieren zu können. In „erwarteten“ Krisensituationen stehen uns meistens auch die Kollegen aus der Entwicklung zur Seite, um selbst Tickets abzuarbeiten oder um Lösungen für anwendungsseitig bedingte Fehler zu erarbeiten. Fehlersuche und Problemlösung gestalten sich jedoch oftmals sehr individuell, da wir sowohl von den Anwendungsfällen, als auch von der Applikationsvielfalt her recht breit aufgestellt sind. Liegt die Lösung eines „Problems“ auf Anwenderseite und gibt es eine Wahrscheinlichkeit, dass das gleiche Phänomen nochmals auftauchen könnte, so beschreiben wir den Anwendungsfall nach Prinzip „P-U-L“ (Problem – Ursache – Lösung) möglichst allgemeingültig in den Frequently Asked Questions (FAQ) zu einer Anwendung.

Nach dem Einsatz ist vor dem Einsatz

Jede System-Aktualisierung und jede damit verbundene Ticket-Flut gehen auch irgendwann vorbei und der Stress legt sich. In diesem Fall dauerte es drei Tage, bis die allermeisten Anwender problemlos mit dem System arbeiten konnten. Das Support-Team geht nun wieder seinen nicht minder fordernden Tagesaufgaben nach, ich selbst widme mich vorwiegend wieder den Betriebsthemen und Implementierungsprojekten. Doch die nächsten Release-Termine sind bereits in Planung – und so wird das Spiel von Neuem beginnen …