blog

Ejemplo práctico: un bot de operaciones para la incorporación

Un ejemplo práctico ilustrativo de un bot de operaciones con AI que enruta solicitudes de acceso de nuevos empleados en Slack. Firma y cifras son supuestos, no un resultado de cliente.

elias a.applied ai & data4 min de lectura

Este artículo. Un ejemplo práctico ilustrativo, no un resultado de cliente. La firma de servicios y cada cifra son supuestos. Muestra cómo un bot de operaciones interno en Slack puede enrutar y aprobar solicitudes de acceso de nuevos empleados, con cada acción registrada.

Supón una firma de servicios profesionales de 40 personas. El equipo, el proceso y las cifras son supuestos para el recorrido, no mediciones de un cliente.

El proceso antiguo no está roto porque la gente sea lenta. Está roto porque un nuevo empleado necesita cuentas, acceso a herramientas y equipo, y cada solicitud vive en una bandeja distinta. La responsable de operaciones persigue aprobaciones a mano. A modo de ilustración, supón que tarda unos tres días laborables desde el inicio del primer día hasta un portátil operativo.

#¿qué se come el tiempo en una incorporación manual?

No el hacer clic. La espera. Una solicitud de plaza en GitHub espera hasta que un responsable ve el correo. Una solicitud de la herramienta de finanzas espera a otro aprobador. Nadie es dueño del traspaso, así que cada paso se detiene en una persona. El trabajo real es una fracción pequeña del tiempo transcurrido.

¿cómo automatiza la AI la incorporación de empleados sin convertirse en otro chatbot?

Enruta y aprueba, no se limita a resumir. Un bot de operaciones lee cada solicitud de acceso de un nuevo empleado en Slack, la compara con un mapa de rol a acceso y luego aprueba por sí mismo los elementos de bajo riesgo o enruta los de más riesgo al responsable designado con aprobación de un clic. Cada acción queda registrada. Lo que hay que vigilar es el tiempo transcurrido desde la solicitud hasta un acceso operativo.

#Entonces, ¿cómo es el diseño?

Un bot que vive donde ya ocurre el trabajo. Cuando se añade una contratación, abre un hilo de Slack por persona. Lee el rol, lo asocia a una lista de accesos definida, y avanza cada elemento. Las cuentas y las licencias de herramientas de bajo riesgo las concede según las reglas que fijó el cliente. Cualquier cosa sensible, como el sistema de finanzas, la enruta al responsable designado con un botón de aprobar o denegar.

  • Un hilo por cada nueva contratación, así toda la solicitud está en un solo lugar, no en cinco bandejas de entrada.
  • Mapa de roles y accesos propiedad del cliente, así las reglas son suyas y auditables.
  • Aprobación en un clic para el responsable, así una decisión tarda segundos, no un día de correos.
  • Un disparador de baja que revoca ese mismo acceso el último día de la persona.

El último elemento importa más que la velocidad de incorporación. Revocar el acceso de quien se va es el paso que todos olvidan. En este diseño se activa desde el mismo mapa que concedió el acceso, así que la baja es tan fiable como el alta y las revocaciones omitidas se vuelven algo que se puede contar.

We are

Stennir despliega un bot de operaciones que aprueba y enruta, que ejecuta una acción y la registra contra un mapa de reglas propiedad del cliente.

We aren't

No es un bot de resumen que lee una solicitud y te entrega un párrafo sobre el que todavía tienes que actuar.

#¿cómo confías en que un bot apruebe accesos?

Delimitas lo que puede decidir. El bot solo aprueba automáticamente los elementos que el cliente marcó como de bajo riesgo en su propio mapa. Todo lo demás se enruta a una persona con el contexto completo en el hilo. Cada concesión, enrutamiento y revocación queda registrado. Así la responsable de operaciones puede responder quién obtuvo acceso a qué, y cuándo, sin abrir cinco herramientas. Esa es la parte de gobernanza, y la incorporamos desde el primer día, no después.

Imagina el primer lunes que funciona: un nuevo analista tiene un portátil operativo y todos los accesos antes de comer, cuando eso solía ser un problema de miércoles. Ese es el resultado para el que se diseña y que se mide, no un resultado que estemos reportando.

En un proyecto real el código es del cliente. Encaja con el caso de uso del bot de operaciones interno dentro de implementación de AI, y tiene la misma forma que los ejemplos prácticos de logística y finanzas del journal. Mismo patrón, distinto departamento: leer la solicitud, comprobar la regla, ejecutar la acción, registrarla.

Si tu incorporación de personal es una pila de bandejas de entrada y una persona persiguiendo aprobaciones, esa es exactamente la forma que esto arregla. Cuéntanos qué estás construyendo y te diremos si un bot de operaciones es la decisión correcta o si bastaría con una automatización de dos líneas. cuéntanos qué estás construyendo.

Dinos qué tarea te lleva más tiempo.

30 minutos. Sin preparación. Te diremos con honestidad si la IA puede ayudar y por dónde empezar.