Cómo hacer un diagnóstico de madurez en IA: guía paso a paso

Por qué el diagnóstico genérico no sirve

Casi toda empresa que decide invertir en IA hace lo mismo antes: baja un cuestionario de 40 preguntas de alguna consultora, lo llena en una reunión de dos horas con el comité gerencial y lo archiva. El resultado es un PDF con un puntaje general (“madurez media-baja”) que no le dice a nadie qué hacer el lunes. Eso no es un diagnóstico, es un ejercicio de relaciones públicas internas.

El problema no es hacer preguntas sobre IA. Es hacerlas mal: sin entrevistar a quien ejecuta el proceso todos los días, sin evidencia concreta detrás de cada puntaje y sin conectar el resultado a una lista de casos de uso priorizada. Un diagnóstico que termina en un documento descriptivo y no en una decisión no vale el tiempo que tomó hacerlo.

Esta guía no explica por qué hacer un diagnóstico, eso se asume resuelto. Explica cómo ejecutarlo esta semana: con qué dimensiones, con qué preguntas y cómo convertirlo en algo que el negocio pueda usar el día después de terminarlo.

Qué es este diagnóstico (y qué no)

No es una auditoría de sistemas de información. No es un test de madurez digital genérico que sirve igual para un banco que para un taller mecánico. Es una evaluación de seis dimensiones específicas del negocio, hecha con entrevistas reales, que termina en una lista de candidatos a caso de uso ordenada por evidencia, no por intuición del gerente.

• Un formulario enviado por correo para que cada jefe de área lo llene solo.
• Una comparación contra “el promedio de la industria” sacada de un reporte genérico.
• Un ranking de madurez para mostrar en una presentación de directorio sin acción detrás.
• Un proyecto de tres meses con consultores externos: esto se ejecuta en una semana con gente de la casa.

Las seis dimensiones que se evalúan

No se diagnostica “la empresa” en abstracto. Se diagnostican seis dimensiones concretas, cada una con su propia evidencia. Si una guía de diagnóstico no nombra estas seis, es genérica y no sirve.

• Procesos mapeados o no. Si el proceso que te interesa transformar existe solo en la cabeza de dos personas, o está documentado con entradas, salidas y dueño claro.
• Calidad y accesibilidad de los datos. Dónde vive la información que un sistema necesitaría para decidir, si está limpia y centralizada o repartida entre Excel, WhatsApp y la memoria de alguien.
• Herramientas actuales. Qué CRM, ERP o automatizaciones sueltas ya existen, y si hablan entre sí o son islas que nadie conectó.
• Capacidad técnica del equipo. Quién dentro de la empresa podría sostener un sistema de IA sin depender al cien por ciento de un proveedor externo.
• Cultura de adopción. Si el equipo prueba herramientas nuevas o las rechaza por costumbre, y qué pasó la última vez que se metió tecnología nueva.
• Gobierno de datos. Quién decide qué información se usa, quién responde por un error del sistema, y qué reglas de acceso y privacidad existen hoy, aunque sea de forma informal.

El paso a paso: cómo ejecutarlo en una semana

Este orden funciona en empresas de 20 personas y en empresas de 500. Lo que cambia es cuántas áreas se entrevistan, no la secuencia.

Día 1: preparar el terreno

• Elige de 3 a 5 áreas para auditar, no toda la empresa a la vez. Empieza por las que más se quejan o las que manejan más volumen.
• Nombra a un responsable del diagnóstico con autoridad para pedir tiempo de las otras áreas, aunque sea alguien de medio tiempo en esto.
• Ajusta las seis dimensiones al lenguaje del negocio: “datos” en una constructora no se pregunta igual que en una fintech.
• Avisa a los jefes de área con anticipación qué se va a preguntar y para qué. Un diagnóstico sorpresa genera respuestas defensivas, no honestas.

Día 2 y 3: entrevistas por área

Aquí se rompe la mayoría de los diagnósticos: se convierten en un cuestionario que alguien llena solo, sin conversación. La entrevista tiene que ser de 30 a 40 minutos, uno a uno o en grupos pequeños, con preguntas ancladas en tareas reales, no en tecnología.

• “Camina conmigo el último caso que atendiste de principio a fin”: revela si el proceso está mapeado o vive improvisado.
• “¿Dónde buscas la información para decidir esto, y cuánto tardas en encontrarla?”: revela el estado real de los datos.
• “¿Qué herramienta usas hoy para esto, y qué tan seguido falla o te obliga a salir de ella?”: revela el estado de las herramientas.
• “La última vez que la empresa metió un sistema nuevo, ¿qué pasó?”: revela la cultura de adopción sin preguntarla directamente.
• “Si esto sale mal, ¿quién se entera y qué pasa después?”: revela el gobierno real, no el que dice el organigrama.

