Metodología de trabajo con proveedor: Qué

En un entorno donde la digitalización es obligatoria y la SUNAT exige facturación electrónica, la relación con el proveedor de software puede convertirse en una traba costosa. Si tu empresa está a punto de firmar un contrato, este artículo te muestra qué preguntar antes de decidir para proteger tu inversión y mantener el control técnico.

Las preguntas que hay que hacer

• ¿Cuál es el modelo de licenciamiento del código fuente?

  • Respuesta esperada: El código se entrega bajo licencia completa para tu empresa, sin cláusulas de exclusividad que impidan su uso interno o externo.
  • Señal de alerta: El proveedor menciona “licencia de uso limitada” o “solo acceso a través de su plataforma”.

• ¿En qué repositorio y con qué herramientas gestionarán el código?

  • Respuesta esperada: Uso de repositorios públicos o privados (GitHub, GitLab) con acceso de administrador para tu equipo.
  • Señal de alerta: No se menciona control de versiones o se propone una herramienta propietaria sin acceso.

• ¿Qué procesos de calidad y pruebas se aplican?

  • Respuesta esperada: Integración continua, pruebas unitarias y de aceptación con métricas claras (porcentaje de cobertura >80%).
  • Señal de alerta: Falta de pruebas automatizadas o dependencia de pruebas manuales sin documentación.

• ¿Cuál es el plan de entrega y los hitos de desarrollo?

  • Respuesta esperada: Road‑map con entregas cada 2‑3 semanas (sprints) y revisión de funcionalidades al final de cada sprint.
  • Señal de alerta: Promesas de “entrega única al final del proyecto” o fechas sin desglose.

• ¿Cómo gestionan los cambios y el alcance del proyecto?

  • Respuesta esperada: Uso de un backlog gestionado en Jira o similar, con proceso de control de cambios aprobado por ambas partes.
  • Señal de alerta: Cambios ilimitados sin control de costos o alcance.

• ¿Qué soporte y mantenimiento se incluyen después de la entrega?

  • Respuesta esperada: Soporte técnico 8‑5, 5 días, con SLA de respuesta <24 h y garantía de corrección de bugs críticos por al menos 6 meses.
  • Señal de alerta: Soporte “a convenir” o sólo bajo contrato adicional.

• ¿Cómo manejan la seguridad y el cumplimiento con la normativa peruana (por ejemplo, la SUNAT)?

  • Respuesta esperada: Encriptación de datos, auditorías de seguridad y cumplimiento con la normativa de facturación electrónica.
  • Señal de alerta: Ignora la normativa local o delega la responsabilidad al cliente sin pruebas.

Lo que tiene que estar por escrito

1. Alcance del proyecto – descripción detallada de módulos, integraciones (por ejemplo, con la plataforma de la SUNAT) y entregables.
2. Cronograma – fechas de inicio, sprints y entrega final, expresado en semanas (ejemplo: 12 semanas para MVP, 8 semanas para fase 2).
3. Entregables – código fuente completo, documentación técnica, diagramas de arquitectura y manuales de usuario.
4. Propiedad del código – cláusula que transfiera la titularidad total a tu empresa al momento de la aceptación final.
5. Soporte y mantenimiento – nivel de servicio, tiempos de respuesta y duración del periodo de garantía.
6. Condiciones de pago – hitos vinculados a entregas verificadas, evitando pagos adelantados sin resultados.
7. Confidencialidad y protección de datos – alineación con la Ley de Protección de Datos Personales de Perú.

Señales de alarma

• El contrato no menciona propiedad del código. Significa que el proveedor podría retener derechos y bloquear futuras modificaciones.
• Plazos ambiguos o “aproximados”. Indica falta de planificación y riesgo de retrasos de semanas o meses.
• Falta de métricas de calidad. Sin pruebas unitarias ni cobertura, el producto será frágil y costará más mantenerlo.
• El proveedor insiste en usar su propia plataforma sin acceso al código. Refuerza la dependencia y dificulta la migración.
• Condiciones de soporte bajo contrato separado. Podrías terminar pagando doble por mantenimiento.

Cómo comparar dos propuestas distintas

1. Normaliza la información – coloca ambas ofertas en una tabla con los mismos criterios: alcance, plazos, entregables, SLA, propiedad del código.
2. Evalúa la consistencia – verifica que los hitos y entregables coincidan con lo que realmente necesitas; si una propuesta incluye funcionalidades que no usarás, descarta el exceso.
3. Analiza el riesgo de dependencia – asigna una puntuación (1‑5) a cada propuesta según la claridad de la propiedad del código y el acceso al repositorio.
4. Considera el coste de transición – estima el tiempo que tu equipo necesitará para asumir el proyecto si cambias de proveedor; una oferta con mayor documentación y capacitación reducirá ese tiempo.
5. Revisa los SLA – compara tiempos de respuesta y garantías; una diferencia de 12 h en respuesta a incidentes críticos puede impactar la operatividad de tu empresa.

Conclusión

Al cerrar un contrato con un proveedor de software, la metodología de trabajo con un proveedor se define por la claridad de las preguntas que haces, la precisión de lo que queda por escrito y la capacidad de detectar señales de alarma. Normaliza y compara las propuestas, y asegura que la propiedad del código y los SLA estén plasmados en el contrato. Así tu empresa mantendrá el control técnico, evitará dependencia excesiva y podrá escalar sus sistemas sin sorpresas.

Una decisión informada se basa en preguntas concretas, cláusulas claras y una comparativa objetiva.