Cuando una empresa decide empezar a automatizar procesos con IA, el primer problema no es técnico: es decidir por dónde empezar. La mayoría tiene más candidatos que capacidad de ejecución, y elegir mal el primer proceso puede generar desconfianza en toda la iniciativa.
Este artículo presenta el marco de priorización que usamos en LichiroLabs para evaluar procesos candidatos, ordenarlos por viabilidad e impacto, y decidir cuál va primero.
Por qué la elección del primer proceso es crítica
El primer proyecto de automatización con IA en una empresa no es solo un proyecto técnico: es un cambio cultural. Si el primer proyecto fracasa (o tarda demasiado en mostrar resultados), las siguientes iniciativas de automatización enfrentarán resistencia interna. Si tiene éxito, genera el capital político y la confianza necesarios para escalar.
Por eso el criterio de selección del primer proceso no es solo «dónde está el mayor ahorro potencial», sino «dónde puedo mostrar resultados reales en el menor tiempo posible con el menor riesgo».
Los cuatro criterios del marco de priorización
El marco usa cuatro criterios que se evalúan de forma independiente para cada proceso candidato. Cada criterio se puntúa de 1 a 3.
Criterio 1 — Frecuencia
¿Con qué regularidad ocurre el proceso y cuánto tiempo consume en total?
| Puntuación | Descripción | |---|---| | 3 | El proceso ocurre varias veces al día o consume más de 10 horas semanales | | 2 | El proceso ocurre diariamente o consume entre 4 y 10 horas semanales | | 1 | El proceso ocurre semanalmente o consume menos de 4 horas semanales |
Un proceso de baja frecuencia puede tener alto coste unitario (por ejemplo, revisar manualmente un contrato complejo una vez al mes), pero si el tiempo total es bajo, el retorno de la automatización raramente justifica el coste de construcción. La frecuencia mide el volumen de trabajo que puedes liberar.
Criterio 2 — Claridad de las reglas
¿Pueden describirse con precisión las decisiones que toma el proceso?
| Puntuación | Descripción | |---|---| | 3 | Las reglas son explícitas, están documentadas y no varían según quien las aplica | | 2 | Las reglas existen pero no están documentadas; hay variación entre personas | | 1 | Las decisiones son implícitas o dependen de juicio experto difícil de articular |
Este criterio mide la facilidad de formalizar el conocimiento necesario para que el sistema tome las mismas decisiones que un humano bien entrenado. Un proceso con reglas implícitas no es imposible de automatizar, pero requiere una fase de extracción de conocimiento más larga y el riesgo de capturar el conocimiento de forma incompleta es mayor.
Si la persona que hace el proceso no puede describir cómo decide, el proceso no está listo para automatizarse. La primera tarea es documentar las reglas, no automatizarlas.
Criterio 3 — Coste de error
¿Qué ocurre cuando el sistema se equivoca?
| Puntuación | Descripción | |---|---| | 3 | El error es detectable y corregible antes de que tenga consecuencias externas | | 2 | El error puede tener consecuencias, pero existe un proceso de revisión que las mitiga | | 1 | El error tiene consecuencias graves, irreversibles o de impacto regulatorio |
Este criterio es el más importante para el primer proyecto. Un sistema de automatización en sus primeras semanas de producción cometerá errores; la clave es que esos errores sean recuperables. Los procesos con alto coste de error no son imposibles de automatizar, pero requieren capas adicionales de supervisión y validación que incrementan el coste y la complejidad del proyecto.
Criterio 4 — Dato disponible
¿Existen datos accesibles y de calidad suficiente para entrenar o configurar el sistema?
| Puntuación | Descripción | |---|---| | 3 | Los datos están en un sistema accesible, son suficientes y tienen la calidad necesaria | | 2 | Los datos existen pero requieren trabajo de limpieza, extracción o etiquetado | | 1 | Los datos no existen, están fragmentados o tienen restricciones de privacidad que los hacen inutilizables |
Para automatizaciones basadas en modelos de lenguaje de propósito general, el requisito de datos propios puede ser bajo: el modelo ya tiene capacidades generales y solo necesitas ejemplos de cómo comportarse en tu contexto. Para modelos supervisados entrenados con datos propios, la disponibilidad de datos de calidad es el cuello de botella más frecuente y el que más se subestima en las estimaciones iniciales.
Los requisitos mínimos de datos varían según la tarea, la arquitectura y el modelo elegido; las cifras anteriores son orientativas, no normativas.
La matriz de priorización
Suma los puntuaciones de los cuatro criterios para cada proceso. El máximo es 12 (3×4) y el mínimo es 4 (1×4).
| Puntuación total | Recomendación | |---|---| | 10-12 | Candidato prioritario: empieza aquí | | 7-9 | Candidato válido: segunda o tercera fase | | 4-6 | Posponer: resolver los criterios bajos antes de automatizar |
Cuando varios procesos tienen puntuaciones similares, desempata con el impacto económico del tiempo liberado: multiplica las horas semanales consumidas por el coste promedio por hora del equipo que lo realiza.
Ejemplo de aplicación del marco
Supón que una empresa tiene tres procesos candidatos:
| Proceso | Frecuencia | Reglas claras | Coste de error | Dato disponible | Total | |---|---|---|---|---|---| | Clasificación de emails de soporte | 3 | 3 | 3 | 2 | 11 | | Revisión de contratos de clientes | 2 | 1 | 1 | 1 | 5 | | Generación de informes semanales | 2 | 3 | 2 | 3 | 10 |
La clasificación de emails de soporte puntúa 11: alta frecuencia, reglas conocidas (las categorías de soporte existen), errores recuperables (clasificar mal un email se corrige al revisarlo) y datos históricos disponibles (los tickets anteriores). Es el primer proyecto.
La revisión de contratos puntúa 5: aunque el impacto potencial es alto, las reglas son implícitas y el coste de error es elevado. No es el primero.
La generación de informes puntúa 10: también es un buen candidato, pero la frecuencia semanal (frente a la diaria de los emails) lo convierte en segunda fase.
Errores comunes de priorización
Elegir el proceso más visible, no el más viable. El proceso que más le duele al CEO o al directivo patrocinador puede no ser el mejor candidato técnico. Un proyecto de baja viabilidad bien elegido políticamente puede generar más daño a la iniciativa que un proyecto de alta viabilidad menos llamativo.
Infraestimar el coste de error. «Siempre podemos revisar los resultados» parece un safety net razonable, pero si la revisión consume tanto tiempo como el proceso manual original, la automatización no ha aportado valor real, solo ha cambiado la forma del trabajo.
Subestimar la fase de datos. Es el criterio que más se obvia en las conversaciones iniciales y el que más proyectos paraliza una vez empezados. Si los datos no están disponibles o no tienen la calidad necesaria, saberlo en la evaluación previa ahorra semanas o meses de trabajo.
Intentar automatizar el proceso completo desde el principio. La mayoría de los procesos tienen pasos con distinta viabilidad. Identificar y automatizar primero los pasos más viables genera retorno más rápido y proporciona los datos de comportamiento real que informan las fases siguientes.
Del proceso priorizado a la hoja de ruta
Una vez seleccionado el primer proceso, el siguiente paso es estructurar el proyecto: definir el alcance concreto (qué pasos del proceso se automatizan, cuáles quedan fuera), establecer criterios de aceptación para el piloto y diseñar el plan de despliegue gradual.
La guía completa de cómo ejecutar cada fase está en el artículo cómo automatizar procesos con IA en tu empresa, que cubre desde la auditoría de datos hasta la puesta en producción con supervisión.
Si tienes varios procesos candidatos y quieres una evaluación independiente de cuáles son los más viables para tu empresa, el servicio de consultoría de IA de LichiroLabs incluye un diagnóstico de priorización como primer entregable. Y si ya tienes el proceso elegido y quieres pasar a la construcción, el servicio de automatización con IA cubre el diseño, el piloto y la puesta en producción.