Qué incluye un contrato de software y qué

En tu empresa ya sabes que la elección del proveedor de software es decisiva; el riesgo de un contrato poco claro puede traducirse en retrasos, sobrecostos o pérdida de propiedad intelectual. En este artículo encontrarás las preguntas que debes hacer, los puntos que deben quedar por escrito y cómo comparar propuestas para evitar sorpresas.

Las preguntas que hay que hacer

• ¿Cuál es el alcance exacto del proyecto?

  • Respuesta esperada: El proveedor detalla funcionalidades, módulos, integraciones con SUNAT y requisitos de facturación electrónica, indicando qué está incluido y qué queda fuera.
  • Señal de alerta: Respuestas vagas como “desarrollaremos lo que necesites” o ausencia de lista de entregables.

• ¿Cómo se estructuran los hitos y los pagos?

  • Respuesta esperada: Cronograma con entregas cada 2‑4 semanas, pago parcial al firmar, otro al validar cada hito y el resto al cierre.
  • Señal de alerta: Pago total al inicio o hitos sin criterios de aceptación claros.

• ¿Qué nivel de soporte y mantenimiento se incluye y por cuánto tiempo?

  • Respuesta esperada: Soporte técnico 8‑x‑5, corrección de bugs críticos durante 6 meses y opciones de mantenimiento evolutivo a partir de la entrega.
  • Señal de alerta: “Soporte bajo pedido” sin tiempo definido.

• ¿Quién será el responsable de la seguridad y el cumplimiento normativo?

  • Respuesta esperada: El proveedor asume la implementación de protocolos de cifrado, pruebas de vulnerabilidad y cumplimiento con la normativa de la SUNAT.
  • Señal de alerta: Delegar la seguridad al cliente sin experiencia.

• ¿Cómo se gestionan los cambios de alcance?

  • Respuesta esperada: Se usa una tabla de control de cambios con impacto en tiempo y costo, aprobada por ambas partes antes de iniciar.
  • Señal de alerta: Cambios “gratuitos” que aparecen después de la fase de desarrollo.

• ¿Qué derechos de propiedad intelectual se transfieren?

  • Respuesta esperada: El cliente recibe la titularidad total del código fuente, licencias y documentación al pago final.
  • Señal de alerta: El proveedor mantiene derechos de explotación o licencia limitada.

• ¿Cuál es la metodología de trabajo?

  • Respuesta esperada: Scrum o Kanban con reuniones de seguimiento cada semana, backlog visible y entregas incrementales.
  • Señal de alerta: Ausencia de metodología o reuniones esporádicas.

Lo que tiene que estar por escrito

Alcance y entregables

• Descripción funcional de cada módulo, diagramas de flujo y criterios de aceptación.
• Listado de documentos: manual de usuario, guía de instalación, arquitectura del sistema.

Plazos

• Calendario con fechas de inicio, revisión de cada sprint (2‑4 semanas) y fecha de entrega final.
• Penalizaciones por incumplimiento de plazos (por ejemplo, reducción del 5 % del pago por cada semana de retraso).

Soporte y mantenimiento

• Horario de atención, canales (ticket, correo, teléfono) y SLA de respuesta (ej. 4 h para incidentes críticos).
• Duración del soporte post‑entrega (mínimo 6 meses) y condiciones para renovar.

Propiedad del código

• Cláusula que transfiera la titularidad del código fuente, bases de datos y documentación al cliente.
• Permiso para que el proveedor reutilice componentes genéricos, pero no el código específico de tu negocio.

Confidencialidad y protección de datos

• Acuerdo de NDA que cubra datos sensibles y cumplimiento con la Ley de Protección de Datos Personales de Perú.
• Responsabilidades en caso de brechas de seguridad.

Condiciones de pago

• Porcentaje inicial (usualmente 30 %), pagos intermedios al aprobar cada hito y 10 % retenido hasta la certificación final.
• Forma de facturación electrónica conforme a SUNAT.

Mecanismo de resolución de conflictos

• Mediación y arbitraje en Lima, con plazos máximos de 30 días para resolver disputas.

Señales de alarma

• El contrato no menciona propiedad del código. El proveedor podría reclamar derechos y bloquear futuras modificaciones.
• Falta de cronograma detallado. Sin hitos claros, el proyecto puede alargarse indefinidamente.
• Soporte descrito como “a convenir”. Significa que después de la entrega podrías quedar sin asistencia.
• El precio está desglosado solo en “costo total”. No sabrás qué parte corresponde a desarrollo, pruebas o mantenimiento.
• El proveedor evita hablar de seguridad. Riesgo de incumplir requisitos de la SUNAT y de la Ley de Protección de Datos.

Cómo comparar dos propuestas distintas

1. Normaliza la unidad de medida – conviértelas a “esfuerzo en semanas” y “costo por semana”. Si una propuesta indica 12 sprints de 3 semanas y la otra 8 sprints de 4 semanas, el total de semanas será comparable.
2. Desglosa los ítems – crea una tabla donde cada fila sea un entregable (p.ej., módulo de facturación electrónica, integración con bancos) y compara la cobertura.
3. Evalúa los riesgos – asigna un puntaje de 1‑5 a cada señal de alarma y suma; la propuesta con menor puntuación tiene menos incertidumbres.
4. Revisa los SLA – compara tiempos de respuesta y penalizaciones; un SLA de 4 h vs 12 h es una diferencia operativa importante.
5. Aplica la regla del 80/20 – identifica cuál propuesta cubre el 80 % de los requisitos críticos con el 20 % de esfuerzo adicional.

En la tabla anterior, la Propuesta B ofrece mayor cobertura y soporte, aunque su plazo sea 4 semanas mayor. La decisión dependerá de la criticidad del tiempo de puesta en marcha frente a la necesidad de cobertura total.

Conclusión

Quien haya leído este artículo ahora tiene una lista concreta de preguntas, sabe qué cláusulas deben estar escritas y reconoce señales de alarma que pueden costar tiempo y dinero. Además, dispone de un método práctico para comparar dos ofertas sin perder detalle. Con esa información, tu empresa podrá firmar un contrato de software sólido, alineado a la normativa peruana y a los objetivos de negocio, minimizando riesgos y asegurando la propiedad total del código.