Después de la entrega: qué ocurre con tu ERP

Cuando el proyecto de ERP se firma y el software llega a tus servidores, la sensación de alivio suele ser breve. La verdadera prueba comienza cuando el sistema pasa de “entregado” a “operativo” y tú, como responsable de la gestión, debes asegurarte de que no se convierta en una carga inesperada. En este artículo verás, paso a paso, qué ocurre después de la entrega, quién debe responder ante fallas, qué incluye un mantenimiento real y cómo proteger la inversión para que tu ERP siga trabajando para ti.

Lo que empieza el día de la entrega

Nadie menciona en la propuesta que, una vez firmado el acta de entrega, el proyecto no termina. Lo que sí se indica es que el software está “listo para usar”, pero la realidad es que el día de la entrega se abre una fase de transición operativa que dura entre 4 y 6 semanas. Durante ese periodo se realizan:

• Capacitación de usuarios clave (aproximadamente 40 horas distribuidas en 2‑3 sesiones).
• Ajustes de parametrización que surgen al probar procesos reales (de 2 a 3 iteraciones).
• Migración de datos finales que, aunque planificada, suele requerir entre 1 y 2 semanas adicionales para validar consistencia.

En muchos casos, el cliente asume que el ERP ya está listo para facturar a SUNAT o para generar órdenes de compra, pero la configuración de los catálogos, los flujos de aprobación y los conectores con la contabilidad pueden necesitar ajustes menores. Ignorar esta ventana de “post‑entrega” genera retrasos posteriores y, sobre todo, deja la puerta abierta a disputas sobre quién está incumpliendo.

Quién responde cuando algo falla

Una vez instalado, la responsabilidad se reparte entre tres actores principales:

1. El proveedor (Kovensa u otro integrador): mantiene la garantía de que el software funciona según lo acordado en el contrato de desarrollo.
2. El cliente interno (tu área de TI o de operaciones): es quien debe gestionar los incidentes cotidianos y escalar los que superen ciertos umbrales.
3. Los usuarios finales: deben reportar los síntomas de forma clara y con la información solicitada.

Tiempos de respuesta estándar

Tipo de incidencia	Tiempo de respuesta inicial	Tiempo máximo de resolución
Crítica (p.ej., bloqueo de facturación SUNAT)	2 horas	24 horas
Alta (errores que impiden procesos clave)	4 horas	3 días hábiles
Media (inconvenientes que tienen solución alternativa)	12 horas	7 días hábiles
Baja (sugerencias de mejora)	24 horas	15 días hábiles

Estos plazos deben estar escritos en el SLA (Acuerdo de Nivel de Servicio) y firmados antes de la entrega. Si el contrato no especifica los tiempos, el cliente tiene derecho a exigir un anexo que los detalle, de modo que cualquier retraso sea medible y no quede a discreción del proveedor.

Qué exigir por escrito

• Procedimiento de escalamiento: número de contactos, roles y horarios de atención.
• Formato de reporte de incidencias: incluye captura de pantalla, descripción paso a paso y datos de prueba.
• Compensación por incumplimiento: penalidades expresas (por ejemplo, crédito de horas de soporte) si los tiempos no se cumplen.

Sin estos elementos, cualquier disputa se vuelve una negociación informal que suele favorecer al proveedor.

Mantenimiento: qué es y qué no

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

1. Corrección de errores (bug fixing): solución de fallos que impiden la operatividad. No incluye cambios en la lógica de negocio.
2. Mejoras (enhancements): incorporación de nuevas funcionalidades solicitadas por el cliente, como un reporte adicional o la integración con un nuevo banco.
3. Re‑desarrollo (rehacer): modificaciones estructurales que alteran la arquitectura del ERP, por ejemplo, migrar de on‑premise a la nube.

Lo que está incluido en un contrato típico de mantenimiento

• Actualizaciones de seguridad: parches mensuales obligatorios para cumplir con la normativa de SUNAT y la protección de datos personales.
• Soporte técnico: cobertura de los niveles de incidencia descritos en el SLA.
• Documentación de cambios: registro de cada corrección o mejora, con versión y fecha.

Lo que no está incluido

• Desarrollo de módulos totalmente nuevos (por ejemplo, un módulo de gestión de activos fijos que no estaba en el alcance original).
• Adaptaciones a cambios regulatorios que requieran re‑configuración profunda (p.ej., una nueva versión de facturación electrónica que implique re‑escritura de interfaces).
• Capacitación adicional más allá de las sesiones iniciales, salvo que se contrate como servicio extra.

Entender esta separación evita que la empresa solicite “todo incluido” y luego se sorprenda con facturas inesperadas.

Cómo evitar quedar atrapado

El riesgo más grande después de la entrega es perder el control técnico y legal del ERP. Para evitarlo, asegúrate de cubrir cuatro áreas clave.

Accesos y credenciales

• Cuentas de administrador: deben ser entregadas al cliente antes del acta de cierre, con contraseñas temporales que el cliente cambie inmediatamente.
• Acceso a repositorios de código (Git, SVN). Si el proyecto es a medida, la empresa debe poseer el repositorio completo, no solo el binario.
• Credenciales de bases de datos: incluye usuario con privilegios de solo lectura para auditorías.

Copias de seguridad y planes de recuperación

• Backup completo al menos semanal y incremental diario. El cliente debe recibir la política escrita y los scripts de restauración.
• Pruebas de recuperación: al menos una simulación cada 3 meses para validar tiempos de restauración (objetivo ≤ 8 horas).

Documentación técnica y funcional

• Manual de usuario actualizado con flujos de trabajo locales (por ejemplo, cómo se genera la declaración de retención para SUNAT).
• Especificación de arquitectura: diagramas de módulos, APIs y puntos de integración con otros sistemas (por ejemplo, sistemas de nómina).
• Registro de cambios (changelog) con versiones, fechas y responsables.

Propiedad intelectual y licencias

• Cláusula de cesión de código: el contrato debe dejar claro que el cliente es propietario del código fuente desarrollado bajo medida.
• Licencias de terceros: lista de componentes de terceros (bibliotecas, motores de base de datos) y sus condiciones de uso.
• Derechos de auditoría: la empresa debe poder auditar el cumplimiento de los SLA sin depender exclusivamente del proveedor.

• El síntoma, en una frase. No puedes acceder al código fuente cuando lo necesitas.
• El síntoma, en una frase. Los backups no se ejecutan y pierdes datos críticos.
• El síntoma, en una frase. El SLA no menciona tiempos de respuesta y el soporte se vuelve impredecible.

Conclusión

Quien haya llegado hasta aquí comprende que la entrega de un ERP es solo el comienzo de una relación contractual y operativa. La clave está en formalizar la transición, definir claramente responsabilidades y tiempos y asegurar la propiedad del código y la documentación. Con estos pilares, tu empresa podrá aprovechar el ERP sin sorpresas, manteniendo la continuidad de procesos críticos como la facturación electrónica a SUNAT y la gestión de compras, y evitando quedar atrapada en dependencias técnicas que drenen recursos.

Después de la entrega, el éxito del ERP depende de acuerdos claros, mantenimiento estructurado y control total de la información.