Wie ein Dienstanbieter seinen Service Desk durchgeführt hat

Hallo allerseits! Ich heiße Alexey Volkov. Zusammen mit meinem Kollegen, dem Entwickler Alexander Solovyov (auch v ), führen wir interne Webdienste in DataLine durch. In diesem Herbst haben wir unseren Service Desk eingeführt, um BMC Remedy zu ersetzen. In einem Beitrag werde ich Ihnen erklären, warum wir eine vorgefertigte Lösung abgelehnt und alles selbst gemacht haben.


Durchschnittlich 450 Anwendungen werden pro Tag über den Service Desk gesendet.

Was hat Remedy uns nicht gefallen?

Ich fing fast sofort an, Remedy zu üben, als ich zu DataLine kam. Nach wiederholten Versuchen, es unter unseren Aufgaben zu beenden, entschieden wir uns, unseren Service Desk zu machen. Hier ist eine nicht ganz so kurze Liste von Gründen, warum wir beschlossen haben, das Remedy Action Request System von BMC aufzugeben:

Unbequeme Schnittstelle. Um eine Anwendung zu registrieren, sie zum Laufen zu bringen und ihre Erlaubnis zu notieren, mussten wir 100500 Klicks machen.


Seite mit dem Vorfall. Nehmen Sie mindestens die Felder für den Inhalt der Nachricht, die in einem speziellen Fenster geöffnet werden mussten.


Eine ganze Kaskade von Registerkarten muss geöffnet werden, um eine Lösung zu schreiben oder den Vorfall an einen anderen Executor weiterzuleiten.

Die Integration mit anderen Client-Schnittstellen und Verbesserungen deuteten sogar auf Tänze mit einem Tamburin hin. Proprietäre Software gab es fast keinen Handlungsspielraum. Die einzigen Lücken waren Webdienste, die wussten, wie man mit Remedy kommuniziert, aber sie waren sehr launisch und instabil. Wir haben einige Dinge komplett manuell und ungeschickt erledigt: Ich erinnere mich, wie wir das Hochladen von Berichten über Vorfälle mithilfe von Auswahlen aus der Datenbank konfiguriert haben.

Natürlich gab es noch einen anderen Weg: einen Auftragnehmer einzustellen und jede Laune zu erfüllen. Zu dieser Zeit gab es nur einen Auftragnehmer auf dem Markt für diese Software, und er wusste davon. Die Produktionsprozesse werden angepasst und Verbesserungen wären ständig erforderlich. In diesem Sinne erwies sich der Preis als unmenschlich und begann bei 5 Millionen.

Nicht genug Lizenzen. Zu Beginn von DataLine haben wir 100 Lizenzen gekauft. Seitdem ist das Unternehmen exponentiell gewachsen. Lizenzen konkurrierten. Zunehmend kam es zu Situationen, in denen ein Ingenieur auf die Freigabe der Lizenz warten musste, um seine Arbeit zu erledigen. Eigentlich war dies der letzte Strohhalm.

Behebung aller Vorfallaktionen . Wir wollten, dass sich alles, was mit dem technischen Support unserer Kunden zu tun hat, im Service Desk widerspiegelt. Abhilfe schaffen in der Tat nur aufgezeichnete Anfragen. Alle eigentlichen Arbeiten an dem Vorfall wurden in der Postkorrespondenz, telefonisch, im Raucherzimmer durchgeführt - überall, aber nicht bei Remedy. Vor allem, wenn es sich um eine komplexe Anwendung handelte, an der Spezialisten aus verschiedenen Abteilungen beteiligt waren. Sie haben das Problem gelöst, aber bei Remedy gab es keine Spur davon. Infolgedessen wurde der Vorfall in Fragmenten dokumentiert und erschien manchmal überhaupt nicht in Remedy. Es war sehr schwierig, etwas zu kontrollieren, zu verstehen und zu analysieren.

Service Desk 2.0

