Plataforma CC
Sumario
- 1 Antecedentes
- 2 Objetivos
- 3 Solución Arquitectónica
- 4 Características Funcionalidades
- 5 Negocio
- 5.1 Innovación
- 5.2 Plataforma
- 6 Planes Futuros
- 7 Problemas Encontrados
- 8 Bugs Conocidos
Antecedentes
Este proyecto tiene nacimiento con el inicio de la pandemia, cuando todas las condiciones con que se operaba la empresa y que estaban completamente perfeccionadas, se vieron desafiadas en todos los sentidos. La plataforma CC nace para responder a las nuevas exigencias que vienen con el translado de la operación del call center a un esquema completamente homeoffice, donde supuestos que hasta entonces se daban como precondiciones mínimas para operar se tienen que revolucionar en el transcurso de unos días.
Algo tan simple como la supervisión de las personas ó la protección de datos que normalmente estarían protegidos por normas de conducta y reglas operativas, dejan de estar vigentes y nos enfrentan a muchos desafíos a los que la plataforma CC intenta responder.
Objetivos
Desde el inicio del proyecto se plantean una serie de objetivos fundamentales que deben cumplirse con la plataforma:
1. Permitir el monitoreo del personal de forma tal que permita mantener/mejorar la productividad de COA
2. Proteger la información sensible de nuestros clientes, de forma tal que sin importar el esquema remoto, se pueda garantizar.
3. Ofrecer un esquema de asignación flexible que no requiera la intervención constante de los supervisores para asignarle tareas al personal a su cargo.
4. Ofrecer esquemas que garanticen la calidad en la ejecución de las tareas, dado que al no poder estar los supervisores presentes monitoreando físicamente es necesario alguna alternativa.
5. La solución debe permitir operar en un esquema de crowdsourcing de tal forma que se puedan atender microtareas con personal tanto externo como interno cuando se determine conveniente.
6. Se debe buscar que la plataforma opere sobre microtareas que resulten tan simples que las curvas de aprendizaje/capacitación y los tiempos de ejecución sean lo mas pequeñas posibles.
Solución Arquitectónica
Características Funcionalidades
La plataforma CC cuenta con las siguientes características:
- Ingesta.
Existen varias formas de poder ingresar una tarea en crowd. Los métodos soportados son:
- Webservice
- Kafka
- Observer DB
- Motor de tareas
- División a microtareas
- Suspensión de tareas
- Rol de asignación
- Álgebra de servicios
- Clonación
- Resolución
- Fronts
- OCR adecuado a la microtarea
- Proveedor teléfónico Integrado
- Botón personalizable para invocar servicios
- Paneles versátiles
- Soporte de documentos en imagen y pdf
- Integración de sistemas externos
- Logs de seguimiento de la trayectoria de una tarea
- Captura de pantalla para manejo de evidencias
- Soporte de tablas para comparar información.
Negocio
En la plataforma Crowd, existen diferentes tipos de tareas, las cuales se pueden reutilizar y adaptar conforme al Proceso de Negocio que se requiera en el momento, ya que muchos productos que vende la financiera, necesita cierto tipo de validaciones y verificaciones, las cuales es muy probable que se requieran en algunas otros productos.
Por lo tanto en la plataforma Crowd existen Tareas las cuales se repiten en diferentes Procesos de Negocio, por lo tanto a continuación se tiene una tabla de relación entre los Procesos de Negocio, Tasks & Podlet
CAPTURA DE DOMICILIO BAJO COSTO
Innovación
Plataforma
Los procesos que conforman la plataforma de CC van desde la forma en la que se ingesta la tarea hasta la resolución de la misma. Para ello diversos componentes participan en cada una de las etapas de acuerdo al tipo de solicitud que se esté procesando. Los servicios y componentes web se encuentran enlistados en la siguientes secciones.
Ingestión de tareas por webservice
La ingestión de tareas por webservice consta de la invocación del servicio de http-inbound, los cuales procesan las tareas dependiendo de qué endpoint sea consumido validando que los datos de entrada sean los requeridos para el flujo que se va a generar. La validación de datos puede ser por medio de json schema o por la configuración de tareas por kafka.
Ingestión de tareas por kafka
La ingestión de tareas por kafka es llevada a cabo por un microservicio que se encarga de escuchar los mensajes que llegan a los tópicos de solicitudes y domiciliación. El modelo utilizado para la ingestión se basa en procesar sólo aquellos mensajes que cumplan con las condiciones configuradas para las tareas. Esta configuración se encuentra almacenada en una entidad de la base de datos del API Core, donde existe un endpoint que consulta dicha información.
Para modificar la configuración se debe acceder a la vista administrativa de configuración de tareas iniciando sesión en la plataforma, entrar en la sección de tareas de kafka y dar click en DATACONF de la tarea a modificar donde se nos mostrará un json con la estructura de la Configuración de ingestión de tareas.
Ingestión de tareas por observer
El modelo de ingestión de tareas por observer se basa en hacer una consulta periódica con ciertos criterios, si estos se cumplen, se procesa la información de los datos consultados para procesarla, en caso contrario, simplemente se espera hasta la próxima iteración. La configuración del tiempo y el procesamiento de la información se llevan a cabo por diferentes DAGS.
Ingestión de tareas por sheets
La ingesta de tareas por sheets, como su nombre hace referencia se trata de generación de tareas dentro de la plataforma Crowd partiendo de la carga de un archivo Excel mediante el front podlet-web-sheet-uploader, la extracción de datos para publicación de tareas es realizada mediante el scheduler layer-api-sheet -publisher-service el cual lo hace partiendo de un template basado en json dentro del cual se indica información sobre el rango de datos (columnas desde, hasta) de extracción, indicador si cuenta con encabezado o no así como numero de fila donde se encuentra el encabezado y por ultimo lo mas importante un formato de nombre el cual es utilizado para realizar la validación del nombre de las hojas del libro que serán procesadas y enviados al servicio layer-api-inbound-http-service para su publicación como tareas.
El scheduler encargado de la publicación se encarga de realizar validaciones del template de extracción, dichas validaciones son utilizadas para invocar al servicio layer-api-excel-service el cual se encarga de extraer la información (rango de datos, encabezados) en formatos json del conjunto de reglas [Archivo][Hoja][RangoFilas] [RangoColumnas].
La función de layer-api-excel-service es ser el intermediario entre el scheduler de Excel y el archivo de Excel, ya que es el encargado de procesar todas las peticiones de extracción de información del archivo, datos, encabezados, nombres de hojas, entre otros datos.
Modelo de calidad
Primer Modelo de Calidad
Desde su origen el cuidado de la calidad de los procesos ejecutados fue un objetivo fundamental. Con esta motivación intrínseca, se diseñó un modelo basado en los siguientes elementos:
- Experiencia del ejecutivo en la ejecución de tarea. (score)
- Naturaleza de la tarea (considerando que no todas las tareas se pueden atender mas).
- Permisos que tienen los crowdworkers para atender tareas (perfil).
- Capacidad en tiempo real de atención (ejecutivos conectados con el perfil)
- Tiempo de ejecución de una tarea.
Con este modelo se lanzó la primer versión de plataforma y funcionaba básicamente de la siguiente forma:
- Se publicaba una tarea en espera de atención de un operador.
- Cuando un operador está disponible para atención y se le asigna una tarea de forma simultánea se notifica al motor de clonación.
- El motor de clonación evaluará si el tipo de tarea es "clonable" (es decir que se puede ejecutar mas de una vez) en caso de que sea continua, si no termina su trabajo.
- Si la tarea es clonable se obtienen sus valores preestablecidos de clonación para obtener la probabilidad de clonación que debe aplicársele, si se decide clonar se continua, si no termina su trabajo.
- Cuando se decida clonar, entonces se revisa si hay ejecutivos con el perfil adecuado conectados, si no los hay se termina con el proceso, si los hay se continua.
- Se publica una tarea exactamente igual para atención de crowdworkers, con la regla de ponerle una excepción para que no le sea asignada al mismo operador al que ya fué asignada.
- Cuando la tarea clonada ha sido publicada, queda en espera de atención, hasta que un operador reporte su disponibilidad, momento en cual se le asigna, siempre que no haya sido el operador al que se le asignó la tarea original.
- Una vez que ambas tareas han sido resueltas, se realiza la resolución de acuerdo a la siguiente regla:
.En caso de que ambas tareas lleguen a la misma resolución ("APROBADA", "RECHAZADA", "ERROR"), se dá la resolución como correcta y se le dan puntos a ambos operadores tomando en cuenta en el tiempo que tardó en realizarla contra el promedio que se tiene de atención del mismo tipo de tarea.
Si, por el contrario la respuesta de las dos tareas no coincide, la plataforma genera una tercer tarea de calidad que se publica para ser atendida por un supervisor, el cual debe dar resolución a la misma. Una vez ocurrido lo cual, se toma como respuesta "oficial" y se verifican respuestas de las tareas anteriores, para verificarlas contra la del supervisor, en caso de coincidencia se le dan puntos considerando el tiempo tomado para la resolución, en otro caso no se le suman puntos (la consecuencia de esto es que su score disminuye debido a que es un promedio ponderado de las tareas realizadas).
Segundo Modelo de Calidad
Conforme se fueron añadiendo funcionalidades y mejorando características a la plataforma CC, se lograron manejos altamente configurables y muy finos de diversos escenarios, desde roles específicos para atender una microtarea dependiendo de su información de entrada, hasta poder configurar el canal de ingestión y/o publicación siendo ya no solo posible atender microtareas desde crowd, sino se ha abierto la posibilidad de atender microtareas usando Findepmovil y Hawking.
Con todos estos cambios, se agregaron nuevas características que obligaron a que el modelo de calidad tuviera que ser reformado para poder satisfacer los nuevos requerimientos. A continuación se enlistan los cambios que se realizaron para extender el modelo de calidad en su segunda versión:
- Soporte de configuración de activación/desactivación de por microtarea específica tomando en cuenta los datos de evaluación.
- Desvinculación del modelo de calidad a un perfil de usuario (hasta ese momento todos los que atendían tareas que compartían front se sujetaban bajo las misma métricas de calidad).
- Recálculo automático de valores de evaluación aplicables en la ejecución del proceso de calidad.
- Segmentación específica de las microtareas para que pueda ser rastreado el modelo de calidad con el que fueron evaluadas.
- Posibilidad de recalibrar usando un interfaz web los valores establecidos para determinar la clonación de una tarea o no.
- Soporte de tareas secuenciales para clonación.
Motor de tareas
En el corazón de la plataforma se tiene un componente que permite hacer la determinación dinámicamente sobre todos los temas asociados a la publicación de una tarea, el motor de tareas.
El motor de tareas está compuesto por dos partes base:
- Publisher. Se encarga de determinar TODOS los aspectos de publicación de una tarea. El publisher es el encargado de deteminar los siguientes elementos para la publicación de una tarea:
- Conjunto en el que se dividirá la tarea como microtareas
- Tipo específico de microtarea que debe publicarse en base a los datos particulares
- Builder. Es el responsable de construir una resolución apartir de las resoluciones de las microtareas asociadas a la tarea.
Para la configuración del motor de tareas se emplea una grámatica formal que se interpreta usando JMESPATH.
Configuración del motor de tareas configuración del motor de tareas
Interpretes Web
Son aquellas interfaces que interpretan los datos y las funcionalidades con las que cuenta la resolución de tareas. Tienen la capacidad de integrar tanto elementos externos como internos así como flexibilidad para funcionar de manera distinta basado en cuestionarios especificados para cada microtarea.
Para más detalles puedes revisar la lista de interpretes web.
Resoluciones
Scheduler
El scheduler consiste en una red de microservicios que estan dirigidos a una base de datos tipo REDIS, el cual es un motor de base de datos en memoria, basado en el almacenamiento en tablas de hashes pero que opcionalmente puede ser usada como una base de datos durable o persistente.
El servicio que se utilizan para el manejo de asignaciones, desasignaciones, eliminado de hashes y modificacion de los mismos es el servicio layer-api-event-bus-service.
Para la publicacion de tareas y monitorizacion de redis se utiliza el servicio layer-api-event-handler-service.
Colas y Hashes
La estructura dentro de REDIS se divide en 2 objetos fundamentales: las colas y los hashes.
Colas
Las colas o queues en redis es una lista de elementos que funcionan principalmente para el manejo de asignaciones o para el almacenamiento de ids.
- TaskList-P-{(#)}
Esta cola es de prioridad, donde # es la prioridad de las tareas de Crowd, yendo de -2 a 3, siendo -2 la prioridad mas alta, donde se encuntran tareas de rápida resolucion, como videollamada.
Esta cola contiene objetos del tipo ListTaskItem
- BusyWorkers{(id)}
Esta cola contiene una lista de strings, donde cada uno es el id de un worker que esta con una tarea asignada.
- {(empresa)}-{(sucursal)}
Esta cola contiene los datos de las tareas asociadas a findepMovil, para su asignación del tipo Pull.
Contiene objetos del tipo ListTaskItemForBranch
- {(sucursal)}
Esta cola contiene los datos de las tareas asociadas a hawking, para su asignación del tipo Pull.
Contiene objetos del tipo ListTaskItemForBranch
Hashes
Los hashes son objetos con una seria de atributos, los cuales pueden ser strings, numericos o booleanos.
- TaskHash{(id)}
El hash TaskHash contiene los elementos necesarios para renderizar una tarea en el front, así como información única del segmento de la tarea.
La estructura del hash es del tipo TaskHash.
- WorkerHash{(id)}
El hash de workers contiene informacion de las tareas asignadas, preasignadas y el tiempo de asignación de la tarea.
La estructura del hash es del tipo WorkerHash
Machine Learning
En la parte de Machine Learning, básicamente, es una red de microservicios con un modelo distinto para la detección de patrones con el objetivo de minar datos o de protección a la información del cliente. A continuación se describirán los servicios que hacen posible esto.
OCR
El ocr es un microservicio con la finalidad de hacer una mineria de datos al texto encontrado en una imagen. Para esto se utiliza el api de google GOOGLE VISION, la cual nos permite obtener el texto encontrado en una imagen y las posiciones de cada una de las palabras y caracteres.
Posteriormente el OCR con sus algoritmos especializados en la minería de datos, obtiene información sensible del documento como lo es el nombre completo de un cliente, direcciones, CURPs, clabes interbancarias, números o claves de rastreos, etc.
La minería de datos es especializada por cada tipo de documentos donde están soportados INEs, IFEs, CURPs, comprobantes de domicilio tipo CFE y tipo TELMEX, además del formato generado por SPEI después de una transferencia bancaria. layer-api-ocr-service
YOLO v3
El servicio de yolo es una red neuronal convolucional conocida como YOLO (You Only Look One), la cual es la encargada de la localización de regiones con información sensible de un tipo especial de documento.
La red neuronal YOLO fue entrenada con una base de imágenes donde encontramos INEs, IFEs, Comprobantes de domicilio CFE y TELMEX, de las cuales se ubicaron las regiones donde esta información como nombre, domicilio y curp.
Con este entrenamiento la red es capaz de retornar las coordenadas donde se encuentra esta información, ya etiquetada por el tipo que es, y finalmente con los servicios de procesamiento de imagen podemos proporcionar a la plataforma una imagen con información sensible bloqueada o recortada. layer-api-yolo-service
Biometría
El servicio de biométricos es un microsrvicio especilizado en la parametrización de rostros humanos en un vector característico, el cual nos proporciona una forma de medir cual es el parentesco entre 2 rostros.
Esta escrito en python bajo el framework de Django, el cual es optimo para el manejo de librerías de machine learning como Tensorflow y Dlib, donde se utiliza esta ultima para el caso de los biométricos.
La libreria Dlib contiene una red neuronal tipo RESNET-54 donde su estrada es una imagen parametrizada con uno o mas rostros humanos, y su salida una serie de vectores de 128D, tantos como rostros humanos se encuentren en la imagen. layer-api-biometric-service
Planes Futuros
Problemas Encontrados
Bugs Conocidos
Videollamada
Podelt: Cvideocall
Minimizar el navegador del móvil al momento entre ingresar el otp y al inicio del video
¿Que pasa?
En algunas ocaciones el video se pausa, por lo que tecnicamente el web socket detecta que el cliente sigue en el proceso, pero como el video esta pausado, puede tardar ahi minutos y en el proceso el operador tendría minutos la tarea sin ver a alguien.
En algunas otras ocaciones, el video sigue corriendo, por lo que si el cliente minimiza, y el video pasa, el cliente no se da cuenta sobre el boton de "aceptar la grabación" por lo que el proceso terminaría y el operador se le desasignaría la tarea.
¿Que debería pasar?
