RFP para servicios TI: qué debe incluir para evaluar y comparar proveedores

Tres proveedores pueden recibir aparentemente la misma solicitud y responder con tres propuestas completamente diferentes.

Eso no significa necesariamente que uno sea caro y otro barato. Muchas veces significa que cada proveedor entendió un alcance distinto.

Un RFP —Request for Proposal o Solicitud de Propuesta— ayuda a reducir esa ambigüedad. Su función no es únicamente pedir una cotización, sino explicar con suficiente claridad qué necesita la empresa para que distintos proveedores puedan responder sobre una base comparable.

Por eso, un buen RFP empieza mucho antes de preguntar cuánto cuesta el servicio.

¿Qué es un RFP y para qué sirve en servicios TI?

Un RFP es un documento mediante el cual una organización presenta una necesidad y solicita a uno o varios proveedores que planteen cómo podrían atenderla.

En proyectos tecnológicos, debería permitir que el proveedor comprenda el problema, el alcance esperado, los requerimientos y las condiciones bajo las cuales será evaluada su propuesta.

Esto es importante porque expresiones como “necesitamos soporte”, “queremos automatizar este proceso” o “buscamos especialistas SAP” todavía dejan muchas preguntas abiertas.

¿Cuántos usuarios están involucrados? ¿Qué sistemas participan? ¿Qué responsabilidad tendrá el proveedor? ¿Qué debe entregar? ¿Durante cuánto tiempo? ¿Qué situaciones se consideran críticas?

Cuanto más ambigua sea la necesidad, más difícil será comparar las propuestas después.

El error de empezar preguntando por el precio

Solicitar una cotización antes de definir el problema puede producir números que parecen comparables, pero que en realidad corresponden a alcances distintos.

Por ejemplo, dos proveedores pueden cotizar un servicio de soporte TI. Uno puede estar considerando atención reactiva durante horario laboral y otro puede haber incluido seguimiento, documentación, escalamiento y especialistas adicionales.

Los dos precios responden a servicios diferentes. Por eso, antes de pedir un monto, la empresa debería entender primero su situación actual.

Un ejercicio útil es describir el escenario AS-IS, es decir, cómo funciona hoy el proceso: quién participa, qué sistemas utiliza, dónde aparecen los problemas, qué tareas siguen siendo manuales y qué dependencias existen.

Este tipo de mapeo permite convertir problemas generales en requerimientos mucho más concretos.

1. Explica el problema que quieres resolver

El RFP debería empezar con contexto, no con una lista de tecnologías.

En lugar de escribir:

“Necesitamos un proveedor de soporte SAP.”

Es más útil explicar:

“El equipo interno necesita reforzar la atención de incidencias funcionales y técnicas porque existen requerimientos que superan su capacidad actual y generan demoras en procesos críticos.”

El segundo planteamiento ayuda al proveedor a comprender por qué se necesita el servicio. Conviene explicar:

• qué problema existe actualmente;
• qué áreas están involucradas;
• quiénes son los usuarios;
• qué impacto tiene el problema;
• qué espera mejorar la organización;
• qué restricciones ya se conocen.

El objetivo no es contar toda la historia de la empresa. Es proporcionar suficiente contexto para que el proveedor entienda la necesidad que está intentando resolver.

2. Describe la situación actual

Antes de pedir una solución, describe brevemente cómo funciona hoy.

Esto puede incluir:

• sistemas utilizados;
• procesos involucrados;
• equipos internos responsables;
• proveedores actuales;
• herramientas existentes;
• integraciones relevantes;
• incidencias o limitaciones conocidas;
• actividades manuales;
• dependencias críticas.

Esta sección es especialmente importante cuando el nuevo proveedor tendrá que integrarse con una operación que ya existe. Un servicio TI rara vez comienza desde cero.

3. Define claramente el alcance

El alcance debería responder una pregunta muy sencilla:

¿Qué esperamos que haga el proveedor?

Debe quedar suficientemente claro qué actividades forman parte del servicio y cuáles no. Por ejemplo, si el RFP corresponde a soporte, podría definir si incluye:

