En casi todas las reuniones donde se evalúa un proyecto de datos aparece la misma pregunta, y casi siempre la hace alguien que no es del área técnica: “¿y cómo llegan los datos del sistema al tablero?”.
Es una buena pregunta y merece una respuesta clara. Mientras la integración siga siendo una caja negra, cualquier presupuesto se evalúa a ciegas: no se puede juzgar si un plazo es razonable, si un costo tiene sentido o si el proveedor está prometiendo algo que su sistema no puede dar.
Esta nota explica cómo funciona la conexión entre un ERP y un tablero, en lenguaje de negocio. Al final vas a poder sentarte con el proveedor de tu sistema de gestión y hacerle las preguntas correctas.
Lo primero: conectar significa leer, no tocar
La confusión más frecuente y la que más ansiedad genera es pensar que el tablero se mete dentro del ERP y lo modifica.
No ocurre eso. Una integración de BI bien hecha es de solo lectura. El tablero consulta información y la muestra ordenada. Tu sistema de gestión sigue siendo el lugar donde se carga y se procesa la operación, con sus mismos permisos, sus mismos usuarios y sus mismas reglas.
Esto tiene dos consecuencias prácticas que conviene tener presentes desde el principio. La primera es que un proyecto de BI no reemplaza tu ERP ni te obliga a cambiarlo. La segunda es que el riesgo operativo de la conexión es bajo, porque nada de lo que pase en el tablero puede alterar un asiento, un stock o una factura.
Con eso claro, quedan tres formas de que esa lectura ocurra.
Las tres modalidades de integración
1. Conector nativo: el sistema ya viene preparado
Algunos sistemas de gestión ya traen una salida pensada para herramientas de análisis. En ese caso la conexión se configura eligiendo el sistema de una lista, ingresando credenciales y seleccionando qué tablas o entidades se van a leer.
Cuándo aplica. Sistemas de gestión modernos, en general los que funcionan en la nube o los que tienen una versión reciente con módulo de integración habilitado.
Qué implica. Es la modalidad más rápida de poner en marcha y la más estable en el tiempo, porque el mantenimiento del conector corre por cuenta del fabricante del sistema. Cuando el ERP se actualiza, el conector se actualiza con él.
Dónde está el límite. El conector expone lo que el fabricante decidió exponer. Si necesitas un campo personalizado que tu empresa agregó por su cuenta, puede que no venga incluido y haya que resolverlo por otra vía.
2. API: el sistema responde consultas
Una API es una puerta de entrada que el sistema abre para que otro programa le pida datos de forma ordenada y automática. En lugar de que una persona entre a la pantalla y exporte, un proceso automatizado pregunta “dame las ventas desde tal fecha” y el sistema responde.
Cuándo aplica. Cuando el ERP tiene API documentada, algo bastante común en sistemas de los últimos años y en la mayoría de los que operan en la nube.
Qué implica. Es la modalidad más flexible: permite traer exactamente los datos que necesitas, con la frecuencia que definas, incluyendo campos personalizados. A cambio, requiere trabajo de desarrollo inicial y credenciales de acceso que alguien tiene que autorizar dentro de tu empresa.
Dónde está el límite. Dos cosas para mirar antes de comprometerse. Una es si el proveedor cobra por habilitarla, porque algunos lo hacen. La otra son los límites de consulta: muchas APIs restringen cuántos pedidos se pueden hacer por hora, y eso condiciona la frecuencia de actualización real del tablero.
3. Archivos: el sistema deposita, el tablero recoge
La modalidad más antigua y la más subestimada. El ERP genera automáticamente un archivo con los datos, normalmente en formato de texto o de planilla, lo deja en una carpeta o en un servidor acordado, y el proceso de BI lo levanta desde ahí en un horario fijo.
Cuándo aplica. Sistemas antiguos, sistemas cerrados sin API, o casos donde el proveedor no autoriza el acceso directo a la base de datos. También sirve como puente inicial mientras se negocia una integración más profunda.
Qué implica. Es simple, barata y funciona en escenarios donde las otras dos no están disponibles. La contrapartida es que la actualización pasa a ser por lotes, típicamente una o dos veces al día, y que el proceso es más frágil: si alguien cambia el nombre de una columna o mueve la carpeta, la carga falla.
Dónde está el límite. No sirve para decisiones que necesitan información del momento. Para un cierre diario o un seguimiento semanal, alcanza sin problema.

El recorrido completo del dato
Independientemente de la modalidad, el camino que hace un dato desde tu operación hasta el tablero tiene siempre las mismas cuatro etapas.
Origen. El dato se genera cuando alguien carga una venta, registra una entrega o cierra una orden de producción. Acá el dato ya nace bien o nace mal, y ninguna etapa posterior arregla del todo un origen desprolijo.
Extracción. El proceso automático trae los datos por alguna de las tres vías descritas. Se define qué se trae, desde cuándo y cada cuánto.
Transformación. Los datos se limpian y se unifican: nombres de clientes que aparecen de tres formas distintas, fechas en formatos diferentes, criterios que no coinciden entre sistemas. Acá también se calculan los indicadores según las definiciones acordadas. Esta es la etapa que más trabajo lleva en cualquier proyecto y la que nadie ve en una demo.
Visualización. Recién al final aparece el tablero, que es la punta visible de todo lo anterior.

