[🛠] Intenté unir dos automatizaciones y acabé separando de nuevo ventas y administración de personal

✨ Resumen de GPT-5.6 Sol

Un registro de cómo pensé una estructura de automatización operativa capaz de ampliar los procesos comerciales y de SMS existentes hacia la atención de llamadas entrantes y la administración de personal sin perder lo que ya funcionaba.

Intenté unir dos programas que ya estaban en funcionamiento

En la empresa ya existían dos programas de automatización que habían evolucionado en direcciones distintas.

Uno era un sistema de gestión de vacaciones por SMS que había implementado mi predecesor. Calculaba los días de vacaciones de cada empleado, enviaba mensajes para fomentar su uso e interpretaba las solicitudes recibidas por SMS hasta aprobarlas o rechazarlas. La web, el backend, la base de datos y un teléfono Android de trabajo ya funcionaban como un único flujo.

El otro era el sistema de recopilación de datos públicos y automatización comercial que yo llevaba tiempo refinando. Recogía información de instalaciones y contactos, la conectaba con las llamadas salientes de Vox y la convertía en actividad comercial real.

Al principio pensé que bastaría con trasladar los dos proyectos a un mismo repositorio para integrarlos. Pero, al pensar en las funciones que quería añadir más adelante, vi que no era suficiente con juntar carpetas.

• atención de llamadas entrantes conectada con el sistema saliente existente
• un flujo que reciba solicitudes de empleados y las derive a tareas administrativas
• generación y entrega automáticas de certificados laborales
• división de permisos según empleados, contratos y centros de trabajo
• una pantalla operativa donde consultar fallos, aprobaciones, reintentos y registros de auditoría

Desde ese momento, la pregunta dejó de ser «cómo unir los dos códigos» y pasó a ser «dónde colocar el trabajo que irá apareciendo».

Decidí no desechar el programa existente

Al ver el sistema de vacaciones por SMS, sentí muchas ganas de rehacerlo. Había estructuras antiguas y configuraciones provisionales, además de bastantes partes que quería rediseñar con los criterios actuales. Parecía que extraer los requisitos y trasladarlos a código nuevo daría un resultado más limpio.

Sin embargo, cuanto más revisaba los materiales, más claro veía que aquel programa contenía cosas más importantes que el código.

• los saldos de vacaciones que veían realmente los empleados
• la forma de calcularlos a partir de la fecha de incorporación
• las personas que debían recibir avisos y el momento del envío
• las reglas para interpretar una solicitud por SMS como fechas y medias jornadas
• el orden de solicitud, aprobación, rechazo y mensaje con el resultado
• la forma en que el teléfono Android de trabajo enviaba y recibía mensajes
• las pantallas y el tratamiento de excepciones que ya utilizaba el equipo de operaciones

Si resumía todo eso en unas cuantas páginas y empezaba de cero, el código nuevo podía quedar limpio, pero el resultado que recibían los usuarios existentes podía cambiar. No debía eliminar por una preferencia de diseño un flujo vertical que mi predecesor sí había llevado hasta producción.

Así que cambié de dirección: primero reproduciría el servicio existente tal como era, conservaría las pantallas y los resultados de cálculo como referencia de regresión y, después, sustituiría por funciones las partes problemáticas. El nuevo sistema no debía empezar borrando el anterior, sino incorporarlo a una estructura mayor sin perder lo que ya hacía.

Ventas y administración de personal no eran la misma aplicación

Unir los proyectos y convertir también la base de datos y el Runtime en una sola cosa habría creado otro problema.

La automatización comercial trata datos públicos, contactos, destinatarios de llamadas y resultados de ventas. La administración de personal trata información de empleados, emisión de documentos, vacaciones, aprobaciones y mensajes. Ambos ámbitos pueden aparecer juntos en una pantalla operativa, pero la naturaleza de sus datos, sus permisos y el alcance de sus fallos son distintos.

No quería que una migration de la base de datos comercial bloqueara un despliegue de administración de personal, ni que una caída del servicio de vacaciones detuviera también la recopilación comercial. Las cuentas y credentials, queues, backups y rollbacks también debían estar separados por área.

Al final decidí mantener un único repositorio, pero dividir ventas y administración de personal en aplicaciones independientes. La pantalla operativa permite recorrer ambas desde un solo lugar, pero no consulta directamente sus bases de datos: cada backend responde de sus propios datos y permisos.

De las llamadas salientes a las entrantes y al trabajo administrativo

La automatización comercial existente se parecía sobre todo a un flujo de llamadas salientes. El día 15 también dediqué mucho tiempo a pensar cómo incorporar las entrantes.

Que entre una llamada no significa que todas las solicitudes deban resolverse dentro del sistema telefónico. La llamada puede ser la puerta de entrada que recibe una petición y la deriva al trabajo adecuado. Si alguien solicita un certificado laboral, hay que enviarlo a los procesos de verificación de identidad y emisión; el documento resultante debe seguir después un procedimiento de entrega independiente. Aunque la misma petición llegue desde la web o el móvil, al final debe confluir en el mismo proceso administrativo.

Por eso decidí empezar con los certificados laborales. Era la primera función que permitía comprobar de una vez todo el flujo necesario para automatizar operaciones: recepción de la solicitud, consulta de datos maestros del empleado, generación del documento, aprobación, entrega, gestión de fallos y auditoría.

No se trataba solo de hacer bien una función, sino de poder reutilizar esos mismos límites cuando llegaran más tareas de administración de personal.

No debía volver a crear los datos maestros

La empresa ya gestionaba empleados, contratos y asignaciones a centros en otro sistema. La automatización necesitaba esa información, pero crear otro registro maestro de empleados por nuestra parte haría que los valores de ambos sistemas acabaran divergiendo.

El sistema externo debía seguir siendo propietario de los datos maestros. Nosotros debíamos leer lo necesario y conservarlo como un snapshot validado. La función que modifica el registro maestro tenía que estar separada de la que usa esa información para tramitar casos administrativos.

El problema era que todavía no había comprobado el formato real del archivo descargable ni encontrado un identificador estable para los empleados. Si llamaba número de empleado a un identificador que solo aparecía en pantalla, o escribía que la descarga era un Excel sin haberla probado, todo el diseño posterior se levantaría sobre una premisa falsa.

Así que dejé lo desconocido sin decidir.

Los límites que definí ese día

• el repositorio seguiría siendo uno, pero ventas y administración de personal serían aplicaciones independientes
• la base de datos, el Runtime, las credentials, las queues, los backups y los rollbacks estarían separados por área
• la pantalla operativa unificada usaría las API de cada backend y no consultaría directamente las bases de datos
• el servicio de vacaciones por SMS conservaría sus resultados actuales como referencia de regresión antes de sustituir sus funciones una a una
• el sistema existente seguiría siendo propietario de los datos maestros de empleados, contratos y centros; la automatización solo conservaría snapshots validados
• el primer vertical slice abarcaría desde la solicitud del certificado laboral hasta su emisión, aprobación, entrega y gestión de fallos

El día 15 casi no escribí código: definí estos límites y el orden de migración del servicio existente.