Por qué, motivaciones y como hemos construido el panel de control del Coronavirus

Motivaciones para crear nuestro panel de seguimiento del Coronavirus

Cuando empezó a crecer el coronavirus en China, la Universidad Johns Hopkins (JHU) recopiló la información de todos los países que iban informando de la cantidad de casos, muertos y recuperados. Creó un cuadro de mando, o dashboard, que reflejaba la evolución especialmente en China vs el resto del mundo. Además, compartió diariamente en GitHub los ficheros que usaba. La información era, y sigue siendo, una mera exposición de los datos primarios por país.

Con posterioridad surgieron otros sitios web que mostraban la misma información con diferentes visualizaciones y tecnologías. Pero, desde nuestro punto de vista, todos se limitaban a exponer, con diferentes presentaciones, la misma información.

Echábamos en falta mediciones de tendencia, comparativas entre países, … Ello nos motivó a desarrollar un dashboard que invitara a poder interaccionar más, a obtener conocimiento basado en la experimentación.

Cómo lo hicimos

Para ello usamos la información de la JHU y ficheros del World Bank Open Data para integrarlos y mostrarlos en una solución interactiva construida inicialmente en MetaBase y posteriormente con Power BI de Microsoft dando un resultado increible.

La carga de los datos se llevó a cabo con Pentaho Data Integration (ETL) y se empleó Weka para realizar análisis de Machine Learning.

Resultado Final

Como resultado de todo ello hemos puesto a disposición de todo el mundo una herramienta en la que se puede:

• Ver tendencias
• Agrupar países por la fase del contagio en la que se encuentran
• Ver la proyección en el tiempo
• Comparar la evolución de los países e incluso
• Estimar el número de contagios reales en todo el planeta.

Esperamos que sea de utilidad para todo aquel que quiera entender mejor la evolución de esta enfermedad y que nos ayude a todos a sacar mejores conclusiones y solventar cuanto antes esta pandemia.

Actualización — Agosto 2026: qué queda de aquel proyecto

Nota editorial: el panel público de seguimiento se retiró hace tiempo, cuando las fuentes de datos originales dejaron de actualizarse a diario. El repositorio de la Johns Hopkins cerró su recopilación en marzo de 2023 y el seguimiento pasó a manos de organismos oficiales con otra cadencia. Mantenemos este artículo porque lo interesante ya no son las cifras, sino cómo se construyó: la arquitectura, las decisiones y los errores siguen siendo exactamente los mismos que encontramos hoy en cualquier proyecto de datos.

El panel de control del Coronavirus que desarrollamos en Keliam fue uno de nuestros proyectos más visibles y demostró nuestra capacidad para crear herramientas de visualización de datos en tiempo real bajo presión. La experiencia adquirida con dashboards interactivos, APIs de datos públicos y visualización geoespacial la aplicamos hoy en proyectos de Business Intelligence con Redash, Metabase y dashboards personalizados para nuestros clientes. La lección aprendida: los datos solo son útiles cuando se presentan de forma clara y accionable.

Seis años después, ese proyecto se ha convertido en nuestro caso de estudio interno favorito para explicar a un cliente por qué un dashboard no es una pantalla bonita, sino la punta visible de una cadena de trabajo que empieza mucho antes. Lo que sigue es esa cadena, contada con lo que sabemos hoy.

Qué aprendimos construyendo un dashboard con datos públicos

El dato crudo casi nunca está listo

La imagen romántica del proyecto de datos es la del gráfico apareciendo en pantalla. La realidad es que entre el 60 % y el 80 % del esfuerzo se va en conseguir que los datos entren limpios. En aquel proyecto nos encontramos con países que cambiaban el nombre a mitad de serie, provincias que aparecían y desaparecían, columnas que se renombraban sin aviso, fechas en tres formatos distintos y correcciones retroactivas que modificaban cifras ya publicadas.

