Da risa porque es verdad (también he estado ahí). Lamentablemente esta es la realidad de muchos equipos de data y de People Analytics. Es triste, porque detrás de cada reporte que nadie usa hay mucha inversión de tiempo, esfuerzo, recursos tecnológicos, capacitaciones, iniciativas que se despriorizaron, reuniones y discusiones con otras áreas. Todo eso se termina convirtiendo en un costo escondido debajo de la alfombra, pasando por etapas de negación, frustración, culpando a algo o a otros para finalmente continuar con el siguiente reporte estrella del cual estamos seguros de que "ahora sí que sí es lo que se necesita". No podemos dejar de mencionar que ese reporte "invisible" se sigue manteniendo, actualizando y consumiendo recursos (humanos y tecnológicos) y suele estar acompañado de otros reportes invisibles.
¿Cuáles son las consecuencias de no romper este ciclo?
El equipo pierde credibilidad frente a clientes internos y estos últimos terminan haciendo sus propios reportes por fuera.
Aparece la frustración de los desarrolladores de sentir que no están aportando valor o que no son tomados en cuenta
y el más importante: cero impacto en el negocio... Corrijo: impacto negativo (solo costos).
En este artículo trato de abordar este problema con el cual, si somos realmente sinceros, nos hemos enfrentado todos los que hemos trabajado en el mundo de la visualización de datos (y el que diga que no, por favor que me contacte y lo invito feliz a un café ☕). Planteo algunos errores comunes en los que se suele caer, y que a mi juicio, son los ingredientes perfectos para generar reportes invisibles. También intento dar sugerencias y guías para evitarlos.
¡Vamos!
Ingrediente N°1: No partir con una pregunta específica de negocio a responder
Lo primero es lo primero. Cada puesto de trabajo dentro de cualquier empresa tiene como objetivo lograr resultados de negocio y esto no es una excepción para los roles de analistas de datos o de visualización. Nuestra misión como profesionales de datos es responder preguntas de negocio para que se tomen acciones al respecto. El problema es que en general nunca se parte desde una necesidad y la secuencia es más o menos así:
hay nueva data disponible,
se cree que por existir más datos es una buena idea generar un reporte al respecto
se intenta responder preguntas que nadie preguntó o encontrar respuestas que nadie anda buscando, y
se le presenta al negocio un hermoso dashboard lleno de indicadores sobre los cuales nadie preguntó (muy parecido a una reunión de venta).
Esto es un error. Debemos siempre partir con una o más preguntas que tenga el negocio, que estén declaradas como prioridades (pueden ser dolores u oportunidades).
Algunos ejemplos de preguntas de negocio en el área de gestión de personas:
¿Por qué aumentó el ausentismo el mes pasado? ¿Es un perfil particular de colaboradores? ¿un área en particular?
¿Cómo puedo disminuir la rotación de empleados?
¿Cómo el eNPS (employee Net Promoter Score) afecta la calidad del servicio al cliente (NPS)? ¿Cuánto me cuesta 1 punto de eNPS en ingresos?
Ingrediente N°2: No cuestionar la pregunta de negocio: "¿y entonces qué?"
No basta con tener las preguntas de negocio claramente definidas y tener las respuestas en un dashboard. Es necesario hacerse otra pregunta (quizás la más importante): "¿y entonces qué?" (o cómo se dice en inglés: so what?).
Esta pregunta debe hacerse antes de empezar a desarrollar. Un ejercicio que he buscado implementar en las primeras conversaciones con el cliente que solicita el reporte es decirle que se ponga en el escenario hipotético de que ya tuviese el dashboard producción y que este incluye todos los indicadores que solicitados. Luego le pregunto: ¿Qué vas a hacer con la información? ¿Quién será el responsable de gestionarlo? ¿Están los recursos para hacerlo?
Ejemplo: El gerente de recursos humanos solicita un dashboard para ver el evolutivo de la rotación de colaboradores abierto por género, edad, estado civil, si tiene hijos, entre otros datos demográficos. Nuestro rol desde People Analytics sería decirle: "Asumamos que hoy ya tenemos desarrollado el dashboard y los datos muestran que la mayor tasa de rotación voluntaria (renuncias) existe en mujeres sobre 40 años. ¿Se puede hacer algo al respecto? ¿Tiene sentido hacerlo? ¿Existe voluntad para hacer algo con este segmento? ¿Hay presupuesto para realizar una acción de ese tipo? ¿Quién estará a cargo de monitorear estos números? ¿Cada cuánto lo harán?"
Este ejercicio confirmará o descartará si existirá un real impacto en el negocio antes de cualquier desarrollo. En simple: Si no habrá gestión, no habrá dashboard.
Ingrediente N°3: Comenzar desarrollando sin el usuario final
Puedes tener la pregunta de negocio (problema) y la gestión de parte del cliente asegurada (acción), pero aún así fallar. ¿Por qué? Porque para generar valor se necesita responder correctamente la pregunta en tiempo y forma (solución). Si fallamos en este paso podemos actuar tarde o equivocadamente.
Lo cierto es que muchos se caen en llegar a una buena solución, por no sentarse a conversar con el cliente interno de forma periódica para validar el desarrollo, tanto en forma como en fondo (ya hablaremos de la forma más adelante). Estas reuniones deben ocurrir desde los inicios del desarrollo, no solo a la mitad o cuando ya falta poco para la entrega. Mientras más las posterguemos, el riesgo de fracaso será mayor.
Algunas preguntas para discutir con el usuario final durante el desarrollo:
¿Cada cuánto necesitan que se actualice la información?
¿Qué granularidad de los datos necesitan? ¿Mensual? ¿Semanal? ¿Diaria?
¿Los datos les cuadran con la información que manejan?
¿Todos los usuarios deberían tener permiso para acceder a toda la información o hay restricciones?
¿El orden de los distintos gráficos es coherente para la forma en que se analizará el problema de negocio?
¿Qué tan amigos de la tecnología son los usuarios finales? ¿Vale la pena programar envíos en PDF para algunos?
Protip: Antes de comenzar el desarrollo, siempre se recomienda co-crear con el usuario final un borrador (mockup) en alguna aplicación que el mismo pueda editar (ej: powerpoint), y de esta forma disminuir el riesgo a equivocarnos en la solución (además existirá respaldo visual de lo solicitado).
Ingrediente N°4: Enamorarse más del reporte que del problema de negocio
Otra tentación en la que caen muchos desarrolladores y analistas de datos (sobre todo los más geeks) es la obsesionarse con el diseño y los detalles, enfocándose más en la estética, alineamientos, proporciones, colores, etc., y olvidándose del fondo. Es gratificante a nivel personal para el desarrollador lograr un reporte atractivo (de hecho hay competencias al respecto), pero si este no responde de la manera más eficiente y efectiva a las preguntas de negocio, se cae un error. La verdad es que al final del día nadie quiere ser el creador del reporte desconocido más bonito de la empresa. Lo primero es lo primero: el negocio.
Ingrediente N°5: ¡Mientras más KPIs mejor!
"Mejor que sobre a que falte" recita un dicho popular. Sin embargo, en este caso no aplica. Al agregar más información, agregamos más carga mental para el usuario, el cual debe procesar cognitivamente más y muchas veces solo logramos desconcentrarlo. En general, se cae en este error por no entender en profundidad la problemática de negocio y no conocer cuáles son los datos mínimos y necesarios que el usuario necesita para responder su pregunta. Por lo tanto, intentamos agregar todo buscando maximizar las probabilidades de acertar o porque sentimos que si no incluimos otros datos estamos desaprovechando una oportunidad. Debemos evitar este tipo de razonamientos y en convencernos de que "Menos es más"
Ingrediente N°6: No conocer ni aplicar las mejores prácticas de visualización de datos y data storytelling
La visualización de datos tiene bastante de arte, pero mucho de ciencia también. Existen estudios y buenas prácticas asociadas a cómo los seres humanos procesamos la información (Les dejo un ejemplo: principios de Gestalt del diseño). Por otro lado hay mucha literatura que detalla qué gráficos son mejores para representar cada tipo de información. Por ejemplo, para representar "la parte de un todo" será mejor un gráfico de barras apilados que uno de líneas. Por otra parte, para ver la tendencia de la tasa de rotación en el tiempo, se recomienda más un gráfico de línea que uno de barras.
Si aplicamos este conocimiento al diseño de nuestros dashboards, estaremos aumentando la efectividad de estos y disminuyendo la velocidad de procesamiento de información que tiene que realizar el usuario. Esto se traducirá en decisiones más acertadas y oportunas.
Ingrediente N°7: No tener definidos lineamientos visuales
Una de las primeras actividades que se deben realizar cuando se va a comenzar un área que desarrollará dashboards para varios clientes internos, es definir lineamientos visuales, es decir, reglas sobre las cuales se va a regir cada reporte para tener una estética parecida (look & feel).
Aquí se debe definir (entre otros):
Ubicación del logo de la compañía
Paleta de colores
Colores específicos para representar aumentos, disminuciones, unidades de negocio, países, etc.
Formato y ubicación de filtros
Espacio donde estarán los distintos gráficos
Tamaño y tipo de fuente
El objetivo es que cuando un usuario ingrese al dashboard de "ausentismo de empleados" y luego al de "capacitaciones y formación", debe sentir que está ingresando a un "mismo mundo" (ej.: debe encontrar los filtros en el mismo lugar y saber cómo interpretar cada color). Al igual que en el punto anterior, la práctica de tener lineamientos visuales aumentará la efectividad y la adopción de nuestros dashboards.
Ingrediente N°8: No tener una estrategia de adopción y usabilidad
Por último, pero no menos importante, nosotros cómo área también necesitamos responder nuestras propias preguntas de negocio (nuestro negocio):
¿Se están utilizando nuestros reportes?
¿Quiénes los utilizan? ¿Quiénes no lo utilizan?
¿Se utilizan con la frecuencia para la cual fueron diseñados?
¿Siguen vigentes?
¿Se están actualizando?
¿Tienen una velocidad de carga adecuada?
¿Se revisan todas las hojas?
¿Se descargan los datos?
¿Se comparten con otros usuarios?
¿Están siendo gestionados?
Si nosotros no lo medimos, no lo gestionaremos. Debemos definir nuestros propios indicadores de éxito para asegurarnos de que lo que hacemos está aportando valor al negocio. Para esto se pueden utilizar los reportes de adopción que algunas herramientas incluyen por defecto (ej.: Power BI y Tableau), o crear nuestros propios reportes.
No debemos olvidar que podemos caer en todos los errores ya mencionados anteriormente para el desarrollo de nuestros propios reportes internos. Así que debemos ser muy conscientes para que no nos pase que "En casa del herrero, cuchillo de palo".
Comentarios finales
Los "reportes invisibles" seguirán existiendo siempre y probablemente vas a generar más de uno en lo que queda de tu vida profesional. Sin embargo, lo importante es tener un diagnóstico claro de qué ingredientes fueron los más relevantes a la hora de invisibilizarlos: ¿Fue no entender bien la pregunta de negocio? ¿Quizás dedicaste horas innecesarias al diseño y te olvidaste de la urgencia y la problemática? ¿Faltó monitorear la adopción? ¿Todas las anteriores?
Espero que este artículo te haya ayudado a reflexionar de lo que hará que tus reportes sean usados, gestionados, valorados y tengan un real impacto en el negocio. Espero que te lleve a tomar acciones en tus próximos desafíos, a capacitarte, asesorarte y sumergirte en el negocio.
Si llegaste hasta aquí, muchas gracias por tu atención. Si te aportó valor, te agradecería compartir este artículo con alguien más o en tus redes.
Juan Pablo
Avisos comerciales
En Personalítica podemos ayudarte de distintas formas en tus proyectos de visualización de datos para People Analytics, desde:
Generación de una estrategia de visualización de datos
Desarrollo de lineamientos visuales y templates
Desarrollo de Dashboards para abordar una problemática de negocio específica
Talleres de Visualización de Datos y Data Storytelling
entre otros.
Contáctanos por el medio que prefieras.
Me sentí tremendamente identificado. Me ha pasado bastante que existen "necesidades" de tener un dashboard sin una pregunta de negocios clara y esto a la larga se termina traduciendo en ineficiencias o en un "bonito" dashboard pero que en realidad nadie necesita. Muy buen artículo!