Onboarding y offboarding de TI: el proceso que tu help desk debería automatizar

Automatizar onboarding y offboarding permite que un usuario llegue con accesos, aplicaciones y equipo listos y que, al salir, sus privilegios, licencias y dispositivos queden revocados y recuperados con evidencia. El help desk debe orquestar ese ciclo conectando RH, ITSM, identidad, UEM y aplicaciones para reducir espera, costo administrativo, licencias ociosas y exposición de seguridad.

  • Onboarding de TI: proceso mediante el cual un nuevo colaborador recibe identidad digital, credenciales, dispositivo, aplicaciones, grupos, licencias y permisos necesarios para desempeñar su función. Su objetivo operativo no es “crear una cuenta”, sino reducir el tiempo a productividad desde el primer día.
  • Offboarding de TI: conjunto coordinado de acciones que revoca accesos, recupera activos y licencias, transfiere información, registra evidencias y cierra identidades cuando una persona deja la organización o una función determinada. Su KPI crítico es el tiempo efectivo hasta la revocación completa.
  • Joiner-Mover-Leaver (JML): modelo de gobierno de identidad que divide el ciclo laboral en alta, cambio de función y baja. Microsoft Entra ID Governance utiliza formalmente estas tres etapas y permite ejecutar workflows automáticos según atributos y eventos del usuario.

En Kenos by Scanda llevamos este principio un paso más allá: identificamos las altas, bajas, movimientos y accesos como procesos de soporte susceptibles de automatización de extremo a extremo.

VariableJoiner: altaMover: cambio de puestoLeaver: baja
Evento detonadorFecha de ingresoCambio de rol, área, sede o responsabilidadesFecha/hora de salida
ObjetivoProductividad desde el día unoAjustar privilegios sin acumular accesosEliminar acceso oportunamente
IdentidadCrear/habilitar cuentaModificar atributos y gruposDeshabilitar cuenta
AplicacionesAsignar según perfilAgregar lo nuevo y retirar lo anteriorRevocar aplicaciones y sesiones
LicenciasAsignar solo las requeridasRecalcular entitlementRecuperar licencias
EndpointPreparar y enrolarReconfigurar políticasRecuperar, bloquear o borrar según política
ITSMEjecutar workflow y evidenciasRegistrar cambio y aprobacionesCrear trazabilidad del cierre
Riesgo si es manualUsuario improductivoPrivilegios acumuladosCuenta huérfana o acceso residual
KPI principalTime-to-productivityAccesos fuera de perfilTime-to-revoke
Impacto financieroHoras improductivasLicencias y privilegios innecesariosRiesgo, licencias ociosas y costo de auditoría

Microsoft ya dispone de workflows específicos para onboarding, cambios de perfil, terminaciones en tiempo real, pre-offboarding y post-offboarding. Entre sus acciones estándar están habilitar o deshabilitar cuentas, asignar o retirar grupos, Teams, paquetes de acceso y licencias.

Por qué onboarding y offboarding ya no son tareas administrativas de TI

El error habitual es tratarlos como dos tickets:

“Dar de alta a Juan.”

y tres años después:

“Dar de baja a Juan.”

Entre ambos ocurrieron cambios de puesto, nuevas aplicaciones, proyectos temporales, permisos excepcionales, licencias adicionales, dispositivos reemplazados y accesos aprobados que posiblemente nadie volvió a revisar.

Ahí está el verdadero riesgo.

En un entorno distribuido, el ciclo debería ser:

evento de RH → perfil → identidad → accesos → licencias → endpoint → aplicaciones → validación → evidencia.

El help desk no tiene que convertirse en Recursos Humanos ni sustituir a IAM. Su función es orquestar la ejecución operativa, controlar excepciones y asegurar que el usuario quede habilitado o deshabilitado según una política previamente definida.

Nuestro modelo de Service Desk ya contempla accesos, cambios y onboarding sobre ITSM, catálogo y CMDB, complementados con runbooks y automatización.

