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.

Ya había dos programas 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.

Aunque por fuera haya una interfaz operativa unificada, por dentro no tiene por qué existir un único servicio gigantesco.

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. Aquel fue un día de encontrar muchas respuestas, pero también de corregir frases una y otra vez para no fingir que sabía lo que aún no sabía.

Integrar no consistía en juntar carpetas

El día 15 casi no escribí código. Seguí ordenando los nombres de los proyectos, los límites entre aplicaciones, la propiedad de los datos, el orden de migración del servicio existente y la función de la pantalla operativa.

Quería encontrar una forma de respetar el programa de mi predecesor sin congelarlo para siempre, y de no encerrar mi automatización comercial en su estructura actual. Tenía que poder crecer desde las llamadas salientes de Vox hacia las entrantes, y desde ahí hacia la administración de personal y la automatización documental.

Meter los dos proyectos en una misma carpeta era fácil. Lo difícil era decidir qué conservar, qué separar y por dónde empezar a ampliar. El día 15 fue cuando empecé a mirar dos automatizaciones distintas como una sola estructura operativa.