Transferencia de conocimiento al salir un empleado: checklist práctico
Usa este checklist de transferencia de conocimiento para conservar trabajo crítico antes de una salida y pilotar respuestas internas con fuentes en Polp.
Cuando una persona deja la empresa, las tareas inmediatas son visibles: accesos, nómina, equipo y comunicación. La pérdida costosa suele ser menos visible: el motivo de una promesa a un cliente, el atajo que mantiene un proceso mensual o la excepción detrás de una política. Un traspaso no es volcar una carpeta. Es un proceso breve y responsable para conservar el conocimiento que permite a quien sustituye tomar la siguiente decisión correcta.
Este checklist está pensado para responsables de RRHH, operaciones o equipo que preparan una salida. No sustituye asesoramiento laboral ni un sistema de RRHH, y no presupone que una herramienta de IA pueda reemplazar el criterio de la persona que se va. Su objetivo es más concreto: convertir conocimiento crítico y reutilizable en fuentes aprobadas que un sucesor pueda encontrar y comprobar.
1. Nombra el riesgo de negocio antes de recopilar archivos
Plantea tres preguntas a la persona responsable: ¿qué decisiones se paralizarían la próxima semana?, ¿qué compromisos con clientes, proveedores o cumplimiento esconden contexto?, y ¿qué proceso depende de la memoria de una sola persona? Limita la lista a cinco áreas de alto riesgo. La orientación de gestión del conocimiento de ISO distingue el saber que reside en las personas del saber codificado en documentos: el traspaso necesita ambos, archivos y explicación de uso.
Para cada área, apunta responsable de negocio, sucesor, fecha límite y audiencia. No empieces copiando carpetas personales. Pueden contener borradores, información sensible y material que el sucesor no necesita.
2. Crea un registro de traspaso pequeño
Usa una fila por cada elemento que el sucesor tenga que utilizar. Los campos mínimos son: área de trabajo; decisión o pregunta repetida; fuente aprobada; responsable; audiencia; fecha de vigencia; fecha de revisión; sistema relacionado; y lo que aún no está escrito. Incluye el estado de proyectos y relaciones importantes solo cuando sea apropiado compartirlos.
La guía de offboarding de Atlassian menciona responsabilidades, flujos, estado de proyectos y experiencia especializada. El flujo actual de ServiceNow también agrupa recursos por proyectos para revisión de responsable y empleado. Ambos casos apuntan a la misma disciplina: conservar contexto en una estructura revisable, no tratar un resumen generado por IA como verdad final.
3. Separa conocimiento de administración de accesos
Un buen traspaso nunca retrasa la retirada de accesos. RRHH e IT deben seguir el proceso aprobado de salida para cuentas, dispositivos, registros y material confidencial. El paquete de conocimiento debe enlazar documentos y sistemas aprobados; no debe convertirse en una hoja de contraseñas, credenciales privadas o exportaciones ilimitadas de clientes.
Marca cada elemento como para toda la empresa, solo equipo, solo responsables o excluido. Si algo no se puede compartir de forma segura con el sucesor, registra quién puede responderlo. Así proteges la continuidad sin convertir una salida en una copia descontrolada.
4. Recoge las preguntas, no solo los documentos
Para cada área de riesgo, pide a la persona que se va entre tres y cinco preguntas reales que deberá resolver su sucesor. Por ejemplo: «¿Qué versión de esta tarifa está aprobada?», «¿Qué ocurre si este proveedor no cumple el corte?» o «¿Dónde está el procedimiento de escalado vigente?». Añade la fuente que debería responder cada pregunta y señala las lagunas.
Aquí puede ayudar una capa de conocimiento interna. Cuando los documentos pertinentes están aprobados y delimitados, Polp ayuda a formular preguntas e inspeccionar la fuente de una respuesta. No es un flujo de offboarding, un sistema de identidades ni un sustituto de la revisión de un responsable. Empieza solo con el material de traspaso que el propietario haya aprobado.
5. Haz una prueba de aceptación con el sucesor
Antes del último día, pide al sucesor que complete una tarea habitual usando el registro. Debe localizar el documento autoritativo, explicar la siguiente acción, identificar al responsable y decir qué falta. Cuando sea posible, una persona responsable debe revisar el resultado con quien se va. El flujo de ServiceNow incluye una revisión del empleado antes de compartir el traspaso; aplica el mismo principio aunque tu proceso sea manual.
Registra las preguntas sin respuesta como trabajo del propietario, no como razón para inventar una solución. La definición de laguna de conocimiento ayuda a mantenerlas visibles tras la salida.
6. Mantén vivo el traspaso durante 30 días
Programa una revisión corta después de que el sucesor haya realizado el trabajo. Elimina copias sustituidas, actualiza la fecha de revisión y convierte preguntas repetidas en un procedimiento o FAQ aprobado. Si la misma pregunta vuelve una y otra vez, el traspaso te está mostrando dónde el conocimiento operativo sigue siendo frágil.
Un primer piloto de Polp puede usar una sola área aprobada, una audiencia pequeña autorizada y las preguntas reales recogidas arriba. Consulta la guía de onboarding de empleados con base de conocimiento, que cubre el flujo complementario de llegada, y solicita una demo de Polp para delimitar un piloto de conocimiento seguro y con fuentes.