Por qué no sustituimos BINSA
BINSA sigue siendo, hoy, la fuente de verdad de clientes, contratos e instalaciones de Everest. No lo reemplazamos por una razón simple: migrar por completo un ERP en producción es un proyecto de mucho más riesgo y coste que construir una capa moderna que lo aproveche. Everest actúa como una capa inteligente por encima: recibe las peticiones del frontend, las traduce a BINSA, gestiona autenticación y permisos, y añade todo lo que BINSA no sabe hacer —KPIs históricos, analítica, planificación inteligente y una app móvil.
El límite de BINSA no es de velocidad, sino de diseño: es un ERP administrativo sólido, pero no pensado para hacer analítica temporal ni consultas ad-hoc. Extraer y cruzar esa información a mano es lento, y eso era exactamente lo que Everest venía a resolver.
Cómo resolvemos el problema del histórico
Si BINSA no está pensado para consultas por fecha, ¿cómo mostramos evoluciones mensuales de cartera o de plantilla? La solución fue construir snapshots: periódicamente, el sistema captura una foto del estado de clientes, instalaciones, importe de cartera y plantilla, y la guarda en su propia base de datos. Cuando se consulta un periodo ya cerrado, Everest lee de ese snapshot en vez de ir en vivo contra BINSA, lo que hace la consulta más rápida y con datos que no cambian retroactivamente.
El CMI: tres cuadros de mando, un mismo lenguaje visual
El panel web organiza toda la analítica en tres bloques:
- CMI General: cartera de clientes e instalaciones, movimiento neto y desglose por tipo de cliente, con comparativas temporales.
- CMI Comercial: leads, ofertas, ventas, bajas y rendimiento por comercial, donde vive el CRM propiamente dicho.
- CMI Servicios: planning, incidencias y plantilla, incluyendo un resumen generado por IA que sintetiza en lenguaje natural lo que ha pasado con las incidencias en un periodo determinado.
Todos comparten el mismo lenguaje visual: gráficos consistentes, tarjetas de KPI con tendencias, filtros persistentes y exportación a informe.
El CRM: ligero, pero con piezas propias no triviales
No hay una base de datos de clientes propia: el CRM vive encima de los datos de BINSA, enriquecidos donde hace falta. Un ejemplo claro es la gestión de leads, donde Everest resuelve de golpe información que BINSA solo ofrece de forma parcial o dispersa, evitando que el frontend tenga que hacer decenas de llamadas para conseguir lo mismo.
Un matiz de negocio importante que costó documentar bien: existen dos catálogos distintos de motivos de desestimación —uno amplio de BINSA, usado para bajas y otros flujos, y un subconjunto reducido que usa específicamente el equipo comercial al descartar un presupuesto. Viven en sitios distintos y conviene no confundirlos.
Una decisión de arquitectura poco habitual: sin ORM, a propósito
Todo el backend habla con su base de datos en SQL directo, sin capa de ORM de por medio. Es una decisión pragmática para el tamaño del proyecto: evita una capa de abstracción innecesaria cuando la mayoría de consultas son agregaciones y cruces sobre datos que vienen de un sistema externo, aunque exige coordinación explícita cada vez que cambia algo en el esquema.
También convive con propósito una doble forma de autenticación: el backoffice web se valida contra el propio BINSA, porque el ERP sigue siendo quien decide quién es quién en la empresa, mientras que la app de operarios usa credenciales propias de Everest, desacopladas de BINSA a propósito —un operario de campo no necesita depender del sistema administrativo para poder fichar.
Lo que viene: explorar los datos con lenguaje natural
La siguiente pieza que estamos evaluando es un generador de gráficos a la carta: que el usuario describa en lenguaje natural qué quiere ver, y el sistema lo traduzca automáticamente en una consulta y una visualización, sin depender de un ticket y un release cada vez. La inteligencia artificial ya funciona en producción para los resúmenes de incidencias; el reto real está en replicar de forma fiable los datos de BINSA y blindar bien qué puede y qué no puede consultar cada usuario.
Si tienes un ERP sólido pero difícil de leer y necesitas una capa moderna de analítica encima, hablemos.