Caso de uso · 25 de agosto de 2026
Cuánto tarda de verdad conectar un sistema de gestión
La respuesta honesta es que lo que tarda casi nunca es lo técnico. Acá está la línea de tiempo real de una integración, medida día por día sobre un sistema que hoy corre en producción, y qué pasa en cada tramo.
Esto es un caso de uso real, y no es nuestro único tema. Los días que siguen no son una estimación: salen del historial del proyecto, hito por hito. Elegimos contarlo porque es la pregunta que más se hace y la que peor se responde, pero el método es el mismo para cobros, stock, compras o cualquier otro proceso que deje datos.
La línea de tiempo, con fechas
Una cadena de ocho sucursales con el sistema de gestión repartido en varias bases de datos, una por local. El trabajo arrancó el 23 de mayo de 2026 y estas son las fechas de cada hito, con los días transcurridos entre paréntesis:
- 27 de mayo (día 4): el primer dato copiado del sistema de gestión al almacén.
- 11 de junio (día 19): esa copia verificada contra el sistema original y cuadrando al centavo.
- 21 de junio (día 29): la primera sugerencia producida por el sistema.
- 25 de junio (día 33): las sugerencias empezando a llegar al teléfono de quien decide.
- 29 de junio (día 37): arranca la ventana de operación que después se midió.
Copiar los datos llevó cuatro días. Poder confiar en ellos, quince más. Esa proporción es lo que casi nadie cuenta.
Desde esa última fecha el sistema corre todas las noches sin interrupción. Al momento de escribir esto lleva tres meses en producción, y los números que publicamos salieron de ahí.
Qué pasa en cada tramo
Del día 0 al 4: la conexión
Es la parte técnica y es la más corta. Se define el usuario de solo lectura, se abre el camino hacia la réplica y se copia la primera tanda de tablas.
Acá el reloj no lo maneja quien programa: lo maneja quien autoriza. Si el acceso lo da la misma persona que decide, esto son días. Si hay que esperar a un proveedor externo que administra el servidor, pueden ser semanas, y no hay nada del lado técnico que lo acelere.
Del día 4 al 19: probar que la copia dice la verdad
Este es el tramo que sorprende, y el que separa un trabajo serio de una demo. Tener los datos copiados no significa que estén bien: hay que demostrar que lo que dice el almacén coincide con lo que dice el sistema de gestión, hasta el último centavo, y para cada local.
Ahí aparecen las diferencias reales de cualquier operación con varias bases: códigos que cada sucursal escribe distinto, fechas que se cargan con criterios diferentes, movimientos que se registran con retraso. Cada una hay que entenderla antes de seguir, porque una métrica construida sobre datos que no cuadran produce números que parecen buenos y no lo son.
Si este tramo se saltea, el sistema igual arranca y muestra tableros. El problema aparece dos meses después, cuando alguien compara un número contra el sistema de gestión, no coincide, y a partir de ahí nadie vuelve a creerle.
Del día 19 al 29: de los datos a una decisión
Con los datos confiables se construyen las métricas y recién ahí aparece la primera sugerencia: no "acá hay un número raro" sino "movés estas unidades de este local a este otro". La diferencia entre las dos cosas es la mitad del trabajo.
Del día 29 al 37: que llegue a donde se decide
La sugerencia tiene que salir del sistema y aparecer donde la persona ya está, con la respuesta a un toque. Es poco tiempo de trabajo y es el tramo que más define si esto se usa o se abandona.
Lo que realmente demora
Los accesos. Es lo primero que hay que pedir y lo que más cuesta cuando el servidor lo administra un tercero. Conviene arrancar por ahí incluso antes de firmar nada.
La calidad de los datos históricos. Si el sistema guarda fotos diarias de stock, el trabajo arranca con historia. Si hay que reconstruirla, se pierde tiempo y la serie que sale es una inferencia.
Cuántas bases hay. Una operación con una sola base es sensiblemente más rápida que una con una base por sucursal, porque unificar criterios entre bases es la mayor parte del tramo de verificación.
Quién contesta las dudas. Siempre aparecen preguntas que solo alguien de adentro puede responder. Si hay una persona designada, se resuelven en el día; si hay que perseguir a alguien ocupado, cada duda cuesta una semana.
Por qué no prometemos un plazo
Los días de arriba son de un caso, no una garantía. Ese caso tenía varias bases (lo que suma trabajo) y a la vez un acceso rápido y alguien contestando dudas el mismo día (lo que lo acelera). Otra empresa puede tardar la mitad o el doble por razones que se conocen recién al mirar sus datos.
Lo que sí se puede afirmar es la forma de la curva: la conexión es rápida, la verificación es lo que lleva tiempo, y el valor aparece cuando la primera sugerencia llega a donde se decide. Un proveedor que te promete todo funcionando en una semana está saltándose el tramo del medio, que es justamente el que hace que los números sean confiables.
¿Querés saber cuánto tardaría en tu caso?
En una llamada de 20 minutos miramos cuántas bases tenés, quién administra el servidor y qué historia guarda tu sistema. Con eso se puede estimar en serio, que es distinto de prometer. Gratis y sin venta.
Y si tu problema no es este, sirve igual: el mismo trabajo lo hacemos sobre cobros, stock, compras o cualquier proceso que deje datos.
Los números medidos de lo que encontró ese sistema una vez andando están en la página principal.