La respuesta corta
Cuando el almacén funciona sobre SAP, la app móvil no sustituye nada: se cuelga de lo que ya hay. Y la primera decisión, la que más condiciona el proyecto, es que la app nunca habla directamente con el ERP.
Entre medias va tu backend, que es quien negocia con el sistema del cliente, absorbe sus tiempos, traduce su modelo y protege a la app de sus cambios. Sin esa capa, la versión publicada en la tienda queda atada al calendario del equipo de SAP — y ese calendario no lo mueves tú.
La segunda cosa que hay que aceptar pronto: el camino crítico no es el desarrollo. Son los accesos, los entornos y las ventanas de despliegue del cliente.
La pregunta que revela el escenario
No preguntes «¿tenéis API?». Pregunta esto:
¿Qué integraciones con sistemas externos tenéis hoy en producción, y cómo funcionan?
La respuesta te dice qué sabe hacer esa organización, qué está aprobado y qué camino ya tiene recorrido. Un cliente que ya expone servicios para otro proveedor puede darte uno más; un cliente cuya única integración es un fichero nocturno te está diciendo, sin decirlo, cuál va a ser tu proyecto.
De ahí salen los escenarios habituales, de mejor a peor para el calendario:
- Servicios ya expuestos que puedes consumir, con documentación y un entorno de pruebas.
- Plataforma de integración en medio, mantenida por otro equipo. Tu interlocutor pasa a ser ese equipo.
- Intercambio por mensajería o ficheros, con sus horarios de proceso.
- Nada todavía. Hay que pedir desarrollo del lado del cliente, y eso entra en su cola de prioridades.
En los escenarios 3 y 4, la parte móvil puede ser la mitad del esfuerzo y una fracción pequeña del calendario. Decirlo en la propuesta evita la conversación incómoda del mes cuatro.
Qué diseñar en tu lado
Capa anticorrupción. Tu modelo es tuyo. El del ERP es suyo, y lleva años de decisiones que no vas a cambiar. En medio, un traductor explícito. Si los códigos de almacén, las unidades de medida y los estados del ERP se filtran hasta las pantallas, cualquier cambio suyo te obliga a publicar versión.
Datos maestros en caché, movimientos en tiempo real. El catálogo de artículos, ubicaciones y tipos de movimiento cambia poco: se sincroniza y se guarda. Lo que hay que consultar al vuelo es el estado y la confirmación. Esa separación reduce muchísimo la dependencia de la red.
Idempotencia y confirmación diferida. El operario confirma un movimiento y la red falla. Ese movimiento tiene que poder reenviarse sin duplicarse, y el sistema tiene que poder decir si se aplicó. Es el mismo patrón de cola de eventos que en reparto: está desarrollado en app de reparto sin cobertura.
Modo degradado explícito. El ERP tendrá ventanas de mantenimiento. La app debe distinguir «no hay stock» de «no hemos podido consultar el stock», y el operario tiene que verlo.
El terminal manda sobre la interfaz
En almacén, el dispositivo no es un móvil de oficina: suele ser un terminal industrial con lector integrado. Eso cambia el diseño más que ninguna decisión de backend, y está desarrollado en leer códigos con un terminal Zebra desde Flutter.
Lo esencial: el flujo lo marca el disparo del lector, no el toque en pantalla. Si después de cada lectura hacen falta dos toques, el operario buscará la manera de saltárselos — y la encontrará.
Lo que se subestima al planificar
- Los accesos. Usuarios de servicio, permisos y entornos. Semanas, no días, y depende de gente que no está en tu proyecto.
- Los datos de prueba. Un entorno con inventario representativo es imprescindible para probar de verdad, y conseguirlo es un trámite en sí mismo.
- Las ventanas de despliegue. En un almacén operativo no se despliega cuando tú quieres.
- La formación y el turno de noche. El piloto se hace con operarios reales, en su turno, con su presión.
- El interlocutor técnico del cliente, que lleva el sistema entero encima y tiene tu proyecto entre otros veinte.
Antes de estimar
- ¿Qué integraciones externas hay hoy en producción y cómo funcionan?
- ¿Hay entorno de pruebas con datos representativos, y en cuánto se concede?
- ¿Qué movimientos tiene que poder registrar la app, exactamente?
- ¿Qué pasa si el sistema central no responde en mitad de una operación?
- ¿Qué terminal usa la flota y quién lo administra?
La tercera parece obvia y casi nunca está contestada por escrito. Y de la cuarta depende si el proyecto es una app conectada o un sistema con estado propio, que son dos presupuestos distintos.
Es el trabajo de fondo en apps de logística y transporte: la herramienta de campo funciona cuando encaja con el sistema que ya gobierna el almacén, no cuando pretende reemplazarlo.
