Ausflug in die Vergangenheit
Ich arbeite seit über 4 Jahren für ICL Services und habe als Spezialist für technischen Support bei einem großen Projekt angefangen. Jetzt leite ich die ITSM-Gruppe in Richtung Service Desk - meine Kompetenzen konzentrieren sich auf die Bereitstellung und Konfiguration von ITSM-Systemen, das IT-Prozessmanagement (Incident, Change, Problem Management). In der Tat kann ich ohne Übertreibung sagen: Die geschicktesten Leute auf dem Gebiet der SD arbeiten in meiner Gruppe.
Die Besonderheit eines großen Unternehmens, die ich nach etwa sechsmonatiger Arbeit ab dem Zeitpunkt der Beschäftigung entdeckte, ist folgende: Menschen teilten selten ihre Best Practices mit. Nicht weil sie gierig waren, sondern einfach weil sie viel zu faul waren, um Kollegen zu erklären, was die Vorteile waren. Schließlich waren, wie so oft, alle hier Technikfreaks mit langjährigen Beziehungen.
Und dann komme ich - und ich sehe, dass eines großartige Skripte hat, mit denen ein Teil der Arbeit automatisch erledigt werden kann, das andere einen Zeitplan für seine Schichten in einer Cloud-Anwendung erstellt und die Schichten nie verwirrt (und in diesen dichten Zeiten, in denen wir immer noch Excel verwendet haben), schrieb das dritte ein einfaches Eine Webanwendung, die alle Felder der Anwendung auf einem Bildschirm anzeigt, um keine Zeit damit zu verschwenden, die Registerkarten im ITSM-System zu wechseln und sie beim Überprüfen von Anwendungen zu öffnen.
Diese Entwicklungen blieben jedoch individuell und wurden nicht mit dem gesamten Projektteam geteilt, ganz zu schweigen von Implementierungen bei ähnlichen Projekten. Wie mein Anführer sagte, haben wir unser Fahrrad immer selbst neu erfunden - und ich hatte Recht. Natürlich gab es auch einen menschlichen Faktor: Zum Beispiel gab es jemanden, der mehr Erfahrung hatte und der die Best Practices der "Jungen" nicht anwenden konnte. Und ein besonderer Klassiker - "aber mit ihm haben wir einen persönlichen Konflikt, ich werde die Werkzeuge, die er benutzt, nicht benutzen . "
Es war für mich erfolgreich und im Allgemeinen für unsere gesamte Abteilung wurden neue Ansätze für die Prozesse eingeführt und getestet. Tonnenweise Dokumentation, Heulen von Benutzern und Support-Gruppen - alles ist wie gewohnt. Ich habe es geschafft, die Verbesserungen durchzusetzen, die ich gesehen habe, aber vor allem habe ich es geschafft, fast alle Leute in die Zusammenarbeit am Service einzubeziehen. Wissen Sie doch, wozu ein Team fähig ist, das sich gegen ein Problem zusammenschließt? Das Problem hat keine Chance. Der Kunde hat einen neuen Indikator eingeführt - den Prozentsatz der Fehler beim Ausfüllen von Anträgen. Zu Beginn waren es ungefähr 10% pro Team, dh ungefähr 200 Anwendungen hatten sowohl kleinere als auch signifikante Fehler.
Die Linien- und Projektleiter sagten: „Es ist unmöglich, den Prozentsatz der Fehler noch weiter zu reduzieren - Menschen sind Menschen, und sie werden immer falsch liegen . " Wir haben eine Webanwendung repliziert, die von unserem führenden Spezialisten geschrieben wurde, Kontrollpunkte festgelegt und regelmäßig Informationen zu diesen Indikatoren abgerufen und bestimmte Fälle ausgearbeitet: Wenn das ITSM-System selbst die erforderlichen Felder aus Active Directory ersetzt, worauf zu achten ist. Das Ergebnis ließ nicht lange auf sich warten - in sechs Monaten haben wir den Prozentsatz der Fehler pro Monat auf das kritisch niedrige Niveau von 0 bis 0,6% pro Team gebracht.
Und um diesen Punkt meiner Karriere herum erkannte ich zwei Dinge:
- Ich möchte in einem coolen Team arbeiten , und sein integrales Arbeitsergebnis ist viel besser als das, was selbst der genialste Mitarbeiter tun kann. Diese Entscheidung wird mich definitiv später zum Management führen.
- Ich möchte die Leistungen talentierter, cooler Leute in einem einzigen System kombinieren, das besser, zuverlässiger und schneller ist als das, das Sie zuvor hatten.
Projektstart
2019 wurde mir angeboten, das Digital SD-Projekt zu leiten, bei dem wir unsere Dienste mithilfe moderner Technologien wettbewerbsfähiger machen mussten: Maschinelles Lernen, verschiedene Sprach- und Textbots, Omnichannel-Plattformen, automatische Klassifizierungen und Anwendungen mit automatischer Auflösung. Mit anderen Worten, all diese Dinge, die die Erfahrung des Kunden auf ein neues Niveau heben, ohne die Arbeitskosten für die Erbringung einer Dienstleistung zu erhöhen.
Ehrlich gesagt war ich, nachdem ich auf den ganzen Hype um AI zurückgeblickt hatte, zunächst sehr skeptisch gegenüber der Aufgabe. Und es scheint, dass die Richtung richtig ist und das Ziel gut ist, aber hier stimmte etwas nicht.
Und der Haken war, dass niemand wusste, was genau entwickelt werden musste. Es gibt viele Richtungen, worauf man sich einlassen kann. Normalerweise schreiben sie in solchen Momenten in Artikeln oder Büchern selbstbewusst: „Schon damals wussten wir, wie und wohin wir uns bewegen sollten“. Es geht also nicht um uns. Ich stand mit dem Produktbesitzer zusammen und machte eine Liste mit Fragen, die wir beim Entwerfen des Produkts beantworten mussten:
- Welche nützlichen Funktionen bieten wir dem Benutzer und dem Kunden?
- Wie lässt sich dies in den aktuellen Service integrieren?
- Wie müssen Sie Ihre aktuellen Workflows ändern, damit dies funktioniert und von Vorteil ist?
- Wie und auf welchen Technologien soll dies geschehen?
- Wie soll ein wirtschaftliches Lösungsmodell aufgebaut werden?
Aber wir haben es ganz nachdenklich gemacht: Wir haben eine Gruppe von SD-Experten aus Projektmanagern, Vorgesetzten und technischen Experten zusammengetragen, User Stories aufgeschrieben und eine Wertkarte erstellt - hier ein kleiner Teil davon:
Parallel dazu haben wir gemeinsam mit den Entwicklern die Architektur auf höchster Ebene beschrieben und so einen Ausgangspunkt für das Projekt erhalten ...
SCRUM Arbeit
Also unsere Einführungen: Product Owner, PM, Scrum Master und Entwicklungsteam. Ein Arbeitssprint von 2 Wochen Dauer. Die Aufgabe besteht darin, den Produktfreigabeprozess so zu organisieren, dass ...
Aber im Ernst, es war notwendig, die Anforderungen aller Beteiligten zu berücksichtigen, mit den Schmerzen umzugehen und zu verstehen, was wirklich getan werden muss, was später getan werden kann und was überhaupt nicht.
Wir hatten 3 große Tätigkeitsbereiche:
- . , , , .
- . , «» .
- . HR, , IT, . .
Wir haben es erst im 3. Sprint geschafft, normale Arbeit aufzubauen: Wir haben mehr oder weniger erkannt, dass wir uns auf die Bereiche 1 und 2 konzentrieren müssen, weil die Projektmanager über Schmerzen sprechen und die Leiter der Unterstützungsdienste über Wünsche sprechen.
Ich werde den Artikel nicht dehnen und Ihnen sagen, wie cool Agile an sich ist und wie es sehr hilft. Aber hier ist, was ich wirklich sagen kann, nachdem ich ungefähr 30 Sprints in diesem Modus gearbeitet habe:
- Scrum ist ein funktionierender Ansatz. Sie setzen Ressourcen und Methoden ein und erhalten Lieferungen.
- – . , , , . , , , , « », – .
- . , , . , , – . PM – , , , – , – .
Ich habe weniger Erfahrung dieser Art, daher fiel diese große und schwere Belastung dem Product Owner in größerem Maße zu: Um die Erwartungen der Stakeholder mit der Realität zu vergleichen, die Fähigkeiten meines Teams klar zu verstehen, ein sauberes Auge zu haben, die Marktsituation zu verstehen, das Gleichgewicht zwischen der Ausrichtung der Ressourcen auf nützliche Funktionen und Experimenten und "notwendiges Übel" - Sicherheit von Lösungen, Organisation der Servicearchitektur, Umgebungen, Dokumentation.
- PM . , . -. Devops , , : , /. , , Agile - , : , , .
- - – . , -. , . , PM -, . , . , , !
Wir haben die Entwicklung nicht von vorne begonnen. Wir hatten viele Entwicklungen im Unternehmen, die in der einen oder anderen Form verwendet werden konnten - es gab allein zwei Autoklassifizierer.
Ich fühlte mich déjà vu, als ich all dies aus verschiedenen Projekten und Abteilungen sammelte, als ich einmal Entwicklungen für mein erstes Projekt sammelte.
Wir haben begonnen, das Dialogsystem mit mehreren Open-Source-Bibliotheken zu entwickeln - eine davon war DeepPavlov. Wir hatten nicht viel Erfahrung damit und bei unseren Aufgaben war die Erkennungsqualität mittelmäßig. Bald wechselten wir zu Rasa, und dort lief es viel besser - und nachdem wir das Modell anhand unserer spezifischen Daten trainiert hatten, konnten wir Dialoge gut und sicher erkennen.
Das Layout der Dialoge selbst wurde manuell vorgenommen - in diesem Moment gab es Leute in SD, die diese Aufgabe übernahmen. Unser führender Python-Entwickler hat schnell ein Markup-Programm geschrieben, und wir haben dem Modell ein paar Zehntausende von Gesprächen zugeführt. Die Fragmente wurden mit jeweils 3 Sekunden ziemlich kurz genommen - auf diese Weise kam das Ergebnis besser heraus.
Anfangs hatten wir zwei virtuelle Maschinen unter Windows und Linux, einige der Dienste konnten nur unter Windows funktionieren. Als wir jedoch mit den ersten Entwicklungen im Pilotprojekt begannen, stellten wir schnell fest, dass zwei virtuelle Maschinen für ein Projekt zu teuer sind. Wir müssen es wiederholen. Jetzt verwenden wir eine virtuelle Maschine unter Ubuntu für die Produktion. Natürlich sind sie alle isoliert und jedes Projekt hat seinen eigenen Bereich.
Wir haben auch schnell erkannt, dass das Einrichten von zwei virtuellen Maschinen, das Aufrufen und Debuggen aller Dienste, das Öffnen von Ports und andere Einstellungen absolut unanständige Zeit in Anspruch nehmen. Dann haben wir eine CI / CD-Lösung basierend auf Docker erstellt - sowohl für den Hauptcode als auch für den ML-Teil.
Irgendwann im 9-10. Sprint wurden wir von vielen Kunden aufgefordert, ihr eigenes Spracherkennungssystem zu entwickeln. Die meisten Kunden waren überhaupt nicht bereit, ihre vertraulichen Informationen in die "Clouds" an Dritte weiterzugeben. Also haben wir ein solches System geschrieben und können es jetzt dort anbieten, wo es wichtig ist, die gesamte Architektur innerhalb des Sicherheitsbereichs zu haben - zum Beispiel für Unternehmen, die eng mit dem Staat verbunden sind. Oder platzieren Sie es in unserer Infrastruktur und wissen Sie, dass vertrauliche Daten nicht an Dritte gelangen.
Wir haben ein Komponentenüberwachungssystem bereitgestellt, Integritätsprüfungen eingerichtet und das System in einen Chat-Kanal in Telegram integriert.
Und zum Schluss erzähle ich Ihnen noch etwas Feines, das für jemanden beim Entwerfen seines Chat-Bots nützlich sein kann. Anfangs war unser gesamter Code monolithisch genug und es war mühsam, Änderungen daran vorzunehmen. Wir haben den Chatbot in zwei große Teile unterteilt: den Basisbot und die Anpassung. Wir mussten die Logik neu schreiben - aber dank dieser Trennung konnten wir schnell die grundlegenden und allgemeinen Komponenten des Bots bereitstellen und nur das bearbeiten, was für jedes spezifische Projekt benutzerdefiniert war.
Projektergebnisse
Wir haben die Nische unserer Geschichte klar verstanden: Wir werden nicht mit Boxprodukten konkurrieren können, die seit einem Dutzend Jahren entwickelt wurden, und dies ist auch nicht erforderlich. Unsere Nische besteht darin, Automatisierungstools in jeder Phase eines Serviceprojekts bereitzustellen, vom Vorverkauf bis zum Vertragsablauf. Mit anderen Worten, anfangs hatten wir kein Ziel, Google zu entwickeln - aber das Ziel war es, einen Designer zu entwickeln, der beim Verkauf von Service Desk hilft, die Kosten für die Bereitstellung eines Service senkt und Kunden und deren Unternehmen zusätzliche Möglichkeiten bietet.
Ich habe auch einen interessanten Punkt für mich selbst festgestellt: Selten kann eine Box-Lösung auf dem Markt den Schmerz eines Kunden vollständig abdecken und gleichzeitig einen Preis vereinbaren. Entweder zahlt der Kunde zu viel für die Funktionalität, die er später nicht nutzen wird, oder einige der Verbesserungen müssen von Spezialisten oder Spezialisten des ausgewählten Anbieters vorgenommen werden, wenn er diese in Anspruch nimmt.
Und hier haben wir eine interessante und ziemlich schwierige Integrationsaufgabe. Wir bieten nicht nur reine eigene Automatisierungslösungen an, sondern bauen aus unseren Entwicklungen und bereits auf dem Markt befindlichen Lösungen von Drittanbietern ein System für den Kunden auf, passen zur Funktionalität des Kunden und warten ein solches System als Service. Vielleicht werde ich in den nächsten Artikeln über die Ergebnisse dieser Arbeit sprechen, wenn Interesse besteht.
Die meisten unserer Tools und Entwicklungen wurden bereits in aktuellen Diensten implementiert, wir testen einige und wir werden einige an der BAU verfeinern. Der Chatbot fühlt sich immer noch am schlimmsten an, heute ist er für Projekte am wenigsten nützlich - vielleicht weil die Erwartungen jetzt ziemlich hoch sind. Jeder möchte einen intelligenten Bot, der menschliche Sprache wahrnehmen, alle Benutzerfragen ruhig beantworten, mit Unterbrechungen umgehen kann, in alle Systeme integriert ist, sich ohne menschliches Eingreifen selbst lernt und im Laufe der Zeit immer mehr Absichten erkennt.
Aber jeder Entwickler, der sich mit dem Thema auskennt, weiß, wie schwierig diese Aufgabe ist. Selbst wenn wir die Funktionalität erhöhen und die Anzahl der Absichten erhöhen, die ein Bot erkennen kann, können wir die Erkennung bestehender Absichten verschlechtern. Aber das war ein Exkurs - im Allgemeinen scheint es mir, dass wir die Hauptaufgabe des Projekts dennoch bewältigt haben.
Was ist am Ausgang passiert?
1. Intelligenter Sprachassistent und Skriptdesigner dafür. Schließt die Notwendigkeit der Automatisierung des eingehenden Anrufflusses, erkennt die Sprache des Benutzers, spricht Sprache in Text und überträgt sie je nach Einstellung an Mail, Chat und ITSM-System. Es kann in eine Reihe verschiedener Systeme integriert werden, entweder mit vorgefertigten Anschlüssen oder mit denen, die wir geschrieben haben.
2. Der Dialer mit dem Motor vom Sprachassistenten.Schließt die Notwendigkeit, den angegebenen Nummernpool aufzurufen, und sammelt dann je nach Szenario Benutzerantworten. Regelmäßige Anrufe sind möglich. Es gibt eine Einstellung für die Anzahl der sich wiederholenden Fragen, um zu klären, wie oft und nach welcher Zeit zurückgerufen werden soll. Speichert Daten zu getätigten Anrufen zusammen mit Anrufergebnissen und Anrufaufzeichnung. Jetzt wird es verwendet, um Ingenieure an das Patchen für ein Projekt zu erinnern, das für einen großen internationalen Lebensmitteleinzelhändler in der Personalabteilung bei der Organisation von Interviews für Massenpositionen durchgeführt wurde, um Informationen über die Qualität gelöster Anwendungen in einer großen Fast-Food-Restaurantkette zu sammeln.
3. Ein Chatbot zum Erstellen einer Anwendung, zum Zurücksetzen eines Kennworts und ein Skriptdesigner dafür.Kann Primärinformationen zum Registrieren einer Anforderung anfordern, eine Anforderung im ITSM-System registrieren und eine Anforderungsnummer zurückgeben Wenn der Artikel veröffentlicht wird, wird er lernen, eine Liste offener Anwendungen anzuzeigen, in der Informationen hinzugefügt oder geschlossen werden können Es kann eine Verbindung zu verschiedenen ITSM-Systemen mit oder ohne API-Zugriff herstellen.
4. Werkzeug zur Qualitätskontrolle. Bisher weiß er ein wenig: Er verfolgt Anrufe, erkennt, ob der Bediener begrüßt hat oder nicht, identifiziert konflikterzeugende Wörter, verbindet sich in einem Dialog, verfügt über eine vollwertige Schnittstelle für den Qualitätskontrolleur. Sie haben es für sich selbst gemacht, aber es kann im CC nützlich sein.
5. Auto-Klassifikator.Er kann Anwendungen im ITSM-System analysieren, ausfüllen und an die erforderlichen Lösungsgruppen senden. Kann die Verfügbarkeit, Arbeitsbelastung und Spezialisierung von Ingenieuren berücksichtigen. Sie können beispielsweise die Logik festlegen, dass alle EDS-Anwendungen an die Hauptspezialisten Vasily oder Andrey gesendet werden sollen: Wenn Vasily nicht im Dienst ist, geht die Anwendung an Andrey und umgekehrt. Wenn nicht beides, wird das Ticket dem allgemeinen Support für Geschäftsanwendungen hinzugefügt. Wenn Vasily 2 Bewerbungen hat und Andrey 1, wird eine neue Bewerbung an Andrey gesendet. Sie können das Modell sicher neu trainieren und so die Genauigkeit erhöhen. Der Nachteil des Systems ist sein Punkt.Sie sollten keine 100% ige Genauigkeit vom Modell erwarten oder am gesamten Anwendungsvolumen arbeiten. An einem Testbeispiel haben wir für 50% der Anwendungen mit sehr konsistenten Daten eine Genauigkeit von 90% erzielt, wobei Benutzer daran gewöhnt sind, mit Vorlagen zu arbeiten. Der zweite Nachteil ist das Auftragsvolumen. Es macht keinen Sinn, das Modell zu trainieren, wenn Sie weniger als 1000 Bewerbungen pro Monat haben.
6. Tools zum automatischen Lösen von Anwendungen.Dies ist eine Reihe von Tools aus der GUI mit Skripten, die die Standardaktionen eines Agenten des technischen Supports automatisieren: Sammeln von Protokollen von Systemen, Erstellen von Screenshots, einschließlich im Schattenmodus, Aktualisieren von Richtlinien und anderen projektspezifischen Dingen. Das zweite Tool ist die Automatisierung der Anwendungen, für die eine Genehmigung erforderlich ist. Das Tool selbst generiert einen Brief an den Genehmigenden mit Links zum Genehmigen / Ablehnen und gibt basierend auf den Ergebnissen selbst einen Befehl zum Bereitstellen des Zugriffs aus, oder es generiert einen Brief mit einer Ablehnung.
Anstatt auf Wiedersehen
Der Winter kommt, das Projekt endet Ende dieses Jahres, ich
Vielen Dank für Ihr Interesse und Ihre Zeit, werden Sie nicht krank!