Excursion dans le passé
Je travaille pour ICL Services depuis plus de 4 ans et j'ai débuté en tant que spécialiste du support technique sur un grand projet. Maintenant je dirige le groupe ITSM vers le Service Desk - mes compétences sont concentrées dans le déploiement et la configuration des systèmes ITSM, la gestion des processus informatiques (Incident, Change, Problem Management). En fait, je peux dire sans exagération: les personnes les plus compétentes dans le domaine du développement durable travaillent dans mon groupe.
La particularité d'une grande entreprise, que j'ai découverte après y avoir travaillé pendant environ six mois à partir du moment de l'emploi, est la suivante: les gens partageaient rarement leurs bonnes pratiques. Non pas parce qu'ils étaient avides, mais simplement parce qu'ils étaient trop paresseux pour expliquer à leurs collègues quels étaient les avantages. Après tout, comme cela arrive souvent, pour la plupart, tout le monde ici était des techniciens avec des relations de longue date.
Et puis je viens - et je vois que l'un a de magnifiques scripts qui permettent de faire une partie du travail automatiquement, l'autre garde un calendrier de ses quarts dans une application cloud et ne confond jamais les quarts (et en ces temps denses, nous avons encore utilisé Excel), le troisième a écrit un simple une application Web qui affiche tous les champs de l'application sur un seul écran pour ne pas perdre de temps à changer d'onglet dans le système ITSM et à les ouvrir lors de la vérification des applications.
Mais ces développements sont restés individuels et n'ont pas été partagés avec l'ensemble de l'équipe projet, sans parler des implémentations sur des projets similaires. Comme mon chef l'a dit, nous avons toujours réinventé notre vélo par nous-mêmes - et j'avais raison dans ce cas. Bien sûr, il y avait aussi un facteur humain: par exemple, il y avait quelqu'un de plus expérimenté, et il ne pouvait pas utiliser les meilleures pratiques des «jeunes». Et un classique spécial - " mais avec lui, nous avons un conflit personnel, je n'utiliserai pas les outils qu'il utilise ."
Cela a été un succès pour moi, et en général pour l'ensemble de notre département, de nouvelles approches des processus ont été introduites et testées. Des tonnes de documentation, des hurlements d'utilisateurs et de groupes de soutien - tout est comme d'habitude. J'ai réussi à faire avancer les améliorations que j'ai constatées, mais surtout, j'ai réussi à impliquer presque tous les gars dans la collaboration sur le service. Après tout, savez-vous de quoi est capable une équipe qui s'est unie contre un problème? Le problème n'a aucune chance. Le client a introduit un nouvel indicateur - le pourcentage d'erreurs lors du remplissage des demandes. Au départ, il était d'environ 10% par équipe, c'est-à-dire qu'environ 200 applications présentaient à la fois des erreurs mineures et des erreurs importantes.
Les responsables de ligne et de projet ont déclaré: «Vous ne pouvez pas réduire encore plus le taux d'erreur - les gens sont des personnes, et ils auront toujours tort". Nous avons répliqué une application Web écrite par notre spécialiste de premier plan, défini des points de contrôle et régulièrement pris des informations sur ces indicateurs, élaboré des cas spécifiques: lorsque le système ITSM lui-même remplace les champs nécessaires d'Active Directory, que rechercher. Le résultat ne s'est pas fait attendre - en six mois, nous avons ramené le% d'erreurs par mois au niveau extrêmement bas de 0-0,6% par équipe.
Et autour de ce point de ma carrière, j'ai réalisé deux choses:
- Je veux travailler dans une équipe cool , et son résultat de travail intégral est bien meilleur que ce que même l'employé le plus ingénieux peut faire. Cette décision m'amènera certainement à la direction plus tard.
- Je veux combiner les réalisations de gars talentueux et cool en un seul système qui est meilleur, plus fiable et plus rapide que celui que vous aviez auparavant.
Début du projet
En 2019, on m'a proposé de diriger le projet Digital SD, dans lequel nous devions rendre nos services plus compétitifs à l'aide de technologies modernes: Machine Learning, divers bots vocaux et textuels, plateformes omnicanales, auto-classifications et applications de résolution automatique. En d'autres termes, toutes ces choses qui portent l'expérience du client à un nouveau niveau sans augmenter les coûts de main-d'œuvre liés à la fourniture d'un service.
Honnêtement, après avoir repensé à tout le battage médiatique autour de l'IA, au début, j'étais très sceptique quant à la tâche. Et il semble que la direction soit correcte et que le but soit bon, mais quelque chose n'allait pas ici.
Et le hic, c'est que personne ne savait exactement ce qu'il fallait développer. Il y a beaucoup de directions, à quoi s'accrocher? Habituellement, à de tels moments dans des articles ou des livres, ils écrivent avec assurance: «même alors, nous savions comment et où bouger». Donc, ce n'est pas à propos de nous. Je suis resté avec le propriétaire du produit et j'ai dressé une liste de questions auxquelles nous devions répondre lors de la conception du produit:
- Quelles fonctionnalités utiles apportons-nous à l'utilisateur et au client?
- Comment cela s'intègre-t-il dans le service actuel?
- Comment devez-vous modifier vos flux de travail actuels pour que cela fonctionne et soit bénéfique?
- Comment et sur quelles technologies cela doit-il être fait?
- Comment construire un modèle de solution économique?
Mais nous l'avons fait de manière assez réfléchie: nous avons rassemblé un groupe d'experts du développement durable parmi des chefs de projet, des responsables hiérarchiques, des experts techniques, rédigé des user stories, fait une carte de valeur - en voici un petit morceau:
en parallèle, avec les développeurs, nous avons décrit l'architecture de haut niveau, obtenant ainsi un point de départ dans le projet ...
Travail SCRUM
Donc, nos présentations: Product Owner, PM, Scrum Master et équipe de développement. Un sprint de travail d'une durée de 2 semaines. La tâche est d'organiser le processus de sortie du produit de telle manière que ...
Mais sérieusement, il était nécessaire de prendre en compte les exigences de toutes les parties prenantes, de gérer les douleurs et de comprendre ce qui doit vraiment être fait, ce qui peut être fait plus tard et ce qu'il ne faut pas faire du tout.
Nous avions 3 grands domaines d'activité:
- Produits pour l'automatisation dans les projets de service en cours. Cela comprend tout ce qui aidera à réduire les coûts de main-d'œuvre pour fournir un service, augmenter la satisfaction du client et offrir une valeur supplémentaire.
- Produits pour les nouveaux clients. Tout ce qui produit un effet wow au début et "accroche" le client.
- Produits pour automatiser les tâches internes d'une organisation. Tâches des RH, du marketing, de l'informatique, du service administratif, etc.
Nous n'avons réussi à établir un travail normal qu'au 3ème sprint: nous avons plus ou moins réalisé que nous devons nous concentrer sur les domaines 1 et 2, car les chefs de projet parlent de douleur, et les responsables des services de soutien parlent de souhaits.
Je ne vais pas étirer l'article et vous dire à quel point Agile est cool et en quoi cela aide beaucoup. Mais voici ce que je peux vraiment dire après avoir travaillé dans ce mode pendant environ 30 sprints:
- Scrum est une approche de travail. Vous mettez en place des ressources et une méthodologie, et vous obtenez des fournitures.
- – . , , , . , , , , « », – .
- . , , . , , – . PM – , , , – , – .
J'ai moins d'expérience de ce genre, donc ce lourd et lourd fardeau incombait davantage au Product Owner: comparer les attentes des parties prenantes avec la réalité, comprendre clairement les capacités de mon équipe, avoir un œil net, comprendre la situation du marché, équilibrer entre diriger les ressources vers des fonctionnalités utiles, expérimenter et "mal nécessaire" - sécurité des solutions, organisation de l'architecture des services, environnements, documentation.
- PM . , . -. Devops , , : , /. , , Agile - , : , , .
- - – . , -. , . , PM -, . , . , , !
Nous n'avons pas commencé le développement à partir de zéro. Nous avons eu beaucoup de développements dans l'entreprise qui pouvaient être utilisés sous une forme ou une autre - il y avait deux auto-classificateurs seuls.
J'ai ressenti du déjà vu quand j'ai rassemblé tout cela à partir de différents projets, divisions, car j'ai une fois recueilli les développements sur mon premier projet.
Nous avons commencé à développer le système de dialogue avec plusieurs bibliothèques open source - et l'une d'elles était DeepPavlov. Nous n'en avions pas beaucoup d'expérience, et sur nos tâches, la qualité de la reconnaissance s'est avérée médiocre. Bientôt, nous sommes passés à Rasa, et là, les choses se sont beaucoup mieux déroulées - et après avoir formé le modèle sur nos données spécifiques, nous avons obtenu une bonne et confiante reconnaissance des dialogues.
La mise en page des dialogues eux-mêmes a été faite manuellement - à ce moment-là, il y avait des gars de SD qui se chargeaient de cette tâche. Notre développeur Python principal a rapidement écrit un programme de balisage et nous avons alimenté le modèle de quelques dizaines de milliers de conversations. Les fragments ont été pris assez courts, 3 secondes chacun - de cette façon, le résultat est meilleur.
Au départ, nous avions 2 machines virtuelles sous Windows et sous Linux, certains services ne pouvaient fonctionner que sous Windows. Mais lorsque nous avons commencé à apporter les premiers développements au pilote, nous nous sommes vite rendu compte que 2 machines virtuelles pour un projet coûtaient trop cher, nous devons le refaire. Nous utilisons maintenant une machine virtuelle sur Ubuntu pour la production. Bien sûr, ils sont tous isolés et chaque projet a sa propre zone.
Nous avons également rapidement réalisé que la configuration de deux machines virtuelles, la montée et le débogage de tous les services, l'ouverture de ports et d'autres paramètres prennent un temps absolument indécent. Après cela, nous avons créé une solution CI / CD basée sur Docker - à la fois pour le code principal et pour la partie ML.
Quelque part dans le 9-10ème sprint, nous avons été confrontés à une demande de nombreux clients de créer leur propre système de reconnaissance vocale. La plupart des clients n'étaient pas du tout prêts à transférer leurs informations confidentielles vers les «nuages» à des tiers. Nous avons donc écrit un tel système et maintenant nous pouvons le proposer là où il est important d'avoir toute l'architecture dans le périmètre de sécurité - par exemple, pour les entreprises étroitement liées à l'État. Ou placez-le dans notre infrastructure, en sachant avec certitude que les données sensibles ne parviendront pas à des tiers.
Nous avons déployé un système de surveillance des composants, mis en place des contrôles de santé et intégré le système avec un canal de discussion dans Telegram.
Et enfin, je vais vous parler d'une autre subtilité qui peut être utile pour quelqu'un lors de la conception de son propre chat bot. Au départ, tout notre code était assez monolithique et il était laborieux d'y apporter des modifications. Nous avons divisé le chatbot en deux grandes parties: le bot de base et la personnalisation. Nous avons dû réécrire la logique - mais grâce à cette séparation, nous avons pu rapidement déployer les composants de base et communs du bot et modifier uniquement ce qui était personnalisé pour chaque projet spécifique.
Résultats du projet
Nous avons bien compris la nature de niche de notre histoire: nous ne pourrons pas rivaliser avec les produits en boîte qui ont été développés depuis une douzaine d'années, et cela n'est pas nécessaire non plus. Notre créneau est de fournir des outils d'automatisation à n'importe quelle étape d'un projet de service, de la prévente à l'expiration du contrat. En d'autres termes, au départ, nous n'avions pas pour objectif de créer Google - mais l'objectif était de créer un concepteur qui aiderait à vendre Service Desk, aiderait à réduire le coût de la fourniture d'un service et offrirait des opportunités supplémentaires aux clients et à leur entreprise.
J'ai également noté un point intéressant pour moi-même: rarement une solution en boîte sur le marché peut couvrir complètement la douleur d'un client et en même temps fixer un prix. Soit le client surpaye la fonctionnalité, qu'il n'utilisera pas plus tard, soit certaines des améliorations devront être faites par des spécialistes ou spécialistes du fournisseur sélectionné, s'il entreprend cela.
Et ici, nous avons une tâche d'intégration intéressante et plutôt difficile, en plus d'offrir uniquement nos propres solutions d'automatisation, de construire un système pour le client à partir de nos développements et de solutions tierces déjà sur le marché, adaptées aux fonctionnalités du client et maintenir un tel système en tant que service. Peut-être parlerai-je des résultats de ce travail dans les prochains articles, s'il y a de l'intérêt.
La plupart de nos outils et développements ont déjà été implémentés dans les services actuels, nous en testons certains, et nous en affinerons certains à BAU. Le chatbot ressent toujours le pire de tous, c'est aujourd'hui le moins utile pour les projets - peut-être parce que les attentes sont désormais assez élevées. Tout le monde veut un robot intelligent capable de percevoir la parole humaine, de répondre calmement à toutes les questions des utilisateurs, de gérer les interruptions, de s'intégrer dans tous les systèmes, de s'instruire sans intervention humaine et, au fil du temps, reconnaît de plus en plus d'intentions.
Mais tout développeur qui connaît bien le sujet comprend à quel point cette tâche est difficile - après tout, même en augmentant les fonctionnalités et en augmentant le nombre d'intentions qu'un bot peut reconnaître, nous pouvons aggraver la reconnaissance des intentions existantes. Mais c'était une digression - dans l'ensemble, il me semble que nous avons néanmoins géré la tâche principale du projet.
Que s'est-il passé à la sortie
1. Assistant vocal intelligent et concepteur de script pour cela. Élimine le besoin d'automatisation du flux d'appels entrants, reconnaît la parole de l'utilisateur, la voix au texte et la transmet au courrier, au chat, au système ITSM, en fonction du paramètre. Il peut s'intégrer à un tas de systèmes différents, soit avec des connecteurs prêts à l'emploi, soit avec ceux que nous avons écrits.
2. Numéroteur avec un moteur de l'assistant vocal.Élimine le besoin d'appeler le pool de numéros spécifié, puis collecte les réponses des utilisateurs en fonction du scénario. Des appels réguliers sont possibles, il y a un paramètre pour le nombre de questions répétitives pour préciser combien de fois et après quelle heure rappeler. Stocke les données sur les appels passés avec les résultats des appels et l'enregistrement des appels. Désormais, il est utilisé pour rappeler aux ingénieurs le patching d'un projet mis en œuvre pour une grande distribution alimentaire internationale, au sein du service RH lors de l'organisation d'entretiens pour des postes de masse, dans le cadre de plans de collecte d'informations sur la qualité des applications résolues dans une grande chaîne de restauration rapide.
3. Un chatbot pour créer une application, réinitialiser un mot de passe et un script designer pour cela.Sait comment demander des informations primaires pour enregistrer une demande, enregistrer une demande dans le système ITSM et renvoyer un numéro de demande. Au moment où l'article est publié, il apprendra à afficher une liste d'applications ouvertes avec la possibilité d'y ajouter des informations ou de les fermer. Il peut se connecter à différents systèmes ITSM, avec ou sans accès à l'API.
4. Outil de contrôle qualité. Il en sait un peu jusqu'ici: il suit les appels, reconnaît si l'opérateur les a salués ou non, identifie les mots générateurs de conflits, s'accouple dans un dialogue, dispose d'une interface à part entière pour le contrôleur qualité. Ils l'ont fait pour eux-mêmes, mais cela peut être utile au CC.
5. Auto-classificateur.Il est capable d'analyser les applications dans le système ITSM, de les remplir et de les envoyer aux groupes de solutions nécessaires. Peut prendre en compte la disponibilité, la charge de travail et la spécialisation des ingénieurs. Par exemple, vous pouvez configurer la logique selon laquelle toutes les candidatures d'EDS doivent être envoyées aux principaux spécialistes Vasily ou Andrey: si Vasily n'est pas de service, l'application ira à Andrey, et vice versa. Si ce n'est pas les deux, le ticket sera ajouté à la ligne générale de support des applications métier. Si Vasily a 2 candidatures et Andrey 1, une nouvelle candidature sera envoyée à Andrey. Vous pouvez recycler le modèle en toute confiance, augmentant ainsi la précision. L'inconvénient du système est son point.Vous ne devez pas vous attendre à une précision de 100% du modèle ou travailler sur l'ensemble du volume d'applications. Sur un échantillon de test, nous avons obtenu une précision de 90% pour 50% des applications avec des données très cohérentes, où les utilisateurs sont habitués à travailler avec des modèles. Le deuxième inconvénient est le volume des commandes. Cela n'a aucun sens de former le modèle si vous avez moins de 1 000 applications par mois.
6. Outils pour les applications de résolution automatique.Il s'agit d'un ensemble d'outils de l'interface graphique avec des scripts qui automatisent les actions standard d'un agent de support technique: collecte des journaux des systèmes, prise de captures d'écran, y compris en mode shadow, mise à jour des politiques et autres choses spécifiques à chaque projet. Le deuxième outil est l'automatisation des applications pour lesquelles une approbation est requise. L'outil lui-même génère une lettre à l'approbateur avec des liens pour approuver / refuser et, en fonction des résultats, donne lui-même une commande pour donner accès, ou il génère une lettre avec un refus.
Au lieu d'adieu
L'hiver arrive, le projet se termine à la fin de cette année, je
Merci pour votre intérêt et votre temps, ne tombez pas malade!