Abhilfefunktionen waren leicht zu ersetzen. Die Hauptaufgabe des neuen Service Desks besteht darin, alle Aktivitäten des technischen Supports in ein Fenster zu ziehen: Kontakte, Arbeitskorrespondenz, Dokumente. Wir wollten eine Art Protokollierung von allem, was passiert, nachdem ein Kunde eine Anwendung zur Unterstützung an uns gesendet hat. Auf dem Weg wollten wir viele Dinge automatisieren, um die Belastung der ersten Unterstützungslinie zu reduzieren und den menschlichen Faktor maximal zu eliminieren.

Hier sind die wichtigsten Funktionen, die wir im neuen Service Desk implementiert haben:

Vorfall übertragen. Wir erhalten häufig komplexe Bewerbungen, die in einer Kette von Spezialisten aus verschiedenen Abteilungen ausgeführt werden. Am einfachsten ist eine Anwendung für den physischen Zugriff auf Geräte in einem Rechenzentrum. Zuerst schreibt der Dispatcher einen Pass aus, dann übergibt er die Kundendaten und die Passnummer an den diensthabenden Ingenieur, der den Kunden im Rechenzentrum trifft und begleitet. Es gibt Anfragen, die konsequent 5 Abteilungen bearbeiten.
In all diesen Fällen wurde in der Benutzeroberfläche eine separate Schaltfläche "Senden" angezeigt.



Korrespondenz mit einem Kunden und Kollegen. Diese Funktion soll lediglich sicherstellen, dass die Korrespondenz zu dem Vorfall nicht in die Post "gelangt" und die gesamte Kommunikationshistorie bei uns aufbewahrt wird.

Bisher ist alles sehr minimalistisch. Es ist geplant, einen Volltexteditor mit der Möglichkeit zum Herunterladen von Dateien, Tabellen usw. zu erstellen.



Eine Historie von Terminen und eine Historie aller Vorfallaktivitäten. Mithilfe dieser Registerkarten können Sie strittige Probleme und interne Untersuchungen lösen. Im Moment lade ich Berichte aus dem Verlauf herunter, um zu überwachen, wie oft Disponenten Fehler beim Zuweisen eines Vorfalls zu einer Profilgruppe machen.



Dies ist die Geschichte der Termine für den internen Vorfall "Entlassung eines Mitarbeiters".


Ereignisverlauf. Hier bringen wir noch Schönheit, aber die Hauptaufgabe ist bereits gelöst - alles ist protokolliert.

Beobachter. Es kommt vor, dass der Kunde in einem Bewerbungsschreiben eine Kopie interessierter Personen in einer Kopie befestigt. Alle diese Kameraden erscheinen auf der Registerkarte "Beobachter" und überwachen die Ausführung dieser Anwendung. Sie erhalten Beats über den Status der Anfrage. Wenn sie dies wünschen, können sie sich an unseren technischen Support wenden. Innerhalb des Unternehmens ist diese Funktion ebenfalls gefragt: Service Manager können in jede Anfrage ihres Kunden passen und deren Ausführung überwachen.
Die Liste der Beobachter kann bearbeitet werden: Löschen und Hinzufügen neuer Beobachter.



Ereignismuster. Es gibt viele typische Fragen. Um einen Antrag auf Pass- oder Müllreinigung nicht dutzende Male am Tag auszufüllen, haben wir die Möglichkeit hinzugefügt, Vorfallvorlagen zu erstellen. Sie müssen nur auf die Schaltfläche "Vorfall erstellen" klicken, und eine vorab ausgefüllte Vorlage mit dem vorgeschriebenen Ausführenden, Typ, Priorität und Status wird geöffnet.

Es gibt viele regelmäßig wiederkehrende Anwendungen in der Arbeit von Rechenzentren: Runden, Tests, Überprüfungen von technischen Geräten gemäß Checklisten usw. Für all dies werden automatische Vorfälle eingerichtet, die automatisch mit einer bestimmten Häufigkeit in den Tracker fallen.



Analytik. In Remedy gab es keine integrierten Analysetools. Mit normalen Tools konnte nichts entladen werden. Hier haben wir das Entladen von allem und allem zur weiteren Analyse vorgesehen. Zum Beispiel:

