Después de la entrega de apps móviles de campo

En el día en que tu equipo recibe la aplicación móvil para equipos de campo, la presión pasa de la implementación a la operación diaria. En este artículo verás qué debes controlar después de la firma, quién responde ante fallas, qué incluye realmente el mantenimiento y cómo evitar quedar atrapado sin acceso ni documentación.

Lo que empieza el día de la entrega

Nadie suele hablar de los últimos minutos antes de firmar el acta de entrega. En ese momento se asume que el proyecto está cerrado, pero en la práctica se activa una fase crítica que dura entre 2 y 4 semanas. Durante ese lapso se realizan:

• Validación de datos en producción: la migración de información de Excel o de sistemas legacy a la nueva aplicación móvil para equipos de campo debe confirmarse con pruebas reales en terreno.
• Capacitación práctica: los supervisores y técnicos necesitan al menos dos jornadas de entrenamiento con casos de uso reales; de lo contrario, el índice de adopción se reduce en un 30 %.
• Ajustes de integración: conectar la app con la aplicación web para gestión de proyectos o con el módulo de facturación electrónica de SUNAT suele requerir ajustes de API que solo se detectan cuando el sistema ya está en vivo.

Aunque la entrega sea formal, la verdadera puesta en marcha se extiende más allá de la firma.

Quién responde cuando algo falla

Una vez que la aplicación está en producción, la responsabilidad no recae exclusivamente en el equipo de TI interno. El contrato debe especificar:

1. Tiempo de respuesta: para incidencias críticas (pérdida de datos o bloqueo total) el proveedor debe responder en menos de 4 horas hábiles. Para problemas menores, el plazo máximo es 24 horas.
2. Niveles de soporte: definir al menos tres niveles – Soporte de primer nivel (consultas de uso), Soporte de segundo nivel (incidencias técnicas) y Soporte de tercer nivel (cambios estructurales). Cada nivel debe estar documentado por escrito.
3. Procedimientos de escalamiento: incluir un árbol de contactos con nombres, cargos y correos institucionales. En Perú, la normativa de protección de datos exige que cualquier brecha sea notificada a la autoridad dentro de 72 horas; el contrato debe contemplar esta obligación.

Exigir estos puntos en el contrato evita sorpresas y permite medir el cumplimiento con indicadores claros (SLAs).

Mantenimiento: qué es y qué no

El término “mantenimiento” se usa de forma genérica, pero en la práctica abarca tres actividades distintas:

• Corrección de errores: solución de bugs reportados por los usuarios. No implica cambios de funcionalidad.
• Mejoras evolutivas: incorporación de nuevas funcionalidades, como una aplicación para vendedores en ruta o la integración con un nuevo módulo de SUNAT.
• Re‑desarrollo: cuando se requiere una re‑arquitectura completa, por ejemplo, migrar de una solución híbrida a una nativa. Esto no forma parte del mantenimiento estándar.

A continuación, una comparativa rápida de lo que suele incluirse en un contrato de mantenimiento frente a lo que queda fuera:

En el contrato también debe quedar claro que el desarrollo de aplicaciones web a medida que se requiera para ampliar la solución móvil será facturado como proyecto independiente, no como parte del mantenimiento.

Cómo evitar quedar atrapado

El riesgo más frecuente después de la entrega es perder el control sobre el código y la infraestructura. Para mitigarlo, asegúrate de que el acuerdo incluya:

• Acceso total al repositorio: Git, Azure DevOps o la herramienta que se haya usado. El acceso debe ser de nivel administrador y debe entregarse al menos 7 días antes de la firma final.
• Copias de seguridad y planes de contingencia: la empresa debe proporcionar al menos dos copias completas del backend (bases de datos, APIs) y del código fuente, almacenadas en un servidor propio o en la nube pública que la empresa ya utilice.
• Documentación exhaustiva: diagramas de arquitectura, manuales de despliegue, guías de configuración y un registro de versiones. Todo debe entregarse en formato PDF y en un repositorio interno accesible.
• Propiedad intelectual clara: el contrato debe establecer que el cliente es titular de todos los derechos del código, incluyendo futuros desarrollos. De lo contrario, cualquier ampliación requerirá renegociar licencias.

Cumplir con estos puntos evita que, cuando el proveedor decida cerrar su oficina o cambie de modelo de negocio, tu empresa quede sin posibilidad de mantener o evolucionar la aplicación.

Conclusión

Después de la entrega de una aplicación móvil para equipos de campo, la prioridad pasa de la instalación a la gestión operativa. Debes:

• Verificar que la puesta en marcha real se complete en 2‑4 semanas.
• Tener contratos con tiempos de respuesta claros y procedimientos de escalamiento.
• Diferenciar entre mantenimiento correctivo, evolutivo y re‑desarrollo, y negociar cada uno por separado.
• Garantizar acceso, copias de seguridad y documentación completa para no depender de terceros.

Con estos pasos, tu empresa podrá transformar la inversión en una herramienta productiva y sostenible, sin sorpresas ni cuellos de botella posteriores.