• atención de incidencias;
• requerimientos funcionales;
• soporte técnico;
• monitoreo;
• documentación;
• mejoras menores;
• seguimiento;
• reuniones periódicas;
• transferencia de conocimiento.

No todos los RFP necesitan incluir esos elementos. Dependerá del servicio. Lo importante es que los proveedores estén cotizando sobre una misma referencia.

Un precio sin alcance tiene poco valor para comparar.

4. Separa requerimientos funcionales y técnicos

Los requerimientos funcionales explican qué necesita conseguir el negocio.

Los requerimientos técnicos explican qué condiciones tecnológicas deben cumplirse para conseguirlo.

Por ejemplo:

Requerimiento funcional

El usuario debe poder consultar el estado de una solicitud sin depender de otro equipo.

Requerimiento técnico

La solución debe integrarse con el sistema actual mediante el mecanismo de conexión definido por TI y respetar los controles de acceso existentes.

Separarlos ayuda a evitar que el RFP se convierta únicamente en una lista de tecnologías.

La tecnología debería responder a una necesidad del proceso, no reemplazar su definición.

5. Especifica los entregables

Una propuesta también debería permitir entender qué recibirá la empresa.

Dependiendo del servicio, los entregables pueden incluir:

• documentación técnica;
• configuraciones;
• desarrollos;
• reportes;
• manuales;
• procedimientos;
• sesiones de capacitación;
• transferencia de conocimiento;
• informes de seguimiento;
• evidencias de pruebas.

Es mejor definirlos desde el principio que descubrir al final del proyecto que cada parte entendía algo diferente por “entrega”.

6. Define cómo compararás a los proveedores

Elegir proveedor únicamente por precio puede ocultar diferencias importantes. Una matriz de evaluación ayuda a mantener criterios consistentes.

Criterio	Qué revisar
Experiencia	Si ha trabajado con necesidades y contextos comparables
Capacidad técnica	Perfiles, conocimientos y especialización disponibles
Metodología	Cómo realizará diagnóstico, ejecución y seguimiento
Alcance	Qué incluye y qué queda explícitamente fuera
Continuidad	Cómo atenderá cambios, incidencias o necesidades posteriores
Comunicación	Responsables, reuniones y reportes
Riesgo	Qué ocurre ante indisponibilidad, cambios o incidentes
Documentación	Qué evidencia quedará después del servicio
SLA	Cómo se definirán atención, prioridad y escalamiento cuando corresponda
Costo	Qué incluye el precio y qué podría generar cargos adicionales

No necesariamente todos los criterios tendrán el mismo peso. Una empresa puede priorizar experiencia y continuidad en un servicio crítico, mientras que en otro proyecto puede valorar más velocidad, especialización o flexibilidad.

Lo importante es definir esos criterios antes de recibir las propuestas.

7. No preguntes únicamente cuánto demorará: pregunta cómo trabajará

Dos proveedores pueden prometer el mismo plazo y tener formas completamente diferentes de llegar al resultado. Conviene preguntar:

• cómo realizará el levantamiento inicial;
• quién será responsable del proyecto;
• con qué frecuencia reportará avances;
• cómo gestionará cambios;
• cómo documentará decisiones;
• qué información necesitará del cliente;
• cómo gestionará bloqueos;
• cómo realizará el cierre.

Estas preguntas ayudan a evaluar algo que normalmente no aparece en una comparación económica: la capacidad del proveedor para trabajar con tu equipo.

8. Define el modelo de comunicación y seguimiento

La relación no debería empezar con una reunión inicial y reaparecer únicamente cuando existe un problema.

El RFP puede especificar cómo espera la empresa mantener visibilidad sobre el servicio. Por ejemplo:

• responsable principal de cada lado;
• frecuencia de reuniones;
• tipo de reporte;
• seguimiento de pendientes;
• gestión de incidentes;
• canales de comunicación;
• procedimiento de escalamiento.

Esto es particularmente importante en servicios continuos o proyectos que involucran varias áreas.

