Problema
Un término de referencia débil enumera actividades, perfiles y programas informáticos, pero no explica qué decisión debe mejorar ni cómo se aceptará el resultado. Esto produce propuestas difíciles de comparar, productos ambiguos y discusiones tardías sobre datos, método o alcance.
Para estudios y servicios de análisis, el punto de partida debe ser la necesidad pública. La herramienta, la técnica y el formato se justifican después.
Datos y Fuentes
El marco general vigente es la Ley N.° 32069, Ley General de Contrataciones Públicas. El OECE mantiene una versión actualizada de la Ley y su Reglamento y un buscador de interpretación normativa.
El Reglamento establece que el requerimiento de servicios se plasma en términos de referencia. La versión, el procedimiento y las reglas aplicables deben confirmarse con el órgano encargado de las contrataciones y la asesoría jurídica de la entidad antes de convocar.
Método
Diez bloques para estructurar el requerimiento
| Bloque | Pregunta que debe responder | Señal de calidad |
|---|---|---|
| 1. Necesidad | ¿Qué problema público u organizacional origina el servicio? | Describe una condición observable y la decisión que está detenida. |
| 2. Antecedentes | ¿Qué ya se intentó, midió o documentó? | Distingue evidencia disponible, supuestos y vacíos. |
| 3. Objetivos | ¿Qué cambio debe producir el servicio? | Usa verbos verificables y evita confundir objetivo con actividad. |
| 4. Alcance | ¿Qué territorio, población, periodo y unidades cubre? | Declara inclusiones, exclusiones y nivel de desagregación. |
| 5. Preguntas | ¿Qué debe poder responder el análisis? | Cada pregunta se conecta con un usuario y una decisión. |
| 6. Datos | ¿Qué fuentes existen y quién autoriza su uso? | Precisa acceso, calidad, identificadores, privacidad y seguridad. |
| 7. Método | ¿Qué estándar mínimo debe cumplir el análisis? | Exige trazabilidad y robustez sin imponer una técnica innecesaria. |
| 8. Productos | ¿Qué recibe la entidad y para qué lo utilizará? | Cada producto tiene estructura, formato, usuario y versión. |
| 9. Aceptación | ¿Cómo se verificará que cada producto está completo? | Usa criterios observables, no expresiones como “a satisfacción”. |
| 10. Operación | ¿Qué plazo, hitos, roles y transferencia se requieren? | Define revisiones, dependencias, repositorios y cierre. |
Redactar desde la decisión
Una formulación útil tiene cuatro piezas:
- Usuario: quién utilizará el resultado.
- Decisión: qué debe priorizar, corregir, aprobar o monitorear.
- Evidencia: qué información permitirá sustentarla.
- Producto: en qué forma debe entregarse para que pueda usarse.
Ejemplo: “La gerencia regional necesita priorizar asistencia técnica entre provincias. El servicio integrará indicadores, registros y entrevistas; documentará diferencias y entregará perfiles, una matriz de priorización y un brief ejecutivo”.
Diseñar productos aceptables
Para cada entregable conviene definir:
- contenido mínimo y preguntas cubiertas;
- fuentes, periodo y nivel territorial;
- archivos editables, base procesada y diccionario;
- controles de calidad y registro de transformaciones;
- versión para el equipo técnico y síntesis para decisión;
- ronda de observaciones, responsable y plazo de conformidad;
- materiales de transferencia, cuando el producto deba actualizarse.
En un dashboard o sistema, la conformidad no debe limitarse a que “funcione”. Debe incluir definiciones de indicadores, pruebas con usuarios, reglas de actualización, accesos, respaldo, documentación y condiciones de mantenimiento.
Hallazgos
Cinco errores que encarecen el servicio
- Pedir “todos los indicadores disponibles” sin identificar decisiones.
- Exigir software o técnicas específicas sin explicar el resultado esperado.
- Omitir quién entrega bases, permisos, contactos o documentos.
- Concentrar la aceptación en el informe final y no en productos intermedios.
- Solicitar un dashboard sin responsable de actualización ni rutina de uso.
Un buen TDR no elimina la incertidumbre. La hace visible y asigna cómo resolverla: pregunta de inicio, insumo, hito de validación, supuesto o exclusión.
Implicancias
Antes de publicar el requerimiento, realiza una revisión conjunta entre área usuaria, contrataciones, asesoría jurídica y las áreas responsables de datos o tecnología. Confirma la vigencia normativa, la clasificación del objeto, los requisitos proporcionales y la disponibilidad real de cada insumo.
Esta guía orienta el diseño técnico de un servicio de análisis. No constituye asesoría legal ni reemplaza los documentos estándar, directivas o pronunciamientos aplicables a una contratación concreta.
Aplicación y recursos
CTA
Si necesitas convertir una pregunta institucional en alcance, productos y criterios de aceptación, revisa la solución de línea de base y evaluación de programas o plantea el encargo.