Qué es un quick win en un proyecto de IA

El problema: dos años esperando el proyecto grande

Toda empresa que se plantea usar inteligencia artificial en serio tropieza con la misma tentación: pensar que primero hay que ordenar los datos, integrar los sistemas y construir la plataforma correcta, y que solo después de ese trabajo de fondo tiene sentido tocar la IA. Esa lógica no es falsa, pero tiene un costo que casi nadie calcula: mientras el proyecto grande se arma, se cotiza y se aprueba, el dolor operativo diario sigue exactamente igual, y las personas que lo sufren dejan de creer que la inteligencia artificial vaya a cambiar algo alguna vez.

Es lo que le pasó a una empresa de manufactura mediana en México, donde el área de compras llevaba dieciocho meses en la fase de diagnóstico de un programa de transformación con IA que todavía no producía un solo resultado visible para nadie fuera del comité que lo dirigía. Cada mes, dos personas del equipo dedicaban más de un día completo a consolidar a mano las cotizaciones de proveedores que llegaban por correo en formatos distintos, para armar el comparativo que el gerente de compras necesitaba antes de aprobar cada compra grande. Ese trabajo no dependía de ningún proyecto de datos: dependía de que alguien decidiera resolverlo.

Cuando la dirección no ve ningún resultado durante meses, deja de creer en la iniciativa completa, así el proyecto grande esté avanzando bien puertas adentro. El escepticismo no nace de que la IA no funcione: nace de que nadie mostró todavía nada que la dirección pueda tocar, medir y reconocer como propio.

Qué es un quick win en un proyecto de IA

Un quick win no es una versión reducida del proyecto grande de IA, ni una demo para convencer a un comité. Es una categoría de intervención distinta, con su propia lógica de selección, que existe para producir evidencia rápida y comprarle tiempo político al trabajo de fondo que sí necesita más tiempo.

Cada palabra de esa definición filtra candidatos. Mejora chica excluye cualquier iniciativa que necesite un sistema nuevo, un contrato con un proveedor grande o una migración de datos. Semanas excluye cualquier cosa que dependa de que otra área termine un trabajo de meses antes de poder arrancar. Un número que la dirección ya mira excluye los indicadores que hay que inventar o explicar desde cero, porque un número nuevo todavía no convence a nadie. Y compra permiso político es la parte que más se olvida: el quick win no vale por el ahorro que genera en sí mismo, vale por la confianza que construye para lo que viene después.

Los 4 requisitos de un quick win real

No cualquier mejora chica califica como quick win. La mayoría de los que fracasan cumplen uno o dos de estos cuatro requisitos y fallan en los otros, y ese vacío se paga después, cuando el quick win no logra lo único que tenía que lograr: comprar credibilidad.

• Semanas, no trimestres: si la fecha de entrega depende de la disponibilidad de otra área, de una integración nueva o de un ciclo de aprobación largo, ya dejó de ser un quick win y se convirtió en un proyecto mediano con nombre engañoso.
• Un dueño que ya sufre el problema: el quick win tiene que resolver el dolor de alguien identificable que hoy pierde horas o comete errores por esa tarea, no el dolor abstracto de la operación en general. Si nadie puede nombrar a esa persona, el quick win no tiene quién lo defienda cuando algo se atrase.
• Un número que la dirección ya mira: el resultado se reporta en un indicador que ya existe en algún tablero o alguna reunión gerencial, como horas de reproceso, tiempo de respuesta o tasa de error, no en una métrica nueva que hay que explicar antes de poder mostrar el resultado.
• Cero dependencia de un proyecto de datos grande: los datos que hacen falta ya existen hoy, en el estado en que están, aunque estén desordenados. Si el quick win requiere primero limpiar una base, integrar dos sistemas o esperar un proyecto de gobernanza de datos, dejó de ser rápido y se volvió parte del proyecto grande disfrazado de quick win.

Cuando un candidato falla en alguno de los cuatro, la opción no es forzarlo. La opción es dejarlo para el proyecto grande, donde sí tiene sentido invertir el tiempo que de verdad necesita, y buscar otro candidato que sí cumpla los cuatro al mismo tiempo.

Dónde buscar el quick win, no cómo inventarlo