Nada de eso es exclusivo de una emergencia sanitaria. Es exactamente lo que pasa cuando integras el ERP de un cliente con su tienda online, o cuando cruzas el CRM con la facturación: referencias duplicadas, clientes con dos fichas, importes con y sin IVA, y un catálogo que alguien editó a mano el viernes por la tarde. La conclusión práctica es siempre la misma: hay que asumir que la fuente va a cambiar y diseñar el proceso de carga para que avise en vez de romperse en silencio.

Las métricas hay que definirlas una sola vez

El segundo aprendizaje fue más incómodo. Nos dimos cuenta de que la mayoría de discusiones sobre «los números no cuadran» no eran errores de cálculo, sino desacuerdos de definición. ¿Qué es un caso activo? ¿Qué es una recuperación? ¿Se cuenta por fecha de notificación o por fecha de diagnóstico? Cambiar la respuesta modificaba la curva entera.

En un proyecto de empresa, esa misma pregunta se llama: ¿qué es un cliente activo? ¿Un pedido cuenta cuando se paga o cuando se sirve? ¿El margen incluye portes? Si cada informe lo resuelve por su cuenta, acabas con tres cifras distintas para la misma pregunta y con una dirección que deja de fiarse del panel. La solución es una capa semántica: definir cada métrica una vez, con nombre y fórmula, y que todos los cuadros de mando beban de ahí.

Las cinco capas de un panel de control que aguanta

1. Fuentes

APIs públicas, ficheros que alguien deja en una carpeta, la base de datos operacional del ERP, el CRM, la plataforma de ecommerce. Lo primero es inventariarlas: quién las mantiene, con qué frecuencia cambian, qué pasa si un día no llegan. En el proyecto del panel la fuente principal era un repositorio de GitHub que se actualizaba a diario; en una pyme suele ser una mezcla de base de datos propia y integraciones vía API con ERP, logística y pagos.

2. Ingesta y transformación

Es la capa que extrae, valida y normaliza. Aquí van los controles de calidad: ¿ha llegado el fichero?, ¿tiene las columnas esperadas?, ¿el número de filas está dentro de un rango razonable?, ¿hay fechas del futuro? Un proceso de carga que falla ruidosamente es infinitamente mejor que uno que carga datos corruptos sin quejarse.

3. Almacén analítico

Consultar directamente la base de datos de producción para pintar gráficos es una mala idea por dos motivos: castigas al sistema que atiende a los clientes y te atas al modelo transaccional, que no está pensado para agregar. Un almacén separado, aunque sea modesto, permite modelar en estrella, guardar histórico y responder rápido.

4. Capa semántica

El diccionario de métricas del que hablábamos. Puede vivir en vistas SQL, en modelos de dbt o en la propia herramienta de BI, pero tiene que existir y estar documentada.

5. Visualización

La última capa y la única que ve el usuario. Su trabajo no es enseñar todo lo que hay, sino responder preguntas concretas de gente concreta. Un panel para dirección y un panel para el responsable de operaciones no deberían parecerse.

El stack de 2020 y el stack de 2026

Las capas no han cambiado. Las herramientas, bastante. Si tuviéramos que rehacer hoy aquel panel, el diseño sería reconocible pero las piezas serían otras.

Ingesta y transformación

Pentaho Data Integration fue durante años la opción por defecto para ETL visual en proyectos open source. Su situación cambió: Hitachi Vantara dejó de ofrecer la edición community para uso en producción, lo que empujó a mucha gente a buscar alternativas. Hoy el patrón dominante es ELT en lugar de ETL: se cargan los datos casi en crudo y se transforman ya dentro del almacén, normalmente con dbt para la parte SQL y con Airbyte para la ingesta desde fuentes heterogéneas. Quien busque una experiencia visual parecida a la de Pentaho tiene Apache Hop, que nació precisamente como bifurcación de ese ecosistema.

Almacenamiento y orquestación

PostgreSQL sigue siendo suficiente para la inmensa mayoría de proyectos de pyme. Para volúmenes analíticos medianos, DuckDB ha cambiado bastante las reglas: permite consultas analíticas muy rápidas sin montar infraestructura. Y para la orquestación, aquel cron de 2020 se ha sustituido por Airflow o Kestra, que dan reintentos, dependencias entre tareas y trazabilidad de ejecuciones.

