Cómo elaborar un TDR para contratar software a medida

En una contratación pública de software, el documento que más pesa no lo escribe el proveedor: lo escribes tú. El TDR (Términos de Referencia) define qué vas a contratar, y un TDR mal hecho es la causa número uno de proyectos que se encarecen a mitad de camino, terminan en un sistema que nadie usa o se traban en litigios. La buena noticia: escribir uno bueno no es difícil, es método. Esta es la guía práctica — desde la experiencia de haber construido el sistema de caja de una universidad nacional cumpliendo la conformidad del sector público.

Primero: TDR o especificaciones técnicas — no te equivoques de documento

El software a medida es un servicio, no un bien. Su requerimiento se plasma en un TDR (Términos de Referencia), no en especificaciones técnicas (EETT), que son para bienes. Elegir mal el documento desalinea todo el proceso desde el arranque.

En la contratación pública peruana la regla es simple: el requerimiento de bienes se plasma en especificaciones técnicas, y el de servicios y consultorías en términos de referencia. Desarrollar un sistema a medida es un servicio — por eso el instrumento correcto es el TDR. Parece un detalle formal, pero define el tipo de proceso, cómo se evalúan las ofertas y qué puedes exigir. Empezar con el documento equivocado te obliga a rehacer todo.

El marco cambió en 2025: Ley 32069 y el OECE

Desde el 22 de abril de 2025 rige la Ley N.° 32069, que derogó la antigua Ley 30225 y reemplazó al OSCE por el OECE. Su principio rector es “valor por dinero”: la mejor compra no es la más barata, sino la que más beneficio aporta por cada sol. Tu TDR se redacta bajo ese marco.

La Ley General de Contrataciones Públicas (Ley N.° 32069), con su reglamento aprobado por el D.S. 009-2025-EF, cambió el lenguaje y las prioridades del sistema. El histórico OSCE dio paso al OECE (Organismo Especializado para las Contrataciones Eficientes del Estado), y el eje pasó a ser el valor por dinero. Para el software esto es liberador: te da base normativa para no adjudicar por el precio más bajo — que en desarrollo casi siempre sale caro — sino por la oferta que mejor resuelve el problema.

La regla de oro: describe el problema, no la solución

El mejor TDR de software describe el problema y los resultados esperados, no dicta la tecnología. Fijar de más (“debe ser en tal lenguaje, con tal framework”) reduce la competencia y te amarra a una solución peor. La ley además exige que el requerimiento posibilite la participación amplia de proveedores.

El error más común es copiar el TDR de otra entidad y llenarlo de requisitos técnicos arbitrarios. Cada “debe estar hecho en X tecnología” que no responde a una necesidad real hace dos cosas malas a la vez: reduce el número de proveedores que pueden postular y te amarra a una decisión técnica que quizá no sea la mejor para tu caso. Describe qué procesos necesitas, qué usuarios, con qué sistemas debe integrarse y qué resultado esperas — y deja que el experto proponga el cómo. No es solo mejor ingeniería: es lo que la norma pide cuando exige redactar de forma clara y sin restringir la competencia.

Lo que un TDR de software SÍ debe fijar

Fija el qué y las condiciones, no el cómo técnico: alcance funcional por módulos, integraciones requeridas, entregables completos (incluido el código fuente), propiedad intelectual, garantía, capacitación y criterios de evaluación objetivos. Todo lo que no esté aquí, aparecerá después como “adicional”.

La cláusula que más te protege: propiedad del código y de los datos

Exige por escrito que el código fuente, la documentación y los datos son propiedad de la entidad al finalizar. Es la diferencia entre tener un activo auditable que cualquier proveedor puede continuar, y quedar cautivo de uno que puede subir el precio o desaparecer. Un buen proveedor no tiene problema en firmarlo.

Es la cláusula más barata de escribir y la más cara de omitir. Si al terminar el contrato el código no es tuyo, cada cambio futuro depende del mismo proveedor, a su precio y a su ritmo — y si sube la tarifa, descontinúa el servicio o simplemente desaparece, tu operación queda atrapada. Es la misma lógica de fondo que separa el software a medida del enlatado: el a medida se justifica, entre otras cosas, porque el sistema es un activo tuyo. Ese principio tiene que estar escrito en el TDR, no asumido.

Integraciones: el punto que más se subestima (y se cotiza peor)

Si tu sistema debe conectarse con el Estado (RENIEC, SUNAT, SUNARP) o con tu ERP, decláralo explícitamente en el TDR. Las integraciones —vía PIDE o con un ERP como SAP— son la partida que más varía entre ofertas y la que más “adicionales” genera cuando se omite.

Conectar con otros sistemas suele ser la parte más cara y subestimada de un proyecto. El Estado peruano expone servicios a través de la Plataforma de Interoperabilidad del Estado (PIDE), que ya usan más de 450 entidades para intercambiar datos con RENIEC, SUNAT, SUNARP y el Banco de la Nación. Si tu sistema necesita, por ejemplo, validar identidad en tiempo real contra RENIEC o conectarse con tu ERP para la facturación, eso tiene que estar en el TDR con nombre y apellido. Omitirlo no hace la integración más barata: solo la convierte en un “adicional” imprevisto — y en un sistema a medias. Las integraciones se especifican, no se dan por supuestas.

Los errores que encarecen o hunden el proyecto

Un buen TDR atrae proveedores serios y produce ofertas comparables; uno malo ahuyenta a los buenos y encarece todo. La diferencia está en describir el problema (no amarrar la tecnología), fijar la propiedad del código, explicitar las integraciones y evaluar por valor, no solo por precio.

Cuidado con los datos: la Ley 29733

Si el sistema trata datos personales —y casi todos lo hacen—, el TDR debe exigir el cumplimiento de la Ley N.° 29733 de Protección de Datos Personales: tratamiento seguro, finalidad declarada y responsabilidades del proveedor sobre la información.

Un sistema de matrículas, de recaudación o de trámites maneja datos de personas. La Ley N.° 29733 obliga a un trato cuidadoso de ese dato, y el TDR es el lugar para fijar las responsabilidades: qué datos se tratan, con qué finalidad, cómo se protegen y qué pasa con ellos al terminar el contrato. Escrito desde el inicio, es una cláusula; descubierto al final, es un problema legal.

Cómo lo hacemos con entidades públicas

Construimos software para el sector público cumpliendo la conformidad funcional y técnica que exige. Podemos ayudarte a que tu TDR sea técnicamente sólido y realmente comparable entre ofertas — sin amarrarte a un proveedor, incluido nosotros.

Para una universidad nacional construimos su caja central: emisión de recibos con validación en tiempo real contra RENIEC, dashboards para el alto mando y reportes para Tesorería — cumpliendo la conformidad del sector público. Esa experiencia nos deja ver un TDR desde los dos lados: el de la entidad que necesita comprar bien y el del proveedor que va a construir. Si estás por sacar un proceso, revisamos tu TDR sin costo y te decimos dónde está flojo — aunque al final no nos contrates.

En resumen

El TDR no es un trámite: es el plano de tu compra. Elige el documento correcto (TDR, no EETT), redáctalo bajo la Ley 32069 pensando en valor por dinero, describe el problema en vez de amarrar la tecnología, y fija por escrito lo que de verdad te protege — los entregables, la propiedad del código, las integraciones, la garantía y el trato de los datos. Un buen TDR no solo cumple la norma: hace que los buenos proveedores quieran postular y que sus ofertas por fin se puedan comparar. Ahí empieza un proyecto que termina bien.