Por qué es casi imposible comparar propuestas de Salesforce
Al examinar tres propuestas y constatar una diferencia de decenas de puntos porcentuales, el primer instinto es considerar que una de ellas está inflada. En la mayoría de los casos, la razón es más simple: cada propuesta cotiza un proyecto diferente.
Un proveedor incluyó la migración de tres años de historial, mientras que otro asumió un año. Uno contempló seis semanas de estabilización después de la puesta en marcha, el otro entregó y finalizó. Uno calculó cuatro integraciones, el otro dos, asumiendo que un informe diario reemplazaba una interfaz en tiempo real. Ninguno de ellos engañó, simplemente no se les indicó lo contrario.
La comparación, por lo tanto, comienza con la normalización, no con una tabla de precios.
Método de normalización en seis pasos
1. Establezca una lista uniforme de componentes. Once líneas son suficientes: definición de requisitos, configuración, desarrollo, integraciones, migración, pruebas, capacitación, gestión de proyectos, estabilización, documentación, transferencia de conocimiento.
2. Indique para cada propuesta qué está incluido, qué es parcial y qué falta. No complete montos en esta etapa.
3. Valore lo que falta. Para cada componente no incluido en una propuesta, utilice el costo de otra propuesta como estimación y añádalo.
4. Estandarice las suposiciones. Número de usuarios, edición, años de historial, número de unidades de negocio, idiomas.
5. Estandarice el período de garantía. Un período diferente equivale a dinero. Una diferencia de dos meses en la estabilización es un componente de costo real.
6. Calcule el costo promedio por hora y la composición del equipo en cada etapa, no solo el total.
Solo después de estos seis pasos se pueden comparar las cifras. En muchos casos, la propuesta que parecía más económica pasa a segundo lugar.
Componentes que desaparecen de las propuestas y aparecen en la factura
| Componente | Por qué se omite | Magnitud relativa |
|---|---|---|
| Limpieza de datos previa a la migración | Se considera responsabilidad del cliente | A veces muy significativo |
| Segunda ronda de UAT | Se asume una sola ronda | Baja pero bloquea el cronograma |
| Capacitación por rol | Se cotiza como un único taller | Media |
| Soporte intensificado en las primeras semanas | No definido | Medio a alto |
| Documentación propiedad de la organización | Se asume como algo obvio | Baja, crítica a futuro |
| Manejo de errores de integración y monitoreo | Solo se incluye el "camino feliz" | Medio |
| Entornos y DevOps | Se asume su existencia | Bajo a medio |
| Horas de gestión interna de la organización | No incluido en la propuesta | Alto, y siempre presente |
El último punto es el que más sorprende a la dirección. Un proyecto de Salesforce consume una cantidad significativa de tiempo de los responsables de procesos y de la PMO, y este es un costo real, aunque no aparezca en ninguna factura.
De la comparación de precios a la comparación de costos a tres años
Una propuesta se evalúa correctamente en un período de tres años, no solo durante la duración del proyecto. Una estructura de cálculo sencilla:
| Componente | Año 1 | Año 2 | Año 3 |
|---|---|---|---|
| Costo de implementación | Completo | — | — |
| Licenciamiento | Según número de usuarios | Incluye crecimiento esperado | Incluye crecimiento esperado |
| Mantenimiento y soporte | Parcial | Completo | Completo |
| Mejoras planificadas | — | Alcance estimado | Alcance estimado |
| Costo de gestión interna | Alto | Medio | Medio |
La diferencia entre las propuestas en el primer año puede parecer grande. A lo largo de tres años, lo que suele prevalecer es la facilidad con la que se podrá modificar el sistema sin depender del proveedor, es decir, la calidad de la documentación y la transferencia de conocimiento, que casi nunca se ponderan en la decisión.
Señales de alerta en una propuesta
- La migración de datos se cotiza con una suma global sin preguntas sobre el volumen o la calidad.
- No hay período de garantía, o se define como "solución de errores" sin especificar qué constituye un error.
- Una propuesta que incluye solo horas de desarrollo y no tiene una línea de gestión de proyectos.
- Composición del equipo sin nombres, o nombres no comprometidos contractualmente.
- Un precio particularmente bajo para la fase de definición de requisitos, que a veces es una puerta de entrada a un proyecto que luego se cotizará más alto.
- No hay suposiciones explícitas. Una propuesta sin suposiciones es una propuesta no revisada.
Ejemplo ilustrativo: empresa de energía renovable
El escenario es hipotético y tiene fines ilustrativos. Una empresa recibió tres propuestas. La diferencia entre la más económica y la más costosa era de aproximadamente el ochenta por ciento. El comité se inclinó por la más económica.
Después de la normalización, se hizo evidente: la propuesta económica no incluía migración alguna, sino solo la carga de registros de actividad; asumía dos integraciones en lugar de cuatro, porque consideraba que el informe financiero se realizaría mediante exportación manual; y el período de garantía era de dos semanas frente a ocho semanas en la propuesta más costosa.
Después de complementar los costos faltantes con los de los otros proveedores, la diferencia se redujo a aproximadamente un diez por ciento. La decisión final no se basó en el precio, sino en determinar qué proveedor ofrecía una transferencia de conocimiento estructurada, ya que la empresa no contaba con un equipo interno.
Qué hacer con la brecha restante
Después de la normalización, generalmente queda una brecha real. Transforme esto en preguntas y no en suposiciones:
- ¿Por qué su estimación para la integración es menor que la de otros? ¿Qué saben ustedes que ellos no saben?
- ¿Qué sucede si la suposición sobre la calidad de los datos no es correcta?
- ¿Cuántos ciclos de prueba planificaron?
- ¿Quién del equipo presentado acompañará el proyecto de principio a fin?
Las respuestas a estas preguntas distinguen entre un proveedor que cotizó a bajo precio por ser eficiente y un proveedor que cotizó a bajo precio por no comprender.
Conexión con la decisión final
Una comparación estructurada solo aborda el aspecto comercial. El aspecto profesional se evalúa por separado, según ponderaciones predefinidas, y el precio es solo uno de ellos; los detalles se encuentran en la guía para elegir una empresa de implementación de Salesforce. La comprensión de lo que compone el costo desde el principio se detalla en la guía sobre el costo de implementación de Salesforce, y la elección del modelo de contratación en la guía de precios de proyectos.
Lo acordado en la comparación debe reflejarse en el contrato con una redacción precisa; de lo contrario, no existe. Las cláusulas relevantes se encuentran en la guía de contrato y SOW de Salesforce.
Próximo paso
Construya la tabla de normalización antes de abrir las propuestas económicas. Quien la construye después de haber visto los montos, la construye, sin intención, de manera que justifique la propuesta que ya le ha agradado.