„Die kritische Phase beim Service Enabling für eine Lösung entsteht, wenn sie nach der Entwicklungsphase in neue Verantwortlichkeiten gelangt“, erläutert Andreas Selchow, Berater bei Ardour Consulting. Die Fachseite sei dafür nicht in die Pflicht zu nehmen, sondern es sei Aufgabe der Anwendungsbetreuung, für den operativen Betrieb zu sorgen. „Dies ist ohne eine klare konzeptionelle Planung des Supports nicht möglich, trotzdem wird bei der Übernahme der Lösung von der Entwicklung häufig darauf verzichtet“, beschreibt Selchow eine zentrale Ursache für spätere Probleme.
Ausgangspunkt für eine solche Konzeption ist für ihn die Sichtung aller von der Entwicklungsabteilung übermittelten Projektdokumentationen. Sie müssen nach den Erfordernissen der Anwendungsbetreuung erweitert werden, indem die bereit gestellten Dokumentationen auf Veränderungen gegenüber der bisherigen Lösung analysiert werden. „Dafür sind die Datenstrukturen und Schnittstellen ebenso wie die Anwendungsfälle und Datenflüsse zu betrachten, aber auch die Veränderungen bei den prozessualen Bedingungen und Zuständen der Anwendungen müssen analysiert werden“, beschreibt der Ardour-Consultant die Aufgabenstellung. Basis für den Vergleich seien die Informationen in den Manuals, Architektur- und weiteren Dokumentationen.
Dabei sind seinen Empfehlungen nach verschiedene Fragen zu beantworten:
•Welche Konsequenzen ergeben sich für die tägliche operative Arbeit aus den Veränderungen?
•Was muss sich in der Bearbeitung von Störungen und Funktionserweiterungen ändern?
•Wie können Tickets, die mit der neuen Lösung (neuer Kunde, neue Anwendung) in Verbindung stehen, schnell und korrekt zugeordnet werden?
•Wo befinden sich die für die Störungsbehebung notwendigen Spezifikationen?
Die sich aus den Veränderungen ergebenden Konsequenzen für die tägliche Arbeit müssen in die Handbücher bzw. Manuals eingearbeitet werden. Vorteilhaft ist eine Zusammenfassung in Form eines Foliensatzes, der auch Informationen zu den operativen Abteilungen etwaiger externer Provider berücksichtigt. „Der Kern des Support-Konzepts ist eine vollständige und widerspruchsfreie Beschreibung des Störungsbeseitigungsprozesses, des Prozesses für Funktionserweiterungen und der Vorgehensweisen in der Problembehandlung“, erläutert Selchow. Dies bezieht er auf die Prozessstruktur und Überwachung der Performance mit Hilfe passender Kennzahlensysteme sowie auf den Einsatz prozessunterstützender Tools.
Darüber hinaus müssten auch die Kommunikations- und Meetingstrukturen im laufenden Betrieb dargestellt werden. Auch die Einrichtung eines Change Advisory Boards (CAB), das den Change Manager bei der Bewertung, Festlegung von Prioritäten und zeitlichen Planungen unterstützt, kann sich nach den Erfahrungen von Selchow in der Praxis als vorteilhaft erweisen. Zudem empfiehlt er, Workshops mit den Key-Usern der Fachabteilungen, dem Projektleiter und ggf. Service-Provider zu organisieren. „Darin können mit besonderer Beachtung der organisatorischen Schnittstellen die konkreten Prozesse durchgespielt und im Vorweg mögliche Probleme ermittelt werden.“
Er weist noch auf einen weiteren wesentlichen Aspekt hin, der sich aus dem Support-Konzept ableitet. Er betrifft die Fragestellung, welche Änderungen sich für die Service-Levels und Service-Kennzahlen ergeben. „Welche Relevanz sich darin verbirgt, zeigt das Beispiel eines Unternehmens, das seine Gehaltsabrechnung an einen Service-Provider ausgelagert hat.“ Die operativen Konsequenzen seien, dass Reklamationen der Fachabteilung via Help- Desk (1st Level Support) und Anwendungsbetreuung (2nd Level) an den Service-Provider (3rd Level) weitergereicht werden. „In diesem Fall gelten nicht mehr die üblichen Reaktions- und Lösungszeiten für den Second-Level-Support, sondern die für den Third-Level-Support, was neue SLA-Vereinbarungen notwendig macht“, betont Selchow.
