Qué debe exigirle a un proveedor de integración de sistemas críticos

La mayoría de las evaluaciones de proveedor se concentran en dos cosas: el precio y las referencias. Ambas importan, pero ninguna de las dos le dice cómo va a responder ese proveedor el día que algo falle.

Estas doce preguntas sí. Están agrupadas en cuatro áreas, y el criterio para evaluarlas es el mismo en todas: la especificidad de la respuesta importa más que su contenido. Un proveedor que dice “depende del caso, en general entre cuatro y ocho semanas según el volumen de datos” sabe de lo que habla. Uno que dice “nos adaptamos a sus tiempos” está evadiendo.

Capacidad técnica

1. ¿Han integrado antes con este sistema específico? No con “sistemas similares”. Con este. Si la respuesta es no, pregunte cuánto tiempo presupuestaron para aprenderlo y quién asume el costo si toma más.

2. ¿Qué pasa si el sistema de origen no expone una API? Muchos sistemas legados no la tienen. La respuesta revela si el proveedor tiene experiencia real: lectura directa a base de datos, archivos intermedios, capa de middleware — cada opción tiene consecuencias distintas de riesgo y mantenimiento.

3. ¿Cómo manejan los cambios de esquema del lado del otro sistema? Los sistemas de terceros cambian sin avisarle a usted. Si la integración se rompe cada vez que el proveedor del core publica una versión, el costo de mantenimiento es mayor al de construcción.

Operación

4. ¿Quién opera la integración una vez entregada? Si la respuesta es “su equipo”, pregunte qué documentación y capacitación incluye. Si es “nosotros”, pregunte bajo qué contrato y a qué costo recurrente.

5. ¿Cómo se detecta que la integración dejó de funcionar? La respuesta correcta menciona monitoreo activo y alertas. La respuesta preocupante es “el usuario reporta”. Una integración que falla en silencio produce inconsistencia de datos durante días antes de que alguien lo note.

6. ¿Qué pasa con las transacciones que fallan? Reintento automático, cola de pendientes, notificación a un responsable. Si no hay una respuesta clara, los registros fallidos simplemente se pierden.

7. ¿Cuál es el tiempo de respuesta ante un incidente crítico, por escrito? Por escrito. Un compromiso verbal de “atención inmediata” no es exigible.

Contrato

8. ¿El SLA distingue niveles de severidad? Un SLA único para todo tipo de incidente es un SLA mal diseñado. Un error de formato en un reporte y una caída del canal transaccional no pueden tener el mismo tiempo de respuesta.

9. ¿Qué consecuencia tiene incumplir el SLA? Si no hay ninguna, el SLA es una declaración de intenciones. Las penalizaciones no compensan el daño, pero alinean incentivos.

10. ¿Quién es el punto de contacto y qué pasa si esa persona no está? Los proyectos críticos no pueden depender de la disponibilidad de una persona. Pida el esquema de escalamiento.

Salida

11. Si terminamos la relación, ¿qué nos llevamos? Código fuente, documentación de arquitectura, credenciales, datos en formato utilizable. Defínalo antes de firmar, no cuando ya haya conflicto.

12. ¿Qué tan difícil sería que otro proveedor continúe este trabajo? Es la pregunta más incómoda y la más reveladora. Un proveedor seguro de su trabajo responde con normalidad. Uno que construye dependencia se pone a la defensiva.

Cómo interpretar las respuestas

No busque respuestas perfectas. Busque consistencia entre lo que dicen y lo que proponen en la oferta. Si aseguran monitoreo activo pero la propuesta económica no incluye una línea de soporte recurrente, algo no cuadra.

Y desconfíe de la ausencia total de advertencias. Un proveedor con experiencia real en integraciones críticas le va a decir dónde están los riesgos del proyecto antes de que usted pregunte. El que solo tiene buenas noticias todavía no ha hecho el trabajo suficiente para conocer las malas.