Guía para IT en contratos de servicios digitales
Contratos de prestación de servicios digitales: cómo definir el alcance del entregable
Un entregable claro reduce cambios, acelera la aceptación y limita disputas. Aquí tienes un enfoque práctico para redactar y revisar SOW, anexos y criterios de aceptación.
En contratos de prestación de servicios digitales, el “alcance del entregable” no es una frase bonita. Es el conjunto de resultados medibles que el cliente recibe, junto con las reglas que determinan cuándo están completos.
Para equipos IT, esto afecta a licencias, cumplimiento, plazos, y también a cómo se documenta la prestación del servicio. A continuación, te proponemos una estructura de redacción y una lista de verificación para que tu SOW, anexos y criterios de aceptación tengan dientes.
1) Mapa del entregable (qué se entrega, en qué formato y con qué límites)
Empieza por separar tres capas:
- Resultado: el efecto final que el cliente obtiene (por ejemplo, una funcionalidad, un módulo, una integración operativa).
- Entregable material: artefactos concretos (código, ejecutables, configuración, documentación, informes de pruebas).
- Alcance de trabajo: qué actividades incluye el proveedor (desarrollo, configuración, soporte a pruebas, despliegue, formación).
En la práctica, el SOW funciona mejor cuando el entregable se define con:
- Lista de entregables por hito.
- Formato y ubicación (repositorio, entorno, paquetes, versiones, estructura de carpetas, etc.).
- Dependencias del cliente (accesos, datos, infraestructura, licencias que ya tiene el cliente).
- Límites explícitos (lo que queda fuera, lo que es “best effort”, y lo que requiere orden de cambio).
Cuando el alcance incluye componente software, define también versiones y cómo se mide la “compatibilidad” (por ejemplo, versiones soportadas, APIs objetivo, y navegador/entorno).
2) Criterios de aceptación (cómo se comprueba que está “hecho”)
Los criterios de aceptación deben convertirse en una lista verificable. Evita frases genéricas como “conforme a requisitos” si no están definidos.
Una buena pauta es combinar criterios de:
- Funcionalidad: casos de uso, historias de usuario, flujos end-to-end.
- Calidad: rendimiento, estabilidad, tolerancia a errores, seguridad básica.
- Integración: conectividad con sistemas del cliente, interfaces, contratos de API.
- Documentación: que el cliente reciba guías y evidencias suficientes para operar o mantener.
Modelo de redacción: “Se considerará aceptado el hito cuando el cliente ejecute el set de pruebas definido en el anexo y no identifique incidencias de severidad alta o crítica, registradas dentro del periodo de verificación.”
Además, fija:
- Periodo de verificación y canal para reportar incidencias.
- Mecanismo de resolución (correcciones, re-pruebas, reentrega).
- Regla de aceptación tácita si procede, con plazos y forma de notificar rechazo.
3) Gestión de cambios (cómo se evita el “alcance infinito”)
En proyectos digitales, el cambio es normal. El problema aparece cuando el cambio entra sin coste, sin calendario y sin trazabilidad.
Para gestionar cambios de forma contractual, incorpora:
- Procedimiento de solicitud (quién propone, cómo se documenta, qué información mínima incluye).
- Evaluación de impacto (tiempo, coste, dependencias, riesgos).
- Acta u orden de cambio que actualice SOW, anexos y/o cronograma.
- Regla de no afectación: no se asume cambio aceptado hasta formalizar la orden de cambio.
Este punto suele proteger a ambas partes. Reduce fricción cuando el cliente pide variaciones y te obliga a valorar impacto con rigor.
4) Evidencias y documentación (qué deja el proveedor además del “producto”)
Los entregables no son solo binarios. En servicios digitales, los anexos y evidencias determinan si el cliente puede operar y demostrar cumplimiento.
Incluye, según aplique:
- Plan y resultados de pruebas (casos ejecutados, evidencias y trazabilidad).
- Guías de despliegue y procedimientos de rollback.
- Inventario técnico (componentes, versiones, configuración relevante).
- Documentación de uso y criterios para mantenimiento.
- Transferencia de conocimiento (sesiones, materiales, responsables y fechas).
Si el entregable incluye elementos bajo licenciamiento, asegúrate de que la documentación acompañe el uso y las restricciones aplicables, para evitar “sorpresas” en auditorías y aceptaciones.
5) Escenarios típicos de riesgo (y cómo prevenirlos con el alcance)
Estos son casos recurrentes en disputas contractuales. No hace falta citar tecnicismos, basta con que el alcance los cubra o los excluya claramente.
“Funciona en nuestro entorno, pero no en el vuestro”
Define entornos soportados, dependencias, y responsabilidad del cliente en accesos e infraestructura. Adjunta versiones objetivo.
“No era parte del entregable, pero lo hiciste”
Aclara límites y procedimiento de cambio. Si se realiza trabajo fuera de alcance, se documenta como orden de cambio.
“El cliente rechaza sin justificar”
Fija requisitos de notificación de incidencias y umbrales de severidad. Sin evidencia, no debería reiniciarse el ciclo.
“Falta documentación para operar”
Incluye entregables de documentación dentro del alcance de aceptación, con formatos y nivel mínimo de detalle.
Checklist final para tu SOW
- Cada hito tiene lista de entregables y formato.
- Existen criterios de aceptación medibles y un periodo de verificación definido.
- El mecanismo de cambios está documentado y no se acepta tácitamente sin orden.
- Hay evidencias y documentación para operar, mantener y auditar.
- Las dependencias del cliente y los límites quedan explícitos.
Si quieres contrastar cláusulas, revisa también otras guías de la serie sobre licencias y anexos. Un buen alcance del entregable no es un documento único, es un sistema de decisiones que se mantiene a lo largo del proyecto.