Migrar un CRM a Salesforce puede complicarse por decisiones que al principio parecen menores: reproducir los procesos actuales sin revisarlos, trasladar información sin comprobar su calidad o dejar la preparación de los usuarios para el final. Sin una metodología que permita detectar y corregir estos problemas a tiempo, el proyecto puede acumular retrasos y sobrecostes, comprometer la protección de los datos o dar lugar a un sistema difícil de mantener y que los equipos apenas utilicen.
En ALTIA entendemos la migración a Salesforce como una oportunidad para revisar cómo trabaja la organización, aprovechar las capacidades de la plataforma y construir una solución que responda a las necesidades reales del negocio. Para ello, combinamos conocimiento funcional y tecnológico con una metodología que incorpora las buenas prácticas de Salesforce: entender cómo se trabaja, mostrar las capacidades estándar antes de decidir los ajustes y validar la solución con quienes van a utilizarla.
Las decisiones que pueden comprometer una migración
- Cerrar el alcance antes de entender el trabajo. Una lista de peticiones cuenta solo una parte de la historia: puede dejar fuera una aprobación que se hace por correo, un informe que alguien corrige a mano o una conexión con otra aplicación. Entender el proceso completo antes de definir el alcance evita que estas necesidades aparezcan demasiado tarde.
- Pedir un diseño a quienes aún no conocen Salesforce. Sin una referencia de lo que ofrece el producto, es comprensible que los usuarios pidan las mismas pantallas y reglas que utilizan hoy. El problema llega cuando cada hábito se convierte en un desarrollo a medida que habrá que pagar, probar y mantener.
- Abordar las conexiones y la protección de datos tarde. Trasladar datos sin decidir qué aplicación los mantiene, quién puede consultarlos o para qué se usarán crea problemas que una configuración aislada de Salesforce no resuelve. La arquitectura, la integración, la calidad y la protección del dato deben formar parte del diseño desde el principio.
- Confundir rapidez con falta de control. Las mejoras sencillas pueden aportar valor pronto o generar problemas si se acumulan sin revisar cómo afectan al resto. Con la inteligencia artificial, además, una prueba de concepto debe demostrar su utilidad, coste y encaje en el trabajo real antes de escalar.
- Comprobar los datos sin probar el trabajo. Que una oportunidad comercial aparezca en Salesforce no significa que el equipo pueda gestionarla bien. La validación debe reproducir procesos completos, no limitarse a comprobar que los datos se han cargado correctamente.
- Llegar a la fecha de arranque sin haber ensayado. El calendario marca un objetivo, pero no resuelve una conexión que falla ni explica cómo recuperar la actividad. Una puesta en marcha controlada requiere un plan probado, responsables definidos y un escenario de recuperación.
- Dar el proyecto por cerrado demasiado pronto. Las primeras semanas revelan dudas y dificultades que no siempre aparecen en las pruebas. El soporte posterior permite estabilizar la solución, recoger aprendizajes y priorizar su evolución.
Cómo abordamos una migración a Salesforce en ALTIA
Organizamos el proyecto en siete fases, desde el diagnóstico inicial hasta la estabilización y evolución de la solución. Primero entendemos la situación actual; después mostramos Salesforce y acordamos cómo se trabajará. A partir de ahí, construimos y probamos entregas progresivas hasta preparar la puesta en marcha y el acompañamiento posterior. La seguridad, la protección de datos y la calidad de la información acompañan todo el recorrido.
Nuestro equipo Salesforce coordina este recorrido con nuestras áreas transversales. Data analytics ayuda a organizar y aprovechar la información; ciberseguridad a prevenir amenazas y responder a incidentes; cumplimiento normativo, a definir un uso adecuado de los datos; o el área inteligencia artificial en caso de ser necesaria. Así, incorporamos las capacidades necesarias en función de las necesidades de cada proyecto, manteniendo una visión única de la solución.
1. Comprender cómo se trabaja y establecer las prioridades
hablar con las personas que hacen el trabajo y con quienes necesitan sus resultados. Revisamos ejemplos reales con negocio, operaciones y tecnología: cómo se atiende una solicitud, quién aprueba una operación o de dónde sale un informe, además del seguir el trabajo que queda fuera del CRM. Importa entender el motivo de cada paso. Una comprobación manual puede proteger una decisión relevante o limitarse a compensar una carencia del sistema anterior. Distinguir ambas situaciones permite decidir qué mantener, qué simplificar y qué transformar.
Con esa visión identificamos a los responsables de los datos, los problemas de calidad y la información que requiere mayor protección. También acordamos indicadores de partida, responsables de decisión y usuarios clave para la validación.
Es en esta fase cuando identificamos los quick wins: mejoras con capacidad de aportar valor con un esfuerzo limitado y que pueden incorporarse a la hoja de ruta si su viabilidad está contrastada.
2. Mostrar Salesforce y acordar la forma futura de trabajar
Los usuarios pueden decidir mejor cuando han visto el sistema. Por eso, organizamos sesiones prácticas en las que mostramos procesos de Salesforce antes de completar la configuración.
El objetivo no es replicar el CRM anterior, sino explorar cómo Salesforce puede resolver las necesidades del negocio de una forma más sencilla, conectada y escalable.
¿Qué trabajamos en cada workshop?
- Recorrer los procesos que ofrece Salesforce. Mostramos cómo se pueden gestionar procesos relevantes para el negocio y qué capacidades de la plataforma pueden aprovecharse.
- Comparar con el trabajo actual. Los usuarios identifican qué aporta Salesforce, qué tareas pueden simplificarse y qué cambios requerirá la forma de trabajar. Se prueban también las excepciones que tienen valor para el negocio.
- Clasificar las diferencias. Acordamos qué cubre Salesforce directamente, qué necesita ajustes, qué exige cambiar un proceso y qué requiere una solución a medida que deba evaluarse aparte.
- Cerrar decisiones. Cada sesión deja una descripción actualizada de cómo se trabajará, decisiones justificadas, cuestiones pendientes con responsable y condiciones claras para aceptar las mejoras propuestas.
Este trabajo permite tomar decisiones con una visión compartida entre negocio y tecnología y evita convertir cada particularidad del sistema anterior en un desarrollo a medida.
3. Diseñar la solución y proteger la información
Antes de construir, hay que resolver cómo encajará Salesforce en la organización. Estas decisiones dan forma a la arquitectura de la solución, aunque sus efectos se notarán en cuestiones muy cotidianas: qué dato es correcto, cuánto tarda una consulta o quién puede ver un documento.
- Cada aplicación debe tener un cometido claro. Acordamos qué procesos resuelve Salesforce y dónde se mantiene la información de referencia. Si el dato de facturación pertenece a otro sistema, habrá que conectarlo de forma coherente, sin crear dos versiones que compitan entre sí.
- Las conexiones deben contemplar los fallos. Parte de la información necesita actualizarse al momento, otra puede esperar. En ambos casos, debe estar previsto cómo detectar una interrupción y recuperar el intercambio sin perder datos ni duplicarlos.
- Los datos necesitan orden y significado. Aprovechamos la estructura de Salesforce y definimos cómo se trasladan clientes, contactos, documentos e históricos. Además de corregir errores, acordamos qué mide cada indicador para evitar que dos informes den respuestas distintas a la misma pregunta.
- El diseño debe responder al uso previsto. Probamos qué ocurre cuando aumentan los usuarios y las operaciones simultáneas. Así se pueden corregir tareas que se solapan o ralentizan el trabajo antes de que afecten a todo el equipo.
- La protección se comprueba en la práctica. Cada persona debe acceder solo a lo que necesita. Definimos los usos y plazos de conservación de la información y revisamos los accesos reales. Los problemas detectados en la auditoría de seguridad se corrigen y se vuelven a comprobar.
4. Construir con calidad y entregar valor desde las primeras mejoras
Las primeras entregas deben ayudar al equipo a reconocer la utilidad del cambio. Priorizamos con negocio aquellas mejoras que pueden generar impacto desde las primeras fases y que aprovechan las capacidades estándar de Salesforce.
Antes de encargar un desarrollo a medida, comprobamos si la función ya existe y qué ajustes necesita. Si hace falta ampliarla, dejamos claro qué aporta y qué supondrá mantenerla. Los cambios se documentan y se prueban antes de llegar al sistema de uso diario. Estas pruebas incluyen situaciones habituales y excepcionales, permisos y operaciones simultáneas.
Cuando hay inteligencia artificial, la decisión de ampliar su uso depende de los resultados. Primero, comprobamos el caso con los datos disponibles; después, lo prueban usuarios en situaciones reales. Evaluamos utilidad, coste, errores y necesidad de supervisión antes de decidir cómo avanzar.
Cada entrega parte de una necesidad y unos criterios de aceptación claros y se incorpora cuando el resultado está validado y puede mantenerse.
5. Validar procesos completos y preparar a las personas
Una prueba útil reproduce el trabajo de principio a fin: el usuario localiza a un cliente, consulta una oportunidad, la actualiza y revisa cómo aparece en la previsión de ventas. Así validamos simultáneamente los datos, el proceso y la experiencia de usuario. También probamos situaciones excepcionales como conexiones interrumpidas, respuestas lentas, operaciones repetidas o accesos no autorizados.
La formación se apoya en la solución ya validada, para que los equipos aprendan sobre procesos y herramientas que realmente van a utilizar.
6. Preparar una puesta en marcha controlada
El día del cambio debe seguir un plan que ya se haya ensayado. Acordamos cuándo se dejará de trabajar en el sistema anterior, cómo se trasladará la información más reciente y quién comprobará que todo está disponible en Salesforce. También definimos cómo actuar ante una incidencia y qué condiciones permitirían detener o revertir el proceso.
El cliente autoriza la puesta en marcha con los resultados de las comprobaciones. Los usuarios saben desde qué momento deben trabajar en Salesforce y dónde pedir ayuda. El objetivo es que el paso a producción sea un cambio controlado y no el final de la preparación.
7. Estabilizar el servicio y organizar su evolución
Durante las primeras semanas atendemos las dudas y seguimos de cerca el funcionamiento. Algunas incidencias necesitan una solución inmediata, otras señalan una mejora que conviene planificar.
El uso real ofrece información que las pruebas no siempre muestran. Además de revisar la rapidez y las conexiones, observamos si los equipos mantienen actualizadas las oportunidades y si confían en los informes. Este seguimiento permite identificar nuevas oportunidades de mejora y priorizarlas en función de su impacto en el negocio.
Los permisos y los usos de la información cambian con el tiempo. Por eso, la revisión de accesos, controles y políticas forma parte también de la evolución de la solución
De una migración a una plataforma que evoluciona con el negocio
Una implantación bien resuelta se reconoce en el trabajo diario: los equipos entienden los procesos, pueden confiar en la información y saben a quién acudir cuando surge una duda.
Para llegar ahí, en ALTIA combinamos conocimiento del negocio, capacidades tecnológicas y acompañamiento durante todo el proyecto. Contrastamos las necesidades antes de cerrar el alcance, mostramos Salesforce antes de decidir sus ajustes y probamos el trabajo completo antes del arranque. El diseño y la protección de los datos acompañan esas decisiones.
Después seguimos junto al cliente hasta estabilizar la operación y transferir el conocimiento necesario. El resultado es una solución preparada para responder a las necesidades actuales y evolucionar con la organización.
