Recursos · Talento tech
Ya eligió la plataforma: falta elegir quién la implementa
Elegir la plataforma tecnológica es la primera decisión. La segunda, la que se paga en producción, es confirmar que el equipo que la va a implementar ya trabajó antes en esa plataforma puntual.
Justo Torrente Olmos · 22 de agosto de 2026 · 5 min
Revisado el 22 de agosto de 2026

En esta guía
- Elegir la plataforma fue la primera decisión, no la única
- Saber de automatización no es lo mismo que haber implementado esta plataforma puntual
- Qué preguntar antes de contratar: proyectos previos en esa plataforma puntual
- El caso que la documentación no cubre aparece en la semana tres
- Cómo se arma el equipo según cuánta plataforma ya domina el proveedor
Ya pasó por el proceso de evaluar opciones y eligió la plataforma tecnológica: la herramienta de automatización, RPA, orquestación o low code que su empresa va a usar. Esa decisión llevó semanas de comparar funcionalidades, precios y referencias. Lo que queda ahora es una segunda decisión, tan importante como la primera y con mucho menos atención: a quién contrata para implementarla.
Elegir la plataforma fue la primera decisión, no la única
Comparar plataformas es un ejercicio conocido: funcionalidades, integraciones nativas, precio de licencia, curva de adopción para el equipo interno. Ese trabajo suele hacerse con cuidado, porque cambiar de plataforma más adelante es costoso.
Lo que se hace con menos cuidado es la decisión siguiente: quién la va a implementar. Es común asumir que, una vez elegida la herramienta, cualquier proveedor con experiencia en automatización puede ejecutarla. Esa suposición es la que produce la mayoría de los proyectos que se atrasan sin una causa evidente en el contrato ni en el alcance. Por qué elegir la plataforma no resuelve el proyecto: falta quién la implemente con experiencia real, y esa es la pregunta que casi nadie se hace antes de firmar.
Saber de automatización no es lo mismo que haber implementado esta plataforma puntual
Un proveedor puede tener años de trayectoria en automatización de procesos y, aun así, no haber trabajado nunca con la plataforma específica que su empresa eligió. La automatización como disciplina comparte principios generales (mapear el proceso, definir reglas, integrar sistemas), pero cada plataforma tiene su propia lógica de configuración, sus propios límites técnicos y sus propias formas de romperse.
Confirmar que un proveedor "sabe de automatización" no confirma que sepa implementar esa plataforma en particular. Son dos verificaciones distintas, y solo la segunda predice cómo va a ir su proyecto. La diferencia entre 'sabe de automatización' y 'ya implementó esta plataforma puntual' es exactamente la que separa un proyecto que avanza de uno que se atrasa aprendiendo sobre la marcha.
Qué preguntar antes de contratar: proyectos previos en esa plataforma puntual
La pregunta que separa a un proveedor con experiencia real de uno que la va a adquirir en su proyecto es simple de hacer y difícil de simular: ¿qué proyectos ejecutó antes, específicamente, en esta plataforma? No en automatización en general, no en una plataforma parecida.
En Bprosys, esa evidencia se puede verificar de forma concreta. La alianza formal con BOC Group para la plataforma BPM ADONIS es experiencia puntual en una herramienta nombrada, no una afirmación genérica de conocimiento en BPM. El mismo criterio aplica al resto del portafolio: RPA e IA con Power Automate, Automation Anywhere, Rocketbot, BluePrism y UiPath; low code y no code con AgentUI, PerfectApps, Decisions, Microsoft Power Platform y Airtable; integración y orquestación con Stonebranch, GoAnywhere y n8n; cierre financiero con Simetrik; cobranza con PayMeSoft. Antes de contratar, pida ver en cuál de esas plataformas puntuales ya trabajó el proveedor, no una lista de categorías. Qué preguntar antes de contratar: proyectos previos en esa plataforma, casos resueltos fuera de la documentación, referencias que pueda llamar. Esa es la lista corta que reemplaza a cualquier folleto comercial.
El caso que la documentación no cubre aparece en la semana tres
El primer par de semanas de un proyecto de implementación suele ir bien con cualquier proveedor competente: se releva el proceso, se configura el caso estándar, las demos funcionan. La diferencia entre un equipo que ya implementó la plataforma y uno que la está aprendiendo aparece más tarde, cuando el flujo se encuentra con un dato real que no sigue el patrón esperado.
Ese caso fuera de manual es exactamente el que la documentación oficial de la plataforma no cubre, porque cada implementación real tiene excepciones propias del negocio. Un equipo que ya pasó por eso antes en esa misma plataforma reconoce el tipo de problema y sabe por dónde resolverlo. Un equipo que la está conociendo pierde días probando configuraciones y escalando al soporte oficial, mientras el proyecto se atrasa. Esa es la curva de aprendizaje del proveedor, y en un proyecto sin experiencia previa en la plataforma, la termina pagando el cliente. El costo de pagar la curva de aprendizaje del proveedor no aparece en la propuesta comercial: aparece en el cronograma corrido y en las horas extra que su equipo termina supervisando.
Antes de llegar a ese punto conviene entender bien el proceso que se va a automatizar, no solo la plataforma que lo va a ejecutar. Es el criterio que aplicamos con Process Discovery: entender primero, automatizar después, para no pagar al mismo tiempo la curva de aprendizaje del proceso y la de la plataforma.
Cómo se arma el equipo según cuánta plataforma ya domina el proveedor
Confirmada la experiencia previa en la plataforma elegida, la siguiente pregunta es cuánto equipo sumar. Depende de cuánta estructura técnica ya tiene la empresa y del tamaño del proyecto, no solo de la plataforma en sí. Cómo se arma el equipo según cuánta plataforma ya domina el proveedor: perfil puntual o célula dedicada, se decide con ese mismo criterio.
Si el proyecto es acotado y su equipo ya lidera la implementación, alcanza con sumar un perfil especializado en esa plataforma puntual por el tiempo que dure el trabajo: la modalidad de Staff Augmentation, explicada con más detalle en staffing nearshore: el perfil que necesita, en días. Si el proyecto es más grande, todavía no tiene quién lo lidere de punta a punta, o hay varios procesos para implementar en la misma plataforma, conviene un equipo completo dedicado a ese frente, tal como se describe en Célula Dedicada: cuándo conviene un equipo tech completo. En ambos casos, la falta de manos especializadas para ejecutar lo que ya se decidió automatizar es el mismo cuello de botella que describimos en sabe qué automatizar: el problema es quién lo construye.
En Bprosys llevamos más de 15 años implementando plataformas de automatización en 7 países de LATAM, con evidencia verificable de en cuáles trabajamos antes, plataforma por plataforma. Si ya eligió su plataforma y necesita confirmar quién la va a implementar con experiencia real, hablemos 20 minutos sobre su proyecto.
Preguntas frecuentes sobre cómo elegir el equipo que va a implementar la plataforma tecnológica ya elegida
¿Qué preguntar a un proveedor para saber si ya implementó la plataforma que elegí?
Pida proyectos previos ejecutados específicamente en esa plataforma, con referencias verificables, y no en 'automatización' o 'RPA' en general. Un proveedor que ya la implementó puede describir con precisión cómo se conecta con los sistemas típicos del rubro, qué limitaciones tiene la herramienta y qué casos suelen romper el flujo estándar. Un proveedor que la está aprendiendo responde en términos genéricos, sin ese nivel de detalle.
¿Qué riesgo tiene contratar a un equipo que aprende la plataforma durante mi proyecto?
El riesgo es pagar dos curvas de aprendizaje al precio de una: la del proceso de su empresa y la de la plataforma misma. Ese costo no aparece en la propuesta inicial, aparece en el cronograma que se corre y en los casos de excepción que el equipo resuelve por prueba y error en lugar de por experiencia previa.
¿Cómo se arma un equipo de implementación para una plataforma ya elegida?
Depende de cuánto trabajo hay y de cuánta estructura técnica tiene ya la empresa. Si alcanza con reforzar puntualmente, un perfil especializado que se integre al equipo existente suele resolverlo. Si el proyecto necesita relevamiento, construcción, pruebas e integración de punta a punta, conviene un equipo completo dedicado exclusivamente a ese frente.
¿Qué pasa cuando aparece un caso que no está en la documentación de la plataforma?
Ahí se nota si el equipo ya implementó esa plataforma antes o la está conociendo en su proyecto. Un equipo con experiencia previa reconoce el patrón, sabe qué configuración o extensión suele resolverlo y no depende de escalarlo al soporte oficial. Un equipo sin ese antecedente pierde días documentando y probando algo que ya debería conocer.
¿Conviene un equipo dedicado o sumar un perfil puntual para implementar la plataforma que ya elegí?
Un perfil puntual (Staff Augmentation) alcanza cuando el proyecto es acotado y su equipo ya lidera la implementación, solo necesita capacidad técnica adicional en esa plataforma. Una Célula Dedicada conviene cuando el proyecto es más grande, todavía no tiene quién lo lidere de punta a punta, o hay varios procesos para implementar en paralelo en la misma plataforma.
Seguir leyendo