Decidir que automatizar primero con IA es la decisión que separa una operación que escala de una atascada en pilotos eternos. La mayoría de empresas medianas eligen mal. Arrancan por la tarea más visible, más dolorosa o más comentada en LinkedIn. Y fallan. Este artículo explica los 4 criterios que aplicamos en DelegIA para priorizar procesos antes de tocar ninguna herramienta, la matriz impacto contra esfuerzo que usamos como filtro y cómo llevarla a una distribuidora industrial de 40 personas sin parar la operativa de la semana.
Por qué empezar por la tarea más visible casi siempre falla#
El primer instinto del COO es atacar el dolor más alto. La factura que cada mes consume tres horas de revisión manual. El email de bienvenida que el equipo comercial reescribe veinte veces. La tarea visible es la que duele, y por eso se vuelve la primera candidata. Aquí aparece el sesgo: visibilidad e impacto no son lo mismo.
Más del 80% de los proyectos de IA fallan, el doble de la tasa de fallo de proyectos IT sin IA, según el estudio de RAND sobre las causas raíz del fallo en proyectos de IA. La causa principal no es técnica. Es que el equipo eligió el proceso equivocado. Atacaron una tarea que parecía simple pero exigía criterio que nadie había codificado. O al revés: automatizaron un proceso frágil que cambia cada trimestre, y el sistema quedó obsoleto antes de pagarse.
Si quieres ver cómo este patrón se cristaliza en empresas de 15 a 50 personas, conviene leer antes el muro operativo que aparece al pasar de 1M a 5M EUR. Aquel artículo describe el síntoma. Este describe el filtro. La diferencia entre instalar infraestructura con IA dentro de operaciones y montar otra automatización suelta empieza aquí, en qué proceso eliges primero. En el patrón que instalamos en DelegIA dentro de empresas 7-8 cifras, esa decisión la dirige operaciones, no el equipo técnico: aplicamos el filtro de cuatro criterios y la matriz que vienen a continuación, en ese orden.
Los 4 criterios para priorizar qué automatizar primero con IA#
Cada proceso candidato pasa por un test de cuatro filtros. Si falla en uno, baja a la cola. Si los pasa los cuatro, sube a la matriz del siguiente apartado. Los criterios están ordenados de más excluyente a menos.
1. Volumen efectivo, no percibido
El primer filtro es cuantitativo. ¿Cuántas veces a la semana se ejecuta el proceso? Si la respuesta es menos de diez, el coste de instalar un agente o un flujo nunca se amortiza. La intuición del fundador o la directora de operaciones ("esto pasa todo el rato") tiende a inflar el volumen. Lo correcto es medir. Revisar dos semanas el calendario del equipo y contar repeticiones efectivas. Si después de medir el volumen sigue siendo bajo, la respuesta es no automatizar todavía, no tocarlo. Liberar a una persona de una tarea que ocurre tres veces al mes no compensa el ciclo de instalación.
2. Variabilidad baja entre ejecuciones
El segundo filtro es estructural. Un proceso con mucha variabilidad por instancia (cada cliente exige cosas distintas, cada caso aplica reglas distintas) es mal candidato. La IA puede manejar variabilidad si el criterio está codificado, pero el coste de codificarlo cuando hay 47 ramas posibles supera el ahorro generado. La regla es directa: si describir el proceso en una página obliga a llenar la página de "depende", el proceso aún no está listo. Hay que estabilizarlo a mano antes de pasarlo al sistema.
3. Criterio codificable y dueño operativo identificable
El tercer filtro es político. ¿Existe alguien en la empresa que sepa exactamente cómo se decide en este proceso, y puede sentarse dos horas a explicarlo? Si la respuesta es no, ese proceso aún no se puede automatizar bien. Si la respuesta es sí, ese alguien tiene que ser el dueño operativo del piloto, no el fundador. Cuando la dirección de operaciones lidera la implementación y el operador del proceso aporta criterio, el agente queda anclado a la realidad del trabajo, no a una versión idealizada.
4. Calidad de datos suficiente
El cuarto filtro es técnico. ¿La información que el proceso necesita está accesible, ordenada y actualizada? Si los datos viven en cuatro hojas de cálculo distintas con nombres inconsistentes, automatizar el proceso es construir sobre arena. La preparación de datos suele consumir más tiempo que la instalación del agente. Si el proceso candidato no tiene los datos en orden, la primera tarea no es la automatización: es ordenar los datos. Esto coincide con uno de los hallazgos clave de la arquitectura por capas que sostiene la IA empresarial, donde la capa de datos es la base sobre la que descansan las otras tres.
Aplica los cuatro filtros sobre cada candidato. Si menos de tres procesos pasan, el problema no es elegir cuál primero: es que la operativa todavía no está lista para automatizar nada. Y eso, en sí, ya es información accionable.
La matriz impacto contra esfuerzo aplicada a tu operativa#
Los procesos que pasan los cuatro criterios entran en una matriz de dos ejes: impacto operativo en el eje vertical y esfuerzo de instalación en el horizontal. Cada cuadrante tiene una decisión asociada.
| Cuadrante | Impacto | Esfuerzo | Decisión |
|---|---|---|---|
| Quick wins | Alto | Bajo | Empezar aquí. Estos son los primeros 2 o 3 pilotos. |
| Apuestas estructurales | Alto | Alto | Después de los quick wins. Requieren rediseño de proceso. |
| Pequeñas mejoras | Bajo | Bajo | Solo si quedan recursos. No prioritarias. |
| Trampas | Bajo | Alto | Nunca. Aquí mueren los proyectos de IA. |
El cuadrante "trampas" es el que más tiempo consume en empresas medianas. Suelen ser proyectos de gran visibilidad interna (un dashboard que pidió el director financiero, una integración que reclama el comercial estrella) que prometen poco y cuestan mucho. La matriz los excluye sin debate.
Un caso documentado. Una distribuidora industrial de 40 personas, con cuatro líneas de producto y unos 200 pedidos a la semana. Tras aplicar los cuatro criterios, salen siete procesos candidatos. Tras pasarlos por la matriz, dos quedan en quick wins (clasificación automática de pedidos entrantes y generación de proformas), uno en apuesta estructural (forecast de stock por línea), tres en mejoras pequeñas y uno en trampa (un dashboard ejecutivo que el director financiero pidió para "tener visión"). El plan empieza por los dos quick wins, porque demuestran resultado en tres semanas y financian internamente la apuesta estructural posterior. La trampa nunca se ejecuta.
La capa de criterio es la que hoy se rompe en la mayoría de empresas medianas, porque nadie ha sentado al operador a explicar en voz alta cómo decide. Resolverla no es encargar el problema a una agencia externa, ni añadir otra automatización aislada al stack, ni probar otro GPT genérico. Es instalar la arquitectura por capas que ejecuta los procesos repetidos con el criterio del fundador codificado dentro del sistema, operando con la voz operativa de la empresa.
Esta lógica es la que aplicamos cuando una empresa entra en nuestro framework de instalación de IA en operativa. Sin matriz, los proyectos colapsan en los cuadrantes equivocados. Con matriz, el orden es defensible delante del comité de dirección.
Cómo se ejecuta el primer piloto sin parar la operativa#
Una vez decidido el proceso, la ejecución sigue tres pasos cortos. La velocidad no importa: importa no romper lo que ya funciona mientras se construye lo nuevo.
Paso 1: mapeo del proceso actual con el dueño operativo. Dos sesiones de noventa minutos. El operador describe paso a paso. La dirección de operaciones observa y anota los puntos donde el operador "decide a ojo". Esos puntos son los que la IA tiene que codificar después. El mapa final cabe en una página A4 o no es un mapa.
Paso 2: piloto sobre el 20% del volumen. No se automatiza el proceso entero al principio. Se monta el agente, se le da el 20% del volumen (un día a la semana, una línea de producto, un canal de entrada) y se mide durante dos semanas. La métrica clave es tasa de revisión humana: cuánto del output exige corrección. Por debajo del 10%, el agente está listo para escalar. Por encima del 30%, hay que volver al paso 1 y refinar el criterio.
Paso 3: escalado progresivo y monitorización. Subir del 20% al 100% en cuatro semanas, midiendo la tasa de revisión en cada salto. La supervisión humana no desaparece nunca. Cambia de forma. Pasa de revisar todo a revisar solo los casos atípicos que el sistema marca como dudosos. El operador deja de ejecutar y empieza a auditar.
El coordinador central de IA dentro de la empresa es quien orquesta este flujo. No es un agente más. Es la capa que decide a qué agente delegar cada caso, revisa el output y reporta a operaciones. En el patrón que hemos observado en empresas 7-8 cifras, sin esa capa los pilotos quedan aislados y se reabandonan en seis meses.
El 88% de las empresas usa IA en al menos una función, pero solo el 6% reporta impacto medible sobre el EBIT, según The state of AI 2025 de McKinsey. La diferencia entre el 88% que usa y el 6% que captura valor está aquí: el 6% rediseña el proceso antes de automatizarlo. El resto pone IA encima del proceso roto y se sorprende de que no funcione.
Errores frecuentes al elegir qué automatizar primero#
El primer error es delegar la decisión al equipo técnico. El equipo técnico optimiza por viabilidad, no por impacto operativo. Acabas con un agente perfecto resolviendo un problema irrelevante. La decisión de priorización la toma operaciones, con el fundador en segundo plano y el equipo técnico como ejecutor.
El segundo error es elegir muchos procesos a la vez. Empezar con cinco pilotos en paralelo divide el ancho de banda del equipo y ninguno llega a régimen autónomo. La regla es uno o dos pilotos en marcha, nunca tres. El 28% de los casos de IA en operaciones cumple las expectativas de ROI y el 20% falla por completo, según un análisis de Gartner sobre proyectos de IA en infraestructura y operaciones. La distancia entre el 28% y el 20% suele ser foco operativo, no calidad del modelo.
El tercer error es saltarse el paso 1 del mapeo. Asumir que el SOP escrito refleja el proceso ejecutado. Según los casos que hemos instalado, casi nunca lo hace. El SOP describe lo que se debería hacer; el operador hace cosas que ni el SOP recoge ni el fundador conoce. Cuando se automatiza el SOP escrito en lugar del proceso ejecutado, el agente falla en los casos atípicos que ocurren cada semana. Esto se ve literal en el caso de onboarding de clientes en una agencia B2B, donde la primera versión del agente falló dos semanas hasta que el operador codificó el contexto operativo que nadie había documentado.
El cuarto error es no cerrar el bucle de medición. Si después de tres meses no puedes responder con datos a "cuánto tiempo nos ha ahorrado este agente", el piloto no ha sido un piloto: ha sido un experimento sin termómetro. La medición se decide antes de instalar nada, no después.
Si la operativa lleva meses con pilotos sueltos que no escalan, el siguiente paso no es encargar el problema a una consultora externa, ni añadir otro dashboard al stack, ni probar otro SaaS genérico. Lo que instalamos en su lugar es una arquitectura por capas que codifica el criterio operativo, ejecuta los procesos repetidos y reporta a dirección con métricas auditables. ## Lo que entregamos cuando una empresa nos pide ayuda a priorizar
La priorización no es un workshop ni un Excel con valoraciones de 1 a 5. Es un trabajo operativo que cruza tres fuentes: la matriz impacto-esfuerzo aplicada a cada proceso candidato, el inventario real de lo que ya está documentado como SOP, y el coste de oportunidad concreto del fundador en cada uno (cuántas horas suyas absorbe semanalmente).
En el formato que entregamos, la priorización deja un orden ejecutable: el primer proceso entra en arquitectura las primeras tres semanas; el segundo se calibra antes de tocarse; el tercero queda en backlog hasta validar el primero en producción. Sin lista de cinco pilotos en paralelo. Sin agente "perfecto" resolviendo un problema irrelevante. Lo que sale es un plan que opera, no una matriz que se imprime.