Capacidad · Automatización de interfaz
Un robot de escritorio abre, consulta, digita y confirma dentro de su sistema tal como lo haría una persona. Cuando ese mismo sistema sí tiene API o conector, se lo decimos y usamos la API: dura más y se rompe menos.
El robot no compite con la integración: cubre el terreno donde la integración no existe. Estas son las señales de que su caso vive en ese terreno.
Decirlo antes de facturarlo es parte del trabajo. La propia guía de Microsoft recomienda preferir el conector basado en API siempre que exista, porque la API se mantiene estable aunque la aplicación cambie, mientras que el robot depende de que la pantalla no se mueva.
| Criterio | Conector o API | RPA de escritorio |
|---|---|---|
| Resistencia al cambio | Alta. El proveedor evita romper contratos de API entre versiones. | Media. Un rediseño de pantalla o un cambio de campo obliga a ajustar el robot. |
| Puesta en marcha | Depende de que exista, esté documentada y le den credenciales. | No espera a nadie: si usted puede entrar a la pantalla, el robot también. |
| Mantenimiento | Bajo y previsible. | Recurrente y planificado. Se presupuesta desde el inicio, no se descubre después. |
| Volumen y velocidad | Alto. Opera a velocidad de servicio. | Acotado. Opera a velocidad de interfaz, un caso después de otro. |
| Infraestructura | Ninguna adicional en la mayoría de casos. | Requiere una máquina o entorno donde el robot corra, y quién la vigile. |
| Rastro de auditoría | Registro de cada llamada y su respuesta. | Bitácora de cada corrida, con capturas del punto de falla cuando se detiene. |
El criterio en una línea. Si hay API, se usa la API. Si no la hay, el robot es la diferencia entre automatizar el proceso o seguir digitándolo un año más.
La parte fácil es grabar los clics. Lo que sostiene la operación es todo lo que rodea a esos clics: el manejo de excepciones, la bitácora y el traspaso documentado.
Se recorre el proceso con quien lo ejecuta hoy, incluidos los casos raros que nadie documentó.
El robot identifica los campos por sus atributos, no por su posición en pantalla.
Lo que el robot no reconoce se detiene, se notifica y queda en cola para una persona.
Qué procesó, qué omitió y en qué punto falló, con evidencia del momento de la falla.
Documentación, capacitación al área y el robot en manos de su organización.
Quién dirige la práctica. Humberto Henríquez, fundador de la firma: certificaciones Microsoft PL-500 (Power Automate RPA), PL-100 (Power Apps) y PL-300 (Power BI), Ingeniero en Sistemas con maestrías en Data Science y en Business Intelligence. Conocer la firma →
Ninguno de estos puntos es un obstáculo, pero todos se definen antes de construir: un robot sin dónde correr, sin credenciales propias y sin dueño funcional no llega a producción.
En la mayoría de los casos, el RPA cubre el tramo sin API y el resto del recorrido corre por conectores: la mezcla es lo normal, no la excepción.
Cuando la política exige que el motor viva dentro de su perímetro, la arquitectura equivalente está en orquestación autoalojada; cuando el proceso arranca con una conversación en Teams, en agentes con Copilot Studio; y cuando lo atiende un agente que consulta y ejecuta, en agentes de IA.
Es cierto y no lo negamos. Por eso el robot se construye con selectores por atributo, se detiene ante lo que no reconoce y avisa al responsable en lugar de escribir datos dudosos. El mantenimiento se presupuesta desde el día uno.
El robot, su documentación y sus credenciales quedan en su tenant y a nombre de su organización. Se entrega con manual de operación y capacitación para que su equipo pueda mantenerlo sin nosotros.
Opera con una cuenta de permisos mínimos, dentro de la ventana acordada y sin autoridad sobre los pasos irreversibles: el pago, la anulación o el envío al cliente los firma una persona. Todo queda en bitácora.
Es una conversación de arquitectura, no un impedimento: hay opciones sobre máquina virtual de su nube o sobre infraestructura administrada. Se define con TI antes de construir, con su implicación de licenciamiento a la vista.
Suele ocurrir cuando se automatizó el camino feliz y nadie definió las excepciones. Podemos hacernos cargo de lo existente: diagnóstico, manejo de excepciones, alertas y documentación, dentro de operación administrada.
Por el proceso con más volumen y menos criterio. La guía de los nueve procesos que más se automatizan ordena los candidatos, y la calculadora de retorno estima lo que cuesta hoy hacerlo a mano.
Se revisa primero si el sistema expone API, conector o base de datos accesible. Si la expone, se integra por ahí: la integración resiste los cambios de versión que rompen a un robot. El RPA entra cuando la pantalla es la única puerta disponible. La revisión forma parte de la evaluación y no compromete la contratación.
El robot se detiene en lugar de seguir con datos dudosos, avisa al responsable y deja el caso registrado en bitácora. Ajustar el selector afectado es trabajo de mantenimiento previsto, no un rediseño del proceso; con operación administrada, ese monitoreo queda de nuestro lado.
El robot necesita una máquina donde ejecutarse: una estación dedicada, una máquina virtual de su organización o infraestructura administrada. Cuál corresponde y qué licenciamiento implica se define con su área de TI durante la evaluación, junto con el resto del esquema de automatización sobre Microsoft 365.
En la evaluación ejecutiva revisamos si su caso pide un robot, un conector o ninguno de los dos, y se lo decimos con el mismo criterio que aplicaríamos si el proyecto fuera nuestro.
