Zwischen der ersten und zweiten technischen Supportlinie

Wie oft haben Sie Anwendungsadministratoren getroffen, die sich gerne mit der Lösung von Vorfällen befassen?

Darüber hinaus sind die sogenannten Geschäftsvorfälle, dh Vorfälle, die entweder mit einer Verletzung der Logik des Geschäftsprozesses im Service oder mit falschen Aktionen des Benutzers verbunden sind, ein wesentlicher Fluss von Vorfällen in der zweiten Supportlinie.

Wir konnten diese Funktionalität so weit wie möglich aus der zweiten Zeile entfernen und sie an ein separates Team übertragen, das sich aus den Mitarbeitern der ersten technischen Support-Zeile zusammensetzt.

Wir werden Ihnen erzählen, wie wir das gemacht haben und auf welche Schwierigkeiten wir in diesem Artikel gestoßen sind.

Traditionell befasste sich die zweite Linie des technischen Supports mit der Lösung von Vorfällen auf Systemen, die den Service selbst unterstützen, Produktkonfigurationseinstellungen vornehmen, Testumgebungen durchführen, das System überwachen, Patches installieren, an Bereitschaftsschichten teilnehmen usw. Die Lösung von Vorfällen in diesen Teams wurde häufig von einem „Restprinzip“ begleitet (es sei denn, dies ist natürlich ein Vorfall mit kritischer Priorität). In den meisten Fällen passen sie jedoch in die zugewiesenen SLAs.

Als wir erkannten, dass viele der Vorfälle (und auf der Vorderseite der Systeme - hinter jedem) möglicherweise das Problem des Kunden der Bank sein könnten, beschlossen wir, den Zeitaufwand für die Bearbeitung dieser Anfragen zu minimieren, begannen jedoch nicht mit der Erhöhung der Anzahl der Supportteams, sondern mit der Analyse der einzelnen Phasen dieses Prozesses.

Der traditionelle Unterstützungsprozess bei der Bank wurde nach dem klassischen Schema aufgebaut und sah wie folgt aus


Abb. 1 Schema der Organisation des Unterstützungsprozesses (war)

Die Anfrage, die über die erste, zweite und dritte Unterstützungslinie ging, wurde in folgenden Anteilen zwischen ihnen verteilt: 15:75:10.

Die erste Leitung - Service Desk - Empfangen, Verarbeiten und Weiterleiten von Anrufen über die folgenden Kommunikationskanäle:

• Telefon - 8% der Gesamtzahl der Anrufe
  Self-Service-Portal - 83% der Gesamtzahl der Anrufe
  E-Mail - 4% der Gesamtzahl der Anrufe
  Chat-Bot in Viber und Telegramm - 5% der Gesamtzahl

Die erste Zeile befasst sich auch mit der Remote-Lösung von Vorfällen an den Arbeitsstationen der Benutzer und ermöglicht den Zugriff auf die Informationssysteme der Bank. Ich habe über die Arbeit dieser Einheit in einem separaten Artikel geschrieben - Link hier

Die zweite Zeile - Wartungsteams für Anwendungssoftware + Infrastruktur + DBA + ...,

Die dritte Zeile sind Entwicklungsteams.

Da Bankensysteme miteinander integriert sind, ist das Auftreten eines Vorfalls in einem der Systeme häufig das Ergebnis eines Fehlers, der in einem anderen System aufgetreten ist. Und Fehler auf den „Backup-Systemen“ treten hauptsächlich auf der „Vorderseite“ auf und wirken sich direkt auf die Benutzer aus.

Die Identifizierung der Hauptursache des Auftretens erfordert in diesem Fall die Teilnahme mehrerer Begleitteams und infolgedessen eine Reihe von Routings.

Bei einer Stichprobe von Vorfällen über mehrere Monate und der Analyse ihres Lebenszyklus stellten wir fest, dass sie den größten Teil ihres Lebens in der Schlange verbringen und auf eine Analyse durch einen Mitarbeiter eines Second-Line-Supportteams (manchmal bis zu 80%) warten, wobei sie regelmäßig zwischen Teams und einem langen Team neu zugewiesen werden Korrespondenz im Hauptteil der Anfrage.

Bei der Analyse und Analyse dieser Vorfälle haben wir festgestellt, dass Kollegen zur Behebung von Integrationsfehlern Informationen aus benachbarten Integrationssystemen (Protokolle, Auswirkungsanalysen usw.) benötigen, an die sie sich gegenseitig wenden und Vorfälle weiterleiten.

Um die Zeit für die Lösung von Vorfällen zu minimieren, haben wir uns als Pilotprojekt entschlossen, ein funktionsübergreifendes integriertes Team von First- und Second-Line-Mitarbeitern zur Lösung von Vorfällen in den Frontsystemen der Bank zu bilden - Internetbanking, Mobile Banking, Nachrichtenversanddienste (SMS und Push) + Hauptfront - Bank Office System.

Dieser Befehl liegt zwischen der ersten und der zweiten Zeile - eineinhalb Unterstützungszeilen, die wir "Frontline" genannt haben.

Bereits in der Phase der Bildung dieses Teams stießen wir auf bestimmte Schwierigkeiten, auch von Seiten der Manager der zweiten Linie. Die Übertragung von nur einem Mitarbeiter auf dieses Projekt aus jedem der Systeme bedeutete eine Verringerung des Kapitals des aktuellen Teams. Und die Second-Line-Mitarbeiter selbst, die am Pilotprojekt teilnehmen sollten, waren nicht bestrebt, sich kopfüber mit der Lösung von Vorfällen zu befassen.

Durch iterative Verhandlungen konnten wir uns darauf einigen, dass die Hauptaufgabe der Zweitlinien-Teilnehmer an diesem Projekt darin besteht, Erstlinien-Mitarbeiter zu schulen, gemeinsam eine gemeinsame Wissensbasis zu schaffen, interne Interaktionsprozesse aufzubauen, den erforderlichen Zugang bereitzustellen und dann schrittweise zu ihren Mitarbeitern zurückzukehren Einheiten.

Der Standort des Frontline-Standorts war das IT-Center der Bank in Obninsk.

Die erste Aufstellung der anderthalb Unterstützungslinien war wie folgt:

• zwei First-Line-Support-Mitarbeiter
• zwei Mitarbeiter der Front Office System Support Group
• zwei Mitarbeiter der Selbsthilfegruppe Internetbanking und Mobile Banking
• ein Mitarbeiter der Kundeninformationsdienst-Supportgruppe (SMS & Push)

Das Hauptaugenmerk des Teams lag auf 3 Indikatoren:

• GESCHWINDIGKEIT - 70% der beim Team eingegangenen Anfragen müssen in nicht mehr als 8 Arbeitsstunden gelöst werden
• MENGE - Das Team kann nicht mehr als 20% der Anfragen an die zweite Support-Leitung weiterleiten
• QUALITÄT - Der Anteil der von Benutzern wiederentdeckten Vorfälle sollte 3% nicht überschreiten.

Abb. 2 Prozess zur Behandlung von Vorfällen an vorderster Front

Die nächste Schwierigkeit, auf die wir zu Beginn des Piloten stießen, war das Fehlen eines Teams in unserem anfänglichen Verständnis, falls vorhanden.

Trotz der Tatsache, dass sich Frontline-Mitarbeiter in der Nähe im selben Raum befanden, gab es keine Versuche, auf funktionsübergreifende Funktionen, Erfahrungsaustausch und signifikante Interaktion im Inneren umzusteigen. Jeder Teilnehmer konzentrierte sich nach wie vor darauf, Anfragen über sein System zu lösen. Daher war jemand mit Vorfällen „übersät“, jemand war eindeutig freier.

Es wurde beispielsweise beschlossen, die Systeme innerhalb des Teams zu ändern, damit der Vertreter des Internetbanking-Supports keine Vorfälle auf seinem System mehr löst, sondern Anfragen für das Front-Office-System verarbeitet, und der Vertreter des Front-Office-System-Supports beginnt, Vorfälle bei Benachrichtigungsdiensten usw. zu lösen. d.

Warum?

1. Versuchen Sie, universell zu werden, damit die Mitarbeiter zwischen Vorfällen verschiedener Systeme wechseln können, um die Last gleichmäßig auf alle Teilnehmer zu verteilen.
2. Stellen Sie den Kindern ausreichende Kenntnisse über verwandte Systeme zur Verfügung, damit sie die Ursache des Integrationsfehlers schnell identifizieren können.
3. Stellen Sie die Kommunikation innerhalb des Teams her.

Die erforderlichen Konten erstellt, Zugriff auf die Anwendungs- und Datenbankprotokolle bereitgestellt und vieles mehr! :) :)

Anfangs wurde die Auflösung von Vorfällen reduziert. Es ist klar, dass dies keine leichte Aufgabe ist, wenn Sie die Feinheiten des Systems nicht kennen und auch Vorfälle darauf lösen müssen. Aber die Jungs wandten sich aneinander, um Hilfe zu erhalten, die allgemeine Wissensbasis zu studieren und zu aktualisieren, und nach und nach ging es weiter.

Außerdem begannen wir jeden Tag zu Beginn eines jeden Arbeitstages, kleine Stand-Ups in der Nähe der Blätter, die wir an die Wände geklebt hatten, und mit täglichen Indikatoren zu halten. Wir diskutierten und beendeten sie mit einem Marker, freuten uns über ihre Implementierung oder diskutierten den Grund für den Fehler, wenn wir sie nicht erreichen konnten.

Anschließend haben wir diese Blätter natürlich durch Online-Dashboards ersetzt.


Abb. 3 Frontline-Effizienz-Dashboard

An dieser Stelle möchte ich mich ganz besonders beim Leiter des Supportteams für das Front-Office-System der Bank bedanken, der die Führungsrolle übernommen und die Entwicklung des Teams von innen heraus gefördert hat - Alexey, danke! :) :)

In den ersten zwei Monaten konnte das Team die gesetzten Ziele nicht erreichen, der Schulungsprozess war noch nicht abgeschlossen, die Wissensbasis wurde aktualisiert.

Ab dem dritten Monat des Pilotprojekts haben wir begonnen, uns in die Ziele einzufügen, und nach 6 Monaten haben wir sogar begonnen, diese zu übertreffen.


Abb. 4 Frontline-Pilotprojekt, erste Indikatoren

Es wurde schnell klar, dass der Pilot erfolgreich „gestartet“ war, und es war ratsam, das Projekt zu skalieren.

Allmählich fingen wir an, dem Team Kompetenzen in anderen Systemen hinzuzufügen, Zweitlinienmitarbeiter abzuziehen und Mitarbeiter vom Service Desk hinzuzufügen.

Allmählich wechselten wir zu „T - Cross-Funktionalität“, als jedem Teilnehmer ein Hauptsystem und zwei benachbarte zugewiesen wurden.


Abb. 4 Vergleichende Statistiken für 2018 zum Zeitpunkt der Lösung von Anfragen zwischen Frontline- und Second-Line-Tracking-Teams

Im Jahr 2018 schloss das Frontline-Team mehr Vorfälle als jede andere Escort-Einheit der Bank. Die Jungs haben die festgelegten Ziele deutlich übertroffen und erneut gezeigt, dass Teamwork und funktionsübergreifende Kompetenzen signifikante Ergebnisse erzielen können.

Für die zweite Unterstützungslinie ist „Frontline“ heute ein zuverlässiger „Schutzschild“, der den Anruffluss zu ihnen erheblich reduziert.


Abb. 5 Anzahl und Anteil der in Frontline (Abb. - Team1) gelösten Vorfälle im Verhältnis zu den in der zweiten Zeile gelösten Vorfällen für alle Bankensysteme

Heute sind alle Frontline-Teilnehmer Mitarbeiter des Service Desk, die Vorfälle auf den wichtigsten Frontsystemen der Bank lösen und festgelegte Ziele erreichen.

Außerdem ist „Frontline“ der nächste Schritt für Service Desk-Mitarbeiter in unserer Karriereleiter, bevor sie zur zweiten Support-Linie wechseln.