Volver al blog

Caso Nokia: reporting operativo para Central Planning

En Nokia trabajé como data analyst en el departamento de Central Planning. Mi responsabilidad principal era la gestión del reporting operativo: los dashboards que el equipo de planificación usaba todos los días para tomar decisiones sobre asignación de recursos, priorización de proyectos y seguimiento de ejecución.

El contexto: planificación centralizada en una multinacional

Central Planning en Nokia coordina la ejecución de proyectos a nivel global. Eso significa consolidar datos de múltiples equipos, regiones y sistemas en una vista coherente que permita responder preguntas como: ¿estamos cumpliendo los objetivos del trimestre? ¿Dónde hay desviaciones? ¿Qué recursos necesitamos reasignar? Los datos venían de SAP, de hojas de cálculo de equipos regionales, de herramientas de gestión de proyectos, y de fuentes ad-hoc que cambiaban según el trimestre.

Los dashboards: diseñados para decisiones, no para decoración

Diseñé y mantuve una suite de dashboards en Power BI que cubrían tres niveles de detalle. El primero, el dashboard ejecutivo, mostraba la evolución acumulada de ejecución versus objetivos planificados — la vista que el director revisaba cada lunes a las 9am. El segundo, el dashboard operativo, permitía al equipo de planning hacer drill-down por región, por tipo de proyecto, por periodo, e identificar dónde estaban los gaps. El tercero, el dashboard de detalle, llegaba al nivel de proyecto individual para análisis específicos.

Lo importante no era hacer dashboards bonitos — era que fueran útiles. Cada métrica estaba ahí porque alguien la necesitaba para tomar una decisión concreta. Si un KPI no generaba una acción, no tenía sentido mostrarlo.

El modelo de datos: la parte invisible que lo sostiene todo

El 70% del trabajo no era visual — era el modelo de datos detrás. Consolidar fuentes dispares, manejar granularidades distintas (datos diarios de unos sistemas, semanales de otros, mensuales de otros), resolver conflictos de nomenclatura entre regiones, y construir un modelo dimensional que permitiera los cruces que el equipo necesitaba sin que el dashboard tardara 30 segundos en cargar.

Lo que aprendí: el dato es un medio, no un fin

Nokia fue donde entendí que el valor del dato no está en el dato en sí, sino en la decisión que permite tomar. Un dashboard sofisticado que nadie usa no sirve. Un dashboard simple pero que el equipo revisa cada día y con el que toma decisiones concretas, ese sí vale. Esa mentalidad — construir para que se use, no para que impresione — es la que aplico hoy en cada proyecto de datos.

¿Necesitas ayuda con esto?

Si este artículo describe un reto parecido al tuyo, hablemos.

Hablemos de tu proyecto