• die Anzahl der Anfragen pro Tag;
  
• Reaktionsgeschwindigkeit;
  
• Verzögerungen bei Anfragen;
  
• Arten von Anfragen;
  
• Laden nach Abteilungen;
  
• Disponenten arbeiten;
  
• Häufigkeit und Qualität neu auftretender Probleme im Kontext der Kunden;
  
• verschiedene Abhängigkeiten, zum Beispiel die Ausführungsgeschwindigkeit von der Art der Anforderung.
  

Wenig später möchten wir Dashboards mit Diagrammen und Grafiken erstellen, damit wir ohne Entladen und Hexerei in Excel ein Bild davon bekommen, was im technischen Support passiert.


Berichte können mithilfe von Filtern direkt im Service Desk generiert werden.


Entladen von Daten in verschiedenen Formaten.


Sie können die Felder auswählen, die beim Upload angezeigt werden.

API zur Integration mit anderen internen Diensten. Ganz einfach: Der Service Desk ruft Informationen aus Verzeichnissen mit einer Liste von Kundenunternehmen, Verträgen, einer Liste der bestellten Services und verantwortlichen Personen ab, die Anfragen senden können. Zuvor mussten Sie zunächst anhand einer separaten Datei prüfen, ob der Autor ein Kunde ist und ob er Anforderungen von der Firma schreiben kann.

"Bypass Shift on Duty" ist ein weiterer interner Service, mit dem der Service Desk jetzt interagieren kann. Dies ist eine elektronische Checkliste, auf der Dienstoffiziere und Wartungsingenieure mehrmals täglich Rechenzentren auf Ausfälle und Störungen untersuchen. Eine Situation für ein Beispiel: Während eines Umweges stieß der Begleiter auf einen Kundenschreibtisch mit nicht ordnungsgemäß installierter Ausrüstung. Er macht einfach eine entsprechende Notiz im Bypass-Programm, und ein Vorfall mit dem Problem kommt automatisch am Service Desk an. Die Begleitperson geht weiter die Umgehungsstraße entlang, und das Problem mit der Rezeption beginnt bereits, gelöst zu werden.


Für jedes der Checklistenelemente kann ein Vorfall erstellt werden.


Ein Formular für einen Vorfall in der Bypass-Software. Oben hängen Vorfälle in der Arbeit an demselben Objekt.

Auf die kleinen Dinge. Alle gängigen Arten von Anfragen, die wir auf der Schnittstellenseite angezeigt haben. Nach Auswahl einer Priorität sieht der Benutzer die Frist und den Fortschrittsbalken und zeigt an, wie viel Zeit ihm noch zur Ausführung des Vorfalls verbleibt.

Implementierung

Während des Testbetriebs haben wir den Schreibtisch an internen Anwendungen getestet. Etwa einen Monat lang bildeten sie sich in den Abteilungen AXO, Kapitalbau, Produktion und Servicemanagement aus. Externe Anwendungen und Anwendungen aus anderen Abteilungen durchliefen weiterhin Remedy.

Dann haben wir uns mit drei Kunden darauf geeinigt, die Bearbeitung externer Anträge durchzuführen. Hier sind die ersten Probleme aufgetreten.

Als sie gerade mit der Erstellung eines neuen Service Desks begannen, freute ich mich über die Hoffnung, dass unser Smart Mail-Parser in der Lage sein wird, Anfragen zu registrieren, sie über die Fachabteilungen zu verteilen und in einem Vorfall Nachrichten zu demselben Thema abzulegen. Dies bedeutete in Zukunft die Aufgabe von Disponenten bei der Bearbeitung schriftlicher Anfragen. Bei Remedy sind die Leute sehr daran gewöhnt, sich auf E-Mail-Korrespondenz zu verlassen, es gab mehr als wir erwartet hatten. Der Parser schlug bei den Testtests fehl: Er konnte die Abteilungen bei der Anforderung verwechseln. Er registrierte neue Nachrichten zu einem bereits geöffneten Vorfall als neue Vorfälle. Es gab trivialere Schwierigkeiten: Der Parser konnte den Brief, der aus der Post mit dem Zertifikat kam, nicht lesen; Ich habe die nicht standardmäßige Codierung nicht verstanden und den Text aus den Fragen gesendet.

