Las actualizaciones del sistema no se sienten cuando salen bien y se recuerdan un año cuando salen mal. Lo que decide el resultado no es la versión nueva: es la ventana en la que entra, quién la probó antes con movimientos reales y qué pasa si hay que volver atrás.
Un almacén que vive de un sistema tiene que aceptar que ese sistema cambia. Se corrigen errores, se agregan campos, se mueve una pantalla que el equipo tenía memorizada. Las actualizaciones del sistema son la parte del servicio que nadie compra y todos reciben: no se eligen una por una y llegan en el calendario de quien lo opera, no en el del piso.
El problema casi nunca es que algo cambie: es cuándo cambia. Una pantalla nueva un martes tranquilo es una molestia de dos días; la misma un viernes de temporada, con el andén lleno y gente temporal en el piso, cuesta un turno. Ordenarlo no requiere negociar nada complicado: requiere saber qué va a entrar, cuándo entra y qué se hace si sale mal.
Qué tipo de actualizaciones del sistema hay que distinguir
Meterlas todas en la misma bolsa es lo que provoca el susto. Conviene separarlas por el riesgo que traen al piso, que no depende del tamaño del cambio:
- Las correcciones, que arreglan algo que ya estaba mal y casi nunca cambian lo que el operador ve
- Las funciones nuevas, que agregan algo que nadie estaba usando todavía y pueden esperar la ventana que tú elijas
- Los cambios de pantalla, que no agregan nada y sí obligan a reaprender un paso que el equipo hacía de memoria
- Los cambios de regla, que modifican cómo el sistema decide algo —un apartado, una prioridad de surtido— y se notan en el resultado, no en la vista
- Los cambios de integración, que tocan la conexión con la tienda de tu cliente o con el transportista y fallan del lado que no controlas
Las dos que de verdad piden atención son las de pantalla y las de regla. La primera cuesta capacitación y se ve venir. La segunda cambia un resultado sin que nadie lo haya pedido y, si no se avisa, el equipo concluye que el sistema se equivocó y empieza a trabajar por fuera de él.
Cuándo conviene abrir la ventana y cuándo aguantar
La regla que sostiene bien es que el almacén tiene derecho a un calendario. Un cambio entra cuando el piso puede absorber un tropiezo: en los días de menor volumen y a la hora en que no tiene el corte de paquetería encima.
- Fuera de temporada, y fuera de las fechas que tu cliente ya anunció como campaña
- Al principio de la semana, para tener días hábiles por delante si hay que corregir algo
- Con el turno completo enterado, no solo el supervisor que leyó el correo
- Nunca el mismo día en que entra una cuenta nueva o arranca una integración
- Con una ventana de congelamiento declarada por escrito para las semanas críticas del año
La última es la que más pelea genera y la que más sirve. Dejar asentado que en ciertas semanas no entra nada que no sea una corrección urgente le quita al almacén el peor escenario: enterarse de un cambio cuando ya está operando con él.
Una actualización que entra en temporada alta no se evalúa por lo que mejora, sino por lo que costó el día que entró.
Cómo se prueban las actualizaciones del sistema antes de soltarlas al piso
Probar no es leer la lista de cambios. Es correr, en un ambiente separado, los movimientos que tu operación hace todos los días, con datos parecidos a los tuyos:
- Recibir una entrada con lote y caducidad, y confirmar que el dato quedó donde vivía antes
- Surtir una oleada completa y comparar el orden de la hoja con el que el equipo conoce
- Cerrar un embarque con sus bultos y sus medidas, y ver que el documento salga igual
- Generar los cargos de una cuenta y revisar que sigan cuadrando con el movimiento
- Entrar con el usuario de un cliente y confirmar que sigue viendo solo lo suyo
- Pedir el reporte que alguien usa cada semana, no el que nadie abre
Media hora de esto encuentra lo único que importa: si alguno de los pasos que tu almacén repite todo el día cambió de lugar. Y conviene que lo corra alguien del piso: un supervisor detecta en segundos lo que ningún manual describe.
Falta el camino de regreso. Antes de aceptar un cambio hay que saber si se puede volver a la versión anterior, cuánto tarda eso y qué ocurre con lo que se capturó mientras tanto. Si no hay regreso, el cambio no entra en semana de volumen.
Las actualizaciones del sistema que tu cliente no debería notar
Hay una diferencia entre enterar y exhibir. Tu cliente tiene que saber que su portal va a cambiar de aspecto o que un reporte trae una columna nueva; lo que no tiene por qué ver es el nombre de un proveedor de software avisándole de un mantenimiento. Cada aviso así le presenta a un tercero al que podría contratar directo.
Los primeros días después de un cambio también se vigilan distinto. El sistema puede señalar los pedidos que salieron por un camino diferente al habitual, las cuentas cuyos cargos cambiaron de forma o los movimientos que empezaron a tardar más; leer esa lista el primer día es más barato que esperar la queja, y quien decide si algo se corrige o se deja sigue siendo una persona.
Que el aviso de una ventana de mantenimiento salga con tu nombre, que la pantalla nueva llegue ya con tu logotipo puesto y que lo que cambió quede anotado en la misma bitácora donde vive el resto de la operación, es lo que separa a un sistema propio de uno prestado: es lo que se le pide a un WMS marca blanca con IA para 3PL en México cuando la operación no puede detenerse para recibir una versión nueva.
Si hoy los cambios llegan de sorpresa, hay dos cosas que se piden por escrito y ordenan casi todo: aviso con anticipación de lo que va a cambiar en pantalla o en regla, y una ventana de congelamiento en las semanas que tú decidas.