Cómo conectamos POS, stock y loyalty en una infraestructura de datos propia

“Conectar sistemas” suena a un trabajo de un fin de semana: agarras la documentación de cada API, escribes el código que las une, y listo. En la práctica, casi nunca es así. El trabajo difícil no es la conexión en sí, es todo lo que hay que resolver antes de poder confiar en los datos que esa conexión trae. Así construimos la infraestructura de datos de un negocio de restauración real en España, conectando tres sistemas que no se hablaban entre sí.

El problema real no es técnico, es de confianza en los datos

El negocio usaba Ágora como punto de venta, GStock para stock, producción y compras, y Cheerfy como sistema de fidelización. Cada uno tenía su propia API, y en teoría, conectarlas era cuestión de escribir el código correspondiente. En la práctica, cada sistema representaba la misma información de forma distinta: un mismo producto con nombres ligeramente diferentes en cada plataforma, fechas en formatos distintos, registros duplicados cuando una venta se reflejaba en más de un sistema. Sin resolver eso primero, cualquier reporte que cruzara datos de los tres iba a estar mal, aunque la conexión técnica funcionara perfecto.

Las cuatro partes del trabajo

El trabajo tuvo cuatro partes. Primero, la conexión vía API a cada sistema: a Ágora para los datos de venta, a GStock para escandallos, producciones, mermas, stock, compras, albaranes de entrada y facturas, a Cheerfy para los datos de CRM, las campañas de emailing y las ventas de los clientes inscriptos en el programa de fidelización. Segundo, la limpieza de esos datos: unificar cómo se nombra cada producto entre sistemas, normalizar fechas y formatos, y eliminar duplicados. Tercero, los pipelines que mantienen todo esto actualizado de forma automática, para que la información no se desactualice apenas alguien deja de revisarla a mano. Cuarto, una infraestructura de datos propia del negocio (no nuestra), que queda como un activo del cliente, conectada a sus tres sistemas de siempre.

La parte que de verdad importa acá no es la conexión técnica a cada API, eso es relativamente directo. Lo que hace o rompe un proyecto así es la limpieza y la normalización de los datos: sin eso, tienes una conexión que funciona pero que trae información poco confiable, y ningún reporte ni ninguna herramienta construida encima va a servir de nada.

Lo que se puede construir después

Una vez que los datos son confiables y están en un solo lugar, construir cosas nuevas encima se vuelve mucho más simple y rápido. En este proyecto en particular, esa base permitió construir un dashboard con la información del negocio unificada, una herramienta de compras y producción, y conectar esa misma infraestructura a un modelo de IA mediante un servidor MCP, para que el equipo pueda preguntarle en lenguaje natural cómo va el negocio. Contamos esa parte, la del copilot, en un artículo aparte, si te interesa esa mitad de la historia.

Preguntas frecuentes

¿Esto se puede hacer con cualquier sistema, o solo con los que usó este negocio? Se puede hacer con cualquier sistema que tenga una forma de sacarle los datos, ya sea vía API, exportación o algún otro método. Los sistemas puntuales de este caso son un ejemplo, no un requisito.

¿Qué pasa si más adelante se suma un sistema nuevo? Se conecta a la infraestructura ya existente, no hay que rehacer nada desde cero.

¿Necesito un equipo de datos interno para mantener esto funcionando? No, la infraestructura queda construida para mantenerse sola una vez armada; los ajustes puntuales son ocasionales, no un trabajo diario.

Cierre

Si tu negocio también tiene información repartida en varios sistemas que no se hablan entre sí, y te gustaría tener un solo lugar confiable para consultarla, esto es exactamente el tipo de proyecto que armamos como parte de nuestras soluciones de software a medida. Cuéntanos qué sistemas usas hoy y vemos qué tan rápido se puede ordenar esa información.