Der Analytical Operator verändert die Service-Welt: Application Management – Teil 2
IT Service Management wurde in der Vergangenheit oft missverstanden als „Telefondienst“, was die gängigen Vokabeln belegen: Backoffice, Call-Center, Support-Hotline. Doch mit all diesen Funktionen können wir uns bei GFT nicht identifizieren. Wir haben einen anderen Fokus: Wir sorgen für den Kunden, dass sein System dauerhaft gut funktioniert. Insgesamt nennen wir dieses Angebot GFT Application Management. Wichtige Teile davon sind root cause analysis und continuous improvement –Serviceleistungen, die dazu dienen die Stabilität des betreffenden IT-Systems nachhaltig zu fördern.
Das Ziel sollte also nie sein, besonders viel Volumen an Incidents und Problems zu bearbeiten. Ganz im Gegenteil: Wenn die Applikationsexperten die Volumentreiber herausgefunden haben, können sie analysieren: Warum ist das so? Ein Incident, also eine wie auch immer geartete Störung, ist nur ein Symptom, beschreibt aber nicht die Ursache. Und diese ist nicht unbedingt nur an einer Stelle zu finden. Spätestens in Cloud-Umgebungen sind multidimensionale Systeme mit APIs, Interfaces und Containern im Einsatz – und man braucht jemanden, der eine ganzheitliche Sicht darauf hat, da die Entwickler meist auch nur spezialisierte Elemente bauen. Diese Aufgabe fällt dem Team Maintenance/Betrieb zu.
Definition des Analytical Operators
Neben dem operativen Umgang mit Incidents – also dem klassischen IT Service-Management – haben wir bei GFT eine innovative Rolle geschaffen, die wir bei allen Kunden etablieren: Wir machen strukturierte Analysen dazu wo Häufungen auftreten, versuchen Ursachen zu finden, die überall gleich sind und Maßnahmen zur Verbesserung zu ergreifen. Dieser Rolle haben wir einen Namen geben, sie nennt sich „Analytical Operator“. In der Systematik von ITIL, dem Standard im Bereich IT Service-Management, ist diese Aufgabe im Bereich Service Analytics als analytische Bearbeitung der Incident-Fälle beschrieben.
Was macht einen Analytical Operator aus? Er muss die Fachdomäne „Service“ beherrschen, sich also mit Incidents auskennen. Zugleich muss er ebenfalls ein tiefes technisches Verständnis und ausgeprägte Analyse-Kompetenzen haben. Nur wenn dieser Dreiklang gegeben ist, hat das Modell Aussicht auf Erfolg. Im Falle von GFT ist der Operator kein Tool, sondern ein Mensch mit besonderer Expertise. Einen großen Teil seiner Zeit verbringt er damit Bildschirme zu beobachten, die – ähnlich wie in einem Kontrollzentrum der NASA – komplexe Daten von Frontend, Backend und Infrastruktur an einer Stelle sammeln. Das geschulte Auge sieht, welche Häufungen existieren und korreliert diese mit den Incidents.
Grundsätzliche Muster erkennen
Das Ziel des Analytical Operators ist durch das Erkennen von Mustern, vorhersagen zu können, wo als nächstes welche Art von Problem auftreten wird. Dabei werden alle Teilaspekte, wie Infrastrukturkomponenten, Schnittstellen oder einzelne Elemente (etwa eine Maschine, Cloud oder Applikation) untersucht, die Einfluss auf das Gesamtsystem haben.
Der Operator ist nicht am Umgang mit konkreten Incidents beteiligt, ist also nicht der Experte, der angerufen wird, um Forensik zu betreiben. Ganz im Gegenteil: Er ruft selbst an und berichtet, sobald er Veränderungen bemerkt, die in Problemen kulminieren könnten. Sein Ziel ist es Muster zu erkennen, um damit drei Dinge zu tun: Erstens bekommt der Product Owner die Informationen, um das System verbessern zu können. Zweitens werden die operativen Servicekräfte vorgewarnt. Drittens dokumentiert der Analytical Operator seine Erkenntnisse, um überprüfen zu können, ob Veränderungen eintreten. Er ist also ein zentraler Dienstleister für alle Beteiligten, eine Art Single Source of Truth.
Der Operator wird von GFT aktuell beispielsweise in die Smart Factory eines großen Maschinenbauers integriert. Er betrachtet dort nicht nur Applikationen, also Software, sondern das Gesamtsystem mit all seinen Datenpunkten, sprich: die gesamte Fabrik. Bei einem anderen Kunden wird dieses System für die Bestellstrecke von Automobilen und verbundenen Dienstleistungen genutzt und hat geholfen das Incidentvolumen drastisch zu reduzieren und die Systemstabilität zu verbessern.
Das Beste aus zwei Disziplinen: Data Analytics und IT Service-Management
Die Etablierung des Operators ist eine Kombination aus den GFT Lösungen in den Bereichen Data Analytics und IT Service-Management. Letztere Disziplin kämpft mit dem Vorurteil, lediglich prozessual am Umgang mit Incidents interessiert zu sein, da analytisches Vorgehen im Bereich Service nicht etabliert ist. Auf der anderen Seite fehlt den Data-Analysten häufig das direkte Feedback, das im Service ersichtlich wird. GFT arbeitet mit einem Hybrid aus beiden Disziplinen, so dass Mustererkennung und Fachdomäne zusammenkommen.
Was hat der Kunde davon? Er bekommt direkten Mehrwert aus der Fläche zur Verbesserung seiner Software im Sinne der kontinuierlichen Verbesserung (continuous improvement). Eine strukturierte Methodik verschafft ihm Transparenz um herauszufinden, was sich an der Produktqualität verbessern lässt. Gleichzeitig wird er effizienter in seinen Prozessen und kann seinen Personaleinsatz besser steuern.
Aktiv nachgefragt wird der Einsatz des Operators allerdings nicht – weil die Kunden diese Leistung schlicht nicht kennen und erwarten. Die Rolle liefert jedoch unmittelbare Ergebnisse durch die Nutzung vorhandener Daten. Durch unsere Herangehensweise helfen wir erstens dem Service-Manager, der mehr Transparenz in sein System bekommt, zweitens dem Manager für das Gesamtsystem, der die Verantwortung für die Systemverfügbarkeit und -Funktion trägt, drittens dem Product Owner, der ein besseres Produkt bauen kann – und schlussendlich auch dem Umsatz der Gesamtfirma.
Einsatz von KI-Lösungen für automatisierten Support
Der Operator ist eine personifizierte Form von vorausschauender Wartung. In Zukunft wird er immer stärker durch künstliche Intelligenz (KI) unterstützt – aber vermutlich noch lange nicht ersetzt werden. Derzeit sollen die Analysen des Operators möglichst viele Incidents verhindern. Passieren sie doch, untersuchen die GFT Experten sehr genau, warum es so weit kommen konnte und füttern ein automatisiertes System mit diesen Informationen. Die Nutzung von KI kann dabei die Verarbeitungsprozesse beschleunigen und zu echter Predictive Maintenance führen, einer Kombination aus Mustererkennung, darauf aufbauenden Alerts mit Schwellwerten und automatisierten Korrelationsanalysen. Das ist die höchste Ausbaustufe.
Der Einsatz von KI hat auch Einfluss auf die Softwareentwicklung, denn nun müssen auch Daten für den Service bereitgestellt werden. Das heißt: Es müssen Indikatoren bekannt sein, an denen sich erkennen lässt, ob das System gesund ist. Die KI-gesteuerte Predictive Maintenance ist das große Ziel vieler Softwareanbieter und -nutzer. In einer idealen Welt muss niemand mehr mit dem System selbst interagieren und potenzielle Probleme lösen sich von selbst, bevor sie sichtbar werden. Das ist eine komfortabel klingende Vision. Doch was ist der Enabler, um dorthin zu kommen? Voraussetzung ist, dass die Daten verstanden werden, und zwar aus der Perspektive von zwei Fachdomänen, IT und Service. Niemand verbindet dieses Wissen besser als der Analytical Operator.
Erfahren Sie mehr in Teil 1 der Application Management Blogserie.
.webp "Mann vor Bildschirm mit Grafiken – Key Visual für Application Management")
.webp "Mann vor Bildschirm mit Grafiken – Key Visual für Application Management")
