Skip to main content

Someone wanted to learn this too, so Grasp built them a personal learning path.

You can keep exploring this one or create your own

Diagnóstico de las Causas de Baja Adopción

¡Hola! En la lección anterior construiste un panel para el piloto de un agente que clasifica incidencias. El panel muestra dónde cambia el uso, pero no explica por qué. Que alguien no utilice el agente puede deberse a un permiso incompleto, a que apenas recibe incidencias elegibles, a resultados poco fiables o a una rutina de trabajo que no deja espacio para revisarlos. Esas situaciones requieren respuestas distintas.

Hoy aprenderás a pasar de una cifra agregada a un diagnóstico defendible: delimitar la desviación, comparar segmentos, escuchar a quienes realizan el trabajo y comprobar las causas propuestas. La lección está pensada para unos 40–45 minutos, incluidas las lecturas y los fragmentos de vídeo.


1. Define el problema antes de explicar su causa

«La adopción es baja» no indica qué investigar. En cambio, «durante S1, 2 de las 5 personas elegibles de oficina utilizaron el agente al menos un día, frente a 3 de 5 en campo» identifica población, periodo, comportamiento y diferencia. Si el objetivo acordado para ambos grupos era el 60 %, oficina quedó 20 puntos porcentuales por debajo en S1. En S2, ambos grupos llegaron al 60 %. El problema observado, por tanto, no es «oficina nunca adopta la IA», sino una brecha inicial que conviene entender.

Mira este fragmento de 106 - 8 Claves para Mejorar el Análisis Causa Raíz (Parte 1), de Keisen Consultores. Su idea central es útil para evitar que una investigación empiece con una solución preconcebida.

106 - 8 Claves para Mejorar el Análisis Causa Raíz (Parte 1)

En este fragmento, el ponente distingue un problema medible de una impresión como «uso deficiente».

Mira definir la desviación. Atiende a cómo formula la distancia entre el resultado observado y el objetivo, y a por qué evita convertir «dar más formación» en la definición del problema.

La comparación solo tiene sentido si conservas las definiciones del panel anterior. Uso semanal significa al menos un día de uso relevante, no abrir la interfaz. Su denominador son todas las personas elegibles, mientras que activación en siete días se calcula sobre las habilitadas. Si cambias de denominador a mitad de la investigación, puedes fabricar una mejora —o un problema— que no existe.

Hay otra pregunta previa a cualquier explicación: ¿podían y necesitaban usar la solución durante ese periodo? Una persona recién habilitada quizá aún no ha tenido siete días de exposición; otra puede no haber recibido incidencias aptas para el agente. En esos casos, una ausencia de uso no equivale automáticamente a rechazo.


2. Segmenta para localizar la brecha, no para etiquetar personas

En tu panel, el uso global pasó del 50 % en S1 al 60 % en S2. Ese aumento oculta que los grupos siguieron trayectorias diferentes:

Segmento Elegibles Personas activas S1 Uso S1 Personas activas S2 Uso S2
Oficina 5 2 40 % 3 60 %
Campo 5 3 60 % 3 60 %

Oficina mejoró y campo permaneció estable. Pero hay una segunda diferencia: activaron dentro de siete días 2 de 4 personas habilitadas de oficina y 3 de 4 de campo. Esto sitúa una posible dificultad en la llegada al primer valor, aunque todavía no identifica su causa. En ambas funciones había, además, una persona habilitada sin uso relevante en S1 ni S2: U04 en oficina y U07 en campo. Que compartan el mismo patrón numérico no implica que compartan el mismo obstáculo.

El análisis de cohortes ayuda a elegir comparaciones con sentido. Lee las partes indicadas de The Complete Guide to Cohort Analysis, de Amplitude; nos interesan los tipos de grupo y el método para investigar una diferencia, no aprender una herramienta concreta.

The Complete Guide to Cohort Analysis | Amplitude

