Una licitación TI casi nunca falla el día que se adjudica. Falla meses antes, cuando alguien redacta un pliego con requisitos copiados de otro proceso, sin saber qué problema quiere resolver, o cuando el comité evalúa propuestas que no se pueden comparar entre sí. El resultado se ve después: un contrato que cumple en el papel, un proveedor que entrega lo que el pliego pedía —que no era lo que la empresa necesitaba— y una gerencia financiera preguntándose a dónde se fue el presupuesto.

En AIATIC vemos el proceso desde los dos lados de la mesa. Gestionamos compras de tecnología para nuestros clientes y, como fábrica de software, también nos presentamos a licitaciones. Esa doble posición enseña rápido qué revisar antes de abrir un proceso. Esta es la lista que usamos, pensada para gerencia general, financiera y de compras.

Antes del pliego: lo que se decide sin escribir una línea

1. ¿El problema está escrito en términos de negocio?

«Necesitamos un ERP» no es un problema; «cerramos el mes en doce días y necesitamos hacerlo en cinco» sí lo es. Si el objetivo no se puede medir, tampoco se podrá medir si el proveedor lo cumplió. Escribe el problema, el indicador que lo refleja y el valor al que quieres llegar.

2. ¿Sabes cómo funciona hoy el proceso que quieres cambiar?

Comprar tecnología sobre un proceso que nadie ha documentado es tecnificar el desorden. Un diagnóstico corto del flujo actual —quién hace qué, con qué datos y en qué sistema— evita pedir funcionalidades que nadie va a usar y olvidar las que sí son críticas.

3. ¿El presupuesto incluye todo el ciclo de vida?

Licencias o desarrollo son solo una parte. Suma implantación, migración de datos, integración con lo que ya existe, capacitación, soporte y mantenimiento durante la vida útil. Una propuesta barata en la compra y cara en la operación es la forma más común de perder dinero en TI.

4. ¿Hay un dueño interno con tiempo para el proyecto?

Ningún proveedor puede reemplazar a quien conoce el negocio. Si el líder del proyecto lo asume «además de» sus funciones, el cronograma ya tiene un riesgo que ningún contrato cubre.

Durante el pliego: requisitos que se puedan verificar

5. ¿Los requisitos son verificables o son adjetivos?

«Sistema robusto, escalable y amigable» no se puede evaluar. «Soportar 200 usuarios concurrentes con tiempos de respuesta menores a dos segundos» sí. Cada requisito debe responder a una pregunta: ¿cómo voy a comprobar que se cumplió?

6. ¿Separas lo obligatorio de lo deseable?

Un pliego donde todo es obligatorio deja por fuera a buenos proveedores y no ayuda a decidir entre los que quedan. Marca qué es habilitante y qué suma puntos, y asigna el peso según el impacto en el negocio, no según la costumbre.

7. ¿Pides evidencia de capacidad, no solo declaraciones?

Certificaciones de procesos y de seguridad, como un nivel de madurez CMMI o la ISO 27001 cuando el proyecto maneja información sensible, son evidencia auditada por un tercero. Pídelas vigentes, con su alcance, y verifica que ese alcance cubra el servicio que estás comprando. Lo mismo con la experiencia: certificaciones de clientes con contacto, no solo logos.

8. ¿El pliego dice quién es dueño del código, los datos y la documentación?

Propiedad intelectual, acceso a los repositorios, entrega del código fuente, formatos de exportación de datos y documentación técnica. Si esto no queda en el pliego, la salida del proveedor te costará más que la entrada.

9. ¿Los acuerdos de nivel de servicio tienen consecuencias?

Un SLA sin medición ni penalidad es una intención. Define disponibilidad, tiempos de respuesta por severidad, cómo se reporta y qué pasa cuando no se cumple.

En la evaluación: comparar lo comparable

10. ¿Pides las propuestas económicas en un formato único?

Si cada proveedor cotiza a su manera, el comité termina comparando paquetes distintos. Entrega una plantilla con los mismos rubros —licencias, horas por perfil, infraestructura, soporte por año— y exige que todo se cotice ahí.

11. ¿La evaluación técnica incluye una demostración o prueba de concepto?

Una presentación muestra lo que el proveedor quiere enseñar; una prueba con tus datos y tus casos muestra lo que el producto hace. Para compras de cierto tamaño, unos días de prueba controlada valen más que cien páginas de propuesta.

12. ¿Conoces al equipo que va a ejecutar, no solo al que vende?

Pide las hojas de vida del equipo propuesto, su dedicación y un compromiso de no reemplazarlo sin aprobación. El equipo comercial no es el que va a estar en la operación.

Después de adjudicar: donde se pierde el valor

La firma del contrato no cierra el proceso de compra; lo empieza. Tres cosas marcan la diferencia en la ejecución:

• Entregables con criterios de aceptación. Cada pago amarrado a un entregable verificable, no a un porcentaje de avance declarado.
• Seguimiento independiente. Una interventoría o una gerencia de proyecto que represente a la empresa, no al proveedor, y que tenga criterio técnico para discutir.
• Gestión de cambios por escrito. Todo cambio de alcance, con su impacto en costo y tiempo, aprobado antes de ejecutarse.

Lo que aprendimos haciendo interventoría

En proyectos públicos donde hemos actuado como interventores o gerentes de proyecto, el patrón se repite: los problemas más caros de la ejecución tenían su origen en el pliego. Requisitos ambiguos que cada parte interpretaba a su favor, entregables sin criterio de aceptación y cronogramas que no contaban con el tiempo del equipo del contratante. Cuando el pliego se escribió bien, la interventoría pudo concentrarse en la calidad del producto; cuando no, se le fue el tiempo arbitrando discusiones contractuales.

Del otro lado de la mesa, como oferentes, la lección es la misma vista al revés: los procesos mejor estructurados son también los que atraen propuestas más serias, porque el proveedor sabe exactamente qué se le va a exigir y puede cotizarlo sin colchones.

Preguntas frecuentes

¿Cuánto tiempo debería tomar preparar una licitación TI?

Depende del tamaño de la compra, pero el diagnóstico y la definición de requisitos suelen tomar más tiempo que la evaluación de propuestas. Recortar esa etapa es la forma más rápida de alargar la ejecución.

¿Qué certificaciones conviene pedir a un proveedor de software?

Las que correspondan al riesgo del proyecto: un nivel de madurez de procesos como CMMI para desarrollo y servicios, e ISO 27001 cuando el proveedor va a tratar información sensible. Lo importante es verificar la vigencia y que el alcance de la certificación cubra el servicio contratado.

¿Vale la pena contratar una gestión externa de compras TI?

Cuando la empresa no compra tecnología con frecuencia, sí: un tercero con experiencia en ambos lados del proceso reduce el riesgo de un pliego mal planteado y equilibra la negociación con proveedores que licitan todos los meses.

Antes de abrir tu próxima licitación

AIATIC es firma consultora y fábrica de software con certificación CMMI Nivel 3 en desarrollo y servicios. Gestionamos compras de tecnología para nuestros clientes y conocemos el proceso desde el lado del oferente, así que podemos revisar tu pliego con los dos ojos.

Solicita un diagnóstico de tu proceso de compra TI →