Después de la reunión de levantamiento

Tras la reunión de levantamiento de requerimientos, la mayor parte de los gerentes y dueños de empresas se preguntan qué sucede cuando el proyecto se firma y el equipo de desarrollo entrega la solución. La entrega es solo el inicio de una fase crítica para asegurar que la inversión genere el retorno esperado. En este artículo encontrarás los pasos concretos que debes seguir, los compromisos que debes exigir por escrito y las prácticas que evitan que tu empresa quede atrapada en un software incompleto o inaccesible.

Lo que empieza el día de la entrega

Ese día la emoción se mezcla con la incertidumbre. El equipo de desarrollo muestra la aplicación, los usuarios hacen pruebas y se firman los últimos documentos. Lo que nadie cuenta antes de firmar es que la entrega incluye más que el código: implica la transferencia de conocimiento, la puesta en marcha de los entornos productivos y la definición de los criterios de aceptación que servirán para medir el retorno de la digitalización.

• Entorno productivo listo: verifica que los servidores, bases de datos y configuraciones de red estén replicados exactamente como en la fase de pruebas. En Perú, la integración con la SUNAT y la facturación electrónica suele requerir certificados digitales que deben estar activos antes de la puesta en marcha.
• Plan de capacitación ejecutado: aunque no sea un artículo sobre capacitación, el día de la entrega debe quedar constancia de cuántas horas de entrenamiento se entregaron y a quiénes, para que el personal pueda usar el sistema sin depender del proveedor.
• Checklist de aceptación: revisa que todos los indicadores para medir la digitalización estén disponibles en el dashboard del sistema (tiempo de proceso, reducción de errores, ahorro de papel, etc.). Si alguno falta, solicita su inclusión antes de cerrar el proyecto.
• Documentación firmada: la entrega debe incluir manuales de usuario, diagramas de arquitectura y, sobre todo, los acuerdos de propiedad que garanticen que tu empresa posee los códigos fuente y bases de datos.

Quién responde cuando algo falla

Una vez que el software está en producción, la responsabilidad de resolver incidencias recae en el proveedor, pero solo bajo los términos que hayas negociado. Es fundamental que estos acuerdos estén claros y por escrito.

• Tiempo de respuesta: define un SLA (Service Level Agreement) que establezca tiempos máximos de respuesta según la criticidad del problema. Por ejemplo, incidentes críticos (caída del ERP) deben atenderse en 2 horas, mientras que mejoras menores pueden esperar 48 horas.
• Canales de comunicación: exige un ticketing system con seguimiento y registro de cada solicitud. Evita depender de correos electrónicos que se pierden.
• Responsables internos: designa un “owner” de la solución dentro de tu empresa, quien será el punto de contacto único con el proveedor. Esto acelera la priorización y evita que se deleguen tareas a personal que no conoce el contexto.
• Exigencias documentales: solicita un informe de cada incidente que incluya causa raíz, acciones correctivas y plan de prevención. Estos informes son esenciales para medir el retorno de la digitalización, pues permiten cuantificar el tiempo perdido y el impacto financiero.

Mantenimiento: qué es y qué no

El mantenimiento suele confundirse con soporte técnico, pero son conceptos diferentes.

• Corrección (bug fixing): se trata de eliminar errores que impiden el funcionamiento normal. Está incluido en la mayoría de los contratos de garantía y no genera costos adicionales.
• Mejora (enhancement): son solicitudes de nuevas funcionalidades o ajustes que no estaban en el alcance original. Suelen requerir un presupuesto y un plazo adicional.
• Rehacer (re‑engineered): implica una reescritura parcial o total del código, generalmente porque la arquitectura original no soporta la escalabilidad deseada. Este tipo de trabajo nunca está cubierto por la garantía y debe negociarse como un proyecto nuevo.

En el contexto peruano, el mantenimiento también incluye la actualización obligatoria de la normativa de facturación electrónica cada año. Asegúrate de que el contrato contemple estas actualizaciones sin costos extra, ya que la SUNAT puede sancionar a empresas con documentos no válidos.

Cómo evitar quedar atrapado

Muchos directivos descubren demasiado tarde que, aunque el software funciona, no pueden acceder a él sin la intervención del proveedor. Para prevenirlo, controla los siguientes elementos desde el inicio:

• Accesos y credenciales: exige la entrega de todas las contraseñas, claves SSH y tokens de API antes de la firma final. Cambia esas credenciales inmediatamente después de la entrega.
• Copias de seguridad: solicita al menos dos copias completas del entorno productivo (una en la nube y otra on‑premise) y verifica que los backups se ejecuten automáticamente.
• Documentación completa: incluye diagramas de arquitectura, scripts de despliegue, lista de dependencias y versiones de librerías. Esta información permite que otro equipo de desarrollo (incluso interno) pueda dar mantenimiento si el proveedor desaparece.
• Propiedad del código: el contrato debe especificar que el código fuente, la base de datos y los derechos de uso son propiedad de tu empresa. En Perú, la Ley de Protección de Datos Personales exige que el responsable del tratamiento (tu empresa) tenga control total sobre los datos que procesa el software.

Conclusión

Quien ha llegado hasta aquí sabe que la verdadera prueba de la digitalización comienza después de la entrega. Exigir un plan de puesta en marcha detallado, definir SLA claros, distinguir entre corrección y mejora, y asegurar la propiedad total del código son pasos imprescindibles para que tu inversión genere el retorno esperado. Con estos controles, tu empresa podrá medir el retorno de la digitalización de forma objetiva, evitar sorpresas costosas y mantener la operación alineada con la normativa peruana.