Guía: dashboard de KPIs para concesionarias con PostgreSQL y Streamlit

La mayoría de las concesionarias que conozco miden su negocio con planillas Excel. Una por sucursal, una por mes, una por vendedor. Consolidar esas planillas para la reunión del lunes es el trabajo de nadie y el problema de todos.

Después de resolver esto en varios proyectos, acá está la arquitectura que funciona.

El estado inicial típico

El patrón se repite: el contador tiene una planilla con ventas del mes. El gerente de post-venta tiene otra con OTs. Recursos humanos tiene una con presencia. Nadie habla con nadie. Las tres planillas tienen formatos distintos.

La reunión de directorio se prepara los domingos consolidando esas tres planillas en una cuarta. Ese cuarto archivo es el dashboard de facto de la empresa.

La arquitectura

La solución tiene tres capas:

Capa de datos: PostgreSQL como fuente única de verdad. Todas las fuentes (exportaciones del sistema de gestión, cargas manuales, integraciones API) apuntan a la misma base. Un schema por área de negocio (ventas, postventa, rrhh), con una capa de vistas materializadas que pre-calculan los KPIs frecuentes.

Capa de transformación: scripts Python con Pandas que corren en GitHub Actions a las 7am de cada día hábil. Toman los datos brutos, los limpian, los transforman y actualizan las vistas materializadas. Error handling explícito con alertas por email si falla.

Capa de visualización: Streamlit para el dashboard. Elegí Streamlit sobre Power BI o Tableau porque el cliente tiene Python, no licencias de BI. El código vive en Git, los cambios son versionables, y el equipo técnico puede extenderlo sin contratar a nadie más.

Los KPIs que más importan

En cada proyecto de este tipo, lo primero que hago es una sesión con el gerente comercial para definir qué métricas realmente importan. Invariablemente, la lista inicial de 30 KPIs se reduce a 8 que se miran todos los días.

Los más frecuentes: unidades vendidas vs. objetivo mensual, margen bruto por modelo, rotación de inventario (días en stock), leads por canal (WhatsApp/web/walk-in), tasa de conversión por vendedor.

Streamlit: lo que funciona y lo que no

Streamlit es rápido de prototipar pero tiene limitaciones reales para dashboards complejos. El modelo de re-ejecución completa del script en cada interacción puede generar consultas SQL redundantes.

La solución: @st.cache_data con TTL de 15 minutos para queries pesadas. El usuario ve datos con 15 minutos de lag máximo, que para un dashboard operativo de concesionaria es perfectamente aceptable.

Para autenticación, uso st.secrets para variables de entorno y un sistema simple de contraseñas hasheadas por rol. No es un sistema de auth robusto, pero para un panel interno con 5 usuarios es suficiente.

Lecciones aprendidas

La migración de datos históricos siempre toma más de lo estimado. Los datos de planillas tienen inconsistencias que nadie sabe que existen hasta que intentás cargarlos a una base de datos con tipos estrictos.

La adopción del dashboard depende de la capacitación. Entregar el sistema sin una sesión de uso guiada resulta en que el equipo sigue usando las planillas de costumbre. La capacitación de 2 horas al equipo es parte del entregable, no un opcional.

El mejor indicador de éxito: cuánto tiempo tarda en prepararse la reunión del lunes. Si pasó de 3 horas a 15 minutos, el proyecto fue exitoso.