Toma notas textuales de las respuestas, no interpretaciones en el momento. Interpretar mientras se entrevista contamina el diagnóstico con lo que el entrevistador esperaba escuchar.

Día 4: puntuar con evidencia

Se puntúa cada dimensión por área con la evidencia recogida en las entrevistas, no con la impresión general que quedó de la reunión. La escala y el criterio están en la siguiente sección.

Día 5: priorizar casos de uso

• Cruza el puntaje de cada dimensión con el dolor nombrado en las entrevistas: un área con datos débiles y dolor bajo no es prioridad, aunque grite fuerte.
• Construye una lista de 3 a 5 candidatos a caso de uso, cada uno con: dolor identificado, dimensión más débil que lo bloquea y dimensión más fuerte que lo habilita.
• Ordena la lista por dolor real cruzado con viabilidad, no por lo que más entusiasma al gerente general.
• Entrega el resultado en una reunión con el dueño del negocio, no en un documento que circula por correo sin discusión.

Cómo puntuar cada dimensión sin inventar un número

La parte donde casi todos los diagnósticos se vuelven blandos es la puntuación. Si el resultado es “regular”, “bueno” o “necesita mejorar”, no sirve: es una opinión con forma de dato. Usa una escala de 1 a 4, definida antes de entrevistar a nadie, con un criterio explícito por nivel.

• 1, no existe. No hay evidencia de que la dimensión se haya trabajado ni intentado.
• 2, informal. Existe, pero vive en la cabeza de una persona y no está documentada ni es consistente entre áreas.
• 3, parcial. Está documentado o centralizado en parte, pero distintas áreas lo hacen distinto y nadie lo audita.
• 4, sólido. Está documentado, centralizado, tiene un dueño claro y se revisa con alguna periodicidad.

La regla que evita el sesgo: por cada puntaje que asignes, escribe al lado la frase textual de la entrevista que lo justifica. Si no puedes citar la frase, no pongas el número: vuelve a la entrevista o baja el puntaje a lo que sí puedes sostener con evidencia.

Errores comunes al hacer este diagnóstico

• Usar un cuestionario genérico bajado de internet sin adaptarlo al negocio real: las seis dimensiones son fijas, pero las preguntas deben hablar el idioma de esa empresa.
• Entrevistar solo a gerencia y nunca a quien ejecuta el proceso día a día: el gerente cree que el proceso está mapeado, la persona que lo ejecuta sabe que no.
• Puntuar todas las áreas igual, con el mismo criterio blando, para no incomodar a nadie: un diagnóstico que no distingue fortalezas de debilidades no prioriza nada.
• Convertir el resultado en un documento de cuarenta páginas que nadie vuelve a abrir después de la reunión de cierre.
• Diagnosticar y no priorizar: entregar seis puntajes por área sin traducirlos en una lista de casos de uso ordenada.

Cómo se ve en la práctica

Una empresa de manufactura mediana, en Perú, alrededor de 150 personas. El gerente general llegó convencido de que el primer proyecto de IA tenía que ser en planta: “quiero IA en producción”. El diagnóstico se ejecutó en una semana, con cuatro áreas entrevistadas: producción, compras, ventas y administración.

El resultado no confirmó la intuición del gerente. Producción puntuó bajo en datos (la información vivía en las máquinas, sin exportar) y bajo en procesos (nadie los tenía mapeados fuera de la experiencia de dos operarios). Ventas, en cambio, tenía un CRM decente, pero nadie lo llenaba bien por falta de un hábito simple, no por falta de tecnología. La cultura de adopción general puntuó baja porque dos años antes un ERP se había implementado mal y el equipo seguía desconfiando.

La lista priorizada no fue “IA en planta”. Fue ordenar el proceso de reporte de ventas primero, porque tenía datos aprovechables y un dolor real y medible (pedidos que se perdían por seguimiento tardío), y dejar producción para una segunda fase, después de instrumentar sensores básicos que todavía no existían.

Mi criterio

Cómo saber si el diagnóstico fue bien ejecutado

El diagnóstico en sí se puede evaluar con la misma disciplina que le pides al proyecto que viene después.

• Cada dimensión tiene un puntaje con una frase de evidencia citada al lado, no una opinión general.
• Se entrevistó a quien ejecuta el proceso todos los días, no solo a quien lo supervisa desde arriba.
• El resultado final es una lista de 3 a 5 casos de uso candidatos, ordenada, no un documento descriptivo de seis páginas por dimensión.
• El dueño del negocio puede explicar en menos de dos minutos por qué el candidato número uno va antes que el número dos.
• Todo el ejercicio (entrevistas, puntuación, priorización) tomó una semana; no se volvió un proyecto de tres meses con consultores externos.

Si el diagnóstico cumple esto, ya se puede pasar al siguiente paso: elegir el primer caso de uso y escribir qué se espera de él antes de tocar ninguna herramienta.