Ese matiz es importante: automatizar no significa que “el Service Desk decida quién tiene acceso”. Significa que el workflow ejecuta una decisión gobernada.

Qué debe automatizar el help desk en el ciclo Joiner-Mover-Leaver

1. Definir un sistema fuente para el evento

Todo empieza con una señal confiable.

Para un colaborador, normalmente proviene de RH:

  • fecha de contratación;
  • fecha efectiva de ingreso;
  • puesto;
  • unidad de negocio;
  • ubicación;
  • jefe;
  • tipo de contrato;
  • cambio de área;
  • fecha y hora efectiva de salida.

Si el workflow depende de que alguien mande un correo diciendo “por favor den de baja a…”, la automatización empieza demasiado tarde.

La fecha efectiva debe convertirse en un trigger legible por el ITSM/IAM.

Microsoft, por ejemplo, permite activar Lifecycle Workflows mediante atributos como employeeHireDate y employeeLeaveDateTime.

2. Construir perfiles antes que tickets

La unidad básica no debería ser el nombre del colaborador, sino su perfil de acceso.

Por ejemplo:

Analista financiero

  • Microsoft 365;
  • ERP financiero;
  • carpeta departamental;
  • Teams Finanzas;
  • VPN;
  • herramientas de reporting;
  • políticas específicas de endpoint.

Gerente financiero

  • perfil anterior;
  • aprobaciones;
  • dashboards adicionales;
  • acceso a determinados repositorios;
  • privilegios sujetos a autorización.

Con perfiles predeterminados, el alta deja de ser una lista escrita a mano y se convierte en un workflow controlable.

Esto permite aplicar:

  • role-based access;
  • mínimo privilegio;
  • segregación de funciones;
  • catálogo de servicios;
  • aprobaciones según criticidad;
  • excepciones documentadas.

Cómo automatizar el onboarding de TI

3. Ejecutar el preboarding antes del primer día

El objetivo no es entregar credenciales rápido después de que llegue la persona.

El objetivo es que no tenga que esperar.

Un workflow puede preparar previamente:

  • identidad corporativa;
  • correo;
  • MFA;
  • grupos;
  • aplicaciones;
  • licencias;
  • dispositivo;
  • políticas UEM;
  • software por perfil;
  • acceso temporal inicial;
  • comunicaciones al jefe;
  • tareas para áreas que requieran intervención humana.

Microsoft señala precisamente como uno de los objetivos de Lifecycle Workflows que el usuario llegue al primer día con acceso correcto a información, grupos y aplicaciones.

En la operación de Kenos también conectamos esta lógica con Endpoint Management. Nuestro modelo incluye zero-touch onboarding de equipos nuevos, despliegues automatizados y recuperación de licencias, evitando que la automatización termine en la creación del usuario mientras la laptop sigue esperando configuración.

El KPI correcto: tiempo a productividad

Un ticket cerrado no demuestra que el onboarding funcionó.

Mida:

Time-to-productivity = momento en que el usuario puede realizar su trabajo − inicio efectivo de su jornada

Un alta puede estar técnicamente “completada” y aun así obligar al colaborador a esperar seis horas porque falta una aplicación crítica.

En Kenos by Scanda consideramos que el resultado no debe ser “cuenta creada”, sino usuario productivo.

El Mover: la parte del proceso que más organizaciones olvidan

4. Automatizar también los cambios de puesto

Joiner y Leaver reciben casi toda la atención. Mover es donde se acumula deuda de acceso. Cuando alguien cambia de Finanzas a Operaciones, no basta con darle acceso a Operaciones. También debe evaluarse qué deja de necesitar. El workflow debería:

  • detectar cambio de puesto, área o ubicación;
  • identificar los accesos asociados al nuevo rol;
  • retirar privilegios que ya no corresponden;
  • solicitar aprobación para excepciones;
  • modificar grupos;
  • reasignar licencias;
  • actualizar políticas del dispositivo;
  • registrar evidencia;
  • iniciar revisión de accesos privilegiados.

