La respuesta breve
La pregunta central al implementar Salesforce en una organización no es “qué módulo activar primero”, sino cómo construir un camino donde cada etapa genere un entregable validable, y no solo una reunión más. Esta guía sigue ocho estaciones clave: Discovery, Diseño de Solución (Solution Design), Construcción Gradual, Migración, UAT, Capacitación, Puesta en Marcha (Go Live) y Soporte Intensivo (Hypercare). En cada estación, hay un entregable obligatorio, un aprobador y un riesgo principal que debe mitigarse antes de avanzar.
La idea central es una secuencia ineludible: no se puede construir sin un Diseño de Solución aprobado, y no se puede salir en vivo sin un UAT firmado por alguien con autoridad empresarial. Cuando se omite una estación, el problema no desaparece, solo se traslada a una etapa de corrección más costosa. Se puede encontrar información adicional sobre la decisión de reemplazar o no un sistema existente en Reemplazar un sistema CRM con Salesforce.
Mapa completo de las etapas
| Etapa | Entregable obligatorio | Quién aprueba | Riesgo principal |
|---|---|---|---|
| Discovery | Documento As-Is/To-Be, Línea Base y KPIs de éxito | Patrocinador de negocio y Propietario del Proceso | Definición de éxito vaga que solo se descubre en el UAT |
| Diseño de Solución | Modelo de datos, permisos, ADR y diagrama de integraciones | Arquitecto de Salesforce y CIO | Solución construida en torno a una solicitud puntual y no a un proceso |
| Construcción gradual | Segmento vertical (Vertical Slice) funcional en cada sprint, con Demo | Product Owner | Acumulación de un backlog "casi terminado" sin una definición de completitud |
| Migración | Resultado de un ensayo completo de migración (Migration Rehearsal) frente a criterios de calidad | Data Owner por objeto | Datos duplicados o faltantes que se descubren solo después de la carga a producción |
| UAT | Firma de los propietarios del proceso en los escenarios de extremo a extremo | Jefes de equipos de negocio | Pruebas superficiales que cubren solo el "Happy Path" |
| Capacitación | Plan de Habilitación (Enablement), materiales de capacitación y lista de Champions | Gerente de CRM | Usuarios que aprenden "sobre la marcha" y generan datos deficientes |
| Puesta en Marcha (Go Live) | Lista de verificación (Checklist) Go/No-Go firmada y plan de Rollback | Gerencia del Proyecto | Salir en vivo sin un plan de contingencia en caso de fallo |
| Soporte Intensivo (Hypercare) | Registro diario de incidentes y métrica de adopción frente a la Línea Base | Gerente de CRM y equipo de implementación | Cierre prematuro del proyecto, antes de que la adopción se haya estabilizado |
Discovery: antes de tocar las herramientas
La etapa de Discovery determina todo lo que vendrá después, y aun así es la etapa que más organizaciones acortan para "empezar a construir ya". El entregable requerido no es una presentación, sino un documento que incluye un proceso As-Is documentado, un objetivo To-Be y una lista explícita de lo que no se incluirá en la primera versión. Sin esta definición, cualquier nueva solicitud que llegue dos meses después será percibida como una parte "obvia" del proyecto.
La herramienta más práctica en esta etapa es una Línea Base medible: el tiempo de procesamiento de un lead, el porcentaje de negocios cerrados sin doble entrada, la tasa de campos vacíos en una ficha de cliente. Sin un número antes del cambio, es imposible demostrar una mejora después del lanzamiento, solo sentir que existe. Las organizaciones que se saltan esta etapa regresan a ella de todos modos, generalmente en medio de la construcción, y eso es más costoso. Se detallan otras implicaciones de un salto prematuro en Errores en la implementación de Salesforce.
Diseño de Solución: donde se toman las decisiones más costosas
El Diseño de Solución es la etapa en la que se elige entre varias formas posibles de implementación y se documenta por qué se eligió una y no las otras. El modelo de datos, la estructura de permisos (incluido el intercambio entre roles y regiones) y el diagrama de integraciones con sistemas como ERP, plataformas de pago o de marketing, todo esto debe estar escrito antes de que se abra un primer entorno de desarrollo.
Un error común es permitir que el equipo de desarrollo "decida sobre la marcha" cómo se verá el modelo de compartición (Sharing), porque parece un detalle técnico. En realidad, cambiar el modelo de compartición después de que ya hay cientos de registros en producción es un proyecto en sí mismo. Por lo tanto, cuando la decisión cruza varias dependencias o afecta permisos sensibles, es importante asegurar que las responsabilidades y roles en torno al proyecto sean claros; vea más detalles en Roles del equipo del proyecto Salesforce.
Qué debe estar escrito en el Diseño de Solución
- Objeto principal y modelo de campos, incluyendo lo que no se construirá en la primera versión
- Mapa de permisos por rol, incluyendo excepciones y casos de acceso temporal
- Lista de integraciones con dirección del flujo de información y frecuencia de sincronización
- Al menos tres decisiones arquitectónicas con una alternativa descartada y la razón de ello
Construcción gradual: "Vertical Slice" y no una colección de pantallas
En la etapa de construcción, la trampa común es el avance "horizontal": configurar todas las pantallas a la vez sin que ningún proceso funcione de principio a fin. El enfoque correcto es construir un segmento vertical (Vertical Slice) en cada ciclo: un proceso completo, con datos reales y permisos representativos, que se pueda demostrar al propietario del proceso para obtener retroalimentación inmediata.
Cada sprint debe terminar con una demostración, no solo con "código subido". Cuando no hay una Demo regular, se acumula un inventario de "casi terminado" que se revela como incompleto solo en la etapa de UAT, y eso es precisamente lo que encarece el proyecto en su último tercio.
Migración: la parte más subestimada
La migración de datos es a menudo el mayor riesgo en un proyecto y, por lo general, recibe el menor tiempo en el cronograma. Es obligatorio realizar un ensayo completo (Rehearsal) de migración: cargar datos a un entorno de prueba a gran escala, incluyendo volúmenes reales, y verificar el resultado contra criterios de calidad predefinidos: duplicados, campos obligatorios faltantes, formato de fechas y moneda, y compatibilidad entre sistemas.
Una tabla útil para gestionar este riesgo:
| Prueba de calidad | Qué examinar | Umbral de aceptación recomendado |
|---|---|---|
| Integridad de campos obligatorios | Porcentaje de registros con un campo crítico vacío | Menos del 2% |
| Duplicados | Clientes/Leads con el mismo identificador de negocio | Menos del 1% después de la deduplicación |
| Compatibilidad de formato | Fechas, monedas, códigos de país | 100% compatible con el estándar de destino |
| Conectividad de registros | Relaciones Padre-Hijo que no se rompieron en la transición | 100% de las relaciones críticas |
UAT: prueba con propiedad real, no una firma técnica
Un UAT bien hecho implica que los propietarios del proceso ejecuten escenarios de extremo a extremo por sí mismos, no que el equipo del proyecto se los demuestre. Se recomienda seleccionar entre 8 y 12 escenarios que cubran no solo la ruta normal sino también casos extremos: un cliente sin dirección de correo electrónico, una transacción que se anula después de la aprobación, un usuario con permisos parciales. La firma del UAT debe ser explícita: nombre, fecha y una lista de las brechas que quedan abiertas para la próxima versión, no solo una "aprobación verbal en una reunión".
Capacitación: donde el proyecto tiene éxito o fracasa en silencio
Incluso una excelente solución técnica fracasa si los usuarios no la adoptan. Un buen plan de capacitación incluye material adaptado a cada rol (no una presentación uniforme para todos), demostraciones en un entorno Sandbox con datos conocidos y una lista de Champions (usuarios líderes de cada equipo que pueden responder preguntas cotidianas sin abrir un ticket de soporte). Las organizaciones que invierten en capacitación dos semanas antes de la Puesta en Marcha (Go Live) suelen ver menos reportes de errores falsos ("el sistema no funciona" cuando en realidad es un error de entrada).
Puesta en Marcha (Go Live) y Soporte Intensivo (Hypercare): el lanzamiento es el inicio, no el final
La Puesta en Marcha (Go Live) requiere un Checklist firmado que incluya la verificación de permisos en el entorno de producción, la validación de integraciones activas y un plan de Rollback claro en caso de que se descubra un problema crítico. Después del lanzamiento, comienza el período de Soporte Intensivo (Hypercare), generalmente de dos a cuatro semanas, durante las cuales el equipo monitorea diariamente el registro de errores, la tasa de uso real y las quejas de los usuarios, y corrige con alta prioridad en un día hábil. Cerrar el proyecto antes de que la adopción se haya estabilizado es un error común: los datos de las primeras dos semanas casi siempre presentan una imagen peor de lo que la realidad será una vez que los hábitos se consoliden.
Qué es lo que realmente falla en las organizaciones medianas en Israel
En la práctica de HPI Pro con empresas medianas en Israel (entre 20 y 300 empleados), la mayoría de los problemas no provienen de una elección de producto incorrecta, sino de atajos procesales:
- La gerencia no está disponible para aprobar el ámbito (Scope): El proyecto avanza basándose en la interpretación del gerente de TI, y cuando la gerencia finalmente ve un resultado, solicita cambios que retrasan semanas.
- Dependencia de un solo desarrollador o una pequeña oficina sin respaldo de documentación: Cuando la persona se va, nadie comprende las decisiones tomadas en el Diseño de Solución.
- Migración desde fuentes no oficiales: Hojas de Excel que cada vendedor gestiona por separado, sin una fuente de verdad acordada, lo que convierte la etapa de limpieza en un subproyecto.
- Compresión del UAT en una semana antes del Go Live: Cuando el cronograma está ajustado, el UAT es la primera etapa que se recorta, y es precisamente la etapa que más conviene proteger.
- Falta de capacitación adaptada al idioma y al rol: Materiales de capacitación genéricos en inglés para un equipo de ventas que trabaja en hebreo llevan a un uso parcial y a la elusión del sistema en la práctica.
La forma de reducir estos riesgos no es "trabajar más rápido", sino planificar la capa de DevOps del proyecto (entornos de prueba separados, un proceso de Release definido y seguimiento de cambios) desde el principio. Más detalles en Salesforce DevOps Sandboxes.
Lista de verificación antes de pasar de una etapa a otra
- ☐ Existe un entregable documentado para cada etapa, no solo un resumen de reunión
- ☐ La Línea Base se midió antes del inicio del proyecto
- ☐ El modelo de datos y los permisos están aprobados antes de iniciar el desarrollo
- ☐ Cada sprint termina con una demostración de un segmento vertical (Vertical Slice)
- ☐ Se realizó un ensayo de migración completo (Migration Rehearsal) con un umbral de calidad definido
- ☐ El UAT está firmado por los propietarios del proceso con una lista de brechas abiertas
- ☐ Existe un plan de capacitación adaptado al rol y al idioma
- ☐ Hay un Checklist Go/No-Go y un plan de Rollback
- ☐ El período de Soporte Intensivo (Hypercare) está definido en tiempo y responsabilidades
Cómo medir el éxito real del proyecto
| Área de medición | Qué examinar | Frecuencia de seguimiento recomendada |
|---|---|---|
| Adopción | Porcentaje de usuarios activos frente al total de licencias | Semanal durante el primer mes |
| Calidad de los datos | Campos obligatorios faltantes, duplicados | Antes del Go Live y una vez al mes |
| Rendimiento del proceso | Tiempo de procesamiento de un lead/negocio frente a la Línea Base | Mensual durante los primeros tres meses |
| Incidentes | Número de tickets de soporte y tasa de reapertura | Diaria durante el período de Hypercare |
Las organizaciones que eligen un acompañamiento profesional a lo largo de todo este camino, desde el Discovery hasta el cierre del Soporte Intensivo (Hypercare), pueden recurrir al servicio de implementación de Salesforce para asegurar que cada estación reciba el entregable, la aprobación y el control de riesgos adecuados antes de pasar a la siguiente etapa.
Fuentes profesionales
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Implementación de Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – Metodología de trabajo — https://hpi.pro/methodology