Un cuadro de mando en el móvil: ni BI comercial ni todo desde cero
La petición era sencilla: ver cómo va el negocio desde el móvil. Ventas de hoy, margen, pedidos pendientes, sin abrir el portátil ni pedirle un informe a nadie. Detrás había una decisión que cualquier responsable de IT reconoce: ¿compro una herramienta de BI o lo construyo? Mi respuesta acabó siendo «ninguna de las dos del todo», y creo que el razonamiento sirve fuera de mi caso.
Por qué no bastaba con una herramienta de BI
Metabase, Grafana, Superset o Kibana son estupendas para explorar datos en una pantalla grande. En el móvil son incómodas: filtros diminutos, paneles pensados para 1.920 píxeles, gráficas que hay que ampliar con los dedos. Las que sí cuidan el móvil suelen ser caras y piden bastante infraestructura propia.
Pero el problema de fondo no es la pantalla: es que un cuadro de mando en el móvil es otro producto. No se explora; se consulta en diez segundos entre dos reuniones. Pocos números grandes, una comparación que diga si es bueno o malo, una tendencia, y que te avise cuando algo se tuerce.
Por qué tampoco construirlo todo desde cero
- No quería atar el panel a las tablas del ERP. Un panel que lee directamente el esquema de otro sistema se rompe con cada actualización o cambio en ese sistema, y lo mantiene quien no lo diseñó.
- La exploración ya está resuelta. Usábamos Kibana para analizar pedidos; volver a programar filtros arbitrarios y gráficas configurables es reconstruir Kibana, peor.
- El coste real es el mantenimiento, y había varios frentes abiertos a la vez. Cada pieza propia es una pieza más que mantener.
La línea de corte
| Pieza | Decisión | Por qué |
|---|---|---|
| Capa de datos: ingesta e índice de negocio | Construir | Es la inversión que perdura: aísla de las fuentes y la usan todas las vistas |
| Exploración y análisis en escritorio | Reutilizar (Kibana) | Ya está y lo hace bien |
| Consulta rápida en el móvil | Construir, pequeño | Es lo que ninguna herramienta resolvía |
La regla que más importa: la app no habla nunca con Elasticsearch ni con el ERP. Habla con un servicio pequeño que le devuelve los indicadores ya calculados. Si una fuente cambia, solo cambia su conector de entrada; el índice, Kibana y la app siguen igual.
Lo que planifiqué y lo que acabé haciendo
El primer diseño en papel era más ambicioso que la primera versión que funciona, y las diferencias fueron todas a mejor:
| En el plan | En la v1 | Por qué |
|---|---|---|
| Índices nuevos de pedidos, líneas, presupuestos… | Reutilizar un índice de pedidos que ya existía, desnormalizado | Para la v1 no hacía falta ingesta nueva: el trabajo caro ya estaba hecho |
| Un servicio que agrega contra Elasticsearch en cada consulta | Una copia local en SQLite (completa de madrugada e incremental cada 15 minutos) y los indicadores se calculan contra ella | Local first: si Elasticsearch cae, el panel sigue funcionando, y las consultas son instantáneas |
| Una librería de gráficas | Gráficas SVG propias | En el móvil pesa la mitad, y bastan minigráficas, líneas y barras |
Todo va en un solo binario de Go con la interfaz en Vue embebida y una base SQLite, el mismo patrón que uso en documentador y appdist. En el móvil es una PWA: se instala desde Safari en la pantalla de inicio, no pasa por ninguna tienda y, si un día hace falta una app nativa, la API sirve tal cual.
Qué enseña
- Seis tarjetas: ventas, pedidos, ticket medio, margen bruto, margen en porcentaje y clientes nuevos. Cada una con su comparación frente al periodo anterior y frente al mismo periodo del año pasado, y una minigráfica.
- Cuatro periodos: hoy, semana, mes y año.
- Al tocar una tarjeta, la curva acumulada y rankings por fabricante, producto, país, cliente y forma de pago.
- Pedidos pendientes de una ventana de días configurable, con el detalle de cada uno.
- Usuarios propios: son datos sensibles del negocio y no van en abierto.
Lo que aprendí
- El esfuerzo está en los datos, no en las pantallas. Definir qué es exactamente «margen» o «pendiente» lleva más tiempo que pintar la tarjeta.
- Los datos sucios salen a la luz en cuanto los pones en grande. El primer «pedidos pendientes» incluía pedidos de hace años que nadie había cerrado en el ERP. La solución inmediata fue una ventana de días configurable; la de verdad, limpiarlos en origen.
- Elige una fecha de referencia y sé coherente. Usé la de alta del pedido en el ERP porque no cambia al cerrar el día, aunque eso deje los fines de semana a cero.
- Desacoplar la herramienta de sus fuentes es lo que hace que una herramienta interna dure más de un año.
- Una herramienta pequeña y propia no compite con Kibana: lo complementa. Cada una hace lo suyo.
Como todo lo que hago últimamente, lo construí con especificación primero y tests antes que código, con agentes de IA haciendo buena parte de la implementación. El método está contado en iadev.
Comprar o construir casi nunca es la pregunta buena. La buena es: qué parte es tuya de verdad y cuál ya resuelve otro.