Microsoft contempla formalmente workflows de cambios de perfil y membresía dentro del ciclo Mover. La regla debería ser sencilla: un cambio de rol no solo agrega acceso; también obliga a revisar lo que debe desaparecer. Cómo automatizar el offboarding y cerrar la ventana de exposición

5. Hacer que la fecha de salida active la revocación

Un offboarding maduro no comienza cuando el help desk recibe un ticket. Comienza con el evento autorizado de salida. Según el escenario, el workflow puede ejecutar automáticamente:

  • deshabilitación de cuenta;
  • revocación de grupos;
  • eliminación de Teams;
  • retiro de paquetes de acceso;
  • recuperación de licencias;
  • eliminación o bloqueo posterior de la identidad;
  • revocación de privilegios;
  • tratamiento de correo y archivos según política;
  • recuperación del endpoint;
  • cierre o borrado del dispositivo;
  • actualización de CMDB;
  • evidencia para auditoría.

Microsoft incluye estas acciones dentro de sus workflows de Leaver y recomienda un retiro oportuno del acceso al terminar la relación con el usuario.

NIST SP 800-53 va en la misma dirección: el control AC-2 establece que las cuentas deben deshabilitarse cuando ya no están asociadas con un usuario y contempla mecanismos automatizados para la gestión de cuentas y su auditoría.

No confundir “deshabilitar correo” con hacer offboarding

Una baja incompleta puede dejar activos:

  • SaaS independientes;
  • accesos privilegiados;
  • VPN;
  • tokens;
  • dispositivos;
  • grupos;
  • licencias;
  • herramientas de terceros;
  • cuentas compartidas;
  • secretos utilizados por procesos;
  • accesos de proyectos anteriores.

Por eso la CMDB, el catálogo y la identidad deben hablar entre sí.

6. Recuperar dinero, no solo accesos

El offboarding también tiene una consecuencia financiera inmediata: licencias recuperables. Cada baja debería producir automáticamente un inventario de:

  • licencias asignadas;
  • licencias recuperadas;
  • dispositivos pendientes;
  • activos recuperados;
  • líneas o servicios cancelables;
  • aplicaciones con costo unitario;
  • suscripciones que pueden regresar al pool.

El cálculo es sencillo:

Ahorro anual por recuperación de licencias = licencias recuperadas × costo mensual × 12

Si 50 licencias de $800 MXN mensuales permanecen activas sin usuario, el gasto innecesario sería:

50 × $800 × 12 = $480,000 MXN anuales.

No hace falta un espectacular “programa de transformación” para encontrar medio millón de pesos. A veces basta con que Recursos Humanos y TI dejen de pasarse Excel por correo.

Cómo conectar onboarding y offboarding con EBITDA y ROI

7. Monetizar el tiempo improductivo

Para dirección, el KPI técnico debe traducirse.

Una fórmula inicial es:

Costo de onboarding improductivo = altas × horas perdidas × costo laboral cargado por hora

Ejemplo hipotético:

  • 800 altas al año;
  • 4 horas promedio perdidas antes de estar productivo;
  • costo laboral cargado: $350 MXN/hora.

Resultado:

800 × 4 × $350 = $1,120,000 MXN al año.

Este monto no debe presentarse automáticamente como “pérdida de EBITDA”. Para que impacte EBITDA de forma directa tiene que traducirse en menor producción, venta perdida, horas extraordinarias o capacidad adicional requerida.

La disciplina financiera está en distinguir costo de capacidad desperdiciada de impacto económico efectivamente capturable.

8. Calcular el business case de la automatización

Puede estructurarse así:

Beneficio anual = productividad recuperada + licencias recuperadas + horas administrativas evitadas + incidentes evitados − costo de automatización

Y:

ROI = (beneficio anual − inversión) / inversión × 100