Visualización

Metabase sigue siendo nuestra recomendación por defecto cuando el objetivo es que gente no técnica se haga sus propias preguntas: es el open source de BI más adoptado y su rama estable va ya por la serie 60. Apache Superset es la opción cuando pesan más la variedad de gráficos y el gobierno. Redash, que también usamos en su momento, lleva tiempo en modo mantenimiento tras la adquisición por Databricks, así que hoy no lo elegiríamos para un proyecto nuevo. Y Power BI sigue teniendo todo el sentido cuando el cliente ya vive dentro del ecosistema Microsoft. Si estás en esa decisión, lo desarrollamos con más detalle en dashboards a medida vs Power BI vs Metabase.

Machine learning

Weka nos sirvió para prototipar rápido sin escribir código, y para eso sigue siendo didáctico. Pero hoy cualquier análisis de este tipo se hace en Python con scikit-learn, y la parte estadística se documenta en un notebook versionado. Además ha aparecido una capa que en 2020 no existía: los modelos de lenguaje. No sustituyen al análisis, pero sí resuelven bien la consulta en lenguaje natural sobre datos ya modelados y la generación de resúmenes; si te interesa esa vía, explicamos el patrón en nuestra guía sobre RAG aplicado a empresas.

Visualizar sin engañar: seis reglas que aplicamos

Un panel de control tiene poder de convicción. Con los mismos datos se puede transmitir calma o alarma, y eso obliga a cierta disciplina:

• El eje Y empieza en cero en gráficos de barras. Truncarlo exagera diferencias pequeñas.
• Escala logarítmica solo cuando aporta y siempre indicada en el propio gráfico.
• Valores absolutos y relativos juntos. Un país con más habitantes tendrá más casos de casi todo; sin normalizar por población la comparación no dice nada.
• Media móvil para series con estacionalidad semanal. Los datos administrativos caen los fines de semana y rebotan el lunes; sin suavizado se lee un patrón que no existe.
• Fecha del último dato siempre visible. Un panel sin marca temporal es una trampa.
• Distinguir dato de estimación. Si hay proyección, que se vea con otro trazo y con su intervalo.

Gobierno del dato, seguridad y RGPD

Trabajar con datos públicos agregados nos ahorró la parte más delicada. En un proyecto de empresa esa parte es ineludible: los paneles suelen contener datos de clientes, importes, márgenes y a veces información de personal. Tres cosas que revisamos siempre:

Permisos por rol y por fila. No todo el mundo debe ver todo. Un comercial debería ver su cartera, no la del compañero. Las herramientas de BI resuelven esto de forma desigual, y en algunas es una función de pago; conviene comprobarlo antes de elegir.

Minimización y anonimización. Si el panel responde a preguntas agregadas, no necesita el nombre y el DNI del cliente en el almacén. Cuanto menos dato personal viaje a la capa analítica, menos superficie de riesgo.

Credenciales y accesos. Las conexiones del ETL suelen tener permisos amplios y viven en ficheros de configuración. Es uno de los puntos que más veces encontramos flojos: usuarios de base de datos con permisos de escritura donde bastaba lectura, y claves sin rotar desde la instalación. Si tu organización está formalizando esto, el marco de la certificación ISO 27001 ordena bastante bien la conversación, y para la parte de exposición de datos vía API tenemos una guía específica de seguridad en APIs REST.

Cuánto cuesta montar un dashboard como este

La pregunta llega siempre, y la respuesta honesta es que depende casi por completo del estado de las fuentes. El coste de licencias es hoy la parte menor: con Metabase o Superset autoalojados el software no cuesta nada y el servidor es modesto. Lo que se paga es el trabajo de dejar los datos utilizables.

Como orden de magnitud, en los proyectos que vemos: un panel operativo sobre una única fuente ya limpia se resuelve en dos o tres semanas de trabajo. Un cuadro de mando de dirección que cruza ERP, ecommerce y CRM se va a dos o tres meses, y la mitad de ese tiempo es normalización y acuerdos sobre definiciones. Después hay un coste recurrente que casi nadie presupuesta: mantener las cargas cuando las fuentes cambian. Es pequeño, pero no es cero, y cuando se ignora el panel muere en seis meses.

