Un ERP personalizado para recursos humanos tiene sentido cuando los procesos de personal dependen de reglas, aprobaciones o integraciones que el software disponible no resuelve bien. Su función no es sustituir automáticamente cada herramienta del departamento: debe coordinar los datos y flujos que necesitan compartir RR. HH., responsables de equipo, administración y, cuando corresponda, nóminas.
La decisión clave es delimitar qué sistema será responsable de cada dato. Si el ERP guarda la estructura de equipos, pero la aplicación de nóminas calcula y conserva la información necesaria para pagar, esa división debe reflejarse en las integraciones. Sin una fuente definida para cada campo, aparecen duplicados, cambios que no llegan a todos los sistemas y dudas sobre cuál es el dato correcto.
Qué procesos de RR. HH. integrar en el ERP
El alcance suele organizarse alrededor del ciclo de vida laboral y de las tareas administrativas que lo acompañan. No es necesario incluirlas todas desde el inicio. Resulta más útil empezar por los procesos que generan trabajo repetido, errores de coordinación o falta de visibilidad, y dejar fuera aquello que ya funciona correctamente en otra aplicación.
- Datos de la plantilla: ficha de la persona, puesto, equipo, responsable, centro de trabajo y estado de la relación laboral, según las necesidades de la organización.
- Solicitudes y aprobaciones: permisos, ausencias, cambios de datos, gastos u otras peticiones internas, con responsables y estados definidos.
- Incorporación y salida: tareas asignadas a RR. HH., informática y responsables, junto con fechas, documentación y comprobaciones internas.
- Organización y planificación: posiciones, asignaciones, disponibilidad o necesidades de cobertura, si forman parte de los procesos reales de la empresa.
- Informes operativos: información necesaria para hacer seguimiento de solicitudes, cambios pendientes y datos incompletos.
Una función solo merece incorporarse si tiene un usuario responsable, una regla de funcionamiento y un resultado comprobable. Por ejemplo, «gestionar vacaciones» es demasiado amplio para diseñar un flujo. Hay que especificar quién solicita, quién aprueba, qué ocurre si falta el responsable y cómo se registra la decisión.
Cómo diseñar un flujo sin convertirlo en una cadena de correos
Definir estados, responsables y excepciones
Tomemos un ejemplo hipotético: una persona solicita una ausencia y su responsable la revisa. El sistema podría manejar estados como borrador, enviada, aprobada, rechazada y cancelada. Cada transición debe tener una condición: solo quien tenga permiso puede aprobar; una solicitud rechazada conserva el motivo; una cancelación deja constancia de quién la hizo y cuándo.
También hay que resolver las excepciones antes de programar. ¿Qué pasa si el responsable está ausente? ¿Se puede cambiar una solicitud ya aprobada? ¿Quién recibe una tarea bloqueada? Una regla explícita evita que el equipo acabe usando correos o mensajes paralelos para completar lo que el sistema no contempla.
Separar el registro de la información de su cálculo
El ERP puede registrar una petición y su aprobación sin ser necesariamente el sistema que determina su impacto en la nómina. Esa diferencia es importante: el registro de una decisión, el saldo disponible, la planificación de turnos y el cálculo salarial pueden pertenecer a procesos o aplicaciones distintos.
Antes de integrar esos procesos, hay que acordar qué datos se envían, en qué dirección y en qué momento. Si el ERP transmite una ausencia aprobada a otra aplicación, debe existir una respuesta para los errores: por ejemplo, marcar el envío como pendiente, conservar el detalle del fallo y permitir que una persona autorizada lo revise. Una integración que falla sin dejar rastro puede ser más difícil de detectar que una tarea manual visible.
El modelo de datos y las integraciones determinan el mantenimiento
Un diseño sostenible separa las entidades principales. La persona, el puesto, el equipo y la solicitud no deberían convertirse en una única ficha con campos difíciles de interpretar. Las relaciones entre ellas permiten conservar el historial cuando alguien cambia de equipo o de responsable, en lugar de sobrescribir información y perder el contexto de decisiones anteriores.
También conviene definir identificadores estables para enlazar los registros entre sistemas. Usar el nombre como clave suele ser frágil: puede cambiar, repetirse o escribirse de otra forma. La integración necesita un identificador compartido o una correspondencia controlada, además de reglas para altas, bajas, correcciones y registros que no encuentran pareja.
La arquitectura dependerá de las aplicaciones existentes. Una interfaz de programación de aplicaciones (API) puede intercambiar datos cuando los sistemas la ofrecen; en otros casos habrá que valorar importaciones, exportaciones u otro mecanismo compatible. En todos ellos, las pruebas deben comprobar tanto los datos correctos como los fallos: campos vacíos, duplicados, cambios simultáneos y reintentos después de una interrupción.
Si la empresa ya utiliza un programa de nóminas, control horario, identidad corporativa o gestión documental, el proyecto debe identificar las fronteras entre esos sistemas antes de construir módulos equivalentes. Un ERP a medida puede integrar procesos propios, pero cada función añadida crea necesidades de soporte, pruebas y evolución. Mantener una aplicación especializada puede ser más sencillo que replicar una capacidad que ya cubre otra herramienta.
Permisos, historial y protección de la información
Los datos de personal no deben quedar accesibles a toda persona que pueda iniciar sesión en el ERP. Los permisos se diseñan según las tareas: una persona puede consultar su propia información; un responsable, revisar solicitudes de su equipo; y un perfil de RR. HH., gestionar determinados registros. El acceso a datos sensibles requiere una delimitación específica, no una excepción amplia asociada al cargo.
El sistema también debe registrar acciones relevantes: quién modificó un dato, qué cambió, cuándo y, si procede, qué aprobación permitió hacerlo. Ese historial ayuda a revisar incidencias y a distinguir una corrección de una actualización automática. No sustituye las políticas de conservación, seguridad o cumplimiento que correspondan a la organización; estas deben definirse con asesoramiento adecuado al contexto y mantenerse alineadas con los procesos reales.
En las pruebas, no basta con confirmar que un usuario autorizado ve la pantalla correcta. Hay que comprobar que un perfil sin permiso no puede obtener la información mediante búsquedas, informes, exportaciones o llamadas a la API. Las vistas, las descargas y las integraciones deben aplicar las mismas reglas de acceso que la interfaz habitual.
Un ejemplo de alcance inicial y cómo evaluarlo
Imaginemos una empresa que tramita solicitudes internas por correo y mantiene los datos de plantilla en una aplicación distinta de la nómina. Un primer alcance razonable podría incluir un directorio de personal sincronizado, un flujo de solicitudes con aprobación y un panel de tareas pendientes para RR. HH. El cálculo de nóminas seguiría en su sistema actual, mientras que el ERP enviaría solo los datos aprobados que se hayan acordado.
Antes de desarrollar, el equipo puede preparar una matriz sencilla con cada proceso, su responsable, el sistema de origen, el sistema de destino y las excepciones. Después, conviene validar el diseño con escenarios concretos: una solicitud aprobada, otra rechazada, un cambio de responsable y una integración temporalmente fallida. Si alguien no sabe qué acción debe realizar en alguno de esos casos, falta una regla o una responsabilidad por definir.
El resultado se evalúa mejor mediante comprobaciones observables que con una lista de funcionalidades: los usuarios autorizados completan el flujo, los no autorizados no acceden a datos ajenos, los cambios quedan registrados y la información enviada coincide con la acordada. Para comparar enfoques de implementación, también es útil distinguir entre configurar una plataforma existente y desarrollar módulos propios; el análisis de ERP puede ayudar a contextualizar esa elección sin sustituir el levantamiento de requisitos.
El alcance adecuado es el que resuelve un proceso identificable y puede mantenerse con responsables, datos y reglas claros. Si cada excepción exige una modificación de código, el flujo probablemente necesita una política más precisa o una configuración más flexible. Si, en cambio, una herramienta existente ya cubre el proceso y se integra de forma fiable, personalizarlo puede añadir complejidad sin mejorar la operación.
