¿Qué debe estar sobre la mesa el día después de la fase de definición ("blueprint")?
La definición de un CRM se mide por los entregables que permiten trabajar, no por la cantidad de reuniones. Si al finalizar la fase el director de proyecto aún no puede elaborar un plan de trabajo, el desarrollador aún desconoce qué objeto contiene el proceso, y el director de datos aún no sabe de dónde proviene el cliente — la definición no ha concluido, incluso si la presentación fue aprobada.
Esta guía define siete entregables. Cada uno tiene un criterio de madurez: una frase a la que se puede responder con "sí" o "no". Quien responda "aproximadamente" a más de dos de ellos, inicia la fase de construcción con un riesgo que ya se puede cuantificar. La visión general de las fases posteriores a la definición se encuentra en la Guía de Implementación de Salesforce.
Entregable 1: Mapa de procesos a nivel de decisión
No se trata de un diagrama de flujo de cada clic, sino de un mapeo de los puntos de decisión: quién decide, en base a qué información, qué sucede en cada ramificación y qué ocurre cuando no hay decisión. La mayoría de los fallos en proyectos de CRM no residen en la ruta principal, sino en las ramificaciones: un negocio que se congela, un cliente que regresa después de dos años, una consulta abierta por el cliente equivocado.
Criterio de madurez: Es posible tomar un negocio real del último mes y seguirlo en el mapa de principio a fin sin encontrar un vacío.
Entregable 2: Glosario de términos de negocio
Este es el entregable más subestimado y por cuya ausencia más se paga. "Cliente" significa algo diferente en el departamento financiero y en ventas. "Proyecto activo" significa algo distinto en operaciones y en la dirección. Mientras las definiciones no estén escritas, cada informe generará una discusión.
El glosario debe contener, para cada término: una definición en una frase, la entidad en Salesforce que lo representa, el campo que determina el estado y el departamento que mantiene la definición.
Entregable 3: Modelo de datos central decidido
En la fase de definición no se construye un ERD completo, pero sí se deciden las cuatro preguntas cuyo cambio a posteriori es costoso:
- Si la actividad comercial reside en un Opportunity, en un objeto personalizado o en una combinación, y cuál es la relación entre ellos.
- Si una Account representa una entidad legal, un sitio físico o un grupo de compra, y cómo se maneja la jerarquía.
- Cuál es la clave única que identifica a un cliente entre Salesforce y los sistemas centrales.
- Qué datos históricos ingresan al sistema y cuáles permanecen en la fuente.
Criterio de madurez: Es posible dibujar en una pizarra los cinco objetos principales y sus relaciones sin abrir un archivo.
Entregable 4: Modelo de permisos y visibilidad
El modelo de permisos se deriva de la pregunta sobre quién no debe ver qué, no de la pregunta sobre quién debe ver qué. Ambas preguntas parecen idénticas y conducen a arquitecturas opuestas. Una buena definición establece el valor predeterminado organizacional para cada objeto principal, el mecanismo de extensión y los casos que requieren una visibilidad excepcional.
| Pregunta | Qué se verifica en la definición | Por qué es costoso cambiarlo después |
|---|---|---|
| Valor predeterminado para el objeto | Private, Public Read o Read/Write | Afecta a todo el mecanismo de compartir por encima |
| Estructura de jerarquía | Si la jerarquía de roles refleja administración o geografía | Un cambio requiere recalcular el acceso en todos los registros |
| Visibilidad entre unidades | Equipos compartidos, compartición manual o criterio | Determina si se necesita una lógica dedicada |
| Datos sensibles | Qué campos están restringidos y para quién | Un cambio posterior expone información que ya ha sido vista |
Entregable 5: Mapa de sistemas y fuentes de verdad
Cada entidad central debe tener una única y declarada fuente de verdad, y una dirección de sincronización clara. Un planteamiento que deja a dos sistemas "actualizándose mutuamente" crea conflictos que solo se descubrirán en producción. El mapa también debe incluir la frecuencia y la tolerancia al retraso: un proceso de ventas puede tolerar una sincronización de cinco minutos, el control de crédito generalmente no.
Entregable 6: Criterios de aceptación para los procesos clave
Este es el nexo entre la definición y las pruebas. Para cada proceso clave, se requieren entre tres y cinco condiciones de aceptación formuladas como un resultado observable: "Después de cerrar un negocio, se crea un pedido en el sistema central en un plazo de cinco minutos, con el mismo identificador de cliente". Tal formulación es a la vez un requisito, un escenario de prueba y una definición de finalización. Sin esto, la fase de UAT se convierte en una ronda de comentarios de diseño.
Entregable 7: Indicadores de base antes del cambio
Es imposible demostrar una mejora sin una medición previa. En la definición, se eligen entre tres y cinco indicadores y se miden de forma real en la situación actual, incluso si la medición es manual y aproximada. La selección de los indicadores y la forma de conectarlos con el beneficio empresarial se detallan en la Guía de ROI y KPI de Éxito.
Ejemplo ilustrativo: Cadena de clínicas privadas
El siguiente escenario es hipotético y solo tiene fines ilustrativos. Una cadena de clínicas con ocho sucursales abordó un proyecto de CRM para centralizar las consultas de pacientes. Durante la definición, se descubrió que dos sucursales definían "consulta recurrente" de manera diferente: una contaba cada llamada, la otra solo las consultas sobre un tema nuevo. La diferencia parecía semántica, pero determinaba si el sistema necesitaba un solo objeto Case con una jerarquía o dos objetos separados, y definía todos los informes de carga de trabajo de la dirección.
El equipo no zanjó la disputa en el documento. Registró una decisión abierta, definió un propietario a nivel de director de operaciones y una fecha límite antes del inicio de la construcción. La decisión se tomó en dos semanas, y el modelo se construyó una sola vez. Si la decisión se hubiera pospuesto, se habría descubierto en la fase de UAT, después de que se hubieran construido pantallas e informes basándose en una suposición incorrecta.
Señales de advertencia de una definición superficial
- El documento describe pantallas y campos, pero no describe qué sucede cuando un proceso falla.
- No hay ninguna decisión documentada para la cual se hayan considerado alternativas.
- Todos los requisitos tienen una alta prioridad.
- No hay un nombre de persona junto a ningún proceso, solo un nombre de departamento.
- La cantidad de campos solicitados en una pantalla supera los veinticinco sin que nadie haya verificado quién los llena.
La conexión entre una definición superficial y los patrones de fallo que aparecen más adelante en el proyecto se detalla en la Guía de Errores Comunes de Implementación de CRM, y su impacto en el cronograma se explica en la Guía de Duración de Proyectos Salesforce.
Cuando se trata de reemplazar un sistema existente
Cuando el proyecto reemplaza un CRM antiguo, la definición asume una tarea adicional: decidir qué no se transfiere. Un sistema antiguo acumula campos, automatizaciones e informes que nadie usa ya, y su duplicación ciega importa la deuda técnica anterior a una nueva plataforma. El orden de operaciones recomendado en dicha migración se detalla en la Guía para Reemplazar un CRM con Salesforce.
¿Cómo saber que puede comenzar la construcción?
Revise los siete entregables y pregunte la cuestión de madurez para cada uno. Si seis de siete responden que sí, se puede comenzar con la primera fase, gestionando la séptima discrepancia como un riesgo documentado. Si tres o más responden "aproximadamente", es preferible extender el período de definición dos semanas que descubrir la discrepancia después de haber invertido tres meses de trabajo basándose en ella.
El siguiente paso natural es traducir los entregables a un plan de fases, con una decisión explícita sobre qué se incluye en la primera fase y qué se pospone conscientemente.