ERP lento en oficinas remotas: cómo diagnosticar la latencia

Si el ERP se siente lento en una oficina remota, primero identifica qué operación tarda y en qué tramo se acumula la espera. Comprar más Internet o ampliar el servidor sin esa evidencia puede dejar intacto el problema.

Esta guía propone un diagnóstico por sede, usuario y tarea. No requiere desactivar protecciones ni cambiar la red a ciegas. El objetivo es llegar al equipo de soporte con una comparación reproducible y decidir qué merece probarse.

“Está lento” puede describir problemas distintos

Antes de medir, acuerda el inicio y el final de una acción: desde pulsar “Consultar” hasta ver los resultados, desde confirmar “Guardar” hasta recibir confirmación, o desde teclear hasta ver el carácter. No mezcles esos tiempos en una sola cifra.

Si una operación de escritura queda sin confirmación, no hagas clic repetidamente: podrías duplicarla. Comprueba el estado con el procedimiento del ERP y usa datos de prueba autorizados para reproducir. Una investigación no debe introducir un problema contable o de inventario.

Dibuja la arquitectura antes de escoger métricas

• ERP por escritorio remoto: el puesto transmite entrada y recibe pantalla; aplicación y datos pueden estar cerca entre sí o no.
• Cliente instalado en cada oficina: el cliente puede intercambiar múltiples solicitudes con un servicio remoto. Importan las dependencias y el soporte del fabricante para esa topología.
• ERP web: intervienen navegador, servicio web, autenticación, API y datos. Un tiempo de carga puede incluir recursos e integraciones diferentes.

Escribe dónde corre cada componente y qué destino estás midiendo. Probar un sitio público cualquiera no mide necesariamente el trayecto del ERP. Si usas Access, la guía específica de arquitectura de Access explica por qué compartir su archivo por WAN no equivale a ejecutar la aplicación cerca de sus datos.

Mide la experiencia y utiliza la red como evidencia complementaria

La métrica principal debe ser una tarea que importe al negocio. Acompáñala de contexto para que soporte pueda relacionarla con sus registros. Una captura que dice “CPU 20%” tomada diez minutos después no explica una espera anterior.

1. Define una operación segura. Misma consulta, filtros, conjunto de prueba y resultado esperado. Evita carga artificial en producción sin autorización.
2. Registra horario y zona. Comprueba que los relojes de los sistemas que correlacionarás sean coherentes.
3. Repite de forma controlada. Anota cada duración y si es la primera ejecución o una repetición; la caché puede alterar el resultado.
4. Haz una comparación contemporánea. Otra sede o puesto autorizado con la misma operación y carga semejante es mejor control que un recuerdo de la semana pasada.
5. Separa hechos de hipótesis. “La sede A tardó 12 segundos” es un dato; “es el router” necesita una prueba adicional.

Qué dice cada medida y dónde termina su alcance

RTT es tiempo de ida y vuelta al destino que responde. Ayuda a describir el trayecto, no el tiempo completo de una consulta. La pérdida y variación temporal también pueden importar, pero el método, periodo y destino deben quedar registrados. La ausencia de respuesta a ICMP no demuestra por sí sola que la aplicación esté caída.

Un trazado de ruta permite ver los saltos que responden. Microsoft explica que algunos equipos no contestan a paquetes con TTL agotado en su documentación de TRACERT. Por tanto, un asterisco o un salto aislado con respuesta tardía no bastan para atribuir la lentitud del ERP a ese punto. Contrasta el destino final y los datos de la aplicación.

Ancho de banda y latencia no son sinónimos. La guía de red de Microsoft para sesiones remotas relaciona necesidades de ancho de banda con carga, resolución y frecuencia de actualización. Sus recomendaciones tienen condiciones de pérdida y escenario; no deben convertirse en “tantos Mbps por cualquier usuario de ERP”. Prueba las tareas y pantallas que realmente usarás.

Para un entorno RDS compatible, el contador User Input Delay mide cuánto espera la entrada en la cola antes de que la aplicación la recoja, y reporta el máximo del intervalo. No es el RTT ni el retardo completo que ve la persona. Puede ayudar a separar una cola de procesamiento de otros tramos, con interpretación del administrador.

Si el motor es SQL Server, la metodología oficial para consultas lentas distingue ejecución y esperas. Duración, CPU, lecturas y esperas orientan el análisis de la consulta concreta. No deduzcas automáticamente “falta CPU” porque el informe tarda ni “falta disco” porque hay una espera; el tipo de espera y el contexto importan.

Mediana, percentiles y muestras: evita cifras con falsa precisión

Para una primera bitácora pequeña, conserva todos los tiempos, el mínimo, máximo y mediana. Describe cuántas observaciones tomaste y durante cuánto tiempo. No presentes un P99 calculado con tres intentos como diagnóstico fiable de la experiencia de una oficina.

Si más adelante comparas P95 o P99, fija el método de cálculo, la población y el periodo. No mezcles apertura, guardado e informes, ni agregues sedes con comportamientos distintos sin mostrarlas por separado. Un promedio general puede ocultar a la oficina que sufre.

Bitácora para copiar al ticket de soporte

Completa una ficha por operación y periodo. No incluyas contraseñas, identificadores fiscales, datos de clientes ni documentos productivos. Usa códigos internos anónimos que el equipo autorizado pueda relacionar por un canal seguro.

Ficha de observación y comparación

