TL;DR
Un marco de due diligence para evaluar proveedores de software: propiedad intelectual, control de hitos, discovery técnico y cláusulas de salida.
Cómo evaluar un proveedor de software a la medida antes de firmar el contrato
Su empresa lleva seis meses usando un sistema de gestión de inventario desarrollado por un proveedor externo. El negocio crece, necesitan integrar el módulo con su ERP y conectar una nueva sucursal. Cuando llaman al proveedor, descubren que el equipo original ya no existe, que el código fuente nunca fue entregado formalmente y que la única persona que conoce la arquitectura del sistema trabaja ahora en otro país. El contrato no contempla ninguna de estas situaciones.
Este escenario ocurre con más frecuencia de lo que se reporta en las empresas dominicanas. No porque los proveedores sean necesariamente malintencionados, sino porque la evaluación precontractual se hizo de manera superficial: se compararon precios, se revisaron portafolios y se firmó. La due diligence técnica y comercial quedó fuera del proceso.
Este artículo le ofrece un marco práctico para evaluar un proveedor de software a la medida antes de comprometer presupuesto y tiempo operativo.
Por qué la evaluación de proveedores es diferente en software a la medida
Comprar software empaquetado tiene sus complejidades, pero comprar desarrollo a la medida implica riesgos de otra naturaleza. Usted no está adquiriendo un producto terminado; está contratando un proceso de creación cuyo resultado depende de decisiones técnicas, organizacionales y contractuales que se toman durante la ejecución.
Esto significa que evaluar al proveedor antes de firmar es, en realidad, evaluar su capacidad de gestionar incertidumbre, comunicar avances reales y entregar algo que usted pueda mantener, modificar o transferir en el futuro.
Las cuatro dimensiones críticas de la due diligence
1. Propiedad intelectual y entrega de código
Esta es la dimensión que más se ignora y la que más consecuencias tiene. Antes de firmar, debe tener respuesta clara a estas preguntas:
- ¿A quién pertenece el código fuente una vez entregado?
- ¿Se entrega el repositorio completo con historial de versiones?
- ¿Qué sucede si el contrato se rescinde antes del término?
- ¿Qué bibliotecas o componentes de terceros se utilizarán, y bajo qué licencias?
Un contrato que no especifica la propiedad del código le deja en una posición de dependencia permanente con el proveedor, independientemente de cuánto haya pagado.
2. Control de hitos y gobierno del proyecto
El software a la medida sin hitos medibles tiende a convertirse en proyectos que "están al 80%" durante meses. Evalúe si el proveedor propone:
- Entregables concretos por fase, no solo porcentajes de avance
- Criterios de aceptación escritos antes de iniciar cada módulo
- Un proceso formal de revisión y aprobación por parte del cliente
- Mecanismos de escalamiento cuando hay desacuerdos técnicos
3. Discovery técnico previo al contrato
Desconfíe del proveedor que le da una propuesta económica detallada sin haber hecho preguntas técnicas profundas. Un proveedor serio debe realizar un proceso de discovery antes de cotizar: entender sus integraciones existentes, su infraestructura, el volumen de datos, los usuarios concurrentes y las restricciones regulatorias del negocio.
Si la propuesta llega en menos de 48 horas con un precio fijo para un sistema complejo, eso es una señal de alerta.
4. Cláusulas de salida y continuidad del servicio
Ningún contrato de software debería carecer de cláusulas que definan qué ocurre cuando la relación termina, sea por voluntad propia o por incumplimiento. Debe negociar:
- Entrega de código, documentación y credenciales de acceso
- Período de soporte de transición pagado
- Penalidades por incumplimiento de hitos críticos
- Procedimiento para transferir el sistema a otro proveedor
Tabla comparativa: proveedor maduro vs. proveedor con riesgos
| Criterio | Proveedor con procesos maduros | Señales de alerta |
|---|---|---|
| Propuesta económica | Basada en discovery previo con alcance documentado | Precio fijo inmediato sin preguntas técnicas |
| Propiedad del código | Transferencia explícita al cliente desde el inicio | Ambigüedad contractual o retención del código |
| Gestión de cambios | Proceso formal con impacto estimado en tiempo y costo | "Lo hacemos sin problema" sin análisis |
| Equipo asignado | Nombres, roles y disponibilidad definidos | Equipo genérico presentado solo en reunión de venta |
| Documentación técnica | Parte del entregable con criterios de aceptación | Promesa verbal de documentar "al final" |
| Cláusulas de salida | Contempladas explícitamente en el contrato | Ausentes o redactadas en favor exclusivo del proveedor |
Checklist de evaluación precontractual
Antes de firmar cualquier contrato de desarrollo a la medida, verifique estos puntos:
- El contrato especifica que el código fuente pertenece al cliente al momento de cada entrega
- Existe un plan de proyecto con hitos, entregables y criterios de aceptación por escrito
- Se realizó un discovery técnico documentado como parte de la propuesta
- El proveedor nombró al equipo técnico que ejecutará el proyecto
- Hay cláusulas de penalidad por retrasos significativos
- El contrato incluye un protocolo de entrega final con lista de activos
- Se definió un período de garantía post-lanzamiento con alcance específico
- Las integraciones con sistemas de terceros están incluidas en el alcance o explícitamente excluidas
- Se acordó un mecanismo de control de cambios con impacto en tiempo y presupuesto
- El proveedor tiene referencias verificables de proyectos similares en complejidad
Cómo debe aproximarse un socio tecnológico al problema
Un proveedor de software a la medida que opera como socio estratégico, y no como simple ejecutor, se distingue por cómo aborda la conversación inicial. En lugar de preguntar cuánto quiere pagar, pregunta qué problema de negocio está tratando de resolver.
El proceso correcto comienza con un discovery estructurado que no se cobra como un favor, sino que se entiende como parte del proceso de alineación. En esa etapa, el proveedor debe identificar restricciones técnicas no evidentes, dependencias con sistemas existentes y riesgos de alcance que podrían afectar el presupuesto.
Un socio tecnológico también propone gobierno activo: reuniones de seguimiento con agenda técnica, tableros de avance accesibles para el cliente y documentación que crece junto con el proyecto, no al final. Esta diferencia en mentalidad tiene consecuencias prácticas enormes cuando surgen los problemas inevitables de cualquier proyecto de desarrollo.
Finalmente, un buen socio tecnológico le habla de los riesgos antes de que ocurran. No para asustarlo, sino porque esa transparencia es la base de una relación que dura más allá del primer proyecto.
Qué medir en los primeros 90 días
Una vez iniciado el proyecto, los primeros tres meses son el mejor indicador de cómo se comportará el proveedor durante toda la ejecución. Establezca estos KPIs desde el inicio:
Cumplimiento de hitos: porcentaje de entregables entregados en la fecha acordada. Un proveedor saludable debe mantener un cumplimiento igual o superior al 80% en esta etapa.
Tiempo de respuesta a observaciones: cuántos días tarda el equipo en responder a correcciones o preguntas técnicas. Lo aceptable varía por complejidad, pero más de cinco días hábiles en observaciones normales es una señal de capacidad insuficiente.
Tasa de retrabajos por módulo: cuántas veces debe revisarse un entregable antes de ser aceptado. Una tasa alta indica problemas en la comprensión del requisito o en la calidad del desarrollo.
Actualización del repositorio: frecuencia con la que el código se sube al sistema de control de versiones. Si el repositorio no se actualiza con regularidad, el equipo no está trabajando con buenas prácticas.
Alineación de alcance: número de solicitudes de cambio recibidas vs. las anticipadas en el discovery. Si el volumen de cambios supera significativamente lo proyectado, el discovery inicial fue insuficiente.
Errores frecuentes y cómo mitigarlos
Error: Firmar un contrato de precio fijo sin alcance detallado. Mitigación: Exija un documento de alcance funcional aprobado por ambas partes antes de firmar. Si el proveedor no puede producirlo, el proyecto no está listo para ejecutarse.
Error: Asumir que "código entregado" significa código documentado y usable. Mitigación: Defina en el contrato qué constituye una entrega válida: código en repositorio, documentación técnica mínima y pruebas ejecutables.
Error: Delegar toda la supervisión técnica al proveedor. Mitigación: Asigne un responsable interno que participe en las revisiones de hitos y tenga criterio para evaluar los entregables, aunque no sea desarrollador.
Error: Ignorar la estabilidad del equipo del proveedor. Mitigación: Pregunte explícitamente sobre la rotación del equipo y establezca contractualmente que cualquier cambio de personal clave requiere notificación y período de transición.
Error: No negociar las cláusulas de salida porque "la relación va bien". Mitigación: Las cláusulas de salida se negocian precisamente cuando la relación va bien. Incluirlas no expresa desconfianza; expresa profesionalismo.
La evaluación de un proveedor de software a la medida no es un trámite burocrático: es la inversión de tiempo más rentable que puede hacer antes de comenzar un proyecto tecnológico. La due diligence correcta le permite seleccionar con criterio, negociar con fundamento y ejecutar con menos sorpresas.
Habla con Valego: info@valegos.com