Cada cuánto se actualiza y cada cuánto conviene
La frecuencia de actualización se elige, y suele elegirse mal por exceso.
El tiempo real tiene sentido cuando existe una decisión que se toma en el momento: una planta que puede detener una línea, una operación logística que puede reasignar un reparto en curso. Fuera de esos casos, la mayoría de las decisiones gerenciales se toman con información del día anterior sin ninguna pérdida de calidad.
Pedir tiempo real donde no hace falta encarece el proyecto, agrega puntos de falla y presiona a los sistemas de origen. Conviene definir la frecuencia decisión por decisión, y no como una configuración general del tablero.
Qué preguntarle al proveedor de tu ERP
Esta es la parte accionable. Con estas preguntas respondidas por escrito, cualquier presupuesto de BI se vuelve mucho más fácil de evaluar.
- ¿El sistema tiene API documentada? Si la tiene, ¿está incluida en mi licencia o se cobra aparte?
- ¿Existe un conector ya desarrollado para herramientas de análisis?
- ¿Se puede acceder a una réplica de la base de datos en modo lectura?
- Si no hay API, ¿el sistema permite programar exportaciones automáticas a una carpeta?
- ¿Qué límites de consulta tiene la API por hora o por día?
- ¿Los campos personalizados que agregamos están disponibles por esa vía?
- ¿Quién dentro de nuestra empresa puede autorizar las credenciales de acceso?
La respuesta a la primera y a la cuarta ya define casi todo el escenario. Si ninguna de las dos da resultado, todavía quedan caminos, aunque más artesanales.
Cuando el ERP es viejo o cerrado
Es una situación frecuente en empresas medianas que trabajan hace años con un sistema estable que nadie quiere tocar. La buena noticia es que casi siempre hay salida.
La primera opción es la exportación programada, aunque haya que configurarla del lado del sistema con ayuda del proveedor. La segunda es leer una copia de la base de datos, cuando la licencia lo permite, con un usuario de solo lectura. La tercera, y la última en orden de preferencia, es la automatización de la exportación manual: un proceso que simula lo que hace una persona para bajar el archivo. Funciona, resuelve casos donde no hay alternativa, pero es la más frágil de todas y conviene tratarla como puente temporal.
Lo que casi nunca se justifica es cambiar el ERP para poder hacer BI. Si el sistema resuelve bien la operación, la integración se resuelve por alguno de estos caminos y el cambio de sistema se evalúa por sus propios motivos.
Lo que esto significa para tu proyecto
La integración deja de ser una caja negra cuando sabes cuál de las tres modalidades habilita tu sistema, con qué frecuencia necesitas la información y qué campos tienen que viajar. Con esas tres respuestas, un proveedor serio puede darte un alcance realista en lugar de un rango genérico.
Así trabajamos nosotros: revisamos primero qué expone tu sistema y recién después definimos el alcance. Esto es BI aterrizado a tu operación, sin obligarte a reemplazar lo que ya funciona. Implementamos en semanas, no en meses, y sin proyectos eternos.
FAQ: lo que pregunta una gerencia antes de integrar
¿Conectar el tablero puede hacer más lento mi ERP?
Una integración bien configurada consulta en horarios de baja actividad o sobre una réplica, justamente para evitarlo. Es un punto legítimo para plantear al inicio y tiene solución técnica conocida.
¿Necesito que mi proveedor de ERP participe del proyecto?
En general sí, al menos para habilitar accesos y confirmar qué vías están disponibles. No hace falta que desarrolle nada, salvo que el sistema no tenga ninguna salida automática.
¿Se pueden conectar varios sistemas a la vez?
Sí, y es el escenario más común. Una empresa mediana suele tener ERP, algún sistema de facturación o cobranzas y planillas de áreas específicas. Cada fuente entra por la modalidad que tenga disponible y se unifican en la etapa de transformación.
¿Qué pasa si cambio de ERP más adelante?
Se rehace la etapa de extracción para la nueva fuente. Las definiciones de indicadores y los tableros se conservan, que es la parte donde está la mayor inversión de criterio.
¿Cuánto tarda la conexión en sí?
Con conector nativo o API disponible, la conexión inicial suele resolverse en días. Lo que define el plazo del proyecto completo es la transformación, es decir, el estado de los datos de origen y la cantidad de criterios a acordar.
Próximo paso
Si estás evaluando un proyecto de datos, la conversación con el proveedor de tu ERP conviene tenerla antes de pedir presupuestos. Las siete preguntas de más arriba se responden en una llamada y cambian por completo la precisión de lo que te van a cotizar.
Podemos revisar contigo qué expone tu sistema y qué modalidad conviene en tu caso, en un diagnóstico inicial sin costo de 30 minutos.

