Propósito de un Buen Documento de Solicitud de Propuestas (RFP)
El objetivo de un RFP no es obtener un precio. Su finalidad es recibir ofertas comparables e identificar qué proveedor ha comprendido el problema. Un documento que detalla cien requisitos y busca una marcación de "compatible / no compatible" produce el efecto contrario: todos los proveedores marcan "compatible" y la decisión recae en el precio.
Diferencia práctica: en lugar de escribir "el sistema debe permitir la gestión de oportunidades", describa que la empresa gestiona aproximadamente cuatrocientas transacciones al mes, que cada transacción pasa por una aprobación de precios, y que la aprobación se realiza actualmente por correo electrónico. Los proveedores devolverán respuestas muy diferentes, y esa es precisamente la cuestión.
Las Nueve Secciones de un Documento RFP para Salesforce
1. Antecedentes y Objetivo de Negocio. Qué hace la organización, cuál es el problema y qué se consideraría un éxito dentro de un año. De un párrafo a una página.
2. Estado Actual. Sistemas en uso, número de usuarios, qué funciona y qué no. Si existe un entorno Salesforce, especifique la edición, antigüedad y nivel de personalización.
3. Procesos Centrales en Ámbito. De tres a siete procesos, cada uno en un párrafo: quién los ejecuta, cuáles son los puntos de decisión, qué ocurre si algo se desvía.
4. Volúmenes y Datos. Número de registros en cada entidad central, tasa de creación mensual, años de historial a conservar y estado conocido de la calidad. Esta es la sección que más influye en la precisión del pricing y la que más se suele omitir.
5. Integraciones. Para cada sistema: nombre, tipo de interfaz si se conoce, dirección, frecuencia requerida y propietario en la organización.
6. Restricciones. Regulación, seguridad de la información, ubicación de almacenamiento, idiomas, accesibilidad, plazos inamovibles.
7. Qué se Requiere del Candidato. Enfoque propuesto, plan de fases, composición del equipo con nombres y roles, premisas, riesgos y precio con una estructura predefinida.
8. Método de Evaluación. Criterios y ponderaciones, publicados de antemano. Esto genera propuestas enfocadas y reduce las objeciones después de la adjudicación.
9. Calendario del Concurso. Fecha límite para preguntas, fecha límite para respuestas, fecha límite para la presentación, fecha de demostraciones, fecha de decisión.
Datos que Deben Revelarse para Obtener un Pricing Real
| Dato | Por qué es Crítico | Qué Sucede Sin Él |
|---|---|---|
| Número de usuarios por tipo | Determina licencia, capacitación y permisos | Propuestas con un rango demasiado amplio |
| Volumen y historial de registros | Determina el esfuerzo de migración | La migración se cotiza con una estimación burda |
| Número de sistemas fuente | Determina la complejidad e integración | Sorpresas después de la firma |
| Nivel de documentación existente | Determina cuánto descubrimiento se requiere | Los proveedores asumen documentación existente |
| Disponibilidad de los propietarios de procesos | Determina el ritmo de las decisiones | Calendario irreal acordado por ambas partes |
| Presupuesto o rango | Enfoca la solución | Propuestas incomparables |
Preguntas que Distinguen a los Proveedores
Las siguientes preguntas reciben respuestas muy diferentes de distintos proveedores, lo que las hace útiles. Una pregunta a la que todos responden igual no merece un lugar en el documento.
- ¿Cuáles son las tres suposiciones principales en las que se basa la propuesta y cuál es la implicación si alguna de ellas es incorrecta?
- ¿En qué casos recomendaría la configuración, aunque el desarrollo funcionaría mejor, y viceversa?
- Describa un proyecto en el que se haya excedido del cronograma. ¿Qué lo causó y qué ha cambiado desde entonces?
- ¿Quiénes serán los miembros del equipo que trabajarán en el proyecto y qué porcentaje de tiempo dedicará cada uno a este proyecto?
- ¿Qué necesitan de nosotros para tener éxito y qué harán si no lo reciben?
- ¿Cómo nos transferirán la capacidad de mantener el sistema sin ustedes?
La última pregunta es una buena prueba de la naturaleza de la relación. Un proveedor que la evade planea la dependencia.
Qué Solicitar como Resultado Dentro de la Propuesta
- Diagrama de arquitectura preliminar a nivel de bloques, incluyendo fuentes de verdad.
- Plan de fases con el contenido de cada fase y no solo fechas.
- Detalle del precio con una estructura uniforme que usted dicte, por fase y por rol.
- Lista explícita de suposiciones.
- Mapa de riesgos con un plan de mitigación.
- Ejemplo de un producto real de un proyecto anterior, con nombres ocultos, por ejemplo, un documento de decisiones o un plan de prueba.
El último elemento es quizás el más distintivo, ya que muestra un estándar de trabajo y no una promesa.
Estructura de Precios Uniforme: La Herramienta para Prevenir la Comparación de Elementos Dispares
Defina usted mismo la tabla que todo proponente debe completar:
| Fase | Horas Sénior | Horas Júnior | Costo | Qué se Considera Completado |
|---|---|---|---|---|
| Levantamiento de Requisitos | ||||
| Configuración y Desarrollo de la Fase 1 | ||||
| Integraciones | ||||
| Migración de Datos | ||||
| Pruebas y UAT | ||||
| Capacitación y Adopción | ||||
| Estabilización Post-Go-Live | ||||
| Gestión del Proyecto |
Un proveedor que se niega a desglosar el precio según esta estructura no es necesariamente costoso, pero es imposible compararlo, y esta es una razón suficiente para pedirle la reconsideración.
Ejemplo Ilustrativo: Fondo de Pensiones Mediano
El escenario es hipotético y tiene fines ilustrativos. Una entidad financiera emitió un RFP que incluía ochenta requisitos funcionales en una tabla. Los cuatro proponentes marcaron "compatible" en casi todas las líneas, y las ofertas solo se diferenciaban en el precio y el número de horas.
En una segunda ronda, el documento se modificó: en lugar de la tabla de requisitos, se incluyeron tres procesos completamente descritos, datos de volumen reales y una solicitud para resolver un escenario en la demostración. Las propuestas recibidas diferían materialmente entre sí: una proponía un modelo de datos completamente diferente, otra identificó una dependencia de la aprobación regulatoria que nadie había considerado.
El comité no eligió la oferta más barata ni hizo objeciones. Eligió la que mejor pudo explicar por qué el séptimo requisito del documento original no era necesario en absoluto.
Errores Comunes al Redactar un RFP
- Copiar un documento de otro proyecto sin ajustar volúmenes y procesos.
- Solicitar una lista de clientes en lugar de ejemplos de productos.
- Criterios de evaluación redactados después de recibir las propuestas.
- Un cronograma que no deja tiempo para preguntas y respuestas.
- Preferencia encubierta por un proveedor existente, lo que hace que otros inviertan en vano y perjudica la calidad de las futuras propuestas.
Qué Sucede Después de la Presentación
Un buen documento es solo la mitad del trabajo. El siguiente paso es la normalización y comparación de las propuestas sobre la misma base, como se detalla en la guía de comparación de propuestas de Salesforce, y luego una puntuación estructurada según ponderaciones predefinidas, como se detalla en la guía de Scorecard para la selección de proveedores.
La base de información para la redacción del documento en sí proviene a menudo de un proceso de consultoría breve, como se describe en la guía de consultoría de Salesforce, y los criterios para evaluar a la empresa se resumen en la guía para elegir una empresa de implementación.
Siguiente Paso
Antes de enviar el documento, realice una última comprobación: déjelo leer a alguien de la organización que no esté involucrado en el proyecto y pídale que explique en una frase cuál es el problema que intenta resolver. Si no puede, los proveedores tampoco podrán, y simplemente devolverán lo que están acostumbrados a vender.