El problema empieza en el pedido, no en la ejecución
Cuando una organización contacta a un proveedor de Salesforce, la primera solicitud es casi siempre una "cotización para la implementación". En muchos casos, esta no es la solicitud correcta. Hay organizaciones que ya poseen un sistema y necesitan un diagnóstico; hay otras que aún no han definido el proceso que desean; y algunas tienen un sistema que funciona razonablemente, pero les falta la propiedad continua.
Solicitar un tipo de servicio incorrecto genera un proyecto que culmina en un resultado irrelevante, lo cual, a menudo, se descubre solo después de meses. Esta guía mapea los cuatro tipos de servicio según el síntoma que lleva a una organización a buscar ayuda.
Mapeo rápido por síntoma
| Lo que usted dice | Lo que probablemente se necesita | El resultado principal |
|---|---|---|
| "Trabajamos en Excel y queremos orden" | Definición funcional y luego implementación en fases | Mapa de procesos, modelo de datos, primera fase en producción |
| "Tenemos Salesforce pero nadie lo usa" | Health Check y plan de adopción | Informe priorizado de hallazgos y orden de corrección |
| "El sistema está lento y roto después de años" | Diagnóstico técnico y plan de deuda técnica | Mapeo de deuda, recomendación de refactorización o reconstrucción |
| "El proyecto está estancado desde hace seis meses" | Recuperación de proyecto | Evaluación de estado, decisión de continuidad, plan de estabilización |
| "Necesitamos alguien para el mantenimiento continuo" | Acompañamiento o Managed Services | SLA, ritmo de lanzamientos, punto de entrada para solicitudes |
| "El CEO quiere saber si Salesforce es adecuado" | Asesoramiento breve, no un proyecto | Dictamen y recomendación de idoneidad |
Esta tabla es suficiente para la mayoría de los casos. El resto del artículo detalla exactamente qué solicitar en cada servicio.
Servicio 1: Consultoría y Definición funcional
Cuándo solicitarlo: Cuando aún no está claro el proceso, cuál es la fuente de verdad y cuáles son los límites del proyecto; o cuando hay disputas internas entre departamentos.
Qué debe incluir el entregable: Un mapa de procesos a nivel de decisión, un modelo de datos central, un modelo de permisos, un mapa de sistemas, criterios de aceptación y métricas de referencia. Un entregable que no incluya los primeros cinco no es una definición funcional, sino un resumen de reuniones.
Alcance típico: Entre dos y ocho semanas, dependiendo del número de procesos interdepartamentales. Qué se debe exactamente recibir y cómo identificar a un buen consultor se detalla en la Guía de consultoría Salesforce.
Servicio 2: Implementación
Cuándo solicitarlo: Cuando la definición funcional existe, los responsables del proceso son conocidos y se ha decidido qué incluir en la primera fase.
Qué debe incluir el acuerdo: Definición de fases, criterios de aceptación para cada fase, responsabilidad sobre la migración de datos, mecanismo para solicitudes de cambio, período de garantía y plan de transferencia de conocimiento. La ausencia de los dos últimos es la causa común de dependencia a largo plazo del proveedor.
Señal de advertencia: Una propuesta que detalla un número de horas de desarrollo, pero no especifica qué se considera como "completado".
Servicio 3: Health Check y Diagnóstico
Cuándo solicitarlo: Cuando el sistema está operativo, pero algo no funciona, ya sea por baja adopción, datos no fiables, rendimiento o incapacidad para hacer cambios sin causar interrupciones.
Qué debe incluir el entregable: Una lista de hallazgos con su gravedad, impacto comercial, esfuerzo de corrección y orden recomendado. Un informe que enumera cincuenta hallazgos sin un orden de prioridad no es útil; un informe que dice "primero arregle estos tres y no toque los demás aún" es un producto.
Diferencia importante: Un Health Check no es un proyecto de reparación. Su propósito es permitir decidir qué reparar y en qué orden.
Servicio 4: Acompañamiento, Soporte y Managed Services
Cuándo solicitarlo: Cuando el sistema está en producción y no hay un equipo interno que pueda asumir la propiedad continua.
Qué debe estar definido: Qué se incluye y qué no. La distinción crítica es entre la solución de un error, un pequeño cambio de configuración y el desarrollo de una nueva funcionalidad. Un contrato que agrupa los tres en un "banco de horas" tiende a desbordarse en un trimestre, porque el desarrollo de nuevas funcionalidades consume las horas destinadas al soporte.
Además: Tiempos de respuesta según la gravedad, un ritmo constante de lanzamientos y la propiedad de la documentación.
Integración correcta entre los servicios
La mayoría de las organizaciones no consumen un solo servicio, sino una secuencia. La secuencia saludable se ve así:
- Consultoría breve para decidir la idoneidad — días, no semanas.
- Definición funcional enfocada para la primera fase.
- Implementación en fases.
- Un período de estabilización definido después del lanzamiento.
- Acompañamiento continuo.
- Health Check periódico, preferiblemente no realizado por quien construyó el sistema.
El sexto punto es el que se omite con mayor frecuencia, y es el más económico.
Ejemplo ilustrativo: Cadena de hoteles boutique
El escenario es hipotético y tiene fines ilustrativos. Una cadena con cuatro hoteles contactó a tres proveedores solicitando una cotización para implementar Salesforce para la gestión de eventos y solicitudes de huéspedes. Las dos primeras propuestas eran para una implementación completa, con un alcance de muchos meses.
El tercer proveedor hizo una pregunta: ¿Quién define lo que es un "evento"? ¿El gerente de eventos de cada hotel o la sede central? La respuesta fue que no hay una definición compartida. En tal situación, una implementación completa hubiera generado cuatro sistemas diferentes bajo un mismo nombre. La cadena solicitó en su lugar una definición funcional breve, obtuvo una definición única acordada y un modelo de datos, y solo entonces procedió a la implementación, con un alcance menor al propuesto originalmente.
Señales de advertencia al solicitar un servicio
- La propuesta valora horas, pero no define el entregable.
- La misma propuesta incluye definición funcional e implementación en una sola suma, sin un hito que permita detener el proyecto.
- No hay un período de garantía definido después de la entrega.
- No hay una cláusula de transferencia de conocimiento y documentación en propiedad de la organización.
- El proveedor se niega a proporcionar una opinión arquitectónica antes de firmar.
Las herramientas para evaluar al proveedor en sí —y no solo el servicio— se encuentran en la Guía para elegir una empresa de implementación de Salesforce.
Del pedido al documento
Después de decidir qué servicio se necesita, el siguiente paso es redactarlo de manera que las propuestas recibidas sean comparables. La estructura del documento de solicitud y la lista de preguntas que se deben incluir se detallan en la Guía de RFP para la implementación de Salesforce, y las cláusulas que deben incluirse en el acuerdo en sí se detallan en la Guía de Contrato y SOW de Salesforce.
El siguiente paso
Antes de solicitar una cotización, escriba en una frase el síntoma, no la solución. "No tenemos una vista unificada del cliente entre ventas y servicio" lleva a una solicitud diferente de "queremos Salesforce". Esta frase vale más que cualquier documento de requisitos que se redacte después.