Imagine que está llamando a una pregunta al centro de llamadas del banco y obtenga una respuesta. Luego, ven al punto de venta, pero la información obtenida previamente es irrelevante. Para garantizar que se eviten estas discrepancias, decidimos dejar la solución existente creada en el banco en SharePoint, procesamos todo el contenido, identificamos las fuentes de datos y los consumidores, y volvimos a empaquetar toda la información necesaria en un nuevo sistema de gestión del conocimiento, lo mismo para todos los departamentos. En este post compartiremos nuestra experiencia.
Declaración del problema y elección de la solución.
Para empezar, toda la información relacionada con el servicio al cliente, nuestros productos y servicios, tenía que ser unificada. Históricamente, el conocimiento se almacenaba en tres grandes bases de conocimiento creadas en diferentes momentos, de hecho, en diferentes bancos. Al mismo tiempo, uno de los requisitos clave era la capacidad de proporcionar diferentes cantidades de datos, por ejemplo, para puntos de venta y para ATP (centro de llamadas). En el primer caso, la información detallada es importante: cuando las personas acuden a departamentos fuera de línea, esperan escuchar todos los detalles sobre temas de interés. En el segundo caso, por el contrario, una breve información es suficiente; lo principal es que se proporcione de forma rápida y clara.
La tarea se complicó por el hecho de que teníamos hasta seis clientes internos. Y, en consecuencia, diferentes tipos de requisitos. Todos tenían diferentes criterios con respecto a la funcionalidad, el rendimiento y el soporte. Por ejemplo, la presencia de SSO, integración con Active Directory, etc. Las capacidades de implementación rápida del equipo fueron importantes. Esperábamos que el nuevo sistema reduzca el tiempo de servicio para el 25% de las llamadas al centro de llamadas en 5 segundos. También reducirá el tiempo de entrenamiento. Anteriormente, el 3% de todo el tiempo de trabajo se gastaba en él, y cuando se trata de más de 30,000 trabajadores, se gastan gastos considerables.
Además, durante el proyecto, VTB estaba en la etapa de fusionar dos grandes bancos en su estructura, y los clientes del sistema futuro estaban en diferentes subredes, en diferentes segmentos. Todo esto tenía que combinarse y proporcionarse a los empleados que trabajan con el sistema, acceso de extremo a extremo, teniendo en cuenta los roles, varios niveles de acceso a la información, etc. Fue necesario para resolver muchos problemas de infraestructura adicionales.
Ponemos todos los requisitos y criterios necesarios en una tabla de puntuación. Analizamos todas las soluciones clave existentes en el mercado, tanto rusas como extranjeras, subimos porciones de nuestro contenido a ellas y evaluamos qué funciona. Y al final, nos decidimos por un único sistema de gestión del conocimiento de KMS Lighthouse. Con la introducción, nos ayudó el equipo del Grupo DIS, que ofrece KMS Lighthouse en el mercado ruso.
2500 artículos en 16 plantillas para 60 mil usuarios
Hay dos entidades clave en nuestro nuevo sistema de gestión del conocimiento: "plantilla" y "artículo". Un artículo es una página formalizada con información. El mismo artículo se ve diferente para todos los grupos de roles de usuario (empleados bancarios). Los grupos se forman según la afiliación organizacional, funcional o comercial de los empleados.
Después de analizar el contenido que tenemos, nos dimos cuenta de que estábamos tratando con 2500 artículos. Este mar de información necesitaba descomponerse en el número mínimo de plantillas. Además, los artículos deberían haber conservado la flexibilidad descrita anteriormente. Hubo mucho trabajo manual en la creación de plantillas, coordinación y reconciliación. Pero al final, logré cumplir con 16 plantillas; para 2500 artículos, este es un buen nivel de sistematización.
Trabaja en contenido
Se distribuyen 16 plantillas en tres grupos de administradores de contenido. El primer grupo es responsable del contenido asociado con el centro de llamadas. El segundo es para productos, servicios e información relacionada. El tercero es el bloque de contenido de la unidad operativa (DOPB), nuestro back office. Además, tenemos una unidad metodológica que opera a nivel bancario. Casi toda la información del banco pasa a través de él, como a través de un filtro, y como resultado, solo queda la información que debe colocarse en la base de conocimiento.
Discutimos una división más compleja. Se pensó en presentar a los "propietarios" de los grupos responsables del proceso y el sistema. Discutimos la posición del "editor jefe", quien verificará todos los cambios. Pero al final, decidimos centrarnos en tres grupos, ya que el contenido está claramente dividido entre ellos.
KMS Lighthouse le permite construir rápidamente varios niveles de coordinación, pero decidimos no complicar este sistema y, a nivel de administradores de contenido, creamos dos niveles: los que escriben y los que publican. En el último nivel, se destacan aquellos que son responsables de todo el contenido de su grupo. Es cierto que aquí surgió la cuestión de hacer materiales sobre ventas exitosas a la división de alimentos, pero hasta ahora decidieron dejar todo como está.
Por lo tanto, la base de conocimiento se puede desarrollar sin demora. Supongamos que un departamento de alimentos desea publicar de inmediato información sobre un nuevo producto. Envía una solicitud por correo al administrador de contenido: "Colegas, necesitamos publicar este artículo aquí". Después de publicar a través de mecanismos de retroalimentación, el refinamiento está en marcha: en algún lugar, la información puede no ser suficiente, en algún lugar algo no está de acuerdo con la plantilla. Y así sucesivamente hasta que la unidad y el administrador de contenido estén satisfechos. Ahora solo presentamos los elementos necesarios para esta interacción: notificaciones, encuestas, formularios de aprobación. Si el artículo que se está creando cubre las áreas de diferentes grupos de administradores de contenido, entonces todos serán responsables de su propia pestaña.
Se asigna un servidor de aplicaciones separado para los administradores de contenido, donde puede editar artículos o crear nuevos usando plantillas existentes. Aquí puede obtener las estadísticas necesarias sobre las consultas de búsqueda, la relevancia de las respuestas, las conversiones, etc. Los artículos no solo se pueden cambiar, sino también optimizar, por ejemplo, crear metaetiquetas para mejorar la búsqueda. Además, la búsqueda se puede mejorar agregando por la fuerza ciertos artículos a ciertas consultas. Esto se llama "elección del editor"; cuando realiza una búsqueda, el usuario ve dichos materiales en una columna separada.
Búsqueda base
En SharePoint, las personas están acostumbradas a la estructura de árbol de presentar información e interactuar con pestañas. KMS Lighthouse implica el uso de una búsqueda completa. Cuando 60 mil usuarios trabajan con el sistema (un promedio de aproximadamente 1600 a la vez), vale la pena pensar en el equilibrio de carga. Ahora KMS Lighthouse se ejecuta en 10 servidores. Cada uno desplegó dos máquinas virtuales. Un grupo de 20 máquinas virtuales funcionan. Entre ellos hay un balanceador bancario.
La búsqueda se basa en tres motores de búsqueda que indexan todo el contenido. Los índices de búsqueda se crean teniendo en cuenta las solicitudes entrantes, su frecuencia. La relevancia de las respuestas y su posición en los resultados de salida dependen de esto. Lighthouse analiza las solicitudes y puede presentarlas en forma de 16 informes diferentes, con la ayuda de los cuales los administradores de contenido trabajan para llenar el sistema.
Características adicionales
Todos los empleados que trabajan con el sistema se dividen en aproximadamente 35 grupos de roles. Cada uno tiene acceso a ciertas partes de los artículos. Un usuario puede estar en varios grupos; luego ve el contenido de todos estos grupos a la vez.
Los grupos están integrados con puertas de enlace de correo electrónico y SMS. Cuando trabaja con un cliente bancario, un empleado puede enviarle rápidamente la información necesaria, por ejemplo, justo durante una consulta telefónica. Si, por supuesto, se puede enviar información; Los artículos sobre divulgación (y admisibilidad impresa) indican atributos individuales. No es necesario reescribir y copiar y pegar nada.
Yandex.Maps también se integra en la base de conocimiento, a través de la cual los empleados ven cuán ocupados están ciertos departamentos. La información se actualiza cada media hora. Por lo tanto, después de determinar en qué departamentos el cliente puede recibir este o aquel servicio, los empleados pueden aconsejar dónde es mejor dirigirse exactamente para ahorrar tiempo.
KMS Lighthouse está integrado con nuestro sistema front-end y puede llevarse directamente a su interfaz como un widget. En él, puede hacer una solicitud rápida e ir inmediatamente al artículo, como en cualquier motor de búsqueda.
Así es como se organiza nuestra nueva base de conocimiento. Ahora lo estamos finalizando y esperamos que no solo los empleados sino también los clientes de VTB aprecien el efecto positivo de la implementación de KMS Lighthouse.
En conclusión, queremos compartir nuestra alegría. En enero, nuestro Business Wikipedia anunció el proyecto del año según el Global CIO. Lo mantendremos informado y le diremos qué novedades le aplicamos y cómo ayuda al trabajo.