Desde hace ya varios meses en Smartfactory Software Developments nos planteamos el reto de completar nuestro planificador de horarios inteligente Oplanning con un módulo que verificara el cumplimiento del mismo y pudiera cerrar el circulo base mínimo para comercializar el producto en entornos productivos reales. La planificación de horarios, por muy fácil que pueda ser gracias a la inteligencia artificial que potencia OPlanning,  debe ser revisada para verificar su cumplimiento, así que decidimos crear un nuevo módulo llamado PCM (presence control module) para poder implementar de forma eficiente Oplanning en un entorno productivo.

Previo a este análisis, decidimos crear una aplicación, independiente de OPlanning que nos sirviera como base de decisiones y como prueba abierta de una app para registro horario. Debía ser una aplicación sencilla pero elegante de un registro de tiempo para autónomos y personas que necesitaran realizar un pequeño control de los tiempos dedicados a tareas en teletrabajo. En base a esta premisa nació Telework-Time para que de forma gratuita cualquier persona pudiera controlar el tiempo y nos aportara feedback al respecto y poder inferir la experiencia de usuario de la UI para una futura aplicación de registro horario enlazable a Oplanning.

El reto de crear un módulo de control de presencia se basa en un análisis muy detallado sobre cómo hacer una herramienta que sea muy eficiente, sencilla pero potente y sobre todo muy escalable ya que la variedad de tamaños de empresa y número de empleados puede variar de decenas a cientos o miles y el número de terminales de registro horario puede también ser muy variable. Conclusión: el módulo debía poder escalarse horizontalmente de forma eficiente y automática. Hoy por hoy, la tecnología en la nube nos ofrece toda la potencia necesaria, y el balanceo de carga eficiente para poder paralelizar el cálculo en background necesario en el módulo PCM y la paralelización de los threads workers del módulo, pero la arquitectura de nuestra aplicación debe ser compatible con dicha infraestructura en cloud y sobre todo pensada para que cuando eso ocurra se procesen los datos sin redundancia, no relentice el sistema o inhabilite los terminales por un mal escalado.

No sólo es importante el acceso de recursos de red, sino que los cálculos en background realizados para proporcionar los datos en tiempo real de las diferencias entre el horario planificado y el horario real en el registro horario se realicen de forma continua y estén disponibles para ser monitorizaras desde el Frontend o configuradas en el propio backend para que se emitan las alertas necesarias a los supervisores y  poder desviar recursos para evitar roturas en la cadena de producción. 

En cuanto al reto de conseguir un módulo sencillo pero a la vez potente es donde se empieza la magia del análisis. La sencillez se refiere a cómo interpretar los cómputos horarios y diferir qué nos gustaría como supervisores de un sistema obtener. Qué es lo mínimo y qué es lo necesario advertir para tomar decisiones, pero a la vez, tener en cuenta que las diferencias horarias implican saldos acumulados que deben ser extraídos en un momento dado para configurar las bases de rendimiento y en consecuencia los salarios apercibidos de los empleados, sin olvidar que los cálculos en las capas de decisión deben ser rápidos para poder computar miles de registros horarios pero suficientemente flexibles para no computar los registros que ya hayan sido procesados por un hilo paralelo en otro módulo, o de una fecha en concreto. Toda esta complejidad debe tratarse con elegancia y la flexibilidad necesaria para que un determinado cliente pueda alterar el funcionamiento base de la solución respecto a sus necesidades. No es raro que un cliente por ejemplo, establezca un tiempo de cortesía entre el inicio del horario planificado de hasta 10 o 15 minutos para determinar que no se ha producido una ausencia y enviar una alerta al supervisor, sino un retraso de entrada. A su vez, nos podemos enfrentar en un futuro a peticiones específicas de nuestros clientes (lo que nosotros llamamos una CSA, client special adaptation), para que el módulo se comporte de forma no estándar para clasificar los tramos de tiempo, me refiero a pausas o roturas productivas demasiado frecuentes, periodos no computables o acumulables si no sobrepasan un determinado umbral, etc. Algunas de estas necesidades individuales, pueden tratarse como parámetros configurables de forma limpia en el Frontend, pero otras deberán tratarse internamente y alteran el funcionamiento normal del motor de cálculo en el módulo PCM,  así que realizar un análisis en profundidad evita situaciones difíciles y le proporciona la potencia que pretendíamos. La arquitectura del módulo segmentada por etapas de cálculo, posibilita la inclusión de funciones especificas que pueden ser diseñadas fácilmente para cada cliente, proporcionando un interface con funciones de alto nivel sin que se precisen conocimientos del funcionamiento interno de la solución y por tanto requiere capacidades de programación muy básicas.

Por último, pero no menos importante, está la etapa de pruebas. Creo que no me equivoco si digo que no hay una herramienta que no sea más necesaria que las pruebas de unidad (unit test) automatizadas para la creación de un módulo de control de presencia robusto y fiable. Existen muchas posibilidades horarias que validar, muchas combinaciones que deben asegurarse, y todas deben ser exitosas. Cambiar una simple condición de igualdad puede hacer que en algunos casos los tramos horarios se clasifiquen de forma diferente, puede influir en las decisiones tomadas en otra capa del motor de cálculo y se clasifiquen de forma errónea y por ello, disponer de una batería de pruebas unitarias es fundamental para que la fiabilidad sea del 100%. 

El módulo CPM ya esta listo para ser integrado en OPlanning y pronto estará disponible para nuestros clientes Beta.