Cómo priorizar iniciativas de automatización con recursos limitados
En una aseguradora mediana, el equipo de siniestros pedía desde hacía meses un bot para cruzar pólizas contra reportes de fraude. Nunca llegó a la cola de desarrollo. En cambio, se automatizó primero el envío de recordatorios de pago, una tarea que tomaba diez minutos al día. La razón no fue técnica: el gerente de cobranza se quejaba más fuerte y tenía más peso en el comité. Seis meses después, el fraude no detectado costó más que todo el presupuesto anual de TI.
Esto pasa constantemente. Las ideas de automatización en una empresa en crecimiento son infinitas, pero el presupuesto, el tiempo de desarrollo y la capacidad del personal para adaptarse a nuevas herramientas no lo son. Y ante ese límite, la mayoría de los líderes de operaciones prioriza por el criterio equivocado: se construye primero lo que pide el departamento más ruidoso o el directivo con más influencia interna.
El resultado es previsible: capital destruido, equipos de desarrollo saturados en proyectos de bajo impacto, y software huérfano que nadie usa seis meses después. La alternativa es tratar la priorización como un ejercicio cuantitativo, no político.
FrameworkLa matriz esfuerzo/impacto
Esta idea no es nueva — es una variante de frameworks como ICE o RICE scoring, aplicada a automatización. La lógica es simple: cada propuesta se evalúa en dos ejes independientes, impacto y esfuerzo, y de ahí sale la prioridad.
Impacto se mide en tres números concretos
- Horas liberadas por semana. Si nadie ha cronometrado la tarea manual, no se puede evaluar el proyecto — punto de partida obligatorio.
- Costo del error humano: dinero perdido por digitación equivocada, datos mal cruzados o registros duplicados.
- Impacto en la velocidad de entrega del servicio o de atención al cliente.
Esfuerzo depende de tres cosas
- Si el sistema tiene una API documentada o hay que hacer scraping sobre software heredado.
- Si los datos de entrada llegan limpios (JSON, SQL) o hay que interpretar correos y PDFs desordenados.
- Si las reglas del proceso llevan un año estables o cambian cada trimestre.
Alto impacto, bajo esfuerzo. Procesos estables, datos limpios, menos de dos semanas de desarrollo. Generan el ROI que justifica el presupuesto técnico frente a finanzas.
Alto impacto, alto esfuerzo. Como conectar el sistema de producción con el contable. Se abordan una a la vez, planificadas.
Bajo impacto, alto esfuerzo. Flujos hipercomplejos para satisfacer un capricho de un área específica.
Bajo impacto, bajo esfuerzo. Un script que ahorra quince minutos al mes casi nunca justifica la distracción del equipo.
Tres reglas para cuando el equipo está al límite
Automatiza el caso feliz, delega la excepción
El 80% del tiempo de desarrollo se va en programar el 5% de casos raros. Si 95 de cada 100 transacciones siguen un flujo estándar, automatiza esas 95 y que el sistema mande el resto a un humano con una alerta. Cubrir la norma es barato; cubrir la anomalía casi nunca lo es.
No-code para prototipar, código propio para escalar
Las plataformas visuales sirven para validar la lógica de un flujo en una tarde. Pero si ese flujo va a procesar miles de transacciones al mes, el costo de licenciamiento por volumen suele superar al de construir la infraestructura propia. Herramientas visuales para flujos de bajo volumen, código propio para lo que sostiene el negocio.
Sin diagrama de flujo, no hay proyecto
Si el área que pide la automatización no entrega un flujo documentado (BPMN u otro formato claro) con las reglas de decisión por escrito, el proyecto no entra a la cola. No es burocracia — es evitar que un desarrollador pase dos semanas adivinando cómo funciona un proceso que nadie describió bien.
Dónde falla este método
La matriz no resuelve todo. Necesita datos de tiempo confiables — si nadie ha medido cuánto tarda realmente una tarea manual, los números de "impacto" son estimaciones optimistas, y la matriz hereda ese sesgo. En equipos muy pequeños, con dos o tres personas de TI, formalizar este proceso puede ser más esfuerzo que el que ahorra: ahí basta con una lista priorizada a ojo, revisada cada mes.
Tampoco reemplaza el criterio humano en casos límite. Un proyecto de impacto medio pero que resuelve un riesgo regulatorio, por ejemplo, puede merecer prioridad aunque el número no lo justifique. La matriz da un piso objetivo para la conversación, no un veredicto automático.
El éxito de una estrategia de automatización no se mide por la cantidad de procesos automatizados, sino por el valor que cada uno aporta al negocio. Antes de iniciar un nuevo proyecto, la pregunta no debería ser "¿podemos automatizarlo?", sino "¿vale la pena automatizarlo ahora?". Esa diferencia es la que separa a las organizaciones que invierten en tecnología de las que realmente obtienen retorno de ella.
Comentarios
Publicar un comentario