En una reunión sobre automatización es fácil salir con más ideas que decisiones. Ventas quiere que el CRM se actualice solo; administración propone extraer datos de facturas; operaciones pide avisos para dejar de perseguir solicitudes. Cada propuesta tiene a alguien dispuesto a defenderla. Lo que falta es un criterio compartido para decidir cuál merece empezar.
Una matriz de impacto y esfuerzo puede ayudar, siempre que los números sirvan para discutir los supuestos y no para disfrazar una preferencia. Su valor aparece cuando alguien pregunta por qué una iniciativa tiene tanto impacto o qué trabajo se ha quedado fuera del esfuerzo. Antes de dibujar los cuatro cuadrantes, conviene lograr algo más básico: que todos estén comparando oportunidades con un alcance comprensible.
Que todos comparen el mismo tamaño de problema
“Automatizar finanzas” es demasiado amplio para comparar. “Preparar un borrador de registro a partir de una factura y enviarlo a revisión” tiene una entrada, una salida y un responsable reconocibles. Redacta cada oportunidad con cuatro elementos: problema actual, grupo afectado, cambio propuesto y resultado esperado. Añade volumen aproximado y frecuencia. Así evitas comparar una tarea pequeña con la transformación completa de un departamento.
Recoge también dependencias. Si el sistema de origen no permite acceder a los datos, la oportunidad puede necesitar trabajo previo. Esa condición debe aparecer antes de prometer resultados o reservar una fecha.
Impacto: ¿qué cambiaría para el negocio?
El impacto puede incluir capacidad liberada, reducción de errores, menor tiempo de respuesta o mayor visibilidad. Elige dos o tres dimensiones relevantes para tu empresa y evita sumar beneficios que representan lo mismo. Por ejemplo, si una tarea tarda menos y permite atender más solicitudes, no contabilices automáticamente ambas mejoras como ingresos independientes. Primero comprueba si existe demanda adicional y si otros pasos permiten absorberla.
Utiliza una escala sencilla de uno a cinco, con ejemplos compartidos. Un impacto alto puede significar que la mejora afecta a una limitación importante del servicio. Uno bajo puede indicar una comodidad local con poca repercusión en el resultado completo.
El esfuerzo que no aparece en la demo
El esfuerzo no es solo programar el flujo. Incluye acceso y limpieza de datos, integraciones, pruebas, formación, revisión de permisos y mantenimiento. También cuenta el tiempo que el equipo de negocio debe aportar. Valora la incertidumbre. Una conexión ya utilizada tiene un riesgo diferente de una integración desconocida. Un proceso estable resulta más fácil de automatizar que otro cuyas reglas cambian según quién recibe la solicitud.
Asigna una escala de uno a cinco y explica qué determina cada puntuación. No hace falta una precisión falsa: resulta más útil anotar “pendiente de comprobar acceso al ERP” que esconder esa duda detrás de un número exacto.
Cómo leer los cuatro cuadrantes
Alto impacto y bajo esfuerzo suele ser el mejor lugar para buscar un piloto. Aun así, confirma que la oportunidad es real y que existe un responsable disponible. Alto impacto y alto esfuerzo puede justificar un proyecto estratégico. Conviene dividirlo en etapas para validar las dependencias más inciertas antes de asumir todo el compromiso.
Bajo impacto y bajo esfuerzo puede servir para aprender o mejorar una molestia recurrente, siempre que no desplace un problema más importante. Bajo impacto y alto esfuerzo normalmente debería esperar o replantearse. La matriz orienta prioridades. No sustituye obligaciones de seguridad, calidad o continuidad que deban atenderse aunque su beneficio sea difícil de puntuar.
El piloto ganador que quizá no resuelva nada
Pongamos tres propuestas sobre la mesa de una empresa de servicios imaginaria. Un recordatorio avisaría cuando una solicitud supera su plazo; una segunda automatización extraería datos de documentos para que alguien los revise; la tercera resolvería de principio a fin una decisión comercial compleja. El equipo les asigna, respectivamente, impacto/esfuerzo de 3/1, 4/3 y 5/5. Son valoraciones hipotéticas, útiles para conversar, no resultados medidos.
Los recordatorios parecen ganar como primer piloto. Pero alguien de operaciones hace una observación: «Ya sabemos qué solicitudes van tarde; no tenemos capacidad para atenderlas». Si eso es cierto, el proyecto mejor colocado solo añadirá notificaciones a una cola que nadie puede reducir. La puntuación no estaba mal calculada: estaba valorando una solución para el problema equivocado.
Esa objeción es precisamente el tipo de conversación que interesa provocar. Antes de aprobar cualquiera de las tres, pregunta qué tendría que ser verdad para que produjera el beneficio esperado y qué evidencia falta. Una duda anotada a tiempo vale más que una casilla verde defendida por inercia.
Antes de dar luz verde
Antes de aprobar, verifica cuatro condiciones: responsable de negocio, acceso autorizado a datos, criterio de éxito y forma de tratar excepciones. Si alguna falta, el proyecto todavía no está listo. También pregunta si la acción puede corregirse. Preparar un borrador y enviarlo a revisión permite aprender con consecuencias limitadas. Ejecutar un cambio irreversible requiere controles adicionales y una justificación diferente.
La IA no debe aparecer por obligación. Si una regla sencilla resuelve el caso, úsala. Reserva la interpretación mediante modelos para entradas variables donde aporte una ventaja que pueda evaluarse.
Define un alcance pequeño pero completo. No basta con demostrar que una herramienta extrae un campo; el piloto debe mostrar cómo ese resultado llega al siguiente paso y cómo se corrige si es erróneo. Elige una muestra representativa y registra una línea base. Mide tiempo por caso, errores, intervención humana y tiempo total hasta el resultado. Establece quién revisará esos datos y cuándo decidirá continuar, ajustar o detener.
Incluye costes de operación. Una solución rápida de construir puede resultar incómoda de mantener si depende de cambios manuales continuos o de una persona que no tendrá disponibilidad.
Las preferencias también entran en la matriz
El primero es priorizar la propuesta más llamativa. Una demostración visualmente impresionante puede resolver un problema poco frecuente. El segundo es escuchar solo al departamento con más influencia. Compara efectos sobre el proceso completo.
El tercero es utilizar estimaciones optimistas como si fueran compromisos. Presenta rangos y señala qué falta comprobar. Si desconoces el porcentaje de excepciones, conviértelo en una pregunta del piloto. Actualiza la matriz después de aprender. Una oportunidad puede bajar de prioridad al descubrir datos deficientes o subir cuando otra integración elimina una dependencia. Mantener el orden inicial por orgullo sería desperdiciar información.
La reunión debería terminar con una decisión que se pueda ejecutar: una oportunidad, una persona responsable, un resultado observable y una fecha para revisar lo aprendido. Las demás ideas permanecen en la lista, con sus dudas visibles. Posponer una propuesta porque todavía falta acceso a los datos es una decisión mejor fundada que prometer una fecha y descubrir la dependencia durante el desarrollo.
Para trabajar esas prioridades con DigitalCube, trae ejemplos del trabajo actual y a quienes conocen sus excepciones. Al revisar la matriz unas semanas después, lo interesante será ver qué supuestos se confirmaron y cuáles cambiaron. Que una iniciativa se mueva de cuadrante puede ser una buena noticia: significa que ahora sabes algo que en aquella primera reunión todavía era una apuesta.