Hay un caso en el que decimos que no compensa: cuando la empresa tiene tres consultas puntuales al año. Ahí un informe bien hecho es más barato y más útil que una plataforma que nadie abrirá.

Errores comunes que vemos en auditorías de BI

• Panel escaparate. Cuarenta gráficos en una pantalla porque «así se ve todo». Nadie lo mira. Un buen panel responde entre tres y siete preguntas.
• Conexión directa a producción. Funciona el primer mes y penaliza a los clientes el día de más tráfico.
• Métricas sin dueño. Si nadie es responsable de la definición de «cliente activo», habrá tantas definiciones como informes.
• Sin histórico. Sobrescribir la carga cada día impide analizar tendencias y hace imposible auditar una cifra pasada.
• Ausencia de alertas. Si el proceso falla un martes y nadie se entera hasta el viernes, la dirección ha tomado tres días de decisiones con datos viejos.
• Rendimiento ignorado. Un panel que tarda veinte segundos en cargar deja de usarse. Los mismos criterios de rendimiento web aplican aquí.

Hoja de ruta en cuatro fases

Fase 1 — Preguntas antes que datos (1 semana). Sentarse con quien va a decidir y escribir las preguntas que el panel debe responder. Si no se pueden escribir, no hay proyecto todavía.

Fase 2 — Inventario y calidad (2-3 semanas). Localizar fuentes, medir su calidad real y acordar definiciones. Aquí aparecen las sorpresas, y es mejor que aparezcan pronto.

Fase 3 — Pipeline y modelo (3-4 semanas). Cargas automatizadas con validaciones, almacén analítico, capa semántica documentada.

Fase 4 — Visualización e iteración (2-3 semanas y continuo). Primer panel, uso real, ajuste. El primer diseño casi nunca sobrevive al contacto con el usuario, y eso es señal de que el proyecto va bien.

Este esquema es el mismo que aplicamos en proyectos de digitalización industrial y en cuadros de mando de Business Intelligence para ecommerce, donde la fuente es la tienda en lugar de una API pública.

Preguntas frecuentes

¿Sigue disponible el panel del Coronavirus?

No. Se retiró cuando las fuentes originales dejaron de publicar con cadencia diaria. Este artículo se mantiene por su valor técnico, no como herramienta de consulta.

¿Metabase o Power BI?

Metabase si quieres autoalojarlo, controlar el coste por usuario y que gente no técnica explore sin pedir permiso. Power BI si la organización ya trabaja con Microsoft 365 y valora la integración nativa con Excel y Teams. No es una decisión ideológica: es una decisión de contexto.

¿Necesito un data warehouse para empezar?

No necesariamente uno grande. Una base PostgreSQL separada de producción, con un esquema pensado para analítica, cubre a la mayoría de pymes durante años.

¿Puedo usar IA para preguntar a mis datos en lenguaje natural?

Sí, y funciona razonablemente bien, pero solo si debajo hay un modelo limpio y unas métricas definidas. La IA sobre datos desordenados produce respuestas seguras de sí mismas y equivocadas, que es el peor resultado posible.

¿Cada cuánto hay que revisar un dashboard?

Una revisión trimestral basta para retirar lo que ya nadie mira y añadir lo que se pide por email. Un panel es un producto vivo, no un entregable.

Conclusión

Aquel panel de 2020 se construyó en semanas, con herramientas que hoy sustituiríamos casi todas, y aun así las decisiones importantes fueron las mismas que tomamos ahora: entender la fuente antes de dibujar nada, definir las métricas una sola vez, automatizar la carga con validaciones y diseñar la pantalla para responder preguntas concretas. Las herramientas envejecen deprisa; la arquitectura, mucho menos.

Si tienes datos repartidos entre el ERP, la tienda y media docena de hojas de cálculo, y la sensación de que la información existe pero no llega a tiempo a quien decide, ese es exactamente el punto de partida de este tipo de proyectos.