¿Qué ocurre tras la entrega de la integración?

La integración de sistemas que antes no se hablaban suele quedar como un gran logro al firmar el acta de entrega, pero la realidad empieza a mostrarse cuando el día a día vuelve a la oficina. En este artículo verás qué pasa realmente después de la entrega y cómo evitar que la solución se convierta en un dolor de cabeza.

Lo que empieza el día de la entrega

Nadie habla de los últimos ajustes que se hacen justo antes de firmar: pruebas de carga en horarios pico, revisión de logs de la SUNAT para validar la facturación electrónica y la confirmación de que los usuarios clave ya tienen sus credenciales. En esa fase, el proyecto está todavía bajo la lupa del equipo técnico, pero el cliente ya está pensando en la operatividad.

• Checklist de cierre: validar que los flujos críticos (orden de compra → ERP, envío de comprobantes a SUNAT, sincronización de inventario) se ejecutan sin interrupciones durante al menos 48 horas continuas.
• Transferencia de conocimientos: el equipo de Kovensa entrega una guía de uso de 8 páginas y agenda una sesión de 2 horas con los responsables de TI y de operación.
• Acuerdo de niveles de servicio (SLA): se firma un documento que define tiempos de respuesta (máximo 4 horas para incidentes críticos, 24 horas para incidencias menores) y canales de comunicación.

En ese momento, la ilusión está acompañada de una lista de riesgos que, si no se gestionan, se convierten en problemas reales.

Quién responde cuando algo falla

Una vez que la integración está en producción, surgen preguntas inevitables: ¿quién atiende el ticket? ¿Cuál es el plazo para reparar una caída que impide enviar comprobantes a SUNAT? La respuesta debe estar escrita, no en la cabeza de nadie.

• Responsabilidad del proveedor: Kovensa se compromete a corregir errores de desarrollo y a garantizar la disponibilidad de los conectores durante el periodo de garantía (usualmente 12 semanas). Cualquier ajuste que implique cambios en la arquitectura del ERP o en los módulos de la SUNAT pasa a ser una solicitud de cambio y se cotiza por separado.
• Responsabilidad del cliente: mantener actualizados los certificados digitales de SUNAT, asegurar la conectividad de la red interna y proporcionar accesos a los sistemas críticos en los tiempos acordados.
• Tiempos de respuesta:
  • Incidente crítico (pérdida total de sincronización): respuesta en ≤ 4 horas, solución o solución provisional en ≤ 24 horas.
  • Incidente mayor (errores intermitentes que afectan procesos de facturación): respuesta en ≤ 8 horas, solución en ≤ 48 horas.
  • Incidente menor (problemas de interfaz o reportes): respuesta en ≤ 24 horas, solución en ≤ 5 días hábiles.

Es fundamental exigir por escrito los SLA y, de ser posible, incluir cláusulas de penalización por incumplimiento. Sin esa base contractual, cualquier demora se vuelve negociable y el negocio paga con interrupciones.

• El síntoma, en una frase. La explicación, en dos.
• Los tickets se acumulan sin respuesta. No hay un proceso claro y el equipo de TI pierde tiempo clasificando incidencias.
• Los certificados de SUNAT expiran. La facturación electrónica se detiene y la empresa incurre en multas.

Mantenimiento: qué es y qué no

El término “mantenimiento” se usa a menudo como paraguas, pero en la práctica hay tres niveles distintos que conviene diferenciar:

1. Corrección – Reparar defectos detectados en la fase de garantía. No incluye mejoras funcionales ni cambios de alcance.
2. Mejora – Incorporar nuevas funcionalidades solicitadas por el negocio (por ejemplo, añadir un nuevo canal de venta o un reporte de conciliación). Se planifica como proyecto de mejora y tiene su propio presupuesto.
3. Rehacer – Cuando la arquitectura original ya no soporta los volúmenes de datos actuales (por ejemplo, el ERP supera los 2 millones de transacciones mensuales) y se necesita una re‑arquitectura. Esto no forma parte del mantenimiento y se negocia como un nuevo proyecto.

En el contexto peruano, la normativa de la SUNAT exige que cualquier cambio que altere la generación de comprobantes electrónicos sea notificado y validado. Por ello, el mantenimiento debe incluir una revisión de los esquemas de envío y la re‑validación de los certificados cada 6 meses.

Cómo evitar quedar atrapado

El peor escenario es que, tras la entrega, la empresa quede sin acceso a la lógica que conecta sus sistemas. Para evitarlo, se deben asegurar cuatro pilares:

• Accesos: todos los usuarios técnicos deben contar con credenciales de administrador en los servidores de integración y en la cuenta de desarrollador de SUNAT. Estas credenciales deben entregarse en un documento firmado y guardarse en un repositorio seguro.
• Copias de seguridad: la solución debe incluir backups diarios de los scripts de integración y de la base de datos de logs. Al menos 3 copias almacenadas en ubicaciones diferentes (on‑premise, nube privada y almacenamiento externo).
• Documentación: un manual técnico que detalle arquitectura, flujos de datos, puntos de entrada y salida, y ejemplos de payloads. La documentación debe estar versionada (Git) y accesible para el equipo interno.
• Propiedad del código: el contrato debe especificar que el cliente recibe los derechos de uso y copia del código fuente. Sin esta cláusula, cualquier ajuste futuro dependerá exclusivamente del proveedor.

Al cumplir con estos cuatro puntos, la empresa mantiene el control y puede gestionar cambios menores sin depender de terceros.

Conclusión

Después de la entrega de una integración, lo que realmente determina el éxito es la claridad en responsabilidades, la definición de SLA, la separación entre corrección y mejora, y la garantía de que la empresa posee los accesos y la documentación necesarios. Si se establecen estos mecanismos desde el día uno, la solución seguirá generando valor y no se convertirá en una carga operativa. En resumen, la integración no termina con la firma; comienza con la gestión estructurada de lo que viene después.