Lo que realmente quiebra los proyectos por contrato
Casi ningún conflicto en un proyecto de Salesforce comienza con la pregunta "¿cuánto cuesta?". Comienza con la pregunta "¿está terminado?". El proveedor cree que el producto ha sido entregado; la organización cree que no es utilizable. Ambas partes tienen razón desde su propia perspectiva, porque nadie definió de antemano qué se consideraría completado.
De aquí se deriva un principio que guía todas las cláusulas de este artículo: un buen contrato no protege a su parte en un conflicto, lo previene.
Las doce cláusulas
1. Definición de aceptación para cada entregable
La cláusula más importante. Cada entregable requiere un criterio observable: no "pantalla de gestión de clientes", sino "un usuario con el perfil X puede ejecutar el escenario Y y obtener el resultado Z, según lo definido en los criterios de aceptación aprobados".
Redacción recomendada: un período de prueba definido a partir del momento de la entrega, al final del cual el cliente aprueba o detalla por escrito las deficiencias. El silencio más allá del período se considera una aprobación, una cláusula que protege al proveedor y genera disciplina en el cliente.
2. Mecanismo para solicitudes de cambio
Define quién está autorizado a solicitar, quién evalúa, en cuánto tiempo y a qué tarifa. La tarifa debe establecerse en el momento de la firma y no cuando surja la necesidad.
3. Dependencia bidireccional
La mayoría de los contratos definen qué sucede cuando el proveedor se retrasa y no definen qué sucede cuando el cliente se retrasa. Resultado: cuando la organización demora una aprobación, el proveedor la absorbe, y luego la traslada a través de solicitudes de cambio.
Redacción equilibrada: el cronograma está condicionado a una respuesta definida del cliente (tiempo de aprobación, disponibilidad del propietario del proceso, entrega de datos), y un retraso excesivo desplaza el hito mediante notificación escrita.
4. Propiedad del código, configuración y documentación
Separación entre el producto dedicado y los componentes genéricos del proveedor, con una licencia de uso ilimitada en el tiempo para los componentes genéricos, que no está condicionada a la continuación de la relación.
5. Documentación como entregable vinculante
La documentación que no se define como un entregable con un criterio de aceptación, no se escribirá o se escribirá en la última semana. Defina un mínimo: decisiones arquitectónicas, modelo de datos, mapeo de integraciones, procedimientos operativos.
6. Garantía y corrección de defectos
Un período definido y una definición clara de lo que es un defecto frente a un cambio. Una definición funcional: una discrepancia entre el comportamiento real y los criterios de aceptación aprobados es un defecto.
7. Personal clave
Nombres, porcentaje de asignación, preaviso para el reemplazo y nivel profesional equivalente con la aprobación del cliente.
8. Accesos, entornos y seguridad de la información
Quién obtiene acceso a qué entornos, por cuánto tiempo, qué sucede con los accesos al finalizar y cómo se manejan los datos reales en entornos que no son de producción.
9. Cumplimiento de requisitos regulatorios y de privacidad
Ubicación del almacenamiento, manejo de información personal, derecho de auditoría e informe de incidentes de seguridad. En organizaciones reguladas, esta es una cláusula que requiere una redacción específica y no una plantilla.
10. Puertas de decisión y puntos de salida
Derecho a detenerse al finalizar un hito definido, con un acuerdo de pago preestablecido. Una cláusula así reduce el riesgo para ambas partes, por lo que un buen proveedor no se opondrá.
11. Transferencia de conocimiento
No "capacitación", sino: número de horas, a quién, sobre qué y cuál es el resultado. Es preferible que la transferencia se distribuya a lo largo del proyecto y no se concentre al final.
12. Finalización y salida
Una lista de lo que se entrega, formato, período de solapamiento, tarifa por horas de soporte para la transferencia. Esta es la cláusula que nadie quiere discutir en el momento de firmar, y es precisamente por eso que vale la pena insistir en ella entonces.
Mapa de riesgos: qué previene cada cláusula
| Cláusula | Fallo que previene | Costo de la ausencia |
|---|---|---|
| Definición de aceptación | Discusión sobre "terminado" | Retraso en el pago y en la puesta en marcha |
| Solicitudes de cambio | Fijación de precios en momentos de necesidad | Aumento incontrolado de costos |
| Dependencia bidireccional | Acusación mutua de retraso | Desplazamiento del cronograma sin transparencia |
| Propiedad y documentación | Dependencia del proveedor | Alto costo al cambiar de proveedor |
| Personal clave | Reemplazo silencioso del equipo | Pérdida de contacto y conocimiento |
| Garantía | Discusión defecto vs. cambio | Doble pago por corrección |
| Salida | Negociación desde una posición de debilidad | Costo de transferencia imprevisto |
Redacciones a evitar
- "El proveedor realizará el trabajo con la profesionalidad habitual" — esto no puede aplicarse sin un criterio.
- "Las partes acordarán en adelante sobre..." — cada cláusula de este tipo es un conflicto futuro en espera.
- "Sujeto a la plena cooperación del cliente" — sin definir qué es esto, es una protección unilateral.
- "El entregable se entregará al finalizar el proyecto" — sin definir qué es la finalización.
- Calendario de pagos según fechas de calendario en lugar de según la aceptación.
Ejemplo ilustrativo: cadena minorista
El escenario es hipotético y está destinado a la ilustración. Una cadena firmó un SOW que incluía "migración de datos de clientes desde un sistema existente". La suposición de la organización era que la migración incluía la limpieza de duplicados; la suposición del proveedor era que transfería lo que le era entregado.
En la práctica, se transfirieron cientos de miles de registros con duplicados. Ambas partes leyeron la misma frase y la entendieron de manera opuesta. No había una línea en el contrato que definiera qué se consideraba un registro válido.
La corrección realizada en los acuerdos posteriores de esa cadena fue breve: un anexo que definía un umbral de calidad medible para la carga – tasa de registros que pasan la validación, reglas de identificación de duplicados y quién aprueba. Este anexo reemplazó docenas de horas de discusión.
Qué verificar antes de firmar
- Cada entregable de la propuesta aparece en el SOW con un criterio de aceptación.
- Toda suposición presentada en la propuesta aparece como una suposición explícita en el contrato.
- El cronograma de pagos está vinculado a la aceptación.
- Existe una cláusula de salida y una cláusula de transferencia de conocimiento.
- La definición de defecto es lo suficientemente clara como para resolver un caso límite.
Lo que se acordó en la comparación de propuestas pero no se incluyó en el contrato, simplemente no existe. El proceso de comparación en sí se detalla en la guía de comparación de propuestas de Salesforce, y la base para redactar los requisitos se establece ya en el documento de solicitud de propuesta, como se detalla en la guía de RFP.
La conexión con la selección del proveedor
Algunas de las cláusulas de aquí también sirven como herramientas de evaluación: un proveedor que se opone a una cláusula sobre la propiedad de la documentación o a una cláusula de salida, le está diciendo algo sobre su modelo de operación. La combinación de la evaluación profesional con la disposición contractual se puntúa conjuntamente en la Guía de Scorecard para la selección de proveedores de Salesforce, y los criterios amplios para la verificación de la empresa se resumen en la guía para elegir una empresa de implementación de Salesforce. La adecuación del tipo de contratación al tipo de servicio adquirido se detalla en la guía de servicios de Salesforce.
Siguiente paso
Tome el SOW que tiene delante y marque cada lugar donde dice "se entregará" o "se realizará" sin especificar cómo se sabrá que esto ha ocurrido. Cada una de estas marcas es un conflicto potencial, y cada una cuesta cinco minutos de arreglar ahora mismo.