Caso de cliente · Manufactura y distribución
Sustituir un ERP de 35 años sin parar los pedidos
Un operador estadounidense que gestiona pedidos, producción, almacén y cobros para marcas de calzado dependía de un ERP escrito hacia 1990: medio millón de líneas de código que nadie se atrevía a tocar. Lo mapeamos, reconstruimos la operación como plataforma multiempresa sobre NetSuite y auditamos el sistema de almacén que otro proveedor había dejado a medias.
En cifras
35+
años de reglas de negocio mapeadas antes de escribir una línea
13
módulos que siguen el flujo físico, de la line sheet a la nota de crédito
~50
transacciones bastaban para tumbar el código de almacén heredado; la auditoría lo vio primero
Para quién es
Dueños y directores de empresas de distribución o fabricación cuya operación depende de un sistema que nadie se atreve a tocar, y que necesitan saber qué implica de verdad sustituirlo antes de comprometerse. Te llevas la secuencia que seguimos, mapear, auditar, decidir, pilotar, y los fallos concretos que encontramos en el código heredado, para que hagas las mismas preguntas al tuyo.
Ideas clave
- Mapear las reglas antes de elegir la herramienta. Treinta y cinco años de lógica vivían en código FoxPro y en la memoria de la gente. Leer el código proceso a proceso es lo que hizo segura la sustitución.
- El trabajo heredado se audita, no se amplía. El sistema de almacén abandonado tenía un techo duro en unas 50 transacciones. Encontrarlo primero convirtió un desarrollo sin final en una decisión con alcance.
- Una plataforma arriba y un sistema de registro debajo. Ni un ERP nuevo ni un NetSuite personalizado: una capa escrita para el mayorista de calzado, con NetSuite haciendo lo que hace bien.
- El orden es parte del diseño. Una marca piloto entró primero mientras el sistema heredado seguía funcionando. Por eso no se paró ningún pedido.
- Publicamos lo que podemos demostrar. Las horas ahorradas, las tasas de error y los tiempos de ciclo todavía se están contando, y se añadirán cuando el cliente los tenga.
¿Qué encuentras al abrir un ERP de 35 años?
Una operación que funciona de punta a punta sobre código de 1990
La empresa está entre las marcas de calzado y las tiendas que les compran: crea los catálogos de temporada, recibe pedidos a mano y por EDI, coordina fábricas en Asia y Europa, recibe contenedores en dos almacenes, asigna inventario, libera envíos, factura y cobra a través de un factor de crédito. Cada uno de esos pasos pasaba por un ERP construido en FoxPro hacia 1990: más de 500 programas, más de 600 tablas por compañía y décadas de reglas de negocio que no existían en ningún otro sitio.
El problema era que funcionaba
El sistema funcionaba. Ese era el problema. Gestionaba el EDI con grandes cadenas minoristas, el inventario de varios almacenes, el empaquetado y las etiquetas de transportista, y varias sociedades, y nadie podía decir con seguridad qué se rompería si algo cambiaba. Alrededor había crecido el andamio de siempre: hojas de cálculo, hilos de correo con fábricas y transitarios, una herramienta de BI y una instancia de NetSuite que llevaba las finanzas pero no la operación.
La verdadera pregunta del dueño
Un proveedor anterior había empezado un sistema de gestión de almacén sobre NetSuite y se había ido. La pregunta del dueño no era «qué software compramos». Era: cómo salimos de esto sin parar los pedidos, y cuánto de lo que ya pagamos merece conservarse.
Leer el negocio y el código de la misma manera
Entender llevó más tiempo del que nadie quería. Documentamos el negocio tal como es: los actores (marcas, tiendas, fábricas, almacenes, transitarios, transportistas, agentes de aduanas, el factor de crédito), los tipos de pedido, los puntos de aprobación y las excepciones. Después leímos el código heredado de la misma manera, relacionando programas y tablas con los procesos a los que servían, para que lo que viniera después conservara las reglas y no solo las pantallas.
Construir, comprar o reconstruir: ¿qué decidimos, y por qué?
Una plataforma para el sector, con NetSuite debajo
La decisión fue construir una capa operativa privada y multiempresa para el negocio, con NetSuite como sistema de registro por debajo. Ni un ERP nuevo ni un NetSuite personalizado: una plataforma escrita para el comercio mayorista de calzado, con NetSuite haciendo lo que hace bien.
Lo que encontró la auditoría del sistema heredado
El sistema de almacén heredado pasó por una auditoría antes de añadirle una sola línea. Encontramos código que funcionaba y también riesgos serios: devoluciones modeladas fuera de las transacciones nativas de NetSuite, scripts por lotes que agotaban los límites de la plataforma con unas 50 transacciones, consultas construidas concatenando texto y roles de integración con muchos más permisos de los necesarios.
| Hallazgo | Por qué importa |
|---|---|
| Devoluciones modeladas fuera de las transacciones nativas de NetSuite | El sistema de registro no las contiene |
| Scripts por lotes que agotaban los límites de la plataforma con unas 50 transacciones | Se rompen con el volumen de un día normal |
| Consultas construidas concatenando texto | Un riesgo de inyección |
| Roles de integración con muchos más permisos de los necesarios | Más acceso del que usa la integración |
La recomendación, con precio
La recomendación fue reconstruirlo como una SuiteApp versionada y orientada a eventos: el escáner envía la operación, una cola la valida y la registra, NetSuite la procesa en segundo plano y cada error queda anotado y se puede reintentar. Pusimos por escrito las horas y las semanas que costaría. El cliente decidió con los números delante.
Por qué el orden importaba tanto como la forma
El orden importaba tanto como la forma. El despliegue se diseñó por partes que el cliente pudiera ver y usar, con una marca como piloto, mientras el sistema heredado seguía funcionando.
¿Qué construimos exactamente?
Una plataforma en trece módulos que siguen el flujo físico: producto y line sheets, clientes, pedidos, producción, recepción, asignación, liberación, envío, devoluciones y abonos, pagos, informes y notificaciones.
- Backend multiempresa con permisos por rol y autenticación en dos pasos, para que cada marca vea su operación y el operador las vea todas.
- Contratos de API tipados y un backlog de QA que valida el flujo completo, del catálogo a la liberación, antes de que un módulo entre en producción.
- NetSuite como fuente de verdad de pedidos y datos maestros, por debajo de la plataforma.
La operación de la marca piloto entró primero: catálogo, pedidos, producción, recepción, asignación y liberación funcionan sobre la plataforma, y el sistema heredado siguió en marcha mientras se movían.
¿Qué ha aguantado desde la puesta en marcha?
Operaciones, finanzas y almacén trabajan sobre un solo sistema con un solo juego de permisos; las aprobaciones que antes viajaban por correo ahora dejan rastro. La migración no ha parado un pedido.
Las reglas de negocio que vivían solo en código de 1990 y en la cabeza de algunas personas están documentadas, probadas y en manos del cliente. La auditoría del almacén convirtió un desarrollo sin final en una decisión con alcance, coste y orden.
La parte medible que más le importa al cliente todavía se está contando: horas ahorradas, tasas de error, tiempos de ciclo. Las publicaremos cuando el cliente las tenga.
Preguntas que hacen los lectores
Equipo de Customer Success
Itaca Technologies
¿Tu pregunta no está aquí?
Escríbela tal cual. La lee el equipo que hace el trabajo y te responde con el siguiente paso concreto.