¿Qué sigue tras entregar la intranet corporativa?

La entrega de un portal de clientes y proveedores marca el fin de un proyecto, pero para la gerencia es solo el comienzo de una nueva fase. En los próximos minutos conocerás qué controles y acuerdos debes tener claros para que la inversión siga generando valor.

Lo que empieza el día de la entrega

Ese momento en que el equipo de desarrollo firma el acta de entrega suele ir acompañado de un alivio palpable, pero también de una serie de incógnitas que rara vez se discuten en la reunión de cierre.

• Validación final: aunque el cliente haya aprobado la prueba de aceptación, es fundamental que la gerencia exija un documento de “cierre técnico” que detalle versiones, configuraciones y los módulos que quedaron fuera del alcance.
• Capacitación práctica: no basta con una presentación de 30 minutos. La capacitación debe programarse en al menos dos sesiones de 2 horas cada una, una para el personal de operaciones y otra para el área de soporte.
• Plan de transición: la entrega incluye la transferencia de credenciales, claves de API y acceso a los entornos de pruebas y producción. Todo debe quedar registrado en un inventario de accesos.
• Acuerdo de nivel de servicio (SLA): antes de firmar, revisa que el contrato especifique tiempos de respuesta (por ejemplo, 4 horas para incidentes críticos y 24 horas para los de menor prioridad) y penalizaciones en caso de incumplimiento.

En Perú, la normativa de SUNAT obliga a que cualquier sistema que gestione facturación electrónica conserve los registros por al menos 5 años y permita su exportación en formato XML. Ese requisito debe estar presente en la documentación entregada.

Quién responde cuando algo falla

Una vez que el portal está en producción, la responsabilidad no desaparece. Lo que sí cambia es el canal por el cual se gestionan los problemas.

• Soporte del proveedor: el contrato debe indicar claramente quién será el punto de contacto (gerente de proyecto, equipo de soporte técnico) y cuáles son sus horarios de atención. En la práctica, la mayoría de los proveedores peruanos ofrecen soporte en horario laboral (08:00‑18:00) con opción de cobertura 24/7 bajo costo adicional.
• Tiempos de respuesta: exige que cada tipo de incidente tenga un plazo de resolución. Por ejemplo, una caída total del portal (incidente crítico) debe resolverse en 8 horas, mientras que una solicitud de ajuste menor (incidente de baja prioridad) puede tener 5 días hábiles.
• Registro de incidentes: solicita que el proveedor use una herramienta de tickets con historial accesible para tu equipo. Así podrás medir cumplimiento y generar reportes trimestrales.
• Exigencias por escrito: cualquier cambio que implique re‑arquitectura o ampliación del alcance debe quedar formalizado en una orden de cambio (Change Request) que incluya estimación de esfuerzo, impacto en los SLA y fecha de entrega.

Si el proveedor no cumple, el contrato debe contemplar cláusulas de rescisión o compensación económica. En el contexto peruano, la Ley de Protección al Consumidor permite reclamar por servicios no prestados según lo pactado.

Mantenimiento: qué es y qué no

El término “mantenimiento” se usa a menudo como paraguas para cubrir tres actividades distintas:

1. Corrección de errores – Solución de bugs que aparecen después de la puesta en marcha. No debe generar cargos adicionales si el error está dentro del alcance original.
2. Mejoras evolutivas – Incorporación de nuevas funcionalidades solicitadas por el negocio (por ejemplo, un módulo de auto‑registro para proveedores). Estas sí requieren un presupuesto extra y deben gestionarse mediante una orden de cambio.
3. Re‑diseño o refactorización – Cuando el código necesita una reescritura profunda por obsolescencia tecnológica. Este tipo de trabajo se considera un proyecto nuevo, no mantenimiento.

Una plataforma de intranet corporativa suele incluir integraciones con sistemas de recursos humanos, contabilidad y la SUNAT. El mantenimiento debe contemplar actualizaciones de esas API cada vez que el ente regulador publique cambios.

En la práctica, el esfuerzo de mantenimiento se distribuye en un 15 % del tiempo total del proyecto durante el primer año, y disminuye a un 5 % anual a partir del segundo año, siempre que no se añadan mejoras significativas.

Cómo evitar quedar atrapado

El mayor riesgo después de la entrega es perder el control sobre lo que se ha construido. Aquí tienes los pasos clave para mantener la soberanía tecnológica:

• Accesos completos: asegura que tu equipo tenga cuentas de administrador en todos los entornos (desarrollo, pruebas, producción). No delegues únicamente al proveedor.
• Copias de seguridad: establece una política de backups diarios y guarda al menos una copia offline. Verifica la restauración cada trimestre.
• Documentación viva: exige que el entregable incluya diagramas de arquitectura, manuales de usuario y scripts de despliegue. La documentación debe estar versionada en un repositorio interno (Git, por ejemplo).
• Propiedad del código: el contrato debe dejar claro que el código fuente, bases de datos y configuraciones son propiedad de tu empresa. Si el proveedor usa componentes de terceros, solicita las licencias y los derechos de uso.
• Plan de salida: define un procedimiento de “exit strategy” que detalle cómo migrar a otro proveedor o a un equipo interno, con plazos (por ejemplo, 8 semanas de transición) y entregables.

Cumplir con estos puntos evita que la plataforma se convierta en un “cajón negro” del que sólo el proveedor puede sacar información.

Conclusión

Después de la entrega de tu portal de clientes y proveedores, la gerencia debe enfocarse en tres pilares: claridad contractual, estructura de soporte y control de la propiedad. Asegurando acuerdos de SLA bien definidos, un plan de mantenimiento que separe corrección de mejora, y una documentación completa con accesos y backups, tu empresa podrá aprovechar al máximo la inversión y evitar sorpresas costosas. En el entorno peruano, cumplir con los requisitos de SUNAT y la normativa de consumo refuerza la seguridad jurídica del proyecto, garantizando que la plataforma siga siendo una herramienta estratégica y no un riesgo operativo.