Amplitude explica cómo agrupar usuarios para responder preguntas distintas y cómo convertir un patrón de uso en una hipótesis investigable.

En «Types of cohort analysis», lee los cuatro tipos. Después, en «How to do a cohort analysis step by step», sigue el método, desde la pregunta inicial hasta la formulación de una hipótesis. Fíjate especialmente en la elección de métrica, ventana temporal y patrones que merecen investigación.

Para este piloto, función (oficina o campo) es una segmentación por características; semana de habilitación permitiría comparar personas con una antigüedad comparable; y haber alcanzado el primer valor en siete días define un grupo por comportamiento. Conviene cruzar esas dimensiones con prudencia. Por ejemplo, si quieres saber si el lanzamiento inicial dificultó el uso, compara grupos con tiempo de exposición semejante antes de atribuir diferencias a la función.

Escoge primero una pregunta y una métrica: «¿En qué función se retrasa el primer valor durante los siete días posteriores a la habilitación?». Después añade solo los cortes necesarios para responderla. Dividir diez personas en muchas combinaciones de función, turno, fecha y comportamiento produce porcentajes llamativos, pero muy frágiles: con cuatro personas habilitadas por función, una sola persona representa 25 puntos porcentuales. Informa siempre del numerador y el denominador junto al porcentaje. En un informe amplio, evita mostrar grupos tan pequeños si permiten identificar indirectamente a alguien; respeta los umbrales y permisos establecidos por el cliente.


3. Combina señales de uso con lo que sucede en el trabajo

Los datos indican qué ocurrió; las señales cualitativas ayudan a reconstruir qué lo dificultó. La escucha es particularmente importante en tu papel: una sesión de formación puede terminar con buenas valoraciones y, aun así, dejar sin resolver un permiso, una instrucción ambigua o una duda sobre qué respuestas de la IA se pueden utilizar.

Patrón que ves Explicaciones que compiten Qué comprobarías
Hay acceso asignado, pero no primer valor Permiso efectivo incompleto; ningún caso elegible; dificultad para completar la primera tarea Reproducción de la tarea, registros de error, volumen de casos elegibles
Hay primer valor, pero cae el uso Resultados que exigen demasiado retrabajo; cambio de prioridades; tarea poco frecuente Casos revisados, calidad de las salidas, calendario operativo
Hay bastante uso, pero baja satisfacción Personas intentando usar la herramienta pese a respuestas poco útiles o difíciles de verificar Ejemplos concretos de salida, entrevistas y feedback
Una función usa menos que otra Distinto acceso, oportunidad, flujo de trabajo o apoyo de supervisión Comparación de condiciones, no solo de porcentajes

Microsoft Learn propone precisamente leer la satisfacción junto con el uso y permite explorar experiencias declaradas mediante encuestas. Lee estas dos partes como ejemplo de cómo complementar un panel; sus umbrales y filtros corresponden a ese producto, no son reglas universales para cualquier piloto.

Connect to the Microsoft Copilot Dashboard for Microsoft 365 customers | Microsoft Learn

La documentación de Microsoft Learn muestra qué aporta el feedback de las personas cuando las cifras de uso no bastan para interpretar la adopción.

En «More details on how to use and interpret satisfaction rate», lee uso y satisfacción. Después, en «Sentiment», lee las encuestas. Observa tanto las posibles interpretaciones como las cautelas sobre otros factores y tamaños mínimos de grupo.

Una conversación diagnóstica busca episodios observables, no una respuesta a «¿por qué no adoptas la IA?». Resultan más útiles preguntas como: «Piensa en la última incidencia para la que consideraste usar el agente: ¿en qué paso dejaste de hacerlo?», «¿Qué ocurrió al intentar verificar la clasificación?» o «¿Qué hiciste después para terminar el trabajo?». Contrasta las respuestas con tickets de soporte, permisos, ejemplos de resultados y datos de incidencias elegibles. Registra los hallazgos sin nombres en la vista compartida y no conviertas una entrevista aislada en la opinión de todo un colectivo.