El error más común no es elegir mal entre varias opciones: es no tener ninguna opción real porque nadie miró la operación con la pregunta correcta. Un quick win no se inventa en una sesión de lluvia de ideas; se encuentra mirando dónde la gente ya se queja todos los días.

• Tareas de copiar y pegar entre sistemas que no conversan entre sí, como pasar datos de un correo a una hoja de cálculo o de un sistema a otro sin que exista una integración real.
• Clasificación manual de documentos o solicitudes que llegan en formatos distintos y que hoy alguien ordena a ojo antes de que el proceso real pueda empezar.
• Respuestas repetitivas a las mismas preguntas de clientes o de otras áreas internas, donde la respuesta correcta ya existe pero alguien tiene que redactarla de nuevo cada vez.
• Reportes que se arman a mano cada semana o cada mes juntando información de varias fuentes, cuando el destino final del reporte, el número que la dirección revisa, ya es conocido y estable.
• Revisiones de calidad o de cumplimiento que hoy dependen de que una persona lea todo un lote antes de aprobarlo, cuando el criterio de revisión ya está bien definido y es repetitivo.

Ninguna de estas tareas necesita un proyecto de datos grande para mejorar. Necesita que alguien las mire con la pregunta de dónde se pierden horas en algo que ya se sabe hacer, y ahí casi siempre aparecen dos o tres candidatos reales desde la primera conversación con el equipo que sufre el proceso.

La trampa: quince automatizaciones que nadie mantiene

Acá es donde la mayoría de empresas que sí logran uno o dos quick wins se meten en un problema distinto y más caro: siguen sumando quick wins sin ningún criterio de conjunto, hasta terminar con una colección de automatizaciones sueltas que nadie diseñó para convivir entre sí.

Una empresa de servicios financieros mediana en Perú llegó a este punto en menos de dos años: un asistente que respondía consultas simples sobre un producto, una automatización que extraía datos de contratos para un área, un script que generaba alertas de vencimiento para otra, y una hoja de cálculo con fórmulas complejas que alguien de finanzas llamaba, en broma, la cuarta inteligencia artificial de la empresa. Cada una había nacido como quick win, resolvía un dolor real y en su momento se reportó como éxito frente a la dirección.

El problema apareció cuando la persona que había construido tres de esas automatizaciones cambió de área. Nadie más entendía del todo cómo funcionaban, ni qué pasaba si el formato de un documento de entrada cambiaba, ni quién debía actualizarlas cuando el proceso de negocio alrededor se modificara. La empresa tenía quince automatizaciones sueltas, ningún inventario centralizado de qué hacía cada una, y ningún dueño técnico claro más allá de la persona que las armó por su cuenta y ya no estaba disponible.

La trampa no es tener quick wins. Es tratarlos como si fueran gratis después de implementados. Cada automatización suelta necesita mantenimiento cuando cambia un formato, una regla de negocio o un sistema conectado, y si nadie asumió ese costo desde el principio, la empresa termina pagando en soporte no planeado lo que ahorró en velocidad de implementación. Un quick win que nadie puede explicar seis meses después no compró permiso político para nada: compró una deuda técnica silenciosa que alguien va a tener que pagar, casi siempre en el peor momento.

La forma de evitar esto no es dejar de perseguir quick wins. Es elegirlos mirando el mapa completo de la operación desde el principio, no al azar según qué área grita más fuerte esa semana, de modo que cada quick win nuevo se sume a los anteriores en vez de competir con ellos por atención y mantenimiento. Cuando eso no se hace a tiempo, el camino de regreso (inventariar lo que ya existe, decidir qué automatización se integra a un sistema real y cuál se apaga) es justo lo que desarrolla la guía sobre cómo migrar de automatizaciones sueltas a un sistema de IA, y es un trabajo bastante más caro que haberlo planeado desde el primer quick win.

Cómo el quick win compra permiso para el proyecto grande

El quick win nunca es el destino. Es la moneda de cambio que permite tener, más adelante, la conversación seria sobre el proyecto de IA que sí requiere presupuesto de varios meses, integración de sistemas y paciencia del directorio. Sin esa moneda, esa conversación no ocurre, sin importar cuán bien armado esté el caso de negocio en una presentación.

