Staff augmentation en automatización: sumar un experto a tu equipo

En LatAm la automatización se compra de dos maneras. En un proyecto cerrado contratas un resultado: un proceso específico funcionando en una fecha acordada. El staff augmentation te da capacidad, es decir, un desarrollador de RPA que trabaja dentro de tu equipo con tus prioridades, tu lista de pendientes y tus reuniones.

Los dos modelos son válidos y en Robotipy trabajamos con ambos. Elegir mal sale caro, y el error tarda unos seis meses en hacerse visible. Esa elección queda en un contrato que, entre otras cosas, define quién arregla un robot que falla un martes a las siete de la mañana, antes de que el área usuaria empiece su jornada.

Qué compras en cada modelo

Entre los dos modelos cambia sobre todo quién asume el riesgo de estimación. El precio por hora, que suele ser lo primero que se compara, sirve poco para decidir.

En un proyecto cerrado ese riesgo es del proveedor. Si el proceso resulta más enredado de lo que se vio en el levantamiento y el trabajo se alarga, el costo extra lo absorbemos nosotros. Un desarrollo con nosotros promedia USD 6.000 e incluye la marcha blanca, un período en que el robot funciona en paralelo al proceso manual hasta que los números cuadran. Ese valor está publicado y explicado en cuánto cuesta automatizar un proceso.

Si pagas las horas de un perfil, el riesgo pasa a ser tuyo. A cambio ganas continuidad y una persona que va conociendo tus sistemas, y puedes cambiar de prioridad un lunes sin renegociar alcance con nadie.

Cuándo conviene más el staff augmentation que un proyecto

Contratar capacidad rinde más que contratar entregables en estos casos:

• Ya tienes robots en producción y te falta gente para sostenerlos. Los proyectos nuevos son lo que se ve, pero con ocho o diez robots en operación, buena parte del trabajo consiste en adaptarse a cambios de portales, ajustar reglas y reprocesar ejecuciones. Ese trabajo no tiene un alcance definible, así que cotizarlo como proyecto funciona mal.
• Las prioridades cambian más rápido de lo que tarda una cotización. El proceso urgente de hoy puede dejar de serlo en tres semanas, y cerrar alcances con esa volatilidad termina en una cadena de órdenes de cambio.
• Estás formando un equipo interno y necesitas a alguien con experiencia al lado de tus analistas. Un desarrollador senior les enseña a decidir con criterio, sobre todo qué procesos conviene dejar sin automatizar.
• Tienes muchos procesos pequeños. Automatizaciones de tres o cuatro pasos no justifican el costo comercial de cotizar cada una por separado. Avanzan mejor como una lista priorizada que alguien va resolviendo.
• Tus restricciones de acceso impiden trabajar desde fuera. Algunas empresas, sobre todo de banca y salud, no pueden dar accesos a un tercero por proyecto, pero sí pueden incorporar a una persona bajo su propio esquema de usuarios y auditoría.

Si solo quieres automatizar un proceso puntual y evaluar después, no estás en ninguno de esos cinco casos. Te conviene un proyecto cerrado, que da un resultado más previsible y no te obliga a gestionar a nadie.

Por qué fracasa el staff augmentation

El fracaso más común empieza en el cliente. Compra horas de un desarrollador, espera el resultado de un proyecto y no asigna a nadie que priorice, consiga los accesos y haga que el dueño del proceso responda las dudas. La persona avanza bien mientras tiene tareas claras y luego se queda esperando respuestas. Meses más tarde se discute por qué se avanzó tan poco, aunque el freno estuvo en las decisiones que el cliente no tomó.

El segundo problema es que cobrar por hora premia que el trabajo dure. Ocurre con cualquier servicio profesional que se cobra por tiempo, y puede sesgar las decisiones técnicas del proveedor sin que haya mala fe: ante dos opciones, tiende a elegir la más completa antes que la más corta. Para nosotros, la única defensa razonable es medir lo que pasa a producción.

El estándar de desarrollo tiene que quedar por escrito

El contrato debería incluir como anexo el estándar con que se construyen los robots. De esa cláusula depende cuánto te cuesta mantenerlos dos años después.

El código que escribe un desarrollador externo dentro de tu equipo se queda en tu empresa. Las personas rotan bastante en este modelo, porque cambian de proyecto, de proveedor y a veces de país. Si cada persona que pasó por el puesto armó los robots a su manera, quien llega después tarda medio día en encontrar dónde está definida una ruta. Ese medio día lo pagas tú cada vez que alguien rota.

Nosotros entregamos con el mismo estándar en cualquier modelo de contratación. Para evaluar el de un proveedor, pregúntale cómo se cambia la carpeta de descarga de un robot que ya está en producción. Una respuesta del tipo "hay que abrir el flujo y buscar dónde quedó escrita la ruta" anticipa un robot caro de mantener. En los nuestros, ese tipo de parámetro está en un archivo .ini separado, dentro de la carpeta de recursos, y se modifica sin tocar el robot.

La segunda pregunta es qué pasa si hay que reprocesar el día de ayer. Cada uno de nuestros proyectos lleva su propia base SQLite local con el registro de lo que ya procesó, y esa base impide que un reproceso duplique operaciones.

Pide el estándar por escrito antes de que se escriba la primera línea de código, aunque sea el del proveedor. Es un anexo de unas dos páginas. Lo tratamos con más detalle en de 1 robot a un Centro de Excelencia.

Cómo medir a un desarrollador que no entrega proyectos

Lo que proponemos es acordar un compromiso por período con dos números: cuántos procesos pasan a producción y qué parte del mes se reserva para sostener los robots que ya están en operación.

Acordar el segundo número evita una discusión típica del cuarto mes. Un desarrollador que además opera diez robots no tiene ocho horas diarias para desarrollo nuevo, aunque su contrato diga cuarenta horas semanales. De dónde sale esa carga de mantenimiento lo explicamos en mantenimiento de robots RPA.

Pide además que ambos números salgan de sistemas que la persona evaluada no pueda editar, porque un reporte de avance escrito por ella misma no permite verificar nada. En nuestro caso, Rocketbot, el orquestador, maneja la agenda de ejecuciones y el reparto del trabajo entre máquinas, y Robotipy Monitor registra qué se ejecutó, qué falló y con qué logs.

Los accesos se definen antes del primer día

Un desarrollador de automatización casi siempre necesita más permisos que uno de software tradicional, porque entra a los sistemas transaccionales con una cuenta que ejecuta operaciones reales. Si para eso usa la cuenta personal de alguien del equipo, tienes un problema de auditoría desde el primer día y nadie lo va a notar hasta que llegue una revisión.

Antes de que la persona empiece, deja definido qué cuenta de servicio usa cada robot, dónde se guardan las credenciales, quién las rota y qué pasa el día que termina el contrato. Se resuelve en una conversación de treinta minutos con el área de seguridad durante la semana previa al inicio. Cuando se posterga, el proyecto suele frenarse en la misma semana en que había que entregar. El tema completo está en seguridad y gobierno en proyectos de RPA.

Preguntas frecuentes

Si estás decidiendo entre formar un equipo interno, contratar proyectos o sumar a alguien por dedicación, primero define qué procesos conviene automatizar y después elige el modelo para ejecutarlos. Lo primero lo tratamos en cómo priorizar qué procesos automatizar, y los criterios para evaluar a un proveedor están en cómo elegir un partner de RPA en LatAm.