Como redactar una propuesta tecnica que gana licitaciones — lo que nadie le ensena
Este articulo prolonga La revolucion informacional, donde se planteaba el marco teorico de la relacion senal/ruido aplicada a las licitaciones, y El mito del executive summary, donde se mostraba que el primer documento leido por el evaluador es tambien el que todo el mundo descuida. Aqui, pasamos a la propuesta tecnica en si — el documento que determina la nota.
La propuesta tecnica es el documento mas redactado, mas reciclado y menos comprendido del proceso de licitacion. Cada ano, miles de bid managers dedican cientos de horas a producir documentos de 100, 200, 300 paginas — y la mayoria obtiene notas entre 11 y 13 sobre 20.
No porque carezcan de competencias. No porque su solucion sea mala. Porque redactan un documento. Y una propuesta tecnica ganadora no es un documento redactado — es un sistema de codificacion optimizado para la grilla de evaluacion.
La diferencia entre 12/20 y 17/20 casi nunca es una cuestion de fondo. Es una cuestion de estructura, de densidad informacional, y de comprension de lo que realmente hace el evaluador cuando abre su archivo.
Lo que el evaluador realmente hace con su propuesta tecnica
Olvide la imagen del lector atento que devora cada pagina. El evaluador de una licitacion publica tiene cinco expedientes que evaluar en dos dias. A veces siete. Cada expediente tiene entre 80 y 300 paginas. Frecuentemente esta solo, a veces acompanado de un colega tecnico que solo ha leido "su" parte. Tiene una grilla de evaluacion impresa junto a la pantalla.
Esto es lo que sucede concretamente.
Los primeros 30 segundos: abre el archivo, mira el indice, verifica que el documento esta estructurado. Si no ve inmediatamente las grandes secciones esperadas, se ancla una senal negativa. No la olvidara.
Los primeros 5 minutos: lee el executive summary — si existe. Es ahi donde se juega la primera impresion. Si lee "Nuestro equipo pluridisciplinario se compromete a acompanar su transformacion con un enfoque probado", ya sabe que tiene entre manos la misma propuesta que las otras cuatro. Su concentracion baja un grado.
La evaluacion propiamente dicha: no lee en orden. Toma su grilla de evaluacion, criterio por criterio, y busca en la propuesta la seccion que responde a cada uno. Escanea los titulos, los primeros parrafos, las tablas. Busca contenido direccionable — una informacion que pueda vincular a una linea de su grilla y a la que pueda asignar una nota.
El comportamiento de escaneo: en una seccion de 15 paginas, el evaluador realmente lee 3 o 4 paginas. El titulo, el primer parrafo, los subtitulos, las tablas, los recuadros, la conclusion de seccion. El resto, lo recorre por encima. No es pereza — es una restriccion de capacidad del canal. Fisicamente no puede absorber 1 500 paginas en dos dias.
La calificacion: evalua cada criterio de forma independiente. Si su mejor argumento para el criterio "metodologia" esta enterrado en la seccion "organizacion del equipo", no lo encontrara. Calificara segun lo que haya encontrado en la seccion "metodologia" — aunque sea mas debil.
A recordar: El evaluador no lee su propuesta. La escanea con una grilla. Cada informacion que no esta en el lugar correcto, en el formato correcto, asociada al criterio correcto — es una informacion perdida. No porque sea mala, sino porque es invisible.
La estructura que marca la diferencia: responder al baremo, no al pliego de condiciones
Es el error mas extendido, y es responsable de mas puntos perdidos que cualquier defecto de contenido.
La mayoria de los bid managers estructuran su propuesta tecnica calcando el plan del pliego de condiciones tecnicas. El pliego tiene 8 capitulos tecnicos? La propuesta tendra 8 capitulos tecnicos, en el mismo orden. Es logico. Es tranquilizador. Es erroneo.
El pliego de condiciones describe la necesidad. El baremo de evaluacion describe lo que el evaluador va a calificar. No son lo mismo, y no siguen el mismo plan.
Tomemos un ejemplo. Una licitacion de servicios informaticos con este baremo:
| Criterio | Ponderacion | Lo que busca el evaluador |
|---|---|---|
| Comprension de la necesidad | 30% | Reformulacion, analisis de los desafios, riesgos identificados |
| Metodologia de implementacion | 25% | Procesos, herramientas, gobernanza, indicadores |
| Recursos humanos | 25% | Perfiles, competencias, organizacion, escalamiento |
| Gestion de riesgos y calidad | 20% | Identificacion de riesgos, plan de mitigacion, SLA |
El pliego, por su parte, esta estructurado por perimetro funcional: gestion de incidentes, gestion de cambios, gestion de puestas en produccion, supervision, reporting. Cinco capitulos tecnicos.
La propuesta calcada del pliego produce cinco grandes secciones (incidentes, cambios, puestas en produccion, supervision, reporting). Para cada seccion, el bid manager mezcla comprension, metodologia, equipo y riesgos. El evaluador que califica el criterio "metodologia" (25% de la nota) debe buscar en cinco secciones diferentes para encontrar los fragmentos dispersos. Encuentra tres de cinco. Nota: 13/20.
La propuesta calcada del baremo produce cuatro grandes secciones (comprension, metodologia, recursos, riesgos). En cada seccion, los perimetros funcionales se tratan como subsecciones. El evaluador que califica el criterio "metodologia" abre la seccion 2, encuentra todo lo que busca, en orden. Nota: 16/20.
Mismo contenido. Estructura diferente. Tres puntos de diferencia.
| Enfoque | Estructura | Comportamiento del evaluador | Nota tipica |
|---|---|---|---|
| Calcada del pliego | Por perimetro funcional | Debe reconstruir cada criterio cruzando las secciones | 11-13/20 |
| Calcada del baremo | Por criterio de evaluacion | Encuentra cada criterio en una seccion dedicada | 15-17/20 |
El pliego le dice que cubrir. El baremo le dice como sera evaluado. Estructurar en torno al que en lugar del como, es como preparar un examen leyendo el curso en lugar de mirar los examenes anteriores. Aprende la materia. No prepara la prueba.
A recordar: El plan de su propuesta tecnica no debe ser el espejo del pliego de condiciones. Debe ser el espejo de la grilla de evaluacion. Cada criterio del baremo = una seccion. Cada subcriterio = una subseccion. El evaluador nunca debe tener que buscar.
Los tres errores que limitan su nota a 12/20
Despues de haber revisado cientos de propuestas tecnicas — como redactor, como revisor, como evaluador — tres patrones aparecen sistematicamente en los expedientes que se estancan entre 11 y 13.
Error 1: la respuesta generica
"Nuestro equipo de proyecto asegurara un seguimiento riguroso de los incidentes conforme a las buenas practicas ITIL."
Esta frase podria figurar en cualquier propuesta, para cualquier licitacion. Es el test del competidor: sustituya el nombre de su empresa por el de un competidor. Si la frase sigue funcionando, no transmite ninguna senal diferenciadora. El evaluador la lee, no aprende nada, y pasa a la siguiente. Acaba de desperdiciar un parrafo.
La respuesta generica es el sintoma de una propuesta redactada a partir de una plantilla en lugar del pliego de condiciones. El bid manager tomo la propuesta de la ultima licitacion, cambio el nombre del cliente, ajusto los volumenes, y envio. Es el sesgo de recencia materializado en un documento Word.
La correccion: cada parrafo debe contener al menos un elemento especifico de la licitacion en curso. Un nombre de tecnologia mencionado en el pliego. Un volumen. Una restriccion. Un riesgo identificado en el contexto del cliente. Si no puede senalar el elemento del expediente que justifica ese parrafo — eliminelo.
Error 2: el parrafo reciclado
Mas insidioso que la respuesta generica: el parrafo que era excelente en el expediente anterior, y que esta fuera de tema en este.
Un parrafo sobre la gestion del cambio en entorno SAP, perfectamente calibrado para un cliente industrial — reciclado tal cual en una licitacion de una entidad territorial que no tiene SAP. El evaluador detecta inmediatamente el desfase. Y la senal que recibe no es "este candidato es generalista" — es "este candidato no ha leido nuestro pliego de condiciones".
El reciclaje es la fuente mas frecuente de ruido destructivo en una propuesta tecnica. Cada parrafo reciclado degrada la relacion senal/ruido del conjunto del documento, porque ocupa espacio sin aportar informacion pertinente.
Error 3: la ausencia de pruebas
"Nuestra experiencia en gestion de proyectos complejos nos permite asegurar una implementacion controlada."
Afirmacion gratuita. Ninguna prueba. Ningun dato. Ninguna referencia. El evaluador no tiene razon alguna para creerle a usted mas que al competidor que escribe exactamente lo mismo.
La nota tecnica no es un ejercicio de persuasion retorica. Es un ejercicio de demostracion. Cada afirmacion debe estar respaldada por:
- Un dato: "Tiempo medio de resolucion de incidentes P1 en nuestros 3 ultimos contratos de TMA: 2h14, frente a un SLA de 4h."
- Una referencia contextualizada: "En la licitacion [X] (entorno comparable: 12 000 puestos, SI heterogeneo), redujimos la tasa de incidentes recurrentes en un 34% en 18 meses." — No un catalogo de logotipos, sino un hecho verificable vinculado a un contexto similar.
- Un entregable concreto: "La metodologia de transferencia de conocimientos se apoya en un kit documental de 47 fichas operativas, cuyo extracto se proporciona en el anexo 3."
| Nivel de prueba | Ejemplo | Impacto en la nota |
|---|---|---|
| Ninguna prueba | "Nuestra experiencia nos permite..." | El evaluador ignora — +0 puntos |
| Prueba debil | "Tenemos la costumbre de..." | Senal vaga — +0,5 puntos |
| Prueba contextual | "En un contexto similar (12 000 puestos), resultado: -34% incidentes" | Senal fuerte — +2 puntos |
| Prueba documentada | Dato + referencia + entregable en anexo | Senal maxima — +3 puntos |
A recordar: Generico + reciclado + sin pruebas = 12/20 garantizado. No es un juicio de valor — es un mecanismo. El evaluador califica lo que ve. Si solo ve ruido, pone la nota media y pasa al siguiente expediente.
Como codificar la senal en cada seccion
El marco teorico senal/ruido da el "por que". Aqui viene el "como".
La codificacion de la senal en una propuesta tecnica se basa en un principio: la senal debe sobrevivir a una lectura en diagonal. Porque asi es como el evaluador va a leerla. No porque sea negligente, sino porque la restriccion temporal le obliga.
Tecnica 1: la primera frase de cada seccion transmite el mensaje
El evaluador lee sistematicamente la primera frase de cada seccion y subseccion. Si su primera frase es "Esta seccion presenta nuestro enfoque metodologico" — acaba de desperdiciar el unico espacio con lectura garantizada.
Malo: "Esta seccion presenta nuestra metodologia de gestion de incidentes."
Bueno: "El riesgo principal de su gestion de incidentes no es el volumen — es el plazo de calificacion. Nuestra metodologia apunta especificamente a esta etapa con un prediagnostico automatizado que reduce el tiempo de calificacion en un 45%."
La primera frase debe ser un concentrado de senal: anuncia su comprension del problema Y el valor de su respuesta. El resto de la seccion desarrolla. Pero si el evaluador solo lee las primeras frases — ya tiene lo esencial.
Tecnica 2: las tablas transmiten las pruebas
El ojo del evaluador se siente atraido por las rupturas visuales: titulos, tablas, recuadros, esquemas. Una tabla se lee incluso en modo escaneo. Un parrafo de prosa puede saltarse.
Concentre sus pruebas en tablas. No tablas decorativas — tablas informativas.
| Proceso | SLA contractual | Rendimiento medio (3 ultimos contratos) | Herramienta |
|---|---|---|---|
| Calificacion incidente P1 | 30 min | 18 min | ServiceNow + prediagnostico IA |
| Resolucion incidente P1 | 4h | 2h14 | Equipo dedicado N2 (3 ingenieros) |
| Resolucion incidente P2 | 8h | 5h30 | Rotacion N2/N3 |
| Informe mensual | M+5 dias habiles | M+3 dias habiles | Cuadro de mando Power BI |
Esta tabla transmite mas senal que dos paginas de prosa. Se lee en 15 segundos. Demuestra en lugar de afirmar. Y sobrevive a la lectura en diagonal.
Tecnica 3: la redundancia estrategica de los win themes
Un win theme es un argumento diferenciador que usted quiere anclar en la mente del evaluador. No debe aparecer una sola vez en la propuesta — debe ser declinado en cada seccion pertinente, bajo angulos diferentes.
Si su win theme es "prediagnostico automatizado", aparece:
- En la comprension de la necesidad: "El volumen de incidentes no es el problema. El plazo de calificacion lo es. El prediagnostico automatizado reduce este plazo en un 45%."
- En la metodologia: descripcion tecnica del proceso de prediagnostico, integracion con la herramienta ITSM del cliente.
- En los recursos: perfil del ingeniero que configura y mantiene el prediagnostico, formacion del equipo del cliente.
- En los riesgos: "Riesgo identificado: resistencia al cambio del equipo N1 frente al prediagnostico. Mitigacion: acompanamiento durante 3 meses con metricas de rendimiento visibles."
No es repeticion. Es redundancia en el sentido de Shannon: un codigo corrector de errores. Aunque el evaluador solo lea una seccion de cuatro, se encuentra con el win theme. La senal pasa a pesar del ruido del canal.
Tecnica 4: nombrar los riesgos que nadie nombra
El evaluador ha leido cuatro expedientes. Los cuatro dicen "nuestra metodologia probada garantiza una implementacion controlada". Ninguno nombra los riesgos especificos de la licitacion. El quinto expediente escribe:
"El riesgo principal de esta licitacion no es tecnico — es la cohabitacion entre el antiguo SI (cuyo desmantelamiento esta previsto pero no fechado) y el nuevo durante un periodo de transicion que podria durar de 18 a 24 meses. Nuestro plan de mitigacion trata especificamente las dependencias aplicativas identificadas en el parrafo 4.3 del pliego de condiciones."
El evaluador posa su boligrafo. Este candidato ha comprendido algo que los otros no vieron — o no se atrevieron a escribir. Es la misma senal que la de las buenas preguntas en la fase de consultas: demuestra una comprension que va mas alla de la lectura superficial.
A recordar: Codificar la senal no es escribir mejor. Es colocar la informacion donde el evaluador la busca, en el formato que absorbe, con la prueba que transforma la afirmacion en hecho. Primera frase = mensaje. Tabla = prueba. Redundancia = robustez. Riesgo nombrado = diferenciacion.
El caso concreto: dos propuestas tecnicas para la misma licitacion
Licitacion de Mantenimiento Correctivo y Evolutivo de Aplicaciones para una metropoli. Perimetro: 14 aplicaciones de negocio, 8 000 usuarios, entorno Java/Oracle. Presupuesto estimado: 2,5 millones de euros en 4 anos. Baremo tecnico: 60% de la nota global.
Criterios de evaluacion:
- Comprension del contexto y de los desafios: 30 puntos
- Metodologia y organizacion: 40 puntos
- Recursos humanos: 30 puntos
Dos licitadores. Mismo tamano de empresa. Competencias comparables. Referencias similares. La diferencia esta en la propuesta.
Licitador A — la propuesta estandar
Estructura: calcada del pliego de condiciones. Cinco grandes partes correspondientes a los cinco dominios funcionales (urbanismo, finanzas, RRHH, GRC, SIG).
Executive summary: "Gracias a nuestra reconocida experiencia en mantenimiento de aplicaciones de negocio para el sector publico, nuestro equipo pluridisciplinario se compromete a acompanar a la Metropoli en la gestion y evolucion de su patrimonio aplicativo, con un enfoque estructurado y probado." — 42 palabras, cero informacion.
Comprension del contexto: reformulacion del pliego. Dos paginas que resumen lo que el cliente escribio, sin analisis, sin identificacion de riesgo, sin desafio explicitado. El evaluador lee su propio texto en version condensada.
Metodologia: descripcion general del proceso ITIL. Ninguna adaptacion al contexto de la metropoli. El mismo capitulo aparece en las 15 ultimas propuestas de la empresa. Algunos esquemas genericos de procesos.
Recursos humanos: lista de CV. Una tabla de perfiles con anos de experiencia y certificaciones. Ninguna explicacion de la organizacion operativa, de la gestion de ausencias, del escalamiento.
Referencias: cuatro logotipos de entidades publicas. Ningun detalle sobre los contextos, los resultados, las dificultades encontradas.
Resultado: 12/20 — Nota detallada: Comprension 16/30, Metodologia 20/40, Recursos 18/30.
Licitador B — la propuesta estrategica
Estructura: calcada del baremo. Tres partes: Comprension, Metodologia, Recursos. Cada dominio funcional se trata como subseccion dentro de cada parte.
Executive summary: "Su desafio principal no es el mantenimiento corriente de 14 aplicaciones — es la gestion de la deuda tecnica acumulada en los modulos Finanzas y RRHH (Java 8, Oracle 11g) durante el periodo de transicion hacia su futuro SI, cuyo calendario de despliegue aun esta por estabilizar. Nuestra respuesta se construye en torno a tres ejes: la aseguracion de la continuidad de servicio en los modulos criticos (apartado 2), un plan de reabsorcion de la deuda tecnica calibrado en 18 meses (apartado 3), y un equipo dimensionado para absorber los picos de carga vinculados a las migraciones aplicativas (apartado 4)." — Especifico. Factual. Estructurante.
Comprension del contexto:
| Desafio identificado | Fuente (apartado del pliego) | Impacto | Nuestra respuesta (apartado de la propuesta) |
|---|---|---|---|
| Deuda tecnica Java 8 / Oracle 11g | apartado 3.2.1, apartado 4.1 | Riesgo de fin de soporte del editor Q3 2027 | Plan de migracion apartado 3.2 |
| Cohabitacion antiguo/nuevo SI | apartado 4.3.2 | Dependencias no documentadas entre 6 modulos | Cartografia apartado 2.3 + hipotesis H-04 |
| Pico de carga en despliegues | apartado 5.1 | 3 periodos criticos identificados (presupuesto, elecciones, inicio de curso) | Dimensionamiento elastico apartado 4.2 |
| Rotacion del equipo actual del proveedor | Consulta Q&R #7 | Perdida de conocimiento de negocio en 3 modulos | Plan de transferencia apartado 4.3 |
Cuatro desafios. Cuatro fuentes. Cuatro respuestas trazables. El evaluador ve inmediatamente que este candidato ha leido, comprendido y estructurado.
Metodologia: proceso ITIL adaptado al contexto. Cada proceso se describe con las especificidades de la licitacion: "La calificacion de los incidentes en el modulo Finanzas sera completada con un prediagnostico automatizado (reglas de negocio extraidas de la documentacion funcional existente) para compensar la falta de documentacion tecnica identificada en el apartado 3.2.1 del pliego de condiciones." Sin descripcion generica — cada parrafo ancla la metodologia en la necesidad.
Recursos humanos: organigrama operativo. Matriz RACI por dominio funcional. Plan de respaldo nominativo (quien sustituye a quien, en que plazo). Curva de escalamiento durante los 6 primeros meses con los hitos de transferencia de conocimientos. No una lista de CV — un sistema organizativo.
Referencias: dos referencias detalladas. Para cada una: contexto (tamano, perimetro, tecnologias), dificultad principal encontrada, solucion implementada, resultado cuantificado. "Contexto comparable (metropoli, 11 000 usuarios, Java/Oracle): reduccion del 28% del stock de bugs criticos en 12 meses, paso de la tasa de resolucion dentro de los SLA del 73% al 94%."
Resultado: 17/20 — Nota detallada: Comprension 26/30, Metodologia 34/40, Recursos 25/30.
Cinco puntos de diferencia. Misma licitacion. Mismo perimetro funcional. La diferencia: una propuesta habla del cliente, la otra habla de si misma.
A recordar: La propuesta a 12/20 no es mala. Es invisible. No le da al evaluador los elementos para poner una buena nota — aunque la solucion detras sea solida. La propuesta a 17/20 codifica la senal para que sobreviva al escaneo. Cada punto del baremo tiene su seccion. Cada afirmacion tiene su prueba. Cada riesgo esta nombrado.
Lo que hace TenderGraph
TenderGraph no escribe su propuesta tecnica. Hace el trabajo que nadie tiene tiempo de hacer — y del que, sin embargo, depende la totalidad de la nota.
Extraccion y cartografia de requisitos
El sistema analiza el expediente de licitacion completo — pliego de condiciones tecnicas, reglamento de consulta, clausulas administrativas, cuadro de precios, anexos — y extrae cada requisito, cada restriccion, cada criterio de evaluacion. No por orden de pagina. Por capa semantica: requisitos funcionales, restricciones tecnicas, criterios de evaluacion, hipotesis implicitas, zonas de ambiguedad.
El resultado es una cartografia estructurada de la necesidad. El equivalente de dos semanas de trabajo de un bid manager senior — producido en unos minutos, con el rigor de un sistema que no salta parrafos y no sufre de sesgo de recencia.
Alineacion baremo-contenido
TenderGraph cruza los criterios de evaluacion con los requisitos extraidos y produce una matriz de alineacion: para cada criterio del baremo, que requisitos del pliego estan en juego, que ponderacion tienen, y que densidad de senal debe alcanzar cada seccion de la propuesta.
Es la diferencia entre el licitador A (que estructura por intuicion) y el licitador B (que estructura por el baremo). El sistema formaliza lo que los mejores bid managers hacen intuitivamente — pero que la presion del calendario impide hacer sistematicamente.
Concentracion de la senal
Para cada seccion de la propuesta, TenderGraph identifica los elementos de fuerte senal: las pruebas cuantificadas, las referencias contextuales, los riesgos especificos, los compromisos medibles. Senala las zonas de ruido: los parrafos genericos, las formulaciones recicladas, las afirmaciones sin prueba.
El bid manager mantiene el control del contenido. El sistema le muestra donde la senal esta concentrada y donde esta diluida — para que pueda asignar su tiempo donde tiene mayor impacto, en lugar de pulir secciones que no pesan nada en el baremo.
Trazabilidad requisito-respuesta
Cada seccion de la propuesta esta vinculada a los requisitos del pliego que aborda. Si un requisito no esta cubierto por ninguna seccion, el sistema lo senala. Si una seccion no responde a ningun requisito, el sistema tambien lo senala — probablemente es ruido.
Esta trazabilidad es exactamente lo que el evaluador hace mentalmente cuando califica: busca, para cada criterio, si la respuesta lo aborda. TenderGraph realiza este trabajo antes que el — para que la respuesta ya este estructurada en el sentido de su lectura.
A recordar: TenderGraph no redacta la propuesta tecnica. Construye la armadura sobre la que la propuesta debe construirse: cartografia de requisitos, alineacion al baremo, concentracion de la senal, trazabilidad. El fondo sigue siendo del experto. La estructura se convierte en la que maximiza la nota. Nuestra vision es que la propuesta tecnica no es un ejercicio literario — es un ejercicio de codificacion.
Lo que debe recordar
Una propuesta tecnica a 17/20 y una propuesta tecnica a 12/20 contienen a menudo las mismas ideas, las mismas competencias, la misma solucion. La diferencia no esta en el fondo — esta en la manera en que el fondo esta estructurado, codificado y presentado a un evaluador que tiene cinco expedientes que leer en dos dias.
Tres principios separan las propuestas que ganan licitaciones de las que "participan":
-
Estructurar en torno al baremo, no al pliego de condiciones. Cada criterio de evaluacion = una seccion. El evaluador nunca debe tener que buscar.
-
Codificar la senal para que sobreviva al escaneo. Primera frase = mensaje. Tabla = prueba. Redundancia estrategica = robustez. Riesgo nombrado = diferenciacion.
-
Demostrar en lugar de afirmar. Cada parrafo contiene un dato, una referencia o un entregable concreto. Las afirmaciones gratuitas no suman puntos — generan ruido.
La propuesta tecnica no es un documento que se redacta. Es un sistema que se construye.
Lea tambien:
- El mito del executive summary — El executive summary es la puerta de entrada de la propuesta tecnica. Si es generico, el resto se lee con un prejuicio negativo.
- Por que sus referencias de clientes no convencen a nadie — Las referencias en una propuesta tecnica no son logotipos. Son pruebas contextuales que validan sus afirmaciones.
- Lo que el pliego de condiciones no dice — La propuesta tecnica que solo aborda lo que esta escrito en el pliego deja de lado lo que hace ganar la licitacion.
- La revolucion informacional: senal y ruido — El marco teorico detras de la codificacion de la senal: Shannon aplicado al bid management.
- El peor enemigo del bid manager: el mismo — Los sesgos cognitivos que producen propuestas tecnicas genericas: recencia, anclaje, completitud.
- La aceleracion de los ciclos de preventa — El tiempo liberado por la automatizacion debe reinvertirse en la construccion de la senal, no en la produccion de volumen.