• Sede y puesto de prueba: ______
• Fecha, intervalo y zona horaria: ______
• ERP, versión y modalidad de acceso: ______
• Operación exacta, inicio y final del cronómetro: ______
• Datos de prueba, filtros y resultado esperado: ______
• Duraciones individuales y número de muestras: ______
• Primera ejecución o repetición; usuarios simultáneos: ______
• Equipo, conexión y destino medido: ______
• RTT/pérdida/variación, herramienta y periodo si se midieron: ______
• Control comparable en otra sede o puesto: ______
• Cambios recientes conocidos, sin atribuir causalidad: ______
• Registro o error exacto anonimizado: ______
• Resultado confirmado de la operación y siguiente prueba: ______

Este formato suele ahorrar más tiempo que enviar solamente una captura de una prueba de velocidad. También permite detectar qué dato falta, en lugar de abrir discusiones entre proveedores sin una referencia común.

Caso hipotético: dos oficinas y un informe lento

Ejemplo didáctico, no resultado de un cliente. Dos sedes ejecutan el mismo informe de prueba con filtros equivalentes dentro del mismo periodo. Se anota que la aplicación está en una sesión remota. Los valores siguientes son inventados para mostrar cómo razonar, no objetivos recomendados.

El informe tarda casi lo mismo aunque el RTT observado sea distinto. Eso no demuestra que la red nunca afecte, pero hace poco convincente comprar un enlace más rápido como primera respuesta a este síntoma. La siguiente comprobación es correlacionar el informe con los tiempos de aplicación y motor, manteniendo constantes los filtros.

Supón que soporte encuentra una espera repetida en la consulta durante esos intervalos. Esa coincidencia orienta una hipótesis; todavía debe identificar su causa y probar una corrección controlada. No basta con que la gráfica del servidor “se vea alta”.

Ahora imagina un segundo síntoma: solo en B el tecleo se retrasa a cierta hora, mientras el informe conserva sus tiempos. Se abre una investigación distinta de puesto, sesión y trayecto de B. Un problema puede coexistir con otro; arreglar la consulta no acredita haber arreglado la sede.

A quién escalar y con qué evidencia

Solicita que cada equipo responda sobre su tramo con el mismo intervalo. “Nuestro servicio funciona” no cierra la investigación si nadie ha comparado la operación completa. Tampoco corresponde culpar a otro proveedor sin evidencia reproducible.

Cambios solo con hipótesis, autorización y retorno

Una prueba bien planteada dice qué se espera mejorar y qué observación la refutaría. Por ejemplo: “Si la saturación del enlace de la sede es relevante, la operación y las medidas del trayecto deben mejorar de forma repetible en un periodo controlado con esa carga ausente”. La alternativa debe ser segura, aprobada y comparable, no una interrupción improvisada de tareas ajenas.

1. Escribe la hipótesis y la métrica de éxito de la tarea, junto con límites de error y efectos que no deben empeorar.
2. Registra configuración inicial y responsable. Elige piloto o ventana autorizada.
3. Cambia una variable cuando sea viable; si cambian varias, documenta que no podrás atribuir el efecto a una sola.
4. Repite la comparación con carga y datos similares, incluyendo primera ejecución y repeticiones.
5. Verifica funcionalidad, seguridad y operaciones relacionadas. Si no mejora o aparece un perjuicio, aplica el retorno acordado.
6. Conserva los resultados y observa un periodo representativo antes de declarar resuelto el problema.

No desactives inspección, antivirus, controles de acceso ni cifrado para “acelerar” el ERP. Que un tráfico esté cifrado no hace innecesarios los controles. Tampoco publiques RDP o la base de datos en Internet como atajo. Cualquier cambio de seguridad requiere evaluación y autorización específicas.

QoS, SD-WAN, codecs, almacenamiento más rápido o ampliar recursos pueden ser opciones en un diseño concreto, no recetas universales. DNS y TTL tampoco son aceleradores generales de consultas ya establecidas. Exige que la propuesta relacione el cambio con evidencia del tramo afectado y con requisitos del fabricante.

IA para ordenar evidencia, no para tocar la red sola

Una IA puede agrupar una bitácora anonimizada por sede y tarea, identificar campos ausentes y proponer preguntas para soporte. Pídele separar “observado”, “hipótesis” y “prueba pendiente”, y comprobar los cálculos con los datos originales.

No entregues credenciales, trazas con datos personales ni información interna a servicios no aprobados. No aceptes cambios de firewall, registro, políticas o base de datos generados automáticamente sin revisión técnica. Un resumen convincente sigue sin ser una medición.

El valor del soporte está en cerrar la investigación

Un socio experimentado puede coordinar proveedor de Internet, plataforma y ERP, conservar la línea base y verificar que la mejora se mantiene. Eso puede ahorrar horas del equipo y evitar compras por ensayo y error. No equivale a garantizar cero latencia ni a prometer que cualquier sistema se corregirá en unas horas.

Si evalúas Cobalt Blue Web u otro proveedor, pide un alcance claro: quién mide, qué accesos necesita, qué entrega, qué cambios están incluidos y quién valida el resultado. Compara el coste total del diagnóstico y la atención, no solo la mensualidad del servidor.

¿Un servidor más cercano siempre hará más rápido el ERP?

Puede reducir una parte del trayecto, pero no elimina una consulta ineficiente, un bloqueo ni una integración lenta. Compara la tarea completa antes y después en un piloto autorizado.

¿Cuándo puedo decir que quedó resuelto?

Cuando el síntoma definido mejora conforme al criterio acordado, en condiciones representativas y sin romper otras funciones. Documenta qué se probó y qué quedó fuera; una sola ejecución rápida no demuestra estabilidad general.

Empieza por una sola tarea importante: completa su bitácora, añade un control comparable y entrega ambos al soporte. Tendrás una base útil para decidir el siguiente paso, con nosotros o con el proveedor que elijas.