4. Sigue la causa hasta donde llegue la evidencia

Volvamos a U04. El panel muestra que figura como habilitada, no alcanzó el primer valor y no registró uso relevante en ninguna de las dos semanas. Eso es una observación, no un diagnóstico. Podrías plantear al menos tres hipótesis: no recibió incidencias aptas, no sabía completar la tarea o podía abrir el agente pero carecía de permiso para consultar los datos necesarios.

Imagina que, en una comprobación adicional de este caso ficticio, U04 intenta clasificar una incidencia de prueba elegible y aparece un error de permiso al consultar su fuente. La persona de soporte reproduce el error con esa configuración y comprueba que otra cuenta autorizada sí completa el mismo paso. Ya hay evidencia concreta de un bloqueo técnico para esa tarea. Aún faltaría revisar por qué la cuenta constaba como «habilitada»: quizá el alta del agente y los permisos sobre la fuente de datos siguen circuitos distintos. Sin esa comprobación, sería precipitado declarar «la causa raíz es un mal proceso de altas». Tampoco podrías extrapolar el error de U04 a U07 sin investigar su caso.

El análisis de causa raíz exige acotar el problema y distinguir una condición inmediata de otra que permite que se repita. Estos dos fragmentos del vídeo anterior muestran cómo estrechar una investigación y por qué una explicación técnica puede no ser suficiente.

106 - 8 Claves para Mejorar el Análisis Causa Raíz (Parte 1)

Continúa con el vídeo de Keisen Consultores para ver cómo pasar de un problema amplio a uno investigable y cómo distinguir obstáculos inmediatos de condiciones organizativas persistentes.

Mira estratificar el problema: céntrate en la utilidad de investigar una dificultad concreta en vez de «toda la adopción». Luego mira causas sistémicas y piensa qué tendría que verificarse antes de atribuir un error de permisos al procedimiento general de altas.

Un diagnóstico breve para dirección puede conservar la incertidumbre sin perder utilidad:

Desviación: en S1, el uso relevante de oficina fue de 2/5 personas elegibles (40 %), frente al objetivo acordado del 60 %; en S2 llegó a 3/5.
Hallazgo localizado: U04 no registró uso relevante en ninguna semana. Una prueba de una incidencia elegible reprodujo un error de permiso sobre la fuente de datos.
Conclusión acotada: el permiso bloquea esa tarea en ese caso; no está demostrado que explique toda la brecha inicial de oficina ni la inactividad de U07.
Comprobación pendiente: revisar si otras altas comparten la configuración y contrastar por separado el contexto de trabajo de las demás personas sin primer valor.

Esta forma de redactar separa hecho, explicación respaldada y cuestión abierta. También evita una atribución injusta, como llamar «resistencia al cambio» a un problema de acceso. Y evita la inferencia opuesta: que dos grupos mejoren después de una formación no demuestra, por sí solo, que la formación causó la mejora. Para sostener esa conclusión habría que descartar cambios simultáneos —por ejemplo, más incidencias elegibles o permisos corregidos— y comprobar el efecto de la intervención.


Cierre

Diagnosticar baja adopción consiste en definir una brecha concreta, localizar dónde se concentra con denominadores y periodos comparables, escuchar cómo se realiza el trabajo y comprobar las hipótesis contra evidencia observable. Un patrón de uso señala dónde preguntar; ni un gráfico ni una opinión aislada identifican por sí solos la causa.

En la próxima lección utilizarás este tipo de diagnóstico para diseñar un plan de recuperación medible. La diferencia será decisiva: en vez de enviar la misma formación a todo el mundo, podrás elegir una acción dirigida al obstáculo que hayas comprobado y definir cómo sabrás si funcionó.

Can't find a good explanation? Sign up and we'll make it for you

Sign up