¿Con qué frecuencia se ha encontrado con administradores de aplicaciones a quienes les gusta lidiar con la resolución de incidentes?
Además, un flujo significativo de incidentes en la segunda línea de soporte son los llamados incidentes comerciales, es decir, incidentes que están asociados con una violación de la lógica del proceso comercial en el servicio o con acciones incorrectas del usuario.
Pudimos eliminar esta funcionalidad de la segunda línea tanto como sea posible, transfiriéndola a un equipo separado formado por los empleados de la primera línea de soporte técnico.
Le diremos cómo lo hicimos y qué dificultades encontramos en este artículo.
Tradicionalmente, la segunda línea de soporte técnico se dedicaba a resolver incidentes en los sistemas, aquellos que brindan soporte para el servicio en sí, realizan ajustes de configuración del producto, entornos de prueba, monitoreo del sistema, instalan parches, participan en turnos de guardia, etc. Y la solución de incidentes en estos equipos a menudo estuvo acompañada de un "principio residual" (a menos que esto sea, por supuesto, un incidente con prioridad crítica), sin embargo, en la mayoría de los casos se ajustan a los SLA asignados.
Al darnos cuenta de que muchos de los incidentes (y en la parte frontal de los sistemas, detrás de cada uno) podrían ser potencialmente el problema del Cliente del Banco, decidimos minimizar el tiempo que llevó completar estas solicitudes, pero no comenzamos aumentando el número de equipos de soporte, sino analizando cada una de las etapas de este proceso.
El proceso de apoyo tradicional en el Banco se construyó de acuerdo con el esquema clásico y tuvo el siguiente aspecto
Fig. 1 Esquema de la organización del proceso de soporte (was)La solicitud que pasó por la primera, segunda y tercera líneas de apoyo, se distribuyó entre ellas en las siguientes proporciones: 15:75:10.
La primera línea , Service Desk, recibe, procesa y enruta llamadas utilizando los siguientes canales de comunicación:
- teléfono: 8% del número total de llamadas
portal de autoservicio: 83% del número total de llamadas
correo electrónico: 4% del número total de llamadas
chat bot en Viber y Telegram - 5% del total
La primera línea también se ocupa de resolver incidentes de forma remota en las estaciones de trabajo de los usuarios, proporcionando acceso a los sistemas de información del Banco. Escribí sobre el trabajo de esta unidad en un artículo separado -
enlace aquíLa segunda línea : equipos de mantenimiento de software de aplicaciones + infraestructura + DBA + ...,
La tercera línea son los equipos de desarrollo.
Dado que los sistemas bancarios están integrados entre sí, la ocurrencia de un incidente en uno de los sistemas a menudo es el resultado de un error que ocurre en otro sistema. Y los errores en los "sistemas de respaldo" aparecen principalmente en el "frente", lo que tiene un impacto directo en los usuarios.
La identificación de la causa raíz de la ocurrencia en este caso requiere la participación de varios equipos de escolta y, como resultado, una serie de rutas.
Al tomar una muestra de incidentes durante varios meses y analizar su ciclo de vida, descubrimos que pasan la mayor parte de sus vidas en línea, esperando un análisis del equipo de apoyo de la segunda línea (a veces hasta el 80%), periódicamente, con reasignación entre equipos y un largo período de tiempo. correspondencia en el cuerpo de la solicitud.
En el proceso de analizar y analizar estos incidentes, descubrimos que para resolver los errores de integración, los colegas necesitan información de los sistemas de integración adyacentes (registros, análisis de impacto, etc.), para lo cual recurren entre sí, enrutando los incidentes.
Para minimizar el tiempo de resolución de incidentes, como proyecto piloto, decidimos crear un equipo integrado
multifuncional de empleados de primera y segunda línea para resolver incidentes en los sistemas frontales del Banco: banca por Internet, banca móvil, servicios de envío de mensajes (sms y push) + frente principal - Sistema de oficinas bancarias.
Este comando es intermedio entre la primera y la segunda línea, una línea y media de soporte, que llamamos "Frontline".
Ya en la etapa de formación de este equipo, encontramos ciertas dificultades, incluso desde el lado de los gerentes de segunda línea, por lo que la transferencia de incluso un empleado a este proyecto desde cada uno de los sistemas significó una disminución en la capacidad del equipo actual. Y los propios empleados de segunda línea, que se suponía que iban a participar en el piloto, no estaban ansiosos por sumergirse de lleno en la resolución de incidentes.
A través de negociaciones iterativas, pudimos acordar que la tarea principal de los participantes de segunda línea en este proyecto es capacitar a los empleados de primera línea, crear conjuntamente una base de conocimiento común, construir procesos de interacción interna, proporcionar el acceso necesario y luego volver gradualmente a su unidades.
La ubicación de la línea de frente era el Centro de TI del Banco en Obninsk.
La primera línea de la línea de soporte de uno y medio fue la siguiente:
- dos personal de apoyo de primera línea
- dos empleados del grupo de apoyo del sistema de front office
- dos empleados del grupo de apoyo de banca por Internet y banca móvil
- un empleado del grupo de soporte de servicios de información al cliente (sms y push)
El enfoque principal del equipo se centró en 3 indicadores:
- VELOCIDAD : el 70% de las solicitudes recibidas por el equipo deben resolverse en no más de 8 horas hábiles
- CANTIDAD : el equipo no puede enrutar más del 20% de las solicitudes a la segunda línea de soporte
- CALIDAD : la proporción de incidentes redescubiertos por los usuarios no debe superar el 3%
fig. 2 Proceso de manejo de incidentes de primera línea
La siguiente dificultad que encontramos al comienzo del piloto fue la falta de un equipo en nuestro entendimiento inicial, si lo hubiera.
A pesar del hecho de que los empleados de Frontline estaban cerca en la misma habitación, no hubo intentos de cambiar a la funcionalidad cruzada, el intercambio de experiencias, la interacción significativa en el interior. Como resultado, cada participante, como antes, estaba concentrado en resolver las solicitudes a través de su sistema: alguien estaba "plagado" de incidentes, alguien era claramente más libre.
Se decidió "cambiar los sistemas" dentro del equipo, por ejemplo, para que el representante del soporte de banca por Internet ya no resuelva incidentes en su sistema, sino que comience a procesar solicitudes para el sistema de recepción, y el representante del soporte del sistema de recepción comenzó a resolver incidentes en los servicios de notificación, etc. d.
Por qué
- Intente llegar a la universalidad para que los empleados puedan cambiar entre incidentes de diferentes sistemas, distribuyendo de manera uniforme la carga en todos los participantes;
- Proporcionar a los niños un conocimiento suficiente de los sistemas relacionados que los ayudarán a identificar rápidamente la causa del error de integración;
- Establecer comunicación dentro del equipo;
Hice las cuentas necesarias, proporcionó acceso a los registros de la aplicación y la base de datos, ¡y más! :)
Inicialmente, la resolución del incidente se redujo. Está claro que cuando no conoce las complejidades del sistema y también necesita resolver incidentes en él, no es una tarea fácil. Pero los muchachos comenzaron a recurrir entre ellos para pedir ayuda, estudiar y actualizar la base de conocimiento general, y gradualmente las cosas se fueron.
Además, todos los días comenzamos a sostener pequeños stand-ups al comienzo de cada día de trabajo, cerca de las hojas de papel que pegamos a las paredes y con indicadores diarios. Discutimos y terminamos con un marcador, regocijándonos en su implementación o discutiendo la razón del fracaso, si no pudiéramos lograrlos.
Posteriormente, por supuesto, reemplazamos estas hojas de papel con paneles en línea.
fig.3 Tablero de control de eficiencia de primera líneaAquí, necesito decir un especial "gracias" al jefe del equipo de soporte para el sistema de recepción del Banco, que asumió el papel de liderazgo y cultivó el desarrollo del equipo desde adentro. Alexey, ¡gracias! :)
En los primeros dos meses, el equipo no pudo hacer frente a los objetivos establecidos, el proceso de capacitación estaba en curso, la base de conocimientos se actualizó.
A partir del tercer mes del proyecto piloto, comenzamos a encajar en los objetivos, y después de 6 meses, incluso comenzamos a superarlos.
Fig. 4 Proyecto piloto de primera línea, primeros indicadoresPronto quedó claro que el piloto "despegó" con éxito, y era aconsejable escalar el proyecto.
Gradualmente, comenzamos a agregar competencias en otros sistemas al equipo, retirar empleados de segunda línea y agregar empleados de la mesa de servicio.
Poco a poco, cambiamos a "T - funcionalidad cruzada", cuando a cada participante se le asignó un sistema principal y dos adyacentes.
fig. 4 Estadísticas comparativas para 2018 sobre el momento de resolver solicitudes entre Frontline y los equipos de seguimiento de segunda líneaEn 2018, el equipo de Frontline cerró más incidentes que cualquier otra unidad de escolta en el Banco. Los muchachos excedieron significativamente los objetivos establecidos, demostrando una vez más que el trabajo en equipo y las competencias interfuncionales pueden lograr resultados significativos.
Para la segunda línea de soporte, "Frontline" hoy es un "escudo" confiable, que reduce significativamente el flujo de llamadas que reciben.
Fig. 5 El número y la proporción de incidentes resueltos en Frontline (Fig. - Equipo1) en relación con incidentes resueltos en la segunda línea para todos los sistemas del BancoHoy, todos los participantes de Frontline son empleados de Service Desk que resuelven incidentes en los principales sistemas frontales del Banco, cumpliendo los objetivos establecidos.
Además, "Frontline" es el siguiente paso para los empleados de Service Desk en nuestra escala profesional, antes de pasar a la segunda línea de soporte.