Nuevo proyecto Salesforce
Implementación de Salesforce
Un proyecto nuevo no significa una empresa sin Salesforce. Puede ser la primera implementación, o un proceso, un equipo o una unidad de negocio que entra en un Salesforce que ya existe. Los dos casos requieren las mismas decisiones de partida y tienen restricciones muy distintas.
En ambos, el proyecto empieza por cómo trabajará el negocio, qué datos necesita y con qué sistemas debe convivir.
Primera implementación
Cuando Salesforce todavía no está en marcha
Tienes decidido que vas a usar Salesforce, o lo estás evaluando. La ventaja es que no hay nada que respetar; la dificultad es que todas las decisiones están abiertas a la vez y algunas son difíciles de revertir después.
Lo que más importa aquí es acotar bien la primera fase. Un alcance amplio parece más eficiente y en la práctica retrasa la puesta en marcha hasta que el equipo que lo pidió ha cambiado de prioridades.
Definimos los procesos, el alcance, los datos, las integraciones y el plan de adopción antes de configurar nada.
Trabajamos por fases con entregas utilizables, para que el criterio se corrija con uso real y no con suposiciones.
Elegimos las licencias y los productos según lo que hace falta, no al revés: primero el proceso, después el catálogo.
El equipo entra en el diseño desde el principio, cuando sus objeciones todavía pueden cambiar decisiones.
Sobre un Salesforce existente
Cuando ya hay algo en producción
Un proceso, un equipo, una unidad de negocio o una capacidad nueva sobre una organización que ya está funcionando. Aquí hay decisiones tomadas, datos históricos y costumbres de equipo, y todo eso es una restricción real.
La pregunta que gobierna el proyecto es cuánto de lo que ya existe se puede reutilizar sin forzarlo. Reutilizar un modelo que no encaja sale más caro que modelar el ámbito nuevo aparte, y al revés: duplicar lo que ya está resuelto crea dos fuentes de verdad.
Revisamos primero qué hay montado y por qué, para no romper procesos que están funcionando aunque no se documentaran.
Decidimos explícitamente qué se reutiliza y qué se modela aparte, con el criterio escrito.
Cuidamos que la coherencia se mantenga: permisos, nomenclatura, informes y automatizaciones tienen que seguir teniendo sentido de conjunto.
Si el proyecto destapa deuda que lo bloquea, lo decimos antes de empezar en lugar de construir encima.
Cómo lo hacemos
Seis fases, y la primera no es técnica
Entender el negocio
Cómo se vende, cómo se atiende, quién interviene y en qué orden. Antes de hablar de objetos y campos hay que saber qué decisión toma cada persona y con qué información.
Definir el alcance
Qué entra en la primera fase y qué se deja para después. Es la decisión que más condiciona el resultado: un alcance demasiado amplio retrasa la puesta en marcha hasta que el equipo pierde el interés.
Modelar los datos
Qué información necesita el negocio, de dónde viene, quién la mantiene y con qué sistemas debe convivir. Un modelo mal planteado se paga en cada evolutivo posterior.
Configurar y construir
Configuración primero, desarrollo solo donde se justifique. Cada personalización es código que hay que mantener con cada actualización de plataforma.
Integrar y migrar
Conectar los sistemas que aportan el dato y llevar el histórico que de verdad hace falta. Migrar todo por si acaso es la forma más rápida de arrancar con datos en los que nadie confía.
Poner en marcha con el equipo dentro
Formación pegada al arranque, acompañamiento en las primeras semanas y un canal para resolver lo que aparece. Es el tramo donde se decide si el proyecto se adopta o se abandona.
Qué ponemos en marcha
Los productos con los que trabajamos
La decisión de producto va después de la de proceso. Estas son las piezas de la plataforma con las que más trabajamos, y en un proyecto típico entran dos o tres, no todas.
Sales Cloud
Gestión de cuentas, oportunidades, previsión y canal, directo e indirecto. La base de la mayoría de los proyectos que arrancamos.
Service Cloud
Atención al cliente multicanal, gestión de casos y consola única de agente, con el historial completo del cliente a la vista.
Marketing Cloud y Account Engagement
Automatización de marketing para B2C y B2B: segmentación, journeys, campañas y medición de lo que aporta cada acción.
Experience Cloud
Portales de cliente, distribuidor o partner para compartir información y trabajar en conjunto sin abrir el CRM entero.
Data Cloud
Unificación del perfil de cliente cuando el dato está partido entre varios sistemas y ninguno tiene la ficha completa.
Platform y analítica
Aplicaciones a medida sobre la plataforma, e informes, cuadros de mando o Tableau para las preguntas que se hace la dirección.
Qué sale mal
Cuatro errores que vemos repetirse
Ninguno es un error técnico. Los cuatro son decisiones de gestión que parecen razonables cuando se toman y se pagan meses después.
Definir el alcance por catálogo
Recorrer la lista de funcionalidad decidiendo qué activar produce un sistema completo que no responde a ningún proceso concreto. El alcance sale del negocio, no del producto.
Dejar la adopción para el final
Si el equipo aparece el día de la formación, llega con el diseño ya cerrado y sin haber podido corregir nada. Tiene que entrar antes, cuando sus objeciones aún cambian algo.
Migrar todo el histórico
Arrastrar años de datos sucios contamina el sistema nuevo desde el primer día y destruye la confianza en los informes. Se migra lo que se va a usar.
Personalizar antes de probar
Muchas peticiones de desarrollo desaparecen cuando el equipo ha usado la configuración estándar unas semanas. Personalizar antes de ese momento es apostar sin información.
Cuéntanos qué proyecto tienes en mente
Con saber qué procesos quieres cubrir, qué sistemas tienes y quién va a usarlo podemos decirte por dónde empezaríamos y qué dejaríamos para una segunda fase.
Preguntas frecuentes
Preguntas frecuentes
¿Cuánto dura una implementación de Salesforce?
Depende del alcance. Los proyectos que tenemos documentados se movieron entre 17 y 26 semanas, repartidas en fases con entrega al final de cada una. Lo que más mueve ese plazo no es la configuración, sino cuántos procesos entran, cuántos sistemas hay que integrar y cuánto histórico se decide migrar.
¿Se puede implantar Salesforce por fases en lugar de todo a la vez?
Sí, y es como lo planteamos por defecto. Poner en marcha un alcance reducido que el equipo use de verdad da información que ningún taller de requisitos da: muchas peticiones de desarrollo desaparecen cuando el equipo ha usado la configuración estándar unas semanas. Personalizar antes de ese momento es apostar sin información.
¿Hay que migrar todo el histórico de datos al nuevo Salesforce?
No, y arrastrarlo entero suele ser un error. Años de datos sucios contaminan el sistema nuevo desde el primer día y destruyen la confianza en los informes, que es lo que sostiene el uso. Se migra lo que se va a usar.
¿En qué momento se forma al equipo en una implementación?
Pegada al arranque, no semanas antes. Formar al equipo mucho antes de que pueda usar lo aprendido garantiza que se olvide; la formación se coloca junto al momento en que el proceso entra en marcha, con acompañamiento en las primeras semanas y un canal para resolver lo que aparece. Es el tramo donde se decide si el proyecto se adopta o se abandona.