Señales de que un proceso es candidato
No todo proceso repetitivo justifica una automatización, pero ciertas señales suelen indicar que vale la pena evaluarlo formalmente:
- Volumen recurrente: se ejecuta muchas veces al día, semana o mes, no como excepción ocasional.
- Reglas identificables: aunque existan excepciones, la mayoría de los casos sigue una lógica que puede describirse.
- Recaptura o transcripción: la misma información se copia entre correo, hojas de cálculo, portales o sistemas.
- Costo visible de espera o error: el proceso genera retrabajo, retrasos o reclamos cuando algo sale mal.
- Dependencia de una persona clave: solo alguien específico sabe ejecutarlo o resolver sus excepciones.
Ninguna señal por sí sola es suficiente. Un proceso con alto volumen pero sin reglas identificables, por ejemplo, suele necesitar primero un trabajo de estandarización antes de automatizarse.
Matriz de impacto y viabilidad
Una forma simple de priorizar varios procesos candidatos es cruzar dos preguntas: cuánto impacto tendría resolverlo, y qué tan viable es hacerlo con la información y los sistemas disponibles hoy.
| Impacto | Viabilidad | Ruta sugerida |
|---|---|---|
| Alto | Alta | Priorizar: candidato para un piloto en el corto plazo. |
| Alto | Baja | Preparar primero: resolver datos, reglas o accesos antes de automatizar. |
| Bajo | Alta | Evaluar si el esfuerzo se justifica frente a otras prioridades. |
| Bajo | Baja | No automatizar por ahora: el costo no compensa el beneficio esperado. |
El impacto se estima con volumen, tiempo invertido y costo de errores; la viabilidad, con la calidad de los datos, la disponibilidad de accesos y la claridad de las reglas. Esta matriz permite priorizar iniciativas con criterios objetivos antes de un diagnóstico formal.
Qué datos reunir antes de un diagnóstico
Llegar con esta información acelera la primera conversación y hace más precisa la recomendación:
- Volumen aproximado por día, semana o mes.
- Tiempo promedio que toma completar el proceso una vez.
- Número de personas involucradas y en qué momento participa cada una.
- Sistemas o fuentes que intervienen (hojas de cálculo, correo, ERP, portales).
- Ejemplos reales de excepciones o casos que salen del flujo normal.
- Reglas documentadas, aunque sean informales o no estén escritas formalmente.
Ejemplo aplicado
Imagina una empresa donde el área de compras recibe solicitudes por correo, las transcribe a una hoja de cálculo y después las captura manualmente en el sistema de compras. El volumen es de varias decenas de solicitudes por semana, las reglas de aprobación están definidas por monto, y el principal problema es el tiempo perdido en la doble captura y los errores ocasionales de transcripción.
Con la matriz anterior, este caso tendría impacto alto (volumen y errores visibles) y viabilidad alta si el sistema de compras permite crear solicitudes por una vía distinta al capturista manual. La ruta sugerida sería priorizar un piloto acotado antes de considerar cualquier otro proceso del área.
Limitaciones de este criterio y cuándo buscar apoyo experto
Esta matriz es un filtro inicial, no un análisis definitivo. No captura riesgos regulatorios, dependencias entre procesos ni la disposición real del equipo para cambiar su forma de trabajar. Si el proceso involucra información sensible, cumplimiento normativo específico o varios sistemas críticos, conviene levantar un diagnóstico formal antes de comprometer presupuesto o tiempo del equipo.