Excursión al pasado
He trabajado para ICL Services durante más de 4 años y comencé como especialista en soporte técnico en un gran proyecto. Ahora lidero el grupo ITSM en la dirección de Service Desk : mis competencias se concentran en la implementación y configuración de sistemas ITSM, gestión de procesos de TI (Incidente, Cambio, Gestión de Problemas). De hecho, sin exagerar, puedo decir: las personas más hábiles en el campo de DS trabajan en mi grupo.
La peculiaridad de una gran empresa, que descubrí después de trabajar en ella durante unos seis meses desde el momento del empleo, es la siguiente: la gente rara vez comparte sus mejores prácticas. No porque fueran codiciosos, sino simplemente porque eran demasiado perezosos para explicar a sus colegas cuáles eran los beneficios. Después de todo, como suele suceder, en su mayor parte, todos aquí eran técnicos con relaciones duraderas.
Y luego vengo, y veo que uno tiene scripts magníficos que permiten que parte del trabajo se haga automáticamente, el otro mantiene un cronograma de sus turnos en una aplicación en la nube y nunca confunde los turnos (y en esos tiempos densos todavía usábamos Excel), el tercero escribió un sencillo una aplicación web que muestra todos los campos de la aplicación en una sola pantalla para no perder tiempo cambiando de pestaña en el sistema ITSM y abriéndola al revisar aplicaciones.
Pero estos desarrollos siguieron siendo individuales y no se compartieron con todo el equipo del proyecto, sin mencionar las implementaciones en proyectos similares. Como dijo mi líder, siempre hemos reinventado nuestra bicicleta por nuestra cuenta, y tenía razón en el caso. Por supuesto, también había un factor humano: por ejemplo, había alguien con más experiencia y no podía utilizar las mejores prácticas de los "jóvenes". Y un clásico especial: " pero con él tenemos un conflicto personal, no usaré las herramientas que él usa ".
Fue un éxito para mí y, en general, para todo nuestro departamento, se introdujeron y probaron nuevos enfoques de los procesos. Gran cantidad de documentación, aullidos de usuarios y grupos de soporte: todo es como de costumbre. Me las arreglé para impulsar las mejoras que vi, pero lo más importante, logré involucrar a casi todos los muchachos en el trabajo conjunto en el servicio. Después de todo, ¿sabes de lo que es capaz un equipo que se ha unido ante un problema? El problema no tiene ninguna posibilidad. El cliente introdujo un nuevo indicador: el porcentaje de errores al completar las solicitudes. Al principio, era alrededor del 10% por equipo, es decir, alrededor de 200 aplicaciones tenían errores menores y significativos.
Los gerentes de línea y de proyecto dijeron: “No se puede reducir aún más la tasa de error: las personas son personas y siempre estarán equivocadas". Replicamos una aplicación web escrita por nuestro especialista líder, establecimos puntos de control y tomamos regularmente información sobre estos indicadores, resolvimos casos específicos: cuando el propio sistema ITSM sustituye los campos necesarios de Active Directory, qué buscar. El resultado no tardó en llegar: en seis meses llevamos el% de errores por mes al nivel críticamente bajo de 0-0.6% por equipo.
Y en este punto de mi carrera, me di cuenta de dos cosas:
- Quiero trabajar en un equipo genial , y todo el resultado de su trabajo es mucho mejor de lo que puede hacer incluso el empleado más ingenioso. Esta decisión definitivamente me llevará a la gerencia más adelante.
- Quiero combinar los logros de chicos geniales y talentosos en un solo sistema que es mejor, más confiable y más rápido que el que tenías antes.
Inicio del proyecto
En 2019, me ofrecieron liderar el proyecto Digital SD, dentro del cual teníamos que hacer más competitivos nuestros servicios utilizando tecnologías modernas: Machine Learning, varios bots de voz y texto, plataformas omnicanal, autoclasificaciones y aplicaciones de resolución automática. En otras palabras, todas aquellas cosas que llevan la experiencia del cliente a un nuevo nivel sin incrementar los costos laborales de brindar un servicio.
Honestamente, después de mirar hacia atrás en todo el bombo en torno a la IA, al principio era muy escéptico sobre la tarea. Y parece que la dirección es la correcta, y el gol es bueno, pero algo andaba mal aquí.
Y el problema era que nadie sabía exactamente qué era necesario desarrollar. Hay muchas direcciones, ¿a qué agarrarse? Por lo general, en esos momentos, en artículos o libros, escriben con confianza: "incluso entonces sabíamos cómo y dónde movernos". Entonces, esto no se trata de nosotros. Me quedé con el propietario del producto e hice una lista de preguntas que teníamos que responder al diseñar el producto:
- ¿Qué funcionalidad útil aportamos al usuario y al cliente?
- ¿Cómo se integra esto en el servicio actual?
- ¿Cómo necesita cambiar sus flujos de trabajo actuales para que esto funcione y sea beneficioso?
- ¿Cómo y con qué tecnologías debería hacerse esto?
- ¿Cómo se debe construir un modelo de solución económica?
Pero lo hicimos con bastante cuidado: reunimos a un grupo de expertos de SD entre gerentes de proyecto, gerentes de línea, expertos técnicos, escribimos historias de usuarios, hicimos un mapa de valores, aquí hay una pequeña parte:
en paralelo, junto con los desarrolladores, describimos la arquitectura de alto nivel, obteniendo así un punto de partida en el proyecto. ...
Trabajo SCRUM
Así que nuestras presentaciones: Product Owner, PM, Scrum Master y Development Team. Un sprint de trabajo de 2 semanas. La tarea es organizar el proceso de lanzamiento del producto de tal manera que ...
Pero en serio, era necesario tener en cuenta los requisitos de todas las partes interesadas, lidiar con los dolores y comprender lo que realmente se debe hacer, lo que se puede hacer más tarde y lo que no se debe hacer en absoluto.
Tuvimos 3 grandes áreas de actividad:
- Productos para la automatización en proyectos de servicios en curso. Esto incluye todo lo que ayudará a reducir los costos laborales para brindar un servicio, aumentar la satisfacción del cliente y brindar valor adicional.
- Productos para nuevos clientes. Cualquier cosa que produzca un efecto sorpresa al principio y "enganche" al cliente.
- Productos para automatizar las tareas internas de una organización. Tareas de RRHH, Marketing, IT, Servicio Administrativo, etc.
Logramos establecer el trabajo normal solo en el tercer sprint: más o menos nos dimos cuenta de que debemos enfocarnos en las áreas 1 y 2, porque los gerentes de proyecto hablan de dolor y los líderes de servicios de apoyo hablan de deseos.
No estiraré el artículo y les diré lo genial que es Agile en sí mismo y cómo ayuda mucho. Pero esto es lo que realmente puedo decir después de trabajar en este modo durante unos 30 sprints:
- Scrum es un enfoque de trabajo. Pones recursos y metodología, y obtienes suministros.
- – . , , , . , , , , « », – .
- . , , . , , – . PM – , , , – , – .
Tengo menos experiencia de este tipo, por lo que esta gran y pesada carga recayó en mayor medida en el Product Owner: comparar las expectativas de las partes interesadas con la realidad, comprender claramente las capacidades de mi equipo, tener un ojo limpio, comprender la situación del mercado, equilibrar la dirección de los recursos hacia la funcionalidad útil, experimentos y "mal necesario": seguridad de las soluciones, organización de la arquitectura del servicio, entornos, documentación.
- PM . , . -. Devops , , : , /. , , Agile - , : , , .
- - – . , -. , . , PM -, . , . , , !
No comenzamos el desarrollo desde cero. Tuvimos muchos desarrollos en la empresa que podrían usarse de una forma u otra: solo había dos autoclasificadores.
Sentí un déjà vu cuando recopilé todo esto de diferentes proyectos, divisiones, como una vez recopilé los desarrollos de mi primer proyecto.
Comenzamos a desarrollar el sistema de diálogo con varias bibliotecas de código abierto, y una de ellas fue DeepPavlov. No teníamos mucha experiencia con él, y en nuestras tareas la calidad del reconocimiento resultó mediocre. Pronto cambiamos a Rasa, y las cosas fueron mucho mejor, y después de entrenar el modelo en nuestros datos específicos, obtuvimos un reconocimiento bueno y seguro de los diálogos.
El diseño de los diálogos en sí se realizó manualmente; en ese momento, había personas en SD que asumieron esta tarea. Nuestro desarrollador líder de Python escribió rápidamente un programa de marcado y alimentamos el modelo con un par de decenas de miles de conversaciones. Los fragmentos se tomaron bastante cortos, 3 segundos cada uno, de esta manera el resultado fue mejor.
Inicialmente, teníamos 2 máquinas virtuales en Windows y en Linux, algunos de los servicios solo podían funcionar en Windows. Pero cuando comenzamos a llevar los primeros desarrollos al piloto, rápidamente nos dimos cuenta de que 2 máquinas virtuales para un proyecto es demasiado costoso, necesitamos rehacerlo. Ahora usamos una máquina virtual en Ubuntu para producción. Por supuesto, todos están aislados y cada proyecto tiene su propia área.
También nos dimos cuenta rápidamente de que configurar dos máquinas virtuales, generar y depurar todos los servicios, abrir puertos y otras configuraciones tomaba un tiempo completamente indecente. Luego creamos una solución CI / CD basada en Docker, tanto para el código principal como para la parte ML.
En algún momento del sprint 9-10, nos enfrentamos a una solicitud de muchos clientes para crear su propio sistema de reconocimiento de voz. La mayoría de los clientes no estaban preparados para transferir su información confidencial a las "nubes" a terceros. Entonces, escribimos un sistema de este tipo y ahora podemos ofrecerlo donde es importante tener toda la arquitectura dentro del perímetro de seguridad, por ejemplo, para empresas estrechamente relacionadas con el estado. O colóquelo en nuestra infraestructura, sabiendo con seguridad que los datos sensibles no llegarán a terceros.
Implementamos un sistema de monitoreo de componentes, configuramos controles de salud e integramos el sistema con un canal de chat en Telegram.
Y finalmente, les contaré una sutileza más que puede ser útil para alguien al diseñar su bot de chat. Inicialmente, todo nuestro código era bastante monolítico y era laborioso realizar cambios en él. Hemos dividido el chatbot en dos grandes partes: el bot base y la personalización. Tuvimos que reescribir la lógica, pero gracias a esta separación, pudimos implementar rápidamente los componentes básicos y comunes del bot y editar solo lo que estaba personalizado para cada proyecto específico.
Resultados del proyecto
Entendimos claramente el nicho de nuestra historia: no podremos competir con productos en caja que se han desarrollado durante una docena de años, y esto tampoco es necesario. Nuestro nicho es proporcionar herramientas de automatización en cualquier etapa de un proyecto de servicio, desde la preventa hasta el vencimiento del contrato. En otras palabras, inicialmente no teníamos el objetivo de hacer Google, pero el objetivo era crear un diseñador que ayudara a vender Service Desk, ayudaría a reducir el costo de brindar un servicio y brindaría oportunidades adicionales a los clientes y sus negocios.
También noté un punto interesante para mí: rara vez una solución en caja en el mercado puede cubrir completamente el dolor de un cliente y al mismo tiempo arreglar un precio. O el cliente paga de más por la funcionalidad, que no utilizará más adelante, o algunas de las mejoras deberán ser realizadas por especialistas o especialistas del proveedor seleccionado, si lo acepta.
Y aquí tenemos una tarea de integración interesante y bastante difícil, además de ofrecer puramente nuestras propias soluciones de automatización, construir un sistema para el cliente a partir de nuestros desarrollos y soluciones de terceros que ya están en el mercado, adaptarse a la funcionalidad del cliente y mantener dicho sistema como servicio. Quizás hablaré de los resultados de este trabajo en los próximos artículos, si hay interés.
La mayoría de nuestras herramientas y desarrollos ya se han implementado en los servicios actuales, estamos probando algunas y refinaremos algunas en BAU. El chatbot todavía se siente el peor de todos, hoy es el menos útil para los proyectos, tal vez porque las expectativas ahora son bastante altas. Todo el mundo quiere un bot inteligente que pueda percibir el habla humana, responder con calma a todas las preguntas de los usuarios, poder manejar las interrupciones, tener integración en todos los sistemas, aprender por sí mismo sin intervención humana y, con el tiempo, reconoce cada vez más intenciones.
Pero cualquier desarrollador que esté bien versado en el tema comprende lo difícil que es esta tarea; después de todo, incluso aumentando la funcionalidad y el número de intenciones que un bot puede reconocer, podemos empeorar el reconocimiento de las intenciones existentes. Pero esto fue una digresión; en general, me parece que, no obstante, hemos logrado la tarea principal del proyecto.
Que paso a la salida
1. Asistente de voz inteligente y diseñador de guiones. Cierra la necesidad de automatización del flujo de llamadas entrantes, reconoce el habla del usuario, voz a texto y lo transmite al correo, chat, sistema ITSM, según la configuración. Puede integrarse con un montón de sistemas diferentes, ya sea con conectores listos para usar o con los que escribimos.
2. Marcador con un motor del asistente de voz.Cierra la necesidad de llamar al grupo de números especificado y luego recopila las respuestas de los usuarios según el escenario. Las llamadas regulares son posibles, hay una configuración para el número de preguntas repetitivas para aclarar cuántas veces y después de qué hora devolver la llamada. Almacena datos sobre llamadas realizadas junto con los resultados y la grabación de llamadas. Ahora se utiliza para recordar a los ingenieros sobre la aplicación de parches para un proyecto implementado para un gran minorista internacional de alimentos, en el departamento de recursos humanos al organizar entrevistas para puestos masivos, en planes para recopilar información sobre la calidad de las aplicaciones resueltas en una gran cadena de restaurantes de comida rápida.
3. Un chatbot para crear una aplicación, restablecer una contraseña y un diseñador de scripts para ella.Sabe cómo solicitar información primaria para registrar una solicitud, registrar una solicitud en el sistema ITSM y devolver un número de solicitud. Para cuando se publique el artículo, aprenderá a mostrar una lista de aplicaciones abiertas con la capacidad de agregarles información o cerrarlas. Puede conectarse a diferentes sistemas ITSM, con o sin acceso a la API.
4. Herramienta de control de calidad. Sabe un poco hasta ahora: rastrea las llamadas, reconoce si el operador ha saludado o no, identifica las palabras que generan conflictos, se empareja en un diálogo, tiene una interfaz completa para el controlador de calidad. Lo hicieron por sí mismos, pero puede ser útil en el CC.
5. Autoclasificador.Puede analizar aplicaciones en el sistema ITSM, completarlas y enviarlas a los grupos de soluciones necesarios. Puede tener en cuenta la disponibilidad, carga de trabajo y especialización de los ingenieros. Por ejemplo, puede configurar la lógica de que todas las aplicaciones de EDS deben enviarse a los principales especialistas Vasily o Andrey: si Vasily no está de servicio, la aplicación irá a Andrey, y viceversa. Si no ambos, el ticket se agregará a la línea general de soporte de aplicaciones comerciales. Si Vasily tiene 2 solicitudes y Andrey tiene 1, se enviará una nueva solicitud a Andrey. Puede volver a entrenar el modelo con confianza, aumentando la precisión. La desventaja del sistema es su objetivo.No debe esperar un 100% de precisión del modelo ni trabajar en todo el volumen de aplicaciones. En una muestra de prueba, obtuvimos un 90% de precisión para el 50% de las aplicaciones con datos muy consistentes, donde los usuarios están acostumbrados a trabajar con plantillas. La segunda desventaja es el volumen de pedidos. No tiene sentido entrenar el modelo si tiene menos de 1000 aplicaciones por mes.
6. Herramientas para aplicaciones de resolución automática.Se trata de un conjunto de herramientas de la GUI con scripts que automatizan las acciones estándar de un agente de soporte técnico: recopilar registros de los sistemas, realizar capturas de pantalla, incluso en el modo sombra, actualizar políticas y otras cosas específicas de cada proyecto. La segunda herramienta es la automatización de aquellas aplicaciones donde se requiere aprobación. La herramienta en sí genera una carta para el aprobador con enlaces para aprobar / rechazar y, en función de los resultados, da un comando para proporcionar acceso o genera una carta con un rechazo.
En vez de adios
Se acerca el invierno, el proyecto se cierra a finales de este año,
Gracias por su interés y su tiempo, ¡no se enferme!