Onboarding y offboarding de empleados con HaloESM
November 11, 2026
Son las 8:40 de un lunes. La nueva analista financiera está en recepción con la carta de oferta impresa. Su jefe está en una reunión. RR. HH. envió el correo de bienvenida el viernes, pero TI nunca se enteró de la contratación, así que no hay laptop. Instalaciones no tiene su nombre, así que no hay tarjeta de acceso. Finanzas no recibió aviso, así que su centro de costos todavía no existe. Tres áreas hicieron su trabajo. Nadie operó el proceso completo.
La salida de un colaborador falla de forma más silenciosa. Un ingeniero de ventas renuncia y RR. HH. cierra su expediente. Dos meses después alguien descubre que sus cuentas siguen activas, que su laptop está guardada en una sucursal y que un contrato con un proveedor todavía lo tiene como aprobador. Las dos historias tienen la misma causa. Para el empleado, entrar y salir son eventos únicos. Para la empresa, cada uno es un conjunto de tareas separadas que pertenecen a cuatro o cinco áreas que casi nunca miran la misma pantalla.
Este artículo explica cómo diseñar flujos de onboarding y offboarding de empleados que cruzan RR. HH., TI e Instalaciones, dónde suelen romperse, cuánto cuesta ese quiebre y cómo HaloESM ejecuta toda la secuencia desde un solo lugar. Empezamos por el problema y su costo, porque el diseño solo tiene sentido cuando ves dónde se van realmente las horas y el riesgo.
A la mayoría de las empresas no les faltan pasos de onboarding. Les falta un responsable de la secuencia. RR. HH. es dueño del expediente laboral, TI de las cuentas y los equipos, Instalaciones de los puestos y los accesos, Finanzas de los centros de costos y las tarjetas corporativas, y el jefe directo de todo lo que sobra. Cada área tiene su propia lista, casi siempre en su propia herramienta, y las conexiones entre esas listas viven en cadenas de correo y en la memoria de una sola coordinadora.
Cuando una solicitud pasa de RR. HH. a TI, cambia de forma. RR. HH. escribe "nuevo ingreso, marketing, empieza el 18". TI necesita un rol, una ubicación, un tipo de equipo y una lista de aplicaciones. Alguien tiene que traducir, y en esa traducción se pierde información. Lo mismo ocurre entre TI e Instalaciones: el equipo está listo pero el puesto no, o el puesto está listo y la solicitud de acceso al edificio sigue esperando la firma de un gerente.
El resultado es un proceso que avanza a base de mensajes de seguimiento. Las coordinadoras preguntan "¿te llegó mi correo?" más veces de las que aprovisionan algo. Es el mismo patrón que describimos en nuestra comparación entre ITSM y ESM: un proceso que es simple dentro de un área se vuelve lento y frágil en cuanto cruza el límite de un equipo, porque las herramientas y la responsabilidad terminan en ese límite.
El costo visible es la productividad perdida. Un colaborador sin equipo ni accesos pasa sus primeros días esperando, y su jefe pasa esos días improvisando. El costo menos visible es el tiempo de quienes persiguen: los socios de negocio de RR. HH., los coordinadores de TI y los administradores de oficina que dedican parte de su semana a preguntar a otros equipos en qué va cada cosa. Ese tiempo no aparece en ningún tablero, así que nadie lo gestiona.
Los costos del lado de las salidas son distintos y a menudo mayores. Una cuenta que sigue activa después de que alguien se va es un riesgo de acceso. Un equipo que nunca se recupera es un activo perdido. Un permiso de aprobación que nunca se reasigna es una brecha de control que un auditor encontrará tarde o temprano. No son fallas exóticas. Ocurren cada vez que el offboarding depende de que alguien se acuerde de avisar a otras tres áreas.
Imagina una empresa que contrata cinco personas al mes en tres sedes. Si cada ingreso requiere ocho traspasos entre cuatro áreas, son cuarenta traspasos al mes, y cada uno es una oportunidad de que un mensaje se pierda. Las cifras son ilustrativas, pero la aritmética es el punto: los traspasos crecen con el volumen de contratación, mientras que la capacidad del equipo de coordinación se queda igual.
También está la experiencia de la persona. Una primera semana en la que lo básico no funciona dice mucho de cómo opera la empresa, y una salida manejada con descuido dice otra cosa, tanto a quien se va como a los colegas que observan. Ninguno de esos mensajes es el que la dirección quería enviar.
Un flujo de ingreso no es una lista larga. Es una secuencia corta de etapas, cada una con un responsable claro, un disparador claro y una definición clara de terminado. Las etapas que siguen se ajustan a la mayoría de las organizaciones, y puedes adaptar los detalles a tu tamaño y a tu industria.
Todo empieza con un disparador. En la mayoría de las empresas es una oferta aprobada o un contrato firmado, y lo registra RR. HH. El disparador debe capturar lo que todas las áreas posteriores necesitan: rol, departamento, jefe directo, ubicación, fecha de inicio, tipo de contratación y cualquier requisito especial de equipo o acceso. Si RR. HH. lo captura una sola vez y cada área posterior lo lee de la misma solicitud, el problema de traducción de la sección anterior casi desaparece.
Las aprobaciones que corresponden a esta etapa, como la confirmación de presupuesto o la autorización del jefe para equipo fuera de lo estándar, deben ocurrir aquí y no después. Una aprobación tardía bloquea una tarea que alguien más ya está esperando.
TI recibe una tarea, no un correo. La tarea ya incluye el rol y la fecha de inicio, de modo que el paquete estándar de cuentas, aplicaciones y hardware para ese rol se prepara sin una conversación previa. Las solicitudes fuera del paquete estándar pasan por aprobación dentro del mismo flujo, y quien aprueba ve el contexto.
La decisión de diseño importante es la fecha límite. TI no debería trabajar "lo antes posible", sino contra una fecha ligada al inicio, por ejemplo dos días hábiles antes del primer día. Una fecha convierte una petición vaga en un compromiso que se puede seguir.
Instalaciones necesita la ubicación y la fecha de inicio, y en muchos casos el departamento para que el puesto quede en la zona correcta. Las tareas son sencillas: asignar un escritorio o un casillero, emitir una tarjeta de acceso, dar de alta a la persona en el sistema del edificio y, en roles de campo, preparar uniforme o equipo de seguridad. Son sencillas, pero son las que más se olvidan, porque Instalaciones rara vez está en la lista de distribución de los avisos de RR. HH.
El flujo no termina cuando la laptop está lista. El nuevo colaborador necesita una lista corta de cosas por hacer, como aceptar políticas, completar la capacitación obligatoria y conocer al equipo. El jefe también necesita tareas: una conversación de primera semana, objetivos para el primer mes y un seguimiento. Cuando estas tareas viven en el mismo flujo, RR. HH. puede ver de un vistazo si avanza la parte del jefe y no solo la de TI.
Un flujo de ingreso termina cuando todas las etapas están cerradas y la persona confirma que puede trabajar. Cerrar el flujo con la última tarea, y no con la primera respuesta, es lo que hace medible el proceso.
El offboarding merece más atención de la que recibe, porque las consecuencias de una brecha son peores y menos visibles. Nadie se queja cuando una cuenta antigua sigue activa. El problema se descubre después, casi siempre en una auditoría o un incidente.
El núcleo del offboarding es un corte limpio: cuentas deshabilitadas en la fecha correcta, tarjetas de acceso canceladas, equipos recuperados y revisados, y activos registrados como devueltos. Cada una de esas acciones pertenece a un área distinta y tiene un plazo distinto. El acceso debe terminar el último día laboral, o antes en roles sensibles. La recuperación del equipo puede tardar más, sobre todo con personas remotas, por lo que necesita su propia tarea, su propio responsable y un seguimiento si no llega nada.
Aquí importa la conexión entre el flujo y el registro de activos. Si el sistema sabe qué equipos tiene asignados la persona que se va, las tareas de recuperación se generan a partir de esa lista y no de la memoria de alguien.
Las renuncias, los despidos y los casos disciplinarios no son información para todos. Un flujo de offboarding tiene que mover tareas entre áreas sin exponer el motivo de la salida. La regla de diseño es que cada área vea la tarea que debe ejecutar, por ejemplo "deshabilitar las cuentas de esta persona en esta fecha", y nada más. RR. HH. mantiene los detalles del caso restringidos a RR. HH. Acuerden de antemano qué campos necesita cada área y pidan a RR. HH. y a Legal que revisen esa lista antes de que el primer ingreso pase por el flujo.
Quien se va también deja cosas que no son activos: la titularidad de buzones compartidos, aprobaciones en flujos de finanzas, relaciones con clientes, reportes programados y tareas recurrentes. Un buen flujo de offboarding incluye un paso de traspaso para el jefe, con una lista corta de lo que necesita un nuevo responsable. El paso cuesta poco y evita el problema del contrato con el proveedor que mencionamos al inicio.
Una transferencia interna es un pequeño offboarding y un pequeño onboarding al mismo tiempo. La persona conserva algunos accesos y pierde otros, cambia de centro de costos y quizá de ubicación. Las empresas que solo diseñan para ingresos y salidas suelen descubrir que sus transferencias acumulan permisos con los años. Si construyes bien los dos flujos principales, un flujo de cambio interno es en gran parte una recombinación de etapas que ya tienes.
Antes de elegir cualquier herramienta conviene acordar algunas reglas de diseño. Son las mismas si ejecutas el flujo en una hoja de cálculo o en una plataforma, y deciden si el flujo sobrevive al volumen real de contrataciones.
La regla más importante es que toda la secuencia sea una sola solicitud con un solo historial. RR. HH. la inicia, y las tareas de TI, Instalaciones y Finanzas forman parte del mismo registro. Todos ven el mismo estado. Esa es la diferencia entre operar un proceso y retransmitir mensajes sobre un proceso.
Entre áreas no significa una plantilla única para todos. TI necesita un formulario de equipo, Instalaciones necesita uno de ubicación y RR. HH. necesita campos que los demás no deberían ver. Cada área debe conservar su propio formulario de solicitud, sus reglas de aprobación y su meta de cumplimiento. El flujo conecta estas piezas sin forzarlas a una sola plantilla. Es la misma lógica que aplicamos en los catálogos de servicio para legal, finanzas y mantenimiento, donde cada área conserva su oferta dentro de un mismo portal.
Elige dos o tres indicadores y síguelos desde el primer mes. Algunos útiles son la proporción de nuevos ingresos que tienen todo listo el primer día, el tiempo entre el último día laboral y el cierre del flujo de offboarding, y la cantidad de tareas que pasaron su fecha límite, por área. Estos números convierten el onboarding de una anécdota en algo que puedes mejorar, y muestran qué área necesita apoyo.
La forma más segura de fracasar es modelar todos los roles y todas las sedes en el primer intento. Empieza con el tipo de ingreso más frecuente en una ubicación, opéralo durante un mes y corrige lo que falle. Después agrega el flujo de salidas, y después las excepciones. La misma lógica por etapas está detrás de nuestra guía sobre portales de finanzas y legal en cuatro semanas: algo pequeño, funcionando y medido vale más que algo completo y tardío.
La contratación real está llena de excepciones: alguien que empieza una semana antes, un rol que necesita software especial, un jefe de vacaciones cuando llega la aprobación. Un flujo que solo maneja el caso estándar manda a las personas de vuelta al correo la primera vez que la realidad es distinta. Define con anticipación quién puede aprobar una excepción, quién es el suplente cuando falta un aprobador y qué ocurre cuando una tarea pasa su fecha límite. Una regla de escalamiento que avisa a la siguiente persona sirve más que un reporte que explica el retraso después.
HaloESM cubre el onboarding y el offboarding de RR. HH. como una capacidad de área, junto con el mantenimiento de instalaciones y los pases de acceso, las solicitudes de compra y el alta de proveedores. Así se corresponden sus capacidades con el flujo que describimos.
Sí. En HaloESM las solicitudes se enrutan entre TI, RR. HH., Instalaciones, Finanzas y otras áreas, y cada equipo completa su etapa antes de que el flujo avance. Una solicitud de ingreso puede así pasar por RR. HH., TI e Instalaciones, y todos los equipos trabajan sobre el mismo registro. Los flujos de trabajo de Halo definen el proceso que sigue un ticket antes de poder marcarse como resuelto y suelen incluir pasos de aprobación, de modo que las aprobaciones de la primera etapa quedan dentro del proceso y no al lado.
Sí. Cada área en HaloESM tiene su propia oferta de servicios, sus formularios de solicitud, sus flujos de aprobación y sus metas de SLA, todo accesible desde un portal. RR. HH. puede recoger los campos que necesita, TI puede pedir un tipo de equipo e Instalaciones puede pedir una ubicación, sin una plantilla común que a nadie le gusta. Los administradores configuran reglas de enrutamiento, cadenas de aprobación, notificaciones y traspasos entre equipos sin recursos de desarrollo. Los reportes se separan por área.
Halo da seguimiento a los activos de hardware con marca, modelo, número de serie, ubicación, usuario asignado y estado de garantía, y los activos se pueden vincular a tickets. Como cada activo registra a su usuario asignado, los equipos que tiene quien se va pueden consultarse y vincularse a tickets de recuperación, así que la recuperación parte de una lista real. El seguimiento de la etapa del ciclo de vida y los avisos de fin de vida útil mantienen claro el ciclo del equipo una vez que regresa.
La IA de Halo en la gestión de servicios muestra sugerencias de conocimiento a los usuarios antes de que creen un ticket, y hay un agente virtual para usuarios finales. Un nuevo colaborador puede encontrar la respuesta a una duda básica, como conectarse a la red de la oficina, sin esperar la respuesta de TI. El portal es personalizable y se adapta a pantallas móviles, de modo que el mismo punto de entrada funciona en un teléfono. La base de conocimiento y los formularios se configuran sin código, así que RR. HH. mantiene el material al día sin un desarrollador.
Los asuntos sensibles de RR. HH., legales y de riesgo solo son visibles para los usuarios con los permisos adecuados, y eso se configura mediante control de acceso basado en roles. La administración federada y los permisos de subadministrador permiten que RR. HH. gestione su propia área mientras los equipos centrales conservan el control de la plataforma. Los reportes están separados por área, de modo que RR. HH. puede dar seguimiento a sus indicadores de onboarding sin exponerlos a todos los equipos.
Para una visión más amplia de cómo ESM extiende los mismos estándares de servicio más allá de TI, consulta nuestra guía de gestión de servicios empresariales más allá de TI. Para conocer el producto, la página de Halo en GB Advisors describe los módulos que implementamos.
Las empresas de América Latina enfrentan el mismo problema estructural, con algunas complicaciones locales. Muchas operan en varios países, con sedes que tienen jefes locales distintos, reglas laborales distintas e idiomas distintos para las personas involucradas. Un flujo que funciona en la casa matriz puede fallar en una sucursal porque faltan los pasos locales.
La normativa laboral cambia de un país a otro, y también los documentos y las notificaciones que acompañan una contratación o una salida. El enfoque práctico es una columna vertebral común con pasos locales. La columna cubre las etapas de este artículo. La capa local agrega las tareas propias de cada país, como el trámite que RR. HH. debe presentar o el aviso que Finanzas debe enviar. HaloESM admite configuraciones con varias sedes, varios idiomas y varios equipos, así que la columna puede compartirse mientras cada país conserva sus pasos.
Muchas empresas latinoamericanas contratan por oleadas, por una sucursal nueva, un pico de temporada o un contrato que arranca de golpe. Un proceso manual que aguanta dos ingresos al mes se desborda con veinte. Un flujo no elimina el trabajo, pero lo vuelve repetible y visible, que es lo que exige una oleada de contrataciones. Los equipos distribuidos suman un segundo factor: las personas remotas necesitan que se les envíe y se les recupere el equipo, una tarea con más tiempo de espera y más probabilidad de olvidarse.
En muchas organizaciones de la región la coordinación de RR. HH. corre por grupos de chat y seguimiento personal, algo que funciona mientras las mismas dos personas estén disponibles. El paso a un flujo de trabajo es tanto un cambio cultural como técnico. En GB Advisors ofrecemos consultoría, personalización e implementación de Halo con técnicos certificados, y sugerimos empezar por el proceso: quién es responsable de cada etapa, qué cuenta como terminado y cuál será el primer indicador.
Usa esta lista para comprobar si tu organización está lista para automatizar el onboarding y el offboarding, o para revisar un flujo que ya tienes.
Una lista es un buen comienzo y, con pocas contrataciones al año, puede bastar. El problema aparece cuando la lista tiene que cruzar áreas. Una lista no puede recordarle a TI que una fecha ya pasó, ni mostrarle a RR. HH. qué etapa está detenida. Si tu coordinadora dedica parte de cada semana a pedir novedades a otras áreas, la lista ya te quedó corta, sin importar el volumen de contratación.
Porque el nuevo ingreso no es un problema de TI. TI es una etapa en un proceso que también depende de RR. HH., Instalaciones y Finanzas. Usar una mesa de gestión de servicios de TI para la etapa de TI y el correo para todo lo demás deja los traspasos donde estaban. La ventaja de extender el mismo enfoque a RR. HH. e Instalaciones es que todo el proceso tiene un solo historial y un solo estado, que es la idea detrás de la gestión de servicios empresariales.
Es una preocupación legítima y la respuesta son los permisos, no evitar la plataforma. Los asuntos sensibles de RR. HH. deben ser visibles solo para quienes los necesitan, y las demás áreas deben ver tareas sin los motivos detrás de ellas. El control de acceso por roles y la administración delegada son los mecanismos que lo permiten, y deben ser parte del diseño desde el primer día, no agregarse después de una queja.
No necesitas rediseñar todo. Empieza con el tipo de ingreso más frecuente en una ubicación, opéralo durante un mes y ajusta. El esfuerzo es el mismo que tus coordinadores ya gastan persiguiendo novedades, redirigido a un proceso que hace ese seguimiento por ellos. Una sesión de trabajo corta para mapear las etapas y los responsables actuales muestra rápido dónde está la mayor brecha.
El onboarding y el offboarding de empleados fallan en los traspasos, no dentro de un área. La solución es una sola solicitud con un solo historial, donde cada área conserva sus formularios, aprobaciones y metas, y donde cada etapa tiene un responsable y una fecha límite claros. En los ingresos, eso significa una persona que puede trabajar desde el primer día. En las salidas, significa accesos cerrados, equipos recuperados y responsabilidades traspasadas.
HaloESM enruta solicitudes entre TI, RR. HH., Instalaciones y Finanzas, deja que cada equipo complete su etapa antes de que el flujo avance, mantiene restringidos los asuntos sensibles de RR. HH. y vincula los activos con las personas que los tienen. Si quieres ver cómo se vería con tus propios equipos y sedes, habla con GB Advisors y empezaremos desde tu proceso actual.