La tecnología importa, pero también importa qué tan rápido pueden ambas partes entenderse cuando aparece una excepción.

9. Si necesitas un SLA, define primero qué significa cada tiempo

Pedir simplemente un “SLA de cuatro horas” puede generar más dudas de las que resuelve.

¿Son cuatro horas para responder? ¿Para comenzar a trabajar? ¿Para resolver? ¿Aplica a todos los incidentes?

Si el servicio requiere acuerdos de nivel de servicio, conviene diferenciar conceptos como:

• prioridad;
• severidad;
• tiempo de respuesta;
• tiempo de atención;
• objetivo de resolución;
• horario de cobertura;
• procedimiento de escalamiento.

También debe definirse qué información necesita proporcionar el cliente para que esos tiempos puedan medirse correctamente.

El objetivo no es pedir el SLA más bajo posible. Es establecer un compromiso que tenga sentido para la criticidad real del proceso.

10. Pregunta qué ocurre después de la entrega

Una de las preguntas más útiles en la selección de proveedor es:

¿Qué ocurre cuando el proyecto termina o cuando el servicio entra en operación?

Dependiendo del caso, puede existir:

• estabilización;
• acompañamiento inicial;
• correcciones;
• soporte;
• capacitación;
• documentación;
• transferencia de conocimiento;
• revisiones posteriores.

Este punto permite distinguir una entrega puntual de una relación donde el proveedor también considera la continuidad del cliente.

En servicios tecnológicos, resolver el requerimiento inicial es importante. Pero también lo es evitar que el conocimiento quede únicamente en las personas que ejecutaron el proyecto.

Un RFP también debe mantenerse actualizado

Los procesos cambian. Un requerimiento que era válido hace dos años puede dejar de representar cómo opera actualmente una empresa.

En uno de los estudios revisados para este artículo, al actualizar un RFP asociado a un proyecto ERP se encontraron 78 requerimientos existentes, de los cuales 60 necesitaban mayor claridad. El análisis posterior permitió además incorporar nuevos requerimientos que no estaban contemplados originalmente.

El aprendizaje es importante:

un RFP no debería copiarse de un proyecto anterior sin comprobar primero si el proceso sigue siendo el mismo.

Si cambió la operación, el documento también debería cambiar.

No necesariamente todos los criterios tendrán el mismo peso. Una empresa puede priorizar experiencia y continuidad en un servicio crítico, mientras que en otro proyecto puede valorar más velocidad, especialización o flexibilidad.

Lo importante es definir esos criterios antes de recibir las propuestas.

Checklist para preparar un RFP de servicios TI

Elemento	Revisado
Problema que necesita resolver la empresa	☐
Situación actual o AS-IS	☐
Objetivo esperado	☐
Procesos y áreas involucradas	☐
Sistemas relacionados	☐
Alcance del proveedor	☐
Exclusiones	☐
Requerimientos funcionales	☐
Requerimientos técnicos	☐
Entregables	☐
Cronograma esperado	☐
Perfiles o especialidades necesarias	☐
Modelo de comunicación	☐
Gestión de riesgos	☐
SLA, cuando corresponda	☐
Documentación requerida	☐
Soporte o acompañamiento posterior	☐
Criterios para comparar propuestas	☐
Estructura económica	☐

Un buen RFP ayuda a comparar mejor, pero también a trabajar mejor

El valor de un RFP no termina cuando se selecciona al proveedor.

Una necesidad bien definida reduce interpretaciones distintas, facilita el seguimiento y permite volver al documento cuando aparece una duda sobre alcance, responsabilidades o resultados esperados.

La documentación que utilizamos como referencia para este artículo plantea justamente una secuencia útil: identificar los procesos afectados, comprender el estado actual mediante un análisis AS-IS y después convertir esa información en requerimientos funcionales y técnicos para el RFP.

El objetivo final no debería ser obtener la propuesta más extensa.

Debería ser recibir propuestas que respondan al mismo problema, permitan comparar criterios relevantes y ayuden a tomar una decisión con mayor claridad.