En este artículo
Para que una persona pueda empezar una tarea el primer día, separe cuatro estados: acceso solicitado, aprobado por quien corresponde, habilitado por el área técnica y comprobado con la cuenta de la persona. Asigne un dueño y una fecha de revisión a cada transición antes de prometer la tarea. Si una aprobación no llega, el líder debe decidir qué trabajo autorizado puede hacerse mientras tanto y cuándo cambiará el compromiso. RH puede coordinar la llegada, pero no debe convertir una fecha de ingreso en permiso automático. Tener una cuenta creada tampoco demuestra que el recurso necesario funcione.
Este artículo resuelve una decisión puntual del alta: cómo preparar y verificar permisos para el primer trabajo. La guía de onboarding de 30, 60 y 90 días trata la integración más amplia. Y la pieza sobre la lista que RH entrega a Operaciones se ocupa de una transferencia para organizar la inducción; aquí el objeto es una autorización sobre recursos de trabajo y la prueba de que ese acceso permite comenzar.
La fecha de ingreso y el permiso son decisiones distintas
Escena ilustrativa, con empresa y personas ficticias. RH confirma que Valeria ingresará el lunes como analista de operaciones. Su líder prepara una primera tarea: revisar incidencias en un tablero y proponer preguntas para la reunión del martes. El viernes, el equipo técnico crea su cuenta. El lunes, Valeria abre el correo y la plantilla, pero el tablero le muestra “sin autorización”. El líder había entendido “cuenta creada” como “todo listo”; RH había entendido “solicitud enviada” como “permiso confirmado”; el dueño del tablero todavía no había revisado la petición.
No se necesita suponer negligencia individual para ver el vacío. Cada función completó una parte, pero nadie verificó la cadena entera. Si el líder insiste en el informe, Valeria deberá pedir una nueva ruta, cambiar el alcance o esperar. La guía Worklife explica cómo puede comunicar ese bloqueo sin cargarlo como una falla de desempeño. Para la organización, la pregunta anterior al primer día es otra: ¿quién sabía que el tablero era indispensable, quién podía autorizarlo y cómo se comprobaría que Valeria entraba con su propia cuenta?
El ejemplo no describe un cliente ni un resultado de KLIIMA. Tampoco significa que todo permiso deba estar listo antes de la contratación. Puede haber acceso que depende de capacitación, verificación o condiciones aún no cumplidas. Lo que sí debe estar listo es una decisión honesta sobre el primer trabajo: qué recursos necesita, qué autorizaciones siguen pendientes y qué se hará si no llegan. Una agenda de bienvenida no corrige una tarea imposible.
Defina “listo” según el trabajo, no según una casilla verde
Antes de medir el alta, acuerden qué significa “listo para empezar” para ese puesto y esa primera actividad. Una identidad creada es un estado administrativo. Poder autenticarse es otro. Ver la aplicación no prueba que la persona pueda consultar el recurso correcto; ver un menú tampoco prueba que pueda realizar la acción necesaria. A la inversa, no toda persona necesita permisos amplios desde el primer día. La prueba debe corresponder a un caso de uso autorizado.
Una descripción útil es: “Con su cuenta, la persona puede abrir el tablero de incidencias del área y consultar la vista agregada que requiere el primer informe”. Identifique recurso, nivel de permiso y tarea. Es mejor que “dar acceso al sistema”, que deja espacio para sobreasignar privilegios. El glosario de NIST define el privilegio mínimo como limitar autorizaciones y recursos a lo necesario para la función. Esa es una referencia de diseño, no una lista de permisos aplicable sin más a cada empresa.
Si el primer día será de observación y no requiere datos del tablero, no inventen un acceso urgente. Si el líder cambió la tarea para incluir un informe, actualicen la necesidad y soliciten aprobación. Si existen entornos de práctica, úsenlos sólo si están aprobados para esa finalidad. “Primer día” es una meta de preparación para trabajo previsto, no un argumento para omitir controles.
Conviene distinguir “preparado” de “garantizado”. Una solicitud puede estar aprobada y fallar por configuración, sincronización o un error de la aplicación. La comprobación final debe registrar si la persona puede hacer la acción prevista. Si todavía no ingresa, el estado no es verde porque un administrador vea una casilla activa. Cerrar el caso antes de probarlo desplaza el costo de descubrir el fallo a quien acaba de incorporarse.
Empiece por una solicitud que permita decidir
El líder del puesto debería indicar la primera tarea y los recursos que la hacen posible. RH aporta datos de ingreso confirmados por el canal autorizado, como fecha y tipo de relación, y coordina que el alta empiece cuando corresponde. El dueño de cada recurso decide qué permisos proceden; el área técnica los configura tras la autorización y verifica el estado de ejecución. En una organización pequeña, una persona puede cubrir varias funciones, pero las decisiones siguen siendo distintas. Especificarlas evita que “ya lo vio RH” se interprete como aprobación de un recurso.
La solicitud mínima contiene: rol vigente, tarea concreta, recurso, nivel de acceso requerido, fecha en que se necesita para esa tarea, aprobador identificado y canal donde se registrará la respuesta. Agregue información adicional sólo si la política interna la exige. No copie documentos de identidad, datos médicos, conversaciones de contratación ni credenciales en un tablero compartido para explicar por qué existe la cuenta. Una solicitud completa debe ayudar a evaluar el permiso, no convertirse en expediente paralelo.
La OIT subraya en su manual de gestión de recursos humanos que el diseño del puesto y las descripciones escritas dan dirección y criterios para valorar el trabajo. Es un principio general de claridad de funciones; no aprueba por sí solo ningún acceso. Aquí permite comprobar si el permiso solicitado responde a una responsabilidad real. Si nadie puede describir por qué la persona necesita editar una base de datos durante su primera semana, conviene resolver esa pregunta antes de conceder edición.
El formulario o ticket puede incluir una opción “decisión de rol pendiente”. Esa etiqueta no es una aprobación provisional; revela que el líder y el dueño del recurso deben aclarar la tarea. Es preferible a copiar los permisos del ocupante anterior sin revisar si su trabajo, proyecto o nivel de responsabilidad era el mismo.
Aprobación, habilitación y prueba tienen dueños diferentes
Un flujo simple puede funcionar sin comprar otro sistema. El líder solicita el acceso. Quien posee el recurso acepta, limita o niega la petición conforme a las reglas existentes. El equipo administrador ejecuta la decisión. La persona nueva confirma con su propia cuenta que puede realizar la acción prevista, y el líder valida que ya puede encargar el trabajo. Cada paso debe tener fecha y responsable. Si la misma persona administra y aprueba, la organización debe evaluar si esa concentración está permitida; este artículo no modifica la política de separación de funciones.
El catálogo de controles AC-2 y AC-6 de NIST SP 800-53 ofrece referencias sobre gestión de cuentas y privilegio mínimo. No impone una herramienta concreta ni sustituye el proceso local de aprobación. Su valor para esta conversación es recordar que crear una cuenta y asignarle derechos son acciones gestionadas, no favores informales activados por una fecha en el calendario.
Al registrar un avance, usen verbos precisos. “RH notificó el ingreso”, “el líder solicitó la vista de lectura”, “el dueño aprobó la vista de lectura”, “TI habilitó”, “la persona comprobó”. “Resuelto” sólo es una etiqueta útil cuando se entiende qué acción final se verificó. Si la configuración está terminada pero la persona todavía no ha probado acceso, el estado puede ser “habilitado, pendiente de prueba”; eso no impide preparar otras partes de la jornada.
Los productos técnicos pueden ofrecer automatización, pero esa posibilidad no elimina la decisión de negocio. Microsoft documenta tareas de flujos de ciclo de vida para procesos de incorporación y gestión de identidad. Es un ejemplo de un proveedor sobre sus propias herramientas, no evidencia de que la empresa lectora las use o de que automatizar conceda autoridad. Si la política de permisos está mal definida, un flujo automático puede ejecutar esa ambigüedad más rápido.
Planifique hacia atrás desde la primera actividad real
No fije un “tres días antes” universal. Pregunte cuándo empieza la tarea que requiere el recurso y cuánto tiempo necesitan el aprobador, el equipo técnico y la prueba según sus procesos. Algunas altas se resuelven pronto; otras dependen de licencias, verificación o una decisión de seguridad. Calcule ventanas internas con datos propios y deje explícita la fecha de corte para cambiar la agenda, no una promesa de que todas las solicitudes serán aprobadas.
Una secuencia ilustrativa podría ser: al confirmarse el ingreso, RH avisa por el canal designado; el líder define dos tareas iniciales y sus recursos; los dueños responden antes de que TI configure; TI registra qué se completó y qué falló; la persona prueba el acceso en una actividad acotada. La secuencia puede empezar semanas o días antes según el caso. El punto es que nadie descubra por primera vez el permiso faltante cuando ya prometió un entregable al cliente o al equipo.
Conviene programar una revisión previa donde se lean sólo los pendientes que afectan el primer trabajo. “¿Qué acceso aún espera decisión? ¿Quién debe responder? ¿Cuál es la fecha límite para cambiar la tarea inicial?”. Una reunión que enumera veinte sistemas sin relación con el primer día consume tiempo y puede presionar para habilitar accesos innecesarios. La revisión debe convertir una incertidumbre en una decisión, no llenar una lista.
Deje evidencia suficiente sin publicar un expediente de acceso
Para coordinar, basta con registrar estados y referencias, no replicar todos los datos del sistema de identidad. Una ficha operativa puede incluir un identificador interno de incorporación, rol, primer trabajo, recurso solicitado, tipo de permiso, persona o función aprobadora, estado actual, fecha de última decisión y siguiente revisión. La evidencia de aprobación y los registros técnicos pueden permanecer en las herramientas autorizadas, enlazados por un número de caso que sólo vea quien lo necesita.
“Solicitado” significa que existe una petición. “Aprobado” significa que quien tiene autoridad tomó una decisión sobre un alcance concreto. “Habilitado” significa que se ejecutó técnicamente. “Probado” significa que la persona pudo realizar una acción autorizada con su propia identidad. “Rechazado” o “pendiente de información” también son resultados útiles: obligan a cambiar el trabajo previsto o aclarar la necesidad. No convierta “rechazado” en una falla automática del área técnica.
Si usa un tablero compartido, evite contraseñas, enlaces de recuperación, datos que revelen más de lo necesario y capturas del sistema con información de terceros. Defina quién puede ver la ficha y cuándo se retira. Un registro de coordinación debe responder “¿qué sigue y quién decide?”, no convertirse en un inventario público de permisos individuales. Siga los controles de privacidad y conservación de la organización; este artículo no establece una regla legal de retención.
En sistemas que ya tienen historial, aprovéchelo antes de duplicar información. Microsoft explica cómo consultar estados de tareas completas, en curso, fallidas o sin procesar dentro de sus flujos de ciclo de vida. Esa documentación demuestra una capacidad de esa herramienta, no recomienda que todo equipo adopte esa plataforma. El principio transferible es más simple: distinguir una tarea ejecutada de una pendiente con evidencia que se pueda verificar.
La prueba debe parecerse al primer trabajo, con límites
Una prueba de acceso no exige exponer datos sensibles ni realizar una acción irreversible. Puede consistir en abrir la vista autorizada, verificar que se observa el recurso correcto y, si el puesto lo necesita, intentar una operación inocua de práctica permitida. El líder y el área técnica deben definir de antemano qué cuenta como prueba. “Entró al portal” no basta si la tarea requiere un reporte de una sección distinta. “Pudo modificar cualquier cosa” tampoco es un objetivo aceptable para demostrar que puede leer.
La persona recién incorporada puede reportar exactamente qué ocurrió: “Entré con mi cuenta, veo el tablero principal, pero la vista de incidencias devuelve un error”. Pídanle una descripción de la pantalla y el paso; no le soliciten que envíe secretos o una captura de datos de clientes por un canal improvisado. Si hace falta diagnóstico técnico, el equipo responsable indicará cómo recopilarlo con seguridad.
La prueba también protege contra un falso positivo organizacional. El ticket puede aparecer cerrado y el acceso fallar por una asignación incorrecta. En ese caso, reabran o vinculen la incidencia y actualicen la agenda de trabajo. No pidan a la persona que improvise una solución o que use la cuenta de un colega. Su reporte es una señal de que el resultado aún no funciona, no una queja que deba justificarse.
Cuando la prueba sí funciona, confirmen el alcance: ¿puede consultar lo necesario sin editar algo que no debe?, ¿sabe por dónde entrar?, ¿conoce el canal de soporte si vuelve a fallar? Probar una tarea acotada evita declarar “todos los accesos listos” cuando sólo se verificó uno. Un conjunto de altas puede avanzar por recurso, con estado y fecha propios.
Decida las excepciones antes de que la urgencia decida por el equipo
La primera excepción es una aprobación pendiente. Puede faltar información, el dueño del recurso puede no estar disponible o el uso propuesto puede no corresponder al rol. Identifiquen el motivo y el responsable de resolverlo. Si la empresa ya tiene suplencia formal, úsenla; si no, no inventen una aprobación por silencio. El líder debe elegir una tarea distinta o mover el compromiso que dependía del permiso.
La segunda es un permiso denegado. Pregunten si existe una forma autorizada de obtener el resultado: un dato agregado preparado por alguien facultado, una vista de menor privilegio o una asignación alternativa. No pidan a TI que “lo abra por un día” sin la aprobación prevista. Una negativa puede mostrar que el plan del puesto necesita corregirse; no implica que la persona nueva haya fallado.
La tercera es una solicitud demasiado amplia. “Acceso a todo el proyecto” puede esconder varias funciones con distintos dueños. Divídanla por tarea y recurso para que cada responsable decida lo suyo. El principio de privilegio mínimo de NIST sirve como criterio de alcance, aunque cada organización debe aplicar su política y su análisis de riesgos. No conviertan la simplificación administrativa en un privilegio permanente sin revisar.
La cuarta es una incorporación que cambia de fecha, modalidad o puesto. Revisen autorizaciones ya emitidas y solicitudes abiertas. Tal vez un permiso deja de ser necesario o debe esperar. La coordinación del alta no termina al crear una cuenta; depende de que la función y la actividad previstas sigan vigentes. Los accesos posteriores, las transferencias y las bajas requieren sus propios procesos, fuera del objetivo específico de esta pieza.
Una conversación breve puede revelar el atasco real
En lugar de una cadena de correos que dice “¿cómo vamos?”, hagan una revisión con cuatro preguntas. El líder: “¿Qué hará la persona en su primer trabajo?”. El dueño del recurso: “¿Ese uso está autorizado y con qué alcance?”. El administrador: “¿Qué quedó habilitado y qué condición falta?”. RH: “¿Qué fecha de ingreso está confirmada y a quién avisaremos si cambia?”. La persona nueva interviene para comprobar el acceso, no para negociar permisos que todavía no le corresponde aprobar.
Supongamos que el líder responde “necesita revisar las incidencias de su área”; el dueño autoriza lectura de una vista; TI la habilita; Valeria prueba y puede verla. La ficha se cierra para esa tarea. Si el dueño responde “no se puede consultar información individual”, el líder debe revisar qué informe pedir. El flujo funcionó aunque no se concediera el permiso original: produjo una decisión válida antes de fingir que el entregable seguía igual.
Al cerrar el ingreso, pregunten también qué quedó difícil de entender. Si el líder pidió un recurso equivocado, ajusten su guía de solicitud. Si el aprobador no recibió el caso, revisen la transición. Si la persona pudo entrar pero no comprendió el primer trabajo, eso ya no es un problema de permisos y debe tratarse como claridad de rol, la materia de la guía de onboarding 30-60-90.
Mida la dependencia que quiere corregir, sin culpar a quien acaba de llegar
El dato más útil no es “cuántos tickets cerró TI” si el problema es que las personas no pueden empezar una tarea. Para una revisión interna, definan una unidad: incorporaciones con primera actividad especificada que requería un recurso particular. Después registren cuántas tuvieron el permiso aprobado, habilitado y probado antes de esa actividad; cuántas recibieron una tarea alternativa autorizada; y cuántas descubrieron el bloqueo al intentar trabajar. No mezcle estos estados en una sola tasa de “altas exitosas”.
Si falta información, márquela como desconocida. Una prueba sin registrar no es necesariamente un fracaso ni un éxito. Conviene anotar también por qué se movió un compromiso: aprobación pendiente, configuración fallida, cambio de rol o definición tardía de la tarea. El objetivo de esta clasificación es mejorar transiciones y decisiones, no construir un ranking de personas nuevas, aprobadores o técnicos con casos incomparables.
Revisen una muestra de incorporaciones de roles distintos. Si los permisos de lectura básicos suelen estar a tiempo pero los recursos especializados se solicitan después de la fecha, la respuesta puede estar en la planificación del líder. Si las aprobaciones llegan y la prueba falla, hay que mirar la habilitación. Si un permiso se niega con frecuencia, tal vez la primera tarea definida no corresponde al rol. Cada patrón exige una decisión diferente.
Una medición útil debe llevar a una acción pequeña: cambiar el campo de tarea inicial, asignar suplencia al aprobador según política, mover la revisión previa o definir una prueba mejor. Si la ficha sólo genera reportes y nadie cambia una decisión, simplifíquenla. Preparar accesos no equivale a evaluar adaptación, compromiso o capacidad de Valeria. Es una condición de trabajo que la organización debe hacer visible.
Cierre el alta con una promesa que sí puede cumplir
Antes de decir “todo listo”, el líder puede confirmar tres hechos: la tarea inicial sigue vigente, los recursos necesarios tienen decisión de acceso y la persona pudo comprobar las funciones que usará. Si falta alguno, el compromiso debe decirlo. “La cuenta está creada; la vista del informe espera aprobación; el lunes comenzarás con la revisión de formato y el martes confirmaremos si puedes preparar el recuento” es menos brillante que “todo listo”, pero orienta mejor el trabajo.
RH puede asegurar que el cambio de estado llegue a quien prepara la bienvenida. TI puede informar la configuración ejecutada. El dueño del recurso puede sostener el criterio de autorización. La persona nueva puede probar y reportar el resultado. Nadie debe hacer pasar su parte por toda la cadena. Esa claridad permite reconocer una incorporación preparada sin pedir que alguien comparta credenciales o que se prometa un entregable imposible.
El primer día no exige que cada sistema de la empresa esté disponible. Exige que el primer trabajo tenga una ruta real y que los permisos necesarios sigan los controles establecidos. Cuando un acceso falta, la organización conserva dos obligaciones operativas: resolver la decisión por el cauce correcto y no atribuir a la persona un retraso que todavía depende de esa decisión. El resto de la integración necesitará acompañamiento, práctica y revisión más allá de una cuenta funcional.
Acción breve: en una incorporación próxima, elija la primera tarea real y llene una ficha de una línea: recurso necesario, alcance, aprobador, ejecutor, fecha de revisión y prueba con la cuenta de la persona. Si no puede completar un campo, identifique quién debe decidirlo antes de prometer la tarea.
La experiencia individual: Me piden entregar, pero todavía no tengo acceso muestra cómo puede avisar del bloqueo quien recién llega. Para la coordinación de turnos y recepción, consulte la entrega de RH a Operaciones.
Puede consultar las opciones disponibles con KLIIMA, sin asumir un servicio de implementación. El contacto no configura permisos ni sustituye a sus responsables.
Que esta lectura no se quede como una pestaña abierta.
Enviamos ideas prácticas sobre psicología organizacional aplicada, liderazgo, clima, confianza, burnout y decisiones de talento. Si esta lectura sobre people analytics y rh estratégico te sirvió, el newsletter te ayuda a convertir interés en criterio de trabajo.
Sin ruido motivacional. Sin promesas mágicas. Solo lectura organizacional para RH, líderes y dirección.
Conceptos ligados a esta lectura.
Definiciones rápidas para aterrizar esta conversación en lenguaje de Recursos Humanos, psicología organizacional y desarrollo organizacional.
Contenido editorial institucional basado en psicología organizacional aplicada, desarrollo de liderazgo y experiencia práctica en Recursos Humanos.