Migrar de Excel a una plataforma de RR.HH. no falla por la tecnología: falla por el orden en que se hacen las cosas. Con los datos maestros resueltos y un responsable con poder de decidir reglas, treinta días alcanzan. Sin eso, ni tres meses.
¿Qué hay que tener antes de empezar?
Tres cosas, y ninguna es técnica. Un responsable interno con autoridad para definir reglas: qué cuenta como llegada tarde, quién aprueba una excepción, qué pasa con los feriados de cada sede. Un listado de personal confiable, con una sola versión de cada persona y su área. Y una decisión sobre el alcance de la primera etapa, que casi nunca debería ser "todo".
El error clásico es arrancar por la parametrización porque es la parte que se parece a trabajar. Si el listado tiene duplicados y nadie puede decidir las reglas, esa parametrización se rehace tres veces.
¿Cómo se reparten los treinta días?
| Semana | Qué se hace | Quién lidera | Señal de que se puede avanzar |
|---|---|---|---|
| 1 | Limpieza de datos maestros y definición de reglas horarias | RR.HH. con el responsable interno | Una sola planilla de personal, sin duplicados, con área y horario por persona |
| 2 | Parametrización, carga y configuración de flujos de aprobación | Proveedor con RR.HH. | Las reglas definidas en la semana 1 están cargadas y dan el resultado esperado en casos de prueba |
| 3 | Piloto en un área acotada, en paralelo con el método actual | El área piloto | El registro del sistema y el de la planilla coinciden en el período |
| 4 | Despliegue al resto y cierre del primer período completo | RR.HH. | Un cierre hecho íntegramente con el sistema, sin corregir a mano |
La cuarta columna es la que hace que el plan funcione. Cada semana tiene una condición de salida verificable: si no se cumple, no se avanza. Un proyecto que pasa a la semana 3 sin que las reglas den bien en las pruebas llega al despliegue con errores que después se atribuyen al sistema.
¿Por qué el piloto va en paralelo y no en reemplazo?
Porque es la única forma de detectar diferencias sin arriesgar un cierre. Durante el piloto conviven el método viejo y el nuevo, y al final del período se comparan. Las diferencias que aparecen no son fallas: son reglas mal definidas que ahora se pueden corregir.
Es también la etapa donde se resuelve la resistencia del equipo, que es real y previsible. Un piloto acotado con gente que después cuenta que funcionó vale más que cualquier comunicado interno.
¿Qué área conviene elegir para el piloto?
Ni la más fácil ni la más difícil. La más representativa: la que tenga los casos típicos de la operación —turnos, alguna excepción habitual, algún horario partido— pero sin ser la más caótica de la empresa.
Elegir el área más simple da una falsa sensación de éxito y esconde los problemas hasta el despliegue. Elegir la más caótica hunde el piloto por razones que no tienen que ver con el sistema.
¿Qué hace fracasar una migración?
Migrar el desorden. Si las reglas actuales son "depende del supervisor", el sistema va a reproducir eso con más precisión. Primero se define la regla, después se carga.
Querer todo en la primera etapa. Asistencia, vacaciones, legajo, evaluación y encuestas al mismo tiempo multiplica las decisiones pendientes y ninguna se cierra. Conviene arrancar por lo que duele hoy.
No cerrar el Excel. Mientras la planilla vieja siga viva "por las dudas", el equipo la va a seguir usando y va a haber dos verdades. La fecha de apagado se define desde el principio y se cumple.
Dejar el histórico afuera. Definir desde qué fecha se carga el pasado y qué queda archivado evita descubrir en una auditoría que no hay nada antes del go-live. La guía completa de criterios para elegir plataforma está en la guía de software de RRHH en la nube.
¿Cómo acompaña Lenox HR esa migración?
Con la parametrización de reglas horarias hecha sobre la operación real —turnos, sedes, excepciones— y la carga de datos maestros como primer entregable, que es el orden que evita rehacer trabajo. El módulo de control horario suele ser el punto de entrada porque es donde el dolor es más medible.
Y como los reportes salen desde el primer período, la comparación del piloto contra el método anterior se hace con datos y no con impresiones.
Preguntas frecuentes
- ¿Se puede migrar de Excel a un software de RR.HH. en 30 días?
- Sí, si hay un responsable interno con autoridad para definir reglas y un listado de personal confiable. Sin esas dos condiciones el plazo se estira, y no por razones técnicas.
- ¿Por dónde se empieza?
- Por la limpieza de datos maestros y la definición de reglas horarias, no por la parametrización. Cargar reglas que todavía no están decididas obliga a rehacer el trabajo varias veces.
- ¿Conviene hacer un piloto?
- Sí, en paralelo con el método actual y en un área representativa. Al cierre del período se comparan ambos registros: las diferencias que aparecen suelen ser reglas mal definidas, y todavía se pueden corregir.
- ¿Qué área conviene para el piloto?
- La más representativa, no la más fácil ni la más caótica. Tiene que tener los casos típicos de la operación —turnos, alguna excepción habitual— sin ser el área más desordenada de la empresa.
- ¿Qué hace fracasar una migración?
- Migrar el desorden en lugar de definir reglas primero, querer implementar todos los módulos a la vez, no fijar una fecha de apagado del Excel y no decidir qué se hace con el histórico.