Mapeo de Dolores: el punto de partida de la estrategia con IA
Antes de cualquier herramienta de IA, hay una pregunta que casi nadie responde bien: ¿dónde duele de verdad, y cuánto cuesta eso? Esta lección enseña el workshop de mapeo de dolores, en tres bloques, con métrica de resultado en cuatro categorías, para que abras la ruta de Estrategia con dato, no con suposición.
Te sientas a hacer tu mapeo de dolores y la primera idea que se te ocurre es "quiero un dashboard". Detente. Antes de cualquier solución, la pregunta correcta es otra: ¿qué actividad te consume demasiado tiempo, con qué frecuencia, y cuánto costaría medir esa mejora dentro de seis meses? Ahí es donde empieza de verdad el mapeo.
Listas rapidito tres dolores de RRHH en una reunión de planeación: "proceso lento", "mucha cosa manual", "la gente se queja". Ninguno tiene número, y por eso ninguno se vuelve prioridad cuando se disputa el presupuesto. El mapeo de verdad pide otra cosa: qué proceso exactamente, cuántas horas consume por ciclo de contratación, con qué frecuencia se repite, y qué pasaría si cortaras ese tiempo a la mitad. Solo después de ese número el dolor se vuelve algo defendible en una reunión, ya no un desahogo de pasillo.
Escribes "priorización confusa" como dolor del producto y ya quieres saltar directo a la solución: "necesito una IA que priorice por mí". Frena esa idea un instante. Primero mide: cuántas horas gasta el equipo en reunión decidiendo qué entra en el próximo sprint, y con qué frecuencia esa decisión cambia de opinión a mitad de camino, obligando a rediseñar todo el board. Sin ese número, cambias un dolor real por una herramienta bonita que tal vez ni resuelva lo que realmente traba.
Señalas "pierdo muchos leads" como dolor comercial, sin ningún número detrás. El mapeo pide el dato: cuántos leads se enfrían por semana esperando respuesta en el CRM, y cuánto costó eso, en oportunidad perdida, en facturación del último trimestre. Solo con ese número en la mano el problema sale de la charla de pasillo y entra a la agenda que decide el board.
Escribes "el SLA se rompe todo el tiempo" en el tablero y ya pasas a la siguiente línea, sin detallar nada. Pero el mapeo de dolores exige el número detrás de la frase: con qué frecuencia se rompe el SLA por mes, cuántas horas gasta el equipo apagando incendios después de cada incumplimiento, y cuál es el costo real de eso en retrabajo o multa contractual. Sin ese dato, "se rompe todo el tiempo" es desahogo, no prioridad.
Anotas "la auditoría es sufrida" y sigues adelante sin detallar. El mapeo correcto pregunta: cuántos controles revisas manualmente por ciclo, cuánto tiempo te consume eso al mes, y qué riesgo queda sin cobertura hoy simplemente porque no sobra tiempo para revisarlo todo. Es ese riesgo descubierto, nombrado y medido lo que justifica invertir en automatizar la revisión.
Escribes "mucho código repetitivo" y ya piensas directo en herramienta nueva. Antes de eso, el mapeo pide el número: cuántas horas por sprint se van en ese tipo de tarea mecánica, y cuál es la tasa de retrabajo cuando alguien se equivoca a mano en ese tramo de código. Solo con ese número queda claro si vale la pena automatizar o si el tiempo perdido ni era tan grande como parecía desde la silla.
Anotas "la investigación tarda mucho en volverse insight" sin detallar nada más. El mapeo exige: cuántas horas toma hoy desde la entrevista hasta el informe listo, y cuántas decisiones de diseño quedan paradas mientras tanto esperando que salga ese informe. Es esa fila de decisiones paradas la que muestra el costo real del atraso, no la sensación vaga de que tarda mucho.
Vaya, déjame hacerte una pregunta antes de cualquier conversación sobre herramienta de IA: ¿dónde duele, exactamente, y cuánto cuesta eso? Parece obvio, pero casi nadie responde bien. La respuesta que da la mayoría es vaga: "perdemos tiempo", "es medio manual", "podría ser más rápido". Eso no es un dolor mapeado, es un desahogo. Y un desahogo no se vuelve prioridad, no se vuelve presupuesto, no se vuelve proyecto. Esta lección es el primer paso de la ruta de Estrategia: el workshop que transforma desahogo en dato.
La idea central de esta lección. Antes de elegir dónde entra la IA, mapeas el dolor con precisión: en tres bloques (los tuyos, los de tu área, y el más molesto y operativo), cada uno con una métrica de resultado en una de cuatro categorías, tiempo, costo, calidad o riesgo evitado. Sin número, el dolor no está mapeado, es opinión. Y es ese mapa, con número, el que se vuelve el punto de partida de todo lo que enseña después la ruta de Estrategia.
01Por qué mapear el dolor antes de pensar en la solución
Hay un reflejo casi automático cuando alguien habla de IA: saltar directo a la solución. "Quiero un agente que...", "necesito un dashboard que...", "se podría tener una IA que...". El problema es que solución sin dolor mapeado es apuesta a ciegas. Puedes terminar construyendo algo bonito para un problema que no es, ni de cerca, lo que más duele en tu rutina o en tu área.
Mapear antes de idear resuelve dos problemas de una vez. Primero, te obliga a nombrar el dolor real, no la primera idea de herramienta que se te pasó por la cabeza. Segundo, te da una línea base: si no sabes cuánto tiempo, dinero o riesgo cuesta hoy el dolor, nunca vas a poder probar, después, que la solución funcionó. Sin número al inicio, no hay "antes y después" para mostrar al final.
02Los tres bloques
El mapeo se organiza en tres bloques, cada uno con una pregunta distinta detrás.
Bloque A, los tuyos. Tres dolores de tus propias actividades: lo que consume demasiado tiempo, lo que te frustra con frecuencia, lo que sigues postergando. Empieza por aquí porque es el terreno que mejor conoces, y es donde resulta más fácil ser honesto sobre el número.
Bloque B, los de tu área. Tres dolores de quien trabaja contigo o depende de ti, sin repetir nada de lo que ya entró en el Bloque A. Si el dolor del área es literalmente el mismo dolor personal, busca otro: el objetivo es mapear el problema, no llenar líneas.
Bloque C, el más molesto. Una sola actividad, la más mecánica y operativa que haces hoy, repetitiva, sin ninguna decisión real involucrada. Y la pregunta que la acompaña: ¿por qué todavía existe así como está? A veces la respuesta es "porque nadie se detuvo a cuestionarlo", y eso ya es una señal valiosa.
03Las 4 categorías de métrica
Todo dolor mapeado necesita una métrica de resultado, algo que puedas medir de nuevo dentro de seis meses para probar que mejoró. Solo existen cuatro categorías aceptadas, y eso es a propósito: evita que la métrica se vuelva rodeo.
- Tiempo. Cuántas horas por ciclo (día, semana, mes) consume hoy este dolor, y cuánto podría bajar. Ejemplo de formato: "44 horas por mes reducidas a 12 horas por mes".
- Costo. Cuánto dinero se recupera o deja de perderse por mes, si se resuelve el dolor. Ejemplo de formato: "$X recuperados por mes".
- Calidad o error. La tasa de retrabajo, de error o de queja hoy, y a dónde podría bajar. Ejemplo de formato: "5% de retrabajo bajando a menos del 1%".
- Riesgo evitado. Para dolores de compliance, LGPD, seguridad de la información o regulación. No fuerces la conversión a dinero cuando el riesgo es difuso, mide el riesgo como riesgo mismo. Áreas como jurídico y datos suelen tener más dolores de este tipo que de las otras tres.
Profundiza: los antipatrones que hacen que el mapeo no sirva de nada
Cuatro errores comunes invalidan un mapeo de dolores, incluso cuando parece completo en el papel.
El primero es listar tres dolores en menos de dos minutos, sin ningún detalle. Eso suele ser lo primero que se te viene a la cabeza, no el dolor real. Si te pasó, prueba con otra pregunta: ¿qué día de la semana abres la computadora y piensas "qué fastidio"?
El segundo es derrapar directo hacia la solución, tipo "quería un dashboard" o "necesitaba una IA que...". Anota la idea, pero vuelve: antes de la solución, ¿cuál es el dolor detrás de ella?
El tercero es usar métrica vaga, "más rápido", "más ágil", "mejor". Eso no es métrica, es adjetivo. Exige un número, aunque sea una estimación honesta.
El cuarto es listar un dolor que no tendrías forma de medir de nuevo dentro de seis meses. Si no se puede probar después que mejoró, el dolor no está listo para entrar al mapa, necesita una pregunta más antes.
04Qué viene después de este mapa
Este mapa no es el final, es la puerta de entrada. Con los dolores nombrados y cada uno con su métrica, tienes el material bruto que las próximas lecciones de esta ruta van a usar para decidir dónde la IA de verdad ayuda, qué es solo una automatización simple disfrazada de proyecto de IA, y por dónde empezar cuando varios dolores compiten por tu atención al mismo tiempo. Sin este mapa, cada decisión siguiente se vuelve suposición. Con él, se vuelve lectura de dato.
Hazlo ahora
Toma una hoja, o abre un documento nuevo, y haz tu mapeo de dolores ahora, tu tarea real o cualquier otro contexto real de tu día.
- Bloque A, 3 dolores personales: lista las tres actividades que más te consumen tiempo, te frustran o más postergas. Para cada una, escribe la métrica de resultado (tiempo, costo, calidad o riesgo) que podrías medir de nuevo en seis meses.
- Bloque B, 3 dolores de tu área: misma estructura, sin repetir nada del Bloque A. Piensa en quién depende de tu trabajo y dónde aparece el dolor de esa persona.
- Bloque C, 1 actividad más molesta: la más mecánica, repetitiva y sin decisión que haces hoy. Escribe por qué todavía existe de esa forma.
- Para cada uno de los siete dolores, escribe una primera idea de solución, y sé honesto sobre su naturaleza: ¿es clasificación, generación de texto, cálculo, o automatización de sistema? Y, lo más importante, di en voz alta si esto es realmente un problema de IA generativa, o si es ETL, regla de negocio o automatización simple. Las dos respuestas son válidas, lo que no vale es fingir que es IA cuando no lo es.
Cuando terminas este mapa con número en cada línea, pasas de "perdemos tiempo con esto" a "esto cuesta 20 horas por mes, y se puede medir de nuevo en seis meses". Es ese giro el que abre la ruta de Estrategia.
Practica
1. ¿Por qué el mapeo de dolores pide que nombres y midas el dolor antes de pensar en la solución?
2. ¿Cuál de las siguientes opciones es una métrica de resultado válida, de las cuatro categorías aceptadas en el mapeo?
3. Un dolor de compliance es difícil de convertir a dinero, porque el riesgo es difuso. ¿Qué recomienda el mapeo en ese caso?
Para la pizarra
Sobre el desahogoperdemos tiempo no es un dolor mapeado. El desahogo no se vuelve prioridad, ni presupuesto, ni proyecto.
Sobre el ordennombrar y medir antes de pensar la solución. Sin línea base no existe el antes y después.
Sobre lo que no se fuerzael riesgo difuso de compliance no se vuelve dinero a ojo. Existe una categoría propia de métrica para eso.
Gracias por el feedback. Esto ayuda a afinar la próxima lección.