Elegir bien el primer quick win, y el segundo y el tercero, requiere haber mirado antes el mapa completo de dónde está la empresa en su relación con la IA, no solo la lista de tareas molestas del mes. La guía sobre cómo hacer un diagnóstico de madurez de IA cubre justamente ese mapeo previo, y la guía sobre cómo elegir el primer caso de uso de IA desarrolla el criterio de selección con más detalle del que cabe aquí. Sin ese mapa, cada quick win se elige de forma aislada, y ahí es donde empieza la colección sin sistema descrita antes.

Un quick win bien elegido también deja pistas sobre qué sigue: si el resultado es sólido y repetible, el siguiente paso razonable suele ser un caso de uso de IA más ambicioso, con su propio piloto, no saltar directo a una implementación total. La diferencia entre un quick win y un caso de uso de IA, y entre este y un piloto de IA, está desarrollada en sus propias entradas del glosario, y conviene no confundirlas: el quick win compra tiempo y confianza, el caso de uso define el problema de negocio a resolver, y el piloto prueba la solución en condiciones reales antes de escalarla.

Lo que realmente convence a una dirección escéptica no es un quick win aislado, por bueno que sea, sino ver que la empresa logra sostenerlo en el tiempo sin que nadie tenga que estar empujándolo. Eso ya no es un tema de implementación, es un tema de adopción de IA, y es la señal real de que el permiso político para el proyecto grande se ganó de verdad, no solo se prestó por un trimestre.

Mi criterio

Cuándo sí y cuándo no perseguir un quick win

No todo dolor operativo es candidato a quick win, y no toda empresa está lista para perseguir uno todavía. Estas son las señales que de verdad separan un buen candidato de uno que solo lo parece.

Señales de que sí tienes un buen candidato a quick win

• Puedes nombrar a la persona exacta que hoy pierde horas o comete errores por esta tarea, y esa persona está dispuesta a probar algo nuevo.
• El resultado se puede medir con un número que ya existe en algún reporte o tablero gerencial, sin tener que inventar ni explicar una métrica nueva.
• Los datos que hacen falta ya existen hoy, en el estado en que están, aunque haya que ordenarlos un poco antes de usarlos.
• El alcance cabe en un equipo pequeño y en semanas, sin depender de la aprobación ni del calendario de otra área de la empresa.
• Ya tienes uno o dos quick wins anteriores mapeados, y este nuevo candidato encaja con ellos en vez de competir por el mismo dueño o el mismo sistema.

Señales de que no es un quick win, es otra cosa

• La tarea requiere integrar dos sistemas que hoy no se hablan entre sí; eso ya es un proyecto de infraestructura, no una mejora chica.
• Nadie puede decir qué número de negocio se movería con el cambio; sin eso, el resultado no se puede defender frente a la dirección después.
• El plan incluye primero limpiamos la base de datos como paso uno; ese primer paso ya es el proyecto grande entrando por la puerta de atrás.
• El dueño propuesto del problema no es la persona que lo sufre a diario, sino un gerente que lo delega sin involucrarse en la solución.
• La fecha de entrega depende de un proveedor externo con tiempos de contrato largos; eso cambia la naturaleza del esfuerzo, así el resultado final sea simple.

El único trabajo real de un quick win

El quick win bien elegido respeta el mismo orden que cualquier decisión seria de IA, solo que comprimido en semanas: arranca en un dolor operativo real y nombrado, se apoya en un proceso que ya existe y que se puede ajustar sin rediseñar toda el área, usa los datos tal como están hoy en la empresa, y llega a la herramienta al final, como la pieza más pequeña de la ecuación, no como el punto de partida. Cuando una empresa invierte ese orden y sale a buscar dónde meter una herramienta de IA que ya decidió comprar, lo que produce no es un quick win: es una automatización sin dueño esperando a sumarse a la colección que nadie va a mantener.

Un buen quick win no se recuerda por el ahorro que generó ese trimestre. Se recuerda porque, meses después, es la razón por la que la dirección aceptó financiar el proyecto que de verdad iba a cambiar cómo opera la empresa. Ese es su único trabajo real, y es también la medida más honesta de si valió la pena hacerlo.