Ich musste Handarbeit hinzufügen - ein Kontrollraum erschien. Dies ist ein Fegefeuer für alle Anwendungen, die an support@dtln.ru gesendet wurden . Von dort aus verteilen die Disponenten die Anträge manuell nach Abteilungen.



Auf der Client-Seite ist die Logik der Interaktion mit dem technischen Support dieselbe geblieben, nur das Erscheinungsbild der Beats hat sich geändert. In den frühen Tagen gab es mehrere Überlagerungen mit ihnen, hauptsächlich aufgrund falscher Kontaktdaten in Verzeichnissen. Einer der Kunden hatte also 23 verantwortliche Personen und alle hatten eine gemeinsame E-Mail, wie zum Beispiel info @. Der Service Desk benachrichtigte gehorsam alle und erfüllte den Tagessatz für eine Stunde, indem er auf diese Mailbox einging.

Was weiter?

In naher Zukunft - Integration mit My Account . Alle Korrespondenz- und Kontakthistorien werden im Kundenprofil angezeigt. Theoretisch ist dies eine Möglichkeit, E-Mails von der Kommunikation mit dem technischen Support auszuschließen und den Client schließlich in unsere Weboberfläche zu ziehen. Mal sehen, wie es im Leben Wurzeln schlägt.

Implementierung einer parametrisierten Anwendung . Es gibt Abfragen, die viele Parameter und Werte enthalten, und es ist wichtig, nichts darin zu verwechseln. Zum Beispiel, wenn ein Client Sie auffordert, virtuelle Ressourcen zum Pool hinzuzufügen oder virtuelle Maschinen bestimmter Größen zu erstellen. In solchen Fällen planen wir, einen Konstruktor mit Parametern zu erstellen. Solche per E-Mail empfangenen Client-Anfragen werden automatisch analysiert. Es wird von den Disponenten verwendet, wenn Anträge telefonisch angenommen werden.


So sieht eine parametrisierte Reihenfolge aus.

Bewertung des technischen Supports. Die berüchtigten "bewerten unseren Service auf einer Fünf-Punkte-Skala" mit der Fähigkeit, in freier Form zu schreiben, alles, was der Kunde über unseren Service denkt.

Wir wollen den Versandraum , der als Krücke für den Mail-Parser entstanden ist, an einem vollwertigen automatisierten Arbeitsplatz des Dispatchers (AWP) entwickeln . Jetzt muss der Dispatcher verschiedene Schnittstellen (Gerätebuchhaltung, Liste der Verantwortlichen, Kundendienst) untersuchen, um die erforderlichen Informationen über den Kunden zu sammeln. In AWP wird jedoch alles in einem Fenster angezeigt: Kundenvorfälle, Kontakte, Verträge, bestellte Services und deren Parameter usw. Daten.

Verlieren Sie nicht die Hoffnung auf die automatische Verteilung von Anträgen nach Abteilungen . Jetzt denken wir an ein Hashtag-System für einen E-Mail-Parser.

***.
Der Service Desk ist seit November im Kampfmodus und während dieser ganzen Zeit hat sich die Anzahl der Vorfälle stetig erhöht (+ 40%), hauptsächlich aufgrund interner Anfragen. Ich wage zu hoffen, dass dies auf die Tatsache zurückzuführen ist, dass der neue Service Desk in jeder Hinsicht freundlicher ist und die Anfragen nicht mehr an ihm vorbeischlüpfen.

Ein weiterer Vorteil des neuen Service Desks ist die Flexibilität. Wir haben bereits mehrere kundenspezifische Lösungen für einzelne Kunden entwickelt, um diese in ihre internen Service Desks zu integrieren oder einfach an ihre Produktionsprozesse anzupassen. Früher dauerte es Monate und Millionen, jetzt ist nur noch ein Brief an Ihren Entwickler und 1-2 Wochen erforderlich, abhängig von der Komplexität der Aufgabe.