Para el CFO hay cuatro bolsillos distintos:

  1. Productividad: tiempo que los nuevos usuarios dejan de perder.
  2. OPEX de TI: menos trabajo administrativo repetitivo.
  3. Licenciamiento: recuperación automática.
  4. Riesgo: menor ventana de exposición y mejor evidencia para auditoría.

El cuarto no debe inflarse con promesas. Una cuenta huérfana no equivale a una brecha. Lo que sí puede afirmarse es que las credenciales siguen siendo un vector material de ataque: el Verizon 2026 DBIR sitúa el abuso de credenciales en 13% de los vectores conocidos de acceso inicial analizados.

Y el impacto financiero potencial de una brecha ya es suficientemente serio sin adornarlo: IBM reportó en 2026 un costo global promedio de US$4.99 millones por brecha de datos. Este dato sirve como contexto de riesgo, no como costo atribuible automáticamente a un mal offboarding.

Qué arquitectura conecta RH, Service Desk, identidad y endpoints

9. Diseñar un workflow end-to-end

Una arquitectura operativa madura puede verse así:

HRIS / Capital Humano
↓ evento laboral

ITSM / Service Desk
↓ workflow, catálogo, aprobaciones, SLA y evidencia

IAM / Identity Governance
↓ identidad, grupos, roles y privilegios

UEM / Endpoint Management
↓ dispositivo, políticas, software, bloqueo o borrado

Aplicaciones SaaS y corporativas
↓ provisión/deprovisión

CMDB / Asset Management
↓ identidad + equipo + ubicación + responsable

Dashboard de gobierno
↓ KPIs, excepciones, auditoría y costo

El Service Desk actúa como orquestador operativo, no necesariamente como propietario de cada plataforma.

En Kenos by Scanda conectamos precisamente Service Desk, Endpoint Management, automatización, ITSM y gobierno para eliminar los espacios donde normalmente termina un sistema y comienza el correo manual. Nuestra propuesta de productividad sin fricciones integra onboarding, soporte, accesos, endpoints y automatización dentro de una misma operación.

Qué requisitos debe cumplir un workflow de onboarding y offboarding

Antes de automatizarlo, el proceso debería tener:

  • un sistema fuente de identidad;
  • fecha efectiva confiable;
  • perfiles de acceso documentados;
  • dueño de cada aplicación;
  • matriz de aprobación;
  • integración con ITSM;
  • integración con IAM;
  • integración con UEM;
  • inventario de licencias;
  • CMDB o repositorio de activos;
  • tratamiento definido de excepciones;
  • manejo de empleados, contratistas y proveedores;
  • reglas para permisos privilegiados;
  • evidencia automática;
  • alertas de workflows fallidos;
  • mecanismo de reconciliación posterior;
  • KPI de productividad y de revocación.

Automatizar un proceso mal definido solo permite equivocarse a mayor velocidad. Primero se normaliza la regla; después se automatiza.

Qué KPIs deben llegar al CIO, CISO y CFO

10. Dejar de medir solamente tickets

Para el CIO

  • porcentaje de usuarios listos antes del día uno;
  • tiempo promedio a productividad;
  • porcentaje de workflows ejecutados sin intervención humana;
  • errores de provisión;
  • cumplimiento de SLA de altas y bajas;
  • licencias recuperadas.

Para el CISO

  • tiempo desde baja efectiva hasta deshabilitación;
  • cuentas huérfanas detectadas;
  • accesos fuera de perfil;
  • privilegios revocados;
  • excepciones pendientes;
  • porcentaje de bajas con evidencia completa;
  • cuentas inactivas fuera de política.

Para el CFO

  • costo administrativo por alta/baja;
  • costo de tiempo improductivo;
  • gasto recuperado en licencias;
  • activos no recuperados;
  • costo por usuario habilitado;
  • ahorro generado por automatización.

En Kenos ya medimos el Service Desk más allá del volumen de tickets: FCR, MTTR, TCO, SLA/XLA, espera y automatización forman parte del modelo.

Además, contamos con evidencia operativa en Service Desk donde la automatización alcanzó 30% de las interacciones recurrentes y contribuyó a una reducción de 20% del TCO. Kenos también opera a una escala de 52,000 usuarios de TI al mes. Estas cifras son evidencia de nuestra operación, no benchmarks que deban extrapolarse automáticamente a cualquier organización.

Esa distinción importa: para construir un caso financiero serio usamos la línea base del cliente antes de comprometer ahorros.

Conclusión predictiva

Durante años, onboarding y offboarding significaron crear una cuenta y después cerrarla. Ese modelo ya quedó corto. La siguiente etapa será administrar simultáneamente personas, dispositivos, privilegios, automatizaciones e identidades no humanas.

La señal ya existe. Microsoft incorporó en Lifecycle Workflows plantillas específicas para transferir el patrocinio de agentes cuando su responsable abandona la organización o cambia de función. Esto anticipa un cambio importante: el offboarding de los próximos años no preguntará solamente “¿qué accesos tenía esta persona?”, sino también:

  • ¿qué automatizaciones dependían de ella?;
  • ¿qué agentes patrocinaba?;
  • ¿qué credenciales o secretos utilizaban?;
  • ¿quién hereda su responsabilidad?;
  • ¿qué licencias deben recuperarse?;
  • ¿qué datos puede seguir utilizando cada agente?;
  • ¿qué evidencia demuestra que todo quedó gobernado?

En Kenos by Scanda consideramos que ahí está la evolución natural del Service Desk: dejar de esperar solicitudes y convertirse en el motor que orquesta el ciclo completo de productividad del usuario. Automatizar onboarding y offboarding no es automatizar Recursos Humanos. Es eliminar la espera al entrar, los privilegios olvidados al moverse y los accesos residuales al salir.

Y esas tres cosas terminan apareciendo donde dirección sí mira: productividad, costo, riesgo y continuidad.

FAQ

  1. ¿Cuál es el principal beneficio financiero de automatizar onboarding y offboarding? Depende de la línea base. Los beneficios más fáciles de monetizar son horas improductivas evitadas, horas administrativas eliminadas y licencias recuperadas. El ROI debe calcularse con volúmenes y costos reales de la organización, no con porcentajes genéricos de mercado.
  2. ¿Cuánto tiempo debería tardar TI en revocar los accesos de un empleado que sale de la empresa? La organización debe definirlo según riesgo y política. NIST establece que las cuentas que ya no estén asociadas con un usuario deben deshabilitarse dentro de un periodo definido. Para salidas de alto riesgo, la práctica operativa debería hacer coincidir la revocación con la hora efectiva de terminación, evitando depender de ejecución manual.
  3. ¿Qué debería automatizar primero una empresa que todavía gestiona altas y bajas manualmente? Comience por procesos de alto volumen, baja ambigüedad y alto impacto: creación y deshabilitación de cuentas, grupos, licencias, aplicaciones estándar, preparación de endpoints y recuperación de licencias. Después incorpore perfiles complejos, accesos privilegiados y excepciones. El objetivo inicial debe ser reducir tiempo a productividad y tiempo a revocación, no automatizar el 100% por decreto.

Convierte las altas y bajas de TI en un proceso medible, no en una cadena de correos. En Kenos by Scanda podemos revisar cómo gestionas hoy el ciclo completo de tus usuarios: onboarding, movimientos, accesos, dispositivos, licencias y offboarding.

Partimos de tu operación real para identificar qué tareas pueden automatizarse, cuánto tiempo productivo puede recuperarse y dónde existen accesos, licencias o pasos manuales que hoy generan costo y riesgo. Agenda una sesión con nosotros y construyamos una línea base para identificar tus primeras oportunidades de automatización.

Estamos listos para hablar de tu proyecto

CONTACTO

Envíanos tus datos y nos pondremos en contacto contigo sin ningún compromiso