# HPI Pro — Full Knowledge Base Website: https://hpi.pro/es Language: Spanish (es) Hebrew edition: https://hpi.pro Contact: https://hpi.pro/es/contact > Consultoría, arquitectura e implementación de Salesforce y CRM para empresas y organizaciones. ## Core pages - https://hpi.pro/es/services - https://hpi.pro/es/consulting-discovery - https://hpi.pro/es/crm-architecture - https://hpi.pro/es/salesforce-implementation - https://hpi.pro/es/salesforce-health-check - https://hpi.pro/es/salesforce-development-automation - CI/CD y DevOps para Salesforce: https://hpi.pro/es/salesforce-cicd-devops - https://hpi.pro/es/agentforce-ai - https://hpi.pro/es/integrations-data - https://hpi.pro/es/support - https://hpi.pro/es/salesforce-expert-staffing - https://hpi.pro/es/solutions - https://hpi.pro/es/methodology - https://hpi.pro/es/about - https://hpi.pro/es/insights - https://hpi.pro/es/contact --- # Knowledge Base ## ¿Cuánto cuesta implementar Salesforce en su organización? Componentes de costo y un modelo de estimación responsable URL: https://hpi.pro/es/insights/salesforce-implementation-cost El costo de implementar Salesforce se construye a partir de siete componentes distintos con un comportamiento muy diferente: desde licencias hasta integraciones y el costo interno oculto. Quienes aprueban un presupuesto basándose en un solo número a menudo descubren desviaciones en la segunda ronda. ## La respuesta concisa No existe una respuesta única sobre cuánto cuesta implementar Salesforce, ya que se trata de la suma de siete componentes que se comportan de manera diferente: la licencia se paga por número de usuarios y nivel de edición, los servicios de implementación se pagan según el alcance del trabajo, mientras que el costo interno oculto —las horas de su equipo— ni siquiera figura en la propuesta del proveedor. Una organización que solo presupuesta lo que aparece en el contrato se encuentra con una desviación ya en el segundo mes. La forma correcta de abordar esta cuestión no es buscar un "precio de implementación de Salesforce" como un número único, sino construir un modelo de estimación que separe los componentes con alta certeza (licencias) de aquellos que dependen del alcance y la complejidad (implementación, integraciones, migración). Quienes se encuentren en una etapa temprana de selección encontrarán información complementaria en [empresa de implementación de Salesforce](/es/insights/choose-salesforce-implementation-company), mientras que quienes ya estén comparando propuestas pueden consultar el artículo sobre [RFP de Salesforce](/es/insights/salesforce-rfp-guide). ## Los siete componentes del costo El costo de una implementación de Salesforce no es una sola línea en el presupuesto, sino siete componentes distintos, cada uno de los cuales se valora de una manera diferente y se comporta de distinto modo a lo largo del tiempo: 1. **Licenciamiento (Licensing)** — Costo anual o mensual por usuario, dependiente de la edición (Professional, Enterprise, Unlimited) y productos asociados como Sales Cloud, Service Cloud o Data Cloud. 2. **Servicios de implementación (Implementation Services)** — Trabajo de definición, configuración, desarrollo personalizado y pruebas, generalmente valorado por horas o con un precio fijo basado en un alcance definido (Scope). 3. **Integraciones** — Conexión entre Salesforce y sistemas existentes (ERP, pasarela de pago, sistema de telefonía, herramientas de marketing), un costo que depende del número de sistemas y de la complejidad del mapeo de datos entre ellos. 4. **Migración** — Limpieza, mapeo y transferencia de datos históricos de un sistema anterior, a menudo subestimado porque la calidad de los datos originales no se ha verificado previamente. 5. **Capacitación** — Formación de usuarios finales y gerentes, un costo fácil de omitir en el presupuesto, pero que determina el ritmo de adopción real. 6. **Soporte continuo** — Mantenimiento, resolución de problemas, pequeños cambios y actualizaciones de versión después del Go Live, generalmente bajo un acuerdo separado de la implementación. 7. **Costo interno oculto** — Horas del equipo de la organización: propietarios de procesos, gerente de proyecto interno, pruebas de aceptación y comunicación del cambio, que no aparecen en la propuesta del proveedor pero consumen un recurso real. ## Tabla de factores de precio | Componente | Qué eleva el precio | Cómo se minimiza | Bandera roja | | :------------------------ | :------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Licenciamiento | Número de usuarios, edición, productos asociados | Verificar el uso real antes de renovar y no añadir "por si acaso" licencias | El proveedor recomienda una edición superior sin vincularla a una necesidad empresarial específica | | Servicios de implementación | Número de procesos, complejidad de automatización, cantidad de objetos personalizados | Empezar con un "Vertical Slice" y expandirse gradualmente en lugar de un Big Bang | Una propuesta sin una Estructura de Desglose del Trabajo (WBS) detallada por proceso o flujo de trabajo | | Integraciones | Número de sistemas, formato de datos, necesidad de Middleware | Mapear las dependencias de antemano y elegir entre iPaaS económico o API personalizada costosa según el volumen real | No se define quién es responsable del mantenimiento de la integración después del Go Live | | Migración | Volumen de registros, duplicidades, número de fuentes históricas | Realizar un estudio de calidad de datos antes de la estimación, no después | La propuesta asume "datos limpios" sin verificación real | | Capacitación | Número de roles, complejidad del proceso, dispersión geográfica | Capacitar según rol y escenario en lugar de una formación de pantalla general | Sección de capacitación limitada a un taller de dos horas para toda la organización | | Soporte continuo | SLA, horas de disponibilidad, volumen de cambios mensuales | Definir el nivel de SLA según la criticidad del proceso en lugar de forma uniforme | No hay distinción entre "error" y "cambio" en el acuerdo de soporte | | Costo interno oculto | Disponibilidad de los propietarios de procesos, calidad de las pruebas de aceptación, gestión del cambio | Asignar de antemano un porcentaje ordenado del puesto de gerente de proyecto interno | La propuesta asume que el equipo interno "estará disponible" sin una estimación de horas | ## Modelo de estimación: rangos de esfuerzo, no un listado de precios En lugar de basarse en una lista de precios fija que rápidamente queda obsoleta y varía entre proveedores, es aconsejable pensar en términos de rangos de esfuerzo (Effort Bands) para cada componente, y luego traducirlos a un precio con el proveedor específico: * **Esfuerzo bajo** — Un proceso de negocio, sin integraciones complejas, menos de 20 usuarios, datos históricos limitados. Típico para pequeñas empresas B2B que implementan un Sales Cloud básico. * **Esfuerzo medio** — De dos a cuatro procesos de negocio, de una a tres integraciones con sistemas existentes, 20-100 usuarios, migración desde un sistema CRM anterior. Este es el rango más común en el mercado. * **Esfuerzo alto** — Múltiples unidades de negocio o países, múltiples integraciones con sistemas Legacy, un modelo de permisos complejo, más de 100 usuarios, requisitos de Compliance específicos del sector. Para cada rango de esfuerzo, se debe realizar una traducción separada para cada uno de los siete componentes, y no asumir que todos los componentes crecen en la misma proporción. Las integraciones, por ejemplo, pueden pasar de un esfuerzo bajo a uno alto incluso en un proyecto relativamente pequeño, si el sistema existente no expone una API adecuada. ## Cómo traducir un rango de esfuerzo a una propuesta de precio real Una vez definido el rango de esfuerzo esperado, el siguiente paso es solicitar a al menos tres proveedores un desglose de horas por componente, y no solo una suma total. Este detalle proporciona a la organización una capacidad de comparación real: hemos ampliado esto en [Consultor Salesforce](/es/insights/salesforce-consulting-guide), donde también se explica cómo identificar una propuesta que reduce artificialmente la fase de pruebas para parecer más económica. ### Tres escenarios de precio típicos **Escenario A - Implementación inicial pequeña**: Un solo proceso de ventas, sin integración, 10-15 usuarios. La mayor parte del costo se concentra en servicios de implementación y capacitación; el licenciamiento y el soporte continuo constituyen una parte relativamente pequeña en el primer año. **Escenario B - Reemplazo de un sistema CRM existente**: Migración de miles de registros, 40-60 usuarios, una integración con un sistema contable. Aquí, la migración y las integraciones podrían representar un tercio del presupuesto total, y este es precisamente el componente que las estimaciones iniciales tienden a subestimar. **Escenario C - Expansión plurianual para una gran organización**: Múltiples unidades de negocio, Salesforce ya implementado y se necesita añadir Service Cloud o Data Cloud. El costo interno oculto —tiempo de los propietarios de procesos y gerentes de TI— se convierte en el componente más significativo, y a veces mayor que el costo de la licencia. ## Un escenario organizacional de ejemplo Supongamos un fabricante multi-planta que solicita propuestas de tres integradores para la implementación de Salesforce. La propuesta más económica es un 35 por ciento inferior a las demás, pero al examinarla se observa que incluye solo 40 horas de migración a pesar de que la organización tiene aproximadamente 60,000 registros de clientes históricos en un sistema antiguo con muchas duplicidades. El equipo solicita al proveedor que detalle los supuestos de trabajo, y descubre que la propuesta asumía "datos limpios y listos para transferir", un supuesto que no se verificó con la realidad. La organización decide realizar un breve estudio de calidad de datos antes de firmar el contrato. El estudio revela que el 18 por ciento de los registros están duplicados y el 30 por ciento carece de un campo obligatorio para el nuevo proceso. Como resultado, la organización solicita a los tres proveedores que re-coticen la fase de migración basándose en los hallazgos, y añade una cláusula al contrato que separa el costo de la migración única del mantenimiento continuo de la calidad de los datos, tal como se detalla en [Cláusulas de Contrato SOW de Proyectos Salesforce](/es/insights/salesforce-sow-contract-clauses). El resultado: la propuesta finalmente seleccionada no fue la más económica, pero fue la única que incluyó los siete componentes del costo con un detalle real, incluyendo una estimación de las horas internas de la propia organización. Este cambio de enfoque —primero mapear el costo real, y luego comparar las propuestas— fue lo que evitó una desviación presupuestaria de aproximadamente el 25 por ciento que se descubrió solo en el cuarto mes en uno de los competidores que eligió la oferta más barata. ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | :----------------------------------- | :--------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | | Propuesta "demasiado redonda" | Una suma total sin desglose por componente | Exigir un desglose de horas y costes para cada uno de los siete componentes | | Ignorancia del costo interno | La organización no presupuesta el tiempo de gestión interna y las pruebas de aceptación | Estimar previamente las horas de personal interno, por separado del costo del proveedor | | Migración subestimada | Asumir que "los datos están bien" sin verificación | Realizar un estudio de calidad de datos antes de la estimación final | | Capacitación como elemento marginal | Presupuesto de capacitación limitado a un día para toda la organización | Presupuestar la capacitación según el rol y el escenario real | | Soporte sin definición de SLA | Contrato de soporte vago sobre tiempos de respuesta y resolución | Establecer un SLA escalonado según la criticidad y cotizar en consecuencia | A nivel de la gestión del presupuesto de implementación de Salesforce, esta tabla es un punto de partida y no una lista cerrada. Para CIOS, directores generales y responsables de compras, es aconsejable actualizarla en cada ronda de propuestas, y verificar qué riesgos se materializaron en proyectos anteriores del mismo sector antes de aprobar un presupuesto final. ## Cómo verificar que la estimación es razonable | Área de verificación | Qué se verifica | Frecuencia de verificación | | :------------------------ | :------------------------------------------------------------------------------ | :------------------------- | | Ajuste de licencia al uso | Porcentaje de usuarios activos en relación con el número de licencias adquiridas | Trimestral | | Desviación de servicios de implementación | Desviación real de horas respecto a las horas presupuestadas en la propuesta | En cada hito | | Carga de integración | Frecuencia de fallos o retrasos en la transferencia de datos entre sistemas | Mensual | | Calidad de la migración | Porcentaje de registros con error o duplicidad después de la transferencia | Única vez después del Go Live | | Costo de soporte vs. SLA | ¿Los tiempos de respuesta reales corresponden a lo pagado? | Mensual | Para una estimación presupuestaria responsable, es aconsejable seleccionar solo de tres a cinco métricas de la tabla para un seguimiento continuo durante el primer año. Una buena métrica se puede calcular antes y después de firmar el contrato, lo que permite comparar lo prometido con lo ocurrido en la práctica, y no solo basarse en la sensación de que el proyecto "salió bien". La implementación real del modelo de estimación se puede ejecutar a través de [servicio de consultoría y descubrimiento](/es/consulting-discovery). ## Lista de verificación antes de la aprobación del presupuesto - ☐ Cada uno de los siete componentes del costo está valorado por separado y no en una única suma total - ☐ Se ha realizado un estudio de calidad de datos antes de estimar el costo de la migración - ☐ Se ha definido un rango de esfuerzo (bajo, medio, alto) antes de solicitar las propuestas - ☐ Se han estimado las horas de trabajo internas por separado del costo del proveedor - ☐ El presupuesto de capacitación está detallado por rol y no como una partida general - ☐ Se ha definido un SLA claro para el acuerdo de soporte continuo - ☐ Existe una reserva del 10-20 por ciento para cambios de alcance - ☐ Al menos tres proveedores han detallado las horas por componente y no solo una suma total - ☐ Se ha verificado el costo del licenciamiento para 24-36 meses y no solo para el primer año - ☐ Se han definido métricas de verificación posteriores al Go Live y no solo el criterio de "el sistema ha sido implementado" ## Fuentes profesionales - HPI Pro – Consultoría y descubrimiento — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Servicios de Salesforce — https://hpi.pro/services ### Preguntas y respuestas **¿Por qué dos presupuestos para implementar Salesforce pueden variar el doble?** Generalmente se debe a un alcance de trabajo diferente y no a un 'descuento'. Una oferta más económica puede omitir pruebas de carga, migración de datos históricos o capacitación de usuarios finales, cobrándolos como un extra después de la firma. Se debe comparar con la misma Estructura de Desglose de Trabajo (EDT) y las mismas suposiciones, no solo con el número final. **¿Es mejor pagar por licencias premium para ahorrar en el costo de implementación?** A veces sí: una licencia con capacidades de Flujo y Automatización incorporadas puede ahorrar desarrollo personalizado. Pero no es una fórmula fija; el costo de las licencias a tres años a menudo es superior al ahorro en la implementación. Es aconsejable calcular el costo total para 24-36 meses, no solo el precio de implementación único. **¿Cuánto del presupuesto se debe reservar para cambios durante el proyecto?** En proyectos medianos-grandes, es habitual reservar un 10-15 por ciento del costo de los servicios de implementación como reserva para cambios en el alcance. Si la organización también está experimentando un cambio de proceso significativo, y no solo la digitalización de un proceso existente, es recomendable aumentar la reserva a un 20 por ciento. **¿Cuál es la diferencia entre el costo de migración única y el costo del mantenimiento continuo de datos?** La migración es un proyecto con tiempo limitado: limpieza, mapeo y transferencia única de datos. El mantenimiento de datos es un proceso continuo: deduplicación, control de calidad y actualización de permisos. Las organizaciones que solo presupuestan la migración descubren en un año que la calidad de los datos ha vuelto a deteriorarse. **¿Cómo identificar si una cotización oculta un costo interno no contemplado?** Si la cotización no especifica cuántas horas de gestión interna, pruebas de aceptación e involucramiento de los propietarios de los procesos requiere su equipo, es probable que este costo exista pero no se haya contabilizado. Se debe solicitar una estimación de las horas-hombre internas por separado del costo del proveedor. --- ## ¿Cómo elegir una empresa de implementación de Salesforce? Guía profesional para la toma de decisiones URL: https://hpi.pro/es/insights/choose-salesforce-implementation-company La elección de una empresa de implementación de Salesforce suele oscilar entre dos extremos: la impresión de una demostración llamativa o la mera comparación de precios. Un proceso de selección adecuado evalúa la profundidad profesional, las referencias genuinas y un modelo de contratación, antes de mirar el número final en la propuesta. ## La respuesta corta La elección de una empresa para implementar Salesforce suele caer en uno de dos extremos peligrosos: dejarse impresionar por una demostración impactante en una reunión de ventas, o una mera comparación de precios entre ofertas que parecen similares en papel. Ninguno de estos métodos evalúa lo que realmente determina el éxito: si el proveedor comprende el proceso de negocio, cómo maneja las excepciones y qué sucede cuando algo sale mal en la tercera semana del proyecto. Un proceso de selección maduro evalúa cuatro aspectos de forma secuencial: la definición de la necesidad interna antes de contactar al mercado, el tipo de proveedor adecuado para el alcance y el riesgo, la profundidad profesional examinada más allá de una demo, y un modelo de contratación que distribuye el riesgo de manera justa. Hemos abordado en detalle el marco para comparar ofertas y condiciones en [Comparación de propuestas de Salesforce](/es/insights/compare-salesforce-proposals), y aquí nos enfocamos en la etapa previa: cómo llegar a una lista de candidatos adecuados. ## Primera etapa: qué se necesita antes de contactar al mercado El error más común es acudir a los proveedores con la pregunta "¿cuánto cuesta?" antes de definir lo que se necesita. Una empresa que inicia un proceso de adquisición sin un alcance (Scope) documentado recibe propuestas incomparables, ya que cada proveedor llena los vacíos con sus propias suposiciones. Antes de la primera reunión, es aconsejable tener un documento breve que incluya: el proceso de negocio que requiere cambio, los usuarios, los sistemas existentes y qué se considerará un éxito en seis meses. El alcance de esta necesidad también determina directamente el modelo de fijación de precios adecuado: un proyecto con un Scope claro se ajusta mejor a un precio fijo, mientras que un proyecto exploratorio es más adecuado para el modelo de "Tiempo y Material" (Time & Material). Hemos profundizado sobre esto en [Fijación de precios de proyectos Salesforce](/es/insights/salesforce-project-pricing-models). Una organización que omite la etapa de definición casi siempre paga el doble: una vez en una propuesta de precio inflada que cubre la incertidumbre, y otra vez en cambios de Scope a mitad del trabajo. ## Tipos de proveedores: boutique, global y freelancer El mercado de servicios Salesforce se divide, a grandes rasgos, en tres categorías, cada una adecuada para un perfil de riesgo diferente. Las **empresas boutique** suelen tener entre 5 y 30 empleados, se especializan en una o dos áreas (ventas, servicio, Marketing Cloud) y proporcionan acceso directo al arquitecto sénior durante todo el proyecto. La ventaja es la agilidad y un precio competitivo; la desventaja es una capacidad limitada: un proyecto grande que requiera cinco personas simultáneamente podría estancarse. Los **integradores globales** aportan una metodología documentada, capacidad de reclutamiento rápido de personal adicional y experiencia en sectores similares a nivel mundial. El precio es entre un 30% y un 60% más alto en comparación con una boutique, y a menudo existe una capa de gestión de proyectos que separa al cliente del equipo de ejecución real, lo que ralentiza la comunicación en momentos de crisis. Los **freelancers** ofrecen la tarifa por hora más baja, pero exponen a la dependencia de una sola persona. Si el freelancer se enferma, viaja al extranjero o se traslada a otro proyecto, el trabajo se detiene. Son adecuados principalmente para el mantenimiento continuo o para proyectos pequeños con un Scope definido y cerrado. ## Examen de la profundidad profesional más allá de una demo Una demo impresionante demuestra que el proveedor sabe cómo presentar Salesforce, no que sabe resolver el problema específico de la organización. Un examen de profundidad real requiere tres capas: primero, solicitar que el equipo que realmente ejecutará el proyecto (no solo el vendedor) participe en la reunión y responda preguntas técnicas. Segundo, pedir un ejemplo concreto de un proyecto similar en alcance e industria, incluyendo capturas de pantalla reales y no diapositivas de marketing. Tercero, evaluar cómo reacciona el proveedor ante una pregunta trampa, por ejemplo, "¿qué sucede si a mitad del proyecto se descubre que los datos en la fuente no son confiables?". Un proveedor experimentado responderá con un ejemplo, no con un eslogan. Quien dirige realmente la arquitectura determina la calidad de la solución mucho más que el logo en la factura. Es importante asegurarse de que el arquitecto presentado en la reunión de ventas sea realmente quien estará involucrado en el proyecto, y no una "cara" que se presenta a los clientes y después de la firma es reemplazada por un equipo más junior. ## Verificación efectiva de referencias Una buena llamada de referencias no se queda en el nivel de "¿lo recomendaría usted?", sino que desciende a los detalles operativos. Tres preguntas que producen información real: ¿El proyecto se completó dentro del presupuesto y del cronograma original, y si no, cuál fue la desviación y la razón? ¿Qué sucedió cuando se descubrió un error o un bug en producción, y cuánto tiempo tardó en corregirse? Y, ¿el equipo que ejecutó el proyecto sigue trabajando para el proveedor hoy? Una alta rotación de personal en una empresa de implementación es una señal de que el conocimiento adquirido en el proyecto anterior ya no está disponible. Es aconsejable pedir al menos dos referencias: una de un proyecto exitoso y otra de un proyecto con dificultades. Un proveedor que se niega a proporcionar una referencia "problemática" o afirma que todos sus proyectos fueron impecables, está ocultando algo. ## Modelo de contratación: cómo distribuir el riesgo El modelo de contratación determina quién asume el riesgo cuando la realidad se desvía de lo planificado, y esto ocurre casi siempre. | Modelo | Cuándo es adecuado | Riesgo principal | |---|---|---| | Tiempo y Material abierto | Scope no maduro, fase de Discovery | Exceso en la cantidad de horas sin tope | | T&M con tope (Cap) | Scope parcial, primer proyecto con el proveedor | Requiere control continuo frente al tope | | Precio fijo | Scope bien cerrado y documentado | El proveedor puede recortar esquinas para mantener el margen | | Retainer mensual | Mantenimiento y soporte continuo | El volumen de trabajo real no siempre coincide con el pago | Para un primer proyecto con un nuevo proveedor, el modelo de T&M con tope suele ser la elección más equilibrada: evita sorpresas presupuestarias pero no incentiva al proveedor a recortar las pruebas. Considerar un precio fijo solo después de que el Scope haya sido validado frente a escenarios reales de principio a fin, como se describe en [Cómo elegir un proveedor de Salesforce](/es/insights/salesforce-vendor-scorecard). ## Cuadro de mando (Scorecard) para la puntuación de proveedores Una tabla de puntuación ponderada convierte una comparación subjetiva en un proceso que puede defenderse ante la dirección. Pesos sugeridos para un proyecto típico: | Criterio | Peso | Qué se evalúa realmente | |---|---|---| | Pertinencia de la experiencia del sector y el proceso | 25% | Proyectos de alcance y sector similares, no solo un logo conocido | | Profundidad del equipo propuesto | 20% | Antigüedad y rol real del arquitecto y los desarrolladores | | Calidad de la propuesta y el Scope | 20% | Detalle del WBS, suposiciones, excepciones y entregables aceptables documentados | | Referencias y rotación de personal | 15% | Conversaciones directas con clientes anteriores | | Modelo de contratación y equidad contractual | 10% | Distribución razonable del riesgo, no solo precio bajo | | Adecuación cultural y disponibilidad de comunicación | 10% | Tiempo de respuesta, idioma, zona horaria y frecuencia de actualizaciones | Cada proveedor recibe una puntuación del 1 al 5 en cada línea, multiplicada por el peso. La diferencia entre el proveedor líder y el segundo en el resultado global es tan importante como la puntuación misma; una diferencia de menos de 5 puntos generalmente justifica una reunión aclaratoria adicional antes de una decisión final. ## Señales de alerta para identificar temprano * Propuesta de precio sin desglose de horas por tema, solo un "total" global. * Promesa de una "solución completa en Salesforce" para una necesidad que nunca se ha analizado en profundidad. * Negativa a revelar quién del equipo realizará el trabajo. * Presión para firmar rápidamente "porque este precio solo es válido esta semana". * No hay referencia a casos de fracaso o proyectos con dificultades. * Contrato que no define lo que se considera la "finalización" del proyecto y la aceptación final. ## Qué solicitar ver en una reunión: Lista de verificación rápida * ☐ Presencia del equipo ejecutor real, no solo un vendedor. * ☐ Ejemplo concreto de un proyecto similar con capturas de pantalla reales. * ☐ Desglose inicial del Work Breakdown Structure (WBS) con suposiciones y excepciones documentadas. * ☐ Nombre y datos de contacto de al menos dos referencias. * ☐ Propuesta de modelo de contratación con explicación de por qué es adecuado para el alcance. * ☐ Descripción del proceso de manejo de cambios de Scope y de errores (bugs) después de la entrada en operación. ## Escenario organizacional de ejemplo Una empresa mediana de servicios financieros evaluó tres propuestas para Salesforce Sales Cloud: una boutique local, un integrador global y un freelancer recomendado. La dirección inicialmente se inclinó por el freelancer debido a un precio un 40% más bajo, hasta que una llamada de referencia reveló que su proyecto anterior se había detenido durante tres semanas cuando él enfermó. Finalmente, la organización eligió a la boutique, después de que el *Scorecard* mostró una ventaja de 12 puntos en la categoría de profundidad del equipo y baja rotación de personal. El proyecto, de hecho, se encontró con un cambio de requisito a mitad de camino: una nueva necesidad de integración con un sistema de facturación interno que no se había mencionado en la etapa de propuesta. Gracias al modelo de T&M con tope, el cambio se gestionó como una adición previamente acordada y no como una renegociación de todo el contrato. Las organizaciones que dudan entre proveedores similares y desean un marco de preguntas adicional pueden consultar [Preguntas antes de elegir un integrador de Salesforce](/es/insights/questions-before-choosing-salesforce-integrator). ## Cómo medir que la elección fue correcta | Métrica | Qué se evalúa | Cuándo se evalúa | |---|---|---| | Cumplimiento del cronograma | Desviación en días entre el plan y la ejecución real | En cada hito | | Estabilidad del equipo | Si las mismas personas acompañaron el proyecto hasta el final | Al finalizar cada etapa | | Manejo de desviaciones | Tiempo de respuesta a un bug o a un cambio de requisito | Durante todo el proyecto | | Calidad de la documentación | Si se puede transferir el mantenimiento a otro equipo sin dependencia de una persona | Al momento de la entrega | Una métrica que no se puede evaluar en la práctica no es una métrica. Si el contrato no incluye una definición clara de lo que se considera la "finalización" del proyecto, es casi imposible saber si la elección fue correcta hasta que es demasiado tarde para corregirlo. Una organización que desea acompañamiento externo en la construcción del propio proceso de selección puede comenzar con el [servicio de consultoría y definición](/es/consulting-discovery), que ayuda a definir el Scope y a construir un Scorecard adaptado incluso antes de contactar al mercado. ## Fuentes profesionales * HPI Pro – Consultoría y definición — https://hpi.pro/consulting-discovery * Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html * HPI Pro – Servicios Salesforce — https://hpi.pro/services ### Preguntas y respuestas **¿Cuál es la diferencia práctica entre una boutique y un integrador global en un proyecto de Salesforce?** Una boutique generalmente ofrece acceso directo al arquitecto y al desarrollador senior, ciclos de trabajo más cortos y un coste por hora más bajo, pero con una capacidad limitada para proyectos grandes. Un integrador global aporta una metodología estructurada y capacidad de escalado, a un precio más alto y a menudo con capas de gestión adicionales entre el cliente y el ejecutor. **¿Cuánto cuesta generalmente contratar a un freelancer de Salesforce en comparación con una empresa?** Un buen freelancer oscila entre 70 y 130 euros por hora sin gastos de gestión, pero expone a la organización al riesgo de dependencia de una sola persona. Una empresa cobra, en promedio, entre un 20% y un 40% más, pero proporciona respaldo, seguro profesional y continuidad del trabajo incluso si un empleado se va a mitad del proyecto. **¿Qué preguntas debe hacer a las referencias de una empresa de implementación antes de firmar?** Pregunte sobre el cumplimiento de los plazos reales frente a los planificados, la calidad de la documentación recibida, cómo reaccionó el proveedor cuando se detectó un error y si el equipo que ejecutó el proyecto sigue trabajando en la empresa. Una respuesta evasiva a cualquiera de estas preguntas es una señal de advertencia significativa. **¿Cuál es el modelo de contratación recomendado para un primer proyecto de Salesforce en una organización?** Para la primera fase, generalmente se recomienda 'Time & Material' con un tope (Cap), y solo pasar a un precio fijo después de que el alcance se haya estabilizado en torno a escenarios de extremo a extremo definidos. Un precio fijo con un alcance ambiguo incentiva al proveedor a recortar esquinas para proteger su rentabilidad. **¿Cuál es el tamaño mínimo del equipo de proveedores requerido para un proyecto mediano de Salesforce?** Para un proyecto de 3 a 6 meses, es aconsejable asegurarse de que haya al menos dos personas con el conocimiento suficiente para reemplazarse mutuamente: un arquitecto o líder y un desarrollador adicional. Un equipo de una sola persona funciona bien hasta el momento en que se enferma, sale de vacaciones o se va. --- ## ¿Cuánto dura un proyecto Salesforce? Plazos, dependencias y lo que realmente lo retrasa URL: https://hpi.pro/es/insights/salesforce-project-timeline Un proyecto Salesforce promedio dura entre seis semanas y nueve meses. Sin embargo, el rango de fechas en la cotización casi nunca se debe al alcance del desarrollo, sino al ritmo de las decisiones, la preparación de los datos y la disponibilidad de los profesionales en la organización. ## La respuesta corta No existe una respuesta única a la pregunta de cuánto dura un proyecto de Salesforce, pero sí hay rangos realistas que conviene conocer antes de firmar un presupuesto. Un proyecto enfocado de "Quick Win" —una automatización, un Object adaptado, un informe avanzado— a veces se cierra en 3-4 semanas. Una implementación completa de Sales Cloud para un equipo de ventas mediano oscila entre 8 y 14 semanas. Un proyecto Multi-Cloud con integraciones a un ERP y sistemas externos puede durar de 6 a 9 meses, y en ocasiones más si involucra varias unidades de negocio. El factor que determina la duración real no es la magnitud del código, sino el ritmo de toma de decisiones en la organización: quién es el Responsible (Owner) de cada proceso, cuánto tiempo toma aprobar el alcance (Scope) y cuándo los datos están realmente listos para ser validados. Antes de fijar una fecha de lanzamiento (Go Live), es recomendable consultar la guía completa para la [implementación de Salesforce en su organización](/es/insights/salesforce-implementation-guide), que detalla las etapas de trabajo detrás de cada semana en el cronograma. ## Por qué los plazos varían tanto entre proyectos aparentemente similares Dos organizaciones que solicitan una "implementación de Sales Cloud para un equipo de ventas de 20 personas" pueden recibir presupuestos con una diferencia de tiempo de ejecución de hasta tres veces, y ambas ofertas podrían ser correctas. La diferencia casi siempre radica en lo que no está explícitamente en el documento de requisitos: cuántas fuentes de datos existen, cuán complejos son los procesos de aprobación internos y con qué rapidez la organización toma decisiones que afectan a más de un departamento. Un proyecto con un único Product Owner que tiene autoridad para firmar un Scope avanza significativamente más rápido que un proyecto donde cada cambio requiere la aprobación de un comité directivo. Esta no es una diferencia técnica, es una diferencia organizacional que impacta directamente el cronograma, a veces más que cualquier decisión de arquitectura. ## Plazos según el tipo de proyecto La siguiente tabla presenta estimaciones de semanas de trabajo reales (transcurridas, no de esfuerzo) según la etapa y el tipo de proyecto. Se trata de rangos promedio basados en la experiencia, no de un compromiso; cada proyecto concreto requiere una evaluación individualizada. | Etapa | Quick Win / Adición puntual | Implementación estándar (una Cloud) | Proyecto Multi-Cloud con integraciones | | --- | --- | --- | --- | | Discovery y especificación | 3-5 días | 1.5-3 semanas | 3-6 semanas | | Arquitectura y modelo de datos | 2-3 días | 1-2 semanas | 3-5 semanas | | Desarrollo y configuración | 1-2 semanas | 3-6 semanas | 8-16 semanas | | Migración de datos | Generalmente no requerido | 1-2 semanas | 3-6 semanas | | Integraciones | Generalmente no requerido | 1-3 semanas | 4-10 semanas | | UAT y correcciones | 2-4 días | 2-3 semanas | 3-5 semanas | | Go Live y Hypercare | 2-3 días | 1-2 semanas | 2-4 semanas | | **Duración total** | **3-4 semanas** | **8-14 semanas** | **24-40 semanas** | Es importante recordar que las cifras en la tabla asumen una disponibilidad razonable de las partes interesadas y datos de una magnitud manejable. Cualquiera de estas suposiciones, si no se cumple, puede añadir semanas enteras a cada etapa. ## Lo que realmente retrasa los proyectos, y no es lo que piensa Cuando un proyecto de Salesforce se desvía del cronograma, la causa más común no es la complejidad técnica, sino uno de estos cinco puntos: - **Decisiones dependientes que no se toman a tiempo** - Una pregunta de negocio que permanece abierta durante dos semanas porque no hay nadie autorizado para responderla, mientras el equipo técnico espera. - **Datos que no están realmente preparados** - Una fuente de datos "existente y lista" resulta contener duplicados, campos faltantes o dos fuentes contradictorias. - **Disponibilidad de personal clave y propietarios de procesos** - El personal de ventas o servicio que debe probar y aprobar está ocupado con el trabajo diario y no se le concede tiempo con antelación. - **Integraciones con terceros** - Dependencia de un proveedor externo, de una API con limitaciones, o de un equipo de IT interno que no trabaja al mismo ritmo. - **UAT que se alarga** - Porque las pruebas comienzan solo cuando el sistema está "casi listo" y no en paralelo con el desarrollo. De todos estos, las decisiones dependientes son la causa más fácil de prevenir y la más común en la práctica. Una organización que define de antemano quién aprueba qué, y en cuántos días una respuesta se considera un "retraso", ahorra en promedio dos o tres semanas en un proyecto mediano. Este tema se discute ampliamente también en [MVP Salesforce](/es/insights/salesforce-mvp-scope), que explica cómo reducir el número de decisiones dependientes desde el principio, delimitando una primera versión más pequeña. ## La ruta crítica: lo que determina la fecha final En todo proyecto hay una cadena de actividades que determina la fecha mínima de finalización: esta es la ruta crítica. En un proyecto típico de Salesforce, la ruta crítica casi siempre pasa por tres cuellos de botella: 1. **Aprobación del modelo de datos y permisos**: Mientras esto no esté cerrado, no se puede iniciar la integración o migración con confianza. 2. **Disponibilidad de la fuente de datos para la migración**: Aunque el desarrollo esté listo, no se puede lanzar a producción sin datos limpios y validados. 3. **Disponibilidad de los propietarios de procesos para UAT**: Este es a menudo el cuello de botella más estrecho, ya que se trata de personas con funciones completas en la organización y que no tienen disponibilidad de tiempo del equipo del proyecto. Un retraso de una semana en cualquiera de estos tres puntos se traslada directamente a la fecha de Go Live, incluso si el resto del equipo cumple con los plazos. Por lo tanto, una buena PMO supervisa específicamente los elementos de la ruta crítica y no solo el porcentaje de finalización general del proyecto. Esta idea se refleja en el proceso de [UAT para Salesforce](/es/insights/salesforce-uat-guide), que detalla cómo planificar la fase de pruebas para que no se convierta en un cuello de botella adicional. ## Por fases (Phased) vs. Gran Estallido (Big Bang): cómo la elección afecta el cronograma La cuestión de si salir al aire en una sola fase (Big Bang) o en varias etapas (Phased) es una de las decisiones más significativas para el cronograma, y no solo para el riesgo operacional. **Big Bang** es adecuado cuando el alcance es relativamente pequeño, cuando existe una fuerte dependencia entre los componentes (por ejemplo, un proceso Lead-to-Cash unificado que no se puede dividir), y cuando la organización prefiere una inversión de tiempo concentrada en lugar de un período de transición prolongado. La ventaja en el cronograma: una única fecha límite clara. El inconveniente: cualquier retraso en un componente detiene toda la fecha. **Phased** es adecuado cuando el alcance es amplio, cuando hay varias unidades de negocio o procesos que se pueden separar, y cuando la organización busca obtener valor temprano y aprender de una etapa antes de avanzar a la siguiente. La ventaja: una primera etapa entra en producción más rápidamente, y las lecciones aprendidas se aplican en las etapas posteriores. El inconveniente: una duración total más larga y, a veces, un costo de coordinación más elevado entre las etapas. Como regla general, si se espera que el proyecto exceda los 4 meses o incluye más de dos departamentos independientes, un enfoque Phased casi siempre acorta el tiempo hasta el primer valor comercial, incluso si la duración total del proyecto es similar o más larga. ## Cómo acortar el cronograma sin comprometer la calidad Existen maneras reales de acortar el cronograma, y hay atajos que parecen ahorrar tiempo pero en realidad solo posponen el costo al Hypercare o al año siguiente. **Lo que realmente acorta:** - Delimitación estricta del alcance (Scope) para una primera versión, con una lista explícita de "no ahora" aprobada de antemano. - Nombramiento de un único Product Owner con autoridad real para aprobar o rechazar, a fin de eliminar retrasos de comités. - Inicio del trabajo de limpieza de datos en paralelo con la fase de definición, y no después. - Liberar con antelación tiempo en la agenda de los propietarios de procesos para el UAT, no cuando llegue la fase. - Uso de componentes estándar de Salesforce en lugar de desarrollo personalizado siempre que sea posible. **Lo que parece un atajo, pero no lo es:** - Omitir el UAT completo y pasar directamente a la "prueba de desarrolladores”: esto ahorra una semana y genera un mes de correcciones en producción. - Migración de datos sin limpieza, con la intención de "limpiar después”: los datos sucios se convierten en un problema de adopción. - Comprimir la capacitación en un solo día antes del Go Live: lleva a que el sistema sea evitado en las primeras semanas. Cuando se trata de un proyecto en el que el cronograma es realmente crítico para el negocio, el acompañamiento profesional a través del [servicio de implementación de Salesforce](/es/salesforce-implementation) se enfoca precisamente en esta combinación: qué acortamientos son seguros y cuáles solo posponen el costo. ## Escenario organizacional de ejemplo Una empresa de logística planificó la implementación de Service Cloud en 10 semanas, para estar lista antes de la temporada alta. En la segunda semana, se descubrió que el sistema ERP existente no estaba preparado para exponer una API estable y que el equipo de TI interno solo estaba disponible a tiempo parcial para el proyecto. En lugar de retrasar todo el proyecto, el equipo adoptó un enfoque por fases (Phased): la primera etapa incluyó enrutamiento básico de solicitudes y SLA, sin la integración con el ERP, y se lanzó en 7 semanas, tres semanas antes de la temporada. La integración completa se pospuso para una segunda etapa, que se ejecutó en paralelo con la temporada alta y se lanzó dos meses después. La lección principal: cuando se descubre un obstáculo real en la ruta crítica, la pregunta correcta no es "cómo comprimir el tiempo restante", sino "qué se puede separar en una fase nueva sin afectar el valor inmediato". La planificación del Hypercare después de cada etapa se detalla en [Salesforce Hypercare](/es/insights/salesforce-hypercare-plan), que muestra cómo estabilizar cada etapa antes de pasar a la siguiente. ## Lista de verificación para una planificación realista del cronograma - ☐ Se ha definido un alcance (Scope) cerrado para la primera versión, incluyendo una lista de "no ahora". - ☐ Se ha designado un único Product Owner con autoridad de aprobación. - ☐ Se ha verificado la calidad de los datos en la fuente, no solo asumido que están "listos". - ☐ Los propietarios de procesos han liberado tiempo con antelación para los períodos de UAT planificados. - ☐ Las integraciones con terceros se han verificado con respecto a la API y la disponibilidad del proveedor. - ☐ Se ha decidido explícitamente: Phased o Big Bang, y por qué. - ☐ La ruta crítica se identifica y monitorea por separado del porcentaje de finalización general. - ☐ Existe un margen (Buffer) integrado del 10-15% para el cronograma, no una promesa de "todo a tiempo". - ☐ Se capacitó a los usuarios finales antes del Go Live, no el día anterior. - ☐ Se ha definido un plan de Hypercare con un criterio de salida. ## Recursos 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 ### Preguntas y respuestas **¿Cuál es la diferencia en la duración de un proyecto entre un Sales Cloud básico y un Service Cloud con integraciones?** Un Sales Cloud básico para un solo equipo de ventas, sin integraciones complejas, suele completarse en 6-10 semanas. Un Service Cloud con enrutamiento, SLA y 2-3 integraciones (ERP, telefonía, sistema de facturación) generalmente requiere 12-20 semanas debido al mapeo de procesos de servicio y permisos más complejos. **¿Cuánto tiempo real ocupa la fase de datos del cronograma total?** En proyectos con una única fuente de datos limpia, la limpieza y migración toma aproximadamente el 10% del tiempo total. Cuando hay dos o más fuentes con duplicados, la brecha aumenta al 25-30%, porque cada ronda de control de calidad revela más anomalías que requieren una decisión de negocio y no solo una corrección técnica. **¿Es preferible un cronograma fijo de antemano o una estimación que se actualiza a medida que avanza?** Un cronograma fijo solo es correcto cuando el Scope está completamente cerrado y no hay dependencia de una integración externa. En la mayoría de los proyectos se presenta un rango (por ejemplo, 10-14 semanas) que se actualiza al final de cada Sprint, ya que un cierre demasiado temprano suele generar desvíos silenciosos posteriormente y no un cumplimiento real del objetivo. **¿Qué sucede con el cronograma cuando se descubre una integración no planificada a mitad del proyecto?** En un proyecto con un enfoque por fases, la integración puede posponerse a la siguiente fase sin detener el resto del trabajo, generalmente con 2-4 semanas adicionales para una fase separada. En un enfoque Big Bang, este descubrimiento tiende a detener todo el proceso, ya que se supone que todos los componentes deben implementarse juntos. **¿Cuánto tiempo se debe planificar para el UAT para que no se convierta en el cuello de botella del proyecto?** Para un proyecto de tamaño mediano, se recomienda asignar 2-3 semanas para el UAT, incluyendo una ronda de correcciones. El problema común no es la duración del propio UAT, sino la disponibilidad de los propietarios del proceso: si no están liberados de su trabajo diario de antemano, una fase que debería durar dos semanas se extiende a un mes y medio. --- ## Implementación de Salesforce en Grandes Empresas: Principios, Gobernanza y Riesgos URL: https://hpi.pro/es/insights/enterprise-salesforce-implementation Con más de 500 usuarios, el desafío deja de ser 'cómo se construye' para convertirse en 'quién decide', 'quién aprueba un cambio' y 'cómo se coordinan los proyectos paralelos'. Este artículo presenta un modelo de gobernanza, la elección entre Single-org y Multi-org, y patrones de fallo comunes. ## La Respuesta Breve En una organización con decenas de usuarios, la implementación de Salesforce es principalmente un trabajo de configuración y adopción. En una organización con 500 o más usuarios, a través de varias unidades de negocio y, a menudo, en múltiples países, el problema central se desplaza: ¿quién aprueba un cambio?, ¿cómo evitan los equipos paralelos interferir entre sí?, y ¿la estructura del Org soporta el próximo crecimiento o lo bloquea? Sin una gobernanza estructurada, cada mejora puntual se convierte en un riesgo para la estabilidad de toda la organización. Este artículo aborda la capa de gestión por encima del proyecto individual: estructura de decisiones, elección entre Single-Org y múltiples organizaciones separadas, coordinación de releases, seguridad y regulación, localización global y la dependencia entre programas paralelos en el PMO. El contexto completo para las fases básicas de implementación se encuentra en [Implementación de Salesforce en la Organización](/es/insights/salesforce-implementation-guide), y el presente artículo se basa en ello a nivel de escala empresarial. ## Por qué la Escala Cambia las Reglas del Juego En un proyecto de 50 usuarios, los cambios se pueden gestionar a través de una conversación entre dos personas. Con 500 o más usuarios, generalmente ya operan varios equipos de desarrollo, múltiples unidades de negocio con prioridades diferentes, y a veces, varios proveedores de implementación concurrentes. Un pequeño cambio en un objeto compartido —añadir un campo obligatorio, modificar una regla de validación— puede interrumpir un proceso en otra unidad que no estaba al tanto del cambio. Por lo tanto, a escala empresarial, tres preguntas preceden a cualquier discusión técnica: ¿quién es el propietario de cada objeto y proceso central?, ¿qué mecanismo verifica el impacto inter-equipo antes de un despliegue?, y ¿quién está autorizado a detener un release si se detecta un riesgo? Las organizaciones que omiten estas preguntas construyen "rápido" al principio y pagan el precio con interrupciones frecuentes y rollbacks no planificados uno o dos años después. ## Gobernanza y Junta Consultiva de Cambios (Change Advisory Board) Una Junta Consultiva de Cambios (CAB) no es un comité burocrático, es un mecanismo que previene que un cambio que parece pequeño para una unidad afecte a otra. La estructura recomendada incluye tres niveles de aprobación: un cambio de configuración rutinario (riesgo bajo) que es aprobado a nivel de equipo; un cambio que afecta a un modelo de datos compartido o una integración (riesgo medio) que se eleva al CAB semanal; y un cambio arquitectónico (por ejemplo, modificar el modelo de Sharing o pasar a un Single-Org) que requiere la aprobación del Comité Directivo a nivel de CIO. En la práctica, el CAB más efectivo que hemos observado no es el que tiene mayor transparencia documental, sino aquel donde existe un SLA claro: una solicitud de cambio de riesgo medio recibe una respuesta en 3 a 5 días hábiles, no "en la próxima reunión que se celebre en algún momento". Cuando el SLA no se respeta, los equipos aprenden a eludir el proceso, y es precisamente en ese momento cuando la gobernanza se derrumba en la práctica, incluso si existe en el papel. ### Tabla de Responsabilidad (RACI) para Gobernanza Empresarial | Área de Decisión | Patrocinador de Negocio | Arquitecto Empresarial | Líder de Release/DevOps | Seguridad y Cumplimiento | PMO | | --- | --- | --- | --- | --- | --- | | Estructura del Org (Single/Multi-org) | Consultado | Responsable | Informado | Consultado | Informado | | Aprobación de cambios en objetos compartidos | Informado | Responsable | Consultado | Consultado | Informado | | Calendario de releases y Release Train | Informado | Consultado | Responsable | Informado | Responsable | | Política de permisos y Cumplimiento | Consultado | Consultado | Informado | Responsable | Informado | | Dependencia entre programas paralelos | Responsable | Consultado | Informado | Informado | Responsable | | Localización para un nuevo mercado | Responsable | Responsable | Informado | Consultado | Responsable | Esta tabla no es una plantilla fija; debe adaptarse a la estructura organizacional real. El punto importante es que "Responsable" aparece solo una vez en cada fila —cuando dos entidades tienen la propiedad completa de la misma decisión, es la primera señal de que la estructura causará demoras. ## Single-Org vs. Multi-Org Esta es una de las decisiones más costosas de corregir a posteriori. Un Single-Org con separación de permisos precisa (Profiles, Permission Sets, Record Types y Sharing Rules) permite un informe único sobre toda la organización, menos mantenimiento de integraciones y un costo de licenciamiento más bajo. El problema comienza cuando diferentes unidades de negocio requieren una frecuencia de releases completamente distinta, o cuando existe un requisito regulatorio que exige una separación física de los datos. Un Multi-Org resuelve el problema de la separación, pero crea uno nuevo: cada informe inter-organizacional requiere una capa de BI separada o una solución como Data Cloud, y cada proceso global (por ejemplo, Lead-to-Cash) debe construirse dos veces o gestionarse a través de MuleSoft/mecanismos de sincronización. En organizaciones que han explorado ambos caminos, la transición de Single-Org a Multi-Org después de que la organización ya es grande tiende a tardar entre 9 y 14 meses e incluye una compleja migración de datos; por lo tanto, es mejor tomar la decisión temprano, incluso si esto significa convivir temporalmente con una solución de compromiso en la separación de permisos. ## Release Train y DevOps a Nivel Empresarial Cuando varios equipos trabajan en el mismo Org, el despliegue "cuando esté listo" deja de funcionar. El modelo que funciona a escala empresarial es el Release Train: una frecuencia constante (quincenal o mensual), una única Fuente de Verdad en Control de Versiones, y un Pipeline que identifica conflictos en los metadatos entre los equipos antes del día del despliegue, no el mismo día. Componentes prácticos a incluir: - Un entorno de integración compartido donde todos los equipos realizan merges antes de pasar a UAT. - Una ventana de Code Freeze fija (generalmente 48-72 horas) antes de cada release. - Pruebas de regresión automatizadas que se ejecutan sobre los escenarios clave de cada unidad de negocio, no solo sobre el nuevo cambio. - Una política clara: un equipo que no cumpla con el tiempo de merge pasará al siguiente tren y no detendrá a todos. Una ampliación sobre la infraestructura de Sandboxes y los procesos de Pipeline se detalla en [Salesforce DevOps Sandboxes](/es/insights/salesforce-sandbox-devops-strategy), donde también se presenta la estructura recomendada para los entornos entre Dev y Production. ## Seguridad y Cumplimiento a Nivel Empresarial Con más de 500 usuarios, el modelo de permisos se convierte en un activo crítico por sí mismo. Un error común es construir un Profile nuevo para cada pequeño cambio, lo que genera en uno o dos años cientos de Profiles de los que nadie recuerda la lógica detrás. El enfoque que funciona mejor: un Profile restringido según un rol amplio, y Permission Sets modulares que se añaden según la necesidad específica. En organizaciones globales se añade una capa de Compliance: el GDPR en Europa exige capacidad de eliminación y documentación del consentimiento, la regulación de privacidad en Israel requiere el registro de bases de datos, y las organizaciones de salud o financieras en EE.UU. pueden requerir HIPAA o SOX. El significado práctico: cifrado a nivel de campo para datos sensibles, logs de acceso a registros (Field Audit Trail o Shield) y un proceso de documentación que muestre quién accedió a qué y cuándo, no solo quién está autorizado a acceder. ## Globalidad y Localización Una implementación que opera en varios países se encuentra con tres problemas recurrentes: monedas y fechas (Multi-Currency y formato de fecha según Locale), idioma en la interfaz y en los informes (Translation Workbench no siempre cubre campos personalizados), y procesos de aprobación que entran en conflicto con la legislación laboral o fiscal local. Un equipo que planifica la localización como una adición al final del proyecto generalmente descubre que requiere un cambio en el propio modelo de datos, no solo la traducción de cadenas. ## PMO y Dependencia entre Programas Paralelos En una organización grande, un proyecto de Salesforce casi nunca se ejecuta solo. Paralelamente, se ejecutan programas de ERP, un proyecto de Data Warehouse y, a veces, la fusión de dos empresas. Un PMO que no mapea la dependencia entre los programas descubre en una etapa avanzada que él y el ERP están construyendo al mismo tiempo dos fuentes de verdad diferentes para los mismos datos de clientes. La herramienta práctica es una matriz de dependencias que se actualiza mensualmente: para cada programa, qué datos "lidera" (Source of Truth) y qué datos solo consume. Cuando dos programas reclaman la propiedad del mismo campo, el PMO es la entidad que debe decidir, no dejar que se resuelva "en el terreno" entre dos desarrolladores. ## Patrones de Fallo Típicos por Encima de 500 Usuarios | Patrón de Fallo | Cómo se ve en la práctica | Acción preventiva | | --- | --- | --- | | Proliferación de perfiles (Profile Sprawl) | Cientos de perfiles casi idénticos; nadie está seguro de qué está permitido para quién | Transición gradual a Permission Sets modulares | | Despliegue "privado" de un equipo | Un equipo se despliega a producción sin pasar por el CAB, rompiendo otro proceso | Un Release Train obligatorio con Code Freeze compartido | | Dos fuentes de verdad para el mismo dato | ERP y CRM, cada uno "propietario" de los datos del cliente | El PMO establece una única Fuente de Verdad para cada dominio de datos | | Permisos demasiado amplios "para no bloquear" | Fuga de información sensible entre unidades de negocio | Menor privilegio según el rol; auditoría trimestral | | Localización como una adición tardía | Traducción parcial, formato de fecha incorrecto, informes rotos en una región | Planificación del Locale y la moneda en el modelo de datos desde el primer día | | Sandbox no sincronizado | Pruebas que pasan en Sandbox y fallan en Producción debido a diferencias de configuración | Refresh programado y política de Seed Data uniforme | ## Proceso de Trabajo Recomendado para Implementaciones a Escala Empresarial ### 1. Establezca el Comité Directivo y la Junta Consultiva de Cambios antes de iniciar la construcción. Antes de escribir la primera línea de código, se debe designar un Patrocinador a nivel de dirección, definir los tres niveles de aprobación para los cambios y acordar un SLA para la respuesta. Sin esto, los primeros equipos que comienzan a trabajar establecen de facto el precedente para todos los que vienen después. ### 2. Decida entre Single-Org o Multi-Org tempranamente y documente la razón. Esta decisión debe basarse en los requisitos regulatorios actuales y la frecuencia de releases necesaria, no en una preferencia técnica. Debe documentarse la alternativa descartada y la condición que provocará una reevaluación (por ejemplo, la adquisición de una nueva empresa). ### 3. Construya un Release Train antes de tener más de un equipo. Una frecuencia constante, un entorno de integración compartido y un proceso de identificación de conflictos antes del día del release. El equipo central del proyecto se define en [Roles del Equipo de Proyecto de Salesforce](/es/insights/salesforce-project-team-roles), pero a escala empresarial también se requiere un rol dedicado de Release Manager. ### 4. Mapee los permisos y los requisitos de cumplimiento según el área de operación. Identifique de antemano qué regulaciones se aplican en cada país de operación y planifique el cifrado, los logs y el proceso de eliminación en consecuencia, y no como una adición después de una queja o auditoría. ### 5. Documente las dependencias entre programas en el PMO y actualícelas mensualmente. Una matriz de dependencias viva, no un documento escrito una sola vez al inicio del proyecto. Cada cambio en el cronograma de un programa se verifica contra el impacto en otros programas. ### 6. Ejecute un piloto en una unidad de negocio antes de un Rollout empresarial completo. Un Vertical Slice completo, incluyendo permisos e integraciones reales, permite identificar problemas de gobernanza y release antes de que se multipliquen en decenas de unidades. La comprensión de los bloques de construcción a nivel de User Story se presenta en [User Stories de Salesforce](/es/insights/salesforce-user-stories-backlog). ### 7. Expanda en oleadas controladas con medición entre cada oleada. Cada oleada de Rollout se mide contra una línea de base antes de expandirse a la siguiente oleada. Si la primera oleada revela un problema de gobernanza, se corrige antes de continuar, no se expande mientras se corrige. ## Escenario Organizacional de Ejemplo Una compañía de seguros con 1,200 usuarios en tres países intentó implementar Salesforce con dos equipos de desarrollo paralelos —uno para ventas y otro para servicio— sin un CAB activo. Después de cinco meses, ambos equipos modificaban el mismo objeto de cliente cada semana, y los procesos de prueba fallaban intermitentemente sin que nadie supiera por qué. La solución no fue técnica: la organización estableció un CAB semanal con un SLA de 3 días, designó un único Propietario de Objeto para cada entidad central y pasó a un Release Train quincenal con un entorno de integración compartido. En dos meses, el número de conflictos entre los equipos disminuyó significativamente y el cronograma de lanzamiento en los tres países se estabilizó. La lección principal: la escala empresarial no falla debido a la tecnología, sino por la falta de una clara propiedad sobre los datos compartidos. ## Lista de Verificación antes de la Expansión a Escala Empresarial - ☐ Existe una Junta Consultiva de Cambios con un SLA definido y no solo en papel. - ☐ La decisión Single-Org vs. Multi-Org está documentada con una condición para su reevaluación. - ☐ Existe un Release Train con una frecuencia regular y un entorno de Integración compartido. - ☐ El modelo de permisos se basa en Permission Sets y no en un nuevo Profile para cada cambio. - ☐ Se han revisado los requisitos de Cumplimiento para cada país de operación. - ☐ Existe una matriz de dependencias entre programas paralelos que se actualiza mensualmente. - ☐ Se ha definido un Propietario de Objeto único para cada entidad de datos compartida. - ☐ Se ha realizado un piloto en una unidad de negocio antes de un Rollout completo. - ☐ Existe un plan de localización que va más allá de la traducción de cadenas. - ☐ Se han definido métricas de éxito separadas para cada oleada de expansión. ## 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 ### Preguntas y respuestas **¿Cuándo se vuelve relevante la necesidad de un Multi-org en la práctica?** Cuando las unidades de negocio operan con modelos de venta, normativas o idiomas completamente diferentes, y cuando la frecuencia de los cambios en una unidad podría afectar la estabilidad de otra. En la mayoría de las organizaciones con hasta 3.000-5.000 usuarios, un Single-org con una separación precisa de permisos sigue siendo preferible, ya que el costo de mantenimiento de un Multi-org es significativamente mayor. **¿Cuánto tiempo toma establecer una junta de aprobación de cambios (CAB) que funcione eficazmente?** En promedio, de seis a ocho semanas hasta que el proceso se estabilice: definición de tipos de cambio, umbrales de aprobación, calendario de reuniones fijo y formato de solicitud. La verdadera dificultad no es definir el proceso, sino hacer que se cumpla cuando la presión empresarial urge a soslayarlo. **¿Cómo se planifica un Release Train cuando hay 6-8 equipos paralelos?** Se establece una frecuencia regular (por ejemplo, semanal o mensual), una ventana de Code Freeze conjunta y un mecanismo de Merge que identifica conflictos entre metadatos antes del despliegue. Los equipos que no están listos para la fecha pasan al siguiente tren; no se retrasa a todo el grupo. **¿Qué cambia en los requisitos de cumplimiento normativo cuando la organización opera en varios países?** Se requiere un mapeo por región: GDPR en Europa, la Ley de Protección de la Privacidad en Israel, y a veces HIPAA o SOX en organizaciones de salud y finanzas estadounidenses. La diferencia práctica radica en la retención de datos, el cifrado de campos y los registros de acceso, no solo en los permisos de perfil. **¿Qué sucede cuando un proyecto de CRM y uno de ERP chocan en el cronograma?** A menudo, la dependencia en la integración o en una única fuente de verdad (por ejemplo, datos del cliente) solo se descubre en una etapa avanzada. La PMO debe mapear las dependencias entre proyectos desde el primer día y determinar qué proyecto 'lidera' en cada área de datos, para evitar que se tomen dos decisiones contradictorias sobre el mismo campo. --- ## Migración a Salesforce: Planifique el cambio sin perder procesos ni información crítica URL: https://hpi.pro/es/insights/replace-crm-with-salesforce La migración entre sistemas CRM a menudo falla, no por Salesforce, sino por una gestión deficiente de los datos históricos. Este artículo detalla cómo mapear procesos existentes, seleccionar qué información dejar atrás y cuándo desconectar el sistema antiguo de forma segura. ## La respuesta corta Reemplazar un sistema CRM con Salesforce no es un proyecto técnico de "migración de datos"; es una decisión organizacional sobre lo que merece ser conservado, lo que debe dejarse atrás y cómo mantener la operación del negocio mientras se realiza la transición. El error más común no radica en la definición de Salesforce en sí, sino en la suposición tácita de que todo lo que existe en el sistema antiguo debe transferirse tal cual. El enfoque correcto comienza con la elaboración de un mapa de procesos, no con la exportación de tablas. Posteriormente, se construye un nuevo modelo de datos que se alinee con la forma en que la organización opera actualmente, no con la estructura establecida hace diez años en otro sistema. Un período de operación en paralelo controlado y, finalmente, la desconexión ordenada del sistema antiguo con documentación para fines regulatorios, completan el proceso. Las organizaciones que enfrentan estas preguntas encontrarán información complementaria en [Implementación de Salesforce en la organización](/es/insights/salesforce-implementation-guide), donde se detalla el proceso integral de toma de decisiones en un proyecto de Salesforce. ## Mapeo de procesos existentes: no exportar, sino comprender El primer paso en cualquier transición de sistemas CRM no es presionar "Exportar", sino sentarse con los propietarios de los procesos y comprender qué ocurre realmente desde la apertura de un lead hasta el cierre de un negocio, o desde la recepción de una consulta hasta el cierre de un caso de servicio. Un documento de procesos antiguo, si es que existe, está casi siempre desactualizado en relación con lo que sucede en la práctica. En las reuniones de mapeo, conviene documentar no solo los pasos oficiales, sino también los "procesos en la sombra": archivos de Excel paralelos, campos que nadie rellena, aprobaciones que se envían por WhatsApp en lugar de a través del sistema. Estos son precisamente los puntos donde un nuevo sistema, incluso si está bien construido, falla en la adopción si no se tienen en cuenta. El resultado del mapeo debe incluir una tabla con los procesos clave, el propietario del proceso, la frecuencia de uso y el grado de dependencia del sistema antiguo. Un proceso ejecutado una vez al trimestre que genera un informe crítico para el regulador requiere un tratamiento diferente al de un proceso diario de alto volumen. Esta clasificación determina tanto el orden de la migración como el nivel de pruebas necesario para cada proceso. ## Qué no migrar: una decisión que ahorra la mitad del trabajo Una de las decisiones más significativas en un proyecto de migración de CRM no es qué migrar, sino qué **no** migrar. En la mayoría de los sistemas antiguos que se han acumulado durante años, existen capas de campos duplicados, estados que han sido reemplazados y procesos definidos para un proyecto puntual que ya concluyó. Una regla práctica: cualquier objeto o campo que no haya sido utilizado en los últimos dos años se traslada a la lista de "no migrar" por defecto, a menos que un propietario de proceso específico solicite una excepción justificada. Esta lista se construye a partir de los registros de uso real del sistema antiguo, no de la memoria de los usuarios, ya que la memoria humana suele describir el sistema tal como se suponía que funcionaba y no como funciona en la práctica. Es importante distinguir entre tres categorías de información: - **Información activa** – Debe migrar al nuevo sistema como un registro operativo con todas sus relaciones asociadas. - **Información histórica relevante** – Migra como archivo para consulta, generalmente sin necesidad de edición o automatización. - **Información inactiva** – No migra en absoluto, se conserva únicamente en una copia de seguridad externa en caso de auditoría. Una ampliación sobre la gestión de los límites entre la fase de planificación y la de construcción se encuentra en [Scope Creep en Salesforce](/es/insights/salesforce-scope-creep-change-control), ya que la tendencia a añadir "un poco más de datos antiguos" es una de las fuentes más comunes de desviación del alcance en proyectos de este tipo. ## Modelo de datos nuevo versus antiguo: no es una traducción, es un diseño Un error común es abordar el modelo de datos como una traducción 1:1: cada tabla del sistema antiguo se convierte en un objeto en Salesforce, cada columna en un campo. Este enfoque conserva todas las debilidades del sistema antiguo dentro de una nueva plataforma y desaprovecha la principal ventaja de Salesforce: la capacidad de construir relaciones flexibles entre objetos, automatización integrada y una rica capa de permisos. Una comparación entre los dos enfoques principales para la migración ayuda a tomar una decisión informada: | Aspecto | Lift-and-Shift (Migración tal cual) | Rediseño | | --- | --- | --- | | Tiempo del proyecto | Relativamente corto, generalmente 6-10 semanas | Más largo, típicamente 3-5 meses | | Adecuación al proceso de negocio | Baja — conserva limitaciones antiguas | Alta — construido alrededor del proceso actual | | Riesgo de deuda técnica | Alto, se manifiesta en uno o dos años | Menor, ya que la estructura se planifica de antemano | | Costo de mantenimiento futuro | Aumenta con el tiempo | Relativamente estable | | Adecuado para | Organizaciones con presión de tiempo extrema o un Scope muy limitado | La mayoría de las organizaciones que migran de un sistema de más de tres años | | Riesgo principal | "Sistema nuevo, problemas antiguos" | Desviación del cronograma si el Scope no está bien definido | En la práctica, la mayoría de las organizaciones optan por un enfoque intermedio: Rediseño para el modelo central (cuentas, contactos, oportunidades o casos de servicio), y un Lift-and-Shift controlado para entidades secundarias que no tienen un impacto procesal significativo. Esta decisión debe tomarse explícitamente en la fase de planificación, no surgir de forma aleatoria durante la construcción. ## Período de paralelismo: cómo mantener la continuidad del negocio El período de paralelismo es la ventana de tiempo en la que ambos sistemas operan en paralelo, generalmente entre cuatro y ocho semanas. Su objetivo es exponer las brechas en tiempo real, antes de que se conviertan en un problema irreversible. Una venta cerrada, una llamada de servicio abierta o un informe de comisiones generado, todo esto debe verificarse simultáneamente en ambos sistemas y mostrar un resultado idéntico o explicable. Una pregunta que se repite en casi todos los proyectos: ¿cuál es el sistema considerado "fuente de la verdad" durante este período? La respuesta debe ser única y definida de antemano, generalmente Salesforce desde el primer día, donde el sistema antiguo se utiliza solo para verificación y no para el trabajo diario. El trabajo duplicado de los usuarios en ambos sistemas es una receta para la fatiga y el abandono real del nuevo sistema. Herramientas prácticas para gestionar el período: - Un informe de comparación diario o semanal entre los datos clave de ambos sistemas (número de leads, monto de transacciones, llamadas abiertas). - Una lista de excepciones en vivo que se actualiza tan pronto como se detecta una brecha, con un Propietario responsable de cerrarla en un plazo definido. - Un grupo de "usuarios ancla" de cada departamento que informan diariamente sobre problemas de uso, no solo sobre problemas técnicos. Gran parte de los conocimientos recopilados durante este período son relevantes también para el proceso de pruebas sistemáticas, detallado en la [Guía de UAT para Salesforce](/es/insights/salesforce-uat-guide), y para el período posterior al lanzamiento, descrito en el [Plan de Hypercare para Salesforce](/es/insights/salesforce-hypercare-plan). ## Desconexión del sistema antiguo: no es un evento único, sino una secuencia de decisiones La desconexión del sistema antiguo se realiza por fases, no con un solo clic el día del Cutover. La regla general: el sistema se desconecta de la operación diaria inmediatamente el día del Go Live, pero permanece accesible solo en modo de lectura por un período de gracia corto, generalmente de 30 a 60 días, en caso de que se detecte un dato faltante o una pregunta del equipo financiero. ### Lista de verificación para la decisión de Cutover Antes de emitir un anuncio oficial de que el sistema antiguo ha sido desconectado, es aconsejable verificar lo siguiente: - ☐ Todos los informes que se generaban regularmente desde el sistema antiguo han sido recreados con éxito en Salesforce o desde el archivo. - ☐ Se ha completado un ciclo de negocio completo (por ejemplo, un cierre de mes completo) íntegramente dentro del nuevo sistema. - ☐ Las discrepancias de datos entre los sistemas han disminuido por debajo de un umbral predefinido (por ejemplo, menos del 1% de los registros). - ☐ Existe una confirmación por escrito del departamento legal o financiero de que el archivo cumple con los requisitos de conservación. - ☐ Se ha definido quién es el responsable del acceso de solo lectura durante el período de gracia y cuándo se cerrará definitivamente. - ☐ Se ha realizado y verificado una copia de seguridad completa de todos los datos del sistema antiguo antes de cancelar la licencia. - ☐ Se ha enviado una notificación a todos los propietarios de procesos sobre la fecha de desconexión final y la forma de acceder al archivo. Saltarse cualquiera de estos puntos es la razón más común por la que, meses después del proyecto, se descubre que no hay acceso a la información que de repente se necesita para una auditoría fiscal o un litigio. ## Archivo y regulación: qué se debe conservar y por cuánto tiempo Los requisitos de retención de datos varían entre los sectores, pero casi siempre existe la obligación de conservar datos financieros, contractuales o relacionados con quejas de clientes por un período de siete años o más. El error común es intentar "empujar" todo este historial a Salesforce como registros activos, lo que sobrecarga el rendimiento y confunde a los usuarios que ven transacciones de hace una década en sus listas diarias. La solución habitual es la separación en dos capas: | Capa | Contenido | Ubicación | Accesibilidad | | --- | --- | --- | --- | | Información operativa activa | Últimos 24-36 meses | Salesforce | Completa, incluyendo edición y automatización | | Archivo regulatorio | Historial completo según lo 법 | Almacén de datos externo o Salesforce Archive | Solo lectura, con capacidad de búsqueda | Es crucial documentar la política de archivo por escrito y obtener la aprobación del departamento legal antes de revocar el acceso al sistema antiguo, ya que una vez que la licencia es cancelada, no hay vuelta atrás si se descubre que falta un dato. ## Escenario organizacional de ejemplo Una empresa de servicios financieros migró de un sistema CRM local de 12 años a Salesforce. Durante la fase de mapeo, el equipo identificó que aproximadamente el 40% de los campos existentes no se habían tocado en dos años o más, y decidió excluirlos de la migración. Esto ahorró aproximadamente un mes de trabajo en construcción y pruebas. Durante el período de paralelismo, que duró seis semanas, se detectó una discrepancia en el cálculo de comisiones debido a una diferencia en el redondeo de números entre los sistemas, un error que no se habría descubierto sin un informe de comparación diario. El equipo corrigió la fórmula antes de que afectara a una nómina real. El sistema antiguo se desconectó de la operación diaria el día del Go Live, pero el acceso de lectura se mantuvo durante 45 días adicionales para la verificación de un informe trimestral que ya estaba en proceso. El resultado: a los tres meses de la desconexión final, no se requirió acceso adicional al sistema antiguo, y el ahorro en costos de licencias cubrió una parte considerable del costo del propio proyecto de migración. ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Migrar "todo" sin filtrar | El nuevo sistema está abarrotado de datos inactivos y ralentiza la adopción | Definir un criterio de filtrado basado en el uso real en los últimos dos años | | Modelo de datos copiado | Las mismas limitaciones del sistema antiguo se repiten en Salesforce | Diseñar un nuevo modelo alrededor del proceso actualizado, no de las tablas antiguas | | Paralelismo sin Owner | Las brechas entre los sistemas se detectan tarde o no se detectan | Informe de comparación periódico con un responsable definido para cada excepción | | Desconexión demasiado apresurada | Se descubre un dato faltante después de que la licencia ya ha sido cancelada | Período de gracia de acceso de solo lectura antes de la cancelación definitiva | | Ignorar los requisitos de archivo | Una auditoría regulatoria revela que la información requerida no se conservó correctamente | Obtener aprobación legal por escrito sobre la política de archivo antes del Cutover | ## Cómo medir el éxito de la transición | Área | Qué se mide | Frecuencia de revisión | | --- | --- | --- | | Integridad de los datos | Tasa de registros transferidos con éxito y sin errores | Antes y después de cada ejecución de migración | | Coincidencia entre sistemas | Discrepancias en informes clave entre el sistema antiguo y el nuevo | Diariamente durante el período de paralelismo | | Adopción por parte de los usuarios | Tasa de trabajo en el nuevo sistema frente al retorno al antiguo | Semanal durante el primer mes | | Costo operativo | Ahorro en licencias y mantenimiento tras la desconexión | Mensual a partir de los tres meses tras el Go Live | Para el reemplazo de un sistema CRM por Salesforce, es recomendable seleccionar de antemano entre tres y cinco métricas clave, y medirlas tanto antes como después del proyecto. De lo contrario, es difícil demostrar que la transición realmente mejoró el proceso y no solo lo trasladó a otra plataforma. La ejecución práctica de un proceso así puede realizarse con el apoyo de [servicios de implementación de Salesforce](/es/salesforce-implementation), que acompañan a las organizaciones desde la fase de mapeo hasta la desconexión del sistema antiguo. ## 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 ### Preguntas y respuestas **¿Cuántos datos históricos deben migrarse del sistema anterior?** Como regla general, lo práctico es migrar los últimos 24-36 meses como registros activos al nuevo sistema. El resto se transfiere a un archivo de acceso restringido. Migrar una década de historial 'porque es posible' encarece la migración y afecta el rendimiento sin un beneficio comercial demostrado. **¿Qué hacer con los campos que no tienen un equivalente en el nuevo modelo de datos?** Primero, verifique si el campo todavía se utiliza en un proceso activo o si es un remanente histórico. Un campo activo recibirá un mapeo explícito o un nuevo Custom Field; un campo obsoleto solo se conservará en un archivo externo, sin arrastrarlo a Salesforce como un 'campo de texto libre' que nadie entenderá en un año. **¿Cuánto tiempo debe durar el período de coexistencia entre los sistemas?** En promedio, de cuatro a ocho semanas para una organización de tamaño mediano, dependiendo de la complejidad del ciclo de ventas o servicio. Un período demasiado corto no revelará excepciones estacionales; un período demasiado largo acostumbra a los usuarios a trabajar en ambos sistemas y retrasa la adopción. **¿Cuándo se puede desconectar permanentemente el sistema anterior?** Solo después de que se hayan cumplido tres condiciones: coincidencia de datos sin discrepancias significativas entre los sistemas, al menos un ciclo de negocio completo ejecutado en Salesforce, y cada informe regulatorio o de auditoría basado en el sistema anterior se haya replicado exitosamente desde el archivo. **¿Se necesita mantener acceso en vivo al sistema anterior después de la migración?** Por lo general, no se requiere acceso en vivo más allá de un breve período de gracia de 30 a 60 días para pruebas excepcionales. Posteriormente, una simple copia de seguridad para fines regulatorios y de auditoría es suficiente en la mayoría de los sectores, lo que reduce significativamente los costos de licencia y mantenimiento en comparación con mantener el sistema antiguo activo. --- ## Conexión de Salesforce a un ERP: Guía de Arquitectura, Patrones y Riesgos URL: https://hpi.pro/es/insights/salesforce-erp-integration En cualquier integración entre Salesforce y un ERP, siempre llega un momento en que dos números —inventario, saldo deudor o estado del pedido— entran en conflicto, y alguien debe decidir cuál es el correcto. Esta guía enmarca la decisión en torno a la fuente de la verdad, el patrón de sincronización y la planificación de fallos, y no simplemente en una lista de conexiones de API. ## La respuesta breve La conexión entre Salesforce y un sistema ERP a menudo falla, no por un problema técnico en la integración misma, sino por una pregunta no formulada de antemano: ¿qué sistema es el origen de la verdad para cada entidad, y qué sucede cuando el mensaje entre los sistemas se pierde, llega duplicado o en un orden incorrecto? Esta guía estructura la decisión en torno a tres capas: origen de la verdad, patrón de sincronización y manejo de fallos, y muestra cómo elegir entre ellas según un escenario de negocio real, no según lo que permite la API. El enfoque recomendado es comenzar por las entidades (cliente, producto, pedido, factura) y no por la herramienta. Para cada entidad, se define un único propietario, una frecuencia de actualización razonable y quién está autorizado a realizar cambios. A partir de ahí, se derivan el patrón de sincronización, el manejo de errores y el nivel de monitoreo requerido. Una continuación natural a la discusión sobre la conexión entre Salesforce y un ERP se encuentra en la [Arquitectura de Salesforce](/es/insights/crm-architecture-guide). ## Origen de la verdad para cada entidad: la pregunta que precede a cualquier API Antes de elegir un protocolo o herramienta de integración, es fundamental responder a una pregunta para cada entidad: ¿cuál es el sistema que decide qué es correcto en caso de conflicto? Generalmente, el ERP es el origen de la verdad para el inventario, la lista de precios, las facturas y los movimientos financieros, mientras que Salesforce es el origen de la verdad para las relaciones con los clientes, las oportunidades y la actividad de ventas. El problema surge cuando se asume tácitamente que ambas direcciones "se resolverán solas", lo que puede llevar a situaciones donde un representante de ventas cambia una dirección de envío en Salesforce mientras el ERP ya ha despachado el envío a la dirección antigua. La solución práctica es un documento de mapeo de entidades: para cada entidad (Account, Product, Order, Invoice), se especifica el origen de la verdad, la dirección de sincronización (unidireccional o bidireccional) y la frecuencia de actualización requerida. Cuando hay una necesidad real de sincronización bidireccional, por ejemplo, la actualización del estado de pago que regresa del ERP al registro de oportunidad, se establece una regla explícita para la resolución de conflictos, como "la última actualización según la marca de tiempo (Timestamp) prevalece" o "el campo monetario siempre se rige por el ERP". |Entidad|Origen de la verdad|Dirección de sincronización|Frecuencia típica| |---|---|---|---| |Cliente (Account)|Salesforce|Bidireccional con regla de conflicto|Casi instantánea| |Producto y lista de precios|ERP|Unidireccional a Salesforce|Diaria o según cambios| |Pedido (Order)|Creado en Salesforce, gestionado en ERP|Bidireccional, fases separadas|Inmediata en fase de creación| |Factura y pago|ERP|Unidireccional a Salesforce|Diaria o casi en tiempo real (Near Real-Time)| |Inventario disponible|ERP|Unidireccional a Salesforce|Cada pocos minutos hasta horaria| ## Patrones de sincronización: Request-Reply, Batch y Event-Driven Tres patrones cubren la mayoría de los escenarios prácticos. **Request-Reply (síncrono)** es adecuado cuando un usuario en Salesforce espera una respuesta inmediata, por ejemplo, la verificación de disponibilidad de inventario antes de confirmar un pedido. La ventaja es la simplicidad y la respuesta inmediata; la desventaja es la dependencia total de la disponibilidad del ERP en ese momento y el impacto en la experiencia del usuario si la respuesta es lenta. **Batch (por lotes)** es adecuado para actualizaciones de gran volumen que no son urgentes, como la sincronización nocturna de la lista de precios o la importación de facturas del día anterior. Este patrón es más resistente a fallos temporales, pero implica una latencia de horas a un día entre los sistemas, un retraso que debe ser aceptable para el negocio, no solo para el equipo técnico. **Event-Driven** (mediante Platform Events, Change Data Capture o una cola de mensajes externa) es adecuado cuando se necesita una respuesta casi inmediata sin requerir una dependencia síncrona. Un cambio de estado de pedido en el ERP emite un evento, y Salesforce se actualiza cuando está listo, incluyendo reintentos automáticos si estuvo temporalmente no disponible. Este es el patrón más flexible, pero también el más complejo de configurar y monitorear. ### Tabla de selección de patrones por escenario |Escenario|Patrón recomendado|Latencia típica|Riesgo principal| |---|---|---|---| |Verificación de inventario antes de confirmar pedido|Request-Reply|Pocos segundos|Dependencia total de la disponibilidad del ERP; el tiempo de espera (Timeout) afecta la experiencia del usuario| |Sincronización de lista de precios y productos|Batch nocturno|Horas a 24 horas|Datos desactualizados entre ejecuciones; requiere coordinación con campañas y promociones| |Actualización de estado de pago|Event-Driven|Segundos a minutos|Complejidad operativa; requiere monitoreo de cola de mensajes y Dead Letter Queue| |Creación de nuevo pedido en ERP|Request-Reply con Retry|Segundos a un minuto|Fallo parcial: el pedido se creó en el ERP pero la respuesta se perdió, arriesgado a duplicidades| |Actualización de inventario disponible para venta|Batch frecuente (cada 15-60 minutos)|Minutos|Vende basándose en inventario que ya se agotó entre ejecuciones| |Alerta por exceder límite de crédito|Event-Driven|Casi inmediato|Un evento perdido provoca la aprobación de una transacción que no debería haber ocurrido| En este contexto, la decisión sobre el tipo de sincronización también se relaciona con el modelo de permisos y la propiedad de los datos; una extensión sobre esto se encuentra en [Salesforce Sharing and Visibility](/es/insights/salesforce-sharing-visibility-design). ## Middleware versus Point-to-Point Cuando hay una sola conexión entre Salesforce y un ERP, una conexión directa (Point-to-Point) utilizando REST API o Named Credentials puede ser la solución más rápida y económica. El problema surge cuando se incorpora un tercer sistema (un almacén de datos, un sistema de envío o una plataforma de procesamiento de pagos), ya que cada nuevo sistema requiere la construcción de su propia lógica de transformación y manejo de errores, duplicando lo que ya existe en la conexión anterior. Una capa de Middleware (como MuleSoft, Boomi o Workato) resuelve esto centralizando la lógica: cada sistema se conecta una sola vez al Middleware, y este se encarga de la transformación, los reintentos (Retry), la cola de mensajes y el monitoreo centralizado. El precio es un componente de infraestructura adicional que requiere licencia, mantenimiento y experiencia especializada. Una regla general práctica: hasta dos o tres conexiones estables y sin lógica compleja, Point-to-Point es razonable. Con tres o más sistemas, o cuando hay un requisito de gobernanza centralizada (como monitoreo uniforme para todas las integraciones en la organización), el costo del Middleware se justifica casi siempre en uno o dos años. ## Manejo de errores y Idempotency El escenario más peligroso en la integración no es un fallo total, sino un **fallo parcial**: el mensaje fue enviado, el ERP creó un pedido, pero la respuesta a Salesforce se perdió debido a un tiempo de espera (Timeout). Si el sistema emisor intenta nuevamente de forma ingenua, se crea un pedido duplicado. La solución es una Clave de Idempotencia (Idempotency Key): un identificador único creado en el lado emisor y adjunto a cada solicitud. El lado receptor mantiene un registro de los identificadores ya procesados y rechaza (o devuelve el resultado existente) si el identificador ya existe. Otros principios prácticos: - Cada integración crítica recibe un mecanismo de reintento (Retry) con retroceso exponencial gradual, no un intento inmediato y repetido. - Los mensajes que fallaron repetidamente se mueven a una cola de mensajes no entregados (Dead Letter Queue) para revisión manual, y no desaparecen en silencio. - El registro de errores (Error Log) incluye la carga útil completa (Payload) del mensaje fallido para permitir la recuperación manual. - Un proceso de reconciliación diario o semanal compara los sistemas e identifica las discrepancias que la sincronización "perdió". Sin una Clave de Idempotencia y un proceso de reconciliación ordenado, cualquier problema de red transitorio se convierte en un problema de datos persistente que es difícil de localizar semanas después. ## Limitaciones de API, seguridad y monitoreo Salesforce impone límites diarios en el número de llamadas a la API (dependiendo de la licencia y la edición), y límites en el tamaño de la respuesta y el tiempo de ejecución. Una organización que sincroniza decenas de miles de registros al día a través de REST regular, llamada por llamada, alcanzará el límite rápidamente. La solución es Bulk API 2.0 para actualizaciones de volumen, y Composite API para reducir el número de llamadas en procesos síncronos de múltiples pasos. En cuanto a la seguridad, tres principios se repiten en cada proyecto exitoso: 1. El uso de Named Credentials y Connected Apps con OAuth, no nombres de usuario y contraseñas fijas en el código. 2. Los permisos del "usuario técnico" de la integración están restringidos exactamente a los objetos y campos que necesita, no un perfil de administrador del sistema. 3. El tráfico sensible (números de tarjeta de crédito, detalles de cuentas bancarias) se gestiona a través de una capa de Middleware o Tokenización, no se almacena como texto plano en Salesforce. Para el monitoreo, se debe establecer un panel (Dashboard) que muestre al menos tres datos: la tasa de mensajes exitosos frente a fallidos, el tiempo de respuesta promedio y mediano, y el número de registros en la Dead Letter Queue. Una alerta automática cuando la tasa de fallos cruza un umbral definido (por ejemplo, más del 2% de los mensajes en un día) evita una situación en la que un problema acumulativo se detecta solo cuando un cliente se queja. Estas decisiones a menudo se basan en un trabajo fundamental previo en el área de información y permisos, descrito en [Deuda técnica de Salesforce](/es/insights/salesforce-flow-apex-technical-debt). ## Proceso de trabajo recomendado ### 1. Mapear entidades y definir el origen de la verdad Para cada entidad (cliente, producto, pedido, factura), se define cuál es el sistema que decide en caso de conflicto. Sin esta decisión, cualquier conversación sobre "cuál es la forma correcta de sincronizar" se lleva a cabo en la ambigüedad. ### 2. Elegir el patrón de sincronización según la latencia requerida en la práctica No todos los procesos necesitan una respuesta inmediata. La verificación de inventario antes de la venta sí; la actualización nocturna de la lista de precios no. Ajustar el patrón a la necesidad real ahorra costos de infraestructura innecesarios. ### 3. Decidir entre Middleware y Point-to-Point La decisión depende del número de sistemas conectados y de la necesidad de gobernanza centralizada, no de una mera preferencia tecnológica. ### 4. Planificar Idempotency, Retry y Reconciliación desde el principio Estos no son "mejoras futuras", sino parte de la definición de "listo" (Definition of Done) para cualquier integración que involucre dinero, inventario o pedidos. ### 5. Definir permisos mínimos para el usuario técnico Un perfil dedicado, no un permiso de administrador del sistema generalizado. Cualquier cambio en el permiso requiere una aprobación separada del cambio funcional. ### 6. Probar escenarios de fallo, no solo el "Happy Path" Realizar una prueba en la que el ERP "cae" en medio de un proceso, y medir el tiempo de recuperación y si se generan duplicados, revela problemas que no se ven en un entorno de desarrollo tranquilo. ### 7. Establecer un Dashboard y un proceso de Reconciliación permanente El monitoreo técnico (el servidor está vivo) no es suficiente; se necesita monitoreo de negocio (el número de pedidos es igual en ambos sistemas). ## Escenario empresarial de ejemplo Una empresa comercial con aproximadamente 40,000 pedidos al mes conectó Salesforce a su ERP mediante llamadas REST síncronas directas, sin Middleware. Durante un pico de ventas, la tasa de fallos en las llamadas a la API aumentó drásticamente debido al límite diario de llamadas, y los pedidos que no pudieron registrarse en el ERP simplemente "desaparecieron", porque no había una Dead Letter Queue ni una alerta. Después de la revisión, se descubrieron tres elementos faltantes: no se había definido una Clave de Idempotencia, por lo que los intentos repetidos a veces creaban pedidos duplicados; no se había utilizado Bulk API para actualizaciones de volumen; y no existía un proceso de reconciliación que comparara el número de pedidos en ambos sistemas. La solución incluyó la transición a una capa de Middleware con una cola de mensajes, el reemplazo de algunas de las llamadas síncronas por un Batch frecuente y la adición de un Dashboard diario para mostrar las discrepancias. El resultado no fue "cero fallos" (un objetivo poco realista), sino que el tiempo de detección de fallos se redujo de semanas a horas, y un proceso que permite corregir una brecha el mismo día y no después de que un cliente se queje. ## Riesgos comunes y acciones preventivas |Riesgo|Cómo se manifiesta en la práctica|Acción preventiva| |---|---|---| |Origen de la verdad no definido|Dos partes "correctas" simultáneamente, y nadie sabe en quién confiar|Documento de mapeo de entidades con propietario definido para cada campo crítico| |Falta de Idempotency|Pedidos duplicados después de cada fallo de red temporal|Clave de Idempotencia y verificación de duplicidad en el lado receptor| |Point-to-Point sin gobernanza|Cada cambio en un sistema rompe silenciosamente otras conexiones|Capa de Middleware, contratos documentados y propiedad clara| |Ignorar las limitaciones de la API|Llamadas fallidas en el pico de carga, sin alerta temprana|Transición a Bulk API, monitoreo del consumo de cuota diaria| |Permisos amplios para el usuario técnico|Exposición de información sensible más allá de la necesidad de integración|Perfil restringido y revisión periódica de permisos| Quienes se encuentren en una etapa más temprana que la planificación de la conexión pueden encontrar información complementaria en [Salesforce Flow o Apex](/es/insights/salesforce-flow-vs-apex), especialmente en la decisión sobre dónde implementar la lógica de transformación. ## Cómo medir el éxito |Área|Qué se mide|Frecuencia de revisión| |---|---|---| |Fiabilidad|Tasa de mensajes completados versus fallidos|Continua, con alerta sobre umbral excedido| |Latencia|Tiempo de extremo a extremo para cada escenario por separado|Continua| |Consistencia de datos|Número de discrepancias en la revisión de reconciliación|Diaria o semanal| |Costo operativo|Horas de soporte dedicadas a problemas de integración|Mensual| Es aconsejable seleccionar solo tres o cuatro métricas para la primera versión, y medirlas también antes del lanzamiento para tener una línea de base (Baseline) real para comparar, no una estimación de memoria. ## Lista de verificación antes de la puesta en producción - ☐ Para cada entidad se define un origen de la verdad y una regla para la resolución de conflictos. - ☐ Se ha seleccionado un patrón de sincronización (Request-Reply, Batch o Event-Driven) para cada proceso por separado. - ☐ Se ha decidido si se requiere Middleware o si una conexión directa es suficiente. - ☐ Existe una Clave de Idempotencia para cada operación que crea un registro financiero. - ☐ Se ha configurado un mecanismo de reintento (Retry) con retroceso exponencial y una Dead Letter Queue para los mensajes fallidos. - ☐ Se ha verificado el consumo de la cuota diaria de API frente al volumen esperado. - ☐ El permiso del usuario técnico está limitado solo a los objetos y campos necesarios. - ☐ Se ha realizado una prueba de fallo parcial, no solo del "Happy Path". - ☐ Existe un Dashboard para monitoreo empresarial, no solo técnico. - ☐ Se ha definido un proceso de reconciliación periódico y un responsable. ## Notas profundas para la implementación y el mantenimiento ### Nota del arquitecto: Cuándo cambiar un patrón existente Si un patrón Batch nocturno fue elegido inicialmente por simplicidad, pero el negocio comienza a demandar una actualización de inventario casi inmediata, no es necesario "reventar" toda la arquitectura. Se puede aumentar la frecuencia a cada 15 minutos como una etapa intermedia, y transicionar a Event-Driven solo cuando se demuestre que eso tampoco es suficiente. Un cambio gradual, acompañado de la medición de la latencia real, es preferible a una decisión generalizada y prematura. Desde un punto de vista gerencial, la verdadera prueba de la conexión entre Salesforce y un ERP no es solo que "funcione hoy", sino que se pueda explicar en cinco minutos por qué se eligió cada patrón y quién es responsable de arreglarlo cuando algo falla. Una solución que requiere una investigación prolongada en cada fallo genera un costo operativo oculto que aumenta con el tiempo. Cuando la capacidad interna para planificar o implementar una conexión de este tipo es limitada, el [servicio de arquitectura de CRM](/es/crm-architecture) es el camino práctico a seguir. ## Fuentes profesionales - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Arquitectura de CRM — https://hpi.pro/crm-architecture - HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Qué hacer cuando el ERP y Salesforce discrepan sobre el estado del mismo cliente?** Primero, debe determinarse qué sistema es la fuente de la verdad para esa entidad. Generalmente, el ERP lo será para facturación e inventario, mientras que Salesforce lo será para las relaciones con los clientes. Luego, se establece una regla diaria de reconciliación que resalte las diferencias, sin asumir que un 'sync' verde significa que los datos coinciden efectivamente. **¿Cuándo es suficiente una conexión Point-to-Point y cuándo es indispensable un Middleware?** Hasta dos o tres conexiones estables, un enfoque Point-to-Point puede ser suficiente. Sin embargo, a partir de tres o más sistemas, la existencia de una lógica de transformación común o la necesidad de reintentos y monitoreo centralizado, una capa de Middleware como MuleSoft ahorrará la duplicidad de la misma lógica en cada extremo. **¿Cómo se mantiene la Idempotencia cuando se envía un mensaje dos veces?** Cada mensaje recibe un identificador único (Idempotency Key). En el lado del receptor, se verifica si el identificador ya ha sido procesado antes de crear un nuevo registro. En la práctica, esto se guarda en un campo externo dedicado en el registro o en una tabla de registro separada, para que una ejecución duplicada no genere un pedido duplicado. **¿Qué sucede cuando se alcanza el límite diario de llamadas a la API de Salesforce?** Es necesario pasar de llamadas sincrónicas frecuentes a operaciones por lotes (Bulk API) o reducir la frecuencia del Polling. Una organización con decenas de miles de actualizaciones de pedidos al día casi siempre encontrará este límite si utiliza la API REST normal en lugar de Bulk API 2.0. **¿Cómo se prueba una conexión a un ERP antes de que entre en producción?** Se construye un entorno Staging con una copia representativa de los datos, se ejecuta un escenario completo que incluya fallos parciales (ERP no disponible, mensaje corrupto, duplicidad) y se mide el tiempo de recuperación de la consistencia. La aprobación empresarial solo se concede después de que se haya demostrado el escenario de fallo, y no solo el 'Happy Path'. --- ## Migración de datos a Salesforce: La guía completa para Planificación, Limpieza y Cutover URL: https://hpi.pro/es/insights/salesforce-data-migration-guide La mayoría de los fallos de migración no son por la herramienta, sino por un orden de carga incorrecto, un mapeo de campos apresurado y la ausencia de conciliación. Esta guía establece un proceso completo: perfilado, limpieza, IDs externos, Dry Run y correcciones post-Go Live. ## La respuesta breve La migración de datos a Salesforce suele fallar no por la herramienta, sino por un flujo de trabajo deficiente: comenzar la carga antes de entender la calidad de los datos de origen, mapear campos en un Excel sin verificar valores anómalos, y realizar la carga sin respetar las dependencias entre objetos. Un proceso adecuado se construye como un ciclo iterativo: perfilado, mapeo, limpieza, carga controlada, prueba y conciliación (Reconciliation), y solo entonces el “Cutover”. El objetivo de este artículo es desglosar este ciclo de vida en etapas claras, con una tabla de orden de carga y una lista de verificación de conciliación que pueden utilizarse en la práctica. En la mayoría de los proyectos, la diferencia entre una migración fluida y una que implica retrabajo se define en la primera semana, en la etapa de perfilado del origen. El trabajo de limpieza previo ahorra problemas posteriores; le recomendamos leer más al respecto en [Limpieza de duplicados en Salesforce](/es/insights/salesforce-data-deduplication). ## Perfilado del origen: Conocer los datos antes de tocarlos Antes de escribir un solo mapeo de campo, es fundamental realizar un perfilado de los datos de origen: ¿cuántos registros hay en cada tabla?, ¿qué campos están realmente vacíos (no solo en el Schema, sino en los propios datos)?, ¿cuál es el rango de valores en campos numéricos y de fecha?, y ¿dónde hay valores de texto libre que deberían ser una lista cerrada? En un proyecto que asesoramos, el campo "Estado del cliente" contenía 47 expresiones diferentes en el origen – "Activo", "Active", "Activo " con un espacio, "A" – todas las cuales debían mapearse a un único valor en Salesforce. Herramientas como OpenRefine, consultas SQL sencillas o incluso una tabla dinámica en Excel sobre una muestra de los datos suelen ser suficientes para la mayoría de los proyectos. El objetivo es generar un documento de perfilado que muestre: el número total de registros, el porcentaje de campos obligatorios vacíos, el número de valores únicos para cada campo categórico, y una identificación preliminar de posibles duplicados por nombre, teléfono o correo electrónico. En esta etapa también se identifica si hay varias fuentes para información superpuesta –por ejemplo, el mismo cliente existe tanto en un CRM antiguo como en un sistema de contabilidad– y se decide qué fuente es la "Fuente de Verdad" (Source of Truth) para cada campo. Una decisión como esta debe estar documentada, no asumida, ya que afecta a todas las etapas siguientes. ## Mapeo de campos: Más allá de una hoja de Excel Un buen mapeo de campos no es solo "columna A en el origen = campo B en el destino". También incluye la dirección de la transformación: formato de fecha, conversión de unidades, división de un campo de dirección en calle/ciudad/código postal, y una solución para valores que no existen en la lista cerrada del destino. El mejor documento de mapeo que hemos visto incluía cinco columnas: campo de origen, campo de destino, tipo de transformación, regla para manejar valores nulos, y un ejemplo de entrada/salida. Es necesario abordar por separado los campos de tipo Lookup (búsqueda) y Master-Detail (maestro-detalle): estos no contienen un valor directo, sino una referencia a otro registro, por lo que su mapeo depende de que el registro vinculado ya haya sido cargado y posea un identificador al que se pueda apuntar. Esta es la razón por la que el orden de carga (ver más adelante) y el mapeo de campos son dos caras de la misma decisión. Puede encontrar información ampliada sobre la gestión de la calidad de los campos a lo largo del tiempo, no solo en una etapa puntual, en [Calidad de datos en Salesforce](/es/insights/salesforce-data-quality-metrics). ## Limpieza y duplicidades: Antes de la carga, no después La limpieza que se realiza después de que la información ya está en un entorno de producción es exponencialmente más costosa: implica la actualización de registros en vivo, el riesgo de romper automatizaciones y procesos de aprobación, y a veces حتى (incluso) afectar informes que ya han sido distribuidos a la dirección. Por lo tanto, la fase de limpieza debe ocurrir en la capa intermedia (Staging), antes de que los datos ingresen a Salesforce. Reglas de limpieza clave que deben definirse de antemano: - Normalización de teléfono y correo electrónico (eliminación de espacios, uniformidad del formato internacional). - Identificación de duplicados por combinación de campos (nombre + teléfono, o solo número de identificación fiscal para empresas). - Reglas para la selección del registro "Master" al fusionar duplicados – por ejemplo, el registro más actualizado o el más completo. - Manejo de valores nulos versus cadenas vacías, para evitar la creación de "duplicados simulados". En un proyecto típico con aproximadamente 80,000 registros de clientes, una limpieza razonable identificará entre el 3% y el 8% de duplicados reales. Un número significativamente mayor sugiere que el origen mismo no fue mantenido, y justifica una conversación con los dueños del proceso de negocio antes de continuar. ## IDs externos y orden de carga Un External ID es un campo único del sistema original que también se mantiene en Salesforce, y permite la recarga (Upsert) sin crear duplicados cada vez que se ejecuta un archivo nuevamente. Sin un External ID, cada ejecución repetida de Data Loader puede crear una copia adicional del mismo registro, ya que el sistema no sabe cómo "identificar" un registro existente. El orden de carga se determina por las dependencias entre objetos: no se puede cargar un contacto antes de que exista la cuenta a la que está asociado, y no se puede cargar un artículo de pedido antes del propio pedido. | Etapa | Objeto | Dependencia | Nota de External ID | | --- | --- | --- | --- | | 1 | Account | Sin dependencia | Identificador de cliente del sistema de origen (ERP/CRM antiguo) | | 2 | Contact | Depende de Account | Identificador de contacto + Lookup a Account External ID | | 3 | Opportunity | Depende de Account, Contact | Identificador de oportunidad del sistema de origen | | 4 | Product / PriceBook Entry | Sin dependencia (carga paralela a etapa 1-2) | SKU (número de artículo) como External ID | | 5 | Opportunity Line Item | Depende de Opportunity, Product | Combinación de identificador de oportunidad + línea | | 6 | Case / Activity History | Depende de Account, Contact | Identificador de caso del sistema de origen | Desviarse de este orden es uno de los fallos más comunes en proyectos de migración: un equipo que intenta "ahorrar tiempo" y carga todos los archivos en paralelo descubre miles de errores de Lookup difíciles de cribar posteriormente, porque no está claro si el error se debe a datos faltantes o a un orden de carga incorrecto. ## Entornos y pruebas La migración no se carga directamente a producción. Una estructura de entornos recomendada incluye un Sandbox dedicado a la migración (separado del Sandbox de desarrollo habitual), donde se carga el mismo volumen de datos y la misma configuración de Validation Rules y Triggers que en producción, para exponer problemas antes de que afecten a usuarios reales. Las pruebas en esta etapa incluyen pruebas de volumen (si la carga se completa en un tiempo razonable), pruebas de errores (qué porcentaje de registros se rechaza y por qué), y pruebas de comportamiento de automatizaciones – un Flow o Trigger que se ejecuta al crear un registro podría activar el envío de un correo electrónico real a un cliente si no se desactiva temporalmente en el entorno de prueba. Olvidar este detalle causó en un proyecto el envío de miles de correos electrónicos de "bienvenida" duplicados a clientes existentes. ## Dry Run: Ejecución de prueba completa El Dry Run es una ejecución completa del proceso de carga en condiciones lo más cercanas posible a la producción – el mismo volumen, los mismos archivos, el mismo orden – pero en un Sandbox. El objetivo es medir dos cosas: el tiempo de ejecución real (para planificar la ventana de "Cutover" de manera realista) y el porcentaje de errores en cada etapa. Se recomienda realizar al menos dos ejecuciones completas de Dry Run: la primera expone la mayoría de los problemas, la segunda verifica que las correcciones los hayan resuelto y no hayan creado un nuevo problema. Si una segunda ejecución aún arroja más del 1%-2% de errores en objetos críticos, a menudo es preferible posponer la fecha del Cutover en lugar de comprometer la calidad. ## Cutover y conciliación de datos (Reconciliation) El Cutover es la ventana real en la que el sistema antiguo se “congela” (Freeze), se carga la información más actualizada en Salesforce y los usuarios comienzan a trabajar en el nuevo sistema. El éxito en esta fase se mide no solo por "si la carga finalizó", sino por la conciliación (Reconciliation), una comparación sistemática entre el origen y el destino. Lista de verificación para la conciliación que conviene ejecutar al finalizar cada Cutover: - ☐ El recuento de registros es idéntico (o la discrepancia es conocida y explicada) en cada objeto principal. - ☐ Los totales de campos financieros (por ejemplo, el valor total de oportunidades abiertas) coinciden entre las fuentes. - ☐ Se ha revisado manualmente, campo por campo, una muestra aleatoria de 30-50 registros. - ☐ Se han verificado las relaciones: ¿cada Contact tiene una Account válida?, ¿cada Opportunity Line Item tiene una oportunidad? - ☐ Se han revisado los registros "huérfanos": aquellos cargados sin una referencia válida. - ☐ Se ha comparado el recuento de duplicados antes y después con el objetivo establecido en la fase de limpieza. - ☐ El propietario del proceso de negocio ha confirmado que una muestra de su información es correcta. Las discrepancias comunes en la conciliación incluyen: recuentos de registros coincidentes pero valores totales incorrectos porque un campo numérico se cargó en un formato erróneo; o relaciones faltantes porque los Lookups se cargaron por valor de texto y no por External ID. La documentación completa del proceso de conciliación, incluyendo un ejemplo de "baseline" (línea de base), se encuentra también en [Salesforce Master Data Management](/es/insights/salesforce-master-data-management). ## Correcciones después de Go Live Incluso un Cutover exitoso deja una "cola" de correcciones: registros individuales que fueron rechazados en la carga, usuarios que reportan datos faltantes y discrepancias que se descubren solo cuando los usuarios reales trabajan con el sistema y no solo lo prueban. Se debe asignar de antemano un período de dos a cuatro semanas para correcciones focalizadas, con un informe de excepciones diario en la primera semana y semanal a partir de entonces. Es importante distinguir entre una corrección puntual (un registro individual que se actualizó manualmente) y una corrección sistémica (un error de mapeo que se repite en miles de registros y requiere una corrección en la propia herramienta de carga y una nueva ejecución). Mezclar ambos hace que los equipos corrijan manualmente un problema que en realidad es sistemático, perdiendo mucho tiempo. ## Escenario organizacional de ejemplo Una empresa de distribución con aproximadamente 120,000 clientes en un CRM antiguo y otra lista de clientes separada en el sistema de contabilidad, solicitó migrar ambas fuentes a un único Salesforce. Un perfilado inicial reveló que el 11% de los clientes aparecían en ambas fuentes con detalles de contacto diferentes, y el campo "Sector de actividad" contenía 340 valores de texto libre que debían ser unas 25 categorías. El equipo construyó un mapeo de campos detallado, estableció una regla de fusión basada en la combinación de NIF y teléfono, y definió el sistema de contabilidad como "Fuente de Verdad" (Source of Truth) para los detalles de facturación y el CRM antiguo como "Fuente de Verdad" para los detalles de contacto. Una primera ejecución de Dry Run reveló que el 4% de los registros eran rechazados debido a un formato de fecha incorrecto – una corrección que se tuvo en cuenta en la segunda ejecución. El Cutover se realizó durante un fin de semana, con una conciliación completa el lunes por la mañana antes de abrir el sistema a los usuarios. El resultado: menos del 0.3% de los registros requirieron corrección manual después del Go Live, en comparación con una estimación inicial del equipo que esperaba alrededor del 5% de excepciones. La diferencia se debió casi en su totalidad a las dos ejecuciones de Dry Run realizadas antes de la fecha oficial. ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Identidades no unificadas | El mismo cliente activa procesos duplicados | Regla de unificación por External ID y Golden Record | | Carga sin External ID | La recarga crea nuevos duplicados | Definir External ID antes de la primera ejecución | | Orden de carga incorrecto | Errores masivos de búsqueda (Lookup) difíciles de filtrar | Carga según tabla de dependencias predefinida | | Omisión de Dry Run | La ventana de Cutover se alarga y surgen sorpresas en tiempo real | Al menos dos ejecuciones completas en entorno de prueba | | Sin conciliación | Recuento de registros correcto pero importes y relaciones erróneos | Pruebas de recuento, suma, relación y muestreo en cada Cutover | A nivel de gestión de una migración de datos a Salesforce, esta tabla de riesgos es solo un punto de partida. Una ampliación sobre la gestión continua de la calidad, incluida la diferencia entre la limpieza puntual y el gobierno de datos continuo, se encuentra en [Data 360 Zero Copy](/es/insights/data-360-zero-copy-federation). ## Cómo se mide el éxito | Área | Qué se mide | Frecuencia de verificación | | --- | --- | --- | | Integridad (Completeness) | Tasa de campos obligatorios e información crítica completa | Antes y después de cada carga | | Unicidad (Uniqueness) | Tasa de duplicados por entidad | Antes de Dry Run y después de Cutover | | Validez (Validity) | Valores que cumplen reglas de formato y negocio | En cada lote de carga | | Conciliación (Reconciliation) | Coherencia de recuentos, sumas y relaciones con el origen | En cada simulacro y en el Cutover | | Tiempo de ejecución | Duración real de la carga versus la ventana de Cutover planificada | En cada ejecución de Dry Run | Para la mayoría de los proyectos, entre tres y cinco métricas son suficientes para la primera versión. Una buena métrica se puede calcular antes y después del cambio, se relaciona con el propietario de un proceso de negocio y no puede mejorarse artificialmente mediante la entrada parcial de datos. Cuando no existe una línea de base documentada del sistema antiguo, es recomendable invertir uno o dos días en medir el estado actual antes de informar sobre una mejora. ## Checklist antes de Go Live - ☐ El perfilado de origen se ha realizado e incluye porcentajes de campos vacíos y duplicados. - ☐ El documento de mapeo de campos está completo, incluyendo transformaciones y manejo de valores nulos. - ☐ External ID está definido para cada objeto que requiere recarga. - ☐ El orden de carga está documentado y acordado por el equipo técnico. - ☐ Se han realizado dos Dry Runs y los errores se han reducido por debajo del umbral establecido. - ☐ Un escenario de "Rollback" está escrito para el caso de que el Cutover falle. - ☐ El "Checklist" de conciliación está preparado y la persona responsable de ejecutarlo se conoce de antemano. - ☐ Se ha asignado una ventana para correcciones después del Go Live en el cronograma. - ☐ Las automatizaciones que podrían enviar comunicaciones a los clientes se han revisado y están desactivadas durante la carga. - ☐ El propietario del proceso de negocio ha aprobado una muestra final de datos. ## Notas profundas de implementación y mantenimiento ### Nota del arquitecto: La migración no es un evento único Incluso después de un Go Live exitoso, los cambios en el sistema de origen (si sigue funcionando temporalmente en paralelo) o las correcciones manuales crean desviaciones en los datos. Por ello, es importante mantener un informe de conciliación regular – semanal en el primer mes, mensual después – que compare una muestra de datos entre los informes antiguos y nuevos e identifique desviaciones tempranamente. Un proyecto que trata la migración como una línea de meta pasa por alto que la calidad de los datos es un proceso continuo. Desde una perspectiva gerencial, la verdadera prueba de una migración de datos a Salesforce no es solo si los registros se cargaron, sino si los gerentes de Datos, CRM y proyectos pueden confiar en los informes al día siguiente sin verificar manualmente cada número. Las organizaciones que desean acompañamiento profesional para un proceso así pueden recurrir a [Servicios de Integraciones y Datos](/es/integrations-data), que acompaña tanto la fase de planificación como la ventana de Cutover. ## Fuentes profesionales - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Cuánto tiempo antes del Cutover se debe realizar el primer Dry Run?** Se recomienda ejecutar un Dry Run completo al menos de tres a cuatro semanas antes de la fecha de Go Live, y una segunda ejecución una o dos semanas antes. Esto permite tiempo para corregir anomalías, medir la duración real de la carga y verificar que la ventana asignada para el Cutover sea suficiente, incluso con un margen de seguridad. **¿Qué hacer si se detecta duplicidad de clientes después de que el sistema ya está en uso?** Se ejecuta una regla de unificación basada en un identificador comercial (por ejemplo, identificación fiscal o correo electrónico normalizado), se selecciona un registro Maestro según la actualidad e integridad de los datos, y se fusionan mediante una herramienta de Merge o un proceso controlado que actualiza las relaciones antes de eliminar el duplicado. Esta acción requiere una copia de seguridad completa antes de la ejecución. **¿Es posible omitir los External IDs y confiar únicamente en los nombres para hacer coincidir registros?** No es recomendable. Los nombres se repiten, varían entre sistemas y pueden contener espacios o caracteres diferentes. Un External ID único del sistema de origen garantiza un mapeo unívoco, permite la carga repetida (Upsert) sin duplicidades y acorta significativamente el tiempo de resolución de problemas. **¿Cuál es el orden de carga correcto cuando hay un archivo con todos los tipos de registros mezclados?** Es necesario dividir el archivo por objeto y cargar primero las entidades sin dependencia (Cuentas), luego las entidades dependientes (Contactos, Oportunidades), y finalmente las relaciones y los ítems de detalle. Una carga mixta sin orden genera errores de Lookup y registros huérfanos que son difíciles de rastrear a posteriori. **¿Cuánto tiempo se debe asignar para correcciones después del Go Live antes de cerrar el proyecto?** En un proyecto de migración de tamaño medio, se recomienda asignar de dos a cuatro semanas de monitoreo cercano, durante las cuales se revisan informes diarios de anomalías, brechas de conciliación y quejas de usuarios. Solo después de dos ciclos de informes limpios (dos semanas) se puede declarar el cierre de la fase de correcciones. --- ## Agentforce para empresas: cuándo es realmente adecuado y cuándo aún no URL: https://hpi.pro/es/insights/agentforce-for-enterprises No todos los procesos son aptos para un agente de IA autónomo. Esta guía construye un marco de decisión operativo —madurez de datos, contextualización (Grounding), permisos y Human-in-the-loop— que diferencia entre casos de uso maduros para Agentforce y aquellos que es mejor dejar a la automatización clásica. ## La respuesta breve Para las organizaciones, la implementación de Agentforce no es una cuestión de si Salesforce lo soporta, sino de madurez: si existe una fuente de información fiable, si está claro quién aprueba una acción sensible y qué línea base distinguirá el éxito del fracaso. Una organización que omite estas preguntas y se lanza directamente a construir un agente, descubre la brecha en el segundo mes, cuando el costo aumenta y los resultados no son consistentes. El enfoque correcto comienza con la filtración de procesos, continúa con la verificación de la preparación de los datos y los permisos, y termina con un piloto medido con un criterio claro para continuar o detenerse. Quienes todavía estén construyendo una base pueden comenzar con [Preparación para Agentforce](/es/insights/agentforce-salesforce-ai-guide), donde se explica la diferencia entre Copilot, Flow y el propio Agentforce. ## Seis áreas de preparación Antes de elegir el primer caso de uso, vale la pena mapear la organización en seis áreas. Cualquier área que permanezca en el nivel de “no se sabe” es un riesgo que se descubrirá durante el piloto y no antes. | Área de preparación | Pregunta clave | Señal de advertencia común | | --- | --- | --- | | Madurez de datos y conocimiento | ¿Existe una única fuente de información, actualizada y aprobada? | Base de Conocimiento antigua, contradicciones entre documentos | | Grounding | ¿El agente recupera información real o adivina? | Respuestas convincentes pero incorrectas en los hechos | | Temas (Topics) y Acciones (Actions) | ¿Cada Tema está definido dentro de límites estrictos? | Un solo agente que debe "responder a todo" | | Permisos y seguridad | ¿El agente opera según los permisos del usuario real? | Un permiso de sistema que devuelve información a cualquiera | | Intervención humana (Human-in-the-loop) | ¿Quién aprueba una acción irreversible? | Una acción financiera o legal sin control | | Medición y costo | ¿Existe una línea base para comparar? | "Parece impresionante" sin un número que lo respalde | ### Madurez de datos y conocimiento Un buen agente de IA es tan bueno como la información de la que se alimenta. En una organización de servicio con tres sistemas de Knowledge que no se han sincronizado entre sí, el agente aprenderá de la primera fuente que encuentre, incluso si es la menos precisa. Antes de cualquier trabajo técnico, es recomendable verificar: cuándo se actualizó cada documento por última vez, quién es el responsable del mismo y qué sucede cuando hay dos documentos contradictorios. Las organizaciones que omiten esta etapa llegan al piloto con un agente que genera respuestas seguras pero incorrectas, lo cual es peor que "no sé". ### Grounding Grounding es el mecanismo de búsqueda que alimenta al agente con información real antes de formular una respuesta, en lugar de depender del conocimiento general del modelo. La profundidad del tema, incluyendo consideraciones de Chunking, Vector Search y la separación entre fuentes internas y externas, se detalla en [Agentforce Grounding](/es/insights/agentforce-grounding-rag). A nivel de decisión gerencial, basta con saber que, sin un Grounding sólido, cualquier otra inversión —diseño de conversación, Acciones, interfaz— se construye sobre una base inestable. ### Temas (Topics) y Acciones (Actions) El error más común es construir un solo agente con un Topic amplio como "servicio al cliente" en lugar de varios Topics estrechos como, por ejemplo, "consulta de estado de pedido" o "actualización de datos de facturación". Un Topic estrecho es más fácil de probar, más fácil de explicar al usuario por qué el agente no respondió, y más fácil de añadir Actions gradualmente. Una Action en sí misma debe operar bajo permisos limitados, pasar la validación de entrada y devolver un error claro cuando algo no coincide, no intentar adivinar una continuación. ### Permisos y seguridad Un agente que opera bajo un permiso de integración generalizado puede exponer información que el usuario que interactúa con él no debería ver, como el salario de otro empleado, un pedido de otro cliente o una nota interna sensible. La recomendación profesional es ejecutar el agente bajo el contexto de permisos del usuario real (Run As User) siempre que sea posible, y documentar cualquier excepción a este modelo como una decisión consciente con un responsable. ### Intervención humana (Human-in-the-loop) No todas las acciones requieren aprobación humana, pero toda acción irreversible sí. El envío de un reembolso, la cancelación de un pedido, el cambio de un permiso de acceso: estos son los puntos donde es preferible que el agente prepare la acción y se detenga antes de ejecutarla, al menos durante los primeros meses. Con el tiempo, cuando las métricas demuestren una alta precisión en un subconjunto específico, se puede eliminar la aprobación de forma gradual y no de una vez. ### Medición y costo El costo de Agentforce no solo incluye las licencias; abarca tokens, llamadas a la API y la infraestructura para el monitoreo. El tema económico completo, que incluye ejemplos de precios y escenarios de escala, se encuentra en [Precio de Agentforce](/es/insights/agentforce-cost-tco). Sin una línea base de "cuánto tiempo le toma a un agente realizar la tarea hoy", es imposible saber si el agente ahorra dinero o simplemente añade una capa de complejidad. ## Tabla de idoneidad: Apto o No Apto Una tabla como esta no sustituye un análisis en profundidad, pero es una herramienta de filtrado rápida antes de invertir semanas en probar un caso de uso que, de todos modos, no prosperará. | Caso de Uso | Idoneidad | Razón | | --- | --- | --- | | Responder preguntas frecuentes de un Knowledge actualizado | Alta idoneidad | Información estructurada, bajo riesgo, mejora medible en el tiempo de respuesta | | Consultar el estado del pedido y actualizar los datos de envío | Alta idoneidad | Dato cerrado en el sistema, acción sencilla, fácil de verificar | | Análisis de la tendencia de ventas multianual compleja | Idoneidad parcial | Requiere un contexto empresarial profundo; solo apto para una etapa avanzada | | Aprobación de crédito o cambio de condiciones de contrato | No apto en la etapa inicial | Alto impacto financiero, se requiere aprobación humana constante | | Asesoramiento médico, legal o regulatorio al cliente final | No apto | Riesgo de litigio y responsabilidad; requiere control humano completo | | Redacción de borradores de contenido de marketing para revisión humana | Alta idoneidad | El resultado no es definitivo, siempre hay una persona que revisa antes de publicar | ## Plan de piloto realista ### Fase 1: Selección de un único caso de uso (semana 1) Se elige un proceso de la tabla marcado como de alta idoneidad, se define la línea base (tiempo medio de manejo, tasa de escalada actual) y se anota qué se considera éxito. Un patrocinador empresarial firma el alcance. ### Fase 2: Construcción de Grounding y primer Topic (semanas 2-3) Se conecta una única fuente de información verificada, se construye un Topic estrecho con un máximo de 2-3 Acciones, y se definen los permisos según el usuario. Cada Acción pasa por una prueba de entrada no válida antes de ser considerada lista. ### Fase 3: Ejecución interna controlada (semanas 4-5) Un grupo reducido de usuarios (5-15 personas) prueba el agente en escenarios reales, incluyendo la aprobación humana para cada acción significativa. Se recopilan rastros (traces) y errores según su gravedad. ### Fase 4: Medición contra la línea base (semanas 6-8) Se comparan el tiempo de resolución, la tasa de éxito y el costo con la primera fase. Aquí entran los criterios de Go/No-Go: - **Go**: Tasa de finalización de tarea sin escalada superior al 70%, costo por tarea inferior a la alternativa humana, cero incidentes de seguridad o permiso. - **Expansión gradual**: Tasa de finalización del 50-70%: se continúa, pero se reduce el alcance a una subtarea que tuvo más éxito. - **No-Go**: Tasa de finalización inferior al 50%, o un incidente de permiso: se vuelve a la fase de datos y permisos antes de cualquier expansión. Pruebas más exhaustivas, incluyendo la metodología de "Scorers" automáticos, se describen en [Pruebas de Agentforce](/es/insights/agentforce-testing-scorers). ## Escenario organizacional de ejemplo Una empresa de servicios con un centro de llamadas de 40 agentes deseaba implementar Agentforce para reducir la carga de trabajo. La gerencia pidió "un agente que responda a todo". Durante la revisión de preparación, se encontró que existían tres bases de conocimiento no sincronizadas y que la mayoría de las solicitudes requerían acceso a datos de facturación sensibles. En lugar de comenzar de manera amplia, el equipo eligió un único caso de uso: consulta del estado de un pedido, que no requiere datos financieros sensibles. En seis semanas, el agente gestionó el 62% de las consultas de este tipo sin escaladas, con un costo significativamente menor que un minuto de conversación con un agente humano. De acuerdo con el criterio de "Go", la empresa se expandió gradualmente a un segundo "Topic" —actualización de la dirección de envío— y solo después comenzó a considerar acciones financieras, con aprobación humana permanente. El enfoque gradual evitó un fracaso generalizado que habría ocurrido si la organización hubiera optado directamente por el "agente que lo sabe todo". ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Caso de uso demasiado amplio | Imposibilidad de medir el éxito o predecir el comportamiento | Empezar con un proceso estrecho con límites claros | | Grounding débil | Respuestas seguras pero erróneas en los hechos | Una única fuente de información, responsable y proceso de actualización regular | | Permisos demasiado amplios | El agente expone información que el usuario no debería ver | Ejecución bajo el contexto del usuario, no con permisos de sistema | | Omisión de la aprobación humana | Acción financiera o legal realizada sin control | Aprobación humana obligatoria para toda acción irreversible | | Ausencia de línea base | "Parece que funciona" sin pruebas numéricas | Medición del estado actual antes del lanzamiento, no después | ## ¿Cómo saber cuándo es el momento de expandir? La expansión está justificada cuando se cumplen simultáneamente tres condiciones: la métrica principal es estable durante tres ciclos de medición consecutivos, no hay incidentes de permisos o seguridad en el período medido, y el propietario del proceso está dispuesto a firmar que el resultado es equivalente o mejor que la alternativa humana. Cuando una de las condiciones falta, es preferible prolongar la fase piloto dos semanas adicionales antes que expandir basándose en una buena sensación. ## Lista de verificación antes de tomar una decisión - ☐ Se ha seleccionado un único caso de uso con límites claros, no un "agente general". - ☐ Existe una fuente de información verificada y actualizada para el área seleccionada. - ☐ Los permisos del agente coinciden con los permisos del usuario real. - ☐ Se han definido puntos de intervención humana para acciones irreversibles. - ☐ Se ha medido la línea base (baseline) antes del lanzamiento, no solo después. - ☐ Se han establecido criterios de Go/No-Go por escrito de antemano. - ☐ Existe un plan de monitoreo de rastreo (traces) y errores. - ☐ Se ha designado un responsable para el mantenimiento de la fuente de información. ## Resumen: cuándo es aconsejable y cuándo no Agentforce es adecuado cuando existe un proceso delimitado con una fuente de información fiable, cuando el impacto de un error es relativamente bajo y cuando hay una forma de medir el éxito frente a una línea base real. Es menos adecuado –al menos en una fase inicial– para procesos con un alto impacto financiero o legal, para organizaciones donde la información aún está dispersa y no se gestiona adecuadamente, o cuando la dirección espera resultados inmediatos sin una fase piloto. Las organizaciones que respetan este orden de operaciones –primero la preparación, luego un piloto medido y solo después la expansión– logran un resultado mucho más estable que aquellas que se lanzan directamente al desarrollo. La implementación real se puede ejecutar junto con [Servicio de Agentforce y IA](/es/agentforce-ai), que acompaña a la organización desde la etapa de verificación de idoneidad hasta una expansión controlada. ## Fuentes profesionales - Salesforce – Cómo funciona Agentforce — https://www.salesforce.com/agentforce/how-it-works/ - Salesforce – Barreras de seguridad de Agentforce — https://help.salesforce.com/s/articleView?id=ai.agent_plan_risks_guardrails.htm&language=en_US&type=5 - Salesforce – Evaluación Agente Personalizado de Pruebas — https://developer.salesforce.com/docs/ai/agentforce/guide/testing-api-custom-scorers.html - HPI Pro – Agentforce y IA — https://hpi.pro/agentforce-ai ### Preguntas y respuestas **¿Cuál es la diferencia entre un caso de uso adecuado para Agentforce y uno que es mejor construir como un Flow normal?** Un caso de uso adecuado para un agente requiere criterio en tiempo de ejecución: elegir entre varias rutas basándose en lenguaje natural o un contexto cambiante. Si el proceso siempre sigue la misma secuencia fija, un Flow o Apex son más económicos, completamente testeables y no requieren monitoreo de 'Traces'. **¿Cuántos datos documentados se necesitan antes de iniciar un piloto de Agentforce?** No se necesita una documentación perfecta, pero sí una fuente de verdad clara para al menos un ámbito: artículos de Knowledge actualizados, campos de CRM precisos o documentos de políticas aprobados. Si el 30% de las respuestas requieren aclaración humana porque la información es inconsistente o falta, el piloto fallará por los datos y no por el agente. **¿Puede Agentforce operar sin ninguna aprobación humana?** Sí, para operaciones de bajo riesgo como la extracción de información o la actualización de un campo no sensible. Para cualquier acción que afecte dinero, permisos, un cliente externo o datos irreversibles, se recomienda una fase de aprobación humana al menos durante los tres primeros meses posteriores al lanzamiento. **¿Cómo se mide el costo-beneficio de un agente en la práctica, no solo en teoría?** En un piloto de 6 a 8 semanas, se construye un panel (Dashboard) que muestra el costo de tokens e infraestructura frente al número de tareas completadas sin escalamiento. Si el costo de la tarea es mayor que el ahorro que genera —por ejemplo, una hora de trabajo de un representante—, el agente no está listo para escalar, incluso si 'funciona'. **¿Qué sucede si el piloto falla en los criterios Go/No-Go?** No se abandona el proyecto, sino que se reduce el alcance (Scope). Generalmente, el fallo se debe a una contextualización (Grounding) débil o a un caso de uso demasiado amplio, no a la tecnología en sí. Se descompone el proceso en una subtarea específica, se corrige la fuente de información y se vuelve a probar antes de invertir en una expansión adicional. --- ## 15 preguntas esenciales antes de elegir un integrador de Salesforce URL: https://hpi.pro/es/insights/questions-before-choosing-salesforce-integrator La mayoría de las propuestas de Salesforce parecen similares en el papel hasta que se analizan con estas 15 preguntas clave. Esta guía las desglosa en seis temas —desde el equipo hasta la continuidad— y muestra cómo diferenciar una respuesta débil de una confiable. ## La respuesta breve Las propuestas que presentan los diferentes integradores de Salesforce suelen parecer casi idénticas: utilizan los mismos términos, como Discovery, Agile, Best Practice, y prometen el mismo "acompañamiento cercano". La verdadera diferencia se revela solo cuando se examina cada propuesta con preguntas concretas que exponen la forma de pensar del proveedor, no solo lo que ofrece entregar. El objetivo de las siguientes 15 preguntas es identificar las brechas antes de firmar, y no después de que el proyecto ya esté estancado. Las preguntas se dividen en seis temas: equipo, metodología, arquitectura, datos, condiciones comerciales y continuidad. Cada pregunta incluye una breve explicación de por qué es importante y una descripción de cómo sonaría una respuesta débil, para que sea fácil identificarla en tiempo real, ya sea en una reunión o en un documento de propuesta. Las implicaciones prácticas de la elección en todo el proceso de implementación se detallaron por separado en [Empresa de implementación de Salesforce](/es/insights/choose-salesforce-implementation-company). ## Por qué 15 preguntas y no una lista de requisitos técnicos Una lista de requisitos técnicos —cuántos Sandbox, qué licencias, tiempos de SLA— es importante, pero no suficiente. Verifica lo que el proveedor dice que hará, no cómo abordará la situación si la planificación original resulta imprecisa. Las preguntas aquí se seleccionaron porque revelan patrones de trabajo: cómo el equipo documenta las decisiones, cómo maneja los datos sucios y qué sucede cuando algo no sale según lo planeado. ## Tabla resumen: respuesta fuerte vs. respuesta débil | Tema | Una respuesta fuerte suena así | Una respuesta débil suena así | | --- | --- | --- | | Equipo | "La consultora X lidera la arquitectura, el desarrollador Y ejecuta, enviaremos CV y permitiremos una breve entrevista" | "Tenemos un equipo experimentado, asignaremos al adecuado durante el Kickoff" | | Metodología | "Sprints de dos semanas, demo real al final de cada sprint, backlog compartido en Jira" | "Trabajamos con metodología Agile, es flexible y se adapta a cualquier proyecto" | | Arquitectura | "Crearemos un ADR para cada decisión clave, incluyendo la alternativa descartada y la razón" | "Elegiremos la mejor solución según nuestra experiencia" | | Datos | "Ejecutaremos Data Profiling antes de la propuesta final, le informaremos sobre la calidad de las fuentes" | "Nos ocuparemos de la limpieza de datos durante el desarrollo" | | Comercial | "Precio fijo para un Scope definido, horas extra según Change Request documentado" | "T&M flexible para no limitarle" | | Continuidad | "Documento de traspaso, capacitación para Admin interno, dos semanas de Hypercare después del Go Live" | "Siempre estaremos aquí para usted, no hace falta un protocolo de despedida" | ## Equipo: quién trabajará realmente en el proyecto ### 1. Quién acompañará realmente el proyecto, no solo la propuesta Esta pregunta es crítica porque muchas propuestas presentan al miembro sénior del equipo en la reunión de ventas y lo reemplazan por un consultor júnior después de la firma. Una respuesta sólida incluye nombres, roles y el porcentaje de dedicación asignado. Una respuesta débil suena a "elegiremos al más adecuado según la disponibilidad", lo que significa que no hay una asignación real hasta el último momento. ### 2. Cuántos proyectos paralelos maneja cada consultor al mismo tiempo Un consultor que gestiona cinco proyectos simultáneamente no puede prestar atención a los detalles. Una respuesta sólida reconocerá esta limitación y presentará un número razonable (generalmente dos o tres proyectos). Una respuesta débil evade o contesta "depende de la carga de trabajo", sin un número concreto. ### 3. Qué sucede si el consultor principal se va a mitad del proyecto Una respuesta sólida describe un proceso de traspaso documentado, una superposición de dos semanas y una documentación continua que permite la sustitución sin pérdida de conocimiento. Una respuesta débil afirma que "esto casi nunca ocurre con nosotros" sin un plan de contingencia. Se puede encontrar más información sobre una estructura de trabajo adecuada con un [consultor de Salesforce](/es/insights/salesforce-consulting-guide). ## Metodología: cómo se desarrolla el trabajo en la práctica ### 4. Cómo es un sprint típico, qué sucede cuando algo no está listo a tiempo Una respuesta sólida describe la Planificación del Sprint, un Daily breve, Demo y Retrospectiva, y también qué sucede cuando una tarea se atasca: si se pospone al siguiente sprint de forma transparente. Una respuesta débil se limita a "trabajamos con metodología Agile" sin detallar un ritual concreto. ### 5. Cómo es la comunicación continua: canal, frecuencia y responsable Una respuesta sólida detalla el canal (Slack, Teams), una reunión de estado semanal fija y un único punto de contacto para escalaciones. Una respuesta débil responde "estaremos disponibles siempre por correo electrónico", lo que en la práctica significa que no hay un SLA para la respuesta. ### 6. Cómo se prueba el trabajo antes de presentarse al cliente como terminado Una respuesta sólida describe una revisión de QA interna, una Checklist de aceptación y una revisión de acceso y permisos antes de la Demo. Una respuesta débil admite indirectamente que la primera Demo para el cliente es también la primera prueba. ## Arquitectura: cómo se toman las decisiones ### 7. Cómo se documentan las decisiones arquitectónicas y quién las aprueba Una respuesta sólida presenta un formato breve para la decisión —problema, alternativas, elección y razón— que se guarda y es accesible para el cliente. Una respuesta débil dice "elegimos la solución correcta" sin documentar por qué se descartaron otras alternativas. ### 8. Cómo afrontará la solución la carga y el crecimiento en dos o tres años Una respuesta sólida aborda las limitaciones de Governor Limits, el volumen de datos esperado y la planificación de la expansión. Una respuesta débil responde "Salesforce es escalable por naturaleza" sin relacionarlo con el caso específico. ### 9. Qué sucede cuando un nuevo requisito entra en conflicto con una decisión anterior Una respuesta sólida describe un proceso de Change Request que evalúa el impacto en lo que ya se ha construido. Una respuesta débil simplemente promete "nos adaptaremos a cualquier cambio", lo que generalmente termina en una deuda técnica que se acumula silenciosamente. ## Datos: el punto donde la mayoría de los proyectos se estancan ### 10. Cómo se verifica la calidad de los datos antes de empezar a construir Una respuesta sólida incluye una etapa temprana de Profiling —duplicados, campos vacíos, formatos inconsistentes— y un cronograma para la corrección. Una respuesta débil lo pospone a "lo abordaremos durante la migración", lo que casi siempre prolonga el proyecto. ### 11. Cuál es la fuente de verdad para cada tipo de dato, y cómo se gestiona la duplicidad entre sistemas Una respuesta sólida identifica de antemano qué sistemas "prevalecen" en caso de conflicto (por ejemplo, ERP frente a Salesforce para un cliente existente) y documenta la regla. Una respuesta débil responde "Salesforce será la fuente de verdad" de manera general sin verificar si esto es cierto para cada objeto. ### 12. Cuál es el plan de respaldo y recuperación, y quién es responsable de él después de la implementación Una respuesta sólida detalla las herramientas de respaldo, la frecuencia y quién realiza la recuperación en la práctica cuando es necesario. Una respuesta débil asume que Salesforce "ya se encarga de eso" sin distinguir entre el respaldo de la plataforma y el respaldo a nivel de organización. ## Comercial y continuidad: qué sucede después de la firma ### 13. Cómo se estructura el precio: fijo, T&M o combinado, y qué incluye realmente Una respuesta sólida desglosa el precio en Workstreams con horas estimadas para cada uno, y define qué se considera un Change Request con costo adicional. Una respuesta débil proporciona una cifra global sin desglosarla, lo que dificulta la comparación entre propuestas. ### 14. Qué sucede si el proyecto se excede en tiempo: quién asume el costo Una respuesta sólida distingue entre un excedente causado por el proveedor (a su cargo) y un excedente causado por un cambio de requisitos del cliente (con costo). Una respuesta débil se formula de manera ambigua, permitiendo al proveedor trasladar cualquier retraso al cliente. ### 15. Qué sucede al finalizar el proyecto: qué soporte, por cuánto tiempo y a qué tarifa Una respuesta sólida incluye un período definido de Hypercare (generalmente de dos a cuatro semanas), un documento de traspaso y capacitación para el Admin interno. Una respuesta débil promete "soporte continuo" sin una tarifa, alcance o fecha de finalización claros. Se puede encontrar más información sobre la redacción adecuada de tales cláusulas contractuales en [SOW de proyectos de Salesforce](/es/insights/salesforce-sow-contract-clauses). ## Escenario organizacional de ejemplo Una empresa de servicios financieros recibió tres propuestas para fusionar dos sistemas CRM antiguos en un único Salesforce. Dos de las propuestas eran un 20%-25% más bajas en precio que la tercera. Cuando el CIO preguntó la pregunta 10 (prueba de calidad de datos temprana), los dos proveedores más económicos respondieron "lo abordaremos como parte de la migración", mientras que el proveedor más caro presentó un plan de Profiling de una semana antes de que se acordara el monto final. La organización eligió al proveedor más caro. La semana de Profiling reveló aproximadamente 12.000 registros duplicados y un campo de fecha con formato inconsistente en 3 de las fuentes de datos. Esta corrección temprana se incluyó en el precio original; con los otros dos proveedores, se habría descubierto durante la migración, como un cambio de Scope con costo adicional. La lección aquí no es que "lo barato siempre es malo", sino que la brecha entre una respuesta detallada y una respuesta general equivale a dinero real, y solo se puede descubrir con preguntas enfocadas antes de la firma, no después. ## Checklist para la comparación de propuestas - ☐ Hemos recibido los nombres y los porcentajes de dedicación del equipo propuesto, no solo una descripción general. - ☐ Hemos verificado cómo cada proveedor documenta las decisiones arquitectónicas. - ☐ Hemos solicitado un plan de Profiling de datos antes de firmar. - ☐ Hemos desglosado el precio en Workstreams con horas estimadas. - ☐ Hemos aclarado quién asume el costo de un excedente que no es culpa del cliente. - ☐ Hemos recibido una descripción explícita del período de Hypercare y sus condiciones. - ☐ Hemos consultado referencias de clientes con un alcance de proyecto similar. - ☐ Hemos confirmado que el consultor presentado en la reunión es quien trabajará realmente. - ☐ Hemos verificado cuántos proyectos paralelos maneja cada consultor principal. - ☐ Hemos definido de antemano qué evidencia demostrará el éxito al finalizar el proyecto. ## Nota final: las preguntas son una herramienta, no un ritual El propósito de las 15 preguntas no es avergonzar a un proveedor ni alargar innecesariamente el proceso de selección. Se trata de revelar de antemano dónde la propuesta se basa en una suposición no escrita. Un buen proveedor no se ofenderá por las preguntas, se complacerá en responderlas porque le reducen el riesgo a largo plazo. Un proveedor que las evade, o que responde con generalidades recurrentes, da con ello una respuesta por sí mismo. Cuando no se cuenta con la capacidad interna para llevar a cabo un proceso de comparación de este tipo, el [servicio de consultoría y definición de requisitos](/es/consulting-discovery) es el camino práctico a seguir, que incluye la elaboración de un Scorecard ponderado, el acompañamiento en las reuniones con los oferentes y la comparación de las respuestas con criterios objetivos. ## Fuentes profesionales - HPI Pro – Consultoría y definición de requisitos — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Servicios de Salesforce — https://hpi.pro/services ### Preguntas y respuestas **¿Cuánto tiempo suele llevar comparar varios integradores con este nivel de detalle?** Un proceso riguroso toma aproximadamente de tres a cuatro semanas: una semana para definir un alcance compartido, una o dos semanas para reuniones y respuestas escritas, y una semana para comparar y verificar referencias. Un proceso más corto tiende a basarse en la primera impresión y a pasar por alto diferencias en las suposiciones. **¿Qué hacer si un proveedor se niega a responder por escrito algunas preguntas?** Esto es una señal de advertencia significativa, no un tema técnico. Una respuesta verbal es fácil de olvidar o negar más adelante. Si un proveedor explica que la respuesta 'depende del proyecto', puede solicitar un rango o una suposición de trabajo explícita; una negativa absoluta justifica continuar la evaluación con otro proponente. **¿Es válido hacer estas preguntas también a un proveedor existente al renovar un contrato?** Sí, y a veces es aún más crucial. Un proveedor existente que ha acumulado conocimiento interno a menudo deja de documentar y autoevaluarse con el tiempo. Una revisión cada 12-18 meses revela desgaste en el equipo, la documentación o los tiempos de respuesta antes de que se convierta en una dependencia peligrosa. **¿Qué peso relativo se debe dar a cada uno de los seis temas en la decisión?** No hay una fórmula única, pero para un primer proyecto con múltiples fuentes de datos, es recomendable asignar al equipo y los datos combinados aproximadamente el 45% de la puntuación, a la metodología y arquitectura un 35%, y el resto a las condiciones comerciales y la continuidad. En una renovación de contrato existente, el peso se desplaza hacia la continuidad y las condiciones comerciales. **¿Qué es preferible: un proveedor que ofrece un precio bajo con respuestas generales, o uno más caro con respuestas detalladas?** La respuesta detallada es casi siempre más valiosa. Una diferencia del 15-20% en el precio es insignificante comparada con el costo de un retrabajo debido a una suposición incorrecta sobre datos o permisos. Un precio bajo con un alcance ambiguo a menudo significa el mismo trabajo más una sorpresa adicional más adelante. --- ## ¿Cómo rescatar un proyecto Salesforce estancado? Metodología de diagnóstico y rescate URL: https://hpi.pro/es/insights/rescue-stalled-salesforce-project Un proyecto Salesforce estancado a menudo parece un problema de desarrollo, pero en la mayoría de los casos es una mezcla de Alcance poco claro, decisiones de arquitectura no tomadas y confianza erosionada. Esta guía presenta un plan de diagnóstico de 10 días y un plan de rescate de 90 días. ## La respuesta corta La mayoría de los proyectos de Salesforce que se estancan no lo hacen por un código deficiente. Se estancan porque nadie se detuvo a tiempo para preguntar qué cambia realmente en el trabajo de los usuarios, quién es responsable de cada decisión y qué sucede cuando algo no sale según lo planeado. El resultado: sprint tras sprint que añade funcionalidades, sin que el panorama general mejore. Rescatar un proyecto de Salesforce estancado significa, ante todo, detener la “hemorragia” y solo después decidir qué hacer con lo ya construido. Este orden es crucial: muchas organizaciones pasan directamente a la fase de corrección sin diagnosticar primero por qué falló el proceso anterior, repitiendo el mismo error por segunda vez. Aquellos que deseen entender cómo priorizar la deuda acumulada pueden profundizar en [priorización de deuda técnica en Salesforce](/es/insights/salesforce-technical-debt-prioritization). ## Señales de estancamiento: cómo identificar que el proyecto ya no va por el camino correcto Hay una diferencia entre un proyecto que avanza lentamente y uno que ya no se mueve. Las siguientes señales se repiten en casi todos los rescates que hemos realizado: - **Las reuniones de estado se convierten en reuniones de justificación**: una reunión de estado semanal que se transforma en excusas sobre por qué algo aún no está listo, sin una nueva fecha límite fiable. - **El backlog crece más rápido que la tasa de cierre**: se añaden nuevos elementos cada semana, pero el número de elementos cerrados permanece constante o disminuye. - **Ninguna versión ha sido probada con un usuario real en el último mes**: solo demostraciones internas del equipo técnico, sin contacto con quienes realmente utilizarán el sistema. - **Cambios frecuentes de requisitos sin documentación**: cada conversación genera "otro pequeño cambio" que no se incorpora a un documento de alcance organizado. - **Falta de confianza evidente**: los usuarios ya están creando hojas de cálculo de Excel paralelas "por si acaso", y esa es una señal de que han dejado de creer que el sistema funcionará a tiempo. Cuando cuatro de estas cinco señales se presentan simultáneamente, se trata de un proyecto estancado y no de un proyecto lento, y esa diferencia cambia toda la estrategia de abordaje. ## Diagnóstico en 10 días: qué verificar y en qué orden Un buen diagnóstico no requiere dos meses. Diez días hábiles, con la asignación adecuada, son suficientes para obtener una imagen lo suficientemente fiable como para tomar una decisión. Una distribución recomendada: **Días 1-2: Entrevistas y mapeo inicial.** Conversaciones breves con el patrocinador, el propietario del proceso, dos o tres usuarios finales y el jefe del equipo de desarrollo. El objetivo es recopilar diferentes versiones de "qué salió mal", sin llegar aún a una conclusión. **Días 3-5: Revisión técnica directa.** Acceso al propio entorno (Org): estructura de datos, automatizaciones existentes, permisos, registros de errores y consultas lentas. Aquí se verifica si el problema es arquitectónico u operativo. **Días 6-7: Comparación entre lo prometido y lo construido.** Lectura de los documentos originales (SOW, User Stories, Design Docs si existen) frente al estado real en el Sandbox o Producción. **Días 8-10: Formulación de hallazgos y decisión inicial.** Un documento conciso que clasifica cada problema encontrado como alcance, arquitectura o confianza, y presenta una primera recomendación: Reinicio (Reset), Refactorización (Refactor) o Continuación a un ritmo rectificado. ## Tres capas del problema: Alcance, Arquitectura y Confianza El error más común es abordar cada estancamiento como si fuera un único problema. En realidad, casi siempre se trata de una combinación de tres capas diferentes, cada una de las cuales requiere un enfoque distinto. **El problema de Alcance** se manifiesta en que nadie sabe realmente qué se incluye en la primera versión. Esto ocurre cuando la definición original era demasiado general ("gestionar todo el proceso de ventas en Salesforce") y no se desglosó en escenarios concretos. La solución no es otra reunión de planificación, sino la redacción de una lista clara de “Obligatorio”, “Debería tener” y “Para más adelante”, con un Propietario para cada elemento. **El problema de Arquitectura** se manifiesta en elecciones técnicas que no resisten a escala: un modelo de datos que no soporta la cantidad de registros, una automatización que se ejecuta en un orden incorrecto, una integración que falla silenciosamente. Aquí se requiere una verificación técnica profunda y, a veces, la intervención de una [actualización del sistema Salesforce](/es/insights/salesforce-system-upgrade-signs) como infraestructura paralela para la corrección. **El problema de Confianza** es, en su mayoría, el resultado de los dos primeros, pero adquiere vida propia: los usuarios dejan de informar problemas porque "de todos modos no los arreglan", y la dirección deja de financiar cambios porque "ya lo intentamos". Un problema de confianza no se resuelve con declaraciones, sino con pruebas pequeñas y repetidas. ### Tabla de diagnóstico: Síntoma, Causa Raíz y Primera Acción | Síntoma observado | Causa raíz probable | Primera acción recomendada | | --- | --- | --- | | Cada conversación genera un nuevo requisito | Alcance nunca cerrado, sin definición de "fuera de alcance" | Redactar un documento de Alcance con una sección explícita "Qué no se incluye en esta versión" y obtener su aprobación | | Los informes muestran números contradictorios | Varias fuentes de verdad para la información, sin una Única Fuente de Verdad | Identificar el campo/objeto de la fuente oficial y eliminar duplicidades en los informes | | El sistema se "bloquea" con carga media | Automatización ineficiente o bucles de actualización | Perfiles de Flow y Apex bajo carga simulada, antes de cualquier corrección puntual | | Los usuarios vuelven a Excel | No hay confianza en que el sistema refleje la situación real | Corrección rápida de un error puntual que molesta a diario, y comunicación pública de la corrección | | El equipo técnico no explica sus elecciones | Brechas de comunicación entre Negocio y TI, no necesariamente un problema técnico | Una breve reunión de aclaración donde cada decisión técnica se presenta en términos de negocio | | Cada Release pospone la fecha límite | El Alcance crece durante el trabajo sin control | Congelación de cambios (Change Freeze) hasta la finalización de la ola actual | ## Reinicio (Reset) versus Refactorización (Refactor): cómo decidir Esta es la decisión central y también la más costosa, por lo que debe basarse en criterios y no en una intuición. Tres pruebas ayudan: 1. **El alcance de la deuda técnica frente al alcance de lo que ya funciona.** Si el 70% de la funcionalidad funciona razonablemente y solo partes específicas fallan, es una Refactorización. Si el problema radica en el modelo de datos básico, casi siempre es preferible un Reinicio parcial. 2. **El costo de la explicación frente al costo de la reconstrucción.** Si al nuevo equipo le lleva más de una semana entender por qué algo se construyó de cierta manera, es probable que el costo de mantenimiento futuro supere el costo de una construcción limpia. 3. **El estado de confianza de los usuarios.** Cuando la confianza es muy baja, un Reinicio enfocado y transparente (con el anuncio "estamos iniciando una nueva versión, corregida") a veces logra más cooperación que una corrección silenciosa que los usuarios no perciben. En la práctica, la mayoría de los rescates exitosos son híbridos: un Reinicio para el componente central problemático (por ejemplo, el modelo de Opportunity o el proceso de aprobación), junto con una Refactorización del resto del sistema. Una comparación estructurada entre los enfoques se presenta en [reconstruir Salesforce](/es/insights/salesforce-rebuild-vs-refactor), que detalla los criterios para cada escenario. ## Plan de 90 días para el rescate | Etapa | Días | Objetivo principal | Producto medible | | --- | --- | --- | --- | | Estabilización | 1-10 | Frenar el daño, Change Freeze en áreas sensibles | Diagnóstico completo y lista de riesgos | | Decisión | 11-20 | Reset vs. Refactor, Alcance final para la primera ola | Documento de decisión firmado con Propietario | | Primera ola | 21-50 | Corrección del problema más doloroso para los usuarios | Un escenario End-to-End funcionando y probado | | Expansión | 51-75 | Adición de funcionalidades según prioridad acordada | Dos o tres procesos adicionales en uso | | Estabilización y cierre | 76-90 | Medición contra la línea base, entrega de Gobernaza | Dashboard, documentación y plan de mantenimiento | Es crucial planificar la etapa de la "primera ola" en torno a un proceso único que los usuarios notarán en cuestión de semanas, y no en torno al componente técnicamente más interesante. Los proyectos que fallan por segunda vez suelen hacerlo porque vuelven a cometer el mismo error: empezar por la capacidad impresionante en lugar del dolor real. Esta etapa está directamente relacionada con el rendimiento en la práctica, y aquellos que experimenten problemas de velocidad de respuesta pueden consultar [optimización del rendimiento de Salesforce](/es/insights/salesforce-performance-optimization). ## Recuperación de la confianza con los usuarios La confianza no se recupera por una presentación; se recupera por un patrón consistente de pequeñas promesas cumplidas. Algunos principios que han funcionado en la práctica: - **Anuncie una pequeña victoria de manera explícita.** Cuando haya corregido un error recurrente, envíe un mensaje breve que diga exactamente qué se corrigió y quién lo solicitó. Dicha transparencia genera más confianza que una lista general de logros. - **Invite a los usuarios a una prueba temprana, no solo a la UAT al final.** Quien ve una versión intermedia y siente que sus comentarios fueron tomados en cuenta, se convierte en un embajador del proyecto ante el resto del equipo. - **No prometa una fecha de la que no esté seguro.** Una fecha pospuesta por tercera vez daña la confianza más que un cronograma realista pero menos optimista. - **Documente un fallo públicamente también.** Cuando algo no funcionó, una breve explicación de lo sucedido y lo que cambia genera más credibilidad que una silenciosa omisión. El proceso de recuperación de la confianza suele durar más que la propia corrección técnica, por lo que es aconsejable planificarlo como una vía paralela al plan de 90 días y no como un resultado automático del mismo. Las organizaciones que desean un acompañamiento estructurado para este proceso, incluyendo un seguimiento cercano del equipo y la dirección, pueden utilizar el [servicio Salesforce Health Check](/es/salesforce-health-check) como un marco de trabajo completo. ## Escenario organizacional de ejemplo Una empresa de servicios financieros ejecutó un proyecto Salesforce durante nueve meses sin un Go Live. En la revisión, se descubrió que el alcance se había triplicado respecto a lo planeado originalmente, que el equipo técnico había construido tres versiones diferentes del mismo proceso de aprobación sin documentar el porqué, y que los usuarios clave ya habían migrado la gestión del informe mensual a una hoja de cálculo separada. El plan de diagnóstico de diez días reveló que el problema central no era técnico: el equipo técnico había recibido requisitos contradictorios de dos gerentes diferentes sin que nadie los coordinara. La decisión fue una Refactorización parcial, no un Reinicio completo, porque la mayor parte del código estaba correcto. La primera etapa se centró únicamente en el proceso de aprobación, que era la principal fuente de frustración, y en cinco semanas se lanzó una versión estable que los gerentes aprobaron conjuntamente. Solo entonces continuaron con la expansión de los demás procesos. La lección principal: el estancamiento no se debió a un fallo técnico puntual, sino a la ausencia de una única persona que tuviera el mapa completo de decisiones. Un rol ऐसे como este, incluso si es temporal, suele ser la diferencia entre un proyecto que tiene éxito la segunda vez y uno que vuelve a estancarse. ## Lista de verificación antes de decidir sobre un rescate - ☐ Se realizó un diagnóstico de 10 días con entrevistas, revisión del Org y comparación con documentos originales - ☐ Los problemas se clasificaron claramente en Alcance, Arquitectura o Confianza - ☐ Se tomó una decisión documentada de Reinicio/Refactorización con justificaciones - ☐ Se seleccionó un proceso para la primera ola basado en un dolor real de los usuarios - ☐ Se definió un Change Freeze para el período de diagnóstico y decisión - ☐ Se establecieron métricas de línea base antes de iniciar la corrección - ☐ Existe un plan de comunicación continuo para usuarios y dirección - ☐ Se designó un único Propietario que tiene el mapa completo de decisiones - ☐ El plan de 90 días incluye hitos medibles y no solo una fecha de finalización - ☐ Se definió un proceso para la entrega de Gobernanza y mantenimiento al finalizar el rescate ## Recursos profesionales - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check - HPI Pro – Soporte y acompañamiento — https://hpi.pro/support ### Preguntas y respuestas **¿Cuál es la diferencia entre un proyecto 'lento' y un proyecto realmente 'estancado'?** Un proyecto lento aún genera decisiones y progreso medible, aunque a un ritmo menor. Un proyecto estancado es aquel donde pasan dos o tres semanas sin una nueva Decisión, sin una versión probada con un usuario real, y sin cambios en el estado del Backlog. Si no hay una respuesta clara a 'qué pasó esta semana', es probable que estemos ante un estancamiento. **¿Quién debería liderar el proceso de diagnóstico, un consultor externo o alguien del equipo interno?** Es aconsejable que un actor externo lidere la fase de diagnóstico, ya que no tiene responsabilidad por decisiones anteriores y puede hacer preguntas incómodas sin generar actitudes defensivas. El equipo interno debe participar plenamente en las entrevistas y la revisión de datos; de lo contrario, las conclusiones se percibirán como una crítica externa y no como una base para la acción conjunta. **¿Es posible rescatar un proyecto sin cambiar de proveedor o integrador?** Sí, y a veces es el camino correcto, especialmente cuando el problema es de Alcance y comunicación, no de calidad técnica. Esto debe evaluarse frente a tres preguntas: ¿El equipo actual toma decisiones claras, hay transparencia en el código y la documentación, y existe una verdadera voluntad de detenerse y corregir? Si la respuesta es negativa en las tres, el cambio de proveedor se vuelve relevante. **¿Cuánto tiempo se tarda en ver una primera mejora que los usuarios perciban?** En proyectos donde el diagnóstico se realizó correctamente, la primera mejora perceptible llega entre 3 y 4 semanas desde el inicio del plan de 90 días, generalmente corrigiendo un error recurrente o acortando un proceso diario. Una mejora estructural más profunda, como la corrección de un modelo de datos, toma entre 6 y 12 semanas, dependiendo del alcance de la deuda técnica. **¿Qué sucede si el Patrocinador original ya no cree en el proyecto?** Este es el indicador más fuerte de la necesidad de rescate, no una razón para rendirse. El primer paso es construir para ese Patrocinador una pequeña evidencia medible en dos semanas, por ejemplo, corrigiendo un problema que le molesta personalmente a diario. La confianza se reconstruye a través de pequeñas y repetidas pruebas, no mediante una presentación detallada del plan. --- ## ¿Cómo definir un MVP para un proyecto Salesforce sin crear un sistema temporal? URL: https://hpi.pro/es/insights/salesforce-mvp-scope La diferencia entre un MVP y un sistema parcialmente construido no radica en la cantidad de funcionalidades, sino en qué decisiones se han cerrado. Una primera fase bien definida cierra completamente el modelo de datos y los permisos, reduciendo específicamente el alcance comercial. Este artículo presenta un criterio claro para los límites de un MVP y una tabla de decisiones que pueden o no posponerse. ## La prueba que diferencia un MVP de un sistema temporal Dos proyectos pueden lanzarse con el mismo número de pantallas, pero uno servirá de base para el crecimiento mientras que el otro se convertirá en una deuda a solventar. La diferencia no radica en el alcance, sino en el tipo de concesión. La regla práctica es: **en la primera fase, se reduce el alcance de negocio, no la profundidad arquitectónica.** Es permisible limitar la cantidad de procesos, unidades y tipos de clientes a incluir. Sin embargo, no se debe comprometer el modelo de datos central, el modelo de permisos ni la definición de la fuente de verdad. Estos deben construirse correctamente desde el principio, incluso si inicialmente solo atienden a cincuenta usuarios. Quien reduce la profundidad en lugar del alcance obtiene un sistema que funciona durante un trimestre y luego debe ser reconstruido. El contexto más amplio de las fases del proyecto se detalla en la [Guía de Implementación de Salesforce](/es/insights/salesforce-implementation-guide). ## Tres definiciones que suelen confundirse | Término | Qué es en la práctica | Cuándo es apropiado | Riesgo principal | | --- | --- | --- | --- | | Prueba de Concepto (PoC) | Demostración de viabilidad técnica de un componente. | Cuando existe una duda genuina sobre la posibilidad de algo. | Se tiende a escalarlo a producción. | | Piloto | Operación completa en un grupo reducido. | Cuando la solución es conocida y la cuestión es la adopción. | El grupo no es suficientemente representativo. | | MVP (Producto Mínimo Viable) | Primera versión en producción que genera valor real. | Cuando se busca aprender del uso práctico. | Se convierte en permanente sin una decisión formal. | La elección entre estos tres no es una cuestión semántica. Una PoC puede descartarse, un MVP no. Por ello, un MVP solo debe construirse con estándares de producción. ## Decisiones que no se deben posponer Existe un conjunto de decisiones cuyo costo de modificación aumenta exponencialmente una vez que se tienen datos en producción. Estas decisiones deben abordarse en la primera fase, incluso si en ese momento solo cubren una pequeña parte del panorama: - **El objeto que sostiene el proceso de negocio** y su relación con las entidades centrales. - **La clave única que identifica a un cliente** frente a sistemas externos. - **La visibilidad predeterminada** en cada objeto clave. - **La estructura de propiedad de un registro** — quién es el Propietario y qué sucede cuando un empleado se va. - **La definición de la fuente de verdad** para cada entidad sincronizada con otro sistema. Por otro lado, las decisiones que se pueden y deben posponer incluyen: el diseño de informes avanzados, automatizaciones de conveniencia, la integración de canales secundarios, la localización para unidades no incluidas en la primera fase, e integraciones que no son críticas para decisiones en tiempo real. ## Cómo seleccionar el proceso para la primera fase No se elige el proceso más sencillo ni el más problemático. Se selecciona el proceso que cumple con tres condiciones simultáneamente: tiene un único propietario de proceso disponible, genera un resultado visible para la dirección, y representa el modelo de datos central. Un proceso que cumpla con dos de las tres condiciones aún es viable; uno que cumpla con solo una resultará en una primera fase que no aportará aprendizaje significativo. Otra consideración es el volumen: un proceso que ocurre diez veces al mes no generará suficiente uso para aprender de él en un trimestre. ## Criterio de salida — qué indica el éxito de la fase Un MVP sin un criterio de salida se convierte en un estado permanente. El criterio debe ser medible, conciso y conocido de antemano. Un ejemplo de estructura: - El porcentaje de procesos del tipo seleccionado que se ejecutan realmente en el sistema y no fuera de él. - No hay incidencias bloqueantes abiertas por encima de un número definido de días. - Los datos generados durante el período cumplen con el umbral de calidad predefinido. - El propietario del proceso confirma por escrito que el proceso se ejecuta sin soluciones alternativas permanentes. Es importante destacar que ninguno de estos es "el sistema ha sido lanzado". Esa fecha es el punto de inicio de la medición, no su final. ## Costo de la demora — la herramienta para resolver discusiones de alcance Al debatir si una funcionalidad debe incluirse en la primera fase, la pregunta útil no es cuánto cuesta construirla ahora, sino cuánto costará construirla más tarde. La siguiente tabla sirve como herramienta de trabajo en una reunión de alcance: | Tipo de funcionalidad | Costo de construcción en la primera fase | Costo de construcción en la segunda fase | Conclusión | | --- | --- | --- | --- | | Cambio en la estructura del objeto central | Bajo | Muy alto — incluye migración | Se incluye en la primera fase | | Nuevo modelo de permisos | Medio | Alto — la exposición ya ocurrió | Se incluye en la primera fase | | Informe de gestión | Bajo | Bajo | Se pospone | | Automatización de alertas | Bajo | Bajo | Se pospone | | Integración requerida para decisiones en tiempo real | Alto | Alto + solución alternativa establecida | Se incluye si el proceso depende de ella | | Integración solo para informes | Medio | Medio | Se pospone | ## Ejemplo ilustrativo: una empresa de logística internacional El escenario es hipotético y tiene fines ilustrativos. Una empresa de transporte con operaciones en tres países quería lanzar un MVP en once semanas. La propuesta inicial era incluir los tres países, pero solo la fase de cotización, sin la fase de pedido. El equipo invirtió el enfoque: un solo país, pero el proceso completo desde la cotización hasta el pedido aprobado, incluida la integración que extrae las tarifas. La razón era simple: cortar el proceso a la mitad habría obligado a los usuarios a continuar en el sistema antiguo para la fase de pedido, es decir, a introducir datos dos veces. En lugar de aprender si el sistema ayudaba, la empresa habría aprendido que el sistema dificultaba el trabajo. El alcance total en semanas se mantuvo similar. La diferencia fue que, tras la primera fase, la empresa tenía un proceso completo en funcionamiento, en lugar de medio proceso en tres países. ## Señales de que el MVP se ha convertido en un sistema temporal - Existe un proceso manual permanente diseñado para "cubrir hasta la siguiente fase" y que lleva funcionando dos meses. - Se acordó un campo que se utiliza para dos propósitos diferentes porque no hubo tiempo para dividirlo. - Existe un grupo de usuarios que trabaja simultáneamente en dos sistemas. - No hay una fecha de decisión para la siguiente fase, solo una lista de espera. Estos patrones aparecen detallados, junto con otros errores comunes, en la [Guía de Errores Comunes en la Implementación de CRM](/es/insights/crm-implementation-mistakes). ## Integración con el cronograma general La definición del MVP impacta directamente en la duración del proyecto, y a veces en la dirección opuesta a la esperada: una primera fase demasiado estrecha alarga el proyecto global, ya que cada fase conlleva un costo fijo de pruebas, formación y lanzamiento. Cómo traducir esto a una planificación realista y detallada se explica en la [Guía de Duración de Proyectos Salesforce](/es/insights/salesforce-project-timeline), y en caso de reemplazar un sistema existente, también en la [Guía para la Migración a Salesforce](/es/insights/replace-crm-with-salesforce). ## El siguiente paso Escriba en una frase cuál es el proceso de la primera fase, quién es su propietario de proceso y cuál es el criterio que, en un trimestre, indicará su éxito. Si alguna de estas tres frases no se puede redactar ahora, ese es el punto de partida, no la lista de funcionalidades. ### Preguntas y respuestas **¿Cuál es un tamaño razonable para un MVP en un proyecto Salesforce?** No existe un número fijo, pero sí una prueba práctica: la primera fase debe incluir un proceso de negocio completo de principio a fin, para un único grupo de usuarios, con los datos que el proceso realmente necesita. Si tiene que interrumpir el proceso a la mitad para cumplir con el alcance, es una señal de que eligió un proceso demasiado grande, no que el MVP es demasiado pequeño. **¿Es posible aplazar la integración con un sistema central a una segunda fase?** Sí, siempre y cuando el proceso de la primera fase no dependa de ella para la toma de decisiones. Si el equipo de ventas necesita abrir el ERP simultáneamente para conocer el inventario o el saldo de crédito, posponer la integración no ahorra trabajo, sino que crea una práctica de solución alternativa que luego es difícil de eliminar. **¿Quién decide qué queda fuera del MVP?** La decisión recae en el Patrocinador Comercial, con la recomendación del Propietario del Proceso y el Arquitecto, no en un comité. La razón es práctica: excluir una funcionalidad de la primera fase es una concesión política, y solo una entidad con autoridad presupuestaria puede respaldarla sin que la funcionalidad regrese a través de solicitudes de cambio. **¿Cómo se evita que un MVP se convierta en permanente?** Se deben establecer de antemano un criterio de salida medible y una fecha de decisión para la siguiente fase, no solo una lista de continuación. Además, no se debe permitir que la primera fase eluda las decisiones arquitectónicas: un sistema que permanece permanente con un modelo de datos correcto es un resultado razonable, y un sistema que permanece permanente con una solución temporal es una deuda. **¿Es un MVP adecuado también para reemplazar un CRM existente?** Sí, pero el límite se define de manera diferente. Al reemplazar un sistema, existe la presión de transferir todo lo que el sistema anterior hacía, por lo que la primera fase se define por un grupo de usuarios o una unidad de negocio, y no por un subconjunto de funcionalidades. Operar simultáneamente dos sistemas para el mismo grupo genera duplicidad de trabajo y afecta la fiabilidad de los datos. --- ## Equipo de Proyecto Salesforce: Roles, Responsabilidades y Modelo de Colaboración con Proveedores URL: https://hpi.pro/es/insights/salesforce-project-team-roles Los dos roles que determinan el éxito de un proyecto Salesforce suelen residir del lado del cliente, no del proveedor. Aquí se definen los nueve roles esenciales, su impacto crucial, cuáles no pueden externalizarse y cómo una tabla RACI optimizada evita retrasos por espera de decisiones. ## Roles que Impulsan el Ritmo del Proyecto En un proyecto Salesforce, es posible contar con un arquitecto excelente, un equipo de desarrollo experimentado y un director de proyecto organizado, y aun así quedarse atrás en el cronograma. La razón más común no es el ritmo de construcción, sino el ritmo de la toma de decisiones. El desarrollo espera una decisión, la decisión espera una reunión y la reunión espera una agenda. Por lo tanto, la división efectiva de roles no se basa en quién hace qué, sino en **quién decide qué y con qué tiempo de respuesta**. Una revisión de las etapas en las que se requiere cada rol se encuentra en la [Guía de Implementación de Salesforce](/es/insights/salesforce-implementation-guide). ## Los Nueve Roles y Su Mandato **Executive Sponsor** — Resuelve conflictos entre departamentos, aprueba dispensas del alcance y protege la prioridad frente a presiones concurrentes. Si no tiene autoridad presupuestaria, no es un Sponsor, sino un representante. **Dueño del Proceso** — Define cómo se realizará el trabajo en la práctica después del cambio, y valida que el proceso construido se ajusta a la realidad. Uno por cada proceso central, no un comité. **Product Owner / Gerente CRM** — Gestiona la prioridad en el *backlog*, resuelve solicitudes concurrentes y mantiene la conexión entre los requisitos y el valor. **Director de Proyecto** — Cronograma, dependencias, riesgos, coordinación de proveedores e informes. **Arquitecto de Soluciones** — Decide sobre el modelo de datos, permisos, límites del sistema y la forma de implementación; responsable de documentar alternativas consideradas. **Salesforce Admin** — Configuración, entornos, gestión de usuarios y mantenimiento continuo después del lanzamiento. **Desarrollador** — Lógica personalizada, integraciones, pruebas automatizadas. **Dueño de Datos** — Determina la fuente de la verdad, qué se considera un registro válido y quién aprueba la carga. **Líder de Adopción y Capacitación** — Comunicación, formación según el rol, gestión de la resistencia y medición del uso. En un proyecto pequeño, una persona puede desempeñar dos roles, pero hay dos pares que es preferible no unificar: arquitecto y director de proyecto (conflicto entre exhaustividad y velocidad), y dueño del proceso y líder de pruebas (se prueba a sí mismo). ## Quién Debe Ser Interno | Rol | Posibilidad de Provisión Externa | Explicación | | --- | --- | --- | | Executive Sponsor | No | Requiere autoridad organizacional | | Dueño del Proceso | No | Requiere apropiación del trabajo en la práctica | | Dueño de Datos | No | Requiere responsabilidad regulatoria y empresarial | | Product Owner | Parcialmente | Es posible el acompañamiento, no la sustitución | | Director de Proyecto | Sí | Común y adecuado | | Arquitecto de Soluciones | Sí | Recomendable con acompañamiento interno para el conocimiento | | Admin | Sí, temporalmente | Preferible transferir a un recurso interno antes del Go Live | | Desarrollador | Sí | Estándar | | Líder de Adopción | Parcialmente | El mensaje interno debe provenir de la organización | ## Matriz RACI para los Puntos de Decisión Clave | Decisión | Responsable (Accountable) | Consultado (Consulted) | Tiempo de Respuesta Requerido | | --- | --- | --- | --- | | Estructura del modelo de datos | Arquitecto | Dueño del proceso, Dueño de Datos | Hasta una semana | | Cambio en el Alcance (Scope) | Sponsor | Product Owner, Director de Proyecto | Hasta una semana | | Prioridad en el Backlog | Product Owner | Dueños de procesos | Hasta dos días | | Definición de campo obligatorio | Dueño del proceso | Admin | Hasta dos días | | Aprobación de carga de datos | Dueño de Datos | Arquitecto | Hasta tres días | | Aprobación de paso a producción | Sponsor | Director de Proyecto, Dueño del proceso | Según puerta definida | | Resolución de incidencia bloqueante | Director de Proyecto | Arquitecto, Admin | El mismo día | La columna de tiempo de respuesta es la parte interesante de la tabla. Un RACI sin SLA para la decisión es una descripción agradable que no cambia el ritmo. ## Disponibilidad Real — El Error Recurrente en la Planificación | Rol | Etapa de Definición | Etapa de Construcción | Etapa de Pruebas | Go Live y Semanas Posteriores | | --- | --- | --- | --- | --- | | Sponsor | Baja, constante | Baja | Media | Media | | Dueño del Proceso | Alta | Media | Muy alta | Alta | | Product Owner | Alta | Alta | Alta | Media | | Admin | Media | Alta | Alta | Muy alta | | Dueño de Datos | Media | Baja | Alta | Media | | Líder de Adopción | Baja | Media | Media | Muy alta | La planificación defectuosa común es la suposición de que la carga del dueño del proceso disminuye después de la definición. En realidad, vuelve a aumentar en la fase de pruebas, justo cuando el empleado regresa a su trabajo habitual. ## Ejemplo Ilustrativo: Colegio Universitario El escenario es hipotético y tiene fines ilustrativos. Un colegio implementó un sistema de gestión de candidatos. El equipo se definió correctamente en papel, pero el "dueño del proceso" era el jefe de la sección de admisiones, quien dedicaba dos horas semanales al proyecto. Cualquier pregunta sobre el estado de un candidato esperaba hasta el martes por la mañana. Después de dos meses, se determinó que el retraso acumulado por la espera de decisiones superaba el retraso por cualquier otra razón combinada. La solución no fue contratar más desarrolladores. El colegio designó a un subalterno que recibió un mandato expreso para tomar decisiones diarias hasta un nivel de impacto definido, dejando al jefe de la sección solo las decisiones que modificaban la política. El ritmo de desarrollo aumentó sin cambios en el tamaño del equipo del proveedor. ## Modelo de Trabajo con el Proveedor Tres mecanismos son suficientes para la mayoría de los proyectos: - **Registro de decisiones compartido** — Cada decisión con fecha, responsable, justificación y alternativas rechazadas. Esta es también la única documentación que sigue siendo útil dos años después. - **Punto de contacto único en ambos lados** — Las solicitudes directas de múltiples participantes a los desarrolladores son la forma segura de perder la trazabilidad. - **Ciclo de demostración a ritmo constante** — El dueño del proceso ve un producto funcional, no una presentación. La brecha entre la expectativa y la implementación se revela en dos semanas en lugar de dos meses. En organizaciones grandes, se requiere una capa adicional de gobernanza entre unidades de negocio, como se describe en la [Guía de Implementación de Salesforce en una Organización Enterprise](/es/insights/enterprise-salesforce-implementation). ## Puntos de Encuentro con Otras Etapas La composición del equipo se deriva directamente de dos aspectos: los entregables requeridos en la fase de definición, detallados en la [Guía de Descubrimiento de CRM](/es/insights/crm-discovery-guide), y el alcance de la primera ola, determinado según las reglas en la [Guía de Definición de MVP](/es/insights/salesforce-mvp-scope). Una primera ola más delimitada requiere menos dueños de procesos concurrentes, y esta es una razón independiente para reducir la amplitud. ## Revisión Rápida Antes de Iniciar un Proyecto Responda a cuatro preguntas con nombre y apellido, no con el nombre de un departamento: ¿Quién decide cuando Ventas y Operaciones no están de acuerdo?; ¿Quién aprueba que el proceso construido se ajusta a la realidad?; ¿Quién indica qué datos son fiables?; y ¿Quién mantendrá el sistema dentro de un año? Una respuesta faltante a cualquiera de ellas es el mayor riesgo en el proyecto, y es también la única que no se resuelve con dinero. ### Preguntas y respuestas **¿Cuánto tiempo debe dedicar un Propietario de Proceso a un proyecto Salesforce?** Durante la fase de análisis y diseño, generalmente entre un tercio y medio tiempo. En las fases de prueba y lanzamiento, a menudo más. La creencia común de que una reunión semanal es suficiente es la causa frecuente de retrasos: las decisiones diarias son demasiado pequeñas para justificar una reunión, pero bloquean el desarrollo si no hay quien las resuelva el mismo día. **¿Qué roles no se pueden delegar a un proveedor externo?** Tres roles esenciales: el Patrocinador (Sponsor) facultado para resolver conflictos interdepartamentales, el Propietario de Proceso (Process Owner) que define la futura operativa del negocio, y el Propietario de Datos (Data Owner) que establece la integridad y fiabilidad de la información. Un proveedor puede ofrecer arquitectura, desarrollo, gestión de proyectos e incluso gestión del cambio, pero no puede decidir por la organización qué es lo más conveniente para ella. **¿Es necesario contar con un Administrador Salesforce interno desde el inicio del proyecto?** Es preferible que sí, y no solo hacia el final. Un Administrador que se integra en la fase de análisis y diseño comprende la justificación detrás de las decisiones, no solo el resultado final, lo que le permite mantener y modificar el sistema eficazmente. Un Administrador que recibe el sistema en la semana de lanzamiento se ve forzado a aprender la arquitectura desde la configuración, lo cual es lento y propenso a errores. **¿Cuál es la diferencia entre un Product Owner y un Gestor de Proyectos en el contexto de Salesforce?** El Gestor de Proyectos es responsable del cronograma, las dependencias, los riesgos y el presupuesto. El Product Owner es responsable de priorizar el contenido: qué se construye primero y qué se pospone. Cuando estos roles se fusionan en una sola persona, una de las responsabilidades suele descuidarse; generalmente, la priorización se ve sacrificada en favor del cumplimiento de plazos. **¿Cómo colaborar eficazmente con un equipo de proveedor externo remoto?** Mediante tres mecanismos clave: un único punto de contacto en ambas partes, decisiones registradas en un diario de decisiones compartido en lugar de correos electrónicos, y un ciclo de demostraciones breves y regulares donde el Propietario de Proceso vea el producto funcionando. Las barreras idiomáticas y las diferencias horarias son manejables; lo que no lo es, son las decisiones tomadas verbalmente y no documentadas. --- ## UAT en Proyectos Salesforce: Cómo se Prueban los Procesos de Negocio y No Solo las Pantallas URL: https://hpi.pro/es/insights/salesforce-uat-guide Un UAT que parezca un recorrido guiado por pantallas no detectará los errores que pueden frustrar un lanzamiento. La prueba debe ejecutarse con escenarios completos, datos que simulen la realidad y ser realizada por quienes usarán el sistema. Esta guía presenta una metodología sólida para construir casos de prueba, un modelo de severidad para defectos y criterios de aceptación claros. ## Por qué el UAT falla incluso cuando parece exitoso En muchos ciclos de UAT, todos los escenarios se marcan como aprobados, y dos semanas después del lanzamiento, se abren decenas de solicitudes. Esto no es una paradoja, es un resultado directo de una prueba construida en torno a las pantallas. Una prueba centrada en la pantalla pregunta: "¿Es posible crear un registro?". Una prueba centrada en el proceso pregunta: "¿Puede un agente recibir una solicitud, identificar que el cliente existe con otro nombre, verificar su elegibilidad en el sistema central, abrir un caso, transferirlo a otra entidad y cerrarlo, incluso cuando el cliente existe dos veces en el sistema?". El segundo escenario encuentra lo que el primero omite. Esta guía presenta la estructura de UAT que se enfoca en la segunda pregunta. La conexión con otras fases del proyecto se encuentra en la [Guía de Implementación de Salesforce](/es/insights/salesforce-implementation-guide). ## Qué debe estar listo antes de empezar - **Un entorno estable** que no reciba despliegues durante el ciclo, excepto por correcciones de bloqueo aprobadas. - **Datos de prueba** con un volumen y complejidad similares a los de producción. - **Usuarios con permisos reales**, no administradores para todos. La mitad de los problemas de permisos se descubren solo cuando el evaluador tiene el perfil correcto. - **Criterios de aceptación** definidos para cada proceso central. - **Un mecanismo único de reporte de errores**, con campos obligatorios mínimos. El elemento que más se suele omitir es el tercero, y es el que genera los errores más embarazosos el día del lanzamiento. ## Cómo construir un escenario que encuentre problemas Un buen escenario comienza con una persona y un estado inicial, no con un clic. Una estructura que funciona: 1. **Quién** - Rol y permiso exactos. 2. **Estado inicial** - Qué información existe en el sistema antes de que comience el escenario. 3. **Qué sucede** - El evento de negocio que activa el proceso. 4. **Qué hace el evaluador** - A nivel de acción de negocio, no a nivel de clic. 5. **Resultado esperado** - Incluyendo lo que sucedió en otros sistemas. 6. **Qué no debería suceder** - El registro no se expone a quien no debe, la alerta no se envía dos veces. El sexto punto es lo que separa una lista de verificación de una prueba profesional. ## Seis familias de escenarios que deben incluirse | Familia | Ejemplo de escenario | Qué revela | | --- | --- | --- | | Ruta positiva | Proceso completo de principio a fin | Si el proceso es factible | | Excepción de negocio | Cancelación, reembolso, volver a una etapa anterior | Lógica construida solo en una dirección | | Datos con problemas | Cliente duplicado, nombre en hebreo y español, campo vacío | Mapeo y limpieza insuficientes | | Permisos | Usuario que intenta acceder a un registro de otra unidad | Lagunas en el modelo de exposición | | Fallo de integración | El sistema de destino no está disponible | Manejo de errores, bucles, duplicidades | | Volumen | Acción colectiva sobre un gran número de registros | Limitaciones de rendimiento y automatización | La ausencia de una familia completa de la lista es una señal de que la prueba proporcionará una falsa sensación de seguridad. ## Clasificación de la severidad: la condición para gestionar el ciclo Sin una clasificación acordada, cada error parece urgente y la decisión sobre el lanzamiento se convierte en una discusión. Un modelo de cuatro niveles es suficiente: | Nivel | Definición | Impacto en el lanzamiento | | --- | --- | --- | | Bloqueador | No se puede completar un proceso central, no hay solución alternativa | Bloqueador | | Grave | El proceso es posible con una solución alternativa pesada o se guardan datos incorrectos | Bloqueador a menos que se apruebe explícitamente | | Medio | Inconveniente significativo, solución alternativa razonable | No bloqueador, entra en el plan de corrección | | Bajo | Texto, orden de campos, mejora | Se recopila para la siguiente fase | La regla importante: la clasificación la determina el propietario del proceso junto con el equipo técnico, no quien informó del error. ## Condiciones para pasar a producción Se formulan antes de que comience el ciclo y no al final: - Cero errores bloqueadores abiertos. - Todo error grave cerrado o aprobado por escrito con una solución alternativa y un tiempo de corrección. - Todos los procesos centrales ejecutados en un segundo ciclo sin nuevos fallos. - Los propietarios del proceso han aprobado por escrito. - Existe un plan de reversión probado, no solo escrito. ## Ejemplo ilustrativo: Fondo de pensiones El escenario es hipotético y está diseñado para ilustración. Un fondo de pensiones probó un proceso de gestión de solicitudes de afiliados. El primer ciclo de UAT se completó casi en su totalidad. El equipo notó que todos los evaluadores usaron un perfil extendido, porque la asignación de perfiles precisos se había retrasado. En un segundo ciclo, con los perfiles reales, se encontraron once errores: los agentes no veían registros de afiliados que habían sido transferidos entre planes, un botón de aprobación de excepción aparecía para quienes no estaban autorizados, y un informe de cargas devolvía resultados parciales a los jefes de equipo. Ninguno de los errores estaba relacionado con la funcionalidad probada en el primer ciclo; todos estaban en el modelo de exposición. La conclusión práctica que se adoptó allí: no se inicia un ciclo de UAT antes de que todos los participantes tengan el perfil con el que trabajarán en producción. ## Errores de gestión que encarecen el ciclo - Despliegue de versiones en medio del ciclo, lo que invalida la validez de las pruebas ya realizadas. - Evaluadores que informan en WhatsApp y correo electrónico en paralelo al sistema de seguimiento. - Escenarios escritos a nivel de clic, lo que convierte cualquier cambio en la interfaz en una actualización de la documentación. - Acortamiento del segundo ciclo por presión de tiempo, este es el ciclo que descubre las regresiones. Estos patrones aparecen junto con otros fallos en la [Guía de Errores Comunes](/es/insights/crm-implementation-mistakes), y la responsabilidad de cada uno de ellos se define en la [Guía de Roles del Equipo de Proyecto de Salesforce](/es/insights/salesforce-project-team-roles). ## Cuando se trata de reemplazar un sistema existente En un proyecto de reemplazo, UAT tiene un segundo papel: la comparación. Los mismos diez escenarios se ejecutan en ambos sistemas, y los resultados se comparan campo por campo. Esta es la herramienta más eficaz para descubrir inconsistencias de mapeo antes de que se conviertan en lagunas de confianza. El orden de las operaciones en tal transición se detalla en la [Guía para Reemplazar su CRM por Salesforce](/es/insights/replace-crm-with-salesforce). ## Lo que queda después del ciclo Los escenarios de UAT no son un documento de una sola vez. Son la base para las pruebas de regresión en cada lanzamiento futuro, y son la mejor fuente de material de capacitación, ya que están escritos en el lenguaje del proceso y no en el del sistema. Guardarlos en un formato que pueda ejecutarse nuevamente es la inversión más económica que se puede hacer de cara al próximo año. ### Preguntas y respuestas **¿Cuánto tiempo se debe asignar al UAT en un proyecto Salesforce?** Un período práctico es de dos a cuatro semanas para una fase de tamaño medio, pero la variable determinante no es el número de casos de prueba, sino la cantidad de ciclos de corrección. Planifique al menos dos ciclos: el primero para la detección, el segundo para verificar que las correcciones no hayan introducido nuevos problemas. Un UAT de una sola semana casi siempre resulta en descubrimientos en producción. **¿Debe el UAT ejecutarse con datos reales?** Debe realizarse con datos que simulen la realidad en alcance y complejidad, pero adaptados a las restricciones de privacidad. Probar con diez registros limpios no revelará duplicados, nombres problemáticos, clientes con jerarquías profundas o registros históricos faltantes; y estos son precisamente los casos que generan problemas en la primera semana de producción. **¿Quién debe redactar los casos de prueba?** Los propietarios del proceso, con el acompañamiento de quienes conocen el sistema. Cuando los desarrolladores redactan los casos de prueba, estos reflejan lo que se construyó, no lo que el negocio necesita. La función del equipo técnico es añadir escenarios de borde, no definir el proceso que se está probando. **¿Cuál es la diferencia entre UAT y pruebas de integración?** Las pruebas de integración verifican que los sistemas se comuniquen correctamente: formato, campos, manejo de errores, rendimiento. El UAT asegura que la persona que realiza el trabajo puede completarlo y que el resultado es comercialmente correcto. Es posible superar completamente las pruebas de integración y fallar el UAT, porque los datos fueron transferidos, pero el proceso no es ejecutable. **¿Es posible lanzar con errores abiertos?** Sí, si están clasificados y aprobados. Un error sin una solución alternativa viable es probable que se retrase; un error con una solución alternativa documentada y un tiempo de corrección acordado puede avanzar. Lo que no es permisible es lanzar con una lista de errores no clasificados, ya que la decisión se tomará en la práctica durante la primera semana en producción, por parte de los usuarios. --- ## ¿Cómo elegir el modelo de precios de su proyecto Salesforce: Precio Fijo, Tiempo y Materiales o Retainer? URL: https://hpi.pro/es/insights/salesforce-project-pricing-models La elección del modelo de precios es, principalmente, una decisión sobre quién asume el riesgo de la incertidumbre. Un "Precio Fijo" no es necesariamente más económico y "Tiempo y Materiales" no es intrínsecamente más riesgoso. Cada modelo se adapta a un nivel de madurez diferente en la definición del alcance del proyecto. Aquí le presentamos una guía de adaptación, mecanismos de protección para cada modelo y modelos híbridos que funcionan. ## El modelo de precios no es una cuestión de coste, sino de riesgo Cuando una organización considera entre un precio fijo y un modelo de Time & Materials (T&M), la pregunta habitual es cuál de los dos es más económico. Sin embargo, esta no es la pregunta correcta. Ambos modelos representan el mismo trabajo; la diferencia radica en **quién asume la variación cuando la realidad difiere de las suposiciones iniciales**. En un modelo de precio fijo, el proveedor asume el riesgo —por lo tanto, incluye un margen de riesgo en su presupuesto y se protege mediante una definición precisa de lo que está incluido. En T&M, la organización asume el riesgo —por lo tanto, necesita mecanismos de control. En Retainer, ambas partes obtienen estabilidad a cambio de una flexibilidad reducida. La regla general es simple: **cuanto más madura sea la definición del alcance (Scope), más ventajoso es un precio fijo.** Cuando hay más incertidumbre real, es preferible un modelo T&M con un tope máximo. ## Comparación rápida entre los tres modelos | Aspecto | Precio Fijo | Time & Materials | Retainer | | --- | --- | --- | --- | | Quién asume el riesgo del alcance | Proveedor | Organización | Compartido dentro del alcance acordado | | Condiciones de éxito | Scope bien definido | Transparencia y gestión cercana | Demanda estable y predecible | | Flexibilidad al cambio | Baja, a través de solicitudes de cambio | Alta | Media | | Carga administrativa para la organización | Media, concentrada en la definición | Alta, continua | Baja | | Fallo típico | Guerra de Scope | Descontrol de horas | Horas no utilizadas o absorbidas | | Buena adaptación a | Implementación de fase definida | Integración, migración, investigación | Mantenimiento y mejora continua | ## Precio Fijo — Cuándo sí y de qué tener cuidado Este modelo es adecuado cuando existe una especificación con criterios de aceptación, las integraciones son conocidas y documentadas, y la calidad de los datos ha sido verificada. En esta situación, el proveedor puede presupuestar con una confianza razonable y la organización obtiene una certeza presupuestaria real. Mecanismos de protección que debe solicitar: - Definición de "completado" para cada entregable, no solo del nombre del entregable. - Una lista explícita de suposiciones en las que se basa el precio. - Una tarifa acordada de antemano para las solicitudes de cambio, para que no se determine bajo presión. - Un calendario de pagos vinculado a la aceptación y no a fechas. Señal de advertencia: un precio fijo ofrecido sin preguntar sobre el volumen de datos, el número de usuarios o los sistemas de origen. Un precio así cambiará; la única pregunta es cuándo. ## Time & Materials — Cuándo sí y cómo controlarlo Es apropiado cuando existe una incertidumbre que no puede eliminarse a bajo costo: un sistema central heredado sin documentación, datos históricos de calidad desconocida o un proceso de negocio que sigue evolucionando. Mecanismos de control que lo hacen seguro: - **Un tope para cada hito** con una alerta al alcanzar un porcentaje acordado del mismo. - **Informes a nivel de tarea** — nombre de la tarea, horas, estado. - **Puntos de salida** sin penalización al final de cada hito. - **Composición del equipo acordada** — cuántas horas de personal sénior y júnior, para evitar cambios silenciosos. El último punto es a menudo olvidado y afecta el costo más que la tarifa misma. ## Retainer — Cuándo se convierte en un desperdicio El modelo Retainer funciona bien después del lanzamiento, cuando hay un flujo constante de solicitudes. Falla en dos situaciones opuestas: cuando la demanda es baja y la organización paga por horas no utilizadas, y cuando un desarrollo significativo se introduce, agotando la capacidad de soporte. Dos soluciones simples: una separación explícita entre soporte y desarrollo, y una cláusula de transferencia parcial de horas no utilizadas al mes siguiente, con un tope. La combinación de ambos estabiliza el modelo. ## Modelos híbridos que funcionan en la práctica | Fase del proyecto | Modelo recomendado | Justificación | | --- | --- | --- | | Consultoría y especificación | Precio fijo a corto plazo | El alcance es conocido, el entregable está definido | | Migración de datos | T&M con tope | La calidad de los datos se revela durante el proceso | | Integraciones con sistemas legados | T&M con tope | Depende de la otra parte | | Fase de implementación definida | Precio fijo | Existen criterios de aceptación | | Período de estabilización | Incluido en el precio de la fase | Evita disputas sobre qué es un defecto y qué es un cambio | | Mantenimiento continuo | Retainer | Demanda constante | Una distribución como esta puede parecer más compleja que un solo acuerdo, pero reduce precisamente las discusiones que retrasan los proyectos. ## Ejemplo ilustrativo: Importador de equipos médicos El escenario es hipotético y tiene fines ilustrativos. Un importador solicitó un presupuesto de precio fijo para un proyecto que incluía la integración con un sistema de gestión de inventario de quince años de antigüedad, sin documentación de API. Las tres ofertas recibidas tuvieron un rango muy amplio, y la más económica incluía una pequeña frase: "Asumiendo que existe una interfaz REST disponible". La organización realizó una breve prueba de viabilidad de una semana antes de firmar. Se descubrió que no existía tal interfaz y que se requería una capa intermedia. La prueba cambió el panorama: la integración se movió a un modelo T&M con un tope, y el resto del proyecto se mantuvo a precio fijo. Lo que la breve prueba evitó no fue un costo adicional —que habría surgido de todos modos— sino una disputa contractual a mitad del proyecto sobre quién era responsable de una suposición no verificada. ## Qué influye en el precio más que el modelo de tarifas - **Madurez de la definición** — una especificación incompleta encarece cualquier modelo. - **Número de sistemas de origen** y su nivel de documentación. - **Calidad de los datos** existentes. - **Disponibilidad de los dueños del proceso** en la organización — la demora en las decisiones es un costo directo. - **Número de unidades de negocio** que necesitan llegar a un acuerdo. Cuatro de los cinco puntos están bajo el control de la organización y no del proveedor. Esta es la razón por la que invertir en la preparación reduce el costo de un proyecto más que cualquier negociación sobre la tarifa. ## Del modelo al acuerdo Después de elegir el modelo, lo que importa es la redacción: qué se considerará un entregable completado, quién aprueba y qué sucede si la otra parte se retrasa. Las cláusulas que deben incluirse en el acuerdo se detallan en la [Guía de contratos y SOW para proyectos Salesforce](/es/insights/salesforce-sow-contract-clauses), y la forma de redactar la solicitud para que las ofertas sean comparables se detalla en la [Guía de RFP](/es/insights/salesforce-rfp-guide). La elección del tipo de servicio que se presupuesta inicialmente se detalla en la [Guía de servicios de Salesforce](/es/insights/salesforce-services-guide), y la evaluación del proveedor en la [Guía para elegir una empresa de implementación](/es/insights/choose-salesforce-implementation-company). ## Próximo paso Antes de solicitar un presupuesto, clasifique las tres mayores fuentes de incertidumbre en su proyecto. Si puede nombrarlas, estará listo para un precio fijo para parte del trabajo. Si no puede, lo primero que debe adquirir es una breve verificación para eliminarlas, no un presupuesto para todo el proyecto. ### Preguntas y respuestas **¿Un precio fijo realmente protege el presupuesto en un proyecto Salesforce?** Un precio fijo asegura el costo del alcance definido, no el del proyecto completo. Cuando la definición es parcial, las brechas se cierran mediante solicitudes de cambio, facturadas por separado y, a menudo, a una tarifa más alta. El precio fijo solo protege el presupuesto cuando el documento de alcance es lo suficientemente detallado como para que ambas partes acuerden lo que está incluido y lo que no. **¿Cuándo es preferible el modelo de Tiempo y Materiales (T&M) a un precio fijo?** El modelo de T&M es superior cuando existe una incertidumbre genuina que no puede eliminarse antes del inicio del trabajo; por ejemplo, integraciones con sistemas legacy sin documentación, datos de calidad desconocida, o procesos de negocio en constante evolución. En estas circunstancias, un precio fijo simplemente traslada la incertidumbre a un margen de riesgo que usted pagará, se materialice o no. **¿Qué se suele incluir razonablemente en un Retainer mensual para un entorno Salesforce?** Generalmente, un Retainer cubre mantenimiento, soporte, pequeñas configuraciones, gestión de lanzamientos y monitoreo. El desarrollo de nuevas funcionalidades debería estar fuera del Retainer o con un tope definido. De lo contrario, consumiría las horas destinadas al soporte, creando la percepción de que el proveedor no está disponible. **¿Cómo se previene la inflación de horas en un modelo de Tiempo y Materiales (T&M)?** Mediante tres mecanismos clave: un tope de horas acordado por cada hito con una alerta temprana al aproximarse a dicho límite, un reporte de horas a nivel de tarea en lugar de mensual, y la facultad de la organización de detener el trabajo al final de cada hito. Juntos, estos mecanismos ofrecen un control superior al de un precio fijo, permitiendo ajustes continuos durante el desarrollo del proyecto. **¿Es posible combinar diferentes modelos en un mismo proyecto Salesforce?** Sí, y a menudo es la opción más acertada. Un patrón común es aplicar un precio fijo a la fase de definición, un modelo de Tiempo y Materiales (T&M) con tope para integraciones y migraciones, un precio fijo para los despliegues ya definidos y un Retainer para el soporte post-lanzamiento. Esta segmentación permite alinear cada componente del proyecto con el modelo que mejor se adapte a su nivel de incertidumbre inherente. --- ## ¿Salesforce Flow o Apex? Un marco de decisión para automatizaciones empresariales URL: https://hpi.pro/es/insights/salesforce-flow-vs-apex La elección entre Flow y Apex no depende de la habilidad del equipo, sino de la naturaleza de la lógica: cantidad de registros en la transacción, dependencia de los Governor Limits, necesidad de control transaccional y complejidad de las condiciones. Este artículo, elaborado por HPI Pro, presenta un enfoque de decisión operativo en lugar de otra comparación general de funcionalidades. ## La respuesta breve La pregunta "Flow o Apex" recibe una respuesta errónea cuando se evalúa en función de la facilidad de escritura o la disponibilidad del desarrollador. La respuesta correcta depende de cuatro factores técnicos: cuántos registros pasan en una sola transacción, si la lógica debe tener atomicidad completa, cuán complejas son las condiciones y las ramificaciones, y quién mantendrá el componente dentro de un año. Flow es la opción predeterminada correcta para la mayoría de las automatizaciones de negocio, pero existen puntos de inflexión claros en los que continuar trabajando con Flow crea un riesgo operativo y no solo un "código menos elegante". Este artículo se centra en la decisión de elección misma: cómo identificar de antemano que la lógica justifica Apex, y cómo evitar una situación en la que la elección se hace por defecto y no por un juicio. La cuestión de la limpieza de Flows y procesos de automatización existentes que ya se han acumulado como deuda técnica se discute en un artículo separado y no forma parte de esta discusión. ## Qué diferencia en la práctica a ambos a nivel de plataforma Flow es un motor declarativo que se traduce en tiempo de ejecución a instrucciones que ejecutan DML y SOQL en nombre del usuario, mientras que Apex es un código compilado que se ejecuta bajo los mismos Governor Limits pero con control directo sobre el orden de las operaciones. La primera diferencia práctica es la "bulkificación": un desarrollador de Apex construye explícitamente un bucle que recopila todos los registros en una sola matriz y ejecuta un DML único, mientras que en Flow es fácil construir un bucle que realiza una operación DML o una consulta en cada iteración por separado, un patrón que alcanza el límite de 101 consultas permitidas mucho más rápido. La segunda diferencia es el control de la transacción. Apex permite `Savepoint` y `Database.rollback` para una reversión parcial, manejo de `DmlException` a nivel de registro individual a través de `Database.insert(list, false)`, y lógica condicional compleja sin límite de profundidad de ramificaciones. En Flow, el manejo de errores se define a nivel de "Fault Path" para cada elemento, y esto funciona bien para escenarios lineales pero se vuelve difícil de seguir cuando hay más de unas pocas rutas de fallo paralelas. ## Marco de decisión: Cuatro pruebas antes de elegir una herramienta ### Prueba de volumen Regla general: Si el proceso se ejecuta en un solo registro como resultado de una acción del usuario (creación de un lead, cambio de estado de una oportunidad), Flow es casi siempre suficiente. Si el proceso se ejecuta en decenas o miles de registros a la vez —actualización periódica, procesamiento por lotes que proviene de una integración, limpieza de datos programada— Apex con `Batchable` o `Queueable` es la elección segura, ya que otorga control total sobre la "bulkificación" y la gestión de Governor Limits frente a un volumen cambiante. ### Prueba de atomicidad Debemos preguntar: Si parte de la actualización falla, ¿se permite que la otra parte permanezca guardada? Si la respuesta es "no" —por ejemplo, la actualización de un pedido y la creación de un registro de facturación que deben ocurrir juntas— Apex con Savepoint es la forma correcta de garantizarlo. Flow no proporciona una reversión completa entre elementos sin una construcción manual y compleja de lógica de compensación. ### Prueba de complejidad de ramificaciones Un Flow con más de 6-8 elementos Decision anidados se vuelve difícil de leer y costoso de probar, incluso si cada ramificación individual es simple. Cuando la complejidad de la lógica de negocio excede esto, escribir la misma lógica como una función Apex documentada con pruebas unitarias (`@isTest`) suele ser más económico de mantener, incluso si el tiempo de escritura inicial es mayor. ### Prueba de mantenimiento y propiedad Debemos preguntar quién mantendrá el componente dentro de un año, no quién lo construye ahora. Si es el equipo de Admin quien tendrá que actualizar las reglas de negocio de forma rutinaria —como cambiar las condiciones de descuento o los umbrales— Flow es preferible incluso si Apex es técnicamente "más limpio", porque es accesible para actualizar sin un ciclo de implementación. Si los cambios requieren conocimiento del esquema de datos y pruebas de regresión, Apex es la elección correcta incluso si solo hay un pequeño equipo de desarrollo que lo mantendrá. ## Tabla de decisión | Criterio | Elegir Flow | Elegir Apex | | --- | --- | --- | | Volumen de registros en una sola transacción | Hasta unas pocas decenas | Cientos a miles | | Requisito de atomicidad entre varios objetos | No crítico | Crítico — se requiere reversión completa | | Número de ramas de decisión | Hasta 6-8 aproximadamente | Más de esto, o lógica recursiva | | Frecuencia de cambio de las reglas de negocio | Frecuente, por Admin | Rara, requiere pruebas de regresión | | Necesidad de llamar a una API externa compleja | Llamada única sencilla (HTTP Callout) | Lógica de reintento, autenticación compleja o por lotes | | Requisito de pruebas automáticas (CI) | Limitado | Completo, `@isTest` con Coverage | | Integración con un trabajo programado fijo | No es directamente adecuado | Natural a través de `Schedulable` | ## Escenario de ejemplo: Empresa de equipos médicos con proceso de aprobación de pedidos Una empresa de equipos médicos mediana con aproximadamente 40 representantes de ventas implementó un Flow para el proceso de aprobación de pedidos: verificación de inventario, cálculo de descuento, creación de un registro de aprobación y envío de una notificación al gerente. Al principio, funcionó bien para pedidos individuales. Después de seis meses, se añadió un nuevo escenario: la importación de pedidos por lotes desde un archivo de integración con el ERP, que creaba entre 200 y 800 pedidos simultáneamente. El Flow, que se activaba a través de un Record-Triggered Flow a nivel "por registro", realizaba una consulta de verificación de inventario dentro de cada ejecución por separado. Con la importación de 500 pedidos, el sistema superó el límite de 100 consultas en una sola transacción y los pedidos fallaron sin un mensaje de error claro para el usuario. El equipo identificó que el problema no estaba en el Flow en sí, sino en la adaptación entre un proceso diseñado para un solo registro y un escenario de volumen que no existía en el momento de la construcción. La solución no fue descartar el Flow. El equipo dividió la lógica: Flow se mantuvo responsable del proceso manual de un solo pedido (la prueba de volumen era baja, era necesario que el Admin actualizara frecuentemente las reglas de descuento), mientras que el proceso de importación por lotes se transfirió a un Apex Batch Job que realiza una "bulkificación" completa, verifica el inventario en una única consulta centralizada y ejecuta un DML único para todos los registros. Ambos mecanismos llaman a la misma capa de lógica de negocio compartida (una Apex Class a la que también se accede desde el Flow a través de un Invocable Method), para que la regla de descuento no se mantenga dos veces. ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Flow en un volumen que crece gradualmente | El proceso funcionó durante seis meses y luego falló silenciosamente debido a los Governor Limits | Evaluar el volumen esperado a un año y planificar un punto de transición a Apex antes de alcanzar el límite | | Duplicidad de lógica de negocio en Flow y Apex | Dos lugares calculan el descuento de manera diferente | Centralizar el cálculo de negocio en una capa Apex compartida a la que también acceda Flow | | Orden de Trigger inesperado | Varios Flows y Triggers en el mismo objeto entran en conflicto | Un único `Trigger Handler` central en Apex para cada objeto crítico | | Manejo parcial de errores en Flows complejos | Parte de los registros se actualizan y parte no, sin visibilidad | Mover procesos que requieren atomicidad a Apex con `Savepoint` | | Apex sin pruebas suficientes | Un pequeño cambio rompe un proceso crítico en la siguiente implementación | Exigir un `Coverage` real y no solo un porcentaje formal, incluyendo escenarios de fallo | ## Lista de verificación para la decisión antes de construir - ☐ Se ha verificado el volumen esperado a un año, no solo el estado actual. - ☐ Se ha definido si el proceso requiere atomicidad entre varios objetos. - ☐ Se ha contado el número esperado de ramas de decisión en la lógica. - ☐ Se sabe quién mantendrá el componente y con qué frecuencia cambiarán las reglas. - ☐ Se ha verificado si ya existe una lógica similar en Apex o en otro Flow en el mismo objeto. - ☐ Se ha definido el `Trigger Order` si hay varios mecanismos de automatización en el objeto. - ☐ Si se eligió Apex — se han definido escenarios de prueba, incluyendo fallos parciales. - ☐ Si se eligió Flow — se ha definido un `Fault Path` para cada elemento crítico. ## Cómo se conecta esto con la arquitectura más amplia La elección de la herramienta correcta para una automatización individual es solo una capa dentro de una imagen más amplia de la [arquitectura de CRM](/es/insights/crm-architecture-guide), donde tanto el modelo de datos como los permisos afectan a lo que Flow o Apex pueden siquiera tocar. Cuando la automatización cruza una frontera hacia una organización externa, por ejemplo, la verificación de inventario contra un ERP en tiempo real, la elección entre Flow y Apex también se integra en las consideraciones de [patrones de integración](/es/insights/salesforce-integration-patterns) y en la cuestión de cómo [Salesforce se conecta a un ERP](/es/insights/salesforce-erp-integration) en términos de latencia y manejo de fallos. En organizaciones que operan varias organizaciones (orgs), también es necesario verificar si la lógica de negocio es idéntica en todas ellas, un tema que se discute en la [guía de Single Org frente a Multi Org](/es/insights/salesforce-single-org-vs-multi-org) y que influye en la cuestión de si vale la pena centralizar la lógica en un Apex Package compartido. ## Resumen La elección entre Flow y Apex no es una cuestión de habilidad del equipo o preferencia personal, sino el resultado de cuatro pruebas técnicas: volumen, atomicidad, complejidad de las ramificaciones y frecuencia de cambio. Flow es la opción predeterminada correcta para la mayoría de las automatizaciones que afectan a un solo registro y cambian con frecuencia. Apex es necesario cuando hay un volumen significativo, cuando se necesita un control total sobre la transacción, o cuando la complejidad lógica supera un umbral que aún puede mantenerse a través de una interfaz declarativa. Una organización que institucionaliza estas pruebas como parte del proceso de trabajo —y no las deja al juicio ad-hoc de cada desarrollador— ahorra la mayoría de los casos en los que una automatización que funcionó bien al principio se rompe silenciosamente cuando el volumen aumenta. ### Preguntas y respuestas **¿Es posible comenzar con Flow y luego migrar a Apex sin interrumpir el proceso?** Generalmente sí, si el Flow se construye en torno a un evento empresarial claro y no a una pantalla específica. Cuando el Flow invoca un proceso a través de una acción invocable o un subflujo, es posible reemplazar la implementación interna con Apex sin afectar el activador, los permisos o la interfaz. La dificultad surge cuando el Flow y la lógica de negocio están intrínsecamente entrelazados; en ese caso, cualquier cambio exige una reconstrucción, no una refactorización. **¿Puede Flow manejar la actualización masiva de miles de registros simultáneamente?** Técnicamente sí, pero en la práctica depende de la carga de lógica dentro del bucle. Un Flow que ejecuta una consulta SOQL o DML dentro de un bucle para cada registro podría alcanzar los Governor Limits mucho antes que su equivalente en Apex, ya que el motor de Flow no siempre realiza la 'bulkificación' automática con la misma eficiencia. Para actualizaciones masivas recurrentes, Apex con Batch o Queueable es la opción más segura y escalable. **¿Qué sucede cuando hay múltiples Flows y Triggers en el mismo objeto?** El orden de ejecución está determinado por las configuraciones de Salesforce y no siempre por la intención del equipo, lo que puede llevar a resultados inesperados cuando varios mecanismos interactúan con el mismo registro. La solución es centralizar toda la lógica automática de un objeto clave alrededor de un único 'Trigger Handler' en Apex y utilizar Flow solo para procesos que no entren en conflicto con la lógica crítica. En HPI Pro, somos expertos en diseñar arquitecturas robustas para evitar estos conflictos. **¿Cuándo se debe escribir Apex incluso si Flow es técnicamente suficiente?** Cuando la lógica implica una transacción única que debe completarse o fallar en su totalidad, por ejemplo, la actualización de dos objetos relacionados que no deben permanecer desincronizados. Flow maneja los errores a nivel de elemento individual y no siempre garantiza una atomicidad completa, mientras que Apex permite 'Savepoints' y 'Rollbacks' controlados para asegurar la integridad de la transacción. **¿Es Apex siempre más costoso de mantener que Flow?** No necesariamente. Un Flow complejo con docenas de ramas de decisión, subflujos anidados y lógica oculta en 'Formula Fields' puede ser más difícil de diagnosticar que un Apex bien documentado con pruebas unitarias. El costo dependerá del alcance de la lógica y la calidad de la documentación, no de la herramienta en sí. En HPI Pro, priorizamos soluciones claras y sostenibles, independientemente de la tecnología. --- ## ¿Real-Time, Batch o Event-Driven? Elija el patrón de integración ideal para Salesforce URL: https://hpi.pro/es/insights/salesforce-integration-patterns La elección incorrecta de un patrón de integración no se manifiesta en las demostraciones de venta, sino cuando la carga de trabajo aumenta, un sistema externo falla por unos minutos o dos usuarios actualizan el mismo cliente simultáneamente. Esta guía presenta un marco de decisión basado en solo tres preguntas clave: la velocidad de respuesta requerida, la fuente de la verdad para los datos y qué ocurre ante un fallo del sistema. ## Tres preguntas que definen el patrón, no la herramienta El error más común al seleccionar una integración para Salesforce es comenzar por la herramienta: MuleSoft, Platform Events, Bulk API o un simple Webhook. La herramienta es una consecuencia, no un punto de partida. Tres preguntas clave determinan el patrón adecuado: 1. **¿Qué tan rápido necesita saber la otra parte?** Un segundo, un minuto, una hora o un día: esta es la diferencia entre Real-Time y Batch. 2. **¿Quién es el propietario del dato en cada momento?** Si la respuesta no es inequívoca, ningún patrón técnico resolverá el problema. 3. **¿Qué sucede cuando la otra parte no está disponible?** Una respuesta como "esperaremos de nuevo" no es una respuesta; se necesita un comportamiento definido: Retry, cola o fallo explícito. Quien responde estas tres preguntas antes de seleccionar una tecnología, casi siempre llega a la misma conclusión a la que llegaría un arquitecto experimentado, pero sin incurrir en costos de prueba y error en producción. Una ampliación sobre la conexión entre esta decisión y la arquitectura general se encuentra en la [Guía de Arquitectura CRM](/es/insights/crm-architecture-guide). ## Mapa de Patrones: Cuándo es adecuado cada uno | Patrón | Tiempo de respuesta típico | Ejemplo de uso típico | Costo de mantenimiento | Riesgo principal | | :------------------------------ | :--------------------- | :---------------------------------------------------------------- | :-------------------- | :------------------------------------------------------ | | Request-Reply síncrono | Milisegundos a segundos | Verificación de crédito antes de aprobar una transacción en pantalla | Moderado | Un Timeout bloquea al usuario | | Fire-and-Forget | Inmediato en el envío, sin esperar resultado | Envío de un evento para crear una Tarea en otro sistema | Bajo-Moderado | Fallo silencioso sin monitoreo | | Batch periódico | Horas a un día | Sincronización diaria del catálogo de productos desde el ERP | Bajo | Discrepancias temporales entre sistemas | | CDC (Change Data Capture) | Segundos a minutos | Actualización del estado de un pedido que afecta al soporte | Moderado-Alto | Carga en el Event Bus con múltiples cambios | | Event-Driven (Platform Events / Pub-Sub) | Segundos | Notificación de un evento de negocio a varios consumidores simultáneamente | Alto en el setup, bajo en mantenimiento | Requiere disciplina de Schema y Versioning | La tabla es un punto de partida para la discusión, no una decisión final. Un sistema puede, y a veces debe, utilizar varios patrones en paralelo según el tipo de dato. ## Por qué la latencia no es suficiente para decidir El segundo error común: decidir únicamente por la latencia e ignorar la consistencia. Un patrón rápido que actualiza solo una parte y deja a la otra "casi sincronizada" genera un problema más grave que un patrón lento pero consistente, porque los usuarios aprenden a no confiar en el dato y, en consecuencia, eluden el sistema. La pregunta correcta es doble: ¿qué tan rápido se requiere la respuesta **y cuán grave** es una situación en la que ambas partes no están sincronizadas por un momento? Un proceso de cotización presentado a un cliente requiere tanto velocidad como consistencia total; aquí se necesita un Request-Reply síncrono con un Timeout definido y un manejo explícito de fallos. La actualización del "número de vistas de un artículo" puede permitirse un retraso de minutos; en este caso, Fire-and-Forget o CDC son suficientes. ## Propiedad de los datos: Una decisión que precede a cualquier patrón Antes de elegir cómo se transfieren los datos entre los sistemas, es fundamental decidir dónde reside el "dato fuente". Un campo que se actualiza en dos sistemas sin un propietario definido crea un bucle de sincronización: A envía a B, B actualiza y retransmite a A, A envía de nuevo. Esto no es un escenario extremo; es el resultado esperado de una sincronización bidireccional sin reglas de resolución. Una regla de trabajo práctica: a cada campo compartido se le asigna un único propietario (Owner). Si existe una necesidad empresarial real de edición desde ambas partes (por ejemplo, el servicio de atención al cliente actualiza una dirección tanto en Salesforce como en el ERP), se agrega una regla de Conflict Resolution explícita: el último Timestamp prevalece, o un campo determina y el otro es solo para visualización. La gestión de permisos en torno a estos campos sensibles se aborda en la [Guía del Modelo de Permisos en Salesforce](/es/insights/salesforce-permission-model). ## Manejo de fallos: La prueba que la mayoría de los proyectos omiten Casi todas las integraciones se prueban en el "Happy Path". Pocas realizan una prueba sistemática de los siguientes tres escenarios de fallo: - **El segundo sistema no está disponible en el momento del envío** ¿El mensaje se guarda en una cola y se reenvía, o se pierde? - **El mensaje llega dos veces** (problema común en Retry automático y en el Event Bus) ¿El receptor crea un registro duplicado? - **El mensaje llega en un orden incorrecto** ¿La actualización del estado "cancelado" que llega antes que "aprobado" causa un resultado erróneo? Un sistema que no está construido como Idempotente (identificador único para cada mensaje + verificación si ya fue procesado) fallará precisamente en los dos primeros escenarios, y generalmente bajo carga, es decir, justo cuando el negocio más depende de él. Las limitaciones de la API y cómo lidiar con el Throttling en este contexto se detallan en la [Guía de Salesforce API Limits](/es/insights/salesforce-api-limits-resilience). ## Marco de decisión: De la pregunta de negocio al patrón | Pregunta inicial | Si la respuesta es "Sí" | Si la respuesta es "No" | | :------------------------- | :------------------------------------------------------- | :-------------------------------------------- | | ¿El usuario está esperando en pantalla el resultado de la integración? | Request-Reply síncrono con Timeout definido | Pasamos a la siguiente pregunta | | ¿Se requiere una actualización en pocos minutos de un cambio específico? | CDC o Platform Event | Pasamos a la siguiente pregunta | | ¿Varios consumidores diferentes necesitan conocer el mismo evento? | Event-Driven con Pub-Sub | Pasamos a la siguiente pregunta | | ¿Es conveniente procesar un gran volumen en una ventana de tiempo fija? | Batch periódico | Considerar Fire-and-Forget con cola | Este es un punto de partida para la discusión en una reunión de arquitectura, no una fórmula exhaustiva. Siempre existen casos límite (por ejemplo, un volumen masivo que requiere CDC pero también una reconciliación Batch diaria como red de seguridad). ## Escenario de ejemplo: Cadena de clínicas privadas con veinte sucursales Supongamos una cadena de clínicas que utiliza Salesforce para la gestión de solicitudes de pacientes y un sistema de facturación separado (Billing) que, por el momento, no puede ser reemplazado. El requisito: cuando un paciente completa una cita, el sistema de facturación debe actualizarse inmediatamente, y cuando una facturación se actualiza (por ejemplo, se recibe un pago), Salesforce debe reflejarlo para que el representante de servicio no solicite un pago duplicado. La elección inicial del equipo fue un Batch nocturno bidireccional, simple de configurar, pero que generó una brecha de hasta 24 horas en la que los representantes veían información desactualizada, lo que provocó quejas. La solución finalmente adoptada: una dirección (finalización de cita desde Salesforce a facturación) pasó a Fire-and-Forget con una cola de mensajes y Retry automático, ya que el usuario no necesita esperar. La otra dirección (confirmación de pago desde facturación a Salesforce) pasó a CDC, ya que se trata de un cambio puntual que debe llegar en minutos. El Batch nocturno se mantuvo solo como un mecanismo de Reconciliación: una comparación diaria que detecta discrepancias y emite alertas, no como el canal de actualización principal. El resultado: el tiempo de actualización se redujo de horas a minutos, y el mecanismo de Reconciliación detectó dos casos de mensajes perdidos en el primer mes, cumpliendo exactamente su función. ## Riesgos y acciones preventivas específicas para la integración | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | :-------------------------- | :------------------------------------------------ | :---------------------------------------------------------- | | Falta de Idempotencia | Registros duplicados después de Retry o fallas de red | Identificador único para el mensaje + verificación antes de crear | | Fuente de verdad indefinida | Bucle de sincronización o actualización "ganadora" aleatoria | Propietario definido para cada campo + regla de Conflict Resolution | | Point-to-Point sin capa de integración | Cualquier cambio de esquema en un sistema rompe otra conexión | Capa de Middleware/API con contrato de versiones explícito | | Monitoreo solo técnico | La integración está "en verde" pero faltan pedidos en la práctica | Métrica de Reconciliation de negocio, no solo Uptime técnico | | Ignorar Governor Limits | La integración colapsa precisamente bajo carga máxima | Planificación de Bulkification y Backoff de antemano, no como reacción | ## Checklist para la selección del patrón de integración - ☐ Se definió el tiempo de respuesta requerido en números, no con la palabra "rápido". - ☐ Se definió un único Owner para cada campo compartido entre los sistemas. - ☐ Se verificó qué sucede cuando la otra parte no está disponible, y se documentó. - ☐ Se verificó qué sucede cuando un mensaje llega dos veces. - ☐ Se verificó qué sucede cuando los mensajes llegan en un orden incorrecto. - ☐ Existe un mecanismo de Reconciliation incluso cuando el patrón principal es asíncrono. - ☐ Las limitaciones de la API y los Governor Limits se verificaron contra el volumen esperado bajo carga máxima. - ☐ Se definieron métricas de éxito de negocio, no solo métricas técnicas. ## Métricas para el monitoreo continuo de la integración Después del lanzamiento, es recomendable monitorear solo tres o cuatro métricas: el porcentaje de mensajes exitosos en el primer intento, el tiempo de extremo a extremo real frente al SLA definido, las diferencias diarias de Reconciliation entre los sistemas y la proximidad a los límites de la API. Un aumento constante en cualquiera de ellos –y no solo una desviación puntual– es la señal para considerar la transición a otro patrón, antes de que el sistema falle en producción. Las consideraciones de identidad y permisos de acceso entre sistemas se detallan en la [Guías de SSO e Identidad en Salesforce](/es/insights/salesforce-sso-identity-architecture). ## Resumen La selección de un patrón de integración adecuado no comienza con la pregunta "¿qué herramienta?", sino con tres preguntas: ¿qué tan rápido se necesita una respuesta?, ¿quién es el propietario del dato? y ¿qué sucede cuando algo falla? Real-Time es apropiado cuando un usuario espera un resultado; CDC y Event-Driven son adecuados para la actualización rápida de un cambio específico o para la distribución a varios consumidores; Batch es idóneo para grandes volúmenes en una ventana de tiempo fija. En cada patrón, la Idempotencia, la propiedad definida de los datos y un mecanismo de Reconciliation no son "deseables", son la condición para que la integración soporte una carga real y no solo una demostración. ## Recursos profesionales - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Arquitectura CRM — https://hpi.pro/crm-architecture - HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Cuál es la diferencia práctica entre 'Fire-and-Forget' y 'Request-Reply' en la integración de Salesforce?** En 'Request-Reply', el sistema de origen espera una respuesta y recibe confirmación inmediata del éxito o fallo de la operación, ideal cuando un usuario necesita un resultado para continuar con su tarea. En 'Fire-and-Forget', el remitente continúa inmediatamente y la respuesta, si existe, llega de forma asíncrona, adecuado para actualizaciones que no bloquean un proceso humano. Una elección incorrecta puede causar que los usuarios esperen a un sistema que no fue diseñado para ello, o que se pasen por alto fallos silenciosos. **¿Cuándo es preferible CDC sobre el procesamiento por lotes periódico para la sincronización de datos?** La Captura de Datos Cambiados (CDC) es preferible cuando el volumen de cambios es pequeño en relación con el volumen total de datos y cuando los cambios deben reflejarse en minutos, no en horas (por ejemplo, una actualización de estado de pedido que impacta el servicio al cliente). El procesamiento por lotes (Batch) es más adecuado cuando es conveniente procesar un gran volumen de datos en una ventana de tiempo regular, cuando la fuente no soporta un flujo de eventos o cuando el procesamiento en sí requiere cálculos sobre un conjunto completo de registros y no sobre un cambio individual. **¿Cómo se maneja la duplicidad de mensajes en una integración basada en eventos?** Se asume que cada mensaje puede llegar más de una vez y se diseña el lado receptor para ser idempotente: esto implica asignar un identificador único a cada mensaje, verificar si ya ha sido procesado antes de realizar la acción y guardar el resultado para que una ejecución repetida no cree un registro duplicado ni actualice dos veces. Confiar en que 'el mensaje llegará solo una vez' es una suposición que a menudo se rompe bajo carga o fallos de red. **¿Quién es el propietario de la verdad cuando el mismo campo se actualiza tanto en Salesforce como en un sistema externo?** Es crucial definir de antemano qué sistema es el propietario del campo y documentarlo en el contrato de integración, no solo en la memoria del equipo. Una actualización bidireccional sin un propietario definido crea bucles de sincronización y un resultado final dependiente del momento de la actualización. Cuando existe una necesidad real de edición desde ambos lados, se requiere una regla explícita de resolución de conflictos, por ejemplo, 'la última actualización prevalece' según la marca de tiempo, en lugar de suponer que esta situación no ocurrirá. **¿Cómo saber si un patrón de integración elegido sigue siendo adecuado después de que la carga de trabajo se ha multiplicado por diez?** Se deben verificar tres aspectos: si el tiempo de procesamiento aún cumple con el SLA definido, si la tasa de fallos y reintentos ha excedido el umbral preestablecido, y si los límites de la API de Salesforce (como los Governor Limits o las llamadas a la API) se están acercando a su capacidad máxima. Un aumento en cualquiera de estas métricas es una señal para considerar la transición de Batch a CDC, la adición de colas de mensajes (queuing), o la división en procesos paralelos, antes de que el sistema falle en producción. --- ## Modelo de Permisos en Salesforce: ¿Cómo Diseñar un Acceso Seguro sin Excederse? URL: https://hpi.pro/es/insights/salesforce-permission-model La mayoría de las organizaciones construyen modelos de permisos de arriba hacia abajo: primero un perfil amplio y luego ajustes individuales hasta que nadie recuerda por qué un usuario tiene cierto acceso. El enfoque correcto es el opuesto: un perfil restringido para acceso básico y Permission Set Groups que componen la capacidad de trabajo según el rol. Este artículo presenta esto como un marco operativo. ## La pregunta fundamental: ¿Qué determina el acceso de un usuario? Cuando alguien pregunta "¿cómo obtuvo un usuario acceso a este campo?", la respuesta correcta es casi siempre una combinación: su Profile determina el acceso base, los Permission Set Groups asignados añaden capacidades según la función, y a veces un Permission Set individual gestiona una excepción específica. El problema en la práctica es que la mayoría de las organizaciones construyen esta combinación en la dirección opuesta, comenzando con un Profile amplio que contiene casi todo, y luego "solucionando" problemas puntuales con permisos individuales que nadie recuerda eliminar. Un modelo de permisos saludable se construye en la dirección opuesta: un Profile lo más restringido posible, que defina principalmente la licencia, el acceso predeterminado a las aplicaciones y las características de inicio de sesión; y toda capacidad de trabajo real –qué objetos, qué campos, qué acciones– se traslada a los Permission Sets y Permission Set Groups. Es importante aclarar: este artículo aborda únicamente el nivel de Object, Field y System Permissions. Las cuestiones de visibilidad de los registros entre usuarios (OWD, Role Hierarchy, Sharing Rules) se discuten en la [Guía de Visibilidad y Compartición](/es/insights/crm-architecture-guide), ya que se trata de una capa de decisión separada con sus propias compensaciones (trade-offs). ## Las tres unidades y su función | Unidad | Qué determina | Cuántas puede tener un usuario | Cuándo se elige | | --- | --- | --- | --- | | Profile | Licencia, App Visibility predeterminada, Page Layout, Login Hours/IP | Exactamente uno | Diferencias de infraestructura entre tipos de usuarios | | Permission Set | Permisos de Objeto, Campo, Apex Class, Pestaña (Tab) - solo añade | Tantos como sea necesario | Una única capacidad relevante para algunas funciones | | Permission Set Group | Agrupación de varios Permission Sets bajo un nombre, con opción de Muting | Tantos como sea necesario | Una combinación fija de permisos que representa un rol de trabajo completo | La diferencia entre un Permission Set y un Permission Set Group no es solo técnica, es organizacional. Un Permission Set individual es adecuado para una capacidad única y específica ("acceso a informes financieros"). Un Permission Set Group es adecuado cuando se quiere asignar un "paquete de trabajo" completo a un departamento o a una función, y mantenerlo en un solo lugar cuando cambie. ## Marco de decisión: ¿Dónde pertenece un nuevo permiso? Cuando surge una solicitud para añadir acceso, la primera pregunta no es "¿a qué Profile añadir?" sino a qué unidad pertenece el permiso desde una perspectiva estructural: 1. **¿Es un permiso que caracteriza a todos los que tienen el mismo tipo de licencia?** Si es así, es un lugar para el Profile, siempre que se refiera a todos los titulares de la licencia y no a un subconjunto. 2. **¿Es una capacidad de trabajo que un grupo de rol específico siempre necesita junto con permisos adicionales?** Si es así, es un lugar para el Permission Set Group, incluso si primero hay que dividirlo en varios Permission Sets separados para permitir una combinación flexible. 3. **¿Es un permiso puntual y temporal para un usuario individual o una excepción?** Si es así, un Permission Set independiente, asignado manualmente y revisado en la auditoría periódica. 4. **¿Debe el permiso negar algo a un usuario específico dentro de un grupo amplio?** Aquí entra un Muting Permission Set dentro de un Permission Set Group, la única herramienta en Salesforce que permite reducir un permiso sin tocar el Profile o desagrupar el grupo. La regla que previene la mayor parte de la "deriva": nunca se edita un Profile para resolver un problema de un solo usuario. Si la corrección se define como una excepción, pasa por un Permission Set documentado y con fecha de revisión. ## Lista de verificación para construir un modelo de permisos desde cero * ☐ Se han mapeado las funciones de trabajo reales (no los departamentos organizacionales) y cada función ha recibido un nombre claro. * ☐ Para cada función, se ha definido una lista de capacidades requeridas a nivel de objeto, campo y Apex Class. * ☐ Se han construido Permission Sets enfocados en una única capacidad, no "pilas de permisos" genéricas. * ☐ Cada función ha recibido un único Permission Set Group que agrupa las capacidades relevantes. * ☐ Los Profiles se han reducido a meras diferencias de licencia e infraestructura. * ☐ Se ha definido un proceso para casos excepcionales: quién aprueba un Permission Set puntual y por cuánto tiempo. * ☐ Se ha establecido una frecuencia de auditoría (trimestral al menos) que compara los permisos activos con la función actual. * ☐ Se ha definido un único propietario para el mantenimiento del modelo de permisos frente a los cambios en la estructura organizacional. ## Escenario organizacional: Una compañía de seguros con tres unidades de ventas Consideremos una compañía de seguros mediana con unos trescientos usuarios de Salesforce, divididos en tres unidades: ventas directas, ventas a través de agentes y reclamaciones. Antes del proyecto, la compañía tenía doce Profiles diferentes, algunos de ellos copias casi idénticas creadas para "corregir" un permiso para un grupo pequeño. Resultado típico: cuando un nuevo agente se incorporaba, nadie sabía con certeza cuál de los doce Profiles era el adecuado para él, y la respuesta en la práctica era "copie de alguien similar". El equipo de arquitectos reconstruyó el modelo: solo tres Profiles, según el tipo de licencia (Sales Cloud completo, Community para agentes externos, Service Cloud para reclamaciones). Sobre ellos, siete Permission Set Groups según la función de trabajo real: representante de ventas, gerente de equipo de ventas, agente externo, gerente de agentes, evaluador de reclamaciones, gerente de reclamaciones, y un rol de puente que maneja tanto ventas como reclamaciones. Cada Permission Set Group se compuso de Permission Sets específicos como "acceso a pólizas activas" o "aprobación de reembolso hasta un límite definido", de modo que pudieran combinarse de nuevo al surgir un nuevo rol sin construir el permiso desde cero. El resultado medible: el tiempo de configuración de un nuevo usuario se redujo de varios días (que incluían la verificación manual de qué Profile era el adecuado) a unas pocas horas, y el número de solicitudes de soporte del tipo "no tengo acceso al campo X" se redujo a la mitad en el trimestre posterior a la transición, ya que la mayoría de estas solicitudes se debían a un Profile que no incluía la capacidad y no estaba claro a quién recurrir para la corrección. ## Riesgos comunes y acciones de prevención | Riesgo | Cómo se ve en la práctica | Acción de prevención | | --- | --- | --- | | El Profile se convierte en una herramienta de corrección puntual | Multiplexidad de Profiles casi idénticos, cada uno para un grupo pequeño | Trasladar cada permiso puntual a un Permission Set y reducir los Profiles solo a la licencia | | Seguridad a nivel de campo (FLS) inconsistente | El mismo campo está expuesto en un lugar y bloqueado en uno paralelo | Documentar una matriz de FLS central para cada campo sensible y revisarla en cada Release | | Los permisos "se mantienen adheridos" después de un cambio de función | Un usuario que cambió de función mantiene los permisos del rol anterior | Un proceso de Offboarding de función que elimina el Permission Set Group antiguo antes de añadir uno nuevo | | Permisos de sistema demasiado amplios (View All Data, Modify All) | Se otorgan "para ahorrar tiempo" y no se eliminan después | Aprobación específica y fecha de vencimiento para cada permiso de sistema amplio | | Ausencia de un propietario para el modelo de permisos | Cada equipo añade permisos sin una visión integral | Un único propietario que aprueba cada nuevo Permission Set o Group antes de la implementación | ## Métricas para evaluar la salud del modelo | Área | Qué se mide | Frecuencia de revisión | | --- | --- | --- | | Redundancia innecesaria | Número de Profiles activos en relación con el número de tipos de licencia reales | Trimestral | | Precisión del permiso | Porcentaje de usuarios cuyos permisos coinciden con el rol registrado en RR.HH. | Trimestral | | Excepciones abiertas | Número de Permission Sets puntuales sin fecha de revisión | Mensual | | Permisos amplios | Número de usuarios con View All Data / Modify All Data sin justificación documentada | Mensual | | Tiempo de configuración | Tiempo promedio desde la solicitud de nuevo acceso hasta la asignación completa | Continuo | En una primera versión de seguimiento, conviene limitarse a tres métricas de las cinco y ampliarlas solo después de tener una línea de base fiable. Una métrica que no tiene propietario ni fecha de revisión tiende a desaparecer del informe después del primer mes. ## Cómo se integra esto en la arquitectura más amplia Un buen modelo de permisos es una condición previa, no un sustituto, para la planificación de la visibilidad de los registros (OWD, Role Hierarchy, Sharing Rules); ambos temas se complementan pero se resuelven por separado. Una organización que intenta resolver un problema de visibilidad ampliando un Profile, o viceversa, suele descubrir que la solución es frágil en cuanto cambia la estructura organizativa. Cuando la organización transita entre múltiples Orgs y un solo Org, el modelo de permisos es una de las cosas que deben remapearse; se encuentra una ampliación sobre el tema en la [Guía Single Org frente a Multi Org](/es/insights/salesforce-single-org-vs-multi-org). Y cuando el permiso en sí depende de una lógica condicional compleja, conviene examinar si la implementación pertenece a Flow o a Apex, como se detalla en la [Guía Flow frente a Apex](/es/insights/salesforce-flow-vs-apex). En organizaciones que ejecutan procesos basados en eventos entre sistemas, es crucial asegurarse de que los permisos de los usuarios de integración (Integration Users) se construyan bajo el mismo principio: Permission Sets específicos y no un Profile amplio con "System Administrator" como predeterminado de conveniencia. Este tema se conecta con la planificación más amplia de la comunicación entre sistemas, descrita en la [Guía de Arquitectura Orientada a Eventos para Salesforce](/es/insights/salesforce-event-driven-architecture). ## Resumen Un modelo de permisos que resiste la prueba del tiempo se construye de abajo hacia arriba: capacidades específicas en Permission Sets, su ensamblaje según el rol de trabajo real en Permission Set Groups, y un Profile que mantiene un rol mínimo de licencia e infraestructura solamente. La señal clara de un fallo es la proliferación de Profiles creados para resolver problemas puntuales; cada Profile adicional de este tipo es una deuda que se acumula hasta que nadie recuerda por qué existe. Cuando falta la capacidad interna para construir o limpiar un modelo existente, el [servicio de arquitectura de CRM](/es/crm-architecture) ofrece una ruta práctica para un inicio enfocado. ### Preguntas y respuestas **¿Cuál es la diferencia práctica entre un Profile y un Permission Set?** Cada usuario tiene exactamente un único Profile, que define aspectos que van más allá del permiso habitual, como la visibilidad predeterminada de la aplicación, la asignación de Page Layout, las horas de inicio de sesión y los rangos de IP. Un Permission Set es un complemento que solo añade acceso y nunca lo restringe. La conclusión de diseño es: se le asigna al Profile un rol mínimo, y la mayoría de las diferencias entre usuarios se construyen con Permission Sets. **¿Cuándo se agrupan varios Permission Sets en un único Permission Set Group?** Cuando un grupo de usuarios, por ejemplo, un 'representante de servicio al cliente senior', requiere siempre la misma combinación fija de permisos provenientes de varios Permission Sets separados (acceso a casos, acceso a reembolsos, acceso a la base de conocimientos). La unificación en un grupo evita la asignación manual repetitiva y minimiza errores donde un usuario solo recibe una parte de la combinación requerida para su rol. **¿Puede un Permission Set revocar un permiso existente en un Profile?** No. Los permisos en Salesforce son exclusivamente aditivos: un Permission Set añade, nunca restringe. Si necesita revocar el acceso a un usuario específico sin afectar a otros, la solución es un Muting Permission Set dentro de un Permission Set Group, no la edición de su Profile. **¿Cuántos Profiles debería tener una organización de tamaño mediano?** No hay un número único, pero una regla general útil es: el número de Profiles debe reflejar las diferencias de licenciamiento e infraestructura (tipo de licencia, acceso predeterminado a la aplicación), no las diferencias de permiso entre roles. Una organización con docenas de Profiles casi siempre los usa para compensar la falta de Permission Set Groups organizados. **¿Cómo se verifica que un permiso añadido no se mantenga activo más allá de lo necesario?** Mediante un Permission Set asignado por un período limitado (un Permission Set License con fecha de caducidad cuando sea relevante, o un proceso de auditoría trimestral) en lugar de un permiso permanente. Además, se ejecuta un informe periódico que compara los permisos activos con el rol actual en la tabla de RRHH y se marcan las anomalías para su revisión. --- ## ¿Un Org de Salesforce o un Multi-Org? Consideraciones para organizaciones multiunidades URL: https://hpi.pro/es/insights/salesforce-single-org-vs-multi-org La arquitectura Multi-Org no nace de una única decisión, sino de la acumulación de unidades de negocio, regulaciones y modelos de datos que no encajan en el mismo espacio. Este artículo presenta una prueba de tres preguntas para verificar la verdadera necesidad, una matriz comparativa de costo-beneficio, y una ruta escalonada para aquellos que ya están en camino de una división. ## Las tres preguntas clave para determinar si requiere un entorno Multi-Org El error común es abordar la pregunta "¿un solo Org o varios?" como si fuera una cuestión técnica de capacidad o rendimiento. En la mayoría de los casos, la respuesta técnica existe dentro de un solo Org: los Record Types, Profiles, Permission Sets y Sharing Rules son suficientes para separar unidades de negocio sin dividir el entorno en sí. Salesforce soporta a decenas de miles de usuarios y millones de registros en un Org individual — la capacidad casi nunca es la verdadera razón para una división. La pregunta que realmente importa es la de la autonomía organizacional, y se desglosa en tres pruebas: 1. **Autonomía regulatoria genuina** — ¿Existe un requisito legal o contractual para la separación física de datos (por ejemplo, una entidad legal separada con regulación local que prohíbe compartir infraestructura), a diferencia de una separación lógica que se puede lograr con el Sharing Model? 2. **Ritmo de cambio incompatible** — ¿Una unidad de negocio requiere ciclos de lanzamiento frecuentes y rápidos, mientras que otra exige máxima estabilidad y una auditoría estricta, de modo que cada lanzamiento compartido se convierte en un punto de fricción constante entre los equipos? 3. **Modelo de datos que colisiona**, no solo difiere — cuando una misma entidad (por ejemplo, "cliente" o "pedido") tiene una definición de campo obligatorio, un flujo de aprobación o una estructura de relaciones que entra en conflicto físico entre las unidades, y no solo difiere en la visualización. Si ninguna de las tres se cumple de manera inequívoca, la solución correcta es un solo Org con separación lógica. Dividir "por si acaso" genera un costo operativo constante — gestión de usuarios duplicada, licenciamiento duplicado y mantenimiento de integración duplicado — a cambio de un problema que podría haberse resuelto con configuración. ## Matriz de Decisión: Un Org frente a Varios Orgs | Dimensión | Un Org con separación lógica | Varios Orgs separados | | :-------------------------------- | :------------------------------------------- | :------------------------------------------- | | Costo de licenciamiento y mantenimiento | Más bajo — una sola licencia, gestión de usuarios centralizada | Más alto — duplicidad de licencias, duplicidad en la gestión de Releases | | Visión unificada (Customer 360) | Natural — todos los datos en el mismo espacio de consulta | Requiere una capa de BI o integración dedicada | | Autonomía operativa por unidad | Limitada — cada Release afecta a todos | Completa — cada unidad controla su propio ritmo | | Cumplimiento de requisitos regulatorios estrictos | No es posible si el requisito es la separación física | El único que cumple con el requisito | | Complejidad de integración entre unidades | Baja | Alta — requiere Middleware o ETL | | Riesgo en futuras fusiones/divisiones | Bajo — solo cambio de permisos | Alto — un proyecto de migración completo | En resumen: la opción predeterminada debe ser un solo Org, y la división solo debe elegirse cuando haya una respuesta positiva y clara a una de las tres preguntas anteriores, no como una respuesta a fricciones organizativas temporales. ## Lo que sucede cuando se divide sin razón suficiente Cuando una organización divide un Org por razones políticas (una unidad que quiere "su propio control") y no por razones técnicas genuinas, ocurren tres cosas en uno o dos años: Primero, se crea un registro de cliente duplicado en cada Org donde aparece la misma entidad comercial, sin una clave de identificación común. Segundo, cada cambio a nivel organizacional (como la actualización de un proceso de seguridad o la implementación de una nueva herramienta) se convierte en un proyecto separado para cada Org, lo que duplica el costo de cualquier cambio futuro. Tercero, la elaboración de informes a nivel de empresa requiere una capa de integración que no era necesaria inicialmente, y a menudo se construye bajo presión después de descubrir el problema, en lugar de como parte de la planificación. Por lo tanto, uno de los principios rectores en la [arquitectura de Salesforce](/es/insights/crm-architecture-guide) es examinar primero si la necesidad organizacional se puede cumplir con permisos y Sharing Rules dentro de un solo Org, y solo después considerar la división. ## Ruta gradual para quienes ya requieren una división Cuando una de las tres pruebas mencionadas sí se cumple, la división debe llevarse a cabo en un orden que minimice el riesgo: ### 1. Defina un identificador global antes de la división Antes de crear un segundo Org, establezca un campo de identificación uniforme (número de identificación fiscal, ID de cliente global o código similar) que permita en el futuro vincular registros entre los entornos. Sin esto, cualquier intento futuro de unificar la vista del cliente se basará en la coincidencia de nombre y dirección, lo que genera errores a gran escala. ### 2. Elija un patrón de integración según la dirección y el ritmo de los datos Si se trata de una actualización periódica solo con fines de informe, un ETL programado es suficiente. Si se requiere una visión en tiempo real (por ejemplo, verificación de crédito entre unidades), se necesita una API síncrona con manejo de fallos y reintentos. La elección de un patrón incorrecto es la causa principal de que las integraciones Cross-Org fallen bajo carga — más detalles sobre este tema en [patrones de integración de Salesforce](/es/insights/salesforce-integration-patterns). ### 3. Planifique la identidad y los permisos de acceso con antelación Los usuarios que trabajan en ambos Orgs (por ejemplo, gerentes de cuentas globales) requieren una solución de identidad gestionada una sola vez, y no dos usuarios separados con dos contraseñas. La planificación de SSO entre Orgs evita una situación en la que cada cambio en los permisos de usuario se realiza manualmente en ambos entornos — este tema se detalla en [arquitectura de SSO e identidad en Salesforce](/es/insights/salesforce-sso-identity-architecture). ### 4. Pruebe los límites de la API antes de que la integración esté en producción Cada llamada entre dos Orgs cuenta para la cuota de la API de ambas partes. El tráfico planificado sin una prueba de volumen puede afectar los límites diarios precisamente durante la carga máxima, es decir, justo cuando la integración es más necesaria. Esto debe verificarse de antemano con los [Salesforce API Limits](/es/insights/salesforce-api-limits-resilience). ### 5. Defina un propietario y un proceso de gobernanza compartido para ambos Orgs Alguien debe ser responsable de la coherencia de las decisiones arquitectónicas entre los entornos — estructura de campos, convenciones de nombres y políticas de cambio. Sin una propiedad central, los dos Orgs se dividirán también a nivel de estándares en un año, lo que hará que cualquier integración futura sea más costosa. ## Escenario ilustrativo: un grupo asegurador con dos divisiones El escenario es hipotético y tiene fines ilustrativos. Un grupo asegurador tenía una división de seguros generales y una división de seguros de vida, ambas operando bajo la misma entidad legal pero con reguladores diferentes y ciclos de aprobación de productos completamente distintos. La división de seguros de vida requería un control de cambios estricto con aprobación regulatoria para cada Release, mientras que la división de seguros generales quería lanzar mejoras semanalmente. Una propuesta inicial fue dividir en un Org separado para cada división, pero al comparar con las tres preguntas, se encontró que solo el ritmo regulatorio (prueba 2) se cumplía realmente — el modelo de cliente y producto no entraba en conflicto (prueba 3 negativa), y no había un requisito de separación física de datos (prueba 1 negativa). La solución elegida fue un solo Org con dos "carriles de lanzamiento" separados dentro del mismo entorno — un Sandbox dedicado y un proceso de aprobación separado para la división de seguros de vida, utilizando un modelo de datos compartido para un único Customer 360. Se evitó la división completa, y con ello el costo de mantenimiento duplicado que habría sido necesario asumir durante años. ## Riesgos comunes y cómo prevenirlos - **División "temporal" que se vuelve permanente** — Un Sandbox que se convierte en un entorno de producción sin pasar por un control de seguridad. Se previene asegurando que cada Org con datos reales de clientes pase por un proceso formal de aprobación de Gobernanza, sin excepciones. - **Registros duplicados sin clave común** — Ocurre cuando la división se produce antes de que se haya definido un identificador global. Se previene estableciendo el campo común como una condición previa para la división, no como un paso posterior. - **Cuota de API que se agota en momentos de carga máxima** — Sucede cuando la integración entre Orgs se planifica según un volumen promedio y no un volumen pico. Se previene mediante pruebas de carga antes de la puesta en producción y la construcción de un mecanismo de Backoff. - **Deriva de estándares entre Orgs** — Ocurre cuando no hay un único propietario para la arquitectura compartida. Se previene definiendo un comité de Gobernanza pequeño que apruebe los cambios en la estructura de datos en ambas partes. - **Informes de gestión poco fiables** — Sucede cuando se intenta calcular KPIs interorganizacionales directamente desde Salesforce sin una capa de unificación. Se previene estableciendo una capa de BI dedicada desde el primer día de la división, no como un proyecto de corrección tardía. ## Resumen La opción predeterminada es un solo Org; la división es una excepción que requiere una justificación concreta en una de las tres pruebas: autonomía regulatoria genuina, ritmo de cambio incompatible o un modelo de datos que colisiona físicamente. Cuando la justificación existe, el éxito de la transición se mide por la preparación realizada antes de la división: un identificador global, un patrón de integración adecuado, identidad compartida, prueba de límites de API y una propiedad clara sobre los estándares compartidos. Una organización que omite esta preparación no ahorra trabajo, solo lo pospone a un momento en el que la corrección es mucho más costosa. ### Preguntas y respuestas **¿Es suficiente la fusión de empresas para justificar una transición a Multi-Org?** No automáticamente. Si ambas empresas van a operar bajo marcas y procesos de venta separados durante años, hay una base para considerar un Org separado. Si el plan es unificar procesos en uno o dos años, a menudo es mejor integrar temporalmente bajo un mismo Org con separación de permisos y así evitar el costo de una fusión inversa en el futuro. **¿Cómo se maneja la generación de informes unificados cuando hay varios Orgs?** Generalmente, a través de una capa externa de BI (como Data Cloud, Snowflake o Tableau) que extrae datos de cada Org por separado y los unifica en un modelo de reporte único. Intentar construir informes Cross-Org dentro del mismo Salesforce casi siempre requiere un trabajo de integración costoso que no vale el valor que proporciona. **¿Qué sucede con un cliente que aparece en dos Orgs diferentes?** Sin un proceso de conciliación definido, ese mismo cliente se abrirá como un registro duplicado en cada Org, con un historial parcial en cada lado. Se debe definir una clave de identificación externa común (como un número de identificación fiscal o un ID de cliente global) y un proceso de sincronización o, al menos, un informe de conciliación periódico, incluso antes de que la división ocurra realmente. **¿Es posible unificar dos Orgs en uno solo?** Sí, pero es un proyecto de migración completo y no una configuración. Se deben ajustar el Object Model, los Record Types, los flujos de aprobación, los datos históricos y las integraciones entre ambos entornos, y a menudo se requerirá una herramienta de migración específica. Por lo tanto, conviene considerar la división como un paso difícil de revertir y no como un experimento reversible. **¿Qué significa 'Multi-Org en la práctica sin una decisión'?** Es una situación común en la que una unidad de negocio abre un Sandbox o un Org separado para una prueba temporal, y este se convierte en un entorno de producción real sin que nadie haya tomado una decisión consciente. La señal identificativa es la existencia de datos reales de clientes en un Org que no ha pasado por un proceso completo de gobernanza, seguridad y control de acceso. --- ## Data Mapping para Migraciones a Salesforce: Evite Errores Antes de la Carga URL: https://hpi.pro/es/insights/salesforce-data-mapping La mayoría de los fallos en las migraciones a Salesforce no son por herramientas, sino por significado: un campo con el mismo nombre en dos sistemas que describe dos conceptos distintos. Esta guía explica cómo construir un documento de mapping que capture el significado de negocio, reglas de transformación, valores predeterminados y responsabilidades, antes de la primera carga. ## La Respuesta Breve El Data Mapping no es simplemente una hoja de traducción entre campos, sino el documento donde la organización define el significado de cada dato que incorpora a Salesforce. Casi cualquier error de carga que parece técnico –formato de fecha, un Picklist desconocido, un vínculo roto– nace primero de una decisión de negocio no tomada. El orden que funciona es el siguiente: primero se determinan qué entidades se migrarán, luego quién es el propietario de negocio de cada entidad, después qué campos tienen un consumidor real, y solo al final se escriben las reglas de conversión. Cuando se inicia en sentido contrario, el equipo técnico toma decisiones de negocio de forma silenciosa, y esto se descubre tres meses después del Go Live, cuando un informe de ingresos no coincide. Los antecedentes sobre la planificación de toda la conversión se encuentran en [Migración de datos a Salesforce](/es/insights/salesforce-data-migration-guide). ## Los Tres Tipos de Brechas que el Mapping Revela | Tipo de Brecha | Ejemplo Común | Quién Decide | | --- | --- | --- | | Brecha Semántica | "Cliente Activo" = compró este año en un sistema, = no bloqueado en otro sistema | Propietario del Proceso de Negocio | | Brecha Estructural | Un cliente con cinco direcciones frente al modelo Account/Contact | Arquitecto de Datos | | Brecha de Calidad | 18% de registros sin ID fiscal válido | Data Owner + Regulación | La brecha semántica es la más costosa, porque no se detecta durante la carga. El dato se ingresa con éxito, la automatización se ejecuta sobre él, y el informe muestra un número erróneo que parece plausible. Las brechas estructurales se detectan durante la carga y, por lo tanto, se descubren temprano. Las brechas de calidad se descubren solo si se han definido umbrales de aceptación previamente. ## La Capa de Significado: Data Dictionary Antes de la Hoja de Mapping Antes de mapear campo a campo, es fundamental crear un diccionario de términos para cada entidad central: qué es una Cuenta (Account), qué diferencia a un Lead de un Contacto en esta organización, cuándo se cierra una Oportunidad (Opportunity). Estas definiciones son concisas –dos líneas por entidad– pero son clave para resolver disputas en lugar de solo señalar. La prueba sencilla: pida a tres personas de tres departamentos diferentes que definan "cliente" por separado. Si las definiciones son distintas, la migración transferirá tres verdades diferentes a la misma tabla. ## Anatomía de una Fila de Mapping Correcta Cada fila de la hoja debe responder a siete preguntas: desde qué objeto y campo de origen, a qué objeto y campo en Salesforce, cuál es el tipo y longitud del dato, cuál es la regla de conversión, qué sucede con un valor nulo, cuál es el valor predeterminado, y quién lo aprobó. Una fila que carezca de alguna de estas columnas se convertirá en una pregunta en medio de una carga nocturna durante el Cutover. Tres reglas de trabajo que evitan problemas: - **No hay conversiones silenciosas.** Cualquier valor que el sistema "corrige" por sí mismo debe registrarse en un log de excepciones. - **El valor predeterminado es una decisión de negocio.** Quien escribe `País = ES` como predeterminado debe ser el responsable de los informes por región. - **IDs externos antes que nada.** Para cada entidad, se debe preservar el ID externo del sistema de origen. Sin él, no hay Reconciliación ni segundas ejecuciones. ## Transformaciones: Dónde se Cometen Errores Las transformaciones que causan el mayor daño son precisamente las más simples. Las fechas sin zona horaria mueven los registros un día; los nombres que se normalizan con Trim y Upper sin una regla uniforme generan nuevas duplicidades justo después de haber limpiado las antiguas; los montos convertidos a una moneda única con una tasa diaria producen diferencias en los informes frente al ERP. La regla: toda conversión numérica o monetaria se verifica comparando sumas, no comparando registros. Una cuenta idéntica no es prueba de veracidad. Quienes aún no han resuelto la cuestión de la fuente de verdad encontrarán información en [Fuente Única de Verdad en la Organización](/es/insights/salesforce-source-of-truth), y el proceso de migración en sí mismo en [Cutover y Reconciliación en Migraciones de Salesforce](/es/insights/salesforce-migration-cutover-reconciliation). ## Escenario: Empresa de Servicios con Dos Sistemas de Origen Una organización de servicios con 90,000 clientes inició una conversión desde dos sistemas: un sistema de facturación antiguo y un sistema de servicio adquirido con una subsidiaria. La primera hoja de Mapping fue marcada como "lista" en dos semanas, con 340 campos mapeados. En la primera ejecución de prueba (Rehearsal), el 97% de los registros se cargaron. El problema se descubrió durante la Reconciliación: el total de saldos en Salesforce era un 4.1% inferior al del ERP. La razón no fue una carga fallida, sino que todos los registros con saldos negativos (créditos) se mapearon a un campo con una Rule de Validación que impedía valores negativos, y se establecieron silenciosamente en cero. La corrección se implementó en dos niveles: una regla de conversión explícita para los créditos, y un cambio de política para que cualquier regla que establezca un valor en cero o lo trunque deba generar una línea de excepción. En la segunda ejecución, el número de excepciones aumentó a 1,900, lo cual fue un avance: las excepciones eran visibles en lugar de ocultas. La tercera ejecución redujo las excepciones documentadas a 40, y solo entonces se fijó la fecha de Cutover. ## Riesgos Comunes y Acciones Preventivas | Riesgo | Cómo se Manifiesta en la Práctica | Acción Preventiva | | --- | --- | --- | | Transferencia de toda la historia | Volumen, duplicidades e información sin valor migran al nuevo sistema | Definir Retention y umbrales de calidad | | Mapping puramente técnico | Los campos se transfieren sin entender su significado de negocio | Data Dictionary y propietarios de negocio | | Conversiones silenciosas | Los valores se corrigen automáticamente y nadie lo sabe | Log de excepciones obligatorio para cada regla de conversión | | Sin Rehearsal | La ventana de inactividad se alarga y surgen sorpresas | Al menos dos ejecuciones completas | | Sin External ID | Imposibilidad de verificar, corregir o volver a ejecutar | La clave de origen se guarda para cada entidad | ## Cómo Medir el Éxito | Área | Qué se Mide | Frecuencia de Verificación | | --- | --- | --- | | Integridad (Completeness) | Tasa de campos obligatorios completados en el destino | Antes y después de cada carga | | Reconciliación | Coherencia de conteos, sumas y relaciones con la fuente | En cada Rehearsal y en el Cutover | | Excepciones | Número de líneas de excepción abiertas según gravedad | Diariamente durante el período de conversión | | Campos sin consumidor | Cuántos campos transferidos no se usaron en 90 días | Una vez después del Go Live | La última métrica es una preparación para el siguiente ciclo: enseña cuánto trabajo fue innecesario y orienta el alcance de la próxima conversión. Las organizaciones que prefieren acompañamiento profesional en la construcción del Mapping lo hacen a través del [Servicio de Integraciones y Datos](/es/integrations-data). ## Checklist Antes de la Primera Carga - ☐ Diccionario de términos conciso para cada entidad central, aprobado por el negocio - ☐ Lista de campos con un consumidor definido; el resto al archivo - ☐ ID externo para cada entidad que se migra - ☐ Tabla completa de Value Mapping, incluyendo valores para elementos desconocidos - ☐ Regla explícita para cada valor nulo y para cada valor predeterminado - ☐ Cada regla de conversión genera una línea de excepción en lugar de una corrección silenciosa - ☐ Escenario de Reconciliación: conteo, sumatoria, relación, muestreo manual - ☐ Umbral de excepciones acordado por encima del cual no se realiza el Cutover - ☐ Versión y firma de la hoja de Mapping - ☐ Plan de Rollback y de reejecución ## Recursos Profesionales - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Integraciones y Datos — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Preguntas y respuestas **¿Cuál es la diferencia entre un Mapping técnico y uno de negocio?** Un Mapping técnico responde a la pregunta '¿en qué campo se guarda esto?'. Un Mapping de negocio responde a '¿qué significa este campo, quién lo actualiza y qué ocurre si está vacío?'. Dos sistemas pueden tener un campo llamado 'Estado' que describe una etapa de venta en uno y un estado de cobranza en otro; solo el Mapping de negocio revela esta discrepancia antes de la carga. **¿Cuántos campos necesitamos migrar realmente?** En los proyectos que hemos acompañado, entre el 40% y el 60% de los campos en el sistema de origen no están en uso activo o pueden ser derivados. La regla práctica es migrar un campo solo si tiene un consumidor definido: un proceso, un informe, una automatización o un requisito regulatorio. Un campo sin consumidor permanece en el archivo, no en Salesforce. **¿Dónde se documentan las reglas de transformación?** En una única tabla de Mapping con control de versiones, donde cada fila tiene: origen, destino, tipo, regla de conversión, valor por defecto, manejo de valores vacíos y un propietario de negocio que lo apruebe. Si la regla solo existe en un script ETL, nadie en la empresa puede aprobarla ni se puede verificar en la conciliación. **¿Qué se hace con los valores de Picklist que no coinciden?** Se construye una tabla de Mapeo de Valores (Value Mapping) separada con un mapeo completo, incluyendo un valor por defecto para valores desconocidos. La regla es: ningún valor de origen queda sin destino, y ningún valor desconocido se carga silenciosamente; debe ir a un informe de excepciones que se cierre antes del cutover. **¿Cuándo se considera listo el Data Mapping?** Cuando se ha completado un ensayo (Rehearsal) con conciliación que verifica recuentos, sumas y relaciones padre-hijo, y la lista de excepciones restantes es menor que el umbral acordado previamente y es aprobada por escrito por los propietarios del proceso. --- ## Depuración de Duplicados Pre-Salesforce: Una Estrategia Práctica de Deduplicación URL: https://hpi.pro/es/insights/salesforce-data-deduplication La duplicación no es una falla técnica de datos, sino un problema de identidad. La organización no ha definido qué convierte a dos registros en un mismo cliente. Esta guía detalla cómo establecer reglas de matching, construir un Golden Record, decidir qué eliminar y qué conservar en el historial, y cómo evitar que los duplicados reaparezcan semanas después de la carga inicial. ## La respuesta corta La deduplicación falla cuando se considera una operación de limpieza única. En realidad, son tres decisiones: qué define una identidad, quién prevalece cuando hay un conflicto y cómo se evita que el problema se repita. La herramienta técnica es la parte más fácil. El error común es ejecutar la correspondencia aproximada (Fuzzy Matching) en nombres, obtener una lista de 12 mil posibles coincidencias e intentar resolverlas manualmente bajo la presión de un plazo. Lo que funciona es lo contrario: primero se reduce el espacio de decisión utilizando claves robustas y se deja para revisión humana solo la zona gris. La planificación integral de la migración se describe en [Guía de Migración de Datos a Salesforce](/es/insights/salesforce-data-migration-guide). ## Tres Capas de Correspondencia | Capa | Basada en | Acción | | --- | --- | --- | | Clave Robusta | ID fiscal, ID de sistema fuente, email verificado | Fusión automática | | Clave Compuesta | Nombre normalizado + ciudad + teléfono normalizado | Fusión automática con alta puntuación | | Similitud Textual | Solo nombre, dirección libre | Solo revisión humana | La proporción que caracteriza un proyecto bien gestionado es: aproximadamente el 70% de los duplicados se resuelven en la primera capa, el 20% en la segunda y el 10% restante llega a una persona. Si la mayoría de las coincidencias llegan a la tercera capa, es señal de que no se trabajó en la normalización, y no necesariamente de que los datos sean especialmente deficientes. ## Normalización antes de la Comparación Antes de cualquier comparación, se generan columnas de ayuda normalizadas sin modificar el dato original: eliminación de sufijos corporativos (S.A., Ltd.), uniformidad de espacios y comillas, teléfono a formato E.164, email a minúsculas con eliminación de etiquetas después del signo más, y dirección dividida en calle/número/ciudad. En español, se añade el tratamiento de grafías completas o abreviadas y siglas. La normalización por sí sola suele reducir entre un tercio y la mitad de los duplicados "difíciles" antes incluso de aplicar cualquier algoritmo de similitud. ## Golden Record a Nivel de Campo La decisión de "qué registro sobrevive" no es la más importante. La clave es "qué valor sobrevive en cada campo". Se establece una política concisa: datos de facturación del ERP, datos de contacto del sistema donde se registró la última actividad, estado del cliente del sistema operativo. Cada campo tiene una fuente preferente, y se mantiene un registro del valor descartado. Sin esta política, cada fusión es una decisión de quien la ejecuta en ese momento, y luego no se puede explicar por qué desapareció una dirección. ## Qué Sucede con las Relaciones y el Historial La fusión de registros afecta actividades, oportunidades, Casos, archivos y permisos. Antes de una ejecución masiva, se define explícitamente: a dónde van las actividades, qué ocurre con las oportunidades abiertas para el mismo cliente de dos registros, y quién es el propietario después de la fusión, ya que el cambio de propietario (Owner) modifica tanto la visibilidad como los informes de comisiones. La regla práctica es: no hay fusión antes de que exista un informe de "qué cambió" que pueda restaurarse, y los identificadores de origen se guardan en un campo separado para permitir investigaciones meses después. ## Escenario: un Importador con 210 Mil Contactos Un importador B2B abordó la migración con 210 mil Contactos de tres sistemas. La primera ejecución de la herramienta de similitud arrojó 31 mil pares sospechosos, un número que nadie podía revisar. El equipo se detuvo e invirtió el orden. Primero se normalizaron el email y el teléfono: 14 mil pares se resolvieron automáticamente por clave robusta. Luego, se determinó que la unidad de negocio era la ubicación del cliente y no la corporación, lo que eliminó 6 mil pares legítimos de la lista, sucursales separadas de la misma cadena. Quedaron 4,200 pares para la capa intermedia, de los cuales 3,800 se resolvieron con una alta puntuación. Para revisión humana llegaron 400 pares, y dos personas los resolvieron en tres días. La lección no fue la elección de la herramienta. Fue que la definición de la unidad de negocio, sitio versus corporación, eliminó más "ruido" que cualquier mejora algorítmica. ## Prevención: Por Qué Vuelven los Duplicados Tres fuentes principales reintroducen duplicados después del Go Live: entrada manual sin Matching Rules activas, integraciones que crean un registro en lugar de actualizar (Upsert en External ID resuelve la mayoría), y formularios Web-to-Lead sin verificación de existencia. Si no se cierran estas tres, la tasa de duplicidad vuelve a su nivel original en uno o dos años. ## Riesgos Comunes y Acciones Preventivas | Riesgo | Cómo se Manifiesta en la Práctica | Acción Preventiva | | --- | --- | --- | | Fusión Agresiva | Se unificaron clientes diferentes y no se pueden separar | Umbral de puntuación alto + revisión en la zona gris | | Falta de Definición de Identidad | Discusión recurrente sobre qué se considera el mismo cliente | Decisión documentada a nivel de entidad | | Pérdida de Historial | Actividades y oportunidades desaparecieron en la fusión | Informe "qué cambió" y conservación de IDs de origen | | Limpieza sin Prevención | Los duplicados vuelven en pocos meses | Matching Rules, Upsert y formularios protegidos | | Limpieza después de la Carga | Cada fusión impacta relaciones activas | Limpiar en la etapa de Staging | ## Cómo Medir el Éxito | Área | Qué Medir | Frecuencia de Verificación | | --- | --- | --- | | Unicidad | Tasa estimada de duplicidad por entidad | Semanal durante la migración, trimestral después | | Precisión de Fusión | Porcentaje de fusiones canceladas o corregidas manualmente | Con cada ola de fusión | | Prevención | Nuevos registros bloqueados como duplicados en la entrada | Mensual | | Impacto Comercial | Contactos duplicados con el cliente, precisión de informes de cliente | Trimestral | El acompañamiento profesional en la construcción de reglas de identidad y prevención se ofrece como parte de nuestro [servicio de Integraciones y Datos](/es/integrations-data). ## Lista de Verificación Antes de Ejecutar una Fusión - ☐ Se definió la unidad de negocio: corporación, sitio o contrato. - ☐ Se construyeron columnas de normalización sin modificar el origen. - ☐ Se establecieron tres capas de Matching con umbrales numéricos documentados. - ☐ Se definió la política de Golden Record a nivel de campo, aprobada por el negocio. - ☐ Se decidió qué ocurre con actividades, oportunidades y propiedad. - ☐ Se conservan los IDs de origen después de la fusión. - ☐ Es posible generar y restaurar un informe de "qué cambió". - ☐ Se realizó una prueba en una muestra con verificación manual. - ☐ Matching Rules y Upsert están activos para la prevención. - ☐ Se asignó un propietario permanente para el proceso después del Go Live. ## Fuentes Profesionales - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Qué se considera un duplicado y qué no?** Esta es una decisión de negocio, no técnica. Dos sucursales de la misma corporación pueden ser dos registros legítimos para Ventas y un solo registro para Cobranza. Antes de ejecutar una herramienta de deduplicación, es crucial definir a nivel de entidad: ¿la unidad de negocio es una corporación, una sede o un contrato? **¿Se depura antes o después de la carga?** Se depura antes. Un registro duplicado cargado genera relaciones (actividades, casos, oportunidades), y cualquier fusión posterior se convierte en una operación riesgosa con posible pérdida de historial. Después de la carga, solo queda la aplicación continua de reglas, no una limpieza masiva. **¿Qué se hace cuando dos registros tienen información diferente, pero ambos son correctos?** Se construye un Golden Record a nivel de campo, no de registro. Para cada campo, se establece una regla de precedencia: sistema de origen preferido, el más reciente o el valor validado. De esta manera, no se pierde una dirección correcta solo porque el otro registro fue seleccionado como el ganador. **¿Son suficientes las reglas de matching de Salesforce?** Son suficientes para la prevención continua en la entrada manual, pero no para la limpieza masiva antes de una conversión. Para la depuración inicial, se requiere una herramienta o script que realice un 'fuzzy matching' en la normalización de texto y que permita una revisión humana del 'área gris' antes de la fusión. **¿Cuántos duplicados se consideran 'normales'?** En bases de datos antiguas, no gestionadas, es común observar un 8%-20% de duplicación a nivel de Contacto y un 3%-10% a nivel de Cuenta. El objetivo práctico no es cero, sino un umbral acordado (por ejemplo, por debajo del 2%) con un proceso que evite el deterioro recurrente. --- ## La Fuente Única de Verdad en su Organización: ¿Quién es el Responsable del Cliente, Producto, Pedido y Pago? URL: https://hpi.pro/es/insights/salesforce-source-of-truth Cuando no se define claramente quién está autorizado para modificar un dato, cada integración se convierte en una negociación, lo que resulta en sistemas que se sobrescriben mutuamente. Esta guía explica cómo establecer una fuente única de verdad para cada entidad a nivel de campo, diferenciar entre un sistema de visualización y un sistema autorizado, y reforzar estas decisiones a través del código, no solo de la documentación. ## La respuesta breve La "Source of Truth" (Fuente Única de Verdad) no es una cuestión técnica, sino de autoridad: ¿quién en la organización está facultado para determinar que un valor específico es correcto? Cuando esta decisión no se toma explícitamente, se hace en silencio, por quien escribió la última integración. La regla central: la propiedad se define a nivel de campo, no a nivel de sistema. El intento de declarar "el ERP es la fuente de verdad para el cliente" se rompe en el momento en que el departamento de servicio actualiza un número de teléfono en Salesforce y la sincronización nocturna borra la actualización. ## Tres preguntas que definen la propiedad Para cada entidad, y luego para cada grupo de campos, se pregunta: ¿dónde se **creó** el dato por primera vez, quién está **autorizado** a nivel de negocio para modificarlo, y quién **asume la responsabilidad** cuando este es erróneo? En los tres casos, la respuesta debe ser el nombre de un rol, no el nombre de un sistema. El sistema se deriva del rol. Cuando las respuestas apuntan a dos roles distintos, es casi siempre una señal de que dos campos diferentes se han fusionado en uno. ## Matriz de propiedad de ejemplo | Entidad / Campo | Fuente de Verdad | Salesforce | Dirección de Sincronización | |---|---|---|---| | Razón social, NIF, Condiciones de pago | ERP | Solo lectura | ERP → Salesforce | | Contacto, Cargo, Preferencias | Salesforce | Edición | Salesforce → Sistemas de Marketing | | Catálogo de productos y lista de precios base | ERP / PIM | Solo lectura | ERP → Salesforce | | Oferta y descuento aprobado | Salesforce | Edición | Salesforce → ERP | | Pedido aprobado y estado de entrega | ERP | Solo lectura | ERP → Salesforce | | Saldo deudor y estado de cobro | Sistema financiero | Solo lectura | Financiero → Salesforce | | Actividad, Casos y Comunicación | Salesforce | Edición | Sin sincronización externa | Esta tabla es el producto final. Es concisa, reside en un único documento, y cada nueva integración se verifica contra ella antes de su desarrollo. ## Separación entre presentación y autoridad Gran parte de la tensión entre sistemas desaparece cuando se comprende que presentar un dato no requiere copiarlo. Un saldo deudor que se muestra a un vendedor no tiene por qué ser un campo en Salesforce que se actualiza cada noche; puede ser una vista remota o una capa de federación. Cada campo que se copia implica un compromiso operativo: sincronización, fallos, discrepancias y tiempo. Antes de copiar, pregunte si se requiere automatización o informes históricos sobre él. Si no, es preferible mostrarlo y no copiarlo. Una ampliación sobre este enfoque se encuentra en [Zero Copy y Federation en Data 360](/es/insights/data-360-zero-copy-federation). ## Conflictos: decidir de antemano, no en tiempo real Incluso cuando la propiedad está clara, surgen situaciones de actualización concurrente. Tres reglas posibles son: prioridad del sistema (el propietario siempre prevalece), marca de tiempo más reciente, o marcaje para gestión manual. La tercera regla es la más segura para campos sensibles, siempre que exista una cola de tratamiento con un responsable, y no un registro de log que se pierda. ## Escenario: una organización con dos verdades para una misma dirección Una empresa de servicios de infraestructura gestionaba la dirección de un cliente en dos sistemas: el ERP para fines de facturación y un sistema de servicio de campo para la llegada de técnicos. Ambos se sincronizaban bidireccionalmente con Salesforce. El resultado: una dirección que oscilaba entre versiones, y técnicos que llegaban a la dirección de facturación. La solución no consistió en corregir la sincronización, sino en desglosar la entidad. Se definieron dos campos separados: dirección de facturación bajo la propiedad del ERP, y dirección de servicio bajo la propiedad del sistema de campo; ambos en modo de solo lectura en Salesforce, con un enlace para solicitar cambios que se dirigía al propietario correcto. El número de solicitudes de servicio cerradas por "dirección incorrecta" disminuyó significativamente en el siguiente trimestre. La lección: cuando los sistemas "luchan" por un campo, generalmente se trata de dos datos de negocio distintos que recibieron el mismo nombre. ## Implentación: del documento a la realidad Una matriz de propiedad solo es efectiva si se implementa en tres puntos: Seguridad a nivel de campo (Field-Level Security) que impide la edición por parte de quien no es el propietario, un usuario de integración con permisos restringidos solo a los campos de su propiedad, y un informe mensual que muestre los campos actualizados en contra de la política. El tercer informe es el que revela integraciones antiguas que nadie recuerda. La documentación del significado de cada campo se conecta directamente con el [Mapeo de Datos para Migración](/es/insights/salesforce-data-mapping). ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | |---|---|---| | Propiedad a nivel de sistema | Contradicciones dentro de la misma entidad | Decisión a nivel de campo o grupo de campos | | Sincronización bidireccional por defecto | Valores que se alternan intermitentemente | Dirección única + lectura en el otro lado | | Copia innecesaria | Decenas de campos sincronizados sin consumidor | Mostrar en lugar de copiar | | Documento sin implementación | La política se debilita en meses | Permisos de campo + monitoreo de anomalías | | Sin cola de conflictos | Las contradicciones se acumulan en silencio | Cola de tratamiento con responsable y SLA | ## Cómo medir el éxito | Área | Qué se mide | Frecuencia de verificación | |---|---|---| | Coherencia | Tasa de inconsistencia en campos clave entre sistemas | Mensual | | Anomalías políticas | Escrituras en campos fuera del propietario definido | Mensual | | Conflictos | Número y tiempo de cierre de ítems en la cola | Semanal | | Impacto operativo | Incidencias causadas por datos erróneos | Trimestral | La construcción y aplicación de una matriz de propiedad se realiza dentro del [servicio de Integraciones y Datos](/es/integrations-data). ## Lista de verificación para determinar la Source of Truth - ☐ Lista de las entidades centrales de la organización - ☐ Para cada entidad: dónde se creó, quién está autorizado, quién es responsable del error - ☐ Propiedad definida a nivel de campo o grupo de campos - ☐ Dirección de sincronización explícita para cada grupo - ☐ Cada campo copiado pasa la prueba de "tiene un consumidor" - ☐ Se selecciona y documenta una regla de resolución de conflictos - ☐ Existe una cola de tratamiento manual con un responsable y un SLA - ☐ La Seguridad a nivel de campo (Field-Level Security) es coherente con la matriz - ☐ El usuario de integración está limitado a los campos de su propiedad - ☐ Informe mensual de anomalías políticas ## Recursos profesionales - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Pueden existir dos sistemas como Fuente Única de Verdad para la misma entidad?** Sí para la misma entidad, pero no para el mismo campo. Por ejemplo, los datos de facturación pueden ser propiedad del ERP, mientras que los datos de contacto y actividad pueden ser propiedad de Salesforce para el mismo cliente. Lo inaceptable es que dos partes puedan escribir en el mismo campo sin una regla de arbitraje clara. **¿Cuál es la diferencia entre un System of Record y un System of Engagement?** Un System of Record es el sistema autorizado para definir el valor de los datos; un System of Engagement es donde las personas interactúan con esos datos. Salesforce suele ser un System of Engagement para el cliente, y también un System of Record para el pipeline de ventas y la actividad con el cliente. La confusión entre ambos es una causa común de sincronizaciones bidireccionales innecesarias. **¿Cuándo se justifica una sincronización bidireccional?** Solo cuando ambas partes realmente generan valor en el mismo campo y existe una regla de arbitraje unívoca, como una marca de tiempo o una prioridad del sistema. En cualquier otro caso, es preferible una dirección unidireccional con una pantalla de solo lectura en el otro lado. La sincronización bidireccional duplica el número de posibles fallos. **¿Cómo se aplica la propiedad de los datos en la práctica?** En tres niveles: permisos de campo que impiden la edición por parte del sistema no propietario, una integración que solo escribe en los campos de su propiedad, y la monitorización que reporta escrituras fuera de la política establecida. Un documento de propiedad sin aplicación técnica pierde su efectividad en cuestión de meses. **¿Qué hacer cuando ningún sistema es adecuado para ser la Fuente Única de Verdad?** Esto indica que la entidad está definida de forma demasiado amplia. Se debe desglosar: Por ejemplo, un 'producto' puede dividirse en catálogo (ERP), oferta comercial (CRM) y autorización de uso (sistema operativo). Cada parte tendrá su propia y clara Fuente Única de Verdad. --- ## Métricas de Calidad de Datos en Salesforce: Qué Medir y Cómo Establecer Umbrales URL: https://hpi.pro/es/insights/salesforce-data-quality-metrics La calidad de los datos se vuelve gestionable solo cuando tiene un número, un umbral y un dueño. Esta guía explica qué dimensiones vale la pena medir en Salesforce, cómo definir umbrales no arbitrarios, cómo vincular cada métrica a su impacto comercial y cómo construir un informe de resultados (Scorecard) que se consulte más de una vez. ## La respuesta breve La calidad de los datos no es una característica inherente, sino el resultado de procesos. Por lo tanto, una medición que no esté vinculada a una implicación de negocio y a un propietario no genera un cambio significativo. Solo produce un informe que alguien abre y aprueba trimestralmente. Un Scorecard eficaz consta de solo cuatro a seis métricas, cada una con un umbral, un propietario y una acción correctiva definida. La diferencia entre un Scorecard y un informe es que en el primero, cualquier número en rojo activa a una persona. ## Las cinco dimensiones – y cuáles se miden realmente | Dimensión | Qué evalúa | Cuándo es crítica | | --- | --- | --- | | Completeness (Integridad) | Tasa de campos completados que impulsan una decisión | Siempre | | Validity (Validez) | Concordancia con reglas de formato y valores válidos | Integraciones, regulación | | Uniqueness (Unicidad) | Duplicidad a nivel de entidad | Antes de la migración y después de las fusiones | | Timeliness (Actualidad) | Cuán reciente es el dato frente a la realidad | Pronóstico, servicio, cobro | | Consistency (Consistencia) | Si el mismo dato es idéntico entre sistemas | Múltiples sistemas e informes financieros | Las organizaciones casi siempre empiezan con las tres primeras. La Actualidad (Timeliness) y la Consistencia (Consistency) se incorporan cuando sistemas adicionales dependen del CRM, y es precisamente en ese momento cuando un fallo en estas dimensiones tiene el costo más elevado. ## Completeness (Integridad): no todos los campos justifican una medición Medir la tasa de completitud en 300 campos genera un número carente de significado. El enfoque correcto es definir para cada proceso principal un pequeño "paquete de campos" (cinco a ocho campos sin los cuales el proceso no funciona) y medir solo este paquete. Es importante agregar una verificación de completitud artificial: el porcentaje de registros donde el campo se completó con un valor que se repite de manera sospechosa (un punto, un guion, "desconocido"). Esta es, a menudo, la primera señal de que la regla definida está obstaculizando el trabajo en lugar de mejorarlo. ## Timeliness (Actualidad): la dimensión que todos pasan por alto Un dato puede ser completo, válido y único, y simplemente ya no ser correcto. Un campo de estado de cliente que no se ha tocado en 14 meses no es un dato, es un recuerdo. La medición es sencilla: la distribución del tiempo desde la última actualización de campos esenciales, frente a la velocidad a la que la realidad cambia. En las oportunidades de venta, esto se traduce directamente en la calidad del pronóstico: el porcentaje de oportunidades abiertas cuya fecha de cierre ya ha pasado es una de las métricas más potentes y rápidas de calcular. ## Del umbral a la acción: qué sucede cuando la métrica está en rojo Para cada métrica, se definen tres niveles (verde, ámbar, rojo) y una acción para cada nivel. El ámbar activa una revisión por parte del equipo; el rojo activa una corrección con una fecha límite. Sin esta definición, la métrica se convierte en información y no en gestión. Las acciones en sí deben ser variadas: a veces la corrección es una limpieza puntual, a veces un cambio en el proceso de trabajo, y a menudo la solución correcta es eliminar el campo, porque nadie lo requiere. Para información complementaria sobre duplicidades, consulte la [Limpieza de duplicidades en Salesforce](/es/insights/salesforce-data-deduplication), y sobre una estructura que genera calidad, el [Diseño del modelo de datos de Salesforce](/es/insights/salesforce-data-model-design). ## Escenario: Una compañía de seguros que midió todo y no mejoró nada Una compañía de seguros construyó un panel de control de calidad con 34 métricas. Estuvo funcionando durante un año. Ninguna métrica mejoró significativamente, porque no había una titularidad: el panel de control pertenecía al equipo de BI, y los campos a los agentes. En la segunda etapa, el panel de control se redujo a cuatro métricas: la tasa de completitud del paquete de campos de suscripción, el porcentaje de pólizas con fecha de renovación vencida, la tasa de duplicidad a nivel de asegurado y el porcentaje de correos electrónicos fallidos al enviarse. A cada métrica se le asignó un gerente de área con un objetivo trimestral, y la métrica se presentó en la reunión de ventas y no en la reunión de TI. En dos trimestres, dos métricas cruzaron el umbral. La tercera métrica no se movió, y una investigación reveló que el campo se requería en un formulario que los agentes completaban después del cierre del negocio, es decir, en un momento en que no tenían incentivo. La solución fue un cambio de ubicación en el proceso, no una regla de validación adicional. ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Demasiadas métricas | Panel de control que nadie utiliza | Cuatro a seis métricas con un propietario | | Métrica sin umbral | Debate sobre "si 78% es bueno" | Umbral derivado del impacto de negocio | | Titularidad en TI | Sin cambio de comportamiento en el campo | Propietario de negocio para cada métrica | | Validación sin medición | Campos llenos de valores ficticios | Medición de completitud artificial | | Medición única | Mejora temporal que retrocede | Scorecard periódico constante | ## Cómo medir el éxito | Área | Qué medir | Frecuencia de revisión | | --- | --- | --- | | Completeness (Integridad) | Tasa de completitud del paquete de campos por proceso | Mensual | | Timeliness (Actualidad) | Mediana del tiempo desde la última actualización | Mensual | | Uniqueness (Unicidad) | Tasa de duplicidad estimada | Trimestral | | Impacto | Quejas, fallos de integración, precisión del pronóstico | Trimestral | La construcción de un Scorecard y el proceso operativo se realizan en el marco de [Servicios de integraciones y datos](/es/integrations-data). ## Lista de verificación para establecer la medición - ☐ Se seleccionaron hasta un máximo de seis métricas. - ☐ Cada métrica tiene un paquete de campos definido, no el objeto completo. - ☐ Cada métrica tiene un umbral derivado de una implicación de negocio. - ☐ Cada métrica tiene un propietario de negocio con nombre y apellido. - ☐ Se definió una acción para el nivel ámbar y para el nivel rojo. - ☐ Se mide también la completitud artificial, no solo la llenura. - ☐ Existe una línea base antes de iniciar la mejora. - ☐ El informe se presenta en un foro de negocio y no técnico. - ☐ Se ha verificado si un campo problemático es realmente necesario. - ☐ Se ha establecido una revisión periódica de la propia lista de métricas. ## Fuentes profesionales - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integraciones y datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Por qué dimensión debería empezar?** Empiece por la Exhaustividad (Completeness) en un pequeño grupo de campos que impulsan decisiones, no en todos los campos. La tasa de relleno es la dimensión más sencilla de calcular, la más fácil de explicar a la gerencia y, por lo general, la que más rápidamente revela los procesos que no funcionan. **¿Cómo se establece un umbral no arbitrario?** Se deriva de su impacto. Si el 5% de los correos electrónicos son incorrectos y una campaña genera 200 leads al mes, esto se puede traducir en una pérdida esperada. El umbral se fija donde el costo de la corrección comienza a ser mayor que el daño, no en un número redondo que suena bien. **¿Quién es responsable de una métrica de calidad?** El dueño del proceso que genera el dato, no el equipo de Datos. El equipo de Datos mide y proporciona herramientas; quien vende, factura o da servicio es quien puede cambiar el comportamiento que produce la brecha. Una métrica sin un dueño de negocio no mejora. **¿Las Reglas de Validación resuelven la calidad de los datos?** Parcialmente. Previenen valores incorrectos en la entrada manual, pero empujan a los usuarios a completar un valor cualquiera solo para avanzar. Una regla de validación debe ir acompañada de una métrica que verifique si el campo se completó realmente o de forma artificial. **¿Cuál es la frecuencia de medición correcta?** Durante una migración, semanalmente. En operación continua, mensualmente para la mayoría de las métricas y trimestralmente para la revisión de la gerencia. Medir la calidad de los datos diariamente casi siempre genera ruido al que nadie le da seguimiento. --- ## Agentforce para Servicio al Cliente: Casos de uso ideales para iniciar la transformación URL: https://hpi.pro/es/insights/agentforce-customer-service-use-cases No todas las consultas son aptas para un agente virtual, y el orden con el que se inicia un proyecto determina su éxito o fracaso. Esta guía clasifica casos de uso comunes según su madurez, explica los requisitos para cada uno y revela qué escenarios, aunque tentadores, pueden erosionar la confianza prematuramente. ## La respuesta breve En el servicio de atención al cliente, la diferencia entre un piloto que se expande y uno que se detiene se define casi siempre por la elección del primer caso de uso. Un caso de uso maduro es aquel que se apoya en una fuente de información fiable y única, no realiza una acción irreversible y tiene un volumen que justifica su mantenimiento. Los casos de uso más tentadores —gestionar una reclamación, retener a un cliente, decidir un reembolso— son precisamente los que requieren criterio, sensibilidad e información de múltiples sistemas. Estos son de una tercera etapa, no la primera. El marco general para la decisión de la adaptación de casos de uso aparece en [Agentforce para empresas](/es/insights/agentforce-for-enterprises). ## Clasificación de casos de uso por madurez | Caso de uso | Madurez | Requisitos | Riesgo principal | | --- | --- | --- | --- | | Consultas de estado | Alta | Un único campo fiable en el CRM | Casi nulo; error reversible | | Preguntas frecuentes de conocimiento | Alta | Artículos de Knowledge actualizados para los casos de uso comunes | Cita de política obsoleta | | Asistencia al agente durante la llamada | Alta | Knowledge e historial de casos (Case) | El agente adopta una respuesta incorrecta | | Enrutamiento y clasificación de solicitudes | Media | Taxonomía consistente de tipos de solicitud | Clasificación incorrecta que alarga la gestión | | Actualización de datos y operaciones simples | Media | Permisos precisos y acciones (Actions) limitadas | Actualización incorrecta en el registro del cliente | | Coordinación, cancelación y cambio de fecha | Media | Integración estable con el sistema operativo | Fallo de integración con el cliente | | Reembolsos y compensaciones | Baja | Política escrita, autoridad y aprobación humana | Exposición financiera y precedente con el cliente | | Gestión de reclamaciones y retención | Baja | Comprensión del contexto, sensibilidad e historial completo | Daño a la marca y a la confianza | ## Los tres casos de uso por los que vale la pena empezar Las consultas de estado son el mejor punto de partida. El cliente pregunta dónde está el pedido, cuál es el estado de la solicitud, cuándo llega el técnico. La respuesta se basa en un solo campo, no hay operaciones de escritura y el volumen suele ser alto. El éxito también es fácil de medir: ¿recibió el cliente una respuesta y no volvió a contactar? Las preguntas frecuentes de conocimiento son el segundo caso de uso. Aquí el desafío no es el agente, sino el contenido, por lo que el trabajo comienza por revisar las veinte consultas más comunes y asegurarse de que cada una tenga un artículo aprobado y actualizado. La asistencia al agente es el caso de uso más recomendado para empezar cuando hay dudas. El agente sugiere una respuesta, el representante aprueba o corrige. Cada corrección es un dato de aprendizaje y el riesgo externo es mínimo. Las organizaciones que empiezan aquí alcanzan una exposición externa con un conjunto de pruebas reales en lugar de suposiciones. Lo necesario para que la base de conocimientos soporte la carga se detalla en [Gestión del conocimiento para Agentforce](/es/insights/agentforce-knowledge-readiness). ## Lo que se aplaza para una etapa posterior Los reembolsos y compensaciones requieren una política escrita que en la mayoría de las organizaciones no está completamente definida; reside en el criterio de los gerentes de equipo. Antes de que el agente entre en este ámbito, se debe redactar la política, y entonces se descubre que este es un trabajo organizacional en sí mismo. La gestión de reclamaciones requiere una comprensión del contexto emocional y un historial completo. Incluso cuando la respuesta técnica es correcta, la formulación es clave. Este es el ámbito en el que una escalada rápida es casi siempre preferible a un intento de solución. Los casos de uso de sistemas cruzados en los que la información está dispersa entre tres sistemas sin una única fuente de verdad, no por una limitación de la IA, sino porque la brecha en los datos se revelará aquí primero y se considerará un fracaso del agente. ## Reglas de escalada que deben estar definidas Cuatro factores desencadenantes (triggers) rígidos: una solicitud explícita de hablar con una persona, la identificación de un tono negativo o palabras de escalada, dos intentos fallidos de responder la misma pregunta y cualquier consulta que involucre un tema sensible predefinido. La transferencia debe mantener el contexto. Un cliente que se ve obligado a repetir todo al agente percibe a este como un obstáculo, y esto es lo que recordará. Un resumen de la conversación, lo que se verificó y lo que se encontró, deben transferirse automáticamente al agente. El diseño de las rutas de escalada dentro del conjunto de canales se detalla en [Omni-Channel y SLA en Service Cloud](/es/insights/service-cloud-omnichannel-sla). ## Caso de uso: Un centro de contacto que cambió el piloto después de dos semanas Una empresa de productos de consumo planeó comenzar con un agente que gestionaría las solicitudes de devolución, el caso de uso con más reclamaciones. En las dos primeras semanas se comprobó que cada solicitud requería verificar las condiciones de garantía en el sistema ERP, verificar el inventario y tomar una decisión que, en la práctica, se hacía a criterio de un gerente. El piloto se trasladó a otro caso de uso: responder al estado de una devolución existente. Los mismos clientes, el mismo ámbito, pero basado en un solo campo de estado. El volumen era alto, la tasa de escalada baja y el centro de contacto vio una disminución inmediata de las llamadas repetidas. Seis meses después, una vez redactada la política de devoluciones como documento aprobado, el caso de uso original volvió a la planificación, esta vez con aprobación humana para cada aprobación de devolución. El orden, y no la tecnología, fue lo que lo hizo posible. ## Riesgos y acciones preventivas | Riesgo | Cómo se ve en el centro de contacto | Acción preventiva | | --- | --- | --- | | Empezar con un caso de uso emocional | Reclamaciones que llegan a la dirección en la primera semana | Empezar con un caso de uso informativo en lugar de uno de resolución | | No hay camino hacia una persona | Cliente atrapado en un bucle de preguntas | Botón de transferencia al agente en cada etapa y factores desencadenantes rígidos | | Pérdida de contexto en la escalada | El cliente repite la historia al agente | Transferencia automática del resumen de la conversación | | Política no escrita | Respuestas inconsistentes entre casos | Redactar la política antes de introducir el caso de uso | | Múltiples casos de uso paralelamente | No hay capacidad para mantener y la calidad disminuye | Hasta tres casos de uso activos en el primer año | ## Métricas en el servicio | Métrica | Definición | Frecuencia | | --- | --- | --- | | Containment | Porcentaje de solicitudes cerradas sin agente y sin contacto repetido | Semanal | | Tasa de contacto repetido | Clientes que volvieron a contactar por el mismo tema en una semana | Semanal | | Tiempo hasta la escalada | Cuánto tiempo transcurre hasta la transferencia a una persona cuando es necesario | Semanal | | Satisfacción del canal | Comparación con un canal humano paralelo | Mensual | | Tiempo de manejo del agente | Si la asistencia acortó realmente la llamada | Mensual | El "Containment" sin la tasa de contacto repetido es una métrica engañosa. Una llamada que se cerró rápidamente porque el cliente se rindió se cuenta como un éxito, por lo que las dos métricas siempre se interpretan juntas. Cuando se requiere acompañamiento en la selección de casos de uso y en la configuración de las rutas de escalada, [Servicio Agentforce e IA](/es/agentforce-ai) es la ruta práctica a seguir. ## Lista de verificación para seleccionar el primer caso de uso - ☐ El caso de uso se basa en una única fuente de información fiable. - ☐ No hay ninguna acción irreversible en la primera versión. - ☐ El volumen mensual justifica el mantenimiento continuo. - ☐ Existen artículos aprobados para los casos de uso comunes. - ☐ Se han definido los cuatro factores desencadenantes (triggers) de escalada. - ☐ La transferencia al agente incluye un resumen de la conversación. - ☐ El agente declara que no es humano al inicio. - ☐ Se mide una línea de base (Baseline) de "Containment" y contactos repetidos. - ☐ Se establece un número máximo de casos de uso activos al mismo tiempo. ### Preguntas y respuestas **¿Cuál es el caso de uso más adecuado para empezar?** Las consultas de estado. Son de alto volumen, se basan en uno o dos campos del CRM, no requieren redacción y son fáciles de medir. Además, es el escenario donde el cliente es más indulgente, ya que espera información, no una solución compleja. **¿Debemos empezar con un agente interno para los colaboradores o uno para los clientes?** Casi siempre con un agente interno. Un colaborador puede identificar y corregir una respuesta errónea, por lo que un error en la fase de aprendizaje tiene un costo bajo. El mismo error frente a un cliente afecta la confianza y escala a la dirección. Tres a seis meses de uso interno generan el conjunto de pruebas necesario para una exposición externa. **¿Qué hacer con un cliente molesto que interactúa con el agente virtual?** Identificación y escalamiento inmediato. La detección de un tono negativo o palabras de escalada debe ser una regla estricta que transfiera la interacción a una persona sin mayor dilación. Un agente virtual que intenta calmar a un cliente molesto genera precisamente las situaciones que detienen los proyectos. **¿Debe el agente declarar que no es una persona?** Sí, y en muchos casos es un requisito regulatorio. Además, es una decisión práctica: un cliente que descubre en medio de la conversación que trató con un sistema se siente engañado. Una breve declaración al inicio, junto con una opción clara para hablar con un agente humano, reduce las quejas. **¿Cuántos casos de uso se recomienda implementar simultáneamente en el primer año?** Entre uno y tres. Cada caso de uso requiere su propio contenido, pruebas y monitoreo. Una organización que implementa seis simultáneamente puede encontrar que no tiene la capacidad para mantenerlos adecuadamente. Una expansión adecuada se logra después de que el primer caso de uso sea estable durante un trimestre. --- ## Grounding y RAG en Agentforce: Conectando un Agente con Conocimiento Confiable URL: https://hpi.pro/es/insights/agentforce-grounding-rag Un agente no inventa respuestas por malicia; las inventa cuando la fuente de información es incompleta, contradictoria o no autorizada. Esta guía desglosa la capa de Grounding en sus componentes: qué fuentes conectar, cómo fragmentar y etiquetar el contenido, cómo se mantienen los permisos en la recuperación y cómo medir la precisión antes de permitir que el agente interactúe con un cliente. ## La Respuesta Breve El "Grounding" es la diferencia entre un agente que cita una política aprobada y uno que formula algo que suena plausible. En Agentforce, la capa de Grounding se compone de cuatro elementos que se construyen en orden: qué fuentes se declaran como fuente única de la verdad, cómo se fragmenta y etiqueta el contenido para su recuperación, cómo se mantienen los permisos del usuario en el momento de la recuperación, y qué sucede cuando no se encuentra una fuente adecuada. La mayoría de los fallos que observamos en los proyectos piloto no son del modelo. Son fallos de una base de conocimiento que nadie había gestionado en dos años, de documentos fragmentados a mitad de una tabla, y de la ausencia de una ruta de contingencia (Fallback). Por lo tanto, el trabajo comienza con la evaluación de la preparación del contenido y no con la redacción de instrucciones. La relación general para la selección de casos de uso se encuentra en [Agentforce para Empresas](/es/insights/agentforce-for-enterprises). ## Las Cuatro Capas de Grounding | Capa | Qué se define | Señal de que está rota | Evidencia de que funciona | | --- | --- | --- | --- | | Fuentes | Qué bases de datos se declaran como fuente única de la verdad y quién es el propietario | Dos respuestas contradictorias a la misma pregunta | Lista de fuentes con Propietario y Fecha de Revisión | | Representación | Fragmentación (Chunking), Metadatos y etiquetado por producto, idioma y versión | Una sección recuperada no está relacionada con la pregunta | Recuperación medida en un conjunto de preguntas conocidas | | Permisos | Cómo el contexto del usuario limita la recuperación | Contenido interno aparece en la respuesta a un cliente | Prueba de Persona para cada nivel de permiso | | Transparencia | Citas, Actualidad (Freshness) y ruta de contingencia (Fallback) | Respuesta sin fuente y sin reconocimiento de falta de conocimiento | Porcentaje de respuestas con una cita válida | ## Capa 1: Declaración de Fuentes de la Verdad El primer paso no es técnico. Se toman las veinte preguntas más frecuentes en el proceso seleccionado y, para cada pregunta, se identifica dónde se encuentra la respuesta correcta actualmente. El resultado casi siempre sorprende: algunas respuestas están en un artículo de Knowledge, otras en un campo de CRM, algunas en un documento en posesión de un gerente de equipo, y otras en la mente de dos personas con mucha antigüedad. Cada fuente que se incorpore debe tener un propietario nominal, una frecuencia de actualización acordada y una fecha de última revisión. Una fuente sin propietario se convierte, en pocos meses, en una fuente de información desactualizada, y el agente seguirá citándola con confianza. Las fuentes sin propietario se mantienen fuera, incluso si son ricas en contenido. La decisión difícil es qué no conectar. Un repositorio de correos electrónicos, canales de chat y presentaciones de ventas parecen una mina de oro, pero resultan ser una fuente principal de respuestas incorrectas, ya que no distinguen entre un borrador, una propuesta rechazada y una política aprobada. Los fundamentos de la limpieza y preparación de la base de conocimiento se detallan en [Preparación del Knowledge para Agentforce](/es/insights/agentforce-knowledge-readiness). ## Capa 2: Fragmentación (Chunking), Metadatos y Relevancia Una buena recuperación depende menos del modelo y más de cómo se descompone el contenido. La fragmentación por un número fijo de caracteres destruye tablas, listas de pasos y condiciones de elegibilidad, precisamente el contenido del que se derivan respuestas precisas. Es preferible la fragmentación por estructura: un subtítulo, un paso en un proceso o una fila de tabla que se mantiene completa con su contexto. Los metadatos son lo que permite reducir el espacio de búsqueda antes de que el modelo entre en acción. El etiquetado mínimo que se debe exigir incluye: producto o línea de servicio, mercado o país, idioma, público objetivo (cliente o interno), fecha de vencimiento y estado de aprobación. Sin el etiquetado de mercado e idioma, un agente en una organización global mezclaría políticas de dos países en la misma respuesta. La prueba de relevancia es cuantitativa y no subjetiva: se construye un conjunto de 50 a 100 preguntas reales con la respuesta correcta y la fuente correcta, y se mide en cuántos casos apareció el fragmento correcto en la recuperación. Una puntuación baja de "Recall" (recuperación) indica un problema de representación, y su tratamiento es mucho más económico que reemplazar un modelo o reescribir instrucciones. ## Capa 3: Permisos en el Momento de la Recuperación Esta es la capa que causa el fracaso de proyectos piloto en las auditorías de seguridad. La regla es simple: la recuperación debe ejecutarse en el contexto de los permisos del usuario, no en el contexto de una cuenta de integración amplia. Si una pieza de información estaba oculta para el usuario en la interfaz, también debe estar oculta en la respuesta del agente. En la práctica, se requieren tres pruebas. Primero, un mapeo entre los niveles de clasificación en la fuente externa y los perfiles (Profiles) y conjuntos de permisos (Permission Sets) en Salesforce. Segundo, una prueba de Persona: se ejecutan las mismas diez preguntas con la identidad de un representante, un gerente y un cliente externo y se comparan las respuestas. Tercero, el manejo de contenido mixto: un documento que es mayoritariamente público y un párrafo en él es sensible, debe ser fragmentado o no incluirse. En un canal público, el valor predeterminado seguro es una lista blanca: solo el contenido explícitamente marcado como aprobado para el cliente se indexa y está disponible para el agente externo. Un enfoque de lista negra siempre omitirá un documento. El modelo de responsabilidad entre la organización, Salesforce y el proveedor del modelo se detalla en [Seguridad de Agentforce y Responsabilidad Compartida](/es/insights/agentforce-security-shared-responsibility). ## Capa 4: Citas, Actualidad (Freshness) y Contingencia (Fallback) Estos tres mecanismos transforman un agente de un sistema opaco a uno que puede ser auditado. Una cita auténtica se refiere al fragmento recuperado, no al artículo que el modelo menciona en el texto; esta es la diferencia entre evidencia y adorno. El porcentaje de respuestas con una cita válida es una de las pocas métricas que un gerente no técnico puede leer y comprender. La actualidad (Freshness) requiere un SLA escrito: las políticas de precios se revisan trimestralmente, los procedimientos de servicio semestralmente, el contenido regulatorio inmediatamente después de un cambio. El contenido que ha excedido su fecha de vencimiento debe eliminarse automáticamente del índice y no permanecer hasta que alguien note el error. La contingencia (Fallback) es el comportamiento más importante de verificar antes de la exposición a los clientes. El agente debe indicar explícitamente que no tiene información aprobada y pasar la consulta, en lugar de formular una respuesta plausible. Una buena pregunta para probar: preguntar sobre un producto que no existe y ver si el agente inventa sus términos de servicio. ## Caso de Estudio: Una Compañía de Seguros con 900 Artículos de Knowledge Una compañía de seguros quería un agente que respondiera a los representantes del centro de llamadas sobre las condiciones de las pólizas. El primer proyecto piloto fracasó: el 40% de las respuestas eran incorrectas o incompletas. El análisis mostró que el problema estaba completamente en la capa de fuentes: de 900 artículos, 380 no se habían actualizado en más de tres años, y 60 de ellos contradecían artículos más nuevos sobre el mismo tema. El equipo no tocó el modelo. Redujo el índice a tres productos principales, solo unos 140 artículos, designó propietarios para cada línea de producto y archivó los contradictorios. Agregó etiquetas de producto, año de versión y estado de aprobación, y cambió la fragmentación por sección en lugar de por longitud fija. La segunda ronda con el mismo conjunto de 80 preguntas de prueba logró una precisión mucho mayor y, lo que es más importante, en los casos en que no había una fuente, el agente derivó al problema a una persona en lugar de adivinar. La conclusión que llevó a la expansión no fue "la IA ha mejorado" sino "sabemos en qué se basa". ## Riesgos y Acciones Preventivas | Riesgo | Cómo se detecta tarde | Acción preventiva | | --- | --- | --- | | Fuentes contradictorias | Respuestas diferentes a la misma pregunta entre representantes | Archivo de versiones antiguas y una única fuente de la verdad para cada tema | | Fragmentación que destruye la estructura | Respuestas incompletas en procesos multifásicos | Fragmentación por sección manteniendo el encabezado de contexto | | Permisos a nivel de integración | Exposición de contenido interno en un canal de cliente | Recuperación en el contexto del usuario y pruebas de Persona | | Sin fecha de vencimiento | Cita de una política ya cancelada | SLA para actualización y eliminación automática del índice | | Contingencia (Fallback) indefinida | Formulación de una respuesta convincente sin fuente | Ruta "no hay información aprobada" probada en cada versión | ## Métricas para la Capa de Grounding | Métrica | Definición | Frecuencia | | --- | --- | --- | | Recall de Recuperación | Porcentaje de preguntas en las que se recuperó el fragmento correcto | En cada versión | | Validez de la cita | Porcentaje de respuestas con una fuente existente y válida | Semanal | | Actualidad del Contenido | Porcentaje de artículos en el índice dentro de la fecha de caducidad | Mensual | | Tasa de Contingencia (Fallback) | Porcentaje de consultas transferidas a un agente humano por falta de fuente | Semanal | | Fuga de Permisos | Número de hallazgos de exposición en las pruebas de Persona | En cada versión | Una alta tasa de contingencia (Fallback) no es un fracaso, es un mapa de las brechas de contenido. La lista de preguntas que llevaron a la contingencia es la mejor prioridad para redactar nuevos artículos. Cuando no se dispone de la capacidad interna para establecer una capa de Grounding controlada, el [Servicio de Agentforce e IA](/es/agentforce-ai) es la ruta práctica a seguir. ## Lista de Verificación antes de conectar un Agente a las Fuentes - ☐ Las veinte preguntas más frecuentes están mapeadas a la fuente de la respuesta actual - ☐ Cada fuente en el índice tiene un propietario nominal y una frecuencia de actualización - ☐ Se identificaron y archivaron las fuentes contradictorias - ☐ Existe etiquetado de producto, mercado, idioma, audiencia y fecha de caducidad - ☐ La fragmentación (Chunking) preserva tablas y listas de pasos - ☐ La recuperación se ejecuta en el contexto de los permisos del usuario - ☐ Se realizó una prueba de Persona para cada nivel de permiso relevante - ☐ Existe un conjunto de pruebas de 50 preguntas con respuesta y fuente correctas - ☐ Las citas se refieren al fragmento recuperado - ☐ La ruta de contingencia (Fallback) está formulada y probada en el canal del cliente ### Preguntas y respuestas **¿Cuál es la diferencia entre Grounding y RAG?** RAG es un mecanismo: se recuperan fragmentos de información relevantes y se adjuntan al prompt. Grounding es el compromiso empresarial de que la información recuperada es una fuente de verdad aprobada, actualizada y autorizada para el usuario específico. Es posible implementar un excelente RAG sobre una base de datos desactualizada y obtener respuestas incorrectas con total confianza. **¿Cuántos artículos de Knowledge se necesitan para empezar?** Menos de lo que parece. Es preferible tener veinte artículos actualizados que cubran los diez escenarios más comunes que mil artículos, la mitad de los cuales fueron escritos hace cuatro años. Un artículo contradictorio es más perjudicial que la ausencia de un artículo, porque el agente no puede decidir entre dos versiones. **¿Es posible conectar el agente directamente a SharePoint o Confluence?** Técnicamente sí, mediante la indexación o conexión de datos. La verdadera pregunta son los permisos: si el modelo de permisos en la fuente externa no se puede mapear al usuario en Salesforce, la recuperación podría exponer contenido que el usuario no debería ver. En tal caso, se sincroniza solo un subconjunto clasificado como público-interno. **¿Por qué el agente devuelve una respuesta genérica a pesar de que la información existe en el artículo?** Generalmente, es un problema de fragmentación (Chunking) o metadatos, no un problema del modelo. Si el artículo se fragmenta en medio de una tabla, o no hay etiqueta de producto, país y versión, la recuperación trae un fragmento irrelevante. Una verificación rápida: revise el 'Trace' para ver qué fragmentos se recuperaron realmente antes de culpar al modelo. **¿Qué debe suceder cuando el agente no encuentra una fuente adecuada?** Una ruta de respaldo (Fallback) predefinida: una declaración explícita de que no hay información aprobada y la derivación a una persona o un formulario. Un agente que formula una respuesta plausible sin una fuente es el riesgo principal en el despliegue de cara al cliente, por lo que este comportamiento debe verificarse en cada versión. --- ## Human-in-the-Loop en Agentforce: Cuándo la IA debe detenerse para la aprobación humana URL: https://hpi.pro/es/insights/agentforce-human-in-the-loop La aprobación humana en cada acción anula el valor; la falta de aprobación en cualquier acción genera riesgo. Esta guía presenta una metodología para definir puntos de detención basados en reversibilidad, impacto y sensibilidad, tres patrones de aprobación distintos y condiciones medibles para eliminar puntos de aprobación sin sacrificar el control. ## La Respuesta Corta La pregunta no es si se necesita una persona en el ciclo, sino dónde exactamente. La aprobación en cada paso anula el ahorro y genera fatiga, lo que conduce a una firma automática. La falta de aprobación en operaciones irreversibles genera el tipo de error que llega a la dirección. El método práctico comienza dividiendo el proceso en acciones individuales, clasificando cada acción según su reversibilidad e impacto, y seleccionando un patrón de aprobación adecuado: de bloqueo, a posteriori o por muestreo. Luego, se diseña la pantalla de decisión para que la aprobación sea un juicio genuino y no un simple clic. El marco de gobernanza en el que se toman estas decisiones se detalla en [Gobernanza de IA para Agentforce](/es/insights/agentforce-ai-governance). ## Matriz de Decisión: Reversibilidad vs. Impacto | | Impacto Bajo | Impacto Alto | | --- | --- | --- | | **Fácilmente Reversible** | Sin aprobación, solo monitoreo | Muestreo de un porcentaje de casos para auditoría | | **Reversible con Costo** | Auditoría a posteriori | Aprobación de bloqueo antes de la ejecución | | **Irreversible** | Aprobación de bloqueo antes de la ejecución | Aprobación de bloqueo + justificación escrita + Audit Trail | La reversibilidad se mide con tres preguntas: ¿Cuánto tiempo lleva deshacerla? ¿Cuánto cuesta? y ¿Quién se expone antes de que se deshaga? Un mensaje enviado a un cliente no es reversible, incluso si se puede enviar una corrección, la impresión ya se ha creado. La actualización de un campo interno es reversible en un segundo y, por lo tanto, no justifica una detención. ## Tres Patrones de Aprobación La aprobación de bloqueo detiene la operación hasta la decisión de una persona. Es el patrón más costoso en tiempo y, por lo tanto, se reserva para operaciones irreversibles o de alto impacto. La regla: si detuvimos la operación, la persona debe tener todo lo necesario para la decisión en una sola pantalla. La auditoría a posteriori permite al agente actuar y someter el resultado a revisión dentro de un plazo definido. Es adecuada para operaciones reversibles de bajo costo y requiere dos condiciones: un plazo corto y un botón de cancelación que realmente funcione. El muestreo revisa un porcentaje de los casos y no todos. Este es el patrón correcto para operaciones de alto volumen y bajo impacto, y también es el mecanismo de calidad que permite, en el futuro, justificar la eliminación de una aprobación de bloqueo en otro lugar. ## Diseño de la Pantalla de Decisión Esta es la parte que decide si el "Human-in-the-Loop" es real o formal. Una pantalla que solo muestra la acción propuesta recibe una aprobación automática. Una pantalla que requiere abrir tres pestañas para verificar causa retrasos y omisiones. Cuatro componentes deben aparecer juntos: la acción propuesta en una línea, la justificación en lenguaje de negocios, la fuente en la que se basa el agente con un enlace a la sección extraída, y el nivel de certeza o las banderas activadas. Debajo, tres opciones, no dos: aprobar, rechazar con motivo y corregir antes de ejecutar. La razón del rechazo es el activo más valioso del proceso. Genera el conjunto de entrenamiento y prueba para la próxima versión, por lo que debe ser una lista corta de razones comunes y no un campo de texto libre que nadie completa. Cómo se monitorean estas decisiones a lo largo del tiempo se explica en [Observabilidad para Agentes de IA](/es/insights/agentforce-observability). ## Prevención del "Rubber Stamping" (Aprobación Automática) La fatiga de aprobación es un fallo previsible, no una sorpresa. Tres señales de advertencia: el tiempo promedio de decisión cae por debajo de unos segundos, la tasa de rechazo se acerca a cero y las aprobaciones se concentran al final del turno. El tratamiento no es la capacitación, sino el diseño. Se reduce el número de aprobaciones eliminando las paradas innecesarias en operaciones reversibles, se añade un muestreo a posteriori que genera responsabilidad y se presenta al aprobador retroalimentación sobre la calidad de sus decisiones. Cuando un aprobador sabe que un porcentaje de las decisiones es revisado, la lectura se reestablece. Una métrica clave: si la tasa de correcciones es cero durante meses, o el agente es excelente y se pueden reducir las paradas, o nadie está leyendo. El muestreo es lo que distingue entre los dos. ## Cuándo y Cómo Eliminar un Punto de Aprobación La eliminación es una decisión basada en datos, no en una intuición. Tres condiciones acumulativas: un volumen suficiente de decisiones documentadas en la categoría, una tasa de correcciones baja y estable durante varios meses consecutivos, y un mecanismo de cancelación o suspensión probado en la práctica. La eliminación se realiza por etapas. Primero a un subconjunto estrecho, por ejemplo, solo cantidades por debajo de un cierto umbral, solo clientes en un segmento definido, solo durante horas de actividad. Luego se mide un mes. Solo entonces se amplía. Al mismo tiempo, se mantiene el muestreo a posteriori incluso después de la eliminación, de lo contrario no hay forma de identificar un deterioro. También debe haber una condición de retorno: si la tasa de errores supera un umbral predefinido, la aprobación de bloqueo regresa automáticamente. Sin una condición de retorno escrita, la decisión de eliminar se vuelve irreversible en sí misma. ## Escenario: Un Centro de Servicio que Eliminó la Aprobación Incorrecta Una empresa de telecomunicaciones implementó un agente que preparaba respuestas a consultas de facturación. En la primera versión, cada respuesta pasaba por la aprobación de un representante, incluyendo respuestas de estado simples. El tiempo de gestión solo disminuyó ligeramente, y los representantes se quejaban de leer el mismo texto una y otra vez. El equipo analizó 4,000 aprobaciones y descubrió que el 78% de ellas eran solo respuestas informativas, completamente reversibles y de bajo impacto. La tasa de correcciones en esta categoría era inferior al uno por ciento. En contraste, en la categoría de créditos, la tasa de correcciones era significativamente mayor. La decisión: eliminar la aprobación de bloqueo para respuestas informativas, con un muestreo de un porcentaje de ellas para auditoría semanal; reforzar la aprobación en créditos y añadir la obligación de una justificación escrita por encima de un cierto monto. El tiempo de gestión disminuyó significativamente y los rechazos en la categoría de créditos incluso aumentaron, señal de que los aprobadores volvieron a leer. ## Riesgos y Acciones Preventivas | Riesgo | Cómo se Manifiesta | Acción Preventiva | | --- | --- | --- | | Aprobación de Todo | El valor se pierde y los usuarios lo evitan | Matriz de reversibilidad vs. impacto para cada operación | | Firma Automática | Tiempo de decisión de segundos y cero rechazos | Muestreo a posteriori y retroalimentación personal al aprobador | | Pantalla sin Justificación | El aprobador no puede juzgar realmente | Presentar justificación, fuente y nivel de certeza en una sola pantalla | | Eliminación Temprana | Fallo en producción después de varias buenas semanas | Umbrales de eliminación medibles, expansión por fases y condición de retorno | | Sin Documentación de Rechazos | No hay nada que aprender para la siguiente versión | Lista corta de motivos de rechazo y revisión semanal | ## Métricas | Métrica | Qué Revela | Frecuencia | | --- | --- | --- | | Tasa de Detención | Porcentaje de operaciones que requirieron aprobación | Semanal | | Tasa de Corrección | Porcentaje de casos que el aprobador modificó o rechazó | Semanal | | Tiempo Mediano de Decisión | Si el aprobador realmente lee | Semanal | | Hallazgos de Muestreo | Errores que fueron aprobados | Mensual | | Tiempo Efectivo de Cancelación | Si el mecanismo de retroceso funciona | Con cada versión | Cuando se requiere orientación en la planificación de los puntos de aprobación y su adaptación a la regulación aplicable a la organización, el [servicio de Agentforce y de IA](/es/agentforce-ai) es el camino práctico a seguir. ## Lista de Verificación (Checklist) - ☐ El proceso se descompuso en acciones individuales. - ☐ Cada acción se clasificó según reversibilidad e impacto. - ☐ Se seleccionó un patrón de aprobación para cada acción: de bloqueo, a posteriori o por muestreo. - ☐ El aprobador se definió según la autoridad existente en el proceso. - ☐ La pantalla de decisión muestra la acción, justificación, fuente y nivel de certeza. - ☐ Existe la opción de corregir, no solo aprobar o rechazar. - ☐ Las razones del rechazo se documentan en una lista corta. - ☐ Se definieron umbrales medibles para eliminar aprobaciones y condiciones de retorno. - ☐ El mecanismo de cancelación se probó en la práctica y no solo se planificó. ### Preguntas y respuestas **¿La aprobación humana no anula la ventaja del agente de IA?** No, si se posiciona correctamente. El agente sigue ahorrando en la recopilación de información, el análisis y la redacción, que consumen la mayor parte del tiempo. La persona toma una decisión informada y aprueba en segundos. El valor se pierde solo cuando la aprobación requiere que la persona revise todo lo que hizo el agente. **¿Quién debe aprobar: el agente o el gerente?** Como regla general, quien habría aprobado la acción incluso sin un agente. Si un representante está autorizado a acreditar hasta una cierta cantidad, él es quien aprueba en este caso también. La escalada a un gerente solo es necesaria cuando la cantidad o la sensibilidad exceden la autoridad normal; de lo contrario, se crea un cuello de botella que antes no existía. **¿Cómo se evita la aprobación automática sin revisión?** De tres maneras: presentando la justificación y la fuente, no solo el resultado; muestreando un porcentaje de las aprobaciones para auditorías posteriores; y monitoreando el tiempo de decisión. Una serie de aprobaciones en menos de dos segundos es una señal clara de aprobación automática y exige un cambio en el diseño de la pantalla. **¿Cuándo se puede eliminar un punto de aprobación?** Cuando hay un volumen suficiente de decisiones documentadas, la tasa de correcciones por parte del aprobador es baja y estable durante varios meses, y existe un mecanismo de reversión rápido. La eliminación se realiza por fases, primero para un subconjunto reducido de casos y no para todo el proceso a la vez. **¿Es posible aprobar a posteriori en lugar de antes de la ejecución?** Solo cuando la acción es reversible de forma económica y rápida. Enviar un borrador de correo electrónico interno es adecuado para revisión a posteriori; un abono financiero o un mensaje enviado a un cliente no son reversibles y requieren aprobación previa, incluso si esto ralentiza el proceso. --- ## Implementación de Sales Cloud: Un proceso eficaz desde el Lead hasta la Previsión URL: https://hpi.pro/es/insights/sales-cloud-implementation La implementación de Sales Cloud suele fallar no por configuraciones incorrectas, sino por etapas de venta mal definidas, donde nadie sabe con exactitud cuándo pasar de una a otra. Esta guía muestra cómo construir una cadena única – Lead, Oportunidad, Previsión – donde cada etapa tiene un criterio de salida medible, y por qué esto es la clave para una previsión confiable. ## La respuesta breve La diferencia entre una implementación exitosa y una fallida de Sales Cloud radica casi siempre en una única pregunta: ¿es posible afirmar, en una oración y sin discusión, qué hace que una oportunidad avance de una etapa a la siguiente? Cuando la respuesta existe, el resto —registros, campos, automatizaciones e informes— se deriva de ella. Cuando falta, se obtiene un sistema bien definido que genera una previsión en la que nadie confía. Por lo tanto, el flujo de trabajo es el siguiente: definir las etapas de venta y los criterios de salida, y después el modelo de datos, los permisos, las integraciones y, finalmente, los informes. Hacer lo contrario —empezar por un panel deseado y trabajar en retrospectiva— genera campos que se rellenan para que el informe funcione, no para que la venta se gestione. ## Dónde falla en la práctica En una organización B2B típica, antes de una intervención, se observa lo siguiente: el 40% de las oportunidades en el _pipeline_ con una fecha de cierre ya vencida, una etapa de "Negotiation" que incluye tanto las primeras conversaciones como los contratos en fase de firma, y un gerente de ventas que gestiona la previsión en una hoja de cálculo separada porque no confía en el sistema. Ninguno de estos problemas es una falla técnica; todos son el resultado de definiciones no resueltas. ## Etapas de venta: un criterio de salida para cada etapa La regla simple: una etapa se define por lo que el comprador ha hecho, no por lo que el vendedor siente. "El cliente está interesado" no es un criterio. "Se identificó al decisor y se presupuestó" sí lo es. | Etapa | Criterio de salida medible | Evidencia en el sistema | Probability | | --- | --- | --- | --- | | Qualification | Se identificó una necesidad, el presupuesto y el decisor | Campos de Budget y Decision Maker completados | 10% | | Discovery | Se presentó un mapeo de la necesidad aprobado por el cliente | Documento o Nota vinculada | 25% | | Proposal | Se envió una propuesta con precios y alcance | `Quote` activo | 50% | | Negotiation | El cliente devolvió comentarios comerciales o legales | `Activity` documentada en las últimas dos semanas | 75% | | Closed Won | Firma o PO | Archivo adjunto | 100% | La `Probability` no es un sentimiento del representante, sino una derivada de la etapa. En el momento en que se permite al representante sobrescribirla manualmente, la previsión vuelve a ser subjetiva. ## Lead vs. Opportunity: el límite que determina la calidad del _pipeline_ El error más común es la conversión automática de cada consulta en una `Opportunity`, generalmente para que "parezca llena". El resultado es un _pipeline_ que se triplica y un porcentaje de cierre que se desploma, lo que invalida cualquier análisis histórico. Una definición funcional: un `Lead` sigue siendo un `Lead` hasta que se cumplen tres condiciones: un contacto identificado con autoridad, una necesidad formulada en palabras del cliente y un horizonte temporal. Una consulta que no cumple con esto se gestiona como `Lead` en `Nurture`, no como una oportunidad. Esto también permite medir realmente la tasa de conversión entre marketing y ventas en lugar de medir la generosidad de la conversión. Quienes construyan el modelo de datos detrás de esto encontrarán una base en [diseño del modelo de datos en Salesforce](/es/insights/salesforce-data-model-design). ## Actividades: exigir poco, en los puntos clave El registro de actividades es el punto donde las implementaciones pierden la confianza de los representantes. La obligación de documentar cada interacción se percibe como control, se responde con una documentación mínima y sin valor, y genera datos peores que la falta de documentación. El enfoque que funciona es exigir el registro solo en tres puntos: el avance entre etapas, el cambio de monto por encima de un umbral definido y el aplazamiento de la fecha de cierre. En cada uno de estos casos, la documentación también sirve al propio representante, ya que explica una decisión sobre la que se le preguntará en una reunión. La sincronización automática de correo electrónico y calendario cubre el resto sin necesidad de teclear. ## Forecast: lo que debe estar en su lugar antes de activarlo Una previsión fiable requiere cuatro condiciones previas, y todas actúan como una cadena: un eslabón perdido anula los demás: 1. **Jerarquía de usuarios correcta**: el _Forecast_ en Salesforce se despliega según la `Role Hierarchy`, no según una estructura organizativa en una hoja de cálculo. 2. **Fechas de cierre limpias**: una regla operativa que no permite que una oportunidad permanezca con una fecha vencida por más de una semana. 3. **Categorías de _Forecast_ definidas**: `Pipeline`, `Best Case`, `Commit`, `Closed`, con una definición acordada de quién mueve una oportunidad a `Commit` y cuándo. 4. **Ciclo de revisión regular**: una reunión semanal de _Pipeline_ que se lleva a cabo dentro del sistema y no desde una hoja de cálculo paralela. El último punto es crucial. Mientras exista una hoja de cálculo en la sombra, los representantes saben que el sistema no es la fuente de la verdad y lo actualizan con retraso. ## Qué medir después de la puesta en marcha | Métrica | Qué revela | Umbral problemático | | --- | --- | --- | | Forecast accuracy | Brecha entre la previsión de Commit y el resultado | Desviación superior al 20% por trimestre | | Stage aging | Oportunidades estancadas en una etapa | Más del doble de la mediana | | Actualización en 7 días | Si el sistema refleja la realidad | Menos del 70% de las oportunidades activas | | Data completeness | Campos obligatorios en etapas avanzadas | Menos del 90% | Medidas de adopción más profundas se detallan en [métricas de adopción de Salesforce](/es/insights/salesforce-adoption-metrics). ## Qué no hacer en la primera fase La gestión compleja de territorios (`Territory Management`), múltiples modelos de _Forecast_, un `CPQ` completo y la puntuación automática (`Scoring`) son todas capacidades que es correcto añadir una vez que el proceso básico es estable y han transcurrido dos ciclos de ventas. Añadirlas en la primera fase solidifica suposiciones que aún no se han probado, y aumenta en gran medida el costo de cualquier cambio futuro. ## Resumen La implementación de Sales Cloud es principalmente un trabajo de definiciones de negocio: cuándo una oportunidad avanza de etapa, cuándo una consulta se convierte en oportunidad, y qué requiere documentación. Estas tres decisiones determinan si la previsión será una herramienta de gestión o un ejercicio de reporte. La herramienta en sí soportará cualquier definición que elija, incluso una mala. ### Preguntas y respuestas **¿Cuántas etapas de Oportunidad se recomienda definir?** Generalmente entre cuatro y seis. Un número mayor puede parecer más preciso, pero crea etapas indistinguibles, llevando a que los representantes las actualicen con retraso o todas a la vez antes de la reunión de Pipeline. **¿Cuál es la diferencia práctica entre un Lead y una Oportunidad?** Un Lead es un interés aún no cualificado, mientras que una Oportunidad es una transacción con un comprador identificado, una necesidad definida y un horizonte temporal. Si la conversión se realiza automáticamente para cada consulta, el Pipeline se infla y la previsión pierde significado. **¿Es obligatorio registrar las actividades?** Exigir un registro indiscriminado genera documentación formal sin valor. Es preferible exigir el registro en puntos donde impacte una decisión: al cambiar de etapa, modificar el importe o posponer la fecha de cierre. **¿Cuándo se debe integrar CPQ o la configuración de precios?** Solo después de que las etapas de venta y la estructura de productos sean estables. Integrar la fijación de precios en un proceso aún cambiante duplica el costo de las modificaciones y perpetúa suposiciones temporales. **¿Cuánto tiempo se tarda en obtener una previsión fiable?** Generalmente, dos o tres ciclos de venta completos después de la puesta en marcha. Antes de eso, no hay suficientes transacciones gestionadas según las nuevas definiciones para comparar la previsión con el resultado real. --- ## Implementación de Service Cloud: Casos, SLA, Enrutamiento y Knowledge URL: https://hpi.pro/es/insights/service-cloud-implementation Muchos centros de servicio implementan Service Cloud y descubren que el tiempo de respuesta no mejora. La razón, casi siempre, no es la herramienta, sino cuatro decisiones clave que no se han resuelto: qué se considera un caso, quién lo atiende, cuándo se comienza a contar el tiempo y qué sucede cuando la respuesta ya existe. Esta guía desglosa estas cuatro decisiones en entregables verificables. ## La respuesta breve Service Cloud no reduce por sí mismo los tiempos de respuesta, sino que aplica las configuraciones que se le proporcionan. Si no se ha definido qué constituye un Case, quién lo recibe y cuándo empieza a contabilizarse el tiempo, el sistema medirá con precisión un proceso indefinido. En consecuencia, las métricas podrían parecer mejores o peores de lo que son en realidad, sin una conexión directa con la calidad del servicio. Cuatro decisiones clave determinan el resultado: la definición de un Case, el modelo de asignación, el reloj del SLA y la ubicación del conocimiento. El resto de la implementación (pantallas, canales, automatizaciones) se deriva de estas. ## Decisión 1: Qué constituye un Case Muchos centros de contacto abren un Case para cada interacción con el argumento de que "así se tienen datos". El resultado es el opuesto: miles de registros que se cierran en un minuto inflan el volumen, mejoran artificialmente el tiempo medio de resolución y ocultan las solicitudes que realmente se estancan. Una definición efectiva distingue entre tres tipos: | Tipo de interacción | ¿Se abre un Case? | Razón | |---|---|---| | Pregunta respondida en la llamada | No, se registra como Interacción | No requiere seguimiento ni compromiso | | Solicitud que requiere acción o espera | Sí | Necesita seguimiento y SLA | | Incidencia que podría repetirse | Sí, con clasificación de causa | Requiere análisis de tendencias | ## Decisión 2: Quién recibe la solicitud El fallo común es el Routing basado únicamente en el departamento, lo que crea una gran cola de la que los agentes "pescan" las solicitudes sencillas. Las solicitudes complejas envejecen en la parte inferior de la cola hasta que alguien las escala telefónicamente, y todo el mecanismo de SLA se convierte en una simulación. Un modelo de asignación adecuado define tres dimensiones: la habilidad requerida, la capacidad real del agente (no el número de Cases, sino su 'peso') y las reglas de escalada basadas en tiempo. El Omni-Channel Routing soporta las tres, pero solo si se han definido habilidades reales. Definir "habilidad: soporte" para todos los agentes es equivalente a no definir nada. Una descripción completa de la asignación omnicanal se encuentra en [Omnichannel y SLA en Service Cloud](/es/insights/service-cloud-omnichannel-sla). ## Decisión 3: Cuándo corre el reloj Esta es la decisión que más organizaciones omiten, y es la que determina la fiabilidad de las métricas. Preguntas que deben tener una respuesta documentada: 1. **¿Cuándo se inicia el reloj?** – ¿En el momento de recibir la solicitud o al inicio del siguiente horario laboral? Los Business Hours deben definirse para cada zona horaria relevante. 2. **¿Cuándo se detiene?** – Un Case en espera de respuesta del cliente debe pausar el contador; de lo contrario, el centro de contacto es penalizado por la lentitud del cliente. 3. **¿Qué se mide exactamente?** – Tiempo de primera respuesta, tiempo de resolución, o ambos con objetivos separados para cada nivel de urgencia. 4. **¿Qué sucede antes de una desviación?** – Un Milestone que genera una alerta al 80% del tiempo es más valioso que un informe mensual de desviaciones. Los Entitlements y Milestones son el mecanismo que implementa estas cuatro preguntas. Activarlos sin una decisión escrita previa generará alertas que se ignorarán en dos semanas. ## Decisión 4: Dónde se encuentra el conocimiento La Knowledge Base no es un proyecto separado, sino una condición para reducir la carga de trabajo. El fallo habitual: los artículos se escriben en el lanzamiento, nadie los mantiene y, en seis meses, los agentes vuelven a preguntar en un chat interno. Lo que funciona: un ciclo de vida definido para cada artículo: Owner, fecha de revisión y métrica de uso. Un Case cerrado sin un artículo vinculado y que aparece cinco veces en el mismo trimestre es un disparador automático para la creación de un artículo. Para profundizar en el tema, consulte [Gestión del conocimiento en Salesforce](/es/insights/salesforce-knowledge-management). ## Métricas operativas | Métrica | Definición | Umbral de revisión | |---|---|---| | First response time | Hasta el primer contacto humano | Desviación superior al 10% de los Cases | | First contact resolution | Cerrado sin escalada | Por debajo del 60% | | Reopen rate | Case reabierto en 7 días | Superior al 8% | | Backlog aging | Cases abiertos por encima del SLA | Tendencia semanal al alza | | Knowledge attach rate | Cases con artículo vinculado | Por debajo del 30% | El "Reopen rate" es la métrica más importante y generalmente la más descuidada: expone cierres prematuros realizados para cumplir con el objetivo de tiempo. ## Orden de trabajo recomendado Primera fase: Definición de Case, uno o dos canales, Routing básico, SLA para un nivel de urgencia y diez artículos de Knowledge para las preguntas frecuentes. Segunda fase: Canales adicionales, habilidades, Entitlements completos, Self-Service. Implementar todo a la vez genera un centro de contacto que se enfrenta a cambios de proceso, cambios de herramienta y cambios de medición en la misma semana, y generalmente vuelve a las soluciones parciales. ## Resumen Una implementación exitosa de Service Cloud se mide por una pregunta: ¿Puede el director del centro de contacto mostrar, desde el sistema y sin hojas de cálculo auxiliares, dónde se encuentran las solicitudes que exceden el tiempo y por qué? Si las cuatro decisiones están cerradas, la respuesta existe. Si no, se tendrá un nuevo sistema, pero el mismo centro de contacto. ### Preguntas y respuestas **¿Cada consulta debe abrirse como un caso?** No. Una pregunta que se responde en una llamada y no requiere seguimiento no es un caso. La apertura indiscriminada infla los datos y distorsiona las métricas de volumen y resolución. La regla práctica: un caso se abre cuando se necesita seguimiento, compromiso de tiempo o documentación para análisis. **¿Enrutamiento basado en cola (Queue-based) o en Omni-Channel?** Las colas son adecuadas para centros de contacto pequeños con agentes multifuncionales. Omni-Channel es necesario cuando hay canales paralelos, diferentes habilidades o la necesidad de equilibrar la carga según la capacidad real. **¿Es obligatorio activar Entitlements para gestionar el SLA?** Es posible medir el SLA solo con informes, pero los Entitlements y Milestones son lo que permite la alerta proactiva y la escalada antes de un incumplimiento, no solo el reporte retrospectivo del mismo. **¿Cuándo se añade un Portal o un servicio de autoservicio?** Después de que la base de conocimientos (Knowledge Base) contenga respuestas reales a las preguntas más frecuentes. Un portal que redirige a una base de conocimientos vacía aumenta el número de consultas a través de otros canales. **¿Cuántos tipos de casos se recomienda definir?** Pocos, generalmente de tres a cinco, con un campo de clasificación secundario. Una taxonomía demasiado detallada hace que los agentes elijan la primera opción de la lista y pierde el valor del análisis. --- ## Sales Cloud vs. Service Cloud: ¿Cuál es la diferencia y qué necesita su organización? URL: https://hpi.pro/es/insights/sales-cloud-vs-service-cloud La pregunta sobre qué Cloud adquirir se presenta como una comparación de productos, pero en realidad es una cuestión sobre la estructura del trabajo: ¿la unidad que se gestiona es una oportunidad con un progreso, o una solicitud con un tiempo de respuesta? Esta guía diferencia ambos según objetos, métricas y licenciamiento, y muestra cuándo se necesitan ambos y cómo conectarlos sin duplicar datos. ## La respuesta breve Sales Cloud gestiona una **negociación en curso**: una unidad de trabajo que dura semanas o meses, se mide por la probabilidad de cierre y tiene éxito cuando se cierra. Service Cloud gestiona una **solicitud que se resuelve**: una unidad de trabajo que dura horas o días, se mide por el tiempo de respuesta y resolución, y tiene éxito cuando se cierra rápidamente y sin repetición. Esta diferencia, y no la lista de funcionalidades, determina la elección. Si se gestiona un **Pipeline**, es Sales Cloud. Si se gestiona una cola con SLA, es Service Cloud. Si se gestiona un cliente que compra y también se queja, son ambos, sobre la misma **Account**. ## La diferencia en términos operativos | Dimensión | Sales Cloud | Service Cloud | |---|---|---| | Objeto principal | Opportunity | Case | | Ciclo de vida | Semanas a meses | Horas a días | | Métrica clave | Tasa de cierre (Win rate), Precisión de pronóstico (Forecast accuracy) | Primera respuesta, Resolución en la primera llamada (FCR), Satisfacción del cliente (CSAT) | | Mecanismo de asignación | Propiedad personal a largo plazo | Enrutamiento dinámico según disponibilidad | | Origen de la carga | Número de negociaciones activas | Picos inesperados en los canales | | Componente de conocimiento | Playbooks y precios | Base de conocimientos integrada (Knowledge Base) | La línea más importante es el mecanismo de asignación. En ventas, la propiedad personal es un valor: el cliente desea un contacto constante. En servicio, la propiedad personal es un problema: crea colas individuales que se estancan cuando un agente está de vacaciones. ## Cuándo la elección es clara **Solo Sales Cloud** es adecuado para una organización que vende a través de un proceso continuo y donde el soporte postventa es mínimo o manejado por un socio, como un proveedor de equipos que vende a través de distribuidores y no opera un centro de contacto. **Solo Service Cloud** es adecuado para una organización cuya interacción con el cliente se limita al manejo de solicitudes: una empresa de servicios operativos, un organismo público o un proveedor de infraestructura con contratos existentes. Se requieren **ambos** cuando hay renovación, *upsell* o retención: en el momento en que un agente de servicio necesita saber que el cliente está en proceso de renovación, y un vendedor necesita saber que el cliente ha abierto tres incidencias graves este mes, la separación se convierte en un impedimento. ## Cómo conectar sin duplicar datos Este es el punto donde las implementaciones combinadas fallan. La regla es: **Account y Contact son una única capa compartida**. No existen "clientes de ventas" y "clientes de servicio" separados. De esto se derivan tres decisiones: 1. **Propiedad del registro del cliente**: Quién actualiza la información de contacto, la dirección y la estructura organizacional. Generalmente el servicio, porque interactúa con el cliente con mayor frecuencia. 2. **Visibilidad mutua**: El agente de servicio ve las negociaciones abiertas en modo *solo lectura*; el vendedor ve las incidencias abiertas y el índice de satisfacción. Ambas direcciones se configuran en el modelo de Sharing, no copiando campos. 3. **Disparadores interfuncionales**: Una incidencia crítica con un cliente en renovación genera una alerta para el *Account Manager*. Este mecanismo es más valioso que cualquier panel de control integrado. Puede encontrar más información sobre permisos y visibilidad en [Modelo de Sharing y visibilidad en Salesforce](/es/insights/salesforce-sharing-visibility-design). ## Licenciamiento: Lo que debe saber antes de comparar precios Una licencia de Service Cloud es un superconjunto: incluye las capacidades básicas de Sales Cloud, por lo que un usuario que necesita ambos no requiere dos licencias. La inversa no es cierta: una licencia de Sales no incluye la gestión de casos (*Case management*), Entitlements o Knowledge. El significado práctico es que un cálculo de costos correcto comienza con la asignación de usuarios según lo que realmente hacen, no según el departamento al que pertenecen. Un representante que en dos meses del año contacta con una negociación no es un usuario de ventas. ## Orden de implementación cuando se necesitan ambos La implementación paralela parece eficiente, pero en realidad duplica el riesgo: dos procesos que cambian simultáneamente, dos grupos de usuarios en formación, y la imposibilidad de atribuir mejoras o fallos a una única fuente. El orden recomendado es empezar por el lado con el dolor más cuantificable, generalmente el servicio, porque el tiempo de respuesta y la pérdida de clientes ya se miden actualmente. Después de dos meses de operación estable, se añade el otro lado. La capa compartida (Account, Contact, permisos) se construye en la primera fase, incluso si solo un lado entra en funcionamiento, de lo contrario, la segunda fase requerirá una reconstrucción. ## Resumen La pregunta no es qué producto es mejor, sino qué unidad de trabajo gestiona la organización: una negociación en curso o una solicitud que se resuelve. La mayoría de las organizaciones consolidadas gestionan ambas, y entonces la verdadera decisión no es qué comprar, sino cómo mantener una única capa de cliente subyacente para ambas. ### Preguntas y respuestas **¿Es posible gestionar solicitudes de servicio en Sales Cloud sin Service Cloud?** Técnicamente sí, mediante un objeto personalizado o una Tarea. Sin embargo, una vez que se requieren SLA, enrutamiento por disponibilidad, Base de Conocimiento o canales, el costo de la construcción propia supera la diferencia en el licenciamiento. **¿Se necesitan dos Orgs separados?** Casi siempre no. Ambos Clouds residen en el mismo Org y comparten las cuentas y contactos. La separación en Orgs solo se considera por motivos regulatorios o para empresas completamente independientes. **¿Qué sucede con un usuario que necesita ambos?** Un usuario con licencia de Service Cloud también obtiene las capacidades básicas de Sales Cloud. La dirección opuesta no es cierta: una licencia de Sales no incluye la gestión completa de Casos. **¿Cuál es la diferencia en la definición de éxito entre ambos?** Las ventas se miden por el progreso y el porcentaje de cierre en semanas; el servicio se mide por el tiempo de respuesta, la resolución en la primera interacción y la satisfacción del cliente en horas. Esta diferencia de ritmo afecta la frecuencia de medición, la carga de automatizaciones y la planificación del rendimiento. **¿Por dónde empezar si se necesitan ambos?** Por el lado donde el problema es más medible. La implementación paralela de ambos duplica el alcance del cambio organizacional y dificulta identificar qué causó la mejora o el fracaso. --- ## Gestión del Cambio en Implementaciones de Salesforce: Plan de Trabajo Pre y Post Go-Live URL: https://hpi.pro/es/insights/salesforce-change-management-plan La gestión del cambio va más allá de la semana de capacitación previa a la puesta en marcha. Presentamos un plan de trabajo de cuatro fases —mapeo de impacto, involucramiento de stakeholders, comunicación y ciclo de gestión— con entregables, responsables y métricas para cada etapa. ## La respuesta corta La gestión del cambio no es una actividad de comunicación que se adhiere al final del proyecto. Es un flujo de trabajo paralelo que comienza en la fase de descubrimiento y concluye meses después de la puesta en marcha. La brecha entre los proyectos exitosos y los fallidos casi siempre reside aquí, no en el código. Cuatro etapas, cada una con un entregable definido: mapeo de impacto, involucramiento de stakeholders, comunicación y capacitación, y un ciclo de gestión continuo. ## Etapa 1 – Mapeo de impacto por rol Antes de diseñar una sola pantalla, se define para cada rol afectado: qué hace actualmente, qué cambiará, qué será más sencillo, qué será más complejo y qué se evaluará de manera diferente. Las líneas tercera y cuarta son cruciales: los proyectos fracasan cuando alguien descubre, solo al salir en vivo, que ha perdido el control o ha asumido una carga de trabajo adicional. | Rol | Qué cambia | Riesgo principal | Respuesta planificada | | --- | --- | --- | --- | | Representante de ventas | Registro en el sistema en lugar de Excel personal | Carga de entrada, pérdida de control | Formulario reducido, valor recurrente diario | | Gerente de ventas | Pronóstico basado en el sistema | Exposición a cifras poco favorables | Preparación previa, Dashboard privado para período de transición | | Back Office | Nuevo proceso de aprobación | Retrasos durante el período de transición | Práctica previa, procedimiento de excepciones | | Dirección | Única fuente de verdad para informes | Discrepancias con informes antiguos | Comparación paralela durante un trimestre | El resultado es un documento de dos a cuatro páginas, que sirve como insumo para el diseño de la solución. ## Etapa 2 – Stakeholders y patrocinio (Sponsorship) Un patrocinador (Sponsor) genuino es quien puede modificar un proceso, un objetivo o una recompensa. Un patrocinador que solo aparece en un mensaje de bienvenida no es un patrocinador real. Tres compromisos mínimos que conviene obtener por escrito: - Participación en la revisión mensual del proyecto y en la toma de decisiones pendientes. - Declaración explícita sobre la fuente de la verdad y el cese de informes paralelos en una fecha definida. - Respaldo para el cambio de un proceso, incluso cuando resulte incómodo para un departamento específico. Junto al patrocinador, se construye una red de representantes en el campo que funciona como un canal bidireccional; detalles en la creación de una [red de Champions en Salesforce](/es/insights/salesforce-champions-network). ## Etapa 3 – Comunicación diferente a lo habitual Una comunicación efectiva responde a una pregunta del usuario: ¿qué significa esto para mí? Los mensajes que hablan de "transformación digital" se perciben como ruido. Tres principios: 1. **Segmentación por rol**: Un único mensaje para toda la organización no funciona. Al representante se le explica qué cambia en su pantalla; al gerente, qué cambia en la revisión. 2. **Reconocimiento del costo**: Expresar explícitamente qué será más difícil. La negación erosiona la confianza más rápido que cualquier desventaja real. 3. **Ritmo constante**: Una actualización corta quincenal desde la fase de Discovery hasta Hypercare, incluso cuando no haya noticias dramáticas. La capacitación se estructura en torno a escenarios de trabajo y no a pantallas; la estructura recomendada se detalla en la [capacitación de Salesforce por rol](/es/insights/salesforce-role-based-training). ## Etapa 4 – El ciclo de gestión posterior a la puesta en marcha (Go Live) Esta es la etapa que más se omite y la que más influye. El cambio se consolida solo cuando se integra en la rutina de gestión: - Revisión semanal del equipo desde el Dashboard del sistema, no desde un archivo. - Informe mensual a la dirección generado exclusivamente desde el sistema. - Un canal abierto para solicitudes con lanzamientos periódicos y comunicación de lo que se ha corregido. - Medición mensual de la adopción según las [métricas de adopción de Salesforce](/es/insights/salesforce-adoption-metrics). La fecha límite significativa no es el Go Live, sino el día en que cesa el informe paralelo. Mientras exista un informe "sombra" legítimo, el sistema seguirá siendo secundario. ## Riesgos comunes y señales de advertencia tempranas | Señal de advertencia | Significado | Respuesta | | --- | --- | --- | | El patrocinador omite dos revisiones consecutivas | Falta de apropiación empresarial | Escalar el problema a la dirección antes de la UAT | | Crece la cantidad de solicitudes para "solo un campo más" | El proceso no fue acordado | Congelar y reevaluar el proceso | | La capacitación se pospone por presión de plazos | El proyecto se lanzará sin preparación | Posponer el Go Live solo para el equipo relevante | | Los gerentes piden "también el informe antiguo" | Falta de confianza en los datos | Corrección de datos antes de ampliar el alcance (Scope) | ## Métricas para el plan de cambio Se miden cuatro: el porcentaje de usuarios que completaron la capacitación por escenarios, la tasa de ejecución de una operación esencial en las primeras dos semanas, el número de archivos "sombra" activos y el tiempo promedio de cierre de una solicitud de cambio. Los tres primeros indican la asimilación; el cuarto, la confianza en el canal. ## Resumen Un buen plan de gestión del cambio comienza con un mapeo de impacto en la fase de planificación, se apoya en un patrocinador con autoridad real, se comunica por rol y continúa como un ciclo de gestión meses después de la puesta en marcha. Esta es la parte menos costosa del proyecto y la que más influye en su retorno de inversión (ROI). ### Preguntas y respuestas **¿Cuándo debe iniciarse la gestión del cambio en un proyecto Salesforce?** Debe iniciarse durante la fase de Descubrimiento, paralelamente a la recolección de requisitos. El mapeo del impacto en los roles es un insumo para la planificación de la solución, no un resultado. Comenzar durante la fase de pruebas retrasa el proceso unos tres meses. **¿Qué presupuesto se asigna a la gestión del cambio?** Un rango común es del 10% al 15% del presupuesto total del proyecto para implementaciones de tamaño medio, y puede ser mayor si hay cambios en la estructura organizacional o en el esquema de compensación. En proyectos donde este monto se reduce, el costo generalmente reaparece más tarde como un proyecto de recuperación. **¿Quién es responsable de la gestión del cambio: RRHH, PMO o el equipo de CRM?** La responsabilidad final recae en el Patrocinador (Sponsor) del negocio. RRHH o PMO proporcionan la metodología y las herramientas, el equipo de CRM aporta el contenido; sin embargo, las decisiones sobre cambios de procesos y compensaciones deben tomarse a nivel de negocio. **¿Cómo se aborda la resistencia de los gerentes intermedios?** Los gerentes intermedios suelen oponer resistencia principalmente cuando el sistema genera una transparencia que les resulta amenazante o cuando les añade carga de trabajo. La solución es ofrecerles valor de gestión prioritario, por ejemplo, un Dashboard que les permita prescindir de la elaboración de informes manuales. **¿Qué sucede después de la fase de 'Hypercare'?** Continúan tres aspectos clave: un ciclo定期 de revisión de gestión basado en el sistema, un canal abierto para solicitudes con lanzamientos periódicos, y la medición mensual de la adopción. Sin estas acciones, el cambio tiende a revertirse en un plazo de dos trimestres. --- ## Capacitación de Salesforce por rol: cómo elaborar un programa que genere autonomía URL: https://hpi.pro/es/insights/salesforce-role-based-training La capacitación que solo explica pantallas se olvida en una semana. Estructure un programa de capacitación basado en escenarios: una ruta separada para cada rol, práctica con datos reales en un entorno sandbox, una prueba de autonomía y mantenimiento continuo para los recién incorporados. ## La respuesta corta La formación que explica la ubicación de cada botón se olvida al final de la semana. La formación que practica los escenarios que el usuario realmente ejecuta —"un cliente llama y solicita una propuesta", "la oferta se ha estancado", "es necesario cerrar un caso con un reembolso"— perdura, porque se vincula a la memoria del trabajo mismo. La estructura: una ruta separada para cada función, de dos a cuatro horas, basada en la práctica en un entorno de pruebas ("sandbox") con datos familiares, y que culmina con un examen práctico de autonomía. ## Por qué falla la formación genérica Una formación uniforme para toda la organización enseña el denominador común, es decir, principalmente la navegación. Cada función sale de ella con un 20% de contenido relevante y un 80% de ruido, y llega al primer día sin saber cómo realizar su tarea de principio a fin. El resultado es recurrir al soporte para cada acción, o retroceder al antiguo método de trabajo. Además, la formación genérica oculta problemas de interfaz. Si se necesitan 40 minutos para explicar cómo introducir una oportunidad, el problema no está en la formación sino en la pantalla, un tema que se aborda en [Simplificación de la UX en Salesforce](/es/insights/salesforce-ux-simplification). ## Rutas de formación por función | Función | Escenarios clave | Duración | Examen de autonomía | |---|---|---|---| | Representante de Ventas | De "lead" a oportunidad, avance de etapa, cotización, registro de actividad | 3 horas | Cierre de ciclo completo sin ayuda | | Gerente de Ventas | Revisión de "Pipeline", pronóstico, aprobación de excepción, análisis de equipo | 3 horas | Gestión de revisión semanal desde el sistema | | Representante de Servicio | Apertura de "Case", clasificación, escalamiento, cierre con código de motivo | 3 horas | Gestión de tres "Cases" diferentes dentro del tiempo objetivo | | "Back Office" | Aprobaciones, correcciones de datos, excepciones | 2 horas | Gestión de la cola diaria de aprobaciones | | Dirección | Lectura de "Dashboard", preguntas sobre un dato | 1 hora | Toma de decisiones únicamente desde el sistema | ## Estructura de una sesión eficaz División 20/60/20: 20% contexto —¿por qué cambió y qué me aporta?; 60% práctica manual con escenarios; 20% preguntas y manejo de excepciones. Una conferencia sin un teclado abierto no es formación. La práctica se realiza en un entorno de pruebas ("sandbox") con datos que se asemejan a la realidad de los participantes: nombres de clientes conocidos, importes razonables, productos reales. Los datos de prueba genéricos generan desconexión y dificultan la transición al trabajo real. ## Examen de autonomía Un plan de formación debe tener un criterio de finalización medible. El criterio no es la asistencia ni un cuestionario de conocimientos, sino el desempeño: el participante realiza su escenario central de principio a fin, solo, en un tiempo razonable, sin preguntar. Quien no apruebe recibe una práctica adicional corta y no una formación completa repetida. El fracaso repetido de muchos en la misma etapa es un indicio de un problema de proceso o interfaz, y debe abordarse antes del lanzamiento. ## Materiales de apoyo: concisos y por tarea Después de la formación, lo que realmente se necesita es un documento de una página por cada función y una biblioteca de videos de uno a tres minutos por tarea. Las dos reglas: búsqueda por pregunta ("¿cómo muevo una oportunidad a la siguiente etapa?") y no por módulo, y un propietario definido para actualizar el material con cada cambio del sistema. Un manual de usuario de 60 páginas se escribe una vez, se vuelve obsoleto en dos meses y no se lee. No invierta en él. ## Soporte en las primeras semanas En las dos semanas posteriores al lanzamiento, se requiere la presencia de representantes de campo que puedan ofrecer ayuda in situ. Esta red —"Champions"— es el brazo operativo de la formación, y su construcción se detalla en [La red de Champions en Salesforce](/es/insights/salesforce-champions-network). Toda la formación es un componente dentro de un plan más amplio: [Plan de Gestión del Cambio de Salesforce](/es/insights/salesforce-change-management-plan). ## Los que se incorporan después del lanzamiento En un año, una parte significativa de los usuarios no habrá asistido a la formación original. Sin un programa de incorporación regular, la adopción se erosiona silenciosamente. El programa de incorporación incluye: acceso a la ruta de formación de su función dentro de las dos semanas posteriores a la incorporación, acompañamiento de un "Champion" en el equipo y el examen de autonomía. Esta es la acción más económica para mantener la adopción a largo plazo. ## Medición Evaluamos tres métricas: tasa de aprobación en el examen de autonomía, volumen de solicitudes de soporte en el primer mes por tema, y tasa de ejecución de la operación principal en las primeras dos semanas según [Métricas de Adopción de Salesforce](/es/insights/salesforce-adoption-metrics). La concentración de solicitudes sobre un mismo tema casi siempre indica una corrección necesaria en el sistema y no en la formación. ## Resumen Diseñe una ruta para cada función en torno a escenarios de trabajo, practique en un entorno de pruebas ("sandbox") con datos familiares, finalice con un examen práctico de autonomía y mantenga un programa de incorporación para los recién llegados. Una buena formación no enseña un sistema, sino cómo realizar el trabajo dentro de él. ### Preguntas y respuestas **¿Cuántas horas de capacitación necesita un usuario final?** Entre dos y cuatro horas para los escenarios principales, divididas en dos sesiones cortas en lugar de una sesión larga. Los gerentes requieren una hora adicional para informes y revisión. Más que eso genera olvido, no conocimiento. **¿Es mejor un video grabado o una capacitación en vivo?** Una combinación. La capacitación en vivo es ideal para practicar los escenarios centrales, ya que permite hacer preguntas. Un video corto de uno a tres minutos sirve como biblioteca de referencia por tarea. Casi nadie ve un video largo de 40 minutos. **¿Cuándo debe impartirse la capacitación en relación con el lanzamiento (Go Live)?** Una semana a diez días antes. Una capacitación con un mes de anticipación se olvida, y una capacitación el día anterior choca con la presión del lanzamiento. Los usuarios que se incorporan después del lanzamiento siguen la misma ruta dentro de las dos semanas de asumir su puesto. **¿Cómo se capacita si el sistema aún está cambiando?** Congelar los procesos clave dos semanas antes de la capacitación y documentar los cambios posteriores como una breve lista de delta. Capacitar sobre un sistema en constante cambio genera desconfianza inmediata. **¿Qué se hace con los usuarios que no asistieron a la capacitación?** Bloquear el acceso hasta que completen una ruta corta, con el respaldo de la gerencia. Un usuario que ingresa al sistema sin capacitación genera datos incorrectos por los que todos pagan. --- ## Métricas de Adopción de Salesforce: Por Qué los Inicios de Sesión No Son Suficientes URL: https://hpi.pro/es/insights/salesforce-adoption-metrics Un inicio de sesión es una métrica de presencia, no de valor. Guía práctica para construir un conjunto de métricas de adopción que midan acciones clave, calidad de datos y resultados de negocio, incluyendo línea base, segmentación por rol y un plan de acción para cada hallazgo. ## La Respuesta Breve El inicio de sesión (Login) demuestra que alguien accedió al sistema. Sin embargo, no prueba que se haya trabajado dentro de él, que los datos ingresados sean fiables o que el directivo pueda tomar una decisión basándose en ellos. Una organización que reporta un 92% de Logins y, al mismo tiempo, gestiona su pronóstico en Excel, no ha adoptado Salesforce; solo lo ha abierto. Una métrica de adopción útil responde a una pregunta clave: **¿El proceso de negocio se ejecuta de principio a fin dentro del sistema, con una calidad que permite confiar en él?** De esta premisa se derivan cuatro niveles de medición: acciones principales, calidad de los datos, velocidad del proceso y resultado de negocio. ## Tres Niveles de Adopción | Nivel | Qué se mide | Ejemplo | Qué significa | | --- | --- | --- | --- | | Presencia | Login, tiempo de permanencia | El 92% inició sesión esta semana | Casi nulo | | Uso activo | Acciones principales por rol | El 78% de las oportunidades actualizadas en 7 días | El proceso está en marcha | | Valor | Resultado de negocio + calidad | Desviación del pronóstico disminuyó del 31% al 12% | La adopción generó valor | La mayoría de las organizaciones se quedan en el primer nivel porque es el único disponible sin esfuerzo adicional. Los dos niveles siguientes requieren una decisión preliminar: definir cuál es la "acción principal" para cada rol. ## Cómo Definir una Acción Principal Una acción principal es aquella sin la cual el proceso se interrumpe. No es la acción más frecuente, sino la más crítica. Para un representante de ventas, suele ser la actualización de la etapa y la fecha de cierre; para un gerente de ventas, es la revisión semanal del Pipeline dentro de Salesforce; para un agente de servicio, es el cierre de un Case con un código de motivo correcto. La regla práctica es: si la acción no se realizó, alguien en la cadena de valor trabajará con información incorrecta. Si nadie se ve afectado por la omisión, no es una acción principal y, a veces, ni siquiera debería ser un campo obligatorio. Para cada rol, se define una o dos acciones principales, se documentan explícitamente en la descripción del puesto y se mide el porcentaje de usuarios que las realizaron en el plazo relevante para el proceso. ## Capa de Calidad de los Datos Una acción mal realizada puede ser peor que una acción no realizada, ya que genera una falsa confianza. Por ello, cada métrica cuantitativa debe ir acompañada de una cualitativa: - Porcentaje de oportunidades con fecha de cierre en el pasado: métrica de obsolescencia del Pipeline. - Porcentaje de Cases cerrados con un código de motivo genérico tipo "otro": métrica de categorización deficiente. - Porcentaje de clientes sin una persona de contacto activa: métrica de datos maestros incompletos. - Porcentaje de registros duplicados creados manualmente: métrica de fallo en el proceso de entrada. Estas cuatro métricas revelan en una semana si el sistema está siendo utilizado de forma genuina o solo de forma ceremonial. Puede encontrar más información sobre cómo corregir la causa raíz en [Mejora de la adopción de Salesforce](/es/insights/recover-salesforce-user-adoption). ## Segmentación: El promedio engaña Un promedio organizacional del 70% de adopción puede esconder un equipo con un 95% y otro con un 20%. Toda medición debe ser segmentada al menos por tres criterios: 1. **Rol**: Representante, Gerente, Back Office. Cada uno tiene expectativas diferentes. 2. **Equipo o Gerente Directo**: La mayor diferencia en la adopción casi siempre reside en el gerente directo, no en la capacitación. 3. **Antigüedad en el sistema**: Los usuarios que se incorporaron después del Go Live no recibieron la misma capacitación, y sus datos reflejan el proceso de incorporación. Cuando la brecha entre el equipo líder y el equipo rezagado es más del doble, el problema es de gestión y no sistémico, por lo que la inversión adecuada es en la capa de gestión, no en un desarrollo adicional. ## Baseline: El error que no se puede corregir a posteriori Una métrica sin un punto de referencia es un número sin significado. El Baseline se mide antes del cambio, incluso si se hace manualmente o se estima. Pregúntese: ¿cuánto tiempo toma hoy cerrar un Case? ¿Cuántas oportunidades se actualizan a tiempo? ¿Cuál ha sido la desviación del pronóstico en los últimos tres trimestres? Si el Baseline no se midió antes del lanzamiento, se puede reconstruir parcialmente a partir de datos históricos, pero no se pueden recrear métricas de comportamiento. Esta es la razón por la que la medición de la adopción es una decisión de la fase de planificación, no de la fase de Go Live. ## Del Hallazgo a la Acción La siguiente tabla relaciona hallazgos comunes con la acción correcta. La lógica es: casi ningún hallazgo de adopción se resuelve con capacitación adicional. | Hallazgo | Causa Raíz Probable | Acción Recomendada | | --- | --- | --- | | Logins altos, acciones principales bajas | El sistema no está en el flujo de trabajo diario | Integración en el proceso: alertas, Path, listas de trabajo | | Acciones realizadas pero con semanas de retraso | No hay un ciclo de gestión que dependa de los datos | Revisión semanal del Pipeline desde un Dashboard | | Calidad baja en un campo específico | El campo no es relevante o no es claro | Reducir, cambiar a un Picklist o eliminar | | Un solo equipo rezagado | Gerente directo que no utiliza el sistema | Trabajar con el gerente, no con el equipo | | Todos los campos completados, pero la dirección no confía | Desalineación entre la métrica y la pregunta de negocio | Redefinir la métrica de resultado | ## Cómo se ve en un Informe Mensual Un buen informe de adopción cabe en una página: cuatro métricas con una tendencia de tres meses, segmentadas por equipo, tres hallazgos y tres acciones con su responsable y fecha. Sin acciones, es un informe de estado; con acciones, es una herramienta de gestión. La relación entre la medición y el plan de trabajo organizacional se detalla en [Gestión del cambio en Salesforce](/es/insights/salesforce-change-management-plan), y la planificación de la capacitación basada en los hallazgos se encuentra en [Capacitación de Salesforce basada en roles](/es/insights/salesforce-role-based-training). ## Resumen Las métricas de adopción no son un boletín de calificaciones para los usuarios; son un sistema de detección de fallos en el proceso. Si la medición no conduce a un cambio en el proceso, en la interfaz o en la capa de gestión, solo genera trabajo. Comience con cuatro métricas, segmente por equipo, establezca un Baseline y vincule cada hallazgo a una acción con un responsable. ### Preguntas y respuestas **¿Cuántas métricas de adopción se deben medir?** Entre cuatro y seis. Una métrica de acción clave por cada rol principal, una métrica de calidad de datos, una métrica de velocidad de proceso y una métrica de resultado de negocio. Más que eso genera un panel de control que nadie abre. **¿Qué hacer cuando los datos muestran una alta adopción pero la dirección no está satisfecha?** Casi siempre es una señal de que ha medido actividad y no resultados. Verifique si las acciones medidas realmente mueven las cifras del negocio; por ejemplo, si actualizar la etapa de un trato mejora la precisión de la previsión, o simplemente rellena un campo. **¿Es posible medir la adopción sin una herramienta de análisis dedicada?** Sí. Los Informes y Paneles de control estándar con Tipos de informe sobre el historial de campos son suficientes para la mayoría de las organizaciones. Una herramienta externa es necesaria principalmente cuando se requiere un análisis de pantalla y una secuencia de clics a nivel de usuario. **¿Cuándo se mide por primera vez después de la puesta en marcha (Go Live)?** Dos semanas después de finalizar el Hypercare, no antes. En las primeras semanas, los números se distorsionan por el soporte cercano, las correcciones de datos y el entusiasmo inicial. **¿Cómo se evita que la métrica se convierta en un juego?** Cada métrica cuantitativa va acompañada de una métrica de calidad. Si se mide el número de 'Actividades', se mide junto a la tasa de 'Actividades' con contenido significativo o un vínculo a una oportunidad. Una sola métrica siempre generará una presión artificial. --- ## 8 señales de que su sistema Salesforce actual necesita una actualización URL: https://hpi.pro/es/insights/salesforce-system-upgrade-signs Un sistema CRM rara vez falla de repente; se desgasta gradualmente, y quienes lo usan a diario pueden dejar de percibirlo. Las ocho señales que presentamos son medibles sin necesidad de encuestas ni consultores, y cada una apunta a una causa raíz diferente: proceso, datos, arquitectura o gobernanza. ## La respuesta breve Un sistema necesita una actualización o mejora cuando el trabajo para mantenerlo o gestionarlo supera el trabajo que se realiza dentro de él. Los ocho indicadores que se presentan a continuación son distintas manifestaciones del mismo fenómeno, pero cada uno apunta a una raíz diferente. Por lo tanto, una identificación precisa es más importante que simplemente enumerarlos. ## Los ocho indicadores | # | El indicador | Lo que revela | | --- | --- | --- | | 1 | Hojas de cálculo paralelas para la gestión de pronósticos o colas | El sistema no es la fuente real de la verdad | | 2 | Informes que muestran cifras contradictorias | Definiciones de métricas no unificadas o duplicidad de datos | | 3 | Cada solicitud de cambio tarda semanas | Acumulación de deuda técnica en automatizaciones, falta de un entorno de pruebas adecuado | | 4 | Pantallas con decenas de campos que nadie completa | Acumulación de requisitos sin limpieza | | 5 | La carga de un registro es notablemente lenta | Doble Trigger, Flows anidados, consultas ineficientes | | 6 | Operaciones manuales que se repiten diariamente | Proceso que no fue implementado, solo documentado | | 7 | Permisos otorgados "para que funcione" | Un modelo de visibilidad que ha perdido lógica | | 8 | Conocimiento que reside en una sola persona | Ausencia de documentación y gobernanza | ## Cómo interpretar el panorama Los indicadores se dividen en cuatro categorías, y esto es lo que determina el tipo de trabajo: **Proceso (1, 6)** - El sistema está construido alrededor de un proceso que no es el real. La solución es una redefinición del mapeo, no un desarrollo. **Datos (2)** - El problema radica en las definiciones y la calidad, no en la herramienta de informes. Más información en [Métricas de Calidad de Datos de Salesforce](/es/insights/salesforce-data-quality-metrics). **Arquitectura (3, 5)** - Deuda técnica acumulada en automatizaciones y código. Más información en [Optimización del Rendimiento de Salesforce](/es/insights/salesforce-performance-optimization). **Gobernanza (4, 7, 8)** - No hay quien decida qué entra, quién ve qué y quién documenta. Si no se aborda esta categoría, las demás correcciones volverán a ser necesarias. ## El indicador más contundente De los ocho, una hoja de cálculo paralela utilizada por un ejecutivo senior para la toma de decisiones es el indicador más inequívoco. No es una queja, es una declaración silenciosa de la organización de que el sistema es insuficiente. Mientras exista, cualquier mejora en los informes es un trabajo sobre una vista en la que nadie confía. ## Qué hacer antes de corregir La tentación es empezar por el indicador más ruidoso. El orden eficaz es diferente: dos semanas de medición en los tres indicadores más fuertes para establecer una línea de base (baseline). Sin ella, incluso una corrección exitosa no podrá demostrar su valor, y la financiación para la siguiente fase no será aprobada. Después de la medición, se decide entre una corrección focalizada y un trabajo estructural, detallado en [Corregir o Reconstruir](/es/insights/salesforce-rebuild-vs-refactor). ## Resumen Los indicadores no son una lista de quejas, sino una herramienta de diagnóstico: cada uno apunta a una familia de causas raíz diferente, y tratar el síntoma de la familia incorrecta desperdicia un ciclo completo. Tres indicadores activos justifican una evaluación sistemática; una hoja de cálculo paralela en la gerencia (dirección) lo justifica por sí sola. ### Preguntas y respuestas **¿Cuántas señales deben existir para justificar una auditoría?** Tres de las ocho, o una de alta intensidad, como informes de dirección contradictorios. Una señal débil y aislada suele ser un incidente puntual, no un problema sistémico. **¿La proliferación de hojas de cálculo paralelas siempre indica un problema en el sistema?** Casi siempre, aunque no necesariamente un problema técnico. Una hoja de cálculo nace cuando el sistema no soporta un proceso real o cuando es demasiado lento, dos razones distintas con soluciones diferentes. **¿Cuál es la diferencia entre una actualización y un mantenimiento rutinario?** El mantenimiento aborda averías y solicitudes puntuales. Una actualización modifica la estructura —el modelo, las automatizaciones o los permisos— para eliminar la causa raíz que genera las solicitudes. **¿Es posible identificar las señales sin acceso al sistema?** Sí. La mayoría se observan desde fuera: la duración de una reunión manual, el número de archivos enviados por correo electrónico, el tiempo que tarda en obtener una respuesta a una pregunta sencilla de un informe. **¿Qué se hace después de identificarlas?** Medir antes de corregir. Dos semanas de recopilación de datos sobre las tres señales más fuertes proporcionan una línea base sin la cual es imposible demostrar una mejora posterior. --- ## Estrategia de Sandboxes y DevOps para Salesforce en su Organización URL: https://hpi.pro/es/insights/salesforce-sandbox-devops-strategy El camino desde el desarrollo hasta la producción es determinante para liberar con confianza. Esta guía detalla los tipos de Sandboxes necesarios en cada etapa, cómo construir una ruta Source-Driven con Git y CI, y qué hacer con la configuración manual realizada en Producción. ## La respuesta breve Una estrategia sólida de entornos responde a tres preguntas fundamentales: ¿dónde se ejecuta cada tipo de trabajo?, ¿cómo avanza un cambio? y ¿cómo se revierte si algo falla? La estructura que funciona en la mayoría de las organizaciones incluye un entorno Developer para cada desarrollador, un entorno de integración compartido, un entorno UAT con datos representativos y un entorno de Producción. Todo esto debe complementarse con Git como fuente única de verdad y una automatización del despliegue, al menos hasta el entorno UAT. ## Mapa de entornos | Entorno | Tipo | Actividad | Datos | | --- | --- | --- | --- | | Desarrollo Personal | Developer | Construcción, pruebas, pruebas unitarias | Solo metadatos | | Integración | Developer Pro | Fusión del trabajo del equipo, CI | Muestra pequeña sintetizada | | UAT | Partial o Full | Aceptación de negocio, capacitación, escenarios de borde | Datos reales enmascarados | | Staging / Full | Full | Ensayo general de Release, pruebas de volumen | Copia completa enmascarada | | Producción | — | Operación continua | Datos reales | Se recomienda un Sandbox para Hotfix a las organizaciones cuyos lanzamientos superan las dos semanas. Sin este, cualquier corrección urgente obliga a desplegar trabajo que aún no ha madurado. ## De Change Sets a Source-Driven La transición se realiza en tres etapas. Primero, se exportan los metadatos existentes a un repositorio y se establece una estructura y estrategia de ramas sencilla: una rama principal, una rama de Release y ramas de Feature de corta duración. A continuación, se implementa una integración continua (CI) que ejecuta una validación de despliegue, pruebas Apex y pruebas estáticas con cada Pull Request, sobre el entorno de integración. En la tercera etapa, se conecta el despliegue automático al UAT, manteniendo el despliegue a Producción como una acción manual aprobada con una ventana de lanzamiento definida. Lo que dificulta la transición no es la herramienta, sino el alcance: intentar introducir toda la organización (Org) en el repositorio de una sola vez genera miles de archivos que nadie es capaz de revisar. Es preferible empezar con un grupo de metadatos de un solo dominio de negocio y expandirse gradualmente. ## Lo que no entra en el repositorio Parte del estado no consiste en metadatos desplegables: registros de configuración en Custom Settings y Custom Metadata que dependen del entorno, valores de Named Credentials, Assignment Rules que cambian con frecuencia y contenido de Knowledge. Para cada una de estas categorías debe existir un documento breve que defina quién actualiza, dónde y cómo se sincroniza entre entornos. La ausencia de esta definición es la causa más común de errores que aparecen solo en Producción. La relación entre la frecuencia de los lanzamientos y el método de trabajo se detalla en [Agile vs. Waterfall Híbrido](/es/insights/salesforce-agile-waterfall-hybrid) y en la [Guía de Implementación de Salesforce](/es/insights/salesforce-implementation-guide). ## Actualización y mantenimiento de entornos Un Sandbox que no se ha actualizado en nueve meses ya no representa a Producción, y cualquier prueba realizada en él da una falsa sensación de seguridad. La regla es simple: un entorno UAT se refresca antes de cada Release significativo, y los entornos de desarrollo se refrescan al final de cada ciclo. Es crucial planificar con antelación lo que se pierde con la actualización (datos de prueba, usuarios, configuraciones) y disponer de un script Post-Refresh que los restaure en una hora, en lugar de tres días. ## Riesgos comunes y acciones preventivas El primer riesgo es el Drift: diferencias que se acumulan silenciosamente entre Producción y el repositorio. La única defensa efectiva es una comparación automática semanal de metadatos con alertas. El segundo riesgo son las pruebas Apex que se escribieron solo para cumplir el umbral de cobertura. Una cobertura del 75% sin Assertions reales no es una red de seguridad, y da una falsa confianza justo en el momento en que se necesita la verdadera confianza. El tercer riesgo es un cuello de botella humano: una sola persona autorizada para desplegar. Se requieren al menos dos, con permisos documentados. ## Cómo se mide el éxito Cuatro métricas: frecuencia de los lanzamientos, tiempo desde la fusión hasta Producción, tasa de despliegues fallidos y número de Hotfixes en el mes posterior a cada Release. Una mejora real se observa así: la frecuencia aumenta, el tiempo disminuye, y la tasa de fallos y Hotfixes disminuye simultáneamente. Un aumento en la frecuencia junto con un aumento en los Hotfixes significa que la ruta es más rápida, pero las pruebas son insuficientes. ### Preguntas y respuestas **¿Cuántos Sandboxes son realmente necesarios?** El mínimo práctico para una organización mediana es: Developer para cada desarrollador, un Developer Pro para integración y un Full o Partial para UAT y pruebas de volumen. Una organización pequeña puede conformarse con dos; una organización con varios equipos en paralelo también necesitará un Sandbox dedicado para Hotfix. **¿Es obligatorio migrar a Git y a la implementación automática?** No desde el primer día, pero sí antes de que más de dos personas manipulen los metadatos. Hasta entonces, los Change Sets son suficientes. Más allá de eso, sin una única fuente de verdad en el código, es imposible saber quién cambió qué y no se puede revertir con seguridad. **¿Qué se hace cuando alguien ha cambiado algo manualmente en Producción?** Se identifica mediante una comparación semanal de metadatos, se revierte el cambio a la rama principal como un commit documentado y, si no es deseado, se cancela. Lo que no es tolerable es que el cambio persista en Producción pero no en el repositorio, ya que la siguiente implementación lo sobrescribirá. **¿Un Full Sandbox contiene datos reales? ¿Qué pasa con la regulación?** Sí, por lo que se requiere enmascaramiento de datos antes de conceder acceso amplio. En entornos con información personal, el enmascaramiento o un Partial Sandbox con muestreo representativo son la opción predeterminada correcta, en lugar de un Full con una copia en vivo. **¿Cuánto tiempo se tarda en establecer una ruta básica de DevOps?** De cuatro a ocho semanas: dos semanas para la estructura del repositorio y la estrategia de ramificación, dos semanas para CI y pruebas automatizadas, y el resto para la adopción por parte del equipo. La parte más lenta siempre son los hábitos, no las herramientas. --- ## Hypercare tras el Go-Live de Salesforce: Cómo estabilizar sin crear dependencia URL: https://hpi.pro/es/insights/salesforce-hypercare-plan Hypercare no es una extensión del proyecto, sino un puente planificado hacia la operación habitual (BAU). Estructura de un periodo de estabilización: composición del equipo, SLA temporales, triaje diario, criterios de salida medibles y una transferencia de propiedad ordenada al equipo interno. ## La respuesta corta El día después del "Go Live" no marca el fin del proyecto, sino el inicio de la etapa donde se revela el verdadero valor de lo construido. El Hypercare es un período planificado en el cual el equipo que desarrolló el sistema permanece disponible, abordando las deficiencias con agilidad y, simultáneamente, transfiriendo la propiedad al equipo de mantenimiento. Existen dos errores opuestos: omitir esta fase y dejar a los usuarios desatendidos, o extenderla indefinidamente, generando una dependencia crónica del proveedor. Ambos se evitan estableciendo criterios de salida predefinidos. ## Diferencias clave durante este periodo | Aspecto | Hypercare | Operación estándar (BAU) | | --- | --- | --- | | Canal de contacto | Directo con el equipo del proyecto + presencia en sitio | Cola de soporte regular | | Tiempo de respuesta a un incidente crítico | Hasta una hora | Según SLA operativo | | Frecuencia de despliegue de correcciones | Diaria o interdiaria | Ciclo planificado | | Autoridad de decisión | Propietario del proceso disponible diariamente | Comité de cambios | | Enfoque | Estabilización y corrección | Mejora y desarrollo | ## El triaje diario es fundamental Una reunión de 20 minutos cada mañana, a una hora fija, para abordar tres preguntas: ¿qué se abrió ayer?, ¿qué bloquea el trabajo hoy?, y ¿qué se libera hoy? Cada solicitud se clasifica en cuatro categorías: 1. **Incidente crítico** — Impide la ejecución de un proceso de negocio. Requiere atención inmediata. 2. **Brecha de datos** — La migración o integración resultó en información incorrecta. Prioridad alta por su impacto en la confianza. 3. **Brecha de capacitación** — El sistema funciona según lo previsto, pero el usuario no lo sabía. Respuesta inmediata y registro para ajustar materiales de ayuda. 4. **Solicitud de mejora** — Se envía al Backlog, sin implementación durante este período. Esta clasificación es la herramienta principal para controlar el alcance: sin ella, cada solicitud parece urgente y el período de estabilización se convierte en una fase de desarrollo adicional. ## Composición del equipo y presencia en campo Durante la primera semana, se requiere una presencia física o virtual cercana en las unidades clave. Los profesionales del proyecto trabajan junto a los usuarios, observan los fallos en tiempo real y los corrigen el mismo día. El valor de la observación directa es mucho mayor que el de un informe escrito; la mayoría de los obstáculos graves ni siquiera se reportan. Los representantes en campo que acompañan al equipo son parte de la red de Champions, por lo que reciben capacitación previa y tienen un canal directo. Más detalles en [Red de Champions en Salesforce](/es/insights/salesforce-champions-network). ## Criterios de salida La salida del Hypercare es una decisión medible. Un conjunto común de criterios incluye: * Cero incidentes críticos abiertos durante cinco días hábiles consecutivos. * Una reducción del 60% o más en el volumen diario de solicitudes en comparación con el pico de la primera semana. * La tasa de ejecución de la acción central por rol supera el objetivo definido. * Los tres indicadores clave de calidad de datos dentro del rango acordado. * El equipo de soporte interno gestionó de forma autónoma el 80% de las solicitudes en la última semana. El último criterio es el que distingue una verdadera transferencia de propiedad de un abandono en una fecha arbitraria. La medición se basa en el mismo marco descrito en [Métricas de adopción de Salesforce](/es/insights/salesforce-adoption-metrics). ## Transferencia de propiedad estructurada La transferencia comienza en la primera semana, no el último día. Un mecanismo simple: a partir de la segunda semana, el equipo de soporte interno gestiona las solicitudes en primer lugar, y el equipo del proyecto apoya desde atrás. Cada solicitud resuelta se documenta en una base de conocimiento interna en tres líneas: síntoma, causa, solución. Los productos resultantes de la transferencia incluyen: un documento de arquitectura actualizado, una lista de integraciones con puntos de fallo conocidos, procedimientos de ejecución periódicos, una lista de deudas técnicas generadas bajo presión, y accesos y permisos operativos. ## Dependencia del método de lanzamiento En un lanzamiento "Big Bang", el período de Hypercare es intenso y relativamente corto, con un equipo grande. En un lanzamiento por fases, el período se repite con cada ola, pero a una escala menor, aprendiendo de una fase a otra. Esta implicación es una de las consideraciones al elegir la estrategia. Véase [Big Bang o Rollout por fases](/es/insights/salesforce-big-bang-vs-phased-rollout). ## Cuentas semanales Volumen diario de solicitudes por categoría, tiempo medio de resolución de incidentes críticos, porcentaje de solicitudes resueltas por el equipo interno, y número de deudas técnicas abiertas. Las tres primeras miden la estabilización; la última evita que este período deje problemas ocultos. ## Resumen Planifique el Hypercare como una fase con presupuesto, equipo, triaje diario y criterios de salida cuantificables. Clasifique cada solicitud, no desarrolle mejoras durante este período y transfiera la propiedad gradualmente a partir de la segunda semana. Un sistema estable no es aquel que no tiene fallos, sino aquel que la organización sabe cómo corregir por sí misma. ### Preguntas y respuestas **¿Cuánto tiempo debe durar el período de Hypercare?** De dos a cuatro semanas para una implementación de tamaño medio, y de seis a ocho semanas para lanzamientos multisitio o con migraciones de datos pesadas. La duración se determina según criterios de salida, no exclusivamente por una fecha. **¿Cuál es la diferencia entre Hypercare y el soporte habitual?** Durante Hypercare, el equipo que construyó el sistema está directamente disponible, los tiempos de respuesta son extremadamente cortos y las correcciones se liberan casi de inmediato. En BAU, las solicitudes pasan por una cola de soporte regular con un ciclo de lanzamiento programado. **¿Quién debe formar parte del equipo de Hypercare?** Un desarrollador o administrador familiarizado con la implementación, un propietario de proceso de negocio autorizado para decidir sobre cuestiones de contenido, un representante de migración de datos durante las primeras dos semanas, y un coordinador que gestione el triaje diario. **¿Cómo se evita que el período se extienda indefinidamente?** Se definen criterios de salida numéricos de antemano, se publican y se miden semanalmente. Además, las solicitudes se transfieren gradualmente a la cola de soporte regular a partir de la segunda semana. **¿Qué se hace con las solicitudes de mejora durante Hypercare?** Se registran en el backlog, pero no se implementan. Hypercare está diseñado solo para errores y bloqueos; desarrollar mejoras durante este período socava la estabilidad que se pretende lograr. --- ## Historias de Usuario y Backlog en Proyectos Salesforce: Una Guía para Propietarios de Proceso URL: https://hpi.pro/es/insights/salesforce-user-stories-backlog El backlog de un proyecto Salesforce a menudo falla en el mismo punto: historias que describen una pantalla en lugar de un resultado, y criterios de aceptación redactados después del desarrollo. Esta guía presenta una estructura de historia comprobable, un método de descomposición basado en Vertical Slice y una priorización que se mantiene incluso bajo presión. ## La Respuesta Corta Una buena historia de usuario en Salesforce describe **quién es el usuario, qué intenta lograr y qué debe ser correcto después de la acción** – y no qué campo aparecerá en qué pantalla. La prueba simple es: si los criterios de aceptación se pueden escribir sin saber si la implementación será un Flow, una Validation Rule o Apex, la historia está correctamente formulada. El error común es una historia que ya contiene la solución. Una vez que se escribe "Agregar un campo Picklist a la pantalla de la oportunidad", la discusión sobre el proceso se cierra antes de empezar. ## Estructura Efectiva | Componente | Función | Prueba de Calidad | |---|---|---| | Contexto | Quién es el usuario y cuándo actúa | Rol real, no "usuario" | | Intención | Qué intenta lograr | Formulado en lenguaje empresarial | | Criterios de Aceptación | Qué se verifica | Ejecutable como escenario con datos de prueba | | Casos Extremos | Qué falla intencionadamente | Al menos uno negativo | | Fuera de Alcance | Qué no se incluye explícitamente | Evita disputas en la aceptación | La última línea ahorra la mayoría de los conflictos. Una declaración explícita de lo que no está incluido vale más que tres párrafos de descripción. ## Desglose: Vertical Slice en lugar de Capas La tentación en un proyecto CRM es desglosar por componentes técnicos: primero el modelo de datos, luego las automatizaciones, finalmente los informes. El resultado es que no hay nada que mostrar hasta el final, y nadie sabe si el proceso funciona. El desglose correcto es vertical: un escenario completo, de principio a fin, para un perfil de usuario. Una oportunidad que se abre, avanza, se cierra y aparece en un informe vale más que diez objetos definidos sin proceso. Posteriormente, se añaden perfiles y escenarios alrededor de esa estructura. ## Priorización cuando todo es Urgente Tres criterios son suficientes, en este orden: 1. **¿Bloquea la salida a producción?** – Sin él, el proceso está incompleto. No hay lugar para la negociación. 2. **¿Cuántos usuarios al día?** – La frecuencia prevalece sobre la intensidad de la queja. Un elemento que afecta a 80 agentes diariamente tiene prioridad sobre la solicitud de un solo gerente. 3. **¿Cuál es el costo del aplazamiento?** – ¿Aumenta el costo de la implementación si lo hacemos después del lanzamiento? Un cambio en el modelo de datos sí, un cambio en un informe no. Lo que no pasa estos tres criterios se traslada al Parking Lot. Esta separación evita que el Backlog se convierta en un archivo de deseos. Más detalles sobre la gestión del alcance se encuentran en [Scope Creep y Control de Cambios](/es/insights/salesforce-scope-creep-change-control). ## Deuda de Requisitos: El Fallo Silencioso La deuda de requisitos se crea cuando una historia se cierra sin haber decidido qué sucede en el caso extremo – se deja para "resolverlo más tarde". Después del lanzamiento, estos casos extremos son la mayoría de las llamadas al soporte. La disciplina simple: un elemento no se cierra sin una decisión documentada para cada pregunta abierta registrada, incluso si la decisión es "intencionadamente no se aborda". Documentar la omisión vale más que no tener documentación. ## Relación con las Pruebas Los criterios de aceptación correctamente escritos son, de hecho, los scripts de UAT. Cuando se escriben después del desarrollo, el UAT se convierte en una demostración de lo construido en lugar de una prueba de lo requerido. La secuencia se detalla en la [Guía de UAT](/es/insights/salesforce-uat-guide). ## Resumen Un Backlog de calidad no es largo, sino claro: cada elemento indica para quién es, qué se medirá como éxito y qué no está incluido explícitamente. Estas tres preguntas, formuladas antes de la construcción y no después, determinan casi toda la calidad de la aceptación al final del proyecto. ### Preguntas y respuestas **¿Qué tan detallada debe ser una historia antes de iniciar la construcción?** Debe ser lo suficientemente detallada para que un desarrollador sepa qué construir y un probador sepa qué podría fallar. Si los criterios de aceptación no pueden ejecutarse como un escenario de prueba, la historia aún no está lista, sin importar su extensión. **¿Quién redacta los criterios de aceptación?** El propietario del proceso define qué se considerará un éxito, mientras que el probador o arquitecto añade los casos extremos. La redacción exclusiva por parte del desarrollador puede generar un criterio que describe lo que se construyó, no lo que se requiere. **¿Qué se hace con un requisito que es en realidad una pregunta abierta?** No es una historia, sino un Spike: una tarea de investigación con tiempo limitado cuyo resultado es una decisión documentada. Mezclar la investigación y la construcción en el mismo elemento oculta el riesgo en la estimación. **¿Son necesarios los Story Points en Salesforce?** La estimación relativa ayuda principalmente a revelar desacuerdos sobre el alcance. El valor no reside en la cifra exacta, sino en la conversación que surge cuando las estimaciones son muy dispares. **¿Cómo se evita que el Backlog se infle a miles de elementos?** Se limita la profundidad: lo que no se evaluará para el próximo trimestre se traslada a un Parking Lot separado. Un Backlog que nadie lee hasta el final deja de ser una herramienta de priorización para convertirse en un archivo. --- ## Scope Creep en Proyectos Salesforce: Gestión del Cambio sin Paralizar la Implementación URL: https://hpi.pro/es/insights/salesforce-scope-creep-change-control El 'scope creep' no surge de solicitudes excesivas, sino de la falta de un mecanismo para valorarlas en tiempo real. Esta guía propone una 'baseline' congelada, un formulario de 'Change Request' conciso, una junta de cambios semanal y un presupuesto de contingencia preasignado. Así, es posible decir 'sí' sin comprometer las fechas de entrega. ## La respuesta corta La "expansión del alcance" (Scope Creep) surge cuando no hay una diferencia visible entre lo prometido y lo construido. Esto se resuelve mediante tres mecanismos: una línea base (baseline) documentada y visible para todos, un formulario de solicitud de cambio de media página que incluya una estimación del esfuerzo, y una regla de sustitución que establece que cada adición desplaza algo de tamaño similar o consume un presupuesto de cambio preasignado. Sin estos tres elementos, cualquier "pequeña solicitud" se diluye en el sprint y solo se descubre en la fecha límite. ## ¿Por qué ocurre esto específicamente en Salesforce? Salesforce es lo suficientemente flexible como para que casi cualquier solicitud parezca económica. Añadir un campo toma dos minutos, por lo que es difícil explicar a un interesado por qué no hacerlo. Sin embargo, ese campo implica validaciones, permisos, una columna en un informe, un mapeo en la migración, una línea en la capacitación y una prueba en UAT. El costo real es de cinco a diez veces mayor que el tiempo de construcción, y esa es precisamente la diferencia que nadie ve en el momento de la solicitud. ## Marco de control en cuatro componentes | Componente | ¿Qué incluye? | ¿Quién es el responsable? | Resultado | | --- | --- | --- | --- | | Línea Base Congelada | Lista de capacidades, escenarios y exclusiones explícitas (Out of Scope) | Product Owner | Documento firmado al final del Discovery | | Solicitud de Cambio (Change Request) | Descripción, justificación de negocio, estimación de esfuerzo, impacto en la fecha | Solicitante + Tech Lead | Formulario de media página | | Comité de Cambios | Sesión semanal de 30 minutos sobre todas las solicitudes abiertas | Patrocinador, PO, Tech Lead | Decisión: Aprobado / Rechazado / Para la siguiente fase | | Presupuesto de Cambios | 10%–20% del presupuesto total, asignado al inicio del proyecto | Patrocinador | Seguimiento semanal del saldo | ## El poder de las exclusiones explícitas (Out of Scope) La sección más importante del documento de la Línea Base no es lo que se incluye, sino lo que explícitamente no se incluye. Frases como "la integración con el sistema de nóminas no está incluida en la primera fase" o "la migración de la actividad anterior a 2022 no está incluida" ahorran semanas de discusión. La regla: cualquier cosa que un interesado pueda asumir erróneamente que está incluida debe aparecer en la lista de exclusiones por su nombre completo. ## Cómo decir "sí" sin pagar por ello Un rechazo generalizado genera un proyecto que termina a tiempo y no es utilizado por nadie. El enfoque eficaz es aceptar cada solicitud en el repositorio, valorarla con transparencia y permitir que el interesado elija: incorporarla ahora a expensas de otro elemento, esperar a la próxima fase o consumirla del presupuesto de cambios. Cuando la elección es transparente, la discusión pasa de lo emocional a lo económico, y en la práctica, aproximadamente un tercio de las solicitudes se desestiman tan pronto como se ve el costo. Para una expansión sobre la definición del Baseline, consulte [Definición de MVP](/es/insights/salesforce-mvp-scope) y [Discovery para CRM](/es/insights/crm-discovery-guide). ## Riesgos comunes y acciones preventivas El riesgo principal es un control excesivamente riguroso. Un proceso que requiere tres formularios y dos semanas de espera hace que los equipos lo eviten, y los cambios continúan, pero sin documentación. Media página y una discusión semanal son el límite práctico. Un segundo riesgo es la "expansión técnica": decisiones arquitectónicas que se toman dentro de un sprint y amplían el alcance sin que nadie las catalogue como un cambio. Por lo tanto, un cambio arquitectónico significativo también debe pasar por el mismo comité. Un tercer riesgo es un Patrocinador ausente: cuando no hay nadie con autoridad para decir "no", cada solicitud recibe un "lo evaluaremos", lo cual es equivalente a un "sí". ## Cómo medir el éxito Se realiza un seguimiento de cuatro métricas en un informe semanal: número de solicitudes abiertas, porcentaje aprobado, cambio acumulativo en el alcance con respecto a la Línea Base, y saldo restante del presupuesto de cambios. Un proyecto saludable muestra un cambio acumulativo de hasta el 15% y un saldo de presupuesto positivo en la fase de UAT. Un cambio acumulativo superior al 30% es una señal de que el Discovery fue demasiado superficial, y no que el equipo sea indisciplinado. ### Preguntas y respuestas **¿Cuál es la diferencia entre 'scope creep' y un aprendizaje legítimo en el proyecto Salesforce?** El aprendizaje modifica la solución dentro del mismo objetivo de negocio (outcome), mientras que el 'scope creep' añade un nuevo objetivo sin ajustar la fecha o el presupuesto. La prueba práctica es: si la solicitud surge de algo descubierto en la fase de 'Discovery' o durante las pruebas de aceptación de usuario (UAT), es aprendizaje. Si proviene de un departamento que se unió tardíamente, es una expansión. **¿Qué porcentaje del presupuesto total debería asignarse a cambios en un proyecto Salesforce?** Entre el 10% y el 20% del presupuesto del proyecto, dependiendo del nivel de incertidumbre. Un proyecto con una fase de 'Discovery' exhaustiva y procesos bien definidos podría manejarse con un 10%; mientras que un proyecto que involucra múltiples unidades de negocio o una migración desde un sistema indocumentado podría requerir cerca del 20%. **¿Quién está autorizado para aprobar un cambio en el alcance de un proyecto Salesforce?** El Product Owner puede aprobar un intercambio de funcionalidades dentro de la 'baseline' sin alterar la fecha o el costo. Un Patrocinador (Sponsor) aprueba cualquier cambio que afecte la fecha, el presupuesto o los objetivos de negocio (outcomes). Una cadena de autoridad clara es la defensa más efectiva contra la 'deriva del alcance'. **¿Qué hacer cuando el proveedor afirma 'esto no está incluido en la propuesta'?** Se debe revisar el Statement of Work (SOW) y la documentación de la fase de 'Discovery'. Si realmente se trata de una expansión del alcance, se tarifará como un cambio. Si es una brecha resultante de una definición ambigua en la propuesta, la responsabilidad es compartida. Documentar las suposiciones en el contrato es clave para prevenir estas discusiones. **¿El enfoque 'Agile' elimina la necesidad de controlar los cambios en un proyecto Salesforce?** No. Si bien 'Agile' permite intercambiar elementos en el 'backlog' con facilidad, el presupuesto y la fecha de entrega siguen siendo finitos. El control de cambios en 'Agile' se basa en la regla de intercambio: cada elemento nuevo que entra debe desplazar a otro de tamaño similar. --- ## ¿Agile, Waterfall o Híbrido en su Proyecto Salesforce? Eligiendo el Modelo de Entrega URL: https://hpi.pro/es/insights/salesforce-agile-waterfall-hybrid El debate sobre la metodología en un proyecto Salesforce casi siempre es un debate sobre otra cosa: cuántas decisiones se pueden posponer y cuánto tiempo tienen realmente disponibles los usuarios. Esta guía desglosa la elección en tres variables cruciales y describe el modelo híbrido al que la mayoría de las organizaciones llegan en la práctica. ## La respuesta breve La elección no radica en dos ideologías, sino en dos tipos de decisiones. Hay decisiones cuya alteración incrementa su costo abruptamente con el tiempo —tales como el modelo de datos, los permisos o las integraciones— y estas deben establecerse tempranamente. Por otro lado, existen decisiones cuyo costo de modificación es bajo —como pantallas, campos, informes o redacciones— y es preferible descubrirlas en el transcurso del proyecto. De esto se deduce que el modelo que funciona en la mayoría de los proyectos de Salesforce es híbrido, no por una cuestión de compromiso, sino por su propia estructura: **un marco fijo, contenido iterativo**. ## Las tres variables determinantes | Variable | Impulsa hacia una planificación temprana | Impulsa hacia las iteraciones | | --- | --- | --- | | Claridad del proceso | Proceso regulado y documentado | Proceso cambiante o no consensuado | | Disponibilidad de usuarios | Baja, tiempo limitado | Alta, posible revisión semanal | | Exposición regulatoria | Auditoría, cumplimiento, aprobaciones | Mínima | La segunda variable es más decisiva de lo que se suele suponer. Agile sin disponibilidad de usuarios no es Agile; es una serie de *sprints* al final de los cuales nadie ha validado nada, y toda la retroalimentación llega en el UAT de una sola vez. ## La estructura híbrida en la práctica El enfoque exitoso divide el proyecto en dos partes con ritmos distintos: **Fase de estructura (4-6 semanas, planificada)**: Modelo de datos, modelo de permisos y visibilidad, mapeo de integraciones, estrategia de migración y definición de los procesos incluidos en la primera fase. Sus resultados son documentados y aprobados. **Fases de entrega (sprints de dos semanas)**: Cada fase entrega un escenario completo para un perfil de usuario, incluyendo pruebas y retroalimentación. Los cambios dentro de la fase no requieren una nueva aprobación, siempre y cuando no afecten el marco establecido. La regla que sostiene esto es: **un cambio en el marco es una decisión gestionada, un cambio en el contenido es trabajo continuo**. Sin esta distinción, cada solicitud menor llega al comité directivo y cada cambio estructural pasa desapercibido. ## Dónde falla cada modelo El **Waterfall puro** falla en la UAT: la brecha entre lo escrito en el documento seis meses antes y lo que el usuario espera se revela demasiado tarde para una corrección económica. El **Agile puro** falla en el modelo de datos: después de seis *sprints* de decisiones locales, se descubre que la estructura no soporta la generación de informes interprocesos, y la corrección requiere una migración. El **híbrido** falla cuando el marco no se ha cerrado realmente, es decir, cuando es un "marco" de nombre, pero se reabre en cada fase. En ese caso, se obtienen las desventajas de ambos modelos. ## Qué medir en el camino Tres métricas son suficientes para saber si el modelo funciona: la proporción entre elementos completados y reabiertos, el tiempo desde la retroalimentación del usuario hasta la corrección, y el número de cambios que afectaron el marco. Un aumento en la tercera métrica es la señal más temprana de que la planificación inicial fue superficial. La relación con la gestión del alcance se detalla en [Desvíos del Alcance y Control de Cambios en Salesforce](/es/insights/salesforce-scope-creep-change-control), y los cronogramas en [Cronograma para un Proyecto Salesforce](/es/insights/salesforce-project-timeline). ## Resumen La pregunta pertinente no es qué metodología es más moderna, sino qué decisiones en este proyecto serán costosas de modificar tardíamente. Quien sepa responder a esto, obtiene el modelo de entrega de forma casi automática; y casi siempre será un modelo híbrido con un límite claro entre estructura y contenido. ### Preguntas y respuestas **¿Es posible implementar un Agile auténtico con un presupuesto ya aprobado a precio fijo?** Es posible, siempre y cuando el contrato fije resultados, no una lista de elementos. Un precio fijo frente a un Backlog abierto genera una tensión inherente donde cada cambio se convierte en una discusión comercial en lugar de una profesional. **En un proyecto ágil, ¿qué aspectos permanecen con un enfoque Waterfall?** El modelo de datos, la arquitectura de permisos y la planificación de integraciones. Estos tres elementos son demasiado costosos de modificar en etapas tardías, por lo que se definen tempranamente incluso cuando todo lo demás es iterativo. **¿Cuál es la duración adecuada de un sprint para un proyecto Salesforce?** Dos semanas en la mayoría de los casos. Una semana no es suficiente para configuración, pruebas y retroalimentación; tres semanas retrasan demasiado la retroalimentación, haciendo que la corrección sea más costosa. **¿Qué hacer cuando los usuarios no están disponibles para revisiones?** Se acorta la revisión a 30 minutos y se añade una decisión documentada: lo que no se revise en el plazo establecido se considera aprobado. La falta de disponibilidad no gestionada se convierte más adelante en la objeción de 'esto no es lo que pedimos'. **¿La regulación excluye Agile?** No. Requiere documentación y aprobaciones en puntos definidos, y esto es compatible con las iteraciones siempre que la puerta de aprobación se establezca de antemano y no se incorpore a mitad del proceso. --- ## ¿Big Bang o lanzamiento por fases para su implementación de Salesforce? URL: https://hpi.pro/es/insights/salesforce-big-bang-vs-phased-rollout La elección depende de las interdependencias de datos y procesos, no de una preferencia metodológica. Ofrecemos un marco para decidir entre un lanzamiento único y uno por fases, incluyendo el costo de coexistencia, los riesgos de migración y una tabla de decisión según el tipo de organización. ## La Respuesta Breve El debate entre un lanzamiento "Big Bang" y uno por fases suele presentarse como una cuestión de riesgo, pero es principalmente una cuestión de dependencia. Si dos unidades comparten el mismo registro y el mismo proceso, dividirlas en diferentes olas genera un período intermedio costoso y propenso a errores. Si las unidades son independientes, no hay motivo para implementarlas todas juntas. La regla práctica: **Primero, mapee las dependencias; luego, elija la estrategia.** ## Un Resumen de Ambos Enfoques Un lanzamiento "Big Bang" implementa todas las unidades en una única fecha. La ventaja es una finalización rápida, una fuente de verdad única desde el primer día y cero costos de período intermedio. La desventaja es la concentración del riesgo: cualquier error afecta a todos simultáneamente, y la recuperación es compleja. Un lanzamiento por fases implementa una unidad o proceso en cada ola. La ventaja es el aprendizaje de una ola a otra, un riesgo limitado y un equipo que mejora continuamente. La desventaja es una duración de proyecto más larga, fatiga organizacional y un período prolongado con dos sistemas coexistiendo. ## Mapeo de Dependencias: La Prueba Decisiva | Pregunta | Respuesta que conduce a Big Bang | Respuesta que conduce a Fases | | --- | --- | --- | | ¿El mismo registro es manejado por dos unidades? | Sí, de forma continua | No, con una clara imputación de costos | | ¿El proceso fluye entre departamentos? | Sí, de principio a fin | Procesos separados | | ¿La generación de informes de gestión los unifica a todos? | Sí, diariamente | Informes a nivel de unidad | | ¿Es posible la sincronización bidireccional a un costo razonable? | No | Sí | | ¿Las unidades comparten el mismo catálogo de productos y precios? | Sí | No | Tres o más respuestas en la columna izquierda — la división en fases costará más de lo que ahorrará. ## El Costo de la Coexistencia Este es el punto que decide muchas decisiones y, sin embargo, a menudo se olvida en la planificación. Un período intermedio incluye: sincronización bidireccional entre Salesforce y el sistema heredado, generación de informes unificados de dos fuentes, soporte para dos entornos, capacitación doble para usuarios que interactúan con ambos, y gestión de conflictos de actualización. Una estimación realista oscila entre el 10% y el 25% del presupuesto del proyecto, y aumenta a medida que se alarga el período. Si el plan incluye un año de coexistencia, se debe evaluar seriamente si acortar el período justifica el riesgo adicional de un lanzamiento más amplio. ## Riesgos de Migración en Cada Enfoque En un Big Bang, la migración es un evento único, grande, en una ventana de tiempo corta. Requiere ensayos completos (Mock Cutover) y un plan de reversión comprobado. En un lanzamiento por fases, la migración se repite en cada ola, pero en una escala menor, y cada vez es necesario decidir qué sucede con los registros que afectan a unidades aún no implementadas. En ambos casos, la calidad de los datos es el factor determinante para el día del lanzamiento. Los detalles de planificación se encuentran en la [guía de implementación de Salesforce](/es/insights/salesforce-implementation-guide). ## Matriz de Decisión por Tipo de Organización | Contexto | Recomendación | Principal Justificación | | --- | --- | --- | | Hasta 150 usuarios, proceso uniforme | Big Bang | El costo de la coexistencia supera el riesgo | | Múltiples sitios o países | Fases por sitio | Diferencias regulatorias y de proceso | | Varios departamentos con un proceso compartido | Core compartido y luego fases | Evita la sincronización bidireccional | | Fecha límite estricta para la finalización del contrato existente | Big Bang con alcance reducido | No hay tiempo para el período intermedio | | Organización sin experiencia previa en Salesforce | Primera fase pequeña | Construcción de capacidad interna | | Migración compleja de múltiples fuentes | Fases | Distribución del riesgo de los datos | ## El Enfoque Híbrido que Funciona en la Práctica La mayoría de las implementaciones grandes y exitosas combinan: una capa de "Core" uniforme — modelo de datos, clientes, permisos, informes básicos — implementada para toda la organización a la vez; sobre ella, fases por unidad para los procesos únicos. Esto evita la sincronización bidireccional sobre los datos compartidos, y aun así permite un aprendizaje gradual. La elección del alcance mínimo para la primera fase es una decisión en sí misma, y se detalla en [Definiendo el MVP en Salesforce](/es/insights/salesforce-mvp-scope). En organizaciones grandes, las implicaciones son más amplias y se discuten en [Implementación de Salesforce en una organización grande](/es/insights/enterprise-salesforce-implementation). ## Implicaciones para el Período de Estabilización La estrategia también determina la estructura del Hypercare: en un Big Bang se requiere un equipo grande para un período intenso y corto; en fases se requiere un equipo pequeño que trabaja en cada ola y acumula conocimiento. En ambos casos, se necesitan criterios de salida definidos, como se detalla en [Hypercare después del Go Live](/es/insights/salesforce-hypercare-plan). ## Resumen Mapee las dependencias interunidades antes de discutir la metodología, cuantifique los costos del período de coexistencia y elija según el contexto: una organización pequeña con un proceso uniforme optará por un Big Bang, una organización multi-sitio optará por fases, y la mayoría de las organizaciones medianas se beneficiarán de un Core compartido con fases adicionales. ### Preguntas y respuestas **¿Qué factor es decisivo al elegir entre ambos enfoques?** El grado de interdependencia entre las unidades. Cuando un proceso atraviesa varios departamentos y el mismo registro de datos es gestionado por ambos, la división en fases requiere una sincronización bidireccional costosa, lo que a menudo inclina la balanza hacia un Big Bang. **¿Cuánto cuesta el período de coexistencia?** Generalmente entre el 10% y el 25% del presupuesto del proyecto: sincronización bidireccional, duplicidad de informes, soporte para dos sistemas y confusión del usuario. Este es el elemento más subestimado al tomar la decisión de implementar por fases. **¿Debe el primer grupo ser el más grande?** No. El primer grupo debe ser una unidad lo suficientemente representativa para aprender de ella, pero lo suficientemente pequeña como para recuperarse de posibles errores. Una unidad de 20 a 50 usuarios con un proceso completo suele ser una buena elección. **¿Cuándo es adecuado el enfoque Big Bang?** Cuando se trata de una organización de hasta aproximadamente 150 usuarios, un proceso uniforme, una migración controlada y una fecha límite estricta debido a la finalización del contrato de un sistema anterior. En estas condiciones, el costo de la coexistencia supera el riesgo del lanzamiento. **¿Es posible combinar ambos enfoques?** Sí, y esta es la opción más común en la práctica: un lanzamiento centralizado (Core) uniforme para toda la organización de una vez, seguido de lanzamientos por fases según la unidad para módulos y procesos específicos. --- ## ROI de Salesforce: Cómo definir y medir el valor real de su proyecto URL: https://hpi.pro/es/insights/salesforce-roi-kpis La mayoría de los cálculos de ROI para proyectos CRM se realizan una única vez, en la diapositiva de aprobación de presupuesto, y nunca se revisan. Esta guía propone una metodología diferente: cuatro tipos de valor medidos de distintas maneras, un Baseline establecido antes de la implementación, y una regla de atribución que evita asignar cada mejora comercial al sistema CRM. HPI Pro le ayuda a asegurar un retorno de inversión tangible y sostenible. ## La respuesta breve El ROI de un proyecto de Salesforce no es una cifra única, sino el resultado de cuatro flujos de valor que se comportan de manera distinta: eficiencia operativa, ingresos, riesgo y costos de sistemas. Mezclarlos en un solo número genera una afirmación que no se puede probar ni refutar. La regla práctica es la siguiente: mida un máximo de seis indicadores, cada uno con una línea base (Baseline) recopilada antes de la puesta en marcha y con un responsable (dueño) que sea diferente de quien construyó el sistema. ## Los cuatro flujos de valor | Flujo | Ejemplo de métrica | Cuándo se mide | Nivel de certeza | | --- | --- | --- | --- | | Eficiencia operativa | Minutos de atención por consulta, tiempo de elaboración de propuestas | Primer trimestre | Alto | | Ingresos | Tasa de cierre (Win rate), tamaño promedio de la transacción, tiempo de ciclo | 2-3 ciclos de venta | Medio | | Riesgo y cumplimiento | Hallazgos de auditoría, exposición de permisos | Anual | Bajo en cantidad, alto en impacto | | Costo de sistemas | Licencias canceladas, interfaces eliminadas | Inmediatamente después del apagado | Muy alto | El último flujo suele ser el más fácil de probar y el primero en olvidarse. La desactivación de dos sistemas auxiliares y una interfaz representa una cifra inequívoca en la factura, sin necesidad de suposiciones. ## Línea Base (Baseline): El punto que determina si la medición es posible Sin una medición previa, cualquier discusión posterior al lanzamiento se convierte en una disputa sobre la memoria. Una línea base adecuada requiere tres elementos: una definición escrita de cómo se calcula el indicador, una fuente de datos que permanezca disponible incluso después de la transición, y una ventana de tiempo suficientemente larga para cubrir la estacionalidad. El error común es medir la línea base únicamente a partir del sistema antiguo. Si el 40% del trabajo se realiza en hojas de cálculo, la línea base medida será superior a la realidad y la mejora parecerá menor de lo que realmente es. Es preferible una estimación manual documentada que un dato exacto de una fuente parcial. ## La regla de atribución Después de un lanzamiento exitoso, existe la tentación de atribuir al sistema cualquier mejora. Tres filtros moderan esta tendencia: 1. **Filtro de causalidad**: ¿Existe un mecanismo explicable que conecte un cambio en el sistema con un cambio en el indicador? Si no, se trata de una correlación. 2. **Filtro del grupo de control**: ¿Un grupo que aún no ha realizado la transición muestra la misma tendencia? Si es así, el factor es externo. 3. **Filtro de volumen**: ¿El indicador aumentó o la actividad aumentó? La normalización por volumen elimina la mayoría de las ilusiones. Aquel que está dispuesto a declarar "esta mejora no es nuestra" gana confianza incluso cuando afirma una mejora que sí le pertenece. ## El lado del costo: Lo que se omite del cálculo El costo del proyecto no es el precio del contrato. El cálculo completo incluye el licenciamiento a lo largo de tres años, un porcentaje anual de mantenimiento y cambios (en la práctica, del 15% al 25% del costo de implementación), el tiempo interno de los empleados en reuniones, en UAT y en capacitación, y el costo de la operación paralela durante el período de transición. Un cálculo que omite el apartado de mantenimiento muestra un retorno rápido en el primer año y una pérdida en el segundo. Un detalle de las estructuras de costos está disponible en [Costo de implementación de Salesforce](/es/insights/salesforce-implementation-cost). ## Qué medir en el primer trimestre En el primer trimestre aún no hay valor de negocio medible, por lo que se miden los factores principales (leading indicators) y no los resultados (lagging indicators): la proporción de procesos que se realizan dentro del sistema y no fuera de él, la calidad de los datos en los campos que alimentan los informes, y el número de solicitudes de cambio que indican una brecha de proceso. Estos tres predicen si el valor llegará. Los indicadores detallados de adopción se encuentran en [Métricas de adopción de Salesforce](/es/insights/salesforce-adoption-metrics). ## Resumen Un ROI confiable se construye a partir de la separación entre el valor cierto (sistemas desactivados) y el valor estimado (ingresos), de una línea base recopilada a tiempo y de la voluntad de renunciar a una atribución que no soporta un escrutinio. Un modelo modesto que se sostiene es más valioso que una gran promesa que nadie verificará. ### Preguntas y respuestas **¿Cuándo debe medirse el Baseline?** El Baseline debe medirse antes de que el nuevo sistema impacte el proceso, generalmente durante la fase de descubrimiento. Un Baseline recopilado después de la implementación ya está afectado por cambios de comportamiento y no es apto para una comparación precisa. HPI Pro le guía en este proceso crucial. **¿Cómo se diferencia el impacto del sistema del impacto del mercado?** Esto se logra de tres maneras: comparando con un grupo de control aún no impactado, normalizando según el volumen de actividad para aislar el efecto del sistema, y enfocándose en métricas de proceso (tiempo de ciclo, tasa de contacto recurrente) que son menos sensibles a las fluctuaciones de la demanda. Nuestros expertos le ayudan a establecer estos controles. **¿Es el ahorro de tiempo de un representante un ROI medible?** Solo si el tiempo liberado se reasigna a actividades de valor medible o si evita una contratación adicional. Diez minutos al día por representante, si mantiene las mismas tareas y productividad, no representan un ahorro de flujo de caja real. En HPI Pro, analizamos el impacto real en la eficiencia operativa. **¿Cuál es el plazo razonable para el retorno de la inversión?** En un proyecto de alcance medio, las métricas de proceso suelen ajustarse en un trimestre, las métricas de ingresos en dos o tres ciclos de ventas, y el retorno de caja completo se mide generalmente entre 18 y 30 meses, incluyendo el costo operativo continuo. Le ayudamos a establecer expectativas realistas y medibles. **¿Qué elementos de costo suelen olvidar las organizaciones?** Las organizaciones a menudo olvidan incluir el licenciamiento continuo, el mantenimiento y las modificaciones post-lanzamiento, el tiempo interno del personal dedicado al proyecto y la capacitación, así como el costo de las integraciones que requieren atención constante. Ignorar estos costos genera un ROI que solo luce bien en papel. En HPI Pro, ofrecemos un análisis de costos integral. --- ## RFP para implementación de Salesforce: estructura, preguntas y entregables esenciales. URL: https://hpi.pro/es/insights/salesforce-rfp-guide Un RFP que detalla una lista de requisitos recibe a cambio una lista de promesas. Un buen documento de solicitud describe procesos, volúmenes y decisiones abiertas, lo que obliga a cada proveedor a demostrar cómo piensa. Aquí presentamos una estructura de documento de nueve partes, las preguntas que distinguen a los proveedores y qué entregables exigir en la propuesta. ## Propósito de un Buen Documento de Solicitud de Propuestas (RFP) El objetivo de un RFP no es obtener un precio. Su finalidad es recibir **ofertas comparables** e identificar qué proveedor ha comprendido el problema. Un documento que detalla cien requisitos y busca una marcación de "compatible / no compatible" produce el efecto contrario: todos los proveedores marcan "compatible" y la decisión recae en el precio. Diferencia práctica: en lugar de escribir "el sistema debe permitir la gestión de oportunidades", describa que la empresa gestiona aproximadamente cuatrocientas transacciones al mes, que cada transacción pasa por una aprobación de precios, y que la aprobación se realiza actualmente por correo electrónico. Los proveedores devolverán respuestas muy diferentes, y esa es precisamente la cuestión. ## Las Nueve Secciones de un Documento RFP para Salesforce **1. Antecedentes y Objetivo de Negocio.** Qué hace la organización, cuál es el problema y qué se consideraría un éxito dentro de un año. De un párrafo a una página. **2. Estado Actual.** Sistemas en uso, número de usuarios, qué funciona y qué no. Si existe un entorno Salesforce, especifique la edición, antigüedad y nivel de personalización. **3. Procesos Centrales en Ámbito.** De tres a siete procesos, cada uno en un párrafo: quién los ejecuta, cuáles son los puntos de decisión, qué ocurre si algo se desvía. **4. Volúmenes y Datos.** Número de registros en cada entidad central, tasa de creación mensual, años de historial a conservar y estado conocido de la calidad. Esta es la sección que más influye en la precisión del pricing y la que más se suele omitir. **5. Integraciones.** Para cada sistema: nombre, tipo de interfaz si se conoce, dirección, frecuencia requerida y propietario en la organización. **6. Restricciones.** Regulación, seguridad de la información, ubicación de almacenamiento, idiomas, accesibilidad, plazos inamovibles. **7. Qué se Requiere del Candidato.** Enfoque propuesto, plan de fases, composición del equipo con nombres y roles, premisas, riesgos y precio con una estructura predefinida. **8. Método de Evaluación.** Criterios y ponderaciones, publicados de antemano. Esto genera propuestas enfocadas y reduce las objeciones después de la adjudicación. **9. Calendario del Concurso.** Fecha límite para preguntas, fecha límite para respuestas, fecha límite para la presentación, fecha de demostraciones, fecha de decisión. ## Datos que Deben Revelarse para Obtener un Pricing Real | Dato | Por qué es Crítico | Qué Sucede Sin Él | | --- | --- | --- | | Número de usuarios por tipo | Determina licencia, capacitación y permisos | Propuestas con un rango demasiado amplio | | Volumen y historial de registros | Determina el esfuerzo de migración | La migración se cotiza con una estimación burda | | Número de sistemas fuente | Determina la complejidad e integración | Sorpresas después de la firma | | Nivel de documentación existente | Determina cuánto descubrimiento se requiere | Los proveedores asumen documentación existente | | Disponibilidad de los propietarios de procesos | Determina el ritmo de las decisiones | Calendario irreal acordado por ambas partes | | Presupuesto o rango | Enfoca la solución | Propuestas incomparables | ## Preguntas que Distinguen a los Proveedores Las siguientes preguntas reciben respuestas muy diferentes de distintos proveedores, lo que las hace útiles. Una pregunta a la que todos responden igual no merece un lugar en el documento. - ¿Cuáles son las tres suposiciones principales en las que se basa la propuesta y cuál es la implicación si alguna de ellas es incorrecta? - ¿En qué casos recomendaría la configuración, aunque el desarrollo funcionaría mejor, y viceversa? - Describa un proyecto en el que se haya excedido del cronograma. ¿Qué lo causó y qué ha cambiado desde entonces? - ¿Quiénes serán los miembros del equipo que trabajarán en el proyecto y qué porcentaje de tiempo dedicará cada uno a este proyecto? - ¿Qué necesitan de nosotros para tener éxito y qué harán si no lo reciben? - ¿Cómo nos transferirán la capacidad de mantener el sistema sin ustedes? La última pregunta es una buena prueba de la naturaleza de la relación. Un proveedor que la evade planea la dependencia. ## Qué Solicitar como Resultado Dentro de la Propuesta - **Diagrama de arquitectura preliminar** a nivel de bloques, incluyendo fuentes de verdad. - **Plan de fases** con el contenido de cada fase y no solo fechas. - **Detalle del precio con una estructura uniforme** que usted dicte, por fase y por rol. - **Lista explícita de suposiciones.** - **Mapa de riesgos** con un plan de mitigación. - **Ejemplo de un producto real** de un proyecto anterior, con nombres ocultos, por ejemplo, un documento de decisiones o un plan de prueba. El último elemento es quizás el más distintivo, ya que muestra un estándar de trabajo y no una promesa. ## Estructura de Precios Uniforme: La Herramienta para Prevenir la Comparación de Elementos Dispares Defina usted mismo la tabla que todo proponente debe completar: | Fase | Horas Sénior | Horas Júnior | Costo | Qué se Considera Completado | | --- | --- | --- | --- | --- | | Levantamiento de Requisitos | | | | | | Configuración y Desarrollo de la Fase 1 | | | | | | Integraciones | | | | | | Migración de Datos | | | | | | Pruebas y UAT | | | | | | Capacitación y Adopción | | | | | | Estabilización Post-Go-Live | | | | | | Gestión del Proyecto | | | | | Un proveedor que se niega a desglosar el precio según esta estructura no es necesariamente costoso, pero es imposible compararlo, y esta es una razón suficiente para pedirle la reconsideración. ## Ejemplo Ilustrativo: Fondo de Pensiones Mediano El escenario es hipotético y tiene fines ilustrativos. Una entidad financiera emitió un RFP que incluía ochenta requisitos funcionales en una tabla. Los cuatro proponentes marcaron "compatible" en casi todas las líneas, y las ofertas solo se diferenciaban en el precio y el número de horas. En una segunda ronda, el documento se modificó: en lugar de la tabla de requisitos, se incluyeron tres procesos completamente descritos, datos de volumen reales y una solicitud para resolver un escenario en la demostración. Las propuestas recibidas diferían materialmente entre sí: una proponía un modelo de datos completamente diferente, otra identificó una dependencia de la aprobación regulatoria que nadie había considerado. El comité no eligió la oferta más barata ni hizo objeciones. Eligió la que mejor pudo explicar por qué el séptimo requisito del documento original no era necesario en absoluto. ## Errores Comunes al Redactar un RFP - Copiar un documento de otro proyecto sin ajustar volúmenes y procesos. - Solicitar una lista de clientes en lugar de ejemplos de productos. - Criterios de evaluación redactados después de recibir las propuestas. - Un cronograma que no deja tiempo para preguntas y respuestas. - Preferencia encubierta por un proveedor existente, lo que hace que otros inviertan en vano y perjudica la calidad de las futuras propuestas. ## Qué Sucede Después de la Presentación Un buen documento es solo la mitad del trabajo. El siguiente paso es la normalización y comparación de las propuestas sobre la misma base, como se detalla en la [guía de comparación de propuestas de Salesforce](/es/insights/compare-salesforce-proposals), y luego una puntuación estructurada según ponderaciones predefinidas, como se detalla en la [guía de Scorecard para la selección de proveedores](/es/insights/salesforce-vendor-scorecard). La base de información para la redacción del documento en sí proviene a menudo de un proceso de consultoría breve, como se describe en la [guía de consultoría de Salesforce](/es/insights/salesforce-consulting-guide), y los criterios para evaluar a la empresa se resumen en la [guía para elegir una empresa de implementación](/es/insights/choose-salesforce-implementation-company). ## Siguiente Paso Antes de enviar el documento, realice una última comprobación: déjelo leer a alguien de la organización que no esté involucrado en el proyecto y pídale que explique en una frase cuál es el problema que intenta resolver. Si no puede, los proveedores tampoco podrán, y simplemente devolverán lo que están acostumbrados a vender. ### Preguntas y respuestas **¿Cuántos proveedores debería invitar a un RFP para la implementación de Salesforce?** De tres a cinco. Menos de tres no ofrece una base de comparación suficiente, y más de cinco genera una carga de evaluación que lleva al comité a basarse en el precio en lugar del contenido. Si hay más candidatos calificados, es preferible realizar una ronda de filtrado corta basada en un cuestionario conciso antes de enviar el documento completo. **¿Es necesario revelar el presupuesto en el RFP?** Es preferible revelar un rango o un tope. La divulgación evita propuestas irrelevantes y permite a los proveedores proponer una división por fases dentro del marco presupuestario. No revelar el presupuesto generalmente lleva a los proveedores a cotizar lo que suponen que aprobará, y no lo que se necesita para resolver el problema. **¿Qué hacer si los proveedores hacen preguntas que revelan lagunas en el documento?** Publicar todas las preguntas y respuestas a todos los proponentes en la misma fecha, y actualizar el documento si es necesario. Una buena pregunta de un proveedor es un indicador positivo, por lo que es recomendable documentar quién preguntó qué; esta es una de las mejores métricas para evaluar su comprensión profunda. **¿Se debe solicitar una demostración en vivo como parte del RFP?** Sí, pero no una demostración de producto. Pida al proponente que resuelva un escenario breve de su realidad y explique las consideraciones de implementación. Una demostración de producto estándar muestra lo que Salesforce puede hacer, y esa información no distingue entre proveedores; la resolución de un escenario muestra cómo piensa el proveedor. **¿Cuánto tiempo se debe dar a los proveedores para presentar una propuesta?** De tres a cuatro semanas para un proyecto mediano, incluyendo una ronda de preguntas y respuestas a mitad del proceso. Un plazo demasiado corto genera propuestas basadas en plantillas, que son precisamente lo que se quiere evitar. Si el cronograma es apretado, es preferible reducir la cantidad de información requerida en la propuesta y no el tiempo de preparación. --- ## ¿Cómo comparar propuestas de proyectos Salesforce sin caer en el precio más bajo? URL: https://hpi.pro/es/insights/compare-salesforce-proposals Una oferta un 30% más barata casi siempre significa una oferta diferente, no necesariamente una mejor. Una comparación correcta comienza con la normalización: el mismo alcance, el mismo período de garantía, los mismos componentes ocultos. Presentamos un método de normalización en seis pasos, un mapa de costos que desaparecen de la oferta y un modelo de comparación de costos a tres años. ## Por qué es casi imposible comparar propuestas de Salesforce Al examinar tres propuestas y constatar una diferencia de decenas de puntos porcentuales, el primer instinto es considerar que una de ellas está inflada. En la mayoría de los casos, la razón es más simple: cada propuesta cotiza un proyecto diferente. Un proveedor incluyó la migración de tres años de historial, mientras que otro asumió un año. Uno contempló seis semanas de estabilización después de la puesta en marcha, el otro entregó y finalizó. Uno calculó cuatro integraciones, el otro dos, asumiendo que un informe diario reemplazaba una interfaz en tiempo real. Ninguno de ellos engañó, simplemente no se les indicó lo contrario. La comparación, por lo tanto, comienza con la normalización, no con una tabla de precios. ## Método de normalización en seis pasos **1. Establezca una lista uniforme de componentes.** Once líneas son suficientes: definición de requisitos, configuración, desarrollo, integraciones, migración, pruebas, capacitación, gestión de proyectos, estabilización, documentación, transferencia de conocimiento. **2. Indique para cada propuesta qué está incluido, qué es parcial y qué falta.** No complete montos en esta etapa. **3. Valore lo que falta.** Para cada componente no incluido en una propuesta, utilice el costo de otra propuesta como estimación y añádalo. **4. Estandarice las suposiciones.** Número de usuarios, edición, años de historial, número de unidades de negocio, idiomas. **5. Estandarice el período de garantía.** Un período diferente equivale a dinero. Una diferencia de dos meses en la estabilización es un componente de costo real. **6. Calcule el costo promedio por hora y la composición del equipo** en cada etapa, no solo el total. Solo después de estos seis pasos se pueden comparar las cifras. En muchos casos, la propuesta que parecía más económica pasa a segundo lugar. ## Componentes que desaparecen de las propuestas y aparecen en la factura | Componente | Por qué se omite | Magnitud relativa | | --- | --- | --- | | Limpieza de datos previa a la migración | Se considera responsabilidad del cliente | A veces muy significativo | | Segunda ronda de UAT | Se asume una sola ronda | Baja pero bloquea el cronograma | | Capacitación por rol | Se cotiza como un único taller | Media | | Soporte intensificado en las primeras semanas | No definido | Medio a alto | | Documentación propiedad de la organización | Se asume como algo obvio | Baja, crítica a futuro | | Manejo de errores de integración y monitoreo | Solo se incluye el "camino feliz" | Medio | | Entornos y DevOps | Se asume su existencia | Bajo a medio | | Horas de gestión interna de la organización | No incluido en la propuesta | Alto, y siempre presente | El último punto es el que más sorprende a la dirección. Un proyecto de Salesforce consume una cantidad significativa de tiempo de los responsables de procesos y de la PMO, y este es un costo real, aunque no aparezca en ninguna factura. ## De la comparación de precios a la comparación de costos a tres años Una propuesta se evalúa correctamente en un período de tres años, no solo durante la duración del proyecto. Una estructura de cálculo sencilla: | Componente | Año 1 | Año 2 | Año 3 | | --- | --- | --- | --- | | Costo de implementación | Completo | — | — | | Licenciamiento | Según número de usuarios | Incluye crecimiento esperado | Incluye crecimiento esperado | | Mantenimiento y soporte | Parcial | Completo | Completo | | Mejoras planificadas | — | Alcance estimado | Alcance estimado | | Costo de gestión interna | Alto | Medio | Medio | La diferencia entre las propuestas en el primer año puede parecer grande. A lo largo de tres años, lo que suele prevalecer es la facilidad con la que se podrá modificar el sistema sin depender del proveedor, es decir, la calidad de la documentación y la transferencia de conocimiento, que casi nunca se ponderan en la decisión. ## Señales de alerta en una propuesta - La migración de datos se cotiza con una suma global sin preguntas sobre el volumen o la calidad. - No hay período de garantía, o se define como "solución de errores" sin especificar qué constituye un error. - Una propuesta que incluye solo horas de desarrollo y no tiene una línea de gestión de proyectos. - Composición del equipo sin nombres, o nombres no comprometidos contractualmente. - Un precio particularmente bajo para la fase de definición de requisitos, que a veces es una puerta de entrada a un proyecto que luego se cotizará más alto. - No hay suposiciones explícitas. Una propuesta sin suposiciones es una propuesta no revisada. ## Ejemplo ilustrativo: empresa de energía renovable El escenario es hipotético y tiene fines ilustrativos. Una empresa recibió tres propuestas. La diferencia entre la más económica y la más costosa era de aproximadamente el ochenta por ciento. El comité se inclinó por la más económica. Después de la normalización, se hizo evidente: la propuesta económica no incluía migración alguna, sino solo la carga de registros de actividad; asumía dos integraciones en lugar de cuatro, porque consideraba que el informe financiero se realizaría mediante exportación manual; y el período de garantía era de dos semanas frente a ocho semanas en la propuesta más costosa. Después de complementar los costos faltantes con los de los otros proveedores, la diferencia se redujo a aproximadamente un diez por ciento. La decisión final no se basó en el precio, sino en determinar qué proveedor ofrecía una transferencia de conocimiento estructurada, ya que la empresa no contaba con un equipo interno. ## Qué hacer con la brecha restante Después de la normalización, generalmente queda una brecha real. Transforme esto en preguntas y no en suposiciones: - ¿Por qué su estimación para la integración es menor que la de otros? ¿Qué saben ustedes que ellos no saben? - ¿Qué sucede si la suposición sobre la calidad de los datos no es correcta? - ¿Cuántos ciclos de prueba planificaron? - ¿Quién del equipo presentado acompañará el proyecto de principio a fin? Las respuestas a estas preguntas distinguen entre un proveedor que cotizó a bajo precio por ser eficiente y un proveedor que cotizó a bajo precio por no comprender. ## Conexión con la decisión final Una comparación estructurada solo aborda el aspecto comercial. El aspecto profesional se evalúa por separado, según ponderaciones predefinidas, y el precio es solo uno de ellos; los detalles se encuentran en la [guía para elegir una empresa de implementación de Salesforce](/es/insights/choose-salesforce-implementation-company). La comprensión de lo que compone el costo desde el principio se detalla en la [guía sobre el costo de implementación de Salesforce](/es/insights/salesforce-implementation-cost), y la elección del modelo de contratación en la [guía de precios de proyectos](/es/insights/salesforce-project-pricing-models). Lo acordado en la comparación debe reflejarse en el contrato con una redacción precisa; de lo contrario, no existe. Las cláusulas relevantes se encuentran en la [guía de contrato y SOW de Salesforce](/es/insights/salesforce-sow-contract-clauses). ## Próximo paso Construya la tabla de normalización antes de abrir las propuestas económicas. Quien la construye después de haber visto los montos, la construye, sin intención, de manera que justifique la propuesta que ya le ha agradado. ### Preguntas y respuestas **¿Qué significa una diferencia del 40% entre propuestas de Salesforce?** Casi siempre significa que las propuestas se refieren a un alcance diferente, no que un proveedor sea un 50% más eficiente. Las diferencias comunes incluyen la migración de datos (incluida o no), el número de integraciones consideradas, el período de estabilización post-lanzamiento y la capacitación. Antes de negociar el precio, es crucial asegurar que estos tres elementos estén definidos de manera idéntica en todas las ofertas. **¿Cómo se comparan ofertas con una composición de equipo diferente?** Calcule el costo promedio por hora y observe la proporción senior-junior en cada etapa. Una propuesta con una tarifa horaria baja y un equipo totalmente junior podría requerir más horas para el mismo trabajo. Lo importante es quién liderará las decisiones de arquitectura y qué porcentaje de su tiempo se asigna al proyecto. **¿Deberíamos pedir a los proveedores que ajusten su propuesta después de la comparación?** Sí, una ronda de aclaraciones es una práctica normal y beneficiosa. Envíe a cada proponente solo las discrepancias que identificó en su alcance, sin revelar los precios de otros, y solicite una propuesta actualizada con la misma estructura. Esta ronda suele reducir significativamente la brecha entre las ofertas y revela quién ha comprendido verdaderamente el proyecto. **¿Qué hacer cuando la oferta más barata proviene de un proveedor menos sólido?** Traduzca la diferencia monetaria en lugar de discutirla como una percepción. Una estimación realista de una ronda de corrección adicional, un retraso en el cronograma y horas adicionales de gestión interna genera una cifra que se puede comparar. Por lo general, la diferencia comercial se reduce significativamente después de esta traducción. **¿El costo de las licencias de Salesforce está incluido en la propuesta del integrador?** Normalmente no, y se adquiere por separado. Es vital asegurarse de que todos los proponentes hayan asumido la misma edición y el mismo número de usuarios, ya que una suposición diferente también cambia el alcance del trabajo: una funcionalidad disponible en una edición superior podría requerir desarrollo en una edición inferior. --- ## Contrato y SOW para proyectos de Salesforce: Cláusulas que protegen la entrega URL: https://hpi.pro/es/insights/salesforce-sow-contract-clauses La mayoría de los conflictos en proyectos Salesforce no radican en el precio, sino en lo que se considera completado. Un buen SOW define la aceptación, las dependencias mutuas, la propiedad de los entregables y una salida ordenada. Aquí presentamos doce cláusulas con redacción sugerida y la explicación de lo que previene cada una en la práctica. ## Lo que realmente quiebra los proyectos por contrato Casi ningún conflicto en un proyecto de Salesforce comienza con la pregunta "¿cuánto cuesta?". Comienza con la pregunta "¿está terminado?". El proveedor cree que el producto ha sido entregado; la organización cree que no es utilizable. Ambas partes tienen razón desde su propia perspectiva, porque nadie definió de antemano qué se consideraría completado. De aquí se deriva un principio que guía todas las cláusulas de este artículo: **un buen contrato no protege a su parte en un conflicto, lo previene.** ## Las doce cláusulas ### 1. Definición de aceptación para cada entregable La cláusula más importante. Cada entregable requiere un criterio observable: no "pantalla de gestión de clientes", sino "un usuario con el perfil X puede ejecutar el escenario Y y obtener el resultado Z, según lo definido en los criterios de aceptación aprobados". Redacción recomendada: un período de prueba definido a partir del momento de la entrega, al final del cual el cliente aprueba o detalla por escrito las deficiencias. El silencio más allá del período se considera una aprobación, una cláusula que protege al proveedor y genera disciplina en el cliente. ### 2. Mecanismo para solicitudes de cambio Define quién está autorizado a solicitar, quién evalúa, en cuánto tiempo y a qué tarifa. La tarifa debe establecerse en el momento de la firma y no cuando surja la necesidad. ### 3. Dependencia bidireccional La mayoría de los contratos definen qué sucede cuando el proveedor se retrasa y no definen qué sucede cuando el cliente se retrasa. Resultado: cuando la organización demora una aprobación, el proveedor la absorbe, y luego la traslada a través de solicitudes de cambio. Redacción equilibrada: el cronograma está condicionado a una respuesta definida del cliente (tiempo de aprobación, disponibilidad del propietario del proceso, entrega de datos), y un retraso excesivo desplaza el hito mediante notificación escrita. ### 4. Propiedad del código, configuración y documentación Separación entre el producto dedicado y los componentes genéricos del proveedor, con una licencia de uso ilimitada en el tiempo para los componentes genéricos, que no está condicionada a la continuación de la relación. ### 5. Documentación como entregable vinculante La documentación que no se define como un entregable con un criterio de aceptación, no se escribirá o se escribirá en la última semana. Defina un mínimo: decisiones arquitectónicas, modelo de datos, mapeo de integraciones, procedimientos operativos. ### 6. Garantía y corrección de defectos Un período definido y una definición clara de lo que es un defecto frente a un cambio. Una definición funcional: una discrepancia entre el comportamiento real y los criterios de aceptación aprobados es un defecto. ### 7. Personal clave Nombres, porcentaje de asignación, preaviso para el reemplazo y nivel profesional equivalente con la aprobación del cliente. ### 8. Accesos, entornos y seguridad de la información Quién obtiene acceso a qué entornos, por cuánto tiempo, qué sucede con los accesos al finalizar y cómo se manejan los datos reales en entornos que no son de producción. ### 9. Cumplimiento de requisitos regulatorios y de privacidad Ubicación del almacenamiento, manejo de información personal, derecho de auditoría e informe de incidentes de seguridad. En organizaciones reguladas, esta es una cláusula que requiere una redacción específica y no una plantilla. ### 10. Puertas de decisión y puntos de salida Derecho a detenerse al finalizar un hito definido, con un acuerdo de pago preestablecido. Una cláusula así reduce el riesgo para ambas partes, por lo que un buen proveedor no se opondrá. ### 11. Transferencia de conocimiento No "capacitación", sino: número de horas, a quién, sobre qué y cuál es el resultado. Es preferible que la transferencia se distribuya a lo largo del proyecto y no se concentre al final. ### 12. Finalización y salida Una lista de lo que se entrega, formato, período de solapamiento, tarifa por horas de soporte para la transferencia. Esta es la cláusula que nadie quiere discutir en el momento de firmar, y es precisamente por eso que vale la pena insistir en ella entonces. ## Mapa de riesgos: qué previene cada cláusula | Cláusula | Fallo que previene | Costo de la ausencia | | --- | --- | --- | | Definición de aceptación | Discusión sobre "terminado" | Retraso en el pago y en la puesta en marcha | | Solicitudes de cambio | Fijación de precios en momentos de necesidad | Aumento incontrolado de costos | | Dependencia bidireccional | Acusación mutua de retraso | Desplazamiento del cronograma sin transparencia | | Propiedad y documentación | Dependencia del proveedor | Alto costo al cambiar de proveedor | | Personal clave | Reemplazo silencioso del equipo | Pérdida de contacto y conocimiento | | Garantía | Discusión defecto vs. cambio | Doble pago por corrección | | Salida | Negociación desde una posición de debilidad | Costo de transferencia imprevisto | ## Redacciones a evitar - "El proveedor realizará el trabajo con la profesionalidad habitual" — esto no puede aplicarse sin un criterio. - "Las partes acordarán en adelante sobre..." — cada cláusula de este tipo es un conflicto futuro en espera. - "Sujeto a la plena cooperación del cliente" — sin definir qué es esto, es una protección unilateral. - "El entregable se entregará al finalizar el proyecto" — sin definir qué es la finalización. - Calendario de pagos según fechas de calendario en lugar de según la aceptación. ## Ejemplo ilustrativo: cadena minorista El escenario es hipotético y está destinado a la ilustración. Una cadena firmó un SOW que incluía "migración de datos de clientes desde un sistema existente". La suposición de la organización era que la migración incluía la limpieza de duplicados; la suposición del proveedor era que transfería lo que le era entregado. En la práctica, se transfirieron cientos de miles de registros con duplicados. Ambas partes leyeron la misma frase y la entendieron de manera opuesta. No había una línea en el contrato que definiera qué se consideraba un registro válido. La corrección realizada en los acuerdos posteriores de esa cadena fue breve: un anexo que definía un umbral de calidad medible para la carga – tasa de registros que pasan la validación, reglas de identificación de duplicados y quién aprueba. Este anexo reemplazó docenas de horas de discusión. ## Qué verificar antes de firmar - Cada entregable de la propuesta aparece en el SOW con un criterio de aceptación. - Toda suposición presentada en la propuesta aparece como una suposición explícita en el contrato. - El cronograma de pagos está vinculado a la aceptación. - Existe una cláusula de salida y una cláusula de transferencia de conocimiento. - La definición de defecto es lo suficientemente clara como para resolver un caso límite. Lo que se acordó en la comparación de propuestas pero no se incluyó en el contrato, simplemente no existe. El proceso de comparación en sí se detalla en la [guía de comparación de propuestas de Salesforce](/es/insights/compare-salesforce-proposals), y la base para redactar los requisitos se establece ya en el documento de solicitud de propuesta, como se detalla en la [guía de RFP](/es/insights/salesforce-rfp-guide). ## La conexión con la selección del proveedor Algunas de las cláusulas de aquí también sirven como herramientas de evaluación: un proveedor que se opone a una cláusula sobre la propiedad de la documentación o a una cláusula de salida, le está diciendo algo sobre su modelo de operación. La combinación de la evaluación profesional con la disposición contractual se puntúa conjuntamente en la [Guía de Scorecard para la selección de proveedores de Salesforce](/es/insights/salesforce-vendor-scorecard), y los criterios amplios para la verificación de la empresa se resumen en la [guía para elegir una empresa de implementación de Salesforce](/es/insights/choose-salesforce-implementation-company). La adecuación del tipo de contratación al tipo de servicio adquirido se detalla en la [guía de servicios de Salesforce](/es/insights/salesforce-services-guide). ## Siguiente paso Tome el SOW que tiene delante y marque cada lugar donde dice "se entregará" o "se realizará" sin especificar cómo se sabrá que esto ha ocurrido. Cada una de estas marcas es un conflicto potencial, y cada una cuesta cinco minutos de arreglar ahora mismo. ### Preguntas y respuestas **¿Cuál es la diferencia entre un acuerdo marco y un SOW en un proyecto Salesforce?** El acuerdo marco regula las relaciones legales: confidencialidad, responsabilidad, seguros, propiedad intelectual, condiciones de pago y resolución de disputas. El SOW regula el trabajo en sí: entregables, hitos, aceptación, supuestos y alcance. Un mismo acuerdo marco puede servir para múltiples SOW, lo cual es una estructura conveniente al trabajar por fases. **¿A quién pertenecen el código y la configuración desarrollados en un proyecto Salesforce?** Esto se define exclusivamente en el contrato. Por defecto, algunos proveedores establecen que el producto específico pertenece al cliente, pero los componentes genéricos y la infraestructura del proveedor siguen siendo de su propiedad, bajo una licencia de uso. Es crucial asegurarse de que esta licencia sea ilimitada en el tiempo y no dependa de la continuidad de la relación, ya que, de lo contrario, un cambio de proveedor podría generar problemas. **¿Qué período de garantía es razonable especificar después de la puesta en marcha?** Entre treinta y noventa días, según la complejidad. Más allá de la duración, lo importante es la definición: qué se considera un defecto reparado sin costo versus una solicitud de cambio. La formulación práctica es que cualquier brecha entre el comportamiento real y los criterios de aceptación aprobados es un defecto, y todo lo demás es un cambio. **¿Cómo redactar una cláusula para protegerse contra el cambio de personal del proveedor?** Se nombra al personal clave y su porcentaje de dedicación, y se exige notificación anticipada y reemplazo por personal de nivel profesional equivalente previa aprobación del cliente. Además, conviene establecer un período mínimo de solapamiento. Una cláusula así no impide la salida, pero la transforma de una sorpresa en un proceso gestionado. **¿Qué se debe incluir en una cláusula de salida de la contratación?** Una lista de entregables, formato de entrega, período de solapamiento, transferencia de accesos y entornos, y el precio por horas de soporte para la transición. Sin esta cláusula, la finalización de la relación se convierte en una negociación desde una posición de debilidad, ya que el conocimiento y los accesos están en manos de la otra parte. --- ## Scorecard para la Selección de un Proveedor Salesforce: Criterios y Ponderaciones URL: https://hpi.pro/es/insights/salesforce-vendor-scorecard Un comité de selección sin un modelo de puntuación acordado a menudo llega a una decisión justificada a posteriori. Un Scorecard predefinido establece qué se mide, qué evidencia se requiere para cada puntuación y qué invalida una opción de inmediato. Aquí presentamos un modelo de siete dimensiones con ponderaciones de ejemplo y un proceso de puntuación que previene sesgos. ## Por qué los comités seleccionan bien y justifican mal En una reunión de decisión típica, después de tres presentaciones, los participantes expresan frases como "me impresionaron" o "parecían los más profesionales". A veces, la elección es correcta. El problema es que no hay forma de saberlo —y no hay forma de explicar la decisión un año después, cuando el proyecto se complica. Un Scorecard no pretende reemplazar el juicio. Su objetivo es asegurar que todos los oferentes fueron evaluados según los mismos criterios, que la evidencia de cada calificación fue documentada, y que lo que el comité consideró importante antes de ver las presentaciones fue lo que también prevaleció después. ## Las siete dimensiones de evaluación **1. Comprensión del problema.** Si la propuesta aborda sus procesos y volúmenes, o si es genérica. Si el proponente identificó alguna inconsistencia o brecha en el documento de consulta. **2. Calidad de la propuesta arquitectónica.** Si incluye un diagrama, si se definieron fuentes de verdad, si se consideraron alternativas y se explicó por qué fueron rechazadas. **3. El equipo de trabajo.** Quién lidera, cuánto tiempo dedica, quién ejecuta y la proporción de profesionales sénior en las fases decisorias. **4. Experiencia relevante.** No la cantidad de proyectos, sino la similitud: industria, complejidad de la integración, magnitud y regulación. **5. Modelo de trabajo y gobernanza.** Ritmo de demostraciones, gestión de decisiones, gestión de riesgos y manejo de cambios. **6. Transferencia de conocimiento e independencia.** Si existe un plan explícito que les permita mantener el sistema sin su asistencia. **7. Comercial.** Precio normalizado, modelo de contratación, flexibilidad contractual y disposición a cláusulas de protección. ## Ponderaciones de ejemplo — y cómo ajustarlas | Dimensión | Proyecto nuevo en organización sin equipo | Proyecto de rescate | Expansión en organización con equipo robusto | | --- | --- | --- | --- | | Comprensión del problema | 20% | 25% | 15% | | Arquitectura | 20% | 20% | 25% | | Equipo de trabajo | 15% | 20% | 15% | | Experiencia relevante | 10% | 10% | 10% | | Modelo de trabajo y gobernanza | 10% | 10% | 10% | | Transferencia de conocimiento | 10% | 5% | 5% | | Comercial | 15% | 10% | 20% | La tabla ilustra un principio: las ponderaciones no son fijas, sino que derivan del riesgo dominante. En una organización sin equipo interno, la transferencia de conocimiento es más valiosa. En el rescate de un proyecto, la comprensión de la situación y la identidad del equipo son más importantes. Defina las ponderaciones **antes** de recibir las propuestas y publíquelas en el documento de consulta, tal como se especifica en la [Guía de RFP](/es/insights/salesforce-rfp-guide). ## Escala de calificación con evidencia requerida El problema con una escala de 1 a 5 es que todos califican con 4. La solución es asignar evidencia a cada nivel: | Calificación | Significado | Evidencia requerida | | --- | --- | --- | | 1 | No cumplido | El tema no aparece en la propuesta | | 2 | Genérico | Texto de plantilla sin referencia a la organización | | 3 | Suficiente | Referencia correcta, pero sin profundidad o alternativas | | 4 | Bueno | Referencia específica con justificación y ejemplo | | 5 | Excelente | Alternativas consideradas, riesgo identificado, y recomendación en contra de algo solicitado | La evidencia para una calificación de 5 es lo que hace que el modelo sea útil: un proveedor que dice "esta parte no deberían construirla ahora" demuestra una comprensión que no se puede falsear. ## Condiciones de descalificación — antes de calificar Hay aspectos que no tiene sentido ponderar, porque son motivos de descalificación: - Negativa a ceder la propiedad de los entregables y la documentación a la organización. - Negativa a nombrar a los miembros del equipo y sus porcentajes de asignación. - Incumplimiento de requisitos regulatorios o de seguridad de la información obligatorios. - Propuesta que no se ajusta a la estructura de precios definida, después de haber tenido la oportunidad de corregirla. - Falta de disposición a incluir una cláusula de salida básica. Defínalos de antemano. Una descalificación que se decide a posteriori siempre parece estar dirigida contra un proponente específico. ## Proceso de calificación que reduce el sesgo 1. Cada miembro del comité califica **individualmente** antes de la discusión conjunta. 2. La calificación se acompaña de un breve comentario que cita una fuente en la propuesta. 3. La discusión se centra solo en las grandes diferencias entre los calificadores — allí se encuentra la información clave. 4. El precio se revela en esta etapa y no antes, si el proceso lo permite. 5. La calificación final se documenta junto con la justificación. El cuarto paso tiene el mayor impacto. Un comité que ha visto los precios antes de calificar la calidad, calificará la calidad en función del precio, casi siempre sin darse cuenta. ## Ejemplo de ilustración: empresa de seguridad comercial El escenario es hipotético y tiene fines ilustrativos. Un comité de selección calificó a cuatro oferentes. La propuesta que obtuvo la calificación más alta en la dimensión "experiencia relevante" recibió la calificación más baja en la dimensión "comprensión del problema", porque el documento que presentó era casi idéntico a un documento que había presentado en otro proyecto, incluyendo un nombre de sector irrelevante. En la discusión, se argumentó que la experiencia compensaba. El comité regresó a las ponderaciones que había establecido dos meses antes, donde la comprensión del problema tenía el doble de peso que la experiencia. La decisión se mantuvo. Lo que el modelo previno aquí no fue necesariamente una elección equivocada, sino un cambio en las reglas de juego después de que el resultado ya era conocido. ## Qué hacer con el resultado La calificación no es una decisión. Es un documento que permite una conversación productiva: dónde está la mayor diferencia entre los oferentes, qué falta en la propuesta del líder y qué riesgo queda abierto. Muchas veces, el resultado más útil es una lista de condiciones para el contrato, y no una elección entre proveedores. El aspecto comercial se normaliza por separado antes de la calificación, tal como se detalla en la [Guía para comparar propuestas](/es/insights/compare-salesforce-proposals), y la relación entre la estructura de costos y la calificación comercial se explica en la [Guía de costo de implementación de Salesforce](/es/insights/salesforce-implementation-cost). ## Integración con la entrevista profesional La calificación basada en documentos es limitada. Un complemento esencial es una reunión en la que se formulan preguntas abiertas al proveedor y se evalúa su forma de pensar en tiempo real. Un conjunto completo de preguntas se encuentra en la [Guía de preguntas antes de elegir un integrador Salesforce](/es/insights/questions-before-choosing-salesforce-integrator), y los criterios generales para evaluar a la empresa en la [Guía para elegir una empresa de implementación Salesforce](/es/insights/choose-salesforce-implementation-company). ## El siguiente paso Ponga por escrito sus ponderaciones antes de leer la primera propuesta, y pida a cada miembro del comité que califique individualmente. Estos dos pasos, que en conjunto toman una hora, mejoran la calidad de la decisión más que cualquier ronda adicional de presentaciones. ### Preguntas y respuestas **¿Qué peso se debe asignar al precio al seleccionar un proveedor Salesforce?** En proyectos donde el resultado depende principalmente de la calidad de las decisiones, una ponderación del veinte al treinta por ciento es común y suficiente. Un peso mayor convierte la elección en una decisión basada únicamente en el precio, mientras que un peso demasiado bajo desconecta la decisión de la realidad presupuestaria. Más importante que el peso es que el precio puntuado se normalice al mismo alcance. **¿Quién debería formar parte del comité de selección?** Un representante de compras, el propietario del proceso principal, una figura tecnológica que mantendrá el sistema y un representante financiero. Un tamaño típico es de cuatro a seis miembros. Un comité más grande tiende a una puntuación promedio que no diferencia entre los proponentes, por lo que es preferible incluir a otras partes como asesores en lugar de como evaluadores. **¿Las entrevistas con clientes anteriores realmente valen la pena?** Sí, si se hacen las preguntas correctas. Preguntas sobre la satisfacción generan respuestas educadas. Las preguntas que producen información valiosa son: qué salió mal y cómo reaccionó el proveedor, quién fue el gerente de proyecto y qué hizo, y qué habría hecho usted de manera diferente. Es preferible pedir referencias sobre un proyecto que fue complejo y no sobre un proyecto insignia. **¿Qué hacer cuando dos proveedores obtienen una puntuación casi idéntica?** No agregue un nuevo criterio a posteriori, ya que es precisamente donde se cuelan las preferencias personales. La herramienta correcta es una ronda enfocada: el mismo escenario breve para ambos, la misma pregunta sobre la gestión de riesgos y una evaluación del equipo real. La diferencia que se revela allí suele ser más clara que cualquier tabla. **¿Es preferible un proveedor grande o boutique en un proyecto Salesforce?** La respuesta depende del tipo de riesgo que le preocupe. Un proveedor grande ofrece profundidad de recursos y continuidad, generalmente a un precio más alto y con menor flexibilidad. Un proveedor boutique ofrece un contacto directo con los directivos y mayor flexibilidad, con el riesgo de dependencia de personas individuales. Ambos riesgos se pueden puntuar explícitamente en lugar de decidir por una percepción de tamaño. --- ## Límites de API en Salesforce: Planificación de Integraciones Sólidas y Resilientes URL: https://hpi.pro/es/insights/salesforce-api-limits-resilience Salesforce contabiliza las llamadas a la API en ventanas de 24 horas y, superado el umbral, simplemente las bloquea, no las ralentiza. Una organización que ejecuta una sincronización nocturna, un webhook entrante y reportes simultáneamente necesita un presupuesto de llamadas planificado, no solo un reintento después de agotar la cuota. Esta guía desglosa los límites en la práctica: cómo medir el consumo, cuándo migrar a la API masiva (Bulk API) y cómo construir un retroceso exponencial (Exponential Backoff) que no sature el sistema con una segunda oleada de fallos. ## Qué se rompe primero cuando se ignoran los límites de la API Una empresa que ejecuta tres integraciones simultáneamente —sincronización nocturna de ERP, webhook de un sistema de pagos y un panel externo que extrae datos cada cinco minutos— no falla gradualmente. Funciona perfectamente hasta que cruza un umbral, y entonces cada llamada adicional a la API es rechazada con el código `REQUEST_LIMIT_EXCEEDED` hasta el restablecimiento diario. No hay una alerta temprana incorporada que lo impida de antemano; solo existe un panel que se puede consultar, si alguien ha configurado un proceso para hacerlo. Este tipo de fallo es diferente de la mayoría de los fallos en los proyectos de Salesforce porque no depende de un código deficiente o de un diseño defectuoso. Depende de la acumulación: una nueva integración siempre se construye frente al estado actual, sin verificar cuánto del presupuesto diario ya ha sido consumido por los procesos existentes. El resultado es que la quinta integración "rompe" las cuatro anteriores, a pesar de que ninguna de ellas ha cambiado. ## Mapa de los límites relevantes en la práctica No todos los límites existentes en Salesforce son igualmente importantes para el diseño de integraciones. Aquellos que realmente determinan la arquitectura son: | Tipo de límite | Lo que mide | A quién afecta primero | | --- | --- | --- | | Solicitudes API diarias | Total de llamadas REST/SOAP en 24 horas | Cualquier integración síncrona de alta frecuencia | | Lotes de Bulk API | Número de lotes abiertos/diarios | Procesos de lotes nocturnos que ingieren datos históricos | | Solicitudes concurrentes de larga duración | Llamadas concurrentes que duran más de 20 segundos | Informes pesados o Apex síncrono complejo | | Entrega de Platform Events | Volumen de eventos por día por suscriptor | Arquitecturas basadas en eventos entre Salesforce y sistemas externos | | Filas SOQL por transacción | Filas recuperadas en una única transacción (50.000) | Lógica Apex que ejecuta consultas dentro de un bucle | Esta tabla no es una documentación genérica, es un orden de prioridades. Una organización que planea una nueva integración debe revisar primero las dos primeras filas, ya que son las que realmente se bloquean en producción. El resto de los límites afectan principalmente al rendimiento, no a la disponibilidad. ## Presupuesto de llamadas: cómo construirlo correctamente La herramienta principal para evitar bloqueos no es la monitorización _a posteriori_, sino un presupuesto predefinido para cada consumidor de API. El principio: cada sistema externo, cada Usuario de Integración y cada proceso programado recibe una asignación definida de la cuota total, y no "cuanto sea necesario". La construcción del presupuesto incluye tres pasos: 1. **Mapeo de consumidores:** Una lista de cada proceso que llama a la API: integraciones externas, Scheduled Apex, Data Loader manual, herramientas de BI. Cada uno tiene un Usuario de Integración separado para poder aislar el consumo en Event Monitoring. 2. **Cálculo de la carga según el volumen de negocio, no según la suposición:** ¿Cuántos registros se mueven por día, cuántas llamadas se requieren por registro (incluida la recuperación de listas relacionadas), y qué sucede en el pico (fin de trimestre, Black Friday, cierre de mes)? 3. **Asignación de reserva:** No se distribuye el 100% de la cuota entre los procesos existentes. Se deja un 15%-20% como reserva para procesos de emergencia, informes _ad hoc_ y mantenimiento; de lo contrario, cualquier pequeña adición empuja a la organización a exceder los límites. Aquellos que deseen profundizar en el diseño de la capa que gestiona este presupuesto a nivel de plataforma deberían consultar la [Guía de Arquitectura de CRM](/es/insights/crm-architecture-guide), donde se presenta la división entre la capa de integración y la capa de negocio. ## REST vs. Bulk: cuándo la transición vale la pena El error más común es usar la API REST regular para un alto volumen de tráfico de datos, porque es lo primero que se construye y funciona en una prueba de concepto (PoC). El problema aparece cuando el volumen crece: REST cuenta cada solicitud (hasta 200 registros en Composite) como una llamada separada contra la cuota, mientras que Bulk API 2.0 ejecuta lotes de hasta 10.000 registros y se cuenta con un costo significativamente menor por registro. Una regla práctica general: si un solo proceso actualiza más de aproximadamente 2.000 registros en una ejecución, la transición a Bulk API casi siempre vale la pena, incluso si esto implica cambiar el código del consumidor para trabajar de forma asíncrona con sondeo sobre el estado del trabajo en lugar de una respuesta inmediata. El costo es una latencia más alta (minutos en lugar de segundos), por lo que Bulk no es adecuado para procesos que requieren una decisión en tiempo real, como la verificación de inventario antes de aprobar un pedido. ## Backoff y Retry: prevención del auto-ahogo Cuando una llamada a la API falla debido a un bloqueo de límite, la respuesta instintiva de la mayoría de los equipos es volver a intentarlo de inmediato. Este es precisamente el comportamiento que convierte un bloqueo temporal en un fallo persistente: si diez procesos lo intentan de nuevo al mismo tiempo, empujan al sistema más profundamente en el bloqueo en lugar de permitir que se recupere. Un mecanismo de _backoff_ correcto requiere tres componentes juntos: - **Backoff exponencial:** El tiempo de espera entre intentos crece exponencialmente (por ejemplo, 2, 4, 8, 16 segundos), no permanece constante. - **Jitter:** Una pequeña adición aleatoria al tiempo de espera, para que los procesos paralelos no lo intenten de nuevo en el mismo segundo exacto y creen una nueva ola de carga. - **Circuit Breaker:** Después de una serie de fallas consecutivas (por ejemplo, cinco), el proceso deja de intentarlo por completo durante un período de tiempo fijo y reporta al monitoreo, en lugar de seguir "golpeando la puerta". Sin un _Circuit Breaker_, un proceso que se ejecuta cada cinco minutos y falla consistentemente seguirá intentándolo cien veces al día y consumiendo la cuota solo en fallas; esto es exactamente lo contrario de lo que el mecanismo debería prevenir. Se puede encontrar más información sobre el manejo de errores a nivel de integración en [Manejo de Errores de Integración en Salesforce](/es/insights/salesforce-integration-error-handling). ## Escenario: Comercio minorista con tres puntos de integración Supongamos una cadena minorista mediana, con aproximadamente 40 sucursales, que opera Salesforce Service Cloud frente a un sistema POS y un sistema ERP para inventario. Tres integraciones activas: sincronización de inventario cada 15 minutos desde el ERP (aproximadamente 8.000 SKUs), un _webhook_ desde el POS por cada transacción fallida (aproximadamente 300 por día), y un panel externo para Power BI que extrae datos de servicio cada hora. En el mes en que la cadena agregó un nuevo programa de lealtad, entró en juego una cuarta integración: verificación de puntos de crédito en tiempo real contra Salesforce desde cada caja, aproximadamente 6.000 llamadas diarias adicionales. En dos semanas, la sincronización de inventario comenzó a fallar entre las 14:00 y las 15:00, la hora pico de las cajas. El equipo verificó primero el ERP y pensó que el problema estaba allí, pero el registro de Salesforce mostró `REQUEST_LIMIT_EXCEEDED` exactamente en ese período. La solución no fue comprar cuota adicional, sino cambiar el orden de las prioridades: la verificación de puntos de crédito pasó a usar Platform Cache para resultados que no cambian con frecuencia, lo que redujo las llamadas en aproximadamente un 70%, y la sincronización de inventario pasó de REST a Bulk API con una ejecución cada 30 minutos en lugar de 15. El resultado: la misma cobertura de negocio, un consumo de cuota un 45% menor y una reserva real para el próximo crecimiento. ## Riesgos y acciones preventivas específicas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Nueva integración no probada contra el presupuesto existente | El bloqueo aparece solo después del lanzamiento a producción | Requisito de Revisión de Capacidad para cada nueva integración antes de la puesta en marcha | | Reintento sin Backoff | El bloqueo temporal se convierte en un fallo de horas | Backoff Exponencial con Jitter y Circuit Breaker en cada consumidor de API | | Uso de REST para grandes volúmenes | Un solo proceso consume decenas de porcentajes de la cuota diaria | Transición a Bulk API por encima de un umbral de volumen predefinido | | Ausencia de Usuarios de Integración separados | Imposible saber qué integración consume la cuota | Usuario de Integración dedicado para cada sistema externo, monitoreado por separado | | Falta de reserva en el presupuesto | Cualquier pequeña adición empuja a exceder el límite | Asignación del 15%-20% de la cuota como reserva permanente no asignada para procesos diarios | ## Lista de verificación antes de añadir una nueva integración - ☐ Se conoce el porcentaje actual de consumo de la cuota diaria, por Usuario de Integración. - ☐ Se ha verificado el volumen pico (no el volumen promedio) de la nueva integración. - ☐ Se ha decidido entre REST y Bulk API según el umbral de volumen, no según la conveniencia de desarrollo. - ☐ Existe un mecanismo de Backoff con Jitter y Circuit Breaker en el código del consumidor. - ☐ Se ha configurado una alerta cuando el consumo de la cuota diaria supera el 70%. - ☐ Se ha evaluado el posible uso de Platform Cache para reducir llamadas repetidas. - ☐ Existe una reserva del 15%-20% de la cuota que no ha sido asignada previamente. - ☐ Se ha definido un Propietario operativo que recibe la alerta y no solo un registro técnico. ## Cómo monitorear esto de forma continua La medición fiable requiere una combinación de tres fuentes: Event Monitoring (o Shield Event Monitoring) para el consumo real de API por usuario, Apex Limits dentro del propio código (`Limits.getLimitApiRequests()`) para pruebas locales en tiempo de ejecución, y el Panel incorporado en Información de la Empresa que muestra el consumo frente a la cuota a nivel de organización. Ninguna de las tres es suficiente por sí sola: la primera muestra tendencias, la segunda previene fallos dentro de un proceso individual y la tercera sirve como instantánea diaria para el equipo de operaciones. Una métrica que vale la pena seguir a lo largo del tiempo no es solo "cuánto se consume", sino "cuál es la tasa de crecimiento mensual del consumo", ya que esto permite predecir cuándo la organización alcanzará el límite, en lugar de reaccionar después de que el bloqueo ya haya ocurrido. Cuando hay varios sistemas dependientes entre sí, también vale la pena examinar el patrón de integración general con la [integración de Salesforce con sistemas ERP](/es/insights/salesforce-erp-integration), y la cuestión de la implementación, Flow frente a Apex, que también afecta la eficiencia de las llamadas, en [Salesforce Flow o Apex](/es/insights/salesforce-flow-vs-apex). ## Resumen Los límites de la API de Salesforce no son un problema que se resuelve en el momento en que se descubre; son una variable que debe formar parte de cada decisión de integración desde el primer día. Un presupuesto de llamadas documentado por Usuario de Integración, una elección consciente entre REST y Bulk según el volumen, y un mecanismo de _backoff_ que evita el auto-ahogo, estos tres juntos son lo que distingue a una organización que descubre el problema cuando ya está bloqueada, de una organización que lo ve acercarse con un mes de anticipación y actúa a tiempo. ### Preguntas y respuestas **¿Cuántas llamadas a la API recibe una organización en Salesforce y cómo se actualiza?** La cuota diaria se deriva del tipo de edición y la cantidad de licencias, restableciéndose cada 24 horas a una hora fija, no a medianoche del servidor. El complemento 'Llamadas API Adicionales' (Additional API Calls) añade paquetes fijos si se necesita más, pero resuelve a corto plazo; si el consumo crece con cada nueva integración, el problema es arquitectónico, no cuantitativo. **¿Cuál es la diferencia práctica entre la API REST regular y la API masiva (Bulk API) en el contexto de los límites?** La API REST cuenta cada llamada individualmente contra la cuota diaria, por lo que una actualización secuencial de 50,000 registros podría consumir, por sí sola, decenas de porcentajes del presupuesto. La Bulk API 2.0 opera en lotes (batches) y se contabiliza de manera significativamente más económica por registro, pero es asincrónica: el código de consumo debe adaptarse al sondeo del estado del trabajo (Job Status) y no esperar una respuesta inmediata. **¿Qué se hace al recibir un error REQUEST_LIMIT_EXCEEDED en medio de un proceso crítico de negocio?** Se detiene el hilo solicitante y no se intenta de nuevo inmediatamente con la misma intensidad. Se implementa un retroceso exponencial (Exponential Backoff) con Jitter, se envía la solicitud a una cola de espera y se alerta al equipo de operaciones si el bloqueo persiste más allá de un umbral predefinido. Un proceso que continúa intentando a una velocidad constante solo prolonga el bloqueo y pone en riesgo otros procesos que comparten la misma cuota. **¿Los Platform Events o Change Data Capture se cuentan en la cuota de la API?** Los eventos distribuidos a través de Platform Events y su recepción mediante CometD no se cuentan como llamadas API regulares, lo que los convierte en una forma eficiente de transmitir actualizaciones en tiempo real sin consumir del presupuesto diario. Sin embargo, cualquier llamada REST que el consumidor realice en respuesta a un evento –por ejemplo, para recuperar los detalles completos del registro– sí se cuenta, por lo que es aconsejable considerar la inclusión de los campos necesarios en el propio cuerpo del evento. **¿Cómo saber de antemano si una nueva integración superará los límites de la organización?** Simplemente realice una previsión: volumen diario de registros multiplicado por las llamadas por registro (incluyendo los registros relacionados y las búsquedas que se recuperan por separado), y compare con la suma restante después de las integraciones existentes. Si el resultado supera el 70%-80% de la cuota total, se debe planificar el uso de Bulk API, el almacenamiento en caché (Caching) o la reducción de campos antes de pasar a producción, no después del primer bloqueo. --- ## Arquitectura Orientada a Eventos en Salesforce: Platform Events y Change Data Capture URL: https://hpi.pro/es/insights/salesforce-event-driven-architecture Platform Events y CDC resuelven un único problema: la desvinculación entre sistemas que no necesitan esperar el uno por el otro. El problema surge cuando se elige entre ellos por conveniencia técnica, en lugar de considerar quién es el propietario del dato, el nivel de fiabilidad requerido y qué sucede cuando un mensaje llega dos veces o no llega en absoluto. ## La elección que no se trata realmente de tecnología Cuando una organización comienza a hablar de una Arquitectura _Event Driven_ (EDA) en Salesforce, la conversación se inclina demasiado rápido hacia "¿_Platform Events_ o CDC?" — como si fuera una cuestión de herramientas. En realidad, se trata de una pregunta completamente diferente: ¿qué lado de la integración es la fuente de la verdad, qué puede permitirse perder, y quién asume el costo cuando un mensaje llega tarde, duplicado o no llega en absoluto? La respuesta corta: _Change Data Capture_ (CDC) es adecuado cuando un sistema externo necesita saber que Salesforce ha actualizado un registro y no hay necesidad de envolverlo con lógica de negocio. Los _Platform Events_ personalizados son adecuados cuando se desea publicar un evento de negocio significativo — "el cliente actualizó su plan", no "el campo _Status_c cambió". La elección incorrecta no se hace evidente el día del lanzamiento; se hace evidente cuando alguien necesita reconstruir lo sucedido después de un fallo parcial y descubre que no hay una forma fiable de saberlo. Quien busque una visión más amplia de las integraciones de Salesforce más allá de los eventos la encontrará en la [guía de arquitectura CRM](/es/insights/crm-architecture-guide). ## Tres preguntas que definen la arquitectura antes de escribir una línea de código Antes de elegir un mecanismo, se necesita una respuesta a tres preguntas. Omitir una de ellas es la razón más común por la que los proyectos de integración se estancan en la fase de pruebas. **¿Quién es el dueño del dato?** Si Salesforce es la fuente de la verdad para el registro del cliente, los eventos de salida de Salesforce (_Platform Event_ o CDC) son la dirección natural. Si el sistema ERP es el propietario, la dirección opuesta es correcta, y Salesforce debe consumir eventos en lugar de publicarlos sobre la misma entidad. **¿Qué se puede perder?** Una alerta a un _dashboard_ de gestión puede perder un solo mensaje sin causar daño. Una actualización del saldo de crédito antes de aprobar una transacción no puede. Esta distinción determina si es suficiente un "disparar y olvidar" (_Fire-and-Forget_) o si se requiere un mecanismo de confirmación y monitoreo de discrepancias (_Reconciliation_). **¿Qué sucede cuando el mensaje llega dos veces?** Los _Platform Events_ garantizan _At-Least-Once_, no _Exactly-Once_. Si la respuesta es "no sabemos" — la solución aún no está lista para producción, independientemente de la limpieza del código. ## _Platform Events_ vs. CDC — Tabla de decisión | Criterio | _Platform Event_ personalizado | _Change Data Capture_ (CDC) | | --- | --- | --- | | Qué se publica | Evento de negocio definido (_Payload_ personalizado) | Cambio de registro en bruto (Antes/Después) | | Quién construye la lógica | Desarrollador de Salesforce, en el _Trigger_ o _Flow_ | La plataforma, automáticamente para cada DML configurado | | Acoplamiento al esquema | Bajo — el _Payload_ es controlado por el publicador | Alto — cualquier cambio en la estructura del objeto afecta al consumidor | | Adecuado cuando... | Se desea publicar una intención de negocio ("orden aprobada") | Se desea una sincronización de datos en bruto entre sistemas | | Costo de mantenimiento | Más alto al principio (construcción del _Payload_ y la lógica) | Bajo al principio, alto cuando cambia la estructura del objeto | | Retención | Según la definición de la licencia (horas a días) | Según la definición de la licencia, generalmente igual que los _Platform Events_ | | Volumen recomendado | Eventos de dominio con frecuencia media | Cambios a nivel de registro, incluyendo alta frecuencia | La regla práctica: si el consumidor del evento necesita entender "por qué" sucedió y no solo "qué" sucedió — se necesita un _Platform Event_ personalizado. Si el consumidor solo necesita una copia actualizada del dato — CDC ahorra toda una capa de desarrollo. ## _Ordering_, _Replay_ e _Idempotency_: los tres conceptos que convierten la teoría en producción estable Estos no son temas para una etapa tardía del proyecto — definen la estructura del consumidor desde el primer día. **_Ordering_.** Los _Platform Events_ se envían en el orden de publicación dentro del mismo tema, pero la carga y los fallos parciales pueden alterar el orden de recepción por parte del consumidor. Solución práctica: adjuntar a cada evento una marca de versión o _Sequence Number_ del registro original, y permitir que el consumidor rechace un evento cuya versión sea inferior a la última versión ya procesada. **_Replay_.** Cada evento recibe un _Replay ID_. Un consumidor que falla debe guardar el último _Replay ID_ procesado con éxito — no en la memoria, sino en un lugar persistente (_Custom Object_, tabla externa) — y continuar desde allí con la recuperación. Confiar en que "el sistema comenzará desde cero" solo funciona dentro de la ventana de retención, y más allá de ella los eventos se pierden. **_Idempotency_.** Cada consumidor debe identificar un evento que ya ha sido procesado, generalmente por un identificador de transacción único enviado dentro del _Payload_. Sin esto, un reintento automático por parte del remitente — o un _Replay_ manual después de un fallo — se convierte en una actualización doble, la creación de un registro doble o, en el peor de los casos, un cargo doble. Esta brecha casi nunca se detecta en la demostración. Se detecta bajo carga, en un fallo de red real o en un cambio en el entorno de producción, y entonces el costo de solucionarlo ya incluye también la corrección de datos. Las organizaciones que encuentran un problema paralelo en la capa de automatización encuentran un análisis complementario en [deuda técnica de Salesforce en _Flow_ y _Apex_](/es/insights/salesforce-flow-apex-technical-debt). ## Escenario de ejemplo: cadena minorista con 40 sucursales y sistema de inventario separado Asumamos una cadena minorista hipotética, "Retail del Norte", que opera Salesforce Sales Cloud con equipos de ventas en 40 sucursales, y un sistema ERP separado que gestiona el inventario en tiempo real. Hasta ahora, cada pedido cerrado en Salesforce se transfería al ERP mediante un _Job_ programado que se ejecutaba cada 15 minutos — una solución que provocaba que los representantes a veces vieran inventario desactualizado y aprobaran pedidos de productos agotados. El equipo de arquitectura decidió publicar un _Platform Event_ personalizado llamado `Order_Confirmed__e` cada vez que se aprobara un pedido, con un _Payload_ que incluyera un identificador de transacción único, una lista de artículos y cantidades. El ERP escucha el evento y actualiza el inventario en segundos, verificando el identificador de transacción contra una tabla de transacciones ya procesadas — para evitar una doble deducción si el evento llegara dos veces. Además, se definió un proceso de _Reconciliation_ nocturno que compara el total de pedidos aprobados en Salesforce con el total de actualizaciones registradas en el ERP, y alerta sobre una discrepancia por encima de un umbral definido. La razón: incluso con una _Idempotency_ correcta, se desea una detección temprana de un fallo de red prolongado y no solo confiar en que el evento "seguramente llegó". El resultado: el tiempo de actualización se redujo de 15 minutos a menos de un minuto, y el número de incidentes de inventario incorrecto disminuyó de manera medible en un mes desde la implementación. Este escenario ilustra un principio clave: el valor no se crea por la "transición a eventos" en sí misma, sino por la combinación de un evento de negocio claro, una verificación de duplicados por parte del consumidor y un proceso de monitoreo que identifica una discrepancia antes de que se convierta en una queja de cliente. ## Riesgos comunes y acciones de prevención | Riesgo | Cómo se manifiesta en la práctica | Acción de prevención | | --- | --- | --- | | Publicación de un evento por cada cambio de campo | La cuota diaria de eventos se excede en pocos días | Publicar eventos de dominio con significado de negocio, no un evento técnico por cada DML | | No hay verificación de duplicados por parte del consumidor | Un reintento (_Retry_) o _Replay_ crea registros o actualizaciones duplicados | Adjuntar un identificador de transacción único y verificarlo antes de cada operación | | Confianza en el orden de llegada | Una actualización antigua sobrescribe una actualización más reciente | Adjuntar una marca de versión y rechazar eventos más antiguos que la última versión procesada | | No se guarda el _Replay ID_ | Después de una caída del consumidor, los eventos entre la caída y la ventana de retención se pierden | Guardar el _Replay ID_ en un lugar persistente y ejecutar un _Replay_ automático al reiniciar | | CDC en un objeto cuya estructura cambia con frecuencia | Cada cambio de campo rompe el consumidor externo sin previo aviso | Definir un contrato de datos explícito y comunicar los cambios de esquema con antelación | | No hay monitoreo de negocio, solo monitoreo técnico | La integración está "en verde" pero el inventario o los pedidos reales no coinciden | Añadir una _Reconciliation_ diaria que compare el resultado de negocio entre los sistemas | ## _Checklist_ antes de empezar a desarrollar la capa de eventos - ☐ Cada evento tiene un propietario claro: quién publica y quién es el propietario comercial del dato. - ☐ Se ha definido un _Payload_ consistente y documentado, no una estructura que cambia con cada _Sprint_. - ☐ Se ha elegido entre _Platform Event_ personalizado y CDC según la intención comercial frente al cambio de datos en bruto. - ☐ Cada consumidor tiene un identificador de transacción único y verificación de duplicados (_Idempotency_). - ☐ Se define el tratamiento del orden mediante una marca de versión, no por orden de llegada. - ☐ El _Replay ID_ se guarda en un lugar persistente y se define y prueba un proceso de recuperación. - ☐ Existe un monitoreo comercial (_Reconciliation_) además del monitoreo técnico de la cola de mensajes. - ☐ Se ha probado el escenario de carga y el escenario de fallo parcial, no solo el _Happy Path_. - ☐ La cuota diaria de eventos (_Publish_ + _Delivery_) se ha verificado frente al volumen esperado en producción. - ☐ Se ha definido un _Owner_ operativo para responder cuando se detecta una discrepancia en la _Reconciliation_. ## ¿Cómo se mide el funcionamiento de la arquitectura? | Área | Qué se mide | Frecuencia de verificación | | --- | --- | --- | | Fiabilidad de la entrega | Porcentaje de eventos completados sin reintento (_Retry_), y porcentaje que tuvo éxito después del reintento | Continuo | | Discrepancias en _Reconciliation_ | Diferencia entre los registros confirmados en el origen y los registros recibidos en el destino | Diario | | Latencia de extremo a extremo | Tiempo entre el evento de negocio y la actualización efectiva en el consumidor | Continuo | | Utilización de la cuota de eventos | Porcentaje de la cuota diaria utilizada | Semanal | | Duplicados evitados | Número de eventos identificados como duplicados y bloqueados antes de su ejecución | Semanal | Se recomienda elegir no más de tres o cuatro métricas para la primera versión, y medirlas contra una línea de base (_Baseline_) recopilada antes de la transición a la arquitectura de eventos — no contra una sensación general de que "ahora es más rápido". Para una planificación más amplia de la estructura organizacional de múltiples integraciones, también es aconsejable revisar los [patrones de integración de Salesforce](/es/insights/salesforce-integration-patterns) y las implicaciones para la [arquitectura _Single Org_ vs. _Multi Org_ de Salesforce](/es/insights/salesforce-single-org-vs-multi-org), ya que una decisión sobre eventos a veces cruza los límites organizacionales. ## Resumen La elección entre _Platform Events_ y CDC no es una cuestión técnica que se analiza en un corto período al inicio de un proyecto — determina quién es la fuente de la verdad, qué se puede perder y cómo se comporta el sistema cuando algo falla a mitad de camino. Una organización que planifica de antemano el _Ordering_, _Replay_ e _Idempotency_, y añade una capa de _Reconciliation_ de negocio y no solo un monitoreo técnico, obtiene una integración que soporta la carga y los fallos parciales. Una organización que omite estos pasos obtiene un sistema que parece correcto en las pruebas y que falla en silencio en producción, generalmente sin que nadie se dé cuenta hasta que el daño ya ha ocurrido. Las organizaciones que desean acompañamiento en la construcción de una capa de eventos fiable en Salesforce pueden contactar a través del [servicio de arquitectura CRM](/es/crm-architecture). ### Preguntas y respuestas **¿Cuándo es preferible Change Data Capture (CDC) sobre un Platform Event personalizado?** Es preferible cuando Salesforce es la fuente de la verdad y el sistema de destino necesita saber que un registro ha cambiado, sin que se requiera la creación manual de lógica para publicarlo. CDC elimina esta capa, pero expone la estructura interna del objeto a los 'listeners' externos; cualquier cambio en un campo afecta al consumidor. Un Platform Event personalizado es mejor cuando se desea publicar una intención comercial ('pedido aprobado') en lugar de un cambio técnico en una fila. **¿Los Platform Events garantizan que el mensaje llegará una sola vez?** No. La plataforma garantiza 'At-Least-Once' (al menos una vez), lo que significa que un mensaje puede llegar dos veces en un escenario de fallo de red o Replay. Es crucial diseñar el consumidor como Idempotente, es decir, verificar un identificador de transacción único antes de realizar una acción. De lo contrario, una actualización duplicada, la creación de un registro doble o una facturación doble son resultados esperados, no un fallo excepcional. **¿Qué sucede cuando el consumidor de eventos no está disponible durante varias horas?** Los Platform Events se almacenan en el Event Bus según una ventana de Retención definida por la licencia (generalmente de 24 horas a 3 días), y es posible realizar un Replay desde el último Replay ID recibido con éxito. Es imperativo almacenar el Replay ID en el lado del consumidor y no confiar en haber 'recibido todo'. Si la ventana de Retención expira sin un Replay, los eventos se pierden permanentemente. **¿Cómo mantener el orden de las actualizaciones cuando varios eventos afectan al mismo registro?** Los Platform Events no garantizan el orden entre diferentes canales, y a veces tampoco dentro del mismo canal bajo carga. La solución común es añadir una marca de versión o un número de serie a cada evento y permitir que el consumidor rechace una actualización que llegue con una versión anterior a la que ya ha procesado, en lugar de depender del orden de llegada. **¿Cuántos Platform Events se pueden publicar sin afectar el rendimiento?** El límite se mide según la cantidad de eventos por día y por entrega diaria, en función de la edición y la licencia, y también cuenta los eventos que fallaron en el envío. Un proyecto que publica un evento por cada cambio de campo en una tabla con alta carga alcanzará rápidamente el límite; por lo tanto, se publican eventos de Dominio con significado comercial, y no un evento técnico por cada operación DML. --- ## SSO, MFA e Identidad en Salesforce: Principios de Diseño Empresarial URL: https://hpi.pro/es/insights/salesforce-sso-identity-architecture SAML u OIDC, iniciado por IdP o por SP, JIT o SCIM para la gestión del ciclo de vida: cada elección en la arquitectura de identidad para Salesforce determina quién accede al sistema, con qué permisos y qué sucede el día que un usuario se va. Este artículo presenta un marco de decisión concreto, incluyendo un escenario de offboarding fallido y cómo corregirlo. ## La respuesta breve La arquitectura de identidad en Salesforce no es un proyecto técnico puntual, sino una capa de control que opera a diario: quién accede, con qué identidad, qué permisos tiene y qué sucede cuando ya no debería tener acceso. La elección entre SAML y OIDC, entre JIT y SCIM, y entre una política de MFA a nivel de IdP o una aplicación interna en Salesforce, parecen detalles de configuración. Sin embargo, estas decisiones determinan el tiempo necesario para bloquear el acceso de un empleado desvinculado y qué parte de estos incidentes solo se descubrirá en una auditoría. El enfoque correcto no comienza con el protocolo, sino con dos preguntas: ¿Quién es la fuente de verdad de la identidad del usuario? y ¿Cuál es el tiempo máximo permitido entre un evento de desvinculación (Offboarding) y el bloqueo de acceso real? A partir de ahí se derivan todas las demás decisiones: el tipo de federación, el método de aprovisionamiento, la política de sesión y el proceso de 'Break Glass'. Las organizaciones que también se plantean la cuestión de los permisos en sí, y no solo la autenticación, encontrarán más información en el [modelo de permisos de Salesforce](/es/insights/salesforce-permission-model). ## Mapa de decisiones: Cuatro capas de identidad en Salesforce | Capa | Cuestión a resolver | Opciones principales | Consecuencias de una mala decisión | | --- | --- | --- | --- | | Federación y autenticación | Quién es el Identity Provider y cómo confía Salesforce en él | SAML 2.0, OIDC, Delegated Authentication | Doble inicio de sesión, incompatibilidad de atributos, brecha de confianza | | Aprovisionamiento y ciclo de vida | Cómo se crea, actualiza y desactiva un usuario | JIT Provisioning, SCIM, creación manual | Cuentas huérfanas, acceso que permanece tras la desvinculación | | Sesión y MFA | Dónde se aplica el nivel de autenticación y la duración de la sesión | MFA en IdP, MFA interno en Salesforce, Session Policies | Elusión de MFA por una ruta alternativa, sesión que nunca expira | | Break Glass y auditoría | Qué sucede si el SSO falla y quién verifica las anomalías | Usuario de emergencia controlado, Login History, Event Monitoring | Dependencia total del IdP, incapacidad de investigar retrospectivamente | ## SAML frente a OIDC: No es una cuestión de "qué es más nuevo" La elección entre los dos protocolos no debe basarse en una tendencia, sino en la infraestructura existente. SAML opera con XML y aserciones firmadas, y es común en organizaciones con Active Directory Federation Services o un IdP establecido que ya sirve a docenas de otros sistemas. OIDC se construye sobre OAuth 2.0, es más ligero de mantener y especialmente conveniente cuando el mismo IdP necesita servir tanto a consumidores de API modernos como al inicio de sesión de usuarios. El error común es elegir lo que parece "avanzado" sin verificar qué atributos envía el IdP existente y cómo se mapean a Salesforce (Username, Federation ID, Profile, Permission Set Group). Un mapeo incorrecto de atributos en la fase de configuración a menudo lleva a la corrección manual de docenas de usuarios en producción, y no solo a un cambio de configuración. Un punto que a menudo se olvida: incluso al elegir OIDC o SAML, es conveniente planificar los inicios de sesión Iniciados por el IdP (IdP-Initiated) y por el Proveedor de Servicios (SP-Initiated) por separado. Algunos de los incidentes de seguridad comunes se deben a que el inicio de sesión SP-Initiated permanece abierto a pesar de que se planeó que todo el proceso de inicio de sesión fuera únicamente a través del portal del IdP. ## Aprovisionamiento JIT frente a SCIM: Cuándo "justo a tiempo" no es suficiente El aprovisionamiento JIT (Just-In-Time) crea o actualiza al usuario en Salesforce en el momento del primer inicio de sesión, según los datos proporcionados por el IdP en la aserción SAML o el token OIDC. Esto es conveniente, económico de implementar y suficiente para la mayoría de las organizaciones donde los usuarios inician sesión regularmente. El problema: JIT no resuelve el desaprovisionamiento. Si un empleado es eliminado del IdP pero nunca vuelve a iniciar sesión, su usuario permanece activo en Salesforce indefinidamente porque no hay un evento que active una actualización. Es aquí donde entra SCIM (System for Cross-domain Identity Management), que permite la sincronización proactiva desde el IdP a Salesforce, incluida la desactivación inmediata cuando un usuario es eliminado en la fuente. La regla práctica: si la organización tiene un requisito de desvinculación en horas en lugar de días (contratistas, empleados temporales, acceso a datos sensibles), SCIM no es un "deseable", sino un requisito de cumplimiento. Si el ciclo de rotación de empleados es lento y la gobernanza ya incluye una revisión trimestral de accesos, JIT por sí solo puede ser suficiente, siempre y cuando esté acompañado de un proceso manual documentado para un bloqueo inmediato. La planificación del aprovisionamiento siempre debe considerarse también frente a la complejidad de la automatización que lo rodea, por ejemplo, cuando hay Flows que ejecutan lógica de asignación de permisos durante la creación del usuario. En este contexto, es relevante la comparación en [Flow vs. Apex](/es/insights/salesforce-flow-vs-apex) sobre dónde el código personalizado es valioso. ## MFA y política de sesión: Dos capas, no una Un error común es conformarse con el MFA aplicado en el Identity Provider y asumir que cubre todas las rutas de acceso a Salesforce. En la práctica, mientras exista un usuario que pueda iniciar sesión directamente a través de login.salesforce.com (por ejemplo, una integración, un usuario de API o un administrador con acceso de respaldo), se requiere una política de MFA separada configurada dentro del propio Salesforce (verificación de identidad, niveles de seguridad de sesión). Además, la política de sesión determina aspectos de fácil omisión: tiempo de espera de la sesión (Session Timeout), "forzar cierre de sesión al expirar la sesión" (Force logout on session timeout), rangos de IP de inicio de sesión (Login IP Ranges) y sesiones de alta seguridad (High Assurance Session) obligatorias para operaciones sensibles (como cambiar permisos o exportar grandes volúmenes de datos). Una organización que configura un MFA robusto pero deja el Session Timeout en el valor predeterminado de dos horas, abre una ventana en la que un ordenador robado mantiene un acceso activo mucho más allá de un tiempo razonable. ## Break Glass y auditoría: Cuando el SSO falla, ¿quién accede? La dependencia total de un IdP externo crea un único punto de falla: si el IdP se cae o si hay un error en la configuración de la federación, nadie puede iniciar sesión, incluido quien necesita solucionar el problema. La solución común es un usuario "Break Glass": una cuenta de superadministrador con autenticación independiente (no ligada al SSO), una contraseña gestionada en una bóveda (Vault) y no en la memoria de una persona, y un MFA separado. Es importante destacar: 'Break Glass' no es una "puerta trasera conveniente", es un mecanismo de emergencia controlado. Su uso debe activar una alerta automática y debe ser revisado en un día hábil por una entidad distinta de quien lo utilizó. Muchas organizaciones configuran correctamente el usuario, pero olvidan el control continuo: la contraseña no se rota y sus permisos son demasiado amplios por defecto. ## Escenario empresarial: Fallo de desvinculación en una compañía de seguros mediana Supongamos una compañía de seguros con unos seiscientos empleados, que utiliza Okta como Identity Provider y una configuración SAML con Salesforce establecida hace aproximadamente tres años. El aprovisionamiento se basa completamente en JIT: cuando un nuevo empleado inicia sesión por primera vez, se le crea un usuario con un perfil (Profile) y un grupo de conjuntos de permisos (Permission Set Group) según el grupo de Okta al que pertenece. En uno de los casos, un agente de servicio fue despedido un viernes por la tarde. El equipo de TI lo desactivó en Okta de inmediato. En la práctica, dado que no existía un mecanismo SCIM o un Webhook que sincronizara la desactivación con Salesforce, su usuario permaneció activo allí. Y como su sesión ya estaba activa desde la mañana y no se había configurado "Force logout on session timeout", continuó accediendo al sistema incluso después del despido, hasta que alguien lo notó en una revisión semanal de accesos el lunes. La solución implementada no fue una transición completa a SCIM (que habría requerido un proyecto separado y un presupuesto de integración), sino la combinación inmediata de tres acciones: activación de "Force logout on session timeout" para todos los perfiles sensibles, reducción del Session Timeout de 120 minutos a 30 minutos para los roles de cara al cliente, y la adición de un paso automático en el proceso de desvinculación organizacional que ejecutara una desactivación directa en Salesforce como una acción independiente y no solo como una consecuencia indirecta de la desactivación en Okta. SCIM quedó como objetivo para el próximo trimestre, ya con presupuesto y aprobación, pero la brecha más peligrosa se cerró en una semana. ## Riesgos comunes y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Dependencia total de JIT sin desaprovisionamiento | Usuarios que se fueron permanecen activos indefinidamente | Agregar un paso de desvinculación independiente en Salesforce, no dependiente de la sincronización | | MFA solo en el IdP | Usuarios de integración y administradores eluden MFA mediante inicio de sesión directo | Política de MFA interna en Salesforce para todos los tipos de usuarios | | Tiempo de espera de sesión demasiado largo | Un ordenador robado o una sesión olvidada abierta mantienen el acceso durante horas | Reducir el tiempo de espera y el cierre de sesión forzado para perfiles sensibles | | Break Glass sin control | El uso de una cuenta de emergencia no se detecta a tiempo | Alerta automática y revisión en un día hábil para cada uso | | Mapeo de atributos incorrecto desde el IdP | El usuario obtiene un perfil o rol incorrecto en el primer inicio de sesión | Prueba de mapeo completa en un entorno de Sandbox antes de cambiar en producción | ## Lista de verificación para la implementación o auditoría de la arquitectura de identidad - ☐ Se ha definido un único Identity Provider como fuente de verdad, y se sabe qué sucede si falla. - ☐ Se ha elegido el protocolo (SAML u OIDC) según la infraestructura existente y no según una tendencia. - ☐ El mapeo de atributos entre el IdP y el Perfil/Grupo de Conjuntos de Permisos ha sido verificado en un entorno Sandbox. - ☐ Se ha definido una política clara: solo JIT, o JIT en combinación con SCIM según los requisitos de desvinculación. - ☐ El MFA se aplica también dentro de Salesforce, no solo en el IdP. - ☐ El tiempo de espera de la sesión (Session Timeout) y el cierre de sesión forzado (Force Logout) se configuran según la sensibilidad del perfil. - ☐ Existe un usuario 'Break Glass' controlado, con MFA separado y contraseña en una bóveda segura. - ☐ El proceso de desvinculación incluye un paso independiente para la desactivación en Salesforce. - ☐ El historial de inicio de sesión (Login History) y la monitorización de eventos (Event Monitoring) se revisan según un calendario fijo. - ☐ Existe un plan de revisión periódica (Access Review) que no depende únicamente de la memoria del equipo de TI. ## Cómo medir la efectividad de la arquitectura El indicador principal no es "si el SSO está activo", sino el tiempo de respuesta entre un evento en la fuente de verdad y un cambio correspondiente en Salesforce: cuánto tiempo transcurre entre la eliminación de un usuario en el IdP y su desactivación real. Un indicador complementario es la proporción de inicios de sesión que se realizan a través de una ruta inesperada (inicio de sesión directo en lugar de a través del IdP), que debería tender a cero, salvo en casos documentados de 'Break Glass'. Un tercer indicador es la frecuencia de las revisiones de permisos en comparación con el estado real; no todos los cambios organizacionales llegan a través del IdP, por lo que una revisión trimestral sigue siendo esencial incluso con aprovisionamiento automático completo. Para la implementación o auditoría de una arquitectura de identidad en un entorno Salesforce existente, puede avanzar a través de nuestro [servicio de arquitectura CRM](/es/crm-architecture). Las organizaciones que también exploran la conexión a sistemas ERP y de nóminas como parte de la imagen global de identidad encontrarán información complementaria en [integración de Salesforce con ERP](/es/insights/salesforce-erp-integration) y una visión más amplia de la arquitectura en la [Guía de arquitectura CRM](/es/insights/crm-architecture-guide). ## Resumen La arquitectura de identidad en Salesforce se construye una vez, pero se pone a prueba cada día a través de incidentes aislados: un empleado que se va, una sesión que se olvida abierta, una integración que elude el MFA. Las decisiones clave (SAML frente a OIDC, JIT frente a SCIM, MFA doble, 'Break Glass' controlado) no deben derivarse del valor predeterminado del IdP, sino del tiempo de respuesta necesario para bloquear el acceso y del nivel de sensibilidad de la información expuesta. Una organización que planifica esta capa con antelación, en lugar de descubrir las lagunas en una auditoría o después de un incidente de seguridad, ahorra tanto costos de reparación como riesgos reputacionales y regulatorios. ### Preguntas y respuestas **¿Cuál es la diferencia práctica entre SAML y OIDC para Salesforce?** Ambos son compatibles como proveedores de Single Sign-On, pero OIDC se basa en REST/JSON y se integra más fácilmente con IdP modernos y otros consumidores de API, mientras que SAML es más común en organizaciones con una infraestructura IAM más antigua o requisitos regulatorios ya construidos a su alrededor. La elección debe derivarse del IdP existente de la organización y no solo de una consideración tecnológica; migrar entre ambos después de haber construido mapeos de atributos y conjuntos de permisos a su alrededor no es un trabajo trivial. **¿Cuándo se debería utilizar el aprovisionamiento JIT y cuándo SCIM?** JIT es adecuado cuando es suficiente crear y actualizar un usuario en el momento del primer inicio de sesión, y cuando no hay una necesidad real de desaprovisionamiento inmediato fuera del ciclo de SSO. SCIM es necesario cuando hay una obligación operativa de revocar el acceso en minutos desde que el usuario es eliminado en el IdP, es decir, en organizaciones con un requisito de offboarding inmediato, contratistas temporales o regulaciones que exigen prueba de sincronización entre fuentes. **¿Es suficiente el MFA aplicado por el IdP, o también se necesita MFA a nivel de Salesforce?** Si todos los inicios de sesión pasan por el IdP y no hay una ruta de entrada directa a Salesforce, el MFA en el IdP puede ser suficiente para el inicio de sesión regular. Sin embargo, siempre se requiere una política de MFA interna en Salesforce para cubrir a los usuarios de Break Glass, las integraciones con usuarios de servicio y cualquier ruta que evite el IdP, de lo contrario, se crea una brecha de seguridad precisamente en el punto más sensible. **¿Cómo se construye un usuario 'Break Glass' para que no se convierta en una vulnerabilidad permanente?** Un usuario 'Break Glass' debe tener una contraseña gestionada en una bóveda, MFA separado, permisos limitados a la función de emergencia únicamente y no un 'Administrador de sistema' genérico, además de una alerta automática ante cualquier uso. La regla obligatoria es que cada inicio de sesión con este usuario sea revisado dentro de un día hábil, y que exista un proceso trimestral que asegure el cambio de la contraseña, incluso si no se ha utilizado. **¿Qué sucede cuando un empleado se va y el IdP no está sincronizado con Salesforce en tiempo real?** Sin SCIM o un webhook que active la desactivación inmediata, el usuario permanece activo en Salesforce incluso después de ser eliminado en el IdP, porque una sesión existente no se verifica con el IdP en cada solicitud. La solución práctica es una combinación de un 'Session Timeout' (tiempo de inactividad de sesión) corto, 'Login IP Ranges' (rangos de IP de inicio de sesión) y un proceso de Offboarding que ejecute la desactivación directa en Salesforce como un paso independiente, y no solo supeditado a la lenta sincronización con el IdP. --- ## Sharing & Visibility en Salesforce: Planificación de Acceso a Información Compleja URL: https://hpi.pro/es/insights/salesforce-sharing-visibility-design Un OWD abierto "para no bloquear a nadie" y una jerarquía de roles que crece ad-hoc son el camino más rápido para que el gerente regional vea todos los clientes de su competidor interno en un informe. Este artículo propone un proceso de trabajo inverso: primero se mapea quién necesita ver qué y por qué, y solo entonces se elige entre OWD, Role Hierarchy, Sharing Rules, Teams y Apex Sharing. ## Por qué un modelo de uso compartido correcto a posteriori es más difícil que uno bien construido desde el inicio El problema típico no se revela en el primer mes. Se manifiesta cuando un gerente de ventas regional nota que está viendo una oportunidad de un territorio competidor, o cuando un agente de servicio abre el caso de un cliente VIP que solo debería ser visible para un equipo dedicado. Ambos casos son el resultado directo de un orden de trabajo inverso: se definen objetos y campos, y solo al final se pregunta quién debería ver qué. El modelo de visibilidad en Salesforce se construye con capas que funcionan en conjunto y no de forma aislada: Los Organization-Wide Defaults (OWD) establecen la línea base más restrictiva, la Role Hierarchy añade acceso vertical según la estructura de gestión, los Sharing Rules abren acceso horizontal según un criterio de negocio, los Teams y el Manual Sharing abordan casos específicos, y el Apex Managed Sharing interviene cuando la lógica es demasiado compleja para expresarse de forma estática. Este orden es crucial: cualquier capa elegida prematuramente genera una deuda difícil de deshacer, ya que los permisos ya otorgados se perciben como un derecho existente. ## El mapa de capas y cuándo elegir cada una | Capa | Qué problema resuelve | Cuándo elegirla | Riesgo de una elección incorrecta | | --- | --- | --- | --- | | OWD | Línea base: quién no puede ver nada por defecto | Siempre se configura, generalmente "Private" para objetos sensibles | Un OWD demasiado abierto hace que cualquier otra capa sea redundante | | Role Hierarchy | Acceso vertical de un gerente a la información de sus subordinados | Cuando la estructura de gestión también refleja la necesidad de supervisar datos | Una jerarquía "política" que no se corresponde con la propiedad real de los datos | | Sharing Rules | Apertura de acceso horizontal según un criterio fijo (rol, grupo, valor de campo) | Un equipo interjerárquico que necesita acceso al mismo tipo de registro | Multitud de reglas superpuestas que dificultan saber quién abrió qué | | Public Groups | Agrupación de usuarios para compartir, sin relación con la jerarquía | Cuando un grupo de trabajo no corresponde a un único rol organizacional | Grupos que no se actualizan cuando un empleado cambia de rol | | Account/Case Teams | Acceso variable a un solo registro según la composición de su equipo | Cuando cada cliente o caso tiene un equipo único y cambiante | Mantenimiento manual que se olvida cuando el equipo cambia | | Territory Management | Asignación de acceso basada en reglas dinámicas y multidimensionales | Asignación variable según varios atributos simultáneamente, acceso concurrente para varios representantes | Complejidad de mantenimiento que no se justifica por debajo de un cierto umbral organizacional | | Apex Managed Sharing | Uso compartido derivado de una lógica dinámica que no puede expresarse en una regla estática | Criterio que depende de un cálculo, un evento externo o una combinación de campos | Código sin monitoreo que sigue ejecutándose después de que el requerimiento comercial ha cambiado | ## OWD: La decisión que determina todas las demás OWD no es solo una configuración de seguridad técnica, es una declaración organizacional sobre quién es el propietario inicial de la información. La regla práctica: establezca el OWD según la condición más restrictiva que realmente se necesite, y desde ahí abra el acceso mediante Sharing Rules y no al revés. La razón es que la ampliación puntual del acceso es sencilla y está documentada, mientras que la restricción de un acceso ya existente requiere comunicación organizacional, porque los usuarios perciben la pérdida de acceso como un perjuicio, incluso si es una corrección de un error histórico. Un punto al que no siempre se le presta suficiente atención: el OWD se establece por separado para cada objeto, y los objetos dependientes (Master-Detail) heredan la visibilidad del objeto principal. Al construir un nuevo modelo de datos, se debe verificar la cadena de dependencia completa antes de establecer el OWD; de lo contrario, un objeto "secundario" definido como "Public" por error podría exponer información del objeto principal. ## Role Hierarchy vs. la estructura gerencial real El error más común es replicar el organigrama en la Role Hierarchy tal cual, sin verificar si también refleja el flujo de propiedad de los datos. Un gerente regional necesita ver las oportunidades de su equipo; esa es una función gerencial. Pero un director financiero no necesita ver automáticamente todos los casos de servicio solo porque está más arriba en la jerarquía general; si existe tal necesidad, se resuelve con una Sharing Rule específica y no con una jerarquía excesivamente amplia. Una jerarquía de uso compartido separada de la jerarquía de informes organizacional es una solución legítima y, a veces, preferible, especialmente en organizaciones con una estructura matricial donde el informe gerencial no coincide con la propiedad de los datos del cliente. ## Mapa de decisión: qué mecanismo de uso compartido activa cada situación - **La necesidad cambia según un rol fijo y predecible** → Role Hierarchy. - **La necesidad es compartida por un grupo de trabajo que cruza roles** → Public Group + Sharing Rule. - **La necesidad cambia según la composición del equipo en un registro individual** → Account Team o Case Team. - **La necesidad depende de una combinación de condiciones dinámicas (geografía, producto, tamaño de cliente)** → Territory Management. - **La necesidad se deriva de un cálculo, un evento externo o una condición que no puede expresarse con una regla estática** → Apex Managed Sharing. - **La necesidad es una excepción puntual y temporal para un registro individual** → Manual Sharing, con supervisión y documentación. Esta matriz debe escribirse antes de trabajar con las herramientas, no en paralelo, de lo contrario, elegiremos un mecanismo según lo que sea familiar para el equipo de desarrollo y no según lo que se ajuste a la necesidad. ## Escenario de ejemplo: Un fabricante de equipos industriales con tres canales de venta Supongamos un fabricante de equipos industriales hipotético con aproximadamente 180 usuarios de Salesforce, que opera en tres canales: venta directa por zona geográfica, venta a través de distribuidores y venta a cuentas estratégicas globales gestionadas simultáneamente por varios representantes en diferentes países. Un intento inicial de utilizar solo la Role Hierarchy fracasó: una cuenta estratégica global no pertenecía a una única jerarquía regional, y un representante en Alemania no veía las actualizaciones de su colega en Brasil sobre la misma cuenta. La solución elegida combinó tres capas: el OWD en Account y Opportunity se estableció como "Private"; la Role Hierarchy se utilizó para el acceso gerencial regular dentro de cada región; y para las cuentas estratégicas se configuró un Account Team dinámico que se actualiza automáticamente mediante Flow cuando cambia el campo "Strategic Account Owner Region". Los distribuidores obtuvieron acceso separado a través de una Sharing Rule basada en un Public Group dedicado, para que no estuvieran expuestos a las cuentas de venta directa. El resultado: el tiempo de cálculo de Sharing Recalculation se mantuvo estable, ya que la mayor parte del acceso se derivó de una estructura fija (Role, Public Group) y solo una minoría de las cuentas –las estratégicas– dependía de una actualización dinámica. La principal lección: no es necesario un único mecanismo "correcto" para toda la organización; es preciso adaptar el mecanismo al tipo de dependencia de cada subgrupo de registros. Una ampliación sobre la elección de patrones de integración y un modelo de datos compatible se encuentra en la [guía de arquitectura de CRM](/es/insights/crm-architecture-guide). ## Riesgos específicos en la planificación de la visibilidad y acciones preventivas | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | OWD abierto "temporalmente" en la fase piloto | La apertura permanece incluso después de que el sistema pasa a producción | Establecer de antemano una fecha de cierre y documentarla como un elemento de Go-Live, no como una recomendación | | Multiplicidad de Sharing Rules superpuestas | Imposibilidad de saber con certeza por qué un usuario ve un registro determinado | Un nombre estándar para cada regla que incluya la razón comercial, y una revisión periódica de las reglas no utilizadas | | Apex Sharing sin pruebas de rendimiento bajo carga | El cálculo del uso compartido se retrasa con el crecimiento del volumen de datos | Realizar una prueba de carga en Sharing Recalculation antes de duplicar el volumen de registros en producción | | Jerarquía de uso compartido replicada de una jerarquía organizacional política | Los gerentes ven datos para los que no tienen una necesidad comercial | Separar la jerarquía de Roles para fines de uso compartido de la jerarquía de informes oficial cuando no sean idénticas | | Manual Sharing que se acumula sin un propietario | Los permisos excepcionales permanecen después de que la razón para compartir ya no es relevante | Un proceso de caducidad (Expiration) o una revisión trimestral de los casos de uso compartido manual | | Cambio de rol de usuario sin actualizar los grupos públicos | El acceso antiguo permanece abierto y falta el nuevo acceso | Integrar la actualización de grupos y roles como un único paso en el proceso de cambio de estado de un empleado | ## Lista de verificación antes de finalizar el modelo de uso compartido - ☐ El OWD se configuró según la condición más restrictiva requerida, no según la conveniencia de la fase de desarrollo. - ☐ La cadena de dependencia entre objetos Master-Detail fue verificada frente al OWD del objeto principal. - ☐ La Role Hierarchy fue verificada frente a la propiedad real de los datos, no solo frente al organigrama. - ☐ Cada Sharing Rule tiene un motivo comercial documentado y un propietario responsable de su validez. - ☐ Se verificó si el Territory Management es realmente necesario o si representa una complejidad innecesaria. - ☐ El código de Apex Sharing se probó bajo un volumen de datos realista, no solo en un entorno de pruebas (sandbox) pequeño. - ☐ Existe un proceso para actualizar grupos públicos y permisos al cambiar de rol o al finalizar el contrato de un empleado. - ☐ Se definió una frecuencia de revisión periódica para el Manual Sharing y para las Sharing Rules inactivas. - ☐ Se examinó el impacto del modelo de uso compartido en el rendimiento de los informes y las ejecuciones de lotes (batches) grandes. - ☐ Existe un plan de respuesta en caso de que se detecte una exposición excesiva en producción. ## ¿Cómo saber si el modelo resiste la carga? Una primera medida es el tiempo de recalcular el uso compartido (Sharing Recalculation) después de un cambio estructural; un aumento constante a lo largo del tiempo indica que el modelo se está acercando a una complejidad no planificada. Una segunda medida es el número de solicitudes de soporte del tipo "me falta acceso" frente a "tengo acceso redundante"; una proporción que se inclina bruscamente hacia un lado indica que el OWD o las Sharing Rules no están bien calibradas. Una tercera medida, especialmente importante en organizaciones con múltiples sistemas, es la correspondencia entre los permisos de Salesforce y los permisos en los sistemas sincronizados, especialmente cuando se trata de una arquitectura de integración basada en eventos, como se describe en la [Guía de Arquitectura Dirigida por Eventos en Salesforce](/es/insights/salesforce-event-driven-architecture). En las organizaciones que operan varios "Org", la cuestión del modelo de uso compartido a menudo se mezcla con la pregunta de si realmente se necesita más de un entorno de producción; el debate completo al respecto aparece en [Salesforce Single Org vs. Multi Org](/es/insights/salesforce-single-org-vs-multi-org), y en la elección de un patrón de integración compatible en la [Guía de Patrones de Integración de Salesforce](/es/insights/salesforce-integration-patterns). ## Resumen Un buen modelo de uso compartido y visibilidad no se mide el día del lanzamiento; se mide cuando la organización crece, cuando un usuario cambia de rol y cuando alguien pregunta: "¿Por qué no veo esto?". La forma de lograrlo no es elegir una herramienta y aplicarla a todo, sino mapear cada grupo de registros según su tipo de dependencia (fija, horizontal, dinámica o excepcional) y elegir el mecanismo adecuado para cada uno. Un OWD restringido por defecto, una Role Hierarchy que refleje la propiedad real, Sharing Rules con un motivo documentado y Apex Sharing solo cuando la lógica lo justifique, es la combinación que funciona incluso cuando la organización duplica su volumen y complejidad. ### Preguntas y respuestas **¿Es posible empezar con un OWD abierto y cerrarlo más adelante?** Técnicamente sí, pero en la práctica casi siempre resulta contraproducente: una vez que los usuarios se acostumbran a ver todo, cualquier cierre posterior se percibe como una restricción y genera resistencia. La dirección correcta es la opuesta: empezar con acceso restringido y abrirlo puntualmente mediante Reglas de Compartición cuando surja una necesidad real. **¿Cuándo es preferible usar una Regla de Compartición y cuándo Apex Managed Sharing?** Las Reglas de Compartición son adecuadas cuando el criterio para compartir se deriva de un campo fijo o de la pertenencia a un rol o grupo público. Apex Sharing se requiere cuando el criterio depende de una lógica que cambia en tiempo de ejecución, por ejemplo, un permiso de compartir basado en una combinación de campos, el resultado de un cálculo o un evento en un sistema externo. **¿Vale la pena la complejidad de Territory Management en una organización mediana?** Generalmente no, a menos que exista al menos una de las siguientes condiciones: la asignación de clientes varía según múltiples atributos simultáneamente (geografía, industria, tamaño), se requiere acceso paralelo de varios representantes al mismo registro, o la jerarquía organizacional y la jerarquía de permisos de uso compartido ya no son idénticas. Por debajo de este umbral, la Jerarquía de Roles y las Reglas de Compartición son suficientes y más sencillas de mantener. **¿Cómo se identifica que el modelo de compartición ya no es adecuado para la organización?** Las señales prácticas incluyen: el tiempo de recálculo de la compartición se alarga con cada ejecución, solicitudes recurrentes de soporte como 'no veo un registro que debería ver', un uso creciente del compartición manual puntual como solución alternativa, y quejas de que los informes de gestión presentan cifras diferentes según quién los ejecute. **¿Qué sucede con el modelo de compartición cuando un usuario cambia de rol o departamento?** Cualquier cambio de rol activa un recálculo de la compartición basada en la Jerarquía de Roles, y si también existen Reglas de Compartición basadas en grupos públicos, se debe verificar que el usuario también haya sido actualizado allí, ya que ambos mecanismos no se sincronizan automáticamente. Una organización que realiza cambios estructurales frecuentes necesita un proceso definido, que incluya la verificación de que el acceso antiguo se ha bloqueado y no solo que se ha abierto uno nuevo. --- ## Gestión de Errores y Monitoreo de Integraciones Salesforce de Extremo a Extremo URL: https://hpi.pro/es/insights/salesforce-integration-error-handling La mayoría de los fallos de integración, a menudo no se deben a una caída de la API, sino a un mensaje que falló silenciosamente y nadie supo dónde buscarlo. Este artículo desglosa la cadena de manejo de errores en cuatro capas —Idempotencia, Reintentos, Cola de mensajes fallidos (Dead Letter Queue) y Reconciliación—, mostrando cómo cada una puede fallar en la práctica. ## ¿Por qué una integración "funciona" en la demo y falla silenciosamente en producción? Durante una prueba de aceptación estándar, se envía un mensaje, se verifica su llegada y se confirma. En producción, esa misma integración procesa miles de mensajes al día, y algunos fallarán, ya sea por un tiempo de espera (timeout), un bloqueo de fila, una autorización caducada o un cambio de esquema en el otro sistema. La pregunta que determina la calidad de la solución no es "¿funciona la integración?", sino "¿qué sucede cuando no funciona y quién se da cuenta?". La mayoría de los fallos costosos que he presenciado no fueron causados por un error en el código de integración en sí, sino por la ausencia de tres capacidades: la detección de que un mensaje ha fallado, un mecanismo que reintenta sin crear duplicados y un proceso que garantiza que la información en ambos sistemas sea coherente al final del día. Sin ellas, cualquier integración "funciona" hasta el momento en que se descubre que lleva dos semanas sin funcionar. ## Las cuatro capas que componen una gestión de errores adecuada | Capa | Qué resuelve | Fallo típico sin ella | |---|---|---| | Idempotency | La reejecución del mismo mensaje no crea un registro duplicado | Un pedido duplicado o un movimiento de inventario duplicado después de un reintento | | Retry con Backoff | Un fallo temporal (Timeout, Rate Limit) se corrige automáticamente | Una carga momentánea se convierte en un fallo persistente | | Dead Letter Queue | Un fallo no temporal se marca y no desaparece silenciosamente | Un mensaje se "traga" y las partes creen que fue procesado | | Reconciliación de negocio | Se detectan discrepancias de datos que no lograron fallar de manera explícita | Un informe mensual revela una discrepancia cuyo origen es difícil de rastrear | Cada capa depende de la anterior. Un reintento sin Idempotencia crea duplicados; una Dead Letter sin Reconciliación oculta el hecho de que incluso los mensajes "técnicamente" exitosos no siempre reflejaron el estado comercial correcto. ## Idempotency: La clave para prevenir la duplicidad Cualquier integración que pueda recibir el mismo mensaje más de una vez —y casi todas las integraciones son así— necesita una clave única externa (External ID) que identifique el evento, no solo el registro. En Salesforce, la implementación común es un Upsert mediante un campo External ID con restricción única, combinado con una tabla de registro (Custom Object o Platform Event Log) que registra qué identificadores de evento ya han sido procesados por completo. El error común: conformarse con un Upsert en el propio registro de negocio (por ejemplo, Order External ID) sin documentar los pasos intermedios. Si el proceso también incluye una actualización de inventario en un sistema externo, un Upsert en el pedido no evita una llamada duplicada para esa actualización de inventario; cada suboperación con un efecto secundario externo (Side Effect) debe ser idempotente por sí misma, no solo el registro final. ## Retry: Políticas de Backoff y clasificación de errores No todos los errores merecen un reintento. Es fundamental distinguir de antemano entre tres categorías: - **Errores temporales** (Timeout, 503, Rate Limit): Candidatos para reintento con Exponential Backoff, es decir, el intervalo entre intentos aumenta (por ejemplo, 30 segundos, 2 minutos, 10 minutos) para no agravar la carga. - **Errores estructurales** (campo obligatorio ausente, violación de Validation Rule, valor no válido): No se reintentarán, ya que fallarán de la misma manera. Deben pasar directamente a la Dead Letter. - **Errores de autorización o configuración** (token caducado, cambio de API Version): Requieren una notificación inmediata al equipo técnico, ya que bloquean toda la cola y no solo un mensaje individual. En Salesforce, la implementación del reintento se realiza generalmente en la capa de Middleware o en Apex Queueable/Batch con un contador de intentos almacenado en el propio registro. Un número razonable de intentos para la mayoría de los casos es de 3 a 5 con Backoff, no un reintento infinito; un reintento sin límite convierte un fallo temporal en una carga persistente en ambos sistemas. ## Dead Letter Queue: Donde "viven" los mensajes fallidos Una Dead Letter no es solo un lugar de almacenamiento, es un contrato. Cada mensaje que llega a ella debe contener: el identificador original del evento, el Payload completo, la causa clasificada del fallo, el número de intentos realizados y la hora de entrada en la cola. Sin esta información, la "gestión" de la Dead Letter se convierte en una adivinanza. Dos enfoques comunes para la implementación en Salesforce: 1. **Un Custom Object dedicado** (`Integration_Failed_Message__c`) con campos estructurados y una List View por tipo de error: Adecuado cuando se necesita transparencia para un equipo de negocio dentro del propio Salesforce. 2. **Una cola externa en la capa de Middleware** (por ejemplo, Dead Letter Exchange en MuleSoft/Boomi): Adecuado cuando el equipo técnico monitorea fuera de Salesforce y desea evitar la carga en la Org. La elección depende de quién debe actuar sobre el fallo: si es el propietario de un proceso de negocio, debe verlo dentro de Salesforce; si es un equipo de integración técnico, es preferible en la capa externa. ## Reconciliación de negocio: La verificación que detecta lo que Retry no capturó Incluso con Idempotency y Retry perfectos, existen fallos que "tienen éxito" desde el punto de vista técnico pero crean una brecha de negocio, como un mensaje recibido y procesado, pero con un valor incorrecto obtenido de una fuente de datos desactualizada. La reconciliación es un proceso periódico (diario, por hora, según la frecuencia de los eventos) que compara un recuento o un monto acumulado entre dos sistemas (por ejemplo, el número de pedidos creados en el ERP frente al número de pedidos creados en Salesforce para el mismo día) y destaca las diferencias antes de que se conviertan en un problema de servicio al cliente. Un buen proceso de reconciliación no requiere una revisión campo por campo de cada registro; basta con un checksum o un recuento acumulado que indique cuándo es necesario profundizar. En la mayoría de las organizaciones, una frecuencia diaria es suficiente; en procesos financieros o críticos (pedidos, facturación), se requiere una verificación en cuestión de horas. ## Marco de decisión: Cuándo cada capa es obligatoria y cuándo se puede prescindir de ella | Criterio | Idempotency Obligatoria | Retry Automático Obligatorio | Dead Letter Separada Obligatoria | Reconciliación Diaria Obligatoria | |---|---|---|---|---| | El evento genera un movimiento financiero o de inventario | Sí | Sí | Sí | Sí | | El evento es unidireccional, solo lectura (Read) | No crítico | Sí | No | No | | Volumen superior a 500 mensajes al día | Sí | Sí | Sí | Recomendado | | Socio externo sin SLA de alta disponibilidad | Sí | Sí, con Backoff largo | Sí | Recomendado | | Integración entre dos objetos no financieros de bajo volumen | Recomendado | Recomendado | No necesario | No | La regla que guía la tabla: Cuanto más significativa sea la implicación financiera o irreversible (envío, facturación, actualización de inventario) de un fallo, las cuatro capas pasan de "deseable" a "obligatorio", independientemente del volumen. ## Escenario de ejemplo: Minorista con sincronización de pedidos bidireccional Una empresa minorista con 40 sucursales utiliza Salesforce para la gestión de pedidos B2B y un ERP externo para el inventario y la facturación. La integración se construyó originalmente con una simple llamada REST: cuando se crea un pedido en Salesforce, una llamada síncrona lo crea en el ERP. Sin Retry, sin Dead Letter. Durante un período de alta demanda (Black Friday), el ERP comenzó a devolver Timeouts en aproximadamente el 3% de las llamadas. Sin un mecanismo de Retry, ese 3% simplemente "desapareció"; el pedido permaneció en Salesforce con el estado "enviado" sin que el ERP tuviera conocimiento de ello. En dos días, se acumularon alrededor de 140 pedidos que no llegaron al proceso de empaque y se descubrieron solo cuando los clientes llamaron para preguntar dónde estaba la mercancía. La solución implementada a raíz de esto: una capa Queueable en Apex que reintenta hasta 5 veces con un Backoff de 1/5/15/30/60 minutos; un campo `ERP_Sync_Status__c` con valores Pending/Synced/Failed; un Custom Object `Integration_Failed_Message__c` que centraliza los fallos definitivos con un botón "Reintentar" para el equipo de operaciones; y un informe diario de Reconciliación que compara el recuento de pedidos entre los sistemas y envía una alerta de Slack cuando la diferencia supera cero. El tiempo de detección de un fallo similar se redujo de dos días a menos de una hora. ## Riesgos comunes y acciones de prevención | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | |---|---|---| | Reintento infinito en un error estructural | El mismo mensaje falla repetidamente y genera carga | Clasificar errores de antemano y enviar errores estructurales directamente a la Dead Letter | | Ausencia de clave única para el evento | Un reintento o una llamada duplicada crean un registro duplicado | External ID en el evento, no solo en el registro final | | Dead Letter sin propietario | Los mensajes se acumulan y nadie los gestiona | Definir un propietario y un SLA de gestión por tipo de evento, no por sistema | | Monitoreo únicamente técnico (estado de API) | La integración está "en verde" pero la información de negocio no es coherente | Añadir reconciliación que compare el resultado de negocio, no solo el código de respuesta | | Backoff constante y demasiado corto | Los reintentos repetidos agravan la carga durante un fallo generalizado | Exponential Backoff con un límite definido de intentos | ## Checklist antes de aprobar un diseño de gestión de errores - ☐ Cada evento tiene una clave única (External ID) que previene la duplicidad en la reejecución. - ☐ Los errores se clasifican previamente en temporales/estructurales/de autorización, con un tratamiento diferente para cada tipo. - ☐ Existe una política de Backoff definida con un número máximo de intentos. - ☐ Hay una Dead Letter accesible con Payload completo y motivo del fallo. - ☐ Hay un propietario y un SLA de gestión definidos para cada tipo de fallo. - ☐ Existe un proceso de reconciliación periódico que compara el resultado de negocio entre los sistemas. - ☐ Las alertas llegan a un canal donde alguien las lee activamente (no solo a un registro). - ☐ El escenario de prueba incluye la interrupción del servicio del otro sistema, no solo el "Happy Path". ## Cómo se conecta esto con el resto de la arquitectura El diseño de la gestión de errores no es una característica que se añade al final; es la diferencia entre un sistema que se revela roto después de que un cliente se queja y un sistema que se autoadvierte antes de que el daño se acumule. Las cuatro capas —Idempotency, Retry clasificado, Dead Letter con Propietario y Reconciliación de negocio— no requieren un proyecto separado, pero sí una decisión explícita en la fase de planificación, antes de que la primera integración pase a producción. Una organización que se autoalerta sobre un 3% de mensajes fallidos en una hora es fundamentalmente diferente de una organización que lo descubre a través de un cliente insatisfecho. ### Preguntas y respuestas **¿Cuál es la diferencia entre un reintento automático (Retry) y una Cola de Mensajes Fallidos (Dead Letter Queue)?** Un reintento automático intenta ejecutar nuevamente una llamada que falló por una razón temporal (timeout, bloqueo de fila, límite de velocidad) según una política de retroceso definida. Cuando se agota el número de intentos o el error se clasifica como no transitorio (por ejemplo, un campo obligatorio que falta), el mensaje se mueve a la Cola de Mensajes Fallidos: un lugar donde espera un procesamiento manual o automático separado, sin bloquear el resto de la cola. **¿Cómo se mantiene la idempotencia cuando un sistema externo envía el mismo mensaje dos veces?** Se necesita una clave externa única (External ID) que identifique el evento y no solo el registro, y una verificación de existencia antes de la creación (Upsert) utilizando esa misma clave. Si el evento también implica una transacción financiera o un cambio de inventario, se requiere una tabla de registro separada que registre qué identificadores de evento ya han sido procesados, para que una ejecución duplicada no genere un movimiento doble. **¿Cuánto tiempo se puede dejar un mensaje atascado en el Dead Letter antes de que se convierta en un problema de negocio?** No hay una respuesta universal; depende del proceso. Un pedido no sincronizado en una hora podría causar una entrega doble; una actualización de datos de contacto podría esperar un día. La regla práctica es establecer un SLA de manejo según el tipo de evento y no según el tipo de sistema, y asegurarse de que este SLA se traduzca en una alerta real y no solo en una línea de registro. **¿Quién es responsable de un mensaje atascado: el equipo de Salesforce o el equipo del otro sistema?** La responsabilidad operativa debe recaer en quien posea la capa de integración, no en uno de los dos sistemas por separado. Si no existe tal capa y el mensaje pasa de punto a punto, se debe establecer de antemano una tabla de escalamiento: qué tipo de error se dirige al equipo de Salesforce, cuál al propietario de la API externa, y quién decide en qué plazo cuando la situación no es clara. **¿Un Middleware resuelve automáticamente el problema del manejo de errores?** No. Las herramientas de Middleware (como MuleSoft, Boomi o cualquier otra plataforma iPaaS) proporcionan la infraestructura para reintentos, colas y monitoreo, pero la política de retroceso, la clasificación de errores y la reconciliación del negocio aún deben ser definidas por la organización. Una herramienta sin política genera un registro detallado de fallos que nadie cierra. --- ## Deuda técnica en Flows y Apex: Guía para identificarla y reducirla sin detener el desarrollo URL: https://hpi.pro/es/insights/salesforce-flow-apex-technical-debt La deuda técnica en las automatizaciones de Salesforce no surge de una mala elección entre Flow y Apex, sino de cientos de pequeñas decisiones tomadas sin una política clara ni una visión acumulada. Este artículo explica cómo identificarla de manera práctica —a través de métricas, no de intuiciones— y cómo construir un plan de reducción que no detenga el ritmo de desarrollo. ## ¿Por qué la deuda técnica en automatizaciones es diferente de la deuda técnica regular? En Salesforce, es más fácil acumular deuda técnica que en un entorno de desarrollo regular, ya que la herramienta permite a cualquiera añadir automatizaciones sin pasar por un proceso de código estructurado. Cada administrador que añade un Flow Before Save para resolver un problema puntual, cada Trigger que alguien añadió hace dos años y nadie recuerda por qué, y cada campo de fórmula que contiene una dependencia de otro campo que ya no existe, todo esto se acumula en una capa que nadie ve en su totalidad. La diferencia fundamental entre la deuda técnica regular y la deuda técnica en las automatizaciones de Salesforce es que esta última casi siempre carece de documentación centralizada. El código reside en un repositorio con un historial de Commits; un Flow reside en Setup sin una explicación de su origen. Esto hace que la fase de identificación sea especialmente difícil, no porque el problema sea técnicamente complejo, sino porque no hay a quién preguntar. Este artículo aborda la identificación, medición y reducción de esta deuda. No discute cuándo elegir Flow y cuándo Apex desde el principio; para eso se dedica [Flow vs. Apex: cómo elegir](/es/insights/salesforce-flow-vs-apex). ## Tres tipos de deuda que se comportan de manera diferente No toda la deuda técnica es igual, y tratarla toda como el mismo problema lleva a un desperdicio de esfuerzo. Conviene separarla en tres categorías: | Tipo de deuda | Ejemplo típico | ¿Qué sucede si se ignora? | Prioridad de tratamiento | | --- | --- | --- | --- | | Deuda estructural | Varios Triggers en el mismo objeto sin un Framework unificador | Orden de ejecución impredecible, falla silenciosa | Alta | | Deuda lógica | Flow con decenas de ramas de decisión que representan una regla de negocio ya modificada | Decisiones erróneas que se ejecutan silenciosamente | Alta | | Deuda de mantenimiento | Campos, Flows y variables permanentes sin documentación o uso | Aumento del tiempo de desarrollo, miedo a realizar cambios | Media | La deuda estructural y la deuda lógica generan un riesgo operativo real; pueden causar datos incorrectos que llegan al cliente o a un informe financiero. La deuda de mantenimiento ralentiza al equipo, pero no necesariamente interrumpe un proceso. Esta clasificación determina el orden de tratamiento: primero se elimina el riesgo operativo, luego se mejora la velocidad de desarrollo. ## Cómo identificar la deuda antes de que explote en producción La identificación no debe comenzar con una revisión manual exhaustiva del código; eso es demasiado caro e insostenible. Comienza con algunas métricas cuantitativas que se pueden obtener en una hora: - **Número de Flows activos en cada objeto central** (Lead, Opportunity, Case, etc.). Más de cinco o seis Flows activos en el mismo objeto dificulta la predicción del orden de ejecución. - **Número de Triggers no unificados bajo un mismo Framework** por cada objeto. Más de un Trigger por objeto ya es una señal de advertencia, a menos que exista una capa de enrutamiento explícita. - **Densidad de consultas SOQL dentro de bucles** que aparece en los registros como un Governor Limit cercano al umbral, aunque no se haya superado en la práctica. - **Tiempo de ejecución inusual de Flow o Apex Batch** que aumenta con el tiempo sin que el volumen de negocio crezca en la misma proporción. - **Campos y variables sin uso identificado** en el informe de Uso de Campos, que permanecen "por si alguien los necesita". Estas métricas no demuestran un problema inequívoco, pero proporcionan una lista de sospechosos enfocada. La combinación de estas métricas con una profunda comprensión de las integraciones de las que depende la automatización se detalla en [Patrones de integración de Salesforce](/es/insights/salesforce-integration-patterns). ## Marco de decisión: qué abordar primero No todos los hallazgos en la lista de sospechosos merecen la misma inversión. Un Framework simple para la priorización se basa en dos ejes: impacto comercial y probabilidad de falla: | Situación | Impacto comercial si falla | Probabilidad de falla a corto plazo | Acción | | --- | --- | --- | --- | | Automatización en el proceso de pedido/facturación con múltiples Triggers no documentados | Alta | Alta | Refactorización inmediata, fuera de la cola normal | | Flow complejo en la actualización de estado interno sin impacto externo | Baja | Alta | Documentación y simplificación a ritmo normal | | Trigger antiguo que funciona estable pero no está claro por qué existe | Potencialmente alta | Baja | Documentación primero, no intervención inmediata | | Campos no utilizados y variables permanentes huérfanas | Baja | Baja | Limpieza cíclica a nivel de Release | La regla general es: no se aborda lo que más molesta a los desarrolladores, sino lo que es más peligroso para el negocio. Un Trigger antiguo y estable que nadie entiende es a veces el caso más tentador para intervenir primero, y ese es precisamente el caso en el que una intervención descuidada provoca el mayor daño. ## Escenario organizacional: una compañía de seguros con 14 Flows en Opportunity Supongamos una compañía de seguros mediana que ha gestionado ventas B2B a través de Salesforce durante seis años. Con el tiempo, se han acumulado 14 Flows activos en el objeto Opportunity: siete manejan actualizaciones de etapa, tres envían alertas internas, dos sincronizan datos con una herramienta externa de BI, y otros dos son restos de un proceso antiguo que fue reemplazado hace dos años pero nunca fue desactivado. El detonante para identificar el problema fue una falla concreta: una transacción pasó a la etapa "Cerrada-Ganada" pero la alerta al equipo de suscripción no se envió, porque otro Flow actualizó el mismo campo en paralelo y creó un orden de ejecución no previsto. El equipo pasó dos días intentando entender por qué, no porque el error fuera complicado, sino porque nadie conocía el orden de ejecución completo de los 14 componentes. El tratamiento no fue "reescribir todo en Apex". El equipo primero mapeó los 14 Flows y los clasificó según la tabla anterior: los dos Flows antiguos se desactivaron después de verificar que no había dependencias activas, las tres alertas se unificaron en un solo Flow con una lógica de enrutamiento clara, y las siete actualizaciones de etapa se unificaron bajo un único Record-Triggered Flow con un orden de ejecución explícito. Resultado: de 14 componentes a 6, con un orden de ejecución documentado que cualquier nuevo desarrollador puede leer en quince minutos. ## Riesgos en el propio proceso de reducción La reducción de la deuda técnica es una acción con sus propios riesgos, no solo una corrección de un riesgo existente: | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Cambio en el orden de ejecución que rompe una dependencia oculta | Proceso que funcionaba deja de funcionar después de la unificación de Flows | Mapeo completo de dependencias y pruebas de regresión antes de cualquier unificación | | Eliminación de un componente "muerto" que en realidad sigue funcionando en un escenario raro | Falla que aparece solo al final de un trimestre o en un escenario extremo estacional | Revisar registros de ejecución durante un año completo, no solo el último mes | | Conversión a Apex sin un propietario del proceso que comprenda la regla de negocio | El nuevo código es "técnicamente correcto" pero implementa una regla antigua que ya ha cambiado | Validar la regla de negocio con el propietario del proceso antes de escribir código, no solo con el código existente | | Refactorización realizada en un Sandbox y no sincronizada | El problema reaparece en el entorno de producción después del siguiente Deploy | Gestionar el cambio a través de un proceso de Release regular y no como una corrección "fuera de la cola" | El riesgo común a todos ellos es el mismo fenómeno: el equipo está seguro de que "solo está limpiando" y, por lo tanto, omite las pruebas que habría realizado para una nueva funcionalidad. A nivel de Gobernanza, la refactorización debe pasar por el mismo proceso de aceptación que el desarrollo regular, no menos. ## Métricas para el seguimiento continuo de la reducción Para saber que el esfuerzo realmente reduce la deuda y no solo la desplaza, conviene seguir: - **Número de componentes de automatización activos por objeto**, como una métrica de tendencia trimestral y no puntual. - **Tiempo promedio para diagnosticar un error de automatización**, desde el momento del informe hasta la identificación del componente responsable. - **Porcentaje de componentes documentados** del total de automatizaciones activas en el clúster central. - **Número de errores recurrentes en el mismo componente** en un período de tres meses. Las organizaciones que tienen dificultades para priorizar entre la refactorización y el desarrollo continuo utilizan el [servicio de arquitectura CRM](/es/crm-architecture) para construir un plan de trabajo vinculante y medible. ## Checklist operativo antes de iniciar la refactorización - ☐ Existe un mapa completo de todas las automatizaciones activas en el objeto relevante - ☐ Se conoce el orden de ejecución real, no solo por el orden de creación - ☐ Cada componente destinado a la eliminación ha sido revisado en los registros de ejecución durante un año completo - ☐ El propietario del proceso de negocio ha aprobado la regla que se vuelve a implementar - ☐ Existe un entorno de pruebas que simula un volumen de datos real - ☐ Se ha definido una métrica "antes y después" para el número de componentes y el tiempo de diagnóstico - ☐ El proceso de refactorización pasa por un Release regular, no por un Deploy excepcional - ☐ Se ha asignado una capacidad constante en cada Sprint para el tratamiento continuo, no solo un evento puntual ## Resumen La deuda técnica en las automatizaciones de Salesforce se acumula silenciosamente, componente por componente, y por lo tanto debe desmantelarse también silenciosamente, no en un gran proyecto de limpieza que detiene el desarrollo durante un mes. Las herramientas necesarias son relativamente simples: contar componentes por objeto, mapear el orden de ejecución y clasificar por impacto comercial vs. probabilidad de falla. Lo que determina el éxito es la continuidad: asignar una capacidad constante para reducir la deuda junto con el desarrollo continuo, y no perseguir puntualmente el componente que causó la última falla. Una organización que adopta este hábito de medición llega a un punto en el que cualquier nuevo desarrollador puede entender en una hora qué sucede al guardar un registro, y eso, en última instancia, es la definición más práctica de la ausencia de deuda técnica. ### Preguntas y respuestas **¿Cuántos Flows en el mismo objeto se consideran demasiados?** No hay un número mágico, pero sí una señal clara: cuando un desarrollador no puede predecir lo que sucederá al guardar un registro sin abrir toda la lista y seguir el orden de ejecución, ya existe un problema operativo, incluso si solo hay tres Flows. El problema no es la cantidad, sino la falta de coordinación y documentación del orden de ejecución entre ellos. **¿Es posible reducir la deuda técnica sin detener el desarrollo de nuevas funcionalidades?** Sí, y generalmente es el enfoque correcto. Se asigna un porcentaje fijo de cada Sprint —por ejemplo, una décima parte de la capacidad— a la reducción de la deuda según una lista de prioridades, en lugar de solicitar un 'Sprint de congelación' dedicado que casi siempre se pospone cuando llegan las prioridades comerciales. **¿Cuándo se convierte un Flow en código Apex debido a la deuda técnica?** Cuando el Flow contiene lógica compleja con más de unas pocas ramas de decisión, cuando llama a la misma consulta varias veces debido a una mala estructura modular, o cuando necesita ser sometido a pruebas automatizadas que las herramientas gráficas no soportan adecuadamente. La conversión en sí es una herramienta técnica; la decisión se deriva de la medición de la complejidad real y no de una preferencia estilística. **¿Cómo se mide la deuda técnica sin invertir en una herramienta externa?** Se puede empezar con Salesforce Optimizer y los informes internos de Configuración para contar los Flows activos por objeto, junto con una consulta de Tooling API sobre los límites de Apex y los Registros de Depuración para tiempos de ejecución anómalos. Esto no sustituye por completo a una herramienta dedicada de Static Analysis, pero es suficiente para construir una primera lista de prioridades. **¿Qué hacer cuando el equipo de desarrollo se opone a invertir tiempo en 'Refactor'?** Se presentan los costes en términos que la dirección entienda: horas de soporte repetitivas para el mismo error, tiempo de lanzamiento de versiones que se alarga y riesgo concreto para un proceso comercial clave. Un 'Refactor' que se presenta como 'limpieza de código' casi siempre se pospone; un 'Refactor' que se presenta como una reducción del riesgo operativo se prioriza. --- ## Modelo de Datos en Salesforce: Objetos Estándar, Objetos Personalizados y Decisiones Clave URL: https://hpi.pro/es/insights/salesforce-data-model-design El modelo de datos es la decisión más costosa de modificar después de la puesta en marcha (Go-Live). Esta guía explora cuándo usar Objetos Estándar, cuándo se justifica un Objeto Personalizado, cómo elegir entre Lookup y Master-Detail, y cómo un modelo aparentemente limpio en el diseño puede generar limitaciones de informes, permisos y rendimiento años después. ## La Respuesta Corta Un buen modelo de datos en Salesforce no es el más hermoso teóricamente, sino aquel que sostiene simultáneamente tres elementos: el proceso de negocio, el modelo de permisos y los informes requeridos. La mayoría de los modelos fallidos se construyen únicamente en torno al primero. La diferencia entre una decisión de modelo y otras decisiones en un proyecto radica en el costo del cambio. Cambiar un Flow toma un día; cambiar el tipo de relación entre objetos después de dos años de datos, automatizaciones e integraciones es un proyecto en sí mismo. Por lo tanto, la inversión en la fase de planificación rinde frutos aquí más que en cualquier otro lugar. ## La Primera Regla: Comenzar con los Objetos Estándar Account, Contact, Lead, Opportunity, Case y Product traen consigo capacidades que no se obtienen de forma gratuita con un objeto personalizado: procesos de venta, Forecasting, Entitlements, Omni-Channel, aplicación móvil e integración incorporada con otros productos de la plataforma. Una organización que crea `Customer__c` en lugar de Account inicialmente obtiene un modelo que parece más limpio, y luego descubre que cada capacidad predefinida requiere una construcción independiente. La regla: solo se desvía del estándar cuando existe una razón que se puede escribir en una frase. ## ¿Cuándo se Requiere un Objeto Personalizado? | Situación | ¿Objeto Personalizado? | Justificación | | --- | --- | --- | | Contrato/Suscripción con ciclo de vida propio | Sí | Estados, renovación, propiedad e informes separados | | Activo instalado en un cliente | Sí (o Asset estándar) | Entidad independiente con historial de servicio | | "Cliente potencial" adicional | No | Es un Lead o una Account con un Record Type | | Departamento en la organización | No | Dato sobre un usuario, no una entidad | | Líneas de precios complejas | Depende | Evaluar Quote Line o CPQ antes de construir | ## Normalización vs. Desnormalización: La Decisión que Afecta los Informes En las bases de datos clásicas, la normalización es una virtud. En Salesforce, esta se negocia por la comodidad de los informes: cada nivel adicional de relación dificulta la construcción de un informe sin una herramienta externa, porque los informes estándar están limitados en la profundidad de las relaciones. El compromiso aceptado es la normalización donde los datos cambian y se duplican, y una desnormalización controlada de campos de consulta comunes hacia el objeto desde el cual se informa, siempre que la duplicación se gestione automáticamente y no manualmente. Un campo duplicado que se actualiza mediante entrada manual se convierte en una falsedad en cuestión de meses. ## Los Permisos son Parte del Modelo, no una Etapa Posterior La pregunta "¿quién ve qué?" debe hacerse al diseñar los objetos. Un modelo en el que un dato sensible reside en el mismo objeto que un dato operativo obliga posteriormente a soluciones indirectas, como un objeto sombra, campos cifrados o una apertura de visibilidad demasiado amplia. La prueba práctica: por cada nuevo objeto, se escribe una línea: quién es el propietario, quién lee, quién modifica y qué sucede en la jerarquía. Si la respuesta requiere más de cuatro líneas, la estructura probablemente mezcla dos entidades. Puede encontrar una expansión sobre las fuentes de información y la autoridad de actualización en [Source of Truth en la organización](/es/insights/salesforce-source-of-truth), y sobre la gestión de entidades principales en [Master Data Management](/es/insights/salesforce-master-data-management). ## Escenario: Empresa de Software que Construyó un Modelo en Torno a los Departamentos Una empresa SaaS de tamaño medio construyó un modelo con cuatro objetos personalizados, uno para cada equipo de ventas, porque cada equipo tenía un proceso diferente. Un año y medio después se produjo una fusión de equipos, y entonces se requirieron: consolidación de informes, automatizaciones paralelas en cuatro lugares y una migración interna de 60 mil registros entre objetos. La reconstrucción se basó en una única Opportunity con Record Types para los diferentes procesos. Se mantuvo la misma distinción de negocio (diferentes rutas de venta, diferentes campos, diferentes Page Layouts), pero a nivel de configuración y no a nivel de estructura. El próximo cambio organizativo requerirá un cambio de Record Type, no una migración. La regla que surgió de esto: la estructura representa entidades; la configuración representa la organización. Lo que se espera que cambie cada dos años no debería vivir en la estructura. ## Rendimiento y Volumen: Lo que Realmente Importa Los problemas de rendimiento en un modelo de datos provienen principalmente de tres lugares: Data Skew (un único padre con decenas de miles de hijos, por ejemplo, la Account "clientes individuales"), fórmulas anidadas que calculan en tiempo real a través de relaciones, y el compartir basado en Apex Sharing creado a gran escala. Los tres pueden identificarse en la fase de planificación si se pregunta cuántos registros se esperan bajo cada padre. ## Riesgos Comunes y Acciones Preventivas | Riesgo | Cómo se Manifiesta en la Práctica | Acción Preventiva | | --- | --- | --- | | Objeto Personalizado Innecesario | Capacidades predefinidas se construyen manualmente de nuevo | Revisar el Objeto Estándar antes de cada nuevo objeto | | Master-Detail Demasiado Temprano | Eliminaciones en cascada y una estructura inmutable | Comenzar con Lookup si no se necesita un Roll-Up | | Modelo que Refleja la Organización | Cada cambio organizativo se convierte en una migración | Record Types en lugar de objetos | | Data Skew | Bloqueos y lentitud en actualizaciones masivas | Distribución de padres, verificación de volumen en la planificación | | Permisos como Consideración Tardia | Soluciones indirectas y visibilidad demasiado amplia | Matriz de acceso para cada objeto durante la planificación | ## Cómo Medir el Éxito | Área | Qué se Mide | Frecuencia de Evaluación | | --- | --- | --- | | Uso de Campos | Tasa de completitud por cada campo | Trimestral | | Informes | Porcentaje de informes que requieren consolidación manual | Trimestral | | Estabilidad de la Estructura | Número de cambios estructurales por semestre | Semestral | | Rendimiento | Tiempos de actualización masiva y bloqueos | Mensual | La planificación del modelo de datos como parte de una arquitectura integral se lleva a cabo dentro del marco del [servicio de integraciones y datos](/es/integrations-data). ## Checklist Antes de Congelar el Modelo - ☐ Por cada objeto personalizado existe una justificación en una frase. - ☐ Se ha revisado un Objeto Estándar alternativo para cada entidad. - ☐ El tipo de relación se ha elegido explícitamente con una justificación para Master-Detail. - ☐ Se ha estimado el volumen esperado para cada padre (verificación de Skew). - ☐ Matriz de acceso: propietario, lector, modificador, jerarquía. - ☐ Se ha verificado que cada informe central se pueda construir en el modelo. - ☐ Los campos duplicados se actualizan solo automáticamente. - ☐ Los cambios organizativos esperados se manejan en la configuración. - ☐ Existe un ERD actualizado y documentado. - ☐ Se ha determinado quién aprueba los cambios estructurales futuros. ## Fuentes Profesionales - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Integraciones y Datos — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Preguntas y respuestas **¿Cuándo se justifica un objeto personalizado y cuándo es un error?** Se justifica cuando la entidad tiene un ciclo de vida propio: estados, propiedad, permisos e informes separados. Es un error cuando se crea solo para evitar añadir campos a un objeto existente, o para reflejar una estructura organizacional. Las estructuras organizativas cambian; los objetos no se adaptan fácilmente a esos cambios. **¿Lookup o Master-Detail?** Master-Detail permite Roll-Up Summaries y herencia de permisos, pero es rígido: eliminar el padre elimina los hijos, y el registro no puede existir sin un padre. Lookup es más flexible y se puede modificar posteriormente. La regla práctica: Master-Detail solo cuando el hijo carece realmente de significado sin el padre y se requiere una sumarización automática. **¿Cuántos campos son 'demasiados' en un objeto?** El número es menos importante que el uso. Un objeto con 200 campos, todos utilizados en informes, es aceptable; un objeto con 60 campos, la mayoría vacíos en el 80% de los registros, indica que las entidades se han comprimido en el mismo lugar. La mejor manera de evaluar es la tasa de completitud por cada campo, no el conteo total. **¿Es necesario replicar la estructura del ERP en Salesforce?** No. El ERP está diseñado en torno a transacciones, Salesforce en torno a relaciones y procesos. Replicarlo completamente genera docenas de objetos que nadie usa. Solo transfiera a Salesforce lo necesario para el proceso de ventas y servicio; para todo lo demás, use acceso remoto o Data 360. **¿Cómo saber que el modelo no será sostenible?** Hay tres señales de advertencia: informes que requieren consolidación manual entre objetos, campos de fórmula anidados profundamente para compensar la estructura, y solicitudes de permisos que no se pueden cumplir sin exponer una visibilidad amplia. Cada uno de estos indica que la estructura no es compatible con el proceso. --- ## Gestión de Datos Maestros con Salesforce: Propiedad, Golden Record y Sincronización URL: https://hpi.pro/es/insights/salesforce-master-data-management La Gestión de Datos Maestros (MDM) falla cuando se enfoca como un proyecto tecnológico y tiene éxito cuando se define como un régimen de propiedad. Esta guía explica qué entidades requieren realmente un gestionamiento maestro, cómo construir un Golden Record entre CRM y ERP sin afectar ningún sistema, cuándo es necesaria una herramienta MDM dedicada y cuándo Salesforce es suficiente, y cómo medir la efectividad del régimen. ## La respuesta breve La Gestión de Datos Maestros (MDM, por sus siglas en inglés) no es un repositorio, es un acuerdo. Este acuerdo establece quién define la entidad, quién está autorizado a modificarla, cómo se identifican dos registros como la misma entidad y qué sucede cuando los sistemas discrepan. La tecnología solo aplica lo acordado. El error común es empezar por la selección de una herramienta. Una organización que no ha decidido qué define a un "cliente" obtendrá una herramienta que unifica exactamente esa misma ambigüedad, pero más rápidamente y con un coste más elevado. ## Qué se incluye en los Datos Maestros y qué no | Tipo de Dato | Ejemplo | ¿Es Dato Maestro? | | --- | --- | --- | | Datos Maestros | Cliente, producto, proveedor, sitio | Sí | | Datos de Referencia | Países, monedas, códigos de industria | Gestión separada y más sencilla | | Transaccional | Pedido, factura, caso | No | | Analítico | Segmentación, puntuación, previsión | No - es derivado | Esta distinción es crucial porque cada tipo requiere un gobierno diferente. Los Datos de Referencia se controlan en una tabla pequeña con un único propietario; los Transaccionales permanecen en el sistema que los creó; los Analíticos no deben convertirse en una fuente de verdad, ya que son el resultado de un cálculo variable. ## Los tres estilos de implementación **Registro (Registry)** - Se gestiona únicamente una tabla de identificadores que vincula registros de diferentes sistemas. Es económico, rápido, no modifica ningún sistema existente y proporciona una visión unificada para la lectura. Casi siempre es adecuado como primera fase. **Consolidación (Consolidation)** - Se genera un "Golden Record" para fines de informes y análisis, sin retroalimentarlo. Es adecuado cuando el principal problema son los informes duplicados. **Centralizado (Centralized)** - El Maestro se convierte en la fuente vinculante y los sistemas consumen de él. Ofrece el mayor valor, pero también la mayor exigencia en cuanto a gobierno y procesos de aprobación. Las organizaciones que directamente saltan a esta fase descubren que no tienen Stewards para operarlo. El enfoque práctico es una escalera: un Registro para una entidad, y luego la expansión —según el valor demostrado y no según un plan maestro. ## Survivorship: las reglas que determinan qué prevalece El núcleo del "Golden Record" son las reglas de Survivorship a nivel de campo: para cada campo, existe una fuente preferida y una regla de respaldo cuando la fuente preferida está vacía. Junto a esto, siempre se mantienen los identificadores de los sistemas de origen, para poder explicar cada valor. Un principio que evita discusiones: el "Golden Record" no elimina los registros de origen ni pretende reemplazarlos. Es una capa que los referencia. Esto significa que se puede corregir una regla y recalcular, una capacidad que no tienen quienes lo fusionaron todo en la fase de carga. Una mayor profundización en la determinación de la propiedad se encuentra en [Fuente de Verdad en la Organización](/es/insights/salesforce-source-of-truth), y en la deduplicación que la precede en [Deduplicación de Datos en Salesforce](/es/insights/salesforce-data-deduplication). ## Stewardship: el rol que determina el éxito Todo régimen de MDM genera una cola de decisiones: coincidencias sobre las que el sistema no está seguro, solicitudes para crear una nueva entidad y conflictos entre fuentes. Si no hay una persona con tiempo asignado para gestionar la cola, esta crece hasta que deja de ser revisada. Un alcance realista: en una organización mediana, esto implica unas pocas horas a la semana para una sola entidad, generalmente por parte de alguien del ámbito empresarial y no de TI. Esta es la inversión que determina si el MDM vive o se convierte en una infraestructura silenciosa. ## Escenario: un fabricante con tres sistemas y un cliente Un fabricante industrial gestionaba clientes en tres lugares: ERP, Salesforce y un sistema de servicio. Una misma corporación aparecía como tres entidades diferentes, y un informe de "ingresos por cliente" se construía manualmente en Excel cada trimestre. En lugar de un proyecto MDM completo, la organización comenzó con un Registro: se construyó una tabla de identificadores en Data 360 que vinculaba los tres registros mediante la identificación fiscal y una clave secundaria, y solo después se edificó un "Golden Record" para la lectura. Salesforce no cambió su estructura; recibió un campo de identificador global y una vista de "toda la actividad del grupo". El resultado después de un trimestre: el informe manual fue eliminado, y los comerciales vieron por primera vez la exposición crediticia a nivel de grupo, lo que impulsó una decisión de precios que recuperó el coste de esa fase. La expansión a un sistema Centralizado se consideró solo después de que se demostró que había un Steward que gestionaba activamente la cola. ## Riesgos comunes y acciones de prevención | Riesgo | Cómo se manifiesta en la práctica | Acción de prevención | | --- | --- | --- | | Empezar por la herramienta | Un repositorio unificado que refleja la ambigüedad existente | Definiciones de entidad y propiedad antes de elegir la herramienta | | Demasiadas entidades | Un proyecto largo sin valor visible | Una entidad hasta la producción, y luego la expansión | | Ausencia de Steward | Una cola de conciliaciones que crece y es abandonada | Un rol con tiempo asignado y SLA | | Fusión destructiva | Imposibilidad de explicar o recuperar un valor | Guardar identificadores de origen y recalcular | | Centralizado prematuramente | Todos los sistemas dependen de una infraestructura inmadura | Comenzar con un Registro (Registry) | ## Cómo medir el éxito | Área | Qué se mide | Frecuencia de revisión | | --- | --- | --- | | Cobertura | Porcentaje de registros vinculados a un identificador global | Mensual | | Precisión | Tasa de vínculos cancelados o corregidos | Mensual | | Cola de Stewardship | Elementos abiertos y tiempo medio de cierre | Semanal | | Valor de negocio | Informes manuales eliminados, decisiones a nivel de grupo | Trimestral | La construcción de un régimen de MDM gradual se realiza en el marco de [Servicios de Integraciones y Datos](/es/integrations-data). ## Lista de verificación antes de iniciar MDM - ☐ Se han seleccionado hasta tres entidades para la primera fase. - ☐ Para cada entidad, existe una definición de negocio escrita. - ☐ Se ha elegido el estilo de implementación: Registro, Consolidación o Centralizado. - ☐ Se han identificado claves de identificación robustas para cada fuente. - ☐ Se han redactado las reglas de Survivorship a nivel de campo. - ☐ Los identificadores de origen se conservan y permiten el recálculo. - ☐ Se ha nombrado un Steward con tiempo asignado y un SLA. - ☐ Se ha definido un proceso de aprobación para la creación de nuevas entidades. - ☐ Se ha establecido una métrica de valor para la primera fase. - ☐ Existe una decisión sobre cuándo considerar una herramienta dedicada. ## Recursos profesionales - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Qué entidades necesitan realmente gestión maestra?** Solo aquellas que aparecen en más de un sistema y afectan ingresos, regulaciones o la experiencia del cliente. En la mayoría de las organizaciones, se trata de tres a cinco: Cliente/Proveedor, Producto, Estructura Organizacional-Comercial, y ocasionalmente Ubicación o Activo. Intentar gestionar 20 entidades simultáneamente es la forma más rápida de estancarse. **¿Se necesita una herramienta MDM dedicada?** No siempre. Para hasta tres sistemas de origen y una complejidad de correspondencia media, Salesforce con External IDs, Matching Rules e integración gestionada es suficiente. Una herramienta dedicada se justifica cuando hay múltiples fuentes, requisitos formales de Stewardship, mantenimiento de historial de cambios para regulación, o Survivorship complejo a nivel de campo. **¿Cuál es la diferencia entre Registry, Consolidation y Centralized?** Registry solo almacena mapeos de identificadores y deja los datos en su fuente original. Consolidation produce una copia unificada solo para fines de informes. Centralized convierte el repositorio en la fuente autorizada de la que todos leen. Cuanto más se avanza en la escala, mayor es el valor, así como el costo de implementación y gobierno. **¿Puede Salesforce ser el 'Master' para un cliente?** Sí, cuando el cliente se crea y gestiona a través del proceso de venta. En la mayoría de las organizaciones, el compromiso es una división: identidad legal y condiciones comerciales en el ERP, entidad comercial e información de contacto en Salesforce, con un identificador común que las vincula. **¿Cuánto tiempo se tarda en obtener el primer valor?** Para una entidad con dos orígenes, entre seis y doce semanas hasta tener un Golden Record activo en producción. Los proyectos de MDM planificados para dos años para una 'infraestructura completa' a menudo no sobreviven a los cambios de liderazgo. Es mejor tener una entidad en producción que una arquitectura completa en una presentación. --- ## Data 360 vs. Datos de CRM en Salesforce: ¿Qué guardar dónde? URL: https://hpi.pro/es/insights/data-360-vs-crm-data No todos los datos relacionados con el cliente deben residir en el CRM. Esta guía distingue entre datos operativos que impulsan procesos diarios y datos de comportamiento de alto volumen, esenciales para la unificación, segmentación y activación de perfiles, mostrando cómo esta decisión impacta el rendimiento, el costo, los permisos y las capacidades de IA. ## La respuesta breve La decisión entre un CRM y Data 360 no se trata de "dónde hay espacio", sino de "quién consume el dato y a qué ritmo". Un CRM se construye en torno a un registro que alguien abre, edita y promueve en un proceso. Data 360 se construye en torno a un flujo de eventos que se unifica en un perfil y se utiliza para segmentación, análisis y activación. Cuando se mezclan ambos, se obtienen uno de dos resultados: un CRM pesado con millones de registros que nadie utiliza, o una capa de datos enriquecida que nadie activa porque no llega al flujo de trabajo. ## Distribución práctica | Tipo de información | Dónde | Justificación | | --- | --- | --- | | Cliente, contacto, oportunidad, caso | CRM | Gestionado manualmente, impulsa procesos y permisos | | Etapa de venta, tareas, aprobaciones | CRM | Automatización y operación diaria | | Clics, visualizaciones, uso del producto | Data 360 | Alto volumen, no gestionado manualmente | | Historial de transacciones de ERP | Data 360 (o acceso virtual) | Volumen y fuente de verdad externa | | Perfil unificado e identidad entre sistemas | Data 360 | Su misión es unificar identificadores | | Puntuación, segmentación, recomendación | Calculado en Data 360, mostrado en CRM | Cálculo de alto volumen, uso en el flujo de trabajo | La última línea es el principio central: se calcula donde hay volumen, se muestra donde hay una decisión. ## La prueba de las cuatro preguntas Antes de introducir un dato en el CRM, pregúntese: ¿Alguien lo edita manualmente? ¿Depende de él una automatización o validación? ¿Se requiere en un informe operativo rutinario? ¿Afecta a los permisos o la propiedad? Si la respuesta a las cuatro es no, el dato casi siempre pertenece a la capa de unificación. La dirección inversa también es válida: un dato que solo se guarda en Data 360, pero que se necesita para tomar una decisión en tiempo real, debe tener un mecanismo de retorno —un campo de resumen, una vista o una acción—; de lo contrario, no afectará al resultado de negocio. ## Volumen, rendimiento y coste El precio y el diseño del CRM se basan en registros de negocio. La introducción de eventos de comportamiento en él cambia el perfil de carga: las actualizaciones masivas se ralentizan, la creación de informes se vuelve pesada y las copias de seguridad y los entornos de prueba crecen. Data 360 está diseñado para este ritmo y su precio se basa en el consumo, lo que requiere una atención diferente: las consultas amplias y los flujos innecesarios generan costes recurrentes. En ambos casos, la higiene es la misma: transferir solo lo que tiene un consumidor y definir una política de retención para cada flujo. La discusión sobre la copia frente al acceso remoto se detalla en [Zero Copy y Federation](/es/insights/data-360-zero-copy-federation). ## Permisos: la brecha que es fácil pasar por alto El modelo de permisos de CRM es rico y preciso a nivel de registro y campo. Una capa de unificación funciona de manera diferente: está diseñada para el análisis y su exposición se rige por reglas de acceso y máscaras. Una organización que transfiera datos sensibles a la capa de unificación sin planificarlo podría crear una visibilidad más amplia de la que existe en el CRM. La regla: todo flujo que contenga información sensible recibe una decisión de exposición explícita antes, y no después, de la ingesta. ## Escenario: un minorista que lo transfirió todo al CRM Una cadena minorista transfirió tres años de historial de compras —aproximadamente 40 millones de filas— a un objeto personalizado en el CRM, con el deseo de que "el vendedor tuviera una imagen completa". El resultado: largos tiempos de carga en la pantalla del cliente, actualizaciones nocturnas que excedían la ventana de tiempo disponible y fallos en los informes por tiempo de espera. En la reconstrucción, solo quedaron cuatro valores derivados en el CRM: fecha de la última compra, importe de 12 meses, categoría principal y un indicador de riesgo de abandono. El historial completo se trasladó a la capa de unificación, con un enlace a una vista detallada bajo demanda. La pantalla del cliente se cargaba rápidamente, los vendedores obtuvieron lo que realmente necesitaban, y la segmentación de marketing incluso mejoró, porque se ejecutaba sobre datos que estaban todos en un mismo lugar y no solo sobre aquellos que lograron entrar en el CRM. ## Riesgos comunes y acciones de prevención | Riesgo | Cómo se manifiesta en la práctica | Acción de prevención | | --- | --- | --- | | Todo en el CRM | Rendimiento, coste y tiempos de carga | Valores derivados en lugar de historial bruto | | Todo en la capa de unificación | Conclusiones que no llegan al flujo de trabajo | Mecanismo de retorno: campo, vista o acción | | Sin retención | Volumen que crece sin propietario | Política de retención para cada flujo | | Permisos no planificados | Exposición de información sensible en análisis | Decisión de exposición antes de la ingesta | | Identidad no unificada | Perfil fragmentado para el mismo cliente | Reglas de Identity Resolution definidas | ## Cómo medir el éxito | Área | Qué medir | Frecuencia de revisión | | --- | --- | --- | | Rendimiento | Tiempo de carga de la pantalla del cliente y actualizaciones masivas | Mensual | | Unificación | Porcentaje de perfiles unificados con éxito | Mensual | | Activación | Segmentaciones y acciones creadas a partir de los datos en la práctica | Trimestral | | Coste | Consumo frente a presupuesto por flujo | Mensual | La planificación de la distribución entre el CRM y la capa de unificación se lleva a cabo dentro de los [servicios de integraciones y datos](/es/integrations-data). ## Lista de verificación para la decisión - ☐ Mapeo de flujos de datos por volumen y ritmo de actualización - ☐ Prueba de las cuatro preguntas para cada flujo - ☐ Se han definido los valores derivados que se mostrarán en el CRM - ☐ Existe un mecanismo de retorno de la unificación al flujo de trabajo - ☐ Reglas de Identity Resolution documentadas - ☐ Decisión de exposición para cada flujo con información sensible - ☐ Política de retención para cada flujo - ☐ Estimación de coste de consumo para la primera fase - ☐ Se ha seleccionado un caso de uso para la prueba de valor - ☐ Se ha asignado un propietario para cada flujo de datos ## Fuentes profesionales - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Integraciones y Datos — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Preguntas y respuestas **¿Qué pregunta determina dónde deben residir los datos?** Si un usuario o una automatización actúan sobre esos datos dentro de un proceso de trabajo. Si es así, su lugar es el CRM. Si están destinados a la segmentación, análisis, unificación de perfiles o para alimentar un modelo, su lugar es Data 360. Los datos que nadie utiliza ni analiza no deberían estar en ninguno de los dos. **¿Data 360 reemplaza un Data Warehouse?** No necesariamente. Se especializa en la unificación de perfiles de clientes y en la activación en procesos de ventas, servicio y marketing. Un Data Warehouse empresarial sigue sirviendo para informes financieros y operativos más amplios. En la práctica, coexisten, y a menudo se conectan mediante acceso virtual sin duplicación. **¿Necesitamos Data 360 para la IA?** No para todos los usos. Para resumir una conversación o redactar una respuesta, el contexto en el CRM es suficiente. Sin embargo, para recomendaciones, puntuación o un Agente que requiere un historial amplio de varios sistemas, se necesita una capa de unificación, y ese es precisamente el rol de Data 360. **¿Qué sucede al copiar datos de comportamiento al CRM?** Comienza a pagar el doble: en almacenamiento y rendimiento. Millones de filas de eventos en un objeto personalizado ralentizan las actualizaciones masivas, inflan los índices y dificultan los informes. La solución habitual es un resumen: guardar un valor derivado en el CRM (puntuación, última fecha, contador) y no los eventos en sí. **¿Por dónde empezar cuando ya se tiene un CRM saturado?** Identificando tres grupos de datos de alto volumen y bajo uso operativo, para luego trasladarlos a la capa de unificación, dejando un campo resumido en el CRM. Esto mejora el rendimiento y establece una base para la segmentación sin la necesidad de un proyecto de infraestructura completo. --- ## Zero Copy y Federación de Datos en Data 360: Cuándo no es necesario duplicar su información URL: https://hpi.pro/es/insights/data-360-zero-copy-federation Cada copia de un dato implica un compromiso: recursos, coste, latencia y riesgo. La funcionalidad Zero Copy permite consultar la información en su ubicación original, pero no es una solución universal. Esta guía detalla cuándo es preferible un acceso virtual, cuándo la ingesta de datos es más adecuada y cómo tomar decisiones basándose en la frescura, el rendimiento, la gobernanza y el coste de movimiento de la información. ## La respuesta breve La regla antigua dictaba: "para analizar un dato, primero hay que copiarlo". Sin embargo, Zero Copy anula esta premisa en muchos escenarios: permite consultar una tabla alojada en un almacén de datos externo sin necesidad de transferirla. Esta es una capacidad real, pero intercambia un tipo de costo por otro; en lugar de costos de almacenamiento y canalización, se incurre en costos de computación y se genera una dependencia de la disponibilidad de la fuente. La decisión es correcta cuando se aborda como cualquier decisión arquitectónica: basándose en los requisitos de uso, no en tendencias. ## Los cuatro parámetros decisivos | Parámetro | Se inclina a Zero Copy | Se inclina a Ingestion | | --- | --- | --- | | Freshness | Se requiere el dato más actualizado en todo momento | Ciclos programados son suficientes | | Rendimiento | Análisis y segmentación, tolerancia de segundos | Operación en tiempo real, tiempo de respuesta constante | | Volumen y frecuencia | Gran volumen, pocas consultas | Volumen moderado, muchas consultas | | Gobernanza | La fuente mantiene una política robusta | Se necesita control total sobre la copia | Esta tabla también explica por qué la mayoría de las organizaciones optan por una combinación: los flujos operativos se ingieren, mientras que los flujos analíticos pesados permanecen en su lugar. ## Lo que el equipo mantiene bajo su responsabilidad, incluso con Zero Copy El acceso virtual elimina la canalización, no el trabajo. Siguen siendo necesarios: el mapeo del esquema al modelo compartido, la decisión sobre las claves de identificación para la unificación del perfil, la gestión de cambios de esquema en la fuente y la monitorización de la disponibilidad. Un cambio de nombre de columna en el almacén externo interrumpirá una vista virtual, tal como interrumpe un ETL. Por lo tanto, el acuerdo con el equipo de datos que gestiona la fuente forma parte de la implementación: notificación anticipada de cambios de esquema, una ventana de mantenimiento conocida y un presupuesto de consultas acordado. ## Patrones híbridos que funcionan **Resumen interno, detalle externo** – Se ingresan a la capa de unificación valores resumidos para cada cliente, y las líneas de detalle se mantienen en el almacén para acceso bajo demanda. Este es el patrón más común y generalmente el más económico. **Ventana activa y archivo frío** – Los últimos 12 a 24 meses se copian internamente para un mejor rendimiento, y el historial más antiguo permanece accesible virtualmente. **Virtual primero, copia según la demanda** – Se comienza con acceso virtual, se mide la frecuencia de uso real y se copia solo lo que se ha comprobado que se necesita con regularidad. Esta es la forma efectiva de evitar la copia de datos que nadie consultará. La relación entre esta decisión y la distribución de responsabilidades entre sistemas se detalla en [Datos 360 vs. Datos de CRM](/es/insights/data-360-vs-crm-data) y en [Fuente de la Verdad en la Organización](/es/insights/salesforce-source-of-truth). ## Escenario: una empresa financiera con 400 millones de filas Una empresa de servicios financieros deseaba segmentar clientes basándose en un historial de transacciones de siete años, aproximadamente 400 millones de filas en un data warehouse en la nube. El plan original era la ingesta completa a la capa de unificación. El piloto cambió la decisión. Se determinó que las segmentaciones reales se basaban únicamente en tres cálculos: promedio mensual, tendencia de 90 días y clasificación de actividad, y todos ellos podían calcularse en el propio almacén. En lugar de transferir 400 millones de filas, se transfirieron tres columnas resumidas por cliente, actualizadas diariamente, mientras que el detalle permaneció virtualmente accesible para indagaciones puntuales. Lo que se decidió aquí no fue "virtual vs. copia" sino a nivel de granularidad: la pregunta correcta era con qué resolución se necesitaban realmente los datos. Al responderla, la cuestión de la copia se volvió insignificante. ## Riesgos comunes y acciones de prevención | Riesgo | Cómo se manifiesta en la práctica | Acción de prevención | | --- | --- | --- | | Costo de cómputo sorprendente | Consultas amplias con alta frecuencia | Medición durante el piloto y acuerdo previo | | Dependencia de la disponibilidad de la fuente | Una falla en el almacén interrumpe la segmentación | Fallback o ventana activa copiada | | Cambios de esquema | Las vistas se rompen sin previo aviso | Acuerdo de cambios y monitorización del esquema | | Permisos no definidos | Exposición más amplia que la original | Identidad de consulta y política de exposición escrita | | Granularidad incorrecta | Se transfieren detalles que nadie necesita | Decidir la resolución antes que el método | ## Cómo medir el éxito | Área | Qué se mide | Frecuencia de revisión | | --- | --- | --- | | Rendimiento | Tiempo de respuesta para consultas de segmentación clave | Mensual | | Costo | Costo de cómputo y movimiento por cada caso de uso | Mensual | | Estabilidad | Fallos de consulta y disponibilidad de la fuente | Semanal | | Valor | Segmentaciones y operaciones generadas en la práctica | Trimestral | La elección de la combinación entre acceso virtual e ingesta se realiza en el marco de [Servicio de Integraciones y Datos](/es/integrations-data). ## Lista de verificación para la decisión de Zero Copy - ☐ Se han definido casos de uso concretos y no una "capacidad general". - ☐ Se ha establecido el requisito de frescura para cada caso de uso. - ☐ Se ha verificado la resolución de datos necesaria en la práctica. - ☐ Se ha estimado la frecuencia de consulta y el volumen de escaneo. - ☐ Existe un acuerdo de cambio de esquema con el propietario de la fuente. - ☐ Se ha definido la identidad de la consulta y la política de exposición. - ☐ Se ha considerado un patrón híbrido antes de una decisión binaria. - ☐ Hay un plan de respaldo (fallback) para fallas de la fuente. - ☐ Se ha realizado un piloto medido antes de la expansión. - ☐ Hay un responsable de la monitorización de costos y la revisión periódica. ## Recursos profesionales - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Integraciones y Datos — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Preguntas y respuestas **¿Qué ahorra realmente Zero Copy?** Ahorra el conducto y la redundancia: no hay ETL que mantener, no hay copias que caduquen y no hay dudas sobre qué copia es la correcta. Lo que no ahorra es cálculo: la consulta sigue ejecutándose, solo que en el sistema que posee el dato, donde consume su propio presupuesto. **¿Cuándo es preferible duplicar los datos?** Cuando se requiere un tiempo de respuesta bajo y estable para usos operativos, cuando la fuente no es estable o está limitada en la tasa de consultas, cuando se necesita un historial recuperado a un punto específico en el tiempo, o cuando la fuente podría desaparecer. En estos casos, una ingesta controlada es la elección responsable. **¿Es Zero Copy adecuado para operaciones en tiempo real?** Es menos adecuado. Una consulta virtual es apropiada para la segmentación, el análisis y el enriquecimiento contextual, pero un proceso operativo que espera una respuesta en fracciones de segundo debería basarse en un valor precalculado y almacenado cerca del consumidor. **¿Qué ocurre con la gobernanza y los permisos en el acceso virtual?** Estos permanecen principalmente en la fuente, lo cual es una ventaja: no hay una copia que proteger por separado. Sin embargo, es crucial definir explícitamente con qué identidad se realiza la consulta, qué se expone a quién en el lado del consumidor y cómo se registra la documentación; de lo contrario, se podría generar una exposición más amplia de la existente en el sistema de origen. **¿Cómo se estima el costo de antemano?** Basándose en tres factores: la frecuencia de la consulta, el volumen de escaneo en cada ejecución y la cantidad de tráfico entre entornos y regiones. Una consulta amplia que se ejecuta cada quince minutos puede costar más que la copia diaria del mismo dato. Se recomienda realizar una prueba piloto antes de escalar. --- ## Reconciliación y Cutover en Migraciones de Salesforce: Un Plan Detallado para el Día Cero URL: https://hpi.pro/es/insights/salesforce-migration-cutover-reconciliation El "Día Cero" de una migración a Salesforce suele fallar no por la carga de datos en sí, sino por lo que ocurre a su alrededor: deltas no capturados, integraciones activadas prematuramente o la ausencia de un tomador de decisiones crucial a las dos de la mañana. Esta guía presenta un plan de Cutover por hora, reglas de congelación de sistemas, una metodología de reconciliación en cuatro niveles y criterios claros de Go/No-Go. ## La respuesta breve El Cutover es un ejercicio operativo, no una fase técnica. Su éxito depende de tres factores: un plan detallado por hora con un responsable asignado a cada paso, una conciliación (reconciliation) que demuestre la veracidad de los datos —no solo su llegada—, y la definición de criterios Go/No-Go establecidos con serenidad. La diferencia entre una organización con una transición fluida y otra que experimentó dos semanas de caos reside casi siempre en el número de ensayos de reversión (rehearsals), no en la calidad de las herramientas. La planificación integral de la migración se describe en [Migración de datos a Salesforce](/es/insights/salesforce-data-migration-guide). ## Estructura de la ventana: tres olas | Ola | Cuándo | Qué se carga | | --- | --- | --- | | Históricos | 3-10 días antes | Datos históricos cerrados: oportunidades, casos cerrados, historial | | Delta | Durante la ventana | Todo lo que ha cambiado desde la primera ola | | Post-Go-Live | 24-72 horas después | Archivos pesados, datos no críticos, complementos | Esta división es lo que permite una ventana de tiempo reducida. Una organización que intenta cargar todo en una sola noche descubrirá que el tiempo de carga depende del volumen, y el tiempo de volumen no puede comprimirse más allá de los límites de la plataforma. ## Ejemplo de cronograma - ventana de 12 horas | Hora | Acción | Responsable | | --- | --- | --- | | T-2 | Aprobación Go, verificación de disponibilidad del equipo y decisores | Jefe de Proyecto | | T0 | Freeze en el sistema de origen, desconexión de integraciones salientes | Operaciones de TI | | T0+1 | Extracción de Delta y validación de recuentos en origen | Líder de Datos | | T0+2 | Carga de Delta según orden de dependencias | Migración | | T0+6 | Conciliación automática (reconciliation): recuentos, sumas, relaciones | QA | | T0+8 | Muestreo manual y aprobación de los propietarios del proceso | Negocio | | T0+9 | Punto de no retorno: decisión Go / Rollback | Comité Directivo | | T0+10 | Activación de integraciones, apertura de permisos de usuarios | Operaciones de TI | | T0+11 | Pruebas de humo (smoke tests) en procesos críticos | QA + Negocio | | T0+12 | Anuncio de apertura a usuarios, transición a hypercare | Comunicación | Dos principios en el cronograma: cada línea tiene un responsable y cada verificación tiene un umbral numérico. Una línea sin responsable no se ejecutará; una verificación sin umbral se resolverá mediante discusión. ## Conciliación (Reconciliation): Cuatro niveles ineludibles **Recuento** - Cuántos registros hay en el origen frente al destino, para cada entidad y rango de fechas. Detecta cargas parciales. **Suma** - Sumas de campos monetarios y numéricos. Detecta conversiones erróneas, truncamientos y reseteos silenciosos; un recuento correcto no los revelaría. **Relaciones** - Cuántos registros hijos por cada padre, y cuántos registros huérfanos. Detecta un orden de carga incorrecto y mapeo de claves roto. **Muestreo manual** - De 20 a 50 registros seleccionados previamente, incluyendo casos límite: un cliente con caracteres especiales, una oportunidad en moneda extranjera, un registro que fue fusionado. Este es el único nivel que detecta un error semántico —un dato que se cargó con éxito en el lugar equivocado. La dependencia entre la precisión de la conversión y la calidad del mapeo se explica en [Data Mapping para Migración](/es/insights/salesforce-data-mapping). ## Escenario: La migración que se detuvo a la octava hora Una empresa de distribución planificó una ventana de diez horas para un fin de semana. La carga se completó, los recuentos coincidieron exactamente, y el equipo se preparaba para abrir. Durante el muestreo manual, se descubrió que en seis de los 30 clientes examinados, las oportunidades abiertas estaban asignadas al propietario incorrecto —resultado de una tabla de mapeo de usuarios que no se había actualizado después de dos bajas y un cambio de rol. Los recuentos eran correctos. Las sumas eran correctas. Solo el muestreo lo detectó. El equipo no realizó un Rollback: identificó que se trataba de 1.400 registros que podían corregirse con una consulta, realizó una corrección específica dentro de la ventana y verificó nuevamente. La decisión fue posible porque el criterio No-Go se había definido previamente como "un error que no puede corregirse en las próximas dos horas" y no como "cualquier error". Un criterio bien redactado es lo que permite a un equipo exhausto tomar la decisión correcta a las tres de la mañana. ## Hypercare: Los 14 días posteriores La ventana de Cutover finaliza con la apertura a los usuarios, pero el riesgo persiste. Se requiere un equipo de apoyo con un único canal de contacto, un informe diario de las anomalías de integración y un seguimiento de los indicadores de calidad frente a una línea de base (baseline). Los incidentes se clasifican según su impacto comercial y no por quién alzó la voz más fuerte. La medición continua de la calidad después de la transición se describe en [Métricas de calidad de datos](/es/insights/salesforce-data-quality-metrics). ## Riesgos comunes y acciones de prevención | Riesgo | Cómo se manifiesta en la práctica | Acción preventiva | | --- | --- | --- | | Ventana única para todo el volumen | La carga excede el tiempo y la transición se pospone | División en tres olas | | Integración reactivada | Registros duplicados o actualizaciones contradictorias | Desconexión controlada y activación ordenada | | Conciliación superficial | Recuentos correctos y datos incorrectos | Cuatro niveles incluyendo muestreo manual | | Ausencia de criterios No-Go | Se avanza por inercia | Umbrales escritos antes de la ventana | | Mapeo de usuarios obsoleto | Propiedad incorrecta de registros | Actualización de la tabla de usuarios el día anterior | ## Cómo medir el éxito | Área | Qué se mide | Frecuencia de verificación | | --- | --- | --- | | Precisión de la conversión | Discrepancias de recuento, suma y relaciones | En cada ola y durante el Cutover | | Cumplimiento de plazos | Desviación de los tiempos del cronograma | En cada Rehearsal | | Estabilidad post-transición | Fallos de integración e incidentes P1 por día | Diariamente durante los 14 días | | Adopción | Inicios de sesión y operaciones frente al Baseline | Semanalmente durante el primer mes | El acompañamiento en la planificación y ejecución del Cutover se realiza en el marco del [servicio de integraciones y datos](/es/integrations-data). ## Checklist para Go/No-Go * ☐ Dos ensayos (rehearsals) completos con volumen de producción. * ☐ Cronograma por horas con responsable para cada línea. * ☐ Plan de Freeze acordado con el negocio. * ☐ Lista ordenada de integraciones a desconectar y activar. * ☐ Script de conciliación en cuatro niveles, lo más automatizado posible. * ☐ Muestra manual predefinida, incluyendo casos límite. * ☐ Tabla de mapeo de usuarios y propiedad actualizada. * ☐ Criterios No-Go escritos con umbrales numéricos. * ☐ Punto de no retorno y plan de Fix-Forward. * ☐ Equipo de Hypercare, canal de contacto y reporte diario. ## Recursos Profesionales * Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) * Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) * HPI Pro – Integraciones y Datos — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Preguntas y respuestas **¿Cuántas pruebas de ensayo (Rehearsal) son realmente necesarias?** Se requieren al menos dos ensayos completos, y el segundo debe realizarse con volumen de producción y bajo las mismas condiciones de temporización. El primer ensayo revela errores de contenido, mientras que el segundo identifica problemas de tiempo y secuencia, que son la causa principal del fracaso de una ventana de Cutover. Organizaciones con numerosas integraciones suelen realizar tres. **¿Cuánto tiempo se debe congelar el sistema de origen?** Lo mínimo indispensable, y de forma intencionada. Una ventana de "Freeze" prolongada genera resistencia empresarial y trabajo fuera del sistema. El enfoque común consiste en una carga histórica completa días antes de la migración, y solo un pequeño "Delta" durante la ventana de Cutover, que generalmente dura entre cuatro y doce horas. **¿Cómo se realiza una reconciliación de datos correcta?** En cuatro niveles: primero, el conteo de registros por entidad; segundo, la suma de campos monetarios y numéricos; tercero, la integridad de las relaciones padre-hijo; y cuarto, un muestreo manual de 20-50 registros preseleccionados, incluyendo casos excepcionales. Los tres primeros niveles son automatizados; el cuarto es crucial para detectar errores semánticos. **¿Cuándo se decide un "No-Go"?** La decisión de "No-Go" debe basarse en criterios preestablecidos antes de la ventana de Cutover, no en sensaciones en tiempo real: exceder un umbral de excepciones, fallo en la reconciliación financiera, incumplimiento de tiempos intermedios definidos o la ausencia de un tomador de decisiones disponible. Quienes no establecen criterios de "No-Go" con antelación casi siempre optarán por seguir adelante. **¿Es el Rollback realmente una opción viable?** Solo si se ha planificado minuciosamente. En la mayoría de los casos, un Rollback completo es posible únicamente dentro de la primera ventana, antes de que los usuarios generen nuevos datos. Por ello, se define un 'punto de no retorno' en una hora específica, y a partir de ahí, se transita a un plan de 'Fix-Forward' con un equipo claramente designado. --- ## Costo de Agentforce: Consumo, Licencias y el TCO de un Agente Empresarial URL: https://hpi.pro/es/insights/agentforce-cost-tco El costo de las licencias es la parte más fácil de calcular y, a menudo, no la más voluminosa. Esta guía desglosa el costo total de propiedad (TCO) real en cinco componentes: licencias, consumo, construcción, operación y mantenimiento de contenido. Además, presenta una fórmula de costo por tarea que permite comparar el agente con el costo de la atención humana, en lugar de depender únicamente de promesas. ## La respuesta breve La pregunta "¿cuánto cuesta Agentforce?" recibe una respuesta errónea cuando se traduce a un precio de licencia. El costo real se compone de cinco elementos: licencias, consumo en tiempo de ejecución, desarrollo inicial, operación continua y mantenimiento de contenido. En la mayoría de las implementaciones que hemos analizado, los tres últimos superan la suma de los dos primeros en el primer año. El indicador decisivo no es el costo mensual, sino el costo por tarea completada sin escalamiento. Es el único que puede compararse con el costo de atención actual, y también es el que revela si el problema radica en el precio o en la cantidad de intentos necesarios para su finalización. ## Los cinco componentes del Costo Total de Propiedad (TCO) | Componente | Qué incluye | Comportamiento a lo largo del tiempo | Señal de desviación | | --- | --- | --- | --- | | Licenciamiento | Licencias de plataforma y usuarios | Fijo, aumenta con la expansión | Licencias adquiridas antes de seleccionar el caso de uso | | Consumo | Operaciones en tiempo de ejecución según el modelo de precios | Varía según el volumen y la duración de la conversación | Consumo que aumentó sin incremento en las tareas completadas | | Desarrollo | Descubrimiento, acciones, fundamentación, pruebas | Una sola vez por cada caso de uso, disminuye con la experiencia | Alcance que se expande sin una decisión de negocio | | Operación | Monitoreo, revisión de fallas, correcciones, gestión de cambios | Constante mientras el agente esté activo | No hay propietario, por lo tanto, no hay costo registrado, lo que lleva a la falta de mantenimiento | | Mantenimiento de contenido | Actualización de Knowledge, archivo, control de validez | Constante según el número de áreas de conocimiento | Disminución gradual en la precisión de las respuestas | ## Costo por tarea: la fórmula que debe establecerse Se calcula el costo mensual total de los cinco componentes y se divide por el número de tareas completadas con éxito, es decir, aquellas que terminaron con el resultado deseado sin escalamiento a una persona. Este es el único número que se puede comparar con el costo de atención existente. La definición de "completada" es la decisión difícil y vinculante para el propietario del proceso. Una conversación en la que el cliente recibió una respuesta y volvió a contactar al día siguiente sobre el mismo tema no es una tarea completada. Una definición laxa crea cifras atractivas que no resisten el escrutinio. Es crucial comparar con una línea base (baseline) real. El costo de la atención humana incluye salario, sistemas, capacitación y tiempo de espera, no solo los minutos de la llamada. La comparación con un número parcial es la razón común por la que la justificación económica colapsa en la revisión trimestral. ## Qué encarece realmente el proceso El primer factor es una fundamentación (grounding) deficiente. Cuando el agente no encuentra una fuente precisa, lo intenta más, la conversación se alarga y el consumo aumenta, y al final la conversación se escala de todos modos. Mejorar el contenido suele ser una acción de ahorro mayor que cambiar un modelo. El segundo factor son los reintentos tras un fallo de integración. Cada intento cuenta, y cuando un sistema externo es inestable, el costo se multiplica sin ningún valor adicional. El tercer factor es un alcance (scope) amplio. Un agente que debe responder a todo consume más en cada conversación, porque revisa más fuentes y realiza más consideraciones. Un agente con un alcance más limitado cuesta menos y es más preciso. La relación entre la calidad de las fuentes de información y el costo se detalla en [Fundamentación (Grounding) y RAG en Agentforce](/es/insights/agentforce-grounding-rag). ## Controles presupuestarios que conviene establecer de antemano Un límite mensual definido para cada caso de uso, con una alerta antes de alcanzarlo. Sin un límite, el descubrimiento de la desviación llega con la factura. Desglose del costo por caso de uso y no solo a nivel de organización. Cuando hay tres agentes y solo un número total, es imposible saber cuál de ellos no es rentable para inhabilitarlo. Medición semanal del consumo en relación con las tareas completadas. Un aumento en el consumo simultáneo a la estabilidad en las tareas es una señal de alerta temprana: indica un deterioro en la calidad de las respuestas antes de que los usuarios se quejen. Cómo establecer el monitoreo que alimenta los controles se detalla en [Observabilidad para agentes de IA](/es/insights/agentforce-observability). ## Escenario: un piloto que parecía costoso y resultó ser económico Una empresa de software ejecutó un piloto de ocho semanas y recibió una factura de consumo superior a lo esperado. La primera reacción fue considerar la interrupción. El análisis mostró una imagen diferente: el 62% del consumo provenía de una categoría de preguntas en la que el agente no lograba encontrar una fuente y, por lo tanto, intentaba repetidamente antes de escalar. El tratamiento no fue técnico. Se redactaron once nuevos artículos de Knowledge para esa categoría y se definió un respaldo (fallback) que escalaba después del segundo intento en lugar de intentarlo hasta el final. El consumo mensual disminuyó significativamente y el número de tareas completadas en realidad aumentó. El costo por tarea, el único indicador examinado por el Director Financiero (CFO), mejoró varias veces, y el proyecto fue aprobado para su expansión. La conclusión: una factura alta suele ser un síntoma de una brecha en el contenido y no de un problema de precios. ## Cuándo el agente simplemente no es rentable Hay tres situaciones que conviene identificar temprano: volumen bajo, donde un proceso con solo unos pocos cientos de casos al mes no recuperará el costo operativo, incluso si es molesto; una variabilidad excesiva, donde casi cada caso es una excepción, la tasa de escalamiento permanecerá alta y, con ella, el costo duplicado; y la dependencia de un sistema externo inestable, donde el costo está influenciado por un factor fuera del control del proyecto. En estas situaciones, la respuesta correcta no es "no a la IA" sino "no a este proceso". Casi siempre existe un subproceso con mayor volumen que sí justifica la inversión. ## Riesgos y acciones preventivas | Riesgo | Cómo se manifiesta | Acción preventiva | | --- | --- | --- | | Licenciamiento previo al caso de uso | Licencias sin uso y presión para demostrar valor | Verificación de preparación y selección de procesos antes de la compra | | Falta de presupuesto para operaciones | Disminución de la calidad después del primer trimestre | Presupuesto anual para monitoreo y mantenimiento de contenido | | Medición solo a nivel de organización | Imposibilidad de identificar un agente no rentable | Desglose de costos por caso de uso | | Definición laxa de "completado" | Cifras atractivas que no resisten el escrutinio | Definición de éxito por el propietario del proceso de antemano | | Reintentos ilimitados | Consumo doble sin valor | Limitación de intentos y escalamiento temprano | ## Métricas económicas | Métrica | Definición | Frecuencia | | --- | --- | --- | | Costo por tarea completada | Costo total dividido por tareas sin escalamiento | Mensual | | Consumo por tarea | Unidades de consumo promedio por tarea | Semanal | | Tasa de completitud | Porcentaje de casos finalizados con el resultado deseado | Semanal | | Costo de operación fijo | Horas de monitoreo, correcciones y mantenimiento de contenido | Mensual | | Proporción con el costo de la línea base | Costo del agente versus costo del manejo actual | Trimestral | Cuando se requiere un modelo económico que resista el escrutinio interno antes de una decisión de inversión, el [servicio Agentforce e IA](/es/agentforce-ai) es el camino práctico a seguir. ## Lista de verificación para construir un modelo de costos - ☐ Los cinco componentes del TCO fueron valorados por separado - ☐ Se definió qué se considera una "tarea completada" por el dueño del proceso - ☐ Se midió una línea base del costo de atención existente - ☐ Se estableció un límite de consumo mensual para cada caso de uso - ☐ Existe un desglose de costos a nivel de caso de uso y no solo de organización - ☐ Se presupuestó el monitoreo y el mantenimiento de contenido para el primer año - ☐ Se definió un número máximo de intentos antes de la escalada - ☐ Se estableció un umbral económico a partir del cual el agente se suspende o se cierra ### Preguntas y respuestas **¿Qué encarece a un agente más de lo esperado?** Hay tres factores principales: conversaciones más largas de lo previsto debido a un 'grounding' deficiente, repeticiones tras fallos y el mantenimiento de contenido, un costo que a menudo no se presupuesta. El costo de consumo no suele provenir del precio unitario, sino del número de unidades consumidas por cada tarea completada con éxito. **¿Cómo se compara el costo de un agente con el de un representante humano?** Se calcula el costo por tarea completada sin escalamiento, no el costo por llamada. Si el agente gestiona el ochenta por ciento de una conversación y escala, el ahorro es en tiempo, no en atención completa. Una comparación justa debe incluir también el tiempo del representante necesario para completar la interacción después de una escalación. **¿Disminuye el costo operativo con el tiempo?** El costo de construcción puede disminuir, pero el costo operativo no necesariamente. La monitorización, la revisión de llamadas fallidas y la actualización de contenido son costos fijos mientras el agente esté activo. Las organizaciones que presupuestan solo el proyecto inicial y no el primer año de operación suelen descubrir las discrepancias en el segundo trimestre. **¿Cuánto es razonable asignar al mantenimiento de contenido?** En la práctica, esta partida equivale a un puesto de tiempo parcial constante para un dominio de conocimiento activo. Incluye a quienes actualizan artículos, archivan contradicciones y verifican la validez. Sin esta asignación, la calidad de las respuestas disminuye gradualmente, lo que conduce a la necesidad de una reinversión más costosa. **¿Cuál es la conclusión correcta para no implementar un agente?** Cuando el costo por tarea es superior al valor que genera, incluso después de la optimización, o cuando el volumen es demasiado bajo para justificar la operación continua. Un proceso con solo unos pocos cientos de casos al mes es casi siempre más barato de resolver con automatización clásica o mejorando el proceso actual. --- ## Seguridad de Agentforce y el Modelo de Responsabilidad Compartida URL: https://hpi.pro/es/insights/agentforce-security-shared-responsibility La plataforma asegura la infraestructura; la organización es responsable de lo que el agente puede ver y hacer. Esta guía delimita la línea divisoria en la práctica –datos, permisos, instrucciones, acciones y monitoreo– y muestra qué nuevos riesgos surgen con un agente que no tienen un equivalente en un sistema CRM tradicional. ## La respuesta breve El modelo de responsabilidad compartida no es solo un documento formal; es la línea que determina quién es responsable cuando algo sale mal. La regla simple: la plataforma es responsable de la seguridad del servicio en sí, y la organización es responsable de cada decisión sobre lo que el agente ve, lo que está autorizado a hacer y a quién responde. El mayor riesgo no es una vulneración de la plataforma. Es un agente con demasiados permisos que expone información a una parte indebida o realiza una acción que no debería haber ejecutado —dos fallos que son enteramente responsabilidad de la organización. ## Reparto efectivo de responsabilidades | Área | Responsabilidad de la plataforma | Responsabilidad de la organización | | --- | --- | --- | | Infraestructura | Cifrado, aislamiento, disponibilidad, gestión de vulnerabilidades | Selección del entorno y configuración de red aprobada | | Datos | Almacenamiento y procesamiento según el acuerdo | Qué se indexa y qué se clasifica como sensible | | Identidad y permisos | Mecanismos de autorización de la plataforma | Definición de quién puede ver y hacer qué | | Comportamiento del agente | Capacidades del modelo y herramientas de control | Instrucciones, límites, puntos de aprobación | | Acciones | Infraestructura de ejecución | Autorización de cada Action y validación dentro de esta | | Monitoreo y auditoría | Registros (logs) de la plataforma | Registro de auditoría (audit trail) de negocio, muestreo y revisión | ## Los nuevos riesgos que no existían en un CRM convencional El primero es la exposición a través de la recuperación de información. En un sistema regular, el usuario ve lo que la pantalla le muestra; en un agente, un texto libre puede resultar en la extracción de un fragmento de un documento que no estaba destinado a él. Por lo tanto, la recuperación debe ejecutarse en el contexto de los permisos del usuario, y no en el contexto de una cuenta de integración amplia. El segundo es el Prompt Injection. El contenido que el agente lee —un correo electrónico de un cliente, un campo de descripción, un documento adjunto— puede contener instrucciones que intentan alterar su comportamiento. No es posible protegerse de esto solo con formulaciones; la protección es arquitectónica. El tercero es la fuga de contenido interno a un canal externo. Un artículo escrito para representantes con márgenes de descuento o argumentos de objeción no debería llegar al cliente, y la separación debe basarse en una lista de permitidos (whitelist), no en una lista de bloqueados (blacklist). El cuarto es la ampliación silenciosa de la autoridad: la adición de una Action o un permiso para resolver un problema puntual, sin pasar por el proceso de aprobación. ## Los cinco controles que soportan la mayor parte del peso Recuperación de información en el contexto del usuario. Este es el único control que, si falla, hace inútiles todos los demás. Permiso separado para cada Action, según el principio de privilegio mínimo. Un agente que recibe un perfil único y amplio impide cualquier control futuro. Validación dentro de la operación y no en las instrucciones. Una instrucción es una dirección; una validación es un control. Una operación que realiza un reembolso debe verificar el monto, la elegibilidad y la autorización en su código, incluso si las instrucciones le dicen al agente que no la ejecute en ciertos casos. Aprobación humana para una acción irreversible. Este es el control que convierte una posible falla en un incidente que se detiene a tiempo. Registro de auditoría (audit trail) que vincula usuario, acción, origen y aprobador. Sin él, no hay respuesta a la pregunta de auditoría "¿con base en qué hizo esto el agente?". Los principios generales del modelo de permisos en Salesforce se detallan en el [modelo de permisos de Salesforce](/es/insights/salesforce-permission-model). ## Qué verificar antes de entrar en producción (Go Live) Pruebas de Persona: Se ejecutan diez a veinte preguntas con diferentes identidades —representante, gerente, usuario limitado, cliente externo— y se comparan las respuestas. Cualquier discrepancia que no se explique por un permiso es un hallazgo. Red Teaming de contenido: Intentos deliberados de extraer información no autorizada, ejecutar una acción prohibida y eludir la escalada. Los escenarios se escriben una vez y se guardan para su ejecución repetida en cada versión. Prueba del flujo de acciones: Para cada Action, se verifica que la validación funcione incluso cuando se activa directamente, no solo a través del agente. Verificación de retención de datos: Qué se guarda, por cuánto tiempo, y quién puede acceder a los logs que contienen el contenido de la conversación con datos del cliente. Cómo estas pruebas se integran en un marco de pruebas más amplio se explica en [pruebas de Agentforce](/es/insights/agentforce-testing-scorers). ## Escenario: Hallazgo en una prueba de Persona Una empresa de salud preparó un agente interno para responder preguntas sobre procedimientos. En una prueba de Persona antes del lanzamiento, se descubrió que un usuario con un rol administrativo recibió una respuesta basada en un procedimiento clasificado solo para el personal médico. La razón no fue un error en el agente. El índice fue construido por una cuenta de integración con acceso amplio, y la recuperación no se restringió según los permisos del usuario. La misma exposición existía potencialmente en cualquier pregunta relacionada con esa área. La corrección incluyó dos acciones: trasladar la recuperación al contexto del usuario y marcar explícitamente los documentos clasificados para que no se incluyeran en el índice general. La prueba se agregó como un escenario fijo que se ejecuta antes de cada lanzamiento de versión. ## Riesgos y acciones preventivas | Riesgo | Cómo se detecta | Acción preventiva | | --- | --- | --- | | Recuperación con permisos amplios | Exposición de un documento clasificado en una respuesta inocente | Recuperación en el contexto del usuario y pruebas de Persona | | Prompt Injection | Acción ejecutada debido a contenido externo | Permisos restringidos, validación en la acción, aprobación humana | | Mezcla de contenido interno y externo | Una formulación interna llega al cliente | Lista de permitidos (whitelist) en canal externo | | Expansión silenciosa de la autoridad | El agente hace más de lo aprobado | Etiquetado de cambios significativos y reaprobación | | Sin Audit trail | No hay respuesta para la auditoría | Registro de usuario, acción, origen y aprobador | ## Métricas de seguridad | Métrica | Qué revela | Frecuencia | | --- | --- | --- | | Hallazgos de Persona | Brechas de permisos en la recuperación | En cada versión | | Resultados de Red Teaming | Resistencia a intentos de elusión | En cada versión | | Acciones sensibles sin aprobación | Fallos en el proceso de control | Mensual | | Cambios que eludieron la aprobación | Disciplina del proceso de cambio | Trimestral | | Cobertura del Audit trail | Porcentaje de acciones sensibles completamente documentadas | Trimestral | El marco de aprobaciones dentro del cual se aplican los controles se detalla en [Gobernanza de IA para Agentforce](/es/insights/agentforce-ai-governance). Cuando se requiere acompañamiento en la definición del modelo de responsabilidades y en las pruebas previas al lanzamiento, el [servicio Agentforce e IA](/es/agentforce-ai) es el camino práctico a seguir. ## Lista de verificación de seguridad previa al Go Live - ☐ El documento de reparto de responsabilidades ha sido redactado y aprobado. - ☐ Las condiciones de uso de los datos frente al modelo están documentadas por escrito. - ☐ La recuperación de información se ejecuta en el contexto de los permisos del usuario. - ☐ Se han realizado pruebas de Persona para cada nivel de permiso. - ☐ Cada Action tiene un permiso separado y una validación interna. - ☐ Las acciones irreversibles requieren aprobación humana. - ☐ En el canal externo, funciona una lista de permitidos (whitelist) para el contenido. - ☐ Se han escrito y ejecutado escenarios de Red Teaming de contenido. - ☐ El Audit trail vincula usuario, acción, origen y aprobador. - ☐ La política de retención de logs y contenido de conversación ha sido aprobada. ### Preguntas y respuestas **¿Qué cubre y qué no cubre realmente la plataforma?** La plataforma cubre la infraestructura, el cifrado, el aislamiento de entornos y los compromisos sobre el uso de datos frente al modelo. No determina quién puede ver qué dentro de la organización, qué acciones está autorizado a realizar el agente, qué entra en la base de conocimientos y quién monitorea. Estas son las decisiones que generan la mayor parte del riesgo. **¿Qué es realmente la Inyección de Prompts en un contexto empresarial?** Es un contenido que el agente lee –un correo electrónico entrante, un campo de descripción, un documento cargado– que contiene instrucciones que intentan alterar su comportamiento. La protección no reside en formular mejores instrucciones, sino en los controles: permisos de acción restringidos, validación dentro de la acción y autorización humana antes de una acción sensible. **¿Se utilizan los datos de la organización para entrenar modelos?** La respuesta depende del acuerdo y la configuración, por lo que debe documentarse por escrito antes de la implementación (Go Live), no se debe confiar en suposiciones. Esta es una de las primeras preguntas que hará una auditoría interna, y la respuesta debe estar respaldada por un documento y no por la memoria de quien participó en la reunión de ventas. **¿Es necesaria una prueba de penetración para el agente?** Sí, pero de un tipo diferente. Además de las pruebas técnicas regulares, se requiere un equipo de Red Teaming de contenido: intentos de extraer información no autorizada, provocar acciones no permitidas y eludir las reglas de escalada. Estas pruebas se escriben como escenarios y se guardan para su ejecución repetida en cada versión. **¿Qué se requiere para la auditoría y la regulación?** Un registro de auditoría (audit trail) que muestre para cada acción sensible quién es el usuario, qué hizo el agente, en base a qué fuente y quién lo aprobó. Además, un registro actualizado de agentes y un documento que defina la distribución de responsabilidades. Estos tres puntos cubren la mayoría de las preguntas de auditoría. --- ## Pruebas de Agentforce: Sets de Prueba, Scorers y Escenarios Extremos URL: https://hpi.pro/es/insights/agentforce-testing-scorers Probar un Agente no es como probar un Flow: la misma pregunta puede tener dos respuestas válidas. Esta guía detalla cómo construir un set de prueba que represente la realidad, qué dimensiones medir de forma independiente, cuándo la automatización es suficiente y cuándo se necesita juicio humano, y qué umbral permite el lanzamiento. ## La respuesta corta La prueba de agentes no es una prueba de software clásica. No existe una única respuesta correcta, la misma pregunta puede formularse de veinte maneras y, a menudo, un fallo no es un error, sino una respuesta razonable a la que le falta una condición fundamental. Por lo tanto, se necesita un método diferente: un conjunto de casos representativos, criterios de aceptación en lugar de respuestas exactas y una medición en varias dimensiones de forma independiente. La separación de las dimensiones es lo que hace que una prueba sea útil. "La respuesta no es buena" no es un hallazgo; "El tema se identificó correctamente, pero no se recuperó la fuente relevante" es un hallazgo que se puede corregir. ## Las cuatro dimensiones de la medición | Dimensión | Qué se evalúa | Cómo se mide | Quién corrige | |---|---|---|---| | Identificación del tema | Si el agente entendió el asunto | Comparación con el tema esperado | Quien escribe las instrucciones y descripciones de las Actions | | Recuperación | Si se recuperó la fuente correcta | Si el fragmento esperado apareció en la recuperación | El propietario del contenido y el etiquetado | | Respuesta | Si el contenido es correcto y completo | Criterios de aceptación: obligatorio, prohibido, citación | Contenido e instrucciones | | Proceso | Si se realizó la acción correcta y se mantuvo la escalada | Verificación de la secuencia de acciones y la decisión de detención | Actions y reglas de escalada | ## Construcción de un conjunto de pruebas representativo El material de origen son consultas reales y no escenarios escritos en una reunión. Transcripciones, correos electrónicos y descripciones de Case contienen lo que falta en los escenarios inventados: errores ortográficos, formulación parcial, dos preguntas en una sola frase e información incompleta. Composición recomendada: aproximadamente la mitad de los casos son comunes, una cuarta parte son casos extremos (excepciones, condiciones de elegibilidad límite, preguntas multifacéticas) y una cuarta parte son casos que deberían fallar intencionadamente: solicitudes fuera de Scope, intentos de obtener información no autorizada y un cliente que solicita ser atendido por una persona. Para cada caso, se definen cuatro campos: la consulta tal como se formuló, el tema esperado, el criterio de aceptación para la respuesta y el comportamiento de proceso esperado, incluyendo "debe escalar" como un resultado válido y no como un fallo. ## Criterio de aceptación en lugar de respuesta precisa Este es el principio que permite realizar la prueba en absoluto. En lugar de escribir la respuesta correcta, se redactan tres listas cortas: hechos que deben aparecer, afirmaciones que no deben aparecer y la fuente que debe citarse. El ejemplo típico: una pregunta sobre la elegibilidad para un reembolso. Es obligatorio que aparezca el período de tiempo y las condiciones de estado del producto; no debe aparecer ningún compromiso de reembolso; la fuente debe ser el procedimiento de devolución en su versión vigente. Dos formulaciones completamente diferentes pueden pasar la prueba. Esta es también la forma que permite una clasificación automática fiable: la verificación de la presencia de un hecho definido es mucho más precisa que pedirle a un modelo que evalúe la "calidad". ## Automatización versus juicio humano Los Scorers automáticos son adecuados para la identificación de temas, la presencia de una cita válida, el cumplimiento del formato, la longitud y la identificación de afirmaciones prohibidas. Estos se ejecutan en todo el conjunto en cada versión, a bajo costo. El juicio humano es necesario para la precisión del contenido en áreas sensibles y para la formulación de cara al cliente. No es necesario todo el conjunto, sino una muestra constante de veinte a treinta casos en cada versión, seleccionada para incluir los casos extremos. El riesgo de depender completamente de un evaluador automático es el sesgo hacia respuestas que suenan autoritarias. Una respuesta convincente que omite una condición de elegibilidad pasará automáticamente y será detectada por un evaluador humano. La relación entre los resultados de las pruebas y la supervisión en producción se explica en [Observabilidad para Agentforce](/es/insights/agentforce-observability). ## Casos límite que siempre deben incluirse Una pregunta con dos temas en una frase. Una consulta a la que le falta información esencial: si el agente pregunta por una aclaración o adivina. Un cliente que formula la pregunta en un tono negativo: si se activa la escalada. Una solicitud de una acción que no está permitida para ese usuario. Una pregunta sobre un producto que no existe: si el agente lo admite o lo inventa. Contenido que contiene una instrucción disfrazada que intenta cambiar el comportamiento. Estos seis cubren la mayoría de los fallos que hemos visto llegar a producción, y son económicos de ejecutar repetidamente. Los escenarios de evasión se relacionan con las pruebas de seguridad detalladas en [Seguridad en Agentforce y responsabilidad compartida](/es/insights/agentforce-security-shared-responsibility). ## Umbrales para la puesta en marcha El umbral no es un número uniforme, sino que se deriva del canal y del riesgo. Un agente interno para la asistencia a un representante puede lanzarse con un nivel de precisión más bajo, porque el representante filtra. Un agente que interactúa con los clientes requiere un umbral significativamente más alto y, sobre todo, cero fallos en las categorías críticas. La regla más importante que el número: cero fallos en las categorías obligatorias. La exposición de información no autorizada, una acción irreversible sin aprobación, la no escalada de una solicitud explícita de una persona, cualquiera de estos bloquea la puesta en marcha, independientemente de la puntuación general. ## Escenario: un conjunto pequeño que evitó un lanzamiento deficiente Una empresa de turismo planeaba lanzar un agente de atención al cliente después de que el piloto interno mostrara un buen rendimiento. El conjunto de pruebas construido incluía 90 casos, de los cuales 22 eran casos extremos de consultas reales. La ejecución reveló un patrón: en las preguntas sobre cambios de fecha con condiciones de cancelación especiales, el agente dio una respuesta esencialmente correcta, pero omitió las tarifas de cambio en un tercio de los casos. En las pruebas internas no se detectó porque los representantes sabían cómo añadir la información por sí mismos. El lanzamiento se pospuso tres semanas. La corrección se hizo en el contenido: las condiciones de facturación se trasladaron a una sección separada y marcada en cada artículo relevante, y se añadió un criterio de aceptación explícito. La nueva ejecución pasó la prueba y el lanzamiento se realizó sin incidentes. ## Riesgos y acciones preventivas | Riesgo | Cómo se detecta | Acción preventiva | |---|---|---| | Conjunto de pruebas inventadas | Todo pasa en las pruebas y falla en producción | Casos a partir de consultas reales | | Prueba solo de la puntuación total | Se desconoce qué corregir | Medición separada de las cuatro dimensiones | | Dependencia de un evaluador automático | Las respuestas convincentes con omisiones pasan | Muestra humana constante en cada versión | | No hay casos que deban fallar | El agente responde a lo que no debe | Un cuarto del conjunto: fuera de Scope y evasión | | No hay regresión | Una pequeña corrección rompe otro escenario | Ejecutar el conjunto antes de cada lanzamiento de versión | ## Métricas de prueba | Métrica | Definición | Umbral principal | |---|---|---| | Topic accuracy | Porcentaje de identificación correcta del tema | Alto; un fallo aquí rompe todo lo demás | | Retrieval hit rate | Porcentaje de casos en los que se recuperó la fuente esperada | Alto en el canal del cliente | | Answer acceptance | Porcentaje de respuestas que cumplieron con el criterio de aceptación | Derivado del canal y del riesgo | | Process compliance | Porcentaje de casos en los que se ejecutó la acción o escalada correcta | Cero desviaciones en categorías obligatorias | | Regression delta | Cambio en las puntuaciones respecto a la versión anterior | Sin disminución inexplicable | Cuando se requiere asistencia en la construcción de un conjunto de pruebas y la definición de umbrales de puesta en marcha, el [servicio de Agentforce e IA](/es/agentforce-ai) es el camino práctico a seguir. ## Lista de verificación para pruebas * ☐ El conjunto de pruebas se construyó a partir de consultas reales * ☐ La composición incluye casos comunes, casos límite y casos que deben fallar * ☐ Cada caso tiene un criterio de aceptación: obligatorio, prohibido, fuente * ☐ La medición se divide en tema, recuperación, respuesta y proceso * ☐ Los Scorers automáticos se ejecutan en todo el conjunto * ☐ Se prueba una muestra humana constante en cada versión * ☐ Se incluyeron escenarios de evasión e instrucciones disfrazadas * ☐ Se definieron categorías obligatorias con tolerancia cero * ☐ El conjunto se ejecuta como regresión antes de cada lanzamiento de versión * ☐ Los resultados de las pruebas se documentan y comparan con la versión anterior ### Preguntas y respuestas **¿Cuántos casos debe tener un set de prueba?** Entre 50 y 150 casos son suficientes para una primera versión, siempre y cuando sean representativos. Un set de 500 casos redactados perfectamente es menos útil que uno de 80 que incluya errores ortográficos, preguntas ambiguas, solicitudes fuera de alcance y tentativas de evasión. **¿De dónde se obtienen casos de prueba reales?** De interacciones previamente recibidas: transcripciones de llamadas, correos electrónicos, descripciones de casos. Los casos escritos por el equipo tienden a estar bien formulados y, por lo tanto, pueden ser engañosos. La forma más rápida es tomar los últimos doscientos contactos y filtrar los redundantes. **¿Se puede confiar en un modelo que califica respuestas automáticamente?** Para algunas dimensiones, sí: identificación de tema, presencia de citas, cumplimiento de formato y políticas. Para la precisión del contenido en áreas sensibles, se requiere muestreo humano, ya que un calificador automático tiende a aprobar respuestas que suenan correctas. La combinación habitual es: automatización para todo, juicio humano para una muestra. **¿Qué se considera un fallo cuando hay varias respuestas correctas?** Se define un criterio de aceptación en lugar de una respuesta exacta: qué hechos deben aparecer, cuáles están prohibidos y qué fuente debe ser citada. De esta manera, dos formulaciones diferentes pueden ser válidas, y una respuesta que omite una condición de elegibilidad falla, incluso si está bien escrita. **¿Cada cuánto tiempo se ejecuta el set?** Antes de cada lanzamiento de versión, y también de forma regular en producción sobre una muestra. Un cambio que parece simple, como una actualización de instrucciones, la adición de un artículo o una modificación de acción, puede afectar el comportamiento en otros escenarios, y la regresión es la única forma de detectarlo antes que los usuarios. --- ## Observabilidad para Agentforce: Cómo medir, analizar y mejorar un agente URL: https://hpi.pro/es/insights/agentforce-observability Un agente sin monitoreo es una caja negra que nadie puede defender en una reunión ejecutiva. Esta guía desglosa la capa de monitoreo en tres niveles (una conversación individual, tendencias y resultados de negocio), explica qué datos deben aparecer en un Trace y cómo transformar las conversaciones fallidas en una cola de trabajo semanal, en lugar de un informe que nadie lee. ## La respuesta corta La monitorización de un agente difiere de la monitorización de un sistema convencional: el agente rara vez "cae". Permanece activo, pero su rendimiento disminuye. Por ello, las métricas clásicas de disponibilidad y errores no son suficientes; se requiere una capa que evalúe la calidad de sus decisiones, no solo su operatividad técnica. Una estructura práctica de monitorización comprende tres niveles: un **Trace** para explicar interacciones individuales, **Tendencias Semanales** para identificar deterioros, y una **Métrica de Resultado de Negocio** que justifique la continuidad de la operación. Cada nivel responde a una pregunta diferente y está dirigido a una audiencia específica. ## Tres niveles de monitorización | Nivel | Pregunta que responde | Audiencia | Frecuencia | | --- | --- | --- | --- | | Trace | ¿Por qué esta interacción terminó así? | Equipo técnico y analistas | Según necesidad | | Tendencia | ¿Qué está cambiando para bien o para mal? | Propietario del proceso y administrador de plataforma | Semanal | | Resultado | ¿El agente justifica su existencia? | Dirección y Patrocinador | Mensual y trimestral | ## Nivel 1: Componentes esenciales de un Trace Un Trace útil permite reconstruir una decisión sin necesidad de consultar a nadie. Consta de siete elementos: la consulta formulada, el tema identificado, los segmentos de conocimiento recuperados, las acciones ejecutadas con sus parámetros, el resultado de cada acción, los puntos de aprobación y su decisión, y el motivo de la finalización. El componente más frecuentemente olvidado son los segmentos de conocimiento recuperados. Sin ellos, es imposible distinguir entre dos fallos completamente diferentes: que el agente no encontrara la información, o que la encontrara y la usara incorrectamente. El primer caso se aborda con el contenido, el segundo con las instrucciones; una gestión incorrecta ha desperdiciado semanas en cada organización que hemos observado. También es crucial vincular el Trace a un registro de negocio: un Case, Order u Opportunity. Sin esta vinculación, no es posible verificar si la interacción condujo finalmente a un resultado exitoso o a una nueva consulta. ## Nivel 2: Tendencias recomendadas para seguir Cinco métricas son suficientes para la mayoría de las implementaciones: tasa de finalización sin escalada, tasa de segundas consultas dentro de una semana, porcentaje de respuestas con fuente válida, tasa de fallos de acción, y consumo en relación con las tareas completadas. La lectura debe realizarse en pares. Una alta contención con una alta tasa de segundas consultas no representa éxito. Un consumo que aumenta mientras las tareas se mantienen estables significa que el agente trabaja más intensamente para el mismo resultado, una señal temprana de deterioro del contenido. Las alertas automáticas deben configurarse sobre cambios relativos, no sobre valores absolutos: un salto en la tasa de escalada, una disminución en el porcentaje de fuentes válidas, un aumento en los fallos de acción con un sistema externo específico. La relación entre estas métricas y los costos se detalla en [Costo de Agentforce y TCO](/es/insights/agentforce-cost-tco). ## Nivel 3: Resultado de negocio Este nivel es determinante en la revisión trimestral. Incluye dos cifras: qué ha cambiado en la métrica del proceso preestablecida (tiempo de manejo, abandono, volumen de consultas al agente) y cuál es el costo de la tarea completada frente a la línea base. Es fundamental establecer las definiciones de antemano y no modificarlas una vez que se observan los resultados. Cambiar la definición de "éxito" a mitad de camino es lo que más socava la confianza de la dirección en los datos, incluso cuando el cambio esté justificado. ## Del análisis a la cola de mejora El informe semanal no es el producto final. El producto final es una cola de trabajo. La práctica efectiva es la siguiente: muestreo de veinte interacciones fallidas o escaladas, clasificación según la causa raíz (brecha de contenido, etiquetado incorrecto, instrucción ambigua, fallo de acción o solicitud fuera de alcance), y apertura de un ítem de trabajo solo para la categoría más grande. La regla para evitar desviaciones es: abordar una causa raíz por semana. Las organizaciones que intentan corregir cinco simultáneamente al final no saben qué mejoró la métrica y qué la empeoró. Las brechas de contenido identificadas aquí son una entrada directa a la lista de redacción; el proceso se detalla en [Gestión del Conocimiento para Agentforce](/es/insights/agentforce-knowledge-readiness). ## Escenario: Un declive silencioso detectado a tiempo Una compañía de servicios financieros implementó un agente interno que funcionó de manera estable durante cuatro meses. En la decimoquinta semana, la tasa de escalada aumentó gradualmente sin quejas; los agentes simplemente complementaban el proceso por sí mismos. La alerta configurada para un aumento relativo en la escalada inició una investigación. El muestreo de Traces reveló que, en la mitad de los nuevos casos, no se recuperó ningún segmento relevante. La razón: un cambio en la política de producto llevó al archivado automático de once artículos de conocimiento, y no se redactaron alternativas. La corrección tomó dos días y no requirió modificaciones en el agente. Sin la capa de monitorización, la brecha se habría descubierto solo cuando un gerente preguntara por qué el tiempo promedio de manejo había aumentado, probablemente después de un trimestre. ## Riesgos y acciones preventivas | Riesgo | Manifestación | Acción preventiva | | --- | --- | --- | | Monitorización solo técnica | Todo en verde, pero respuestas de baja calidad | Métricas de calidad y escalada junto a métricas de disponibilidad | | Trace sin segmentos de recuperación | Meses de conjeturas entre contenido y modelo | Registro obligatorio de los segmentos recuperados | | Informe sin cola de trabajo | Datos presentados que no generan cambios | Muestreo semanal y un ítem de trabajo para una causa raíz | | Cambio de definiciones a mitad de proceso | Pérdida de confianza en los datos | Establecer previamente las definiciones de éxito | | Sin vinculación a registro de negocio | Imposibilidad de identificar nuevas consultas | Vincular Trace a Case u Order | ## Tabla de métricas recomendadas | Métrica | Definición | Umbral de alerta | | --- | --- | --- | | Tasa de finalización | Finalización sin escalada y sin nuevas consultas | Disminución relativa significativa semana a semana | | Tasa de escalada | Porcentaje de transferencias a un agente humano | Aumento relativo sostenido | | Fuente válida | Porcentaje de respuestas con cita existente y vigente | Caída por debajo de un umbral preestablecido | | Fallos de acción | Porcentaje de operaciones fallidas según sistema de destino | Aumento de fallos con un destino específico | | Consumo por tarea | Unidades de consumo por tarea completada | Aumento sin incremento en el número de tareas | Si necesita acompañamiento en la implementación de una capa de monitorización y un proceso de mejora semanal, el [Servicio Agentforce e IA](/es/agentforce-ai) es el camino práctico a seguir. ## Checklist para la implementación de la observabilidad - ☐ El Trace registra la consulta, el tema, los segmentos recuperados, las acciones y el resultado. - ☐ Cada Trace está vinculado a un registro de negocio. - ☐ La política de retención distingue entre metadatos y contenido de la conversación. - ☐ Se han seleccionado entre cinco y siete métricas de tendencia, máximo. - ☐ Se han configurado alertas sobre cambios relativos, no sobre valores absolutos. - ☐ Existe una rutina de muestreo semanal de interacciones fallidas. - ☐ Se ha definido una taxonomía de causas raíz de fallos. - ☐ El propietario del proceso de negocio participa en la revisión semanal. - ☐ Las definiciones de éxito se han establecido antes del inicio de la medición. ### Preguntas y respuestas **¿Qué debe incluir obligatoriamente el Trace de una conversación?** La solicitud tal como fue formulada, el tema detectado, los extractos realmente recuperados, las acciones ejecutadas y sus parámetros, el resultado de cada acción, los puntos de aprobación humana y su decisión, y el motivo de la finalización o escalada. Sin los extractos recuperados, es imposible distinguir entre un problema de contenido y un problema de modelo. **¿Cuánto tiempo se deben conservar los Traces?** El tiempo suficiente para investigar una tendencia trimestral, pero siempre de acuerdo con la política de retención de datos y la regulación. El contenido de la conversación con datos del cliente generalmente se retiene por un período más corto que los metadatos, por lo que es habitual separar: métricas y metadatos a largo plazo, contenido completo a corto plazo. **¿Es necesario un software de monitoreo externo?** No al principio. Un dashboard interno con cinco a siete métricas y una cola de conversaciones fallidas es suficiente para el primer año. Una herramienta externa se justifica cuando hay varios agentes, múltiples canales y la necesidad de cruzar datos con otros sistemas de monitoreo en la organización. **¿Cómo se determina si una disminución en la calidad se debe al modelo o al contenido?** Se observa la etapa de recuperación en el Trace. Si no se recupera el fragmento correcto, es un problema de contenido o etiquetado. Si el fragmento correcto se recupera y la respuesta aún es incorrecta, el problema está en las instrucciones o en la formulación. Esta distinción ahorra semanas de conjeturas. **¿Quién debe revisar los datos en la práctica?** El propietario del proceso de negocio de forma semanal, junto con el gerente de la plataforma. El monitoreo que queda solo en el equipo técnico identifica fallas, pero no detecta respuestas que son técnicamente correctas y perjudiciales para el negocio, que es el tipo de falla más común. --- ## Build o Buy en Agentforce: Acciones listas, Flow, Apex y APIs URL: https://hpi.pro/es/insights/agentforce-build-vs-buy-actions Cada acción que realiza un agente puede implementarse de cuatro maneras, y la diferencia entre ellas no es solo técnica: concierne a quién la mantendrá, cómo se prueba y cuánto tiempo tomará cambiarla. Esta guía presenta un orden de selección claro, el costo de mantenimiento de cada opción y los casos en que Apex es la elección correcta a pesar del costo. ## La respuesta resumida Las acciones son el punto en el que un agente deja de hablar y comienza a actuar, concentrando la mayor parte del riesgo y del costo de mantenimiento. Existen cuatro métodos de implementación: acciones estándar, Flow, Apex y servicios externos a través de una API. La elección entre ellos no es una cuestión de capacidad —casi cualquier acción es posible en todos ellos—, sino de quién lo mantendrá, con qué rapidez se puede modificar y cómo se valida. El orden de elección recomendado es de arriba a abajo: comenzar con una acción estándar, pasar a Flow cuando se requiera lógica de negocio, a Apex cuando la complejidad sea significativa y a Servicios Externos cuando la verdad resida fuera de Salesforce. Cada descenso en esta escala aumenta el costo de mantenimiento y, por lo tanto, requiere una justificación. ## Tabla de decisión | Implementación | Cuándo es adecuada | Quién la mantiene | Costo de la opción | | --- | --- | --- | --- | | Acción Estándar | Recuperación, actualización de campos, apertura de un caso, resumen de un registro | Administrador de plataforma | Flexibilidad limitada para reglas de negocio | | Flow | Reglas de negocio cambiantes, múltiples pasos, validación | Administrador o propietario del proceso | Rendimiento en alto volumen, manejo limitado de errores | | Apex | Lógica compleja, procesamiento masivo, control de errores | Solo desarrollador | Cada cambio requiere un ciclo de despliegue y pruebas | | Servicios Externos / API | La fuente de la verdad está fuera de Salesforce | Equipo de integración | Dependencia de la disponibilidad, la latencia y las versiones de terceros | ## La primera regla: descripción antes de la implementación Antes de elegir una tecnología, se debe redactar la descripción de la acción. Esto puede parecer un procedimiento, pero es el elemento que determina si el agente ejecutará la acción correcta. El agente no lee el código: lee la descripción y toma una decisión en consecuencia. Una buena descripción incluye tres partes: qué hace la acción, en qué situaciones usarla y, explícitamente, en qué situaciones no hacerlo. La tercera parte es la que a menudo se olvida y es la que evita que el agente active una acción de crédito cuando el cliente solo preguntó sobre la política de créditos. Los parámetros deben ser mínimos y de tipo definido. Un parámetro de texto libre donde el agente debe ingresar un valor de una lista cerrada es una invitación a errores; una lista de valores definidos lo resuelve sin lógica adicional. ## Cuándo Flow y cuándo Apex Flow es la opción predeterminada para las reglas de negocio porque es visual y permite al propietario del proceso entender lo que sucede. En el caso de los agentes, una ventaja adicional es la velocidad de corrección: si se descubre que la acción no verifica una condición de elegibilidad, se puede corregir el mismo día. Apex se justifica en cuatro situaciones: lógica con muchas ramificaciones que hace que Flow sea ilegible, procesamiento de grandes volúmenes en una sola lectura, la necesidad de un control preciso en el manejo de errores y transacciones, y una integración que requiere un procesamiento complejo de respuestas. Fuera de estas situaciones, Apex principalmente encarece el siguiente cambio. La elección también está relacionada con la deuda técnica existente. Una organización que ya arrastra miles de líneas de Apex sin pruebas debe pensarlo dos veces antes de añadir otra capa; las consideraciones completas se encuentran en [Flow vs. Apex](/es/insights/salesforce-flow-vs-apex). ## Acciones con sistemas externos Este es el ámbito donde los fallos llegan al usuario final. Se deben definir tres decisiones antes de la construcción: cuál es el tiempo máximo de espera, qué dice el agente cuando la llamada falla y si se permite reintentar. La idempotencia es el concepto decisivo. Una operación de lectura se puede reintentar con seguridad. Una operación que crea un registro, envía un mensaje o cobra una tarjeta, un reintento puede generar duplicados. La solución es una clave única para cada solicitud que el sistema receptor identifique, o una renuncia consciente a reintentar. La latencia es una consideración de experiencia, no solo técnica. Una llamada que dura unos segundos es aceptable en un canal de chat si el agente dice que está verificando; una llamada que dura más de eso requiere una ruta asíncrona: el agente confirma la recepción y actualiza cuando llega la respuesta. Los patrones para abordar los fallos de integración se detallan en [Manejo de errores de integración en Salesforce](/es/insights/salesforce-integration-error-handling). ## Permisos a nivel de acción Cada acción debe estar limitada por un permiso separado. El error común es otorgar al agente un perfil amplio que cubre todas las acciones, y luego no hay forma de abrir una acción específica a un grupo determinado sin abrirlas todas. Principio de trabajo: permiso mínimo para cada acción, validación dentro de la acción y no solo en las instrucciones para el agente, y verificación de que la acción respeta el contexto del usuario. No se debe depender de que las instrucciones eviten la activación; las instrucciones son una guía, no un control. ## Cuándo dividir una acción Una acción que realiza tres cosas es difícil de probar y de aprobar. Una señal para dividir: cuando una parte de la acción requiere aprobación humana y otra no, cuando diferentes partes requieren permisos distintos, o cuando un fallo intermedio deja el proceso en un estado inconsistente. La división encarece ligeramente la orquestación, pero vale la pena: cada parte se prueba por separado, el agente puede detenerse entre las partes y los permisos son precisos. La regla práctica: una acción, una decisión. La planificación de puntos de detención entre las partes se detalla en [Human-in-the-Loop en Agentforce](/es/insights/agentforce-human-in-the-loop). ## Escenario: una organización que pasó de Apex a Flow Una empresa de servicios construyó seis acciones en Apex en una fase piloto, suponiendo que así obtendría control total. En dos meses, se hizo evidente que cuatro de ellas cambiaron de lógica tres veces cada una, no por errores, sino porque las reglas de negocio se fueron aclarando con el uso. Cada cambio requería un desarrollador, pruebas y un ciclo de despliegue de varios días. En la segunda ronda, las dos acciones que permanecieron en Apex fueron aquellas con múltiples llamadas a un sistema externo y procesamiento de respuestas. Las otras cuatro se trasladaron a Flow, y el administrador de la plataforma asumió la responsabilidad de ellas. El tiempo promedio de corrección se redujo de días a horas. La lección no fue que Apex sea malo, sino que en la etapa en que las reglas aún se están consolidando, el costo del cambio es más importante que el costo inicial de construcción. ## Riesgos y acciones preventivas | Riesgo | Cómo se manifiesta | Acción preventiva | | --- | --- | --- | | Descripción de acción ambigua | El agente activa la acción incorrecta | Descripción con "cuándo sí" y "cuándo no" y parámetros definidos | | Reintentos a ciegas | Registros o cargos duplicados | Clave única de solicitud o renuncia al reintento (Retry) | | Permiso amplio para el agente | Acción sensible accesible a cualquier usuario | Permiso separado para cada Acción y validación dentro de la acción | | Toda la lógica en Apex | Cada cambio de negocio se convierte en un proyecto de desarrollo | Flow para reglas cambiantes, Apex para complejidad real | | Una acción que hace tres cosas | El fallo intermedio deja un estado inconsistente | División según el criterio y los permisos | ## Métricas para Acciones | Métrica | Qué revela | Frecuencia | | --- | --- | --- | | Tasa de éxito de la acción | Porcentaje de activaciones finalizadas con éxito | Semanal | | Tasa de acción incorrecta | Porcentaje de casos en los que se seleccionó una acción errónea | En cada versión | | Latencia mediana por acción | ¿La experiencia sigue siendo razonable? | Semanal | | Tasa de fallos de integración | Estabilidad de los sistemas de destino | Semanal | | Tiempo promedio de corrección | ¿La implementación elegida permite un cambio rápido? | Mensual | Cuando se requiere acompañamiento en la planificación de la capa de Acciones y su adaptación a la arquitectura existente, el [servicio Agentforce y AI](/es/agentforce-ai) es el camino práctico a seguir. ## Lista de verificación para cada Acción - ☐ Se redactó una descripción con "qué", "cuándo sí" y "cuándo no" - ☐ Los parámetros son mínimos y de tipo definido - ☐ Se seleccionó la implementación de más alto nivel que sea suficiente para la necesidad - ☐ Se definió un permiso separado para la acción - ☐ La validación reside dentro de la acción y no solo en las instrucciones - ☐ Se determinó si la acción es idempotente y cuál es la política de reintentos (Retry) - ☐ Se definió el tiempo máximo de espera y el mensaje de fallo para el usuario - ☐ Las acciones con múltiples decisiones se dividieron - ☐ Existe un escenario de prueba para el fallo y no solo para el éxito ### Preguntas y respuestas **¿Por qué no simplemente construir todo en Apex y terminar?** Porque cada Acción en Apex hace que el próximo cambio dependa de un desarrollador y de un ciclo de despliegue. Para acciones basadas en reglas de negocio cambiantes, Flow permite al propietario del proceso actualizar por sí mismo. Apex se justifica cuando hay lógica compleja, procesamiento masivo o una llamada que requiere un control de errores preciso. **¿Las Acciones Estándar son suficientes para un piloto?** En la mayoría de los casos, sí, e intencionalmente. Un piloto que comienza con la recuperación de un registro, la actualización de un campo y la creación de un caso se construye en días, no semanas, y permite probar la pregunta importante –si el agente elige correctamente cuándo usar una acción– antes de invertir en desarrollo. **¿Cómo sabe el agente cuándo activar una Acción específica?** Según la descripción que se le haya escrito. Una descripción vaga es la razón más común por la que el agente activa la acción incorrecta. Una buena descripción dice qué hace la acción, cuándo usarla y explícitamente cuándo no, y utiliza términos que aparecen en las preguntas de los usuarios. **¿Qué sucede cuando una llamada a un sistema externo falla a la mitad?** Es necesario definir de antemano: un mensaje de usuario claro, el registro del fallo en el Trace, y una política de reintentos solo para operaciones idempotentes. Una operación que crea un registro o cobra una tarjeta no debe reintentarse ciegamente, de lo contrario se obtienen duplicados. **¿Cuándo es recomendable dividir una acción en varias Acciones?** Cuando la acción realiza más de una consideración, o cuando parte de ella requiere aprobación humana y otra parte no. La división permite asignar diferentes permisos a cada parte, probar cada parte por separado y permitir que el agente se detenga a mitad de camino sin dejar un proceso medio completado. --- ## Gestión del Conocimiento para Agentforce: Preparando Contenido No Estructurado para IA URL: https://hpi.pro/es/insights/agentforce-knowledge-readiness Un repositorio de conocimiento creado para humanos no está listo para un agente de inteligencia artificial: contiene versiones contradictorias, documentos sin propietario y contenido interno mezclado con contenido externo. Esta guía presenta un proceso de preparación de cinco pasos (auditoría, archivo, estructuración, etiquetado y asignación de propietarios) con criterios de indexación y un modelo de mantenimiento sostenible a largo plazo. ## La respuesta corta Una base de conocimiento empresarial se construye generalmente para seres humanos que saben cómo cerrar lagunas, identificar un documento antiguo y consultar a un compañero. Un agente no puede hacer ninguna de las tres cosas. Por lo tanto, la preparación no se centra en añadir contenido, sino principalmente en la eliminación, la toma de decisiones y el etiquetado. El proceso práctico consta de cinco fases: revisión de cobertura y validez, archivo de contenido contradictorio y obsoleto, reorganización de la estructura del artículo, etiquetado para su recuperación y asignación de propietarios con un SLA para la actualización. La quinta fase es la que determina si la inversión perdurará más allá de seis meses. Cómo la capa de recuperación consume este contenido se explica en [Fundamentación y RAG en Agentforce](/es/insights/agentforce-grounding-rag). ## Fase 1: Auditoría enfocada No se audita toda la base. Se toma la lista de escenarios que el agente gestionará y se genera una lista de preguntas reales, a partir de solicitudes recibidas, no de la imaginación. Para cada pregunta, se verifica: si existe un artículo, cuándo se actualizó, quién es el propietario y si la respuesta es correcta actualmente. El resultado son cuatro categorías: cubierto y válido, cubierto pero obsoleto, cubierto en varias versiones contradictorias, y no cubierto en absoluto. La tercera categoría es la más peligrosa, ya que es la que provoca que el agente dé respuestas diferentes a la misma pregunta. La brecha encontrada en la cuarta categoría no es necesariamente un problema; se convierte en una lista de redacción y, mientras tanto, en una lista de temas que se dirigen a una persona. ## Fase 2: Archivar antes de escribir La instrucción más difícil de aceptar en las organizaciones es la de eliminar. Sin embargo, un artículo obsoleto que permanece en la base causa un daño mayor que uno faltante: uno faltante conduce a una escalada, uno obsoleto conduce a una respuesta incorrecta con confianza. Regla de trabajo simple: cualquier artículo sin propietario y no actualizado dentro del período definido para su ámbito sale del índice. Puede permanecer en el archivo para fines de documentación, pero no es accesible para el agente. En caso de conflicto entre dos versiones, la decisión recae en el propietario del contenido, no en el equipo técnico. Este es un punto que requiere una decisión de negocio, y omitirla hará que el problema reaparezca en la fase de pruebas. ## Fase 3: Estructura del artículo Una buena estructura para el agente es también una buena estructura para el lector, por lo que no es un trabajo duplicado. El título se formula como una pregunta o un escenario utilizando el lenguaje que emplean los usuarios, no el lenguaje interno. El primer párrafo ofrece una respuesta corta e independiente. El detalle se presenta en secciones con subtítulos. Dos reglas que afectan directamente la calidad de la recuperación: las condiciones de elegibilidad y las excepciones se ubican en una sección separada y marcada, no se insertan en una oración; y las tablas deben ser pequeñas e independientes, ya que una tabla cortada a la mitad genera una respuesta parcial. Lo que se debe evitar: artículos largos que cubren cinco temas. Es preferible dividir en cinco artículos enfocados; la recuperación será más precisa y el mantenimiento más sencillo. Los principios más amplios de gestión del conocimiento en Service Cloud se detallan en [Gestión de Knowledge en Salesforce](/es/insights/salesforce-knowledge-management). ## Fase 4: Etiquetado y segmentación de audiencias Etiquetado mínimo requerido en casi toda organización: producto o línea de servicio, mercado o país, idioma, público objetivo, estado de aprobación y fecha de vencimiento. En una organización global, la ausencia de etiquetado por mercado e idioma es el factor número uno de respuestas incorrectas: el agente recuperará una política de otro país con total confianza. La segmentación de audiencias es una decisión de seguridad, no solo de clasificación. El contenido escrito para representantes a veces incluye márgenes de descuento, objeciones y información competitiva. En un canal de cliente, la configuración predeterminada debe ser una lista de許可 (whitelist): solo el contenido explícitamente marcado como aprobado para el cliente se incluye. Un documento que es mayoritariamente permisible pero que tiene un párrafo sensible no es un caso extremo, es común. La solución es dividir el documento en lugar de marcarlo completamente como interno. ## Fase 5: Propiedad y mantenimiento Esta es la fase que determina la sostenibilidad del resultado. Para cada área de conocimiento, se designa un propietario nominal, se establece una frecuencia de revisión y se define qué sucede cuando un artículo excede su fecha de vencimiento (eliminación automática del índice en lugar de una alerta que nadie lee). El mecanismo de retroalimentación es lo que hace que el mantenimiento sea eficaz. Cada conversación que termina en una escalada debido a la falta de una fuente se añade a la lista de lagunas de contenido, y esta es la mejor lista de prioridades para nueva redacción. Es mejor escribir cinco artículos que realmente se necesitaban que cincuenta que parecían importantes. Presupuesto: El mantenimiento de contenido es una partida fija, no un proyecto. Las organizaciones que lo tratan como una tarea única verán una disminución en la precisión en un plazo de dos trimestres. ## Umbrales de entrada al índice | Criterio | Umbral Mínimo | Por qué | | --- | --- | --- | | Propiedad | Propietario nominal para cada artículo | Sin propietario, no hay quien actualice | | Validez | Dentro del período de revisión definido para el área | Evita citar una política cancelada | | Unicidad | Fuente única para cada tema | Evita respuestas contradictorias | | Audiencia | Marcado como interno o aprobado para el cliente | Evita la exposición de contenido sensible | | Estructura | Título en forma de pregunta y respuesta corta al inicio | Mejora la precisión de la recuperación | ## Escenario: 1.400 documentos reducidos a 190 Un proveedor de servicios de TI quería conectar un agente a una carpeta de SharePoint con 1.400 documentos. La revisión inicial mostró que solo alrededor del 30% se había actualizado en los últimos tres años, y que unos 200 eran borradores o versiones de trabajo. En lugar de un proyecto de limpieza exhaustivo, el equipo mapeó los 25 escenarios que debía cubrir el agente. De la base de datos, se encontraron 190 documentos relevantes; de estos, 40 eran contradictorios y requirieron la decisión de tres propietarios de área. Los documentos seleccionados se dividieron en artículos enfocados y se etiquetaron por producto y audiencia. El piloto se lanzó con 190 elementos en lugar de 1.400, y la precisión de las respuestas fue significativamente mayor que en el primer intento. El resto de la base de datos permaneció en el archivo y se incorporó gradualmente según la lista de brechas acumuladas por las escaladas reales. ## Riesgos y acciones preventivas | Riesgo | Cómo se manifiesta | Acción preventiva | | --- | --- | --- | | Inclusión de toda la base de datos | Baja precisión y dificultad para identificar la causa | Inclusión según escenarios, no según la base de datos completa | | Artículos sin propietario | Obsolescencia silenciosa | Propiedad como condición de entrada al índice | | Versiones contradictorias | Respuestas diferentes a la misma pregunta | Decisión de negocio y archivo | | Mezcla de contenido interno y externo | Exposición de información sensible al cliente | Lista de許可 (whitelist) en canal externo | | Mantenimiento como proyecto puntual | Disminución de la precisión en dos trimestres | Presupuesto fijo y SLA para la actualización | ## Indicadores de preparación del contenido | Indicador | Definición | Frecuencia | | --- | --- | --- | | Cobertura de escenarios | Porcentaje de escenarios con artículo aprobado | Mensual | | Validez | Porcentaje de artículos en el índice dentro de la fecha de vencimiento | Mensual | | Duplicidad temática | Número de temas con más de una fuente | Trimestral | | Brechas por escaladas | Número de temas nuevos requeridos y no disponibles | Semanal | | Tiempo medio de actualización | Cuánto tiempo tarda en corregirse un artículo encontrado incorrecto | Mensual | Cuando se requiere acompañamiento en la preparación de la base de datos y en el establecimiento del modelo de mantenimiento, [Servicio Agentforce e IA](/es/agentforce-ai) es el camino práctico a seguir. ## Lista de verificación para la preparación del conocimiento - ☐ Se creó una lista de preguntas reales a partir de consultas recibidas. - ☐ Cada pregunta se clasificó: válida, obsoleta, contradictoria o faltante. - ☐ Los artículos sin propietario fueron archivados o se les asignó uno. - ☐ Los conflictos fueron resueltos por el propietario del contenido. - ☐ Los artículos están estructurados: título en forma de pregunta, respuesta corta, secciones. - ☐ Las condiciones de elegibilidad y excepciones se encuentran en una sección separada. - ☐ Existe etiquetado de producto, mercado, idioma, audiencia y validez. - ☐ Se separó el contenido interno del contenido autorizado para el cliente. - ☐ Se establecieron la frecuencia de revisión y la eliminación automática al vencimiento. - ☐ Se implementó un mecanismo que convierte las escaladas en una lista de temas pendientes de redacción. ### Preguntas y respuestas **¿Es necesario reescribir todos los artículos antes de comenzar?** No. Comience con los escenarios que el agente manejará en la primera versión, generalmente entre veinte y cuarenta artículos. La reescritura masiva de un repositorio de cientos de artículos lleva meses y a menudo se detiene a mitad de camino, mientras que una capacitación enfocada es suficiente para un piloto. **¿Qué se hace con los artículos que no tienen un propietario?** Se les asigna un propietario o se archivan. Un artículo sin propietario seguirá quedando obsoleto, y el agente seguirá citándolo. Es una decisión incómoda, pero es mucho más barata que descubrir a posteriori que el agente comunicó una política que fue cancelada hace dos años. **¿Cómo se identifican artículos contradictorios en un repositorio grande?** Se agrupan por tema y se revisan manualmente solo los grupos con más de un artículo. También se le pueden hacer al propio agente las veinte preguntas más frecuentes y verificar qué fuentes se recuperaron; una colisión se revela inmediatamente cuando aparecen dos artículos con respuestas diferentes. **¿Son adecuados los PDF y los documentos de Word como fuente?** Menos que un artículo estructurado, pero es posible cuando el documento está dividido en secciones con encabezados claros. Un documento escaneado, una presentación o un archivo con tablas complejas son una fuente problemática, y es preferible extraer el contenido relevante para un artículo dedicado. **¿Cuál es la estructura correcta de un artículo destinado también al agente?** Una pregunta o escenario como título, una respuesta breve en el primer párrafo, y luego detalles en secciones con subtítulos. Las condiciones de elegibilidad y excepciones deben ir en una sección separada y no dentro de una oración. Esta estructura también sirve al lector humano, por lo que no hay aquí ningún compromiso. --- ## Gobernanza de IA para Agentforce: Modelo de Responsabilidad, Riesgos y Controles URL: https://hpi.pro/es/insights/agentforce-ai-governance La gobernanza de la IA falla en dos extremos: un comité que bloquea toda iniciativa, o la ausencia de controles que se revela en una auditoría. Esta guía presenta un modelo escalonado por riesgo: quién aprueba qué, qué controles son obligatorios en cada nivel, qué documentos son realmente necesarios y cómo mantener la velocidad sin sacrificar la responsabilidad. ## La respuesta breve Un buen gobierno de IA no es una capa adicional de certificaciones, sino un mecanismo que resuelve rápidamente preguntas recurrentes: quién decide qué puede hacer un agente, qué controles son obligatorios según el nivel de riesgo y qué se requiere para cambiar un comportamiento después del lanzamiento. Sin un mecanismo como este, cada nuevo agente se convierte en una discusión desde cero. El principio central es la clasificación. Un agente interno que solo lee información y no escribe nada no debe pasar por el mismo proceso que un agente que se comunica con clientes y realiza reembolsos. Un proceso uniforme genera bloqueo o elusión, y generalmente ambos. ## Clasificación de riesgo: la base de todas las demás decisiones | Categoría | Características | Aprobadores | Controles obligatorios | | --- | --- | --- | --- | | Baja | Interno, solo lectura, sin datos sensibles de clientes | Propietario del proceso + Gerente de plataforma | Grounding aprobado, registro de conversaciones, revisión mensual | | Media | Interno con escritura reversible, o exposición de información al cliente | + Arquitecto + Representante de Datos | Conjunto de pruebas, pruebas de Persona, monitoreo semanal | | Alta | Operación con cliente, dinero, permisos o datos irreversibles | + Riesgos, Legal y CISO | Aprobación humana, auditoría completa, plan de reversión | | Prohibida | Decisiones con implicaciones legales o regulatorias directas sin intervención humana | - | Caso de uso rechazado o dividido en una subtarea de menor categoría | La clasificación se determina mediante solo tres preguntas: ¿La acción es reversible?, ¿quién está expuesto al resultado? y ¿qué tipo de información está involucrada en el proceso? Tres preguntas que se pueden responder en diez minutos, y eso es precisamente lo que hace que el modelo sea útil. ## Los tres roles que deben asignarse El propietario de negocio es responsable del resultado, define lo que el agente puede hacer y dirime conflictos. Él deberá explicar a la dirección por qué el agente respondió de cierta manera, por lo que no se puede dejar el rol vacante o compartirlo entre dos gerentes. El propietario técnico es responsable de la implementación, el monitoreo, el proceso de cambio y el costo. Mantiene el registro de agentes y el plan de ejecución para manejar fallos. Un auditor independiente —generalmente un representante de Riesgos o Seguridad de la Información— no participa en la construcción y, por lo tanto, puede verificar. Su función es muestrear conversaciones, verificar que los controles declarados estén en funcionamiento y presentar hallazgos al foro de decisión. Sin un factor que no sea parte del éxito del proyecto, el control se convierte en autorreporte. El modelo de responsabilidad con Salesforce y los proveedores de modelos se detalla en [Seguridad y responsabilidad compartida de Agentforce](/es/insights/agentforce-security-shared-responsibility). ## Registro de agentes Este es el único documento que no se debe omitir. No necesita ser un sistema; una tabla bien mantenida es suficiente, pero debe estar actualizada. Para cada agente activo: un objetivo en una frase, propietarios de negocio y técnico, nivel de riesgo, canales activos, lista de Acciones y sus permisos, fuentes de Grounding, puntos de aprobación humana, fecha de la última revisión y las tres métricas clave de desempeño. El registro resuelve un problema que aparece en el segundo año: la proliferación de agentes. Cuando cada equipo construye su propio agente, se encuentran tres agentes que responden a la misma pregunta de tres maneras diferentes, y nadie sabe quién aprobó el tercero. ## Proceso de cambio después del lanzamiento La distinción entre un cambio rutinario y un cambio sustancial es lo que evita una gobernanza paralizante. Un cambio rutinario —una redacción, una corrección en la redacción de una respuesta, la adición de un artículo de Knowledge existente al índice— sigue el proceso de cambio normal de la plataforma. Un cambio sustancial requiere una nueva aprobación en el nivel adecuado. Cuatro cambios son siempre sustanciales: la adición de una nueva Acción, la extensión de un permiso, la apertura de un nuevo canal y la eliminación o flexibilización de un punto de aprobación humana. Estos son precisamente los cambios que se realizan silenciosamente bajo la presión de mejorar el rendimiento, por lo que deben etiquetarse de antemano. Los mecanismos de monitoreo que alimentan el proceso de cambio se detallan en [Observabilidad para agentes de IA](/es/insights/agentforce-observability). ## Lo que la gobernanza verifica realmente, trimestralmente La revisión trimestral no es una presentación de estado. Verifica cinco cosas: si los agentes registrados siguen siendo necesarios, si los controles declarados están funcionando en el muestreo, si el costo en relación con el resultado se justifica, qué escaladas recurrentes indican una brecha de contenido y si los cambios sustanciales siguieron el proceso correcto. El resultado de la revisión es una lista de decisiones: expandir, reducir, suspender o cerrar un agente. Una gobernanza que no puede cerrar un agente no es gobernanza, es documentación. ## Escenario: Minorista que recuperó el control sin detener el desarrollo Una cadena minorista descubrió que tenía siete iniciativas de IA simultáneas en cuatro departamentos, sin registro y sin el conocimiento de Riesgos. La primera reacción propuesta fue una congelación general hasta que se estableciera una política, una medida que también habría paralizado las dos iniciativas que ya estaban generando valor. En su lugar, se realizó un mapeo de dos semanas: cada iniciativa se clasificó por nivel de riesgo. Cinco se encontraron en un nivel bajo y continuaron con la aprobación abreviada de un propietario de proceso y un gerente de plataforma. Dos, una relacionada con reembolsos a clientes y la otra que exponía datos de inventario a proveedores, se elevaron a un nivel alto, recibieron puntos de aprobación humana y fueron revisadas por Riesgos antes de continuar. Seis meses después, el número de iniciativas había crecido, pero la dirección supo por primera vez qué existía, quién era responsable y cuál era el costo. La conclusión práctica: la gobernanza ganó legitimidad precisamente porque no bloqueó el nivel bajo. ## Riesgos de gobernanza y acciones preventivas | Riesgo | Cómo se manifiesta | Acción preventiva | | --- | --- | --- | | Comité bloqueador | Los equipos construyen fuera del proceso aprobado | Proceso rápido para nivel bajo con solo dos aprobadores | | Registro desactualizado | El auditor descubre un agente que nadie conocía | Actualización del registro como condición para el lanzamiento de la versión | | Propiedad solo en TI | Nadie decide sobre el comportamiento del negocio | Nombramiento de un propietario de negocio nominal para cada agente | | Control autoinformado | Los controles existen en el documento pero no en la realidad | Muestreo de conversaciones por una parte no involucrada en la construcción | | Cambio sustancial en silencio | Eliminación de la aprobación humana para mejorar el tiempo de respuesta | Lista cerrada de cambios que requieren nueva aprobación | ## Métricas de gobernanza | Métrica | Qué revela | Frecuencia | | --- | --- | --- | | Cobertura del registro | Porcentaje de agentes activos documentados | Mensual | | Tiempo promedio de aprobación | Si el proceso se ha convertido en un cuello de botella | Mensual | | Hallazgos del muestreo | Brecha entre el control declarado y el estado real | Trimestral | | Cambios sustanciales en el proceso correcto | Disciplina del proceso | Trimestral | | Agentes suspendidos o cerrados | Si la gobernanza es capaz de decir "no" | Trimestral | Cuando se requiere acompañamiento para establecer un modelo de gobernanza que se adapte al tamaño de la organización y a la regulación aplicable, el [Servicio Agentforce e IA](/es/agentforce-ai) es el camino práctico a seguir. ## Lista de verificación para el establecimiento de la gobernanza - ☐ Modelo de clasificación de riesgos de tres preguntas aprobado - ☐ Aprobadores definidos para cada nivel, incluyendo un proceso rápido para el nivel bajo - ☐ Propietarios de negocio y técnicos designados para cada agente existente - ☐ Auditor independiente designado que no participa en la construcción - ☐ Registro de agentes establecido con todos los campos obligatorios - ☐ Lista cerrada de cambios sustanciales definida - ☐ Rutina de revisión trimestral establecida con autoridad para cerrar un agente - ☐ Métricas de gobernanza y frecuencia de informes a la dirección definidas ### Preguntas y respuestas **¿Es necesario un comité de IA separado o se pueden usar foros existentes?** En la mayoría de las organizaciones, es preferible ampliar un foro existente (comité de cambios o arquitectura) y añadir un representante de Riesgos y uno Legal para las discusiones de IA. Un comité separado tiende a reunirse una vez al mes y se convierte en un cuello de botella, lo que lleva a los equipos a eludirlo. **¿Quién es el propietario de un agente: el negocio o TI?** El propietario del proceso de negocio es el dueño del resultado y de la decisión sobre lo que el agente está autorizado a hacer. TI es el dueño de la implementación, el monitoreo y la estabilidad. Cuando la propiedad reside solo en TI, nadie decide sobre cuestiones de comportamiento, y el agente queda estancado en la primera versión. **¿Todo cambio en las instrucciones requiere aprobación?** No. Un cambio de redacción en un agente de bajo riesgo puede pasar por un proceso de cambio regular. Un cambio que amplía la autorización, añade una acción, abre un nuevo canal o elimina un punto de aprobación humana es un cambio material que requiere una nueva aprobación en el nivel adecuado. **¿Qué debe incluir realmente el registro de agentes?** Para cada agente activo: propósito en una frase, propietario de negocio, clasificación de riesgo, canales, lista de acciones y sus autorizaciones, fuentes de fundamentación (grounding), puntos de aprobación humana, fecha de última revisión y métricas de rendimiento. Este es el primer documento que cualquier auditor solicitará. **¿Cómo se evita que la gobernanza ralentice el desarrollo?** Se define una vía rápida para riesgos bajos: un agente de solo lectura en un canal interno aprobado por el propietario del proceso y el administrador de la plataforma, sin un comité. A medida que el riesgo aumenta, se añaden aprobadores y controles. Un camino uniforme para cada agente es la razón más común para eludir la gobernanza. --- ## Lead-to-Cash en Sales Cloud: optimizando su ciclo de ventas de principio a fin URL: https://hpi.pro/es/insights/salesforce-lead-to-cash El proceso Lead-to-Cash a menudo presenta fricciones en tres puntos de transición clave: de prospecto a oportunidad, de oportunidad a cotización aprobada, y de cotización a pedido en el ERP. Esta guía detalla las configuraciones esenciales para cada etapa, cómo determinar la ubicación óptima de los precios y por qué la aprobación de descuentos es frecuentemente el verdadero cuello de botella. ## La Respuesta Breve El proceso Lead-to-Cash (del prospecto al cobro) atraviesa cuatro áreas funcionales —Marketing, Ventas, Finanzas y Operaciones— y, por tanto, sus interrupciones suelen ocurrir en los límites entre ellas y no en el centro del proceso. Tres puntos de transición son determinantes: cuándo un prospecto (Lead) se convierte en oportunidad (Deal), cuándo una propuesta (Quote) se convierte en una propuesta aprobada (Approved Quote), y cuándo una oportunidad cerrada (Closed Deal) se convierte en una orden (Order) en el sistema operativo. En cada uno de estos puntos deben existir tres respuestas documentadas: quién decide, qué se requiere para la transición y qué sucede si la transición falla. La ausencia de alguna de estas respuestas genera soluciones alternativas manuales ("shadow IT" o hojas de cálculo auxiliares), lo que resulta en la mayoría de las discrepancias entre lo vendido y lo facturado. ## Punto de Transición 1: Del Prospecto a la Oportunidad Este límite define la calidad de todo el Pipeline (embudo de ventas). El fallo común es la conversión automática de todos los prospectos, lo que infla el pronóstico y devalúa el historial de conversión. Lo que se requiere: un criterio de conversión documentado (contacto con autoridad, necesidad formulada, horizonte temporal), un Propietario (Owner) definido para cada lado del límite, y una regla única para el manejo de prospectos que no cumplen con el criterio: Nutrición (Nurture), no eliminación. Para más información, consulte [Implementación de Sales Cloud](/es/insights/sales-cloud-implementation). ## Punto de Transición 2: De la Propuesta a la Propuesta Aprobada Aquí se concentra la mayor parte de la demora en el proceso, casi siempre debido a una jerarquía de aprobaciones indefinida, y no al sistema. | Componente | Qué debe estar definido | Qué ocurre sin él | | --- | --- | --- | | Catálogo y Lista de Precios | Fuente única de la verdad para el precio | Propuestas con precios manuales | | Umbral de Descuento | Jerarquía según porcentaje y tipo de cliente | Todos los descuentos escalan al Gerente General o no se aplican | | Tiempo de Respuesta para Aprobación | Meta definida, por ejemplo, un día hábil | Derivación telefónica y documentación retrospectiva | | Condiciones No-Precios | Condiciones de pago, garantía, SLA | Compromisos que no llegaron a Finanzas | La última fila a menudo se descuida: las organizaciones construyen un control de descuentos riguroso, pero permiten que un representante se comprometa a términos de pago de "contado + 90 días" sin ninguna aprobación. ## Punto de Transición 3: De la Oportunidad Cerrada a la Orden Este es el punto más técnico y también donde los fallos son más costosos. Tres preguntas que determinan la arquitectura: 1. **Quién emite la orden** – Generalmente el ERP. Salesforce envía una solicitud y recibe un identificador, sin gestionar inventario ni facturación. 2. **Qué sucede en caso de fallo** – Se requiere un estado visible en la oportunidad, una notificación al propietario del proceso y un mecanismo de reenvío idempotente que no genere una orden duplicada. 3. **Qué información se devuelve** – Como mínimo, el identificador de la orden, el estado de entrega y el estado de facturación. Sin esta retroalimentación, los representantes de ventas contactan a Finanzas para responder al cliente. Los principios de diseño de la integración se detallan en [Integración de Salesforce y ERP](/es/insights/salesforce-erp-integration), y la gestión de fallos en [Manejo de Errores en Integraciones de Salesforce](/es/insights/salesforce-integration-error-handling). ## El Problema Silencioso: Coordinación de Productos entre Sistemas La mayoría de las discrepancias entre la propuesta y la factura no provienen del precio, sino del producto. Un código de artículo que existe en el ERP pero no en Salesforce, un producto descontinuado en un sistema pero activo en el otro, o una unidad de medida diferente. La regla: el catálogo de productos es propiedad de un solo sistema, generalmente el ERP, y se sincroniza con Salesforce con una frecuencia definida, incluyendo la marcación de productos descontinuados en lugar de su eliminación. La eliminación rompe el historial de oportunidades y distorsiona los análisis. ## Qué Medir | Métrica | Qué revela | | --- | --- | | Tiempo promedio de aprobación de propuestas | El cuello de botella más común | | Tasa de propuestas recreadas | Señal de precios poco claros o un catálogo incompleto | | Fallos en la creación de órdenes | Estabilidad de la integración | | Discrepancia entre el monto de la oportunidad y el monto de la factura | Calidad del proceso de extremo a extremo | | Oportunidades cerradas sin orden en 48 horas | Solicitudes que se perdieron entre los sistemas | La última métrica es la prueba más sencilla para la salud del proceso, y pocas organizaciones la monitorean regularmente. ## Orden de Implementación Primero se implementa un único camino de venta de extremo a extremo (un tipo de cliente, una categoría de producto) hasta la creación exitosa de una orden en el ERP. Solo después de que este camino sea estable, se añaden configuraciones, monedas, entidades legales y renovaciones. Una expansión prematura consolida decisiones de precios antes de que se prueben en el campo. ## Conclusión El proceso Lead-to-Cash no es un proyecto tecnológico, sino un acuerdo entre cuatro áreas funcionales sobre tres límites. Quienes documentan estos límites, incluyendo las rutas de fallo, obtienen un proceso medible; quienes comienzan con las herramientas obtienen una cadena que funciona en una demostración, pero que en la práctica depende de llamadas telefónicas. ### Preguntas y respuestas **¿Es imprescindible CPQ para gestionar el proceso Lead-to-Cash?** No, un catálogo de productos y libros de precios estándar son suficientes cuando la estructura de precios es sencilla. Se requiere CPQ cuando existen configuraciones complejas, niveles de cantidad, renovaciones o modelos de precios de suscripción. **¿Dónde deben residir los precios: en Salesforce o en el ERP?** Los precios de lista pueden coexistir en ambos sistemas, pero solo uno debe ser la fuente de verdad y alimentar al otro. La gestión paralela de precios en ambos sistemas puede generar discrepancias entre la cotización y la factura final. **¿Qué hacer si un pedido falla en el ERP?** Es crucial definir un flujo de manejo de errores: un estado claro del pedido, una notificación al responsable del proceso y la capacidad de reenviar el pedido sin crear duplicados. Sin esto, las oportunidades cerradas pueden perderse entre sistemas. **¿Quién debe aprobar los descuentos que exceden los límites establecidos?** Se requiere una jerarquía de aprobación escalonada según el umbral y el tipo de excepción, con un tiempo de respuesta definido. Un proceso de aprobación que excede un día hábil laboral conduce a soluciones alternativas telefónicas y anula el valor del control. **¿Se necesita un objeto 'Pedido' (Order) en Salesforce?** Cuando el ERP genera el pedido, a menudo basta con reflejar el estado y un identificador. Un objeto 'Pedido' completo en Salesforce se justifica cuando una oportunidad involucra múltiples pedidos, entregas parciales o renovaciones que se gestionan desde el CRM. --- ## Pronósticos y Paneles de Control en Sales Cloud: Cómo Generar Pronósticos Confiables URL: https://hpi.pro/es/insights/salesforce-forecast-dashboards Cuando un gerente de ventas gestiona pronósticos en hojas de cálculo separadas, el problema no reside en el panel de control. Un pronóstico confiable se asienta sobre cuatro pilares fundamentales: una jerarquía adecuada, fechas de cierre claras, categorías estandarizadas y un ciclo de revisión constante. Esta guía detallará cómo construir estos pilares y qué métricas monitorear para asegurar una mejora efectiva en la precisión de sus pronósticos. ## La respuesta breve Un pronóstico no es el resultado de un *dashboard*, sino de la disciplina en la gestión de datos. Si las oportunidades se actualizan una vez a la semana la noche antes de la reunión de *Pipeline*, ningún diseño de informe generará una imagen fiable. Por lo tanto, el trabajo en el *Forecast* comienza con cuatro condiciones operativas y solo después con la visualización. El signo distintivo de que las condiciones no se cumplen es fácil de identificar: existe una hoja de cálculo de pronóstico paralela. Mientras exista, la propia organización declara que el sistema no es la fuente de verdad. ## Las cuatro condiciones previas | Condición | Requerimiento | Consecuencia de su ausencia | | --- | --- | --- | | Jerarquía de usuarios correcta | *Role Hierarchy* que refleje la estructura de ventas real | Cálculo erróneo del pronóstico a nivel de gerente | | Fechas de cierre limpias | Regla que prohíba fechas pasadas con más de una semana | Pronóstico que incluye oportunidades "muertas" | | Categorías acordadas | Definición escrita para *Pipeline*, *Best Case*, *Commit* | Cada gerente interpreta de forma diferente | | Ciclo de revisión regular | Reunión semanal desde el sistema | Actualización retroactiva antes de las reuniones | La cuarta condición es la que genera las tres primeras. Una vez que la reunión se realiza desde la pantalla y no desde una hoja de cálculo, los representantes actualizan sus datos, ya que de lo contrario su oportunidad no es visible. ## Categorías de Forecast: dónde reside el juicio humano Una confusión común es entre probabilidad y categoría. La probabilidad se deriva de la etapa y se utiliza para un cálculo ponderado; es estadística. La categoría es una declaración de compromiso de una persona. Una separación correcta se ve así: la etapa determina una probabilidad automática que nadie puede anular; el gestor de cartera clasifica la oportunidad como *Best Case* o *Commit* según su conocimiento del cliente; y el gerente de equipo puede cambiar la clasificación en la revisión, con documentación. De esta manera, se obtienen dos números con significados diferentes —una estimación estadística y un compromiso de gestión— en lugar de un número único y ambiguo. La definición de las etapas de ventas, de las cuales se deriva la probabilidad, se detalla en [Implementación de Sales Cloud](/es/insights/sales-cloud-implementation). ## Tres Dashboards, no treinta La proliferación de *dashboards* es un síntoma de que nadie confía en los existentes. La estructura que funciona es: 1. **Pronóstico para la dirección** - Un solo número para el trimestre con segmentación por categoría, comparación con el objetivo y tendencia semanal. Sin detalles de oportunidades. 2. **Pipeline para la gestión de equipo** - Oportunidades por etapa y antigüedad, destacando las desviaciones: oportunidades que no se han movido, fechas vencidas, montos modificados. 3. **Lista de trabajo para el representante** - Qué requiere acción hoy. No un informe, sino una cola de trabajo. La comprobación sencilla: si dos *dashboards* muestran el mismo número con valores diferentes, al menos uno de ellos es redundante o incorrecto. ## Medición de la precisión del pronóstico Esta es la métrica que la mayoría de las organizaciones no miden, y por tanto, no saben si han mejorado: - **Desviación del Commit** - La diferencia entre el monto del *Commit* al inicio del trimestre y el resultado real. Una desviación superior al 20% indica una definición laxa de *Commit*. - **Estabilidad del pronóstico** - Cuánto ha cambiado el pronóstico de una semana a otra. Una alta volatilidad indica una actualización tardía, no un mercado dinámico. - **Slippage** - Oportunidades que se pospusieron para el trimestre siguiente. Un porcentaje alto indica criterios de etapa débiles. - **Precisión por representante** - Revela quién infla sistemáticamente y quién es conservador, permitiendo una corrección individual en lugar de un factor de corrección general. Las métricas complementarias para la adopción se encuentran en [Métricas de Adopción de Salesforce](/es/insights/salesforce-adoption-metrics). ## El error recurrente: crear un informe en lugar de corregir un proceso Cuando el pronóstico no es preciso, la reacción común es pedir más segmentaciones —por producto, por región, por origen. Esto genera una carga de informes y oculta la causa. Si el 30% de las oportunidades tienen una fecha vencida, ninguna segmentación ayudará. La secuencia correcta: corregir la calidad de los datos, establecer el ciclo de revisión, medir la precisión durante un trimestre, y solo entonces considerar segmentaciones adicionales. ## Resumen Un pronóstico fiable es el resultado de una rutina de gestión apoyada por el sistema, no de una herramienta de pronóstico. Tres preguntas que determinan si ha llegado a ese punto: ¿Existe una hoja de cálculo paralela?, ¿Todos están de acuerdo con lo que entra en el *Commit*?, y ¿Alguien mide la precisión del pronóstico a posteriori? Tres buenas respuestas valen más que cualquier mejora de *dashboard*. ### Preguntas y respuestas **¿Por qué el pronóstico en el sistema difiere del pronóstico del gerente de ventas?** Casi siempre se debe a que la definición de 'Commit' no está unificada. El gerente incluye oportunidades en su pronóstico basándose en su conocimiento del cliente, mientras que el sistema calcula en función de la etapa. La solución es establecer una definición escrita de qué se incluye en el 'Commit' y quién está autorizado a modificarlo. **¿Deberíamos usar la probabilidad automática o el juicio del representante?** Ambos, pero de forma separada. La probabilidad se deriva de la etapa y se utiliza para un cálculo ponderado; el juicio humano se refleja en la categoría de pronóstico. Mezclarlos, por ejemplo, permitiendo que un representante anule los porcentajes manualmente, invalida la efectividad de ambos. **¿Cuántos paneles de control son necesarios?** Generalmente, tres son suficientes: un pronóstico para la dirección, un panel de pipeline para la gestión del equipo y una lista de trabajo para el representante. La proliferación de paneles de control puede generar versiones contradictorias de las mismas métricas. **¿Qué hacer con las oportunidades cuya fecha de cierre ha vencido?** Implemente una regla operativa estricta: cualquier oportunidad con una fecha de cierre vencida hace más de una semana debe ser actualizada o movida a 'Closed Lost'. Sin esta disciplina, cualquier cálculo de pronóstico se basará en datos incorrectos e inexactos. **¿Cuánto tiempo se tarda en ver una mejora en la precisión?** Normalmente, después de dos o tres ciclos de venta completos. Este es el tiempo mínimo necesario para acumular suficientes oportunidades gestionadas bajo las nuevas definiciones, permitiendo una comparación efectiva entre el pronóstico y el resultado real. --- ## Omnicanalidad y SLA en Service Cloud: Diseño de Enrutamiento y Capacidad URL: https://hpi.pro/es/insights/service-cloud-omnichannel-sla El Omni-Channel suele fallar no por la configuración de enrutamiento, sino por el modelo de capacidad: cuando el chat, el correo electrónico y el teléfono se miden con la misma unidad de peso, los agentes se ven abrumados o inactivos alternativamente. Esta guía explica cómo establecer ponderaciones de trabajo, cómo conectar Entitlements al enrutamiento y cómo identificar con antelación si el modelo no soporta la carga. ## La respuesta breve Omni-Channel no es un mecanismo de distribución, sino un modelo de capacidad. En cada momento, este modelo se plantea una única pregunta: ¿cuánto trabajo puede asumir este agente ahora? Si la respuesta a esta pregunta es incorrecta —porque el chat y el correo electrónico recibieron el mismo peso—, el enrutamiento funcionará exactamente como se configuró y perjudicará el servicio. Por lo tanto, la secuencia de trabajo es la siguiente: primero el modelo de capacidad y los pesos, luego las habilidades, después los Entitlements y los Milestones, y solo al final las automatizaciones de escalamiento. ## Modelo de capacidad: el punto que lo determina todo Omni-Channel asigna a cada agente una "cuota de trabajo" (Capacity) y a cada elemento de trabajo un peso. Un centro que define un peso uniforme para todos los canales obtiene uno de dos resultados: los agentes de chat se colapsan bajo la carga, o los agentes que gestionan correos electrónicos parecen ocupados mientras están disponibles. Un punto de partida razonable para la calibración: | Tipo de trabajo | Característica | Peso relativo recomendado | | --- | --- | --- | | Llamada telefónica | Completamente sincrónica | Ocupa toda la capacidad | | Chat en vivo | Sincrónico con pausas cortas | Alto, generalmente 2-3 en paralelo como máximo | | Correo electrónico / formulario | Asincrónico | Bajo | | Caso en espera del cliente | Inactivo | Cero - debe liberar capacidad | La última línea es la más común en errores: un Case que espera por el cliente y que sigue ocupando capacidad hace que los agentes parezcan ocupados cuando no tienen trabajo activo. ## Habilidades: menos es más El Skills-Based Routing suena como una mejora obvia, pero en la práctica es la fuente más común de solicitudes atascadas. Cuantas más habilidades se añaden, mayor es la probabilidad de que no haya un agente disponible que cumpla con todas ellas. Tres reglas que lo impiden: definir habilidades solo cuando su ausencia impide realmente el tratamiento; definir para cada requisito un nivel de Fallback que se activa después de un tiempo de espera definido; y revisar mensualmente cuántas solicitudes se asignaron a través de Fallback —un porcentaje alto indica que el modelo no coincide con la dotación del centro de contacto. ## Entitlements y Milestones: del compromiso al mecanismo Un SLA que solo aparece en un informe es una notificación a posteriori. Entitlements y Milestones lo convierten en un mecanismo activo: 1. **Entitlement** define qué cliente tiene derecho a qué nivel de servicio —normalmente una configuración predeterminada y algunas excepciones contractuales. 2. **Milestone** define los puntos de tiempo medidos: primera respuesta, actualización periódica, resolución. 3. **Business Hours** determinan cuándo corre el reloj, y deben configurarse para cada zona horaria y cada canal por separado. 4. **Stopped Time** congela el contador en espera del cliente —sin esto, las métricas penalizan al centro de contacto por el comportamiento del cliente. 5. **Acciones de Milestone** generan una alerta y un escalamiento **antes** de la infracción, generalmente alrededor del 75-80% del tiempo. La regla fundamental: si la primera alerta llega después de la infracción, el mecanismo mide, pero no gestiona. Las decisiones fundamentales sobre la definición de Case y el reloj del SLA están detalladas en [Implementación de Service Cloud](/es/insights/service-cloud-implementation). ## ¿Cómo saber si el modelo no funciona? Cinco señales tempranas, antes de que las métricas mensuales revelen un problema: * Alto porcentaje de asignaciones a través de Fallback —las habilidades no coinciden con la dotación. * Solicitudes en la cola de asignación que superan unos pocos minutos —falta de capacidad o una regla de Overflow inexistente. * Agentes que informan de una sobrecarga mientras el informe de capacidad muestra disponibilidad —pesos incorrectos. * Concentración de infracciones de SLA a una hora fija del día —problema de personal, no de enrutamiento. * Alta tasa de solicitudes asignadas y abandonadas inmediatamente —los agentes rechazan el trabajo que no les conviene. ## Medición continua | Métrica | Qué revela | | --- | --- | | Tiempo en la cola de asignación | Si el modelo encuentra un agente a tiempo | | Utilización promedio de la capacidad | Si los pesos son realistas | | Infracciones por Milestone | Dónde exactamente se rompe el SLA | | Tasa de escalamientos evitados | Si la alerta temprana funciona | | Brechas en las infracciones entre canales | Si un canal específico se ve perjudicado en el enrutamiento | ## Orden de implementación Se activa un canal con un único Entitlement y sin habilidades, se calibran los pesos con datos reales durante dos semanas, y solo entonces se añade un segundo canal y habilidades. Una implementación completa en un solo día impide la capacidad de identificar qué componente causó la sobrecarga, y generalmente termina con la desactivación del enrutamiento y el retorno a las colas manuales. ## Resumen Omni-Channel es un modelo de capacidad y no de distribución, y el SLA es un mecanismo de alerta, no un informe. Estos dos principios determinan si el centro de contacto funcionará según el sistema o encontrará formas de eludirlo, y la diferencia se revela ya en la primera semana de operación. ### Preguntas y respuestas **¿Cómo se determina el peso de capacidad para cada canal?** Se mide cuánto tiempo de atención continua requiere cada tipo de tarea. Un chat en vivo ocupa a un agente casi por completo, mientras que un correo electrónico no es sincrónico. Un peso solo estimado suele ser incorrecto en dos semanas, por lo que se recomienda planificar un ciclo de calibración. **¿Cuántas habilidades (Skills) se deben definir?** Pocas y claras. Un exceso de habilidades crea escenarios en los que ningún agente cumple con todos los requisitos y la solicitud queda atascada sin asignación. Es preferible una habilidad básica con un 'fallback' definido. **¿Se requieren Entitlements para cada cliente?** No. Se define un valor predeterminado para todos los clientes y solo excepciones para aquellos con un contrato de servicio realmente diferente. Duplicar Entitlements para cada cuenta genera un mantenimiento insostenible. **¿Qué sucede con una solicitud para la que ningún agente está disponible?** Debe haber una regla de desbordamiento ('overflow') con un tiempo máximo de espera y una cola de respaldo. Sin esta regla, las solicitudes se quedan en la cola de asignación sin que nadie las vea, y el SLA se incumple silenciosamente. **¿Se puede depender únicamente del enrutamiento 'Push'?** Generalmente sí, y es la preferencia correcta, ya que 'Pull' permite a los agentes elegir tareas más fáciles. Una combinación razonable es 'Push' para la mayoría del trabajo y una cola 'Pull' limitada para tareas no urgentes. --- ## Salesforce Knowledge en Service Cloud: Cómo construir una base de conocimiento confiable para agentes y IA URL: https://hpi.pro/es/insights/salesforce-knowledge-management Las bases de conocimiento a menudo fracasan en su segundo año, no en el lanzamiento: los artículos se escriben una vez, nadie los mantiene y los agentes vuelven a preguntar en el chat interno. Esta guía describe un ciclo de vida sostenible que perdura en el tiempo, abordando el costo, los disparadores de creación, la revisión periódica y la medición del uso. También exploramos qué cambia cuando un agente de IA consulta la misma base. ## La respuesta breve Una base de conocimiento no es un proyecto de contenido, sino un proceso operativo. La pregunta que determina su supervivencia no es cuántos artículos se escribieron en el lanzamiento, sino qué impulsa la creación de un nuevo artículo y qué provoca la revisión de uno existente. Sin estos dos mecanismos, cualquier base de conocimiento se degrada a una carpeta de archivos que nadie abre. El control simple para la situación actual es: cuántos casos se cerraron este mes con un artículo vinculado. Por debajo del 30% significa que la base de conocimiento no forma parte del trabajo diario. ## El ciclo de vida de un artículo | Etapa | Responsable | Activador | | --- | --- | --- | | Creación | Agente que resolvió el caso | Un caso recurrente sin un artículo vinculado | | Aprobación | Editor de conocimiento o experto en la materia | Cola de aprobaciones con un tiempo objetivo | | Publicación | Editor | Definición de visibilidad: interna o pública | | Revisión | Propietario definido | Fecha de revisión o datos de uso | | Retiro | Propietario | Producto discontinuado o proceso modificado | La etapa que a menudo se omite es el retiro. Los artículos antiguos no son perjudiciales cuando son una minoría, pero una vez que representan una cuarta parte de la base, los agentes dejan de confiar en los resultados de búsqueda, y este es el punto de no retorno. ## El disparador que garantiza el crecimiento adecuado de la base El enfoque que funciona no es planificar una lista de temas de antemano, sino permitir que los datos de servicio la dicten. Una regla automática simple: un tipo de caso que se repitió más de cinco veces en un trimestre y cuyos cierres no están vinculados a un artículo, entra en la cola de escritura. De esta manera, la base de conocimiento refleja lo que sucede en la práctica y no lo que se estimó en una reunión de planificación. Una adición importante: el agente que escribió el artículo recibe crédito explícito. La contribución de conocimiento que no se contabiliza en ningún lugar se detiene después de unas semanas. ## Estructura de artículo que sirve tanto a la búsqueda como a la IA Un artículo escrito como un documento continuo es difícil de escanear rápidamente durante una llamada y difícil de recuperar con precisión por un modelo. Una estructura eficiente incluye: un título formulado como la pregunta que el cliente hace, una respuesta corta en el primer párrafo, pasos de acción numerados, condiciones y excepciones por separado, y el etiquetado de producto, versión y vigencia. La separación de las excepciones en una sección aparte es el punto importante: cuando se integran dentro de los pasos, tanto un agente bajo presión como un mecanismo de recuperación tienen dificultades para distinguir entre la regla y su excepción. ## Visibilidad: interna vs. pública El mismo tema a menudo requiere dos versiones. La versión interna incluye limitaciones conocidas, soluciones alternativas e instrucciones de escalada; la pública incluye solo lo que el cliente puede realizar. La gestión de esta separación se realiza a nivel del artículo, no a nivel de la base, para evitar que se creen dos bases que luego se bifurquen. Antes de abrir un portal de autoservicio, es recomendable verificar que las versiones públicas sean realmente autosuficientes. Un portal que remite a artículos parciales no reduce las consultas, sino que las desvía a otro canal, generalmente telefónico. El contexto operativo se detalla en [Implementación de Service Cloud](/es/insights/service-cloud-implementation). ## Qué cambia cuando un Agente de IA lee de la base Una base con la que los agentes se las arreglan a pesar de las deficiencias no está necesariamente lista para ser utilizada por un agente de IA. Un agente experimentado sabe cómo ignorar un artículo antiguo; un mecanismo de recuperación no. Se añaden tres requisitos: no hay dos artículos activos que ofrezcan respuestas contradictorias a la misma pregunta; cada artículo tiene una validez y una fuente claras; y se define explícitamente qué se puede mostrar al cliente. Un agente que cita un artículo interno o que combina dos fuentes contradictorias genera un daño a la confianza difícil de reparar. La profundidad en el tema se encuentra en [Grounding y RAG en Agentforce](/es/insights/agentforce-grounding-rag) y en [Preparación del conocimiento para Agentforce](/es/insights/agentforce-knowledge-readiness). ## Medición | Métrica | Qué revela | Umbral para revisión | | --- | --- | --- | | Tasa de adjuntar conocimiento | Si la base de conocimiento forma parte del trabajo | Menos del 30% | | Búsquedas sin resultados | Brechas de contenido reales | Lista semanal para la cola de escritura | | Artículos sin visitas en seis meses | Contenido superfluo o no encontrado en la búsqueda | Más del 25% de la base | | Tiempo desde la creación hasta la publicación | Si la cola de aprobaciones es un cuello de botella | Más de dos semanas | | Calificación "no ayudó" | Calidad de contenido específica | Concentración en un tema | La lista de búsquedas sin resultados es la fuente de planificación de contenido más económica y precisa, y casi siempre está infrautilizada. ## Conclusión Una base de conocimiento exitosa se construye de abajo hacia arriba, a partir de casos reales, y se mantiene mediante solo dos mecanismos: un disparador para la creación y un disparador para la revisión. Todo lo demás, incluida la adaptación para el uso de agentes de IA, se deriva del hecho de que el contenido está actualizado y no se contradice a sí mismo. ### Preguntas y respuestas **¿Cuántos artículos se necesitan para empezar?** Entre diez y veinte, cubriendo las consultas más frecuentes. Una base de conocimiento grande escrita de antemano queda obsoleta antes de usarse; una base pequeña que se actualiza a partir de casos reales crece de forma efectiva. **¿Quién debería escribir los artículos?** Los agentes que resuelven las consultas, con un editor que apruebe y unifique el contenido. La escritura por parte de un tercero genera contenido preciso que no siempre coincide con el lenguaje real que utilizan los agentes. **¿Puede el mismo artículo ser utilizado por agentes y clientes?** Generalmente no en su totalidad. Se requieren diferentes niveles de visibilidad: una parte interna (limitaciones, soluciones alternativas) y una parte pública. Las categorías de datos y canales gestionan esto a nivel de artículo. **¿Cómo se sabe que un artículo está obsoleto?** Se combinan la fecha de revisión, los datos de uso y las evaluaciones de los agentes. Un artículo que no ha sido visto en seis meses o que se ha marcado como inútil entra automáticamente en una cola de revisión. **¿Qué se requiere antes de que un agente de IA consulte la base de conocimiento?** Limpiar artículos contradictorios, indicar validez y fuente, y definir qué puede ser expuesto al cliente. Un agente que cita dos artículos contradictorios genera un daño mayor que la ausencia de respuesta. --- ## Integración del Contact Center con Service Cloud: CTI, Voice y Visión 360 del Cliente URL: https://hpi.pro/es/insights/service-cloud-cti-integration La integración de telefonía con Salesforce se mide en segundos: el tiempo que transcurre antes de que un agente vea quién llama y por qué. Esta guía aborda las decisiones cruciales que determinan el resultado: identificación de llamadas, Screen Pop, propiedad del enrutamiento, manejo de transferencias y desconexiones, y la elección entre Service Cloud Voice y un adaptador CTI existente. ## La respuesta corta La calidad de una conexión CTI se mide en tres segundos: desde que el agente responde hasta que ve quién llama, su historial y los registros abiertos. Si la identificación falla, el agente comenzará cada conversación preguntando “¿con quién hablo?”, haciendo que toda la inversión en telefonía integrada pase desapercibida. La decisión central no es qué adaptador elegir, sino **dónde se toma la decisión de enrutamiento**: en la centralita o en Salesforce. Ahí reside la mayor parte del riesgo y del costo. ## Decisión clave: quién gestiona el enrutamiento | Aspecto | Enrutamiento en centralita (adaptador CTI) | Enrutamiento en Omni-Channel (Voice) | | --- | --- | --- | | Origen de la decisión | IVR y reglas de la centralita | Disponibilidad y habilidades en Salesforce | | Balance entre canales | El teléfono se gestiona por separado del chat y el correo electrónico | Capacidad única para todos los canales | | Cambio de reglas | Depende del proveedor de telefonía | En la configuración de Salesforce | | Complejidad de la implementación | Relativamente baja | Alta, afecta la operación del centro de contacto | | Cuándo es adecuado | Centro de llamadas puramente telefónico, centralita madura | Centro de contacto omnicanal con carga mixta | El caso problemático es la asignación dual: la centralita asigna y el sistema reasigna. El resultado es que los agentes reciben llamadas mientras atienden un chat, y las métricas de disponibilidad no reflejan la realidad. Si se elige Voice, se desvinculan las reglas de asignación de la centralita; si se mantiene la centralita, no se activa Omni-Channel para el canal de voz. ## Identificación del llamante: un problema de datos antes que de tecnología La mayoría de los fallos del Screen Pop no son problemas de integración, sino de falta de normalización de los números de teléfono. El mismo cliente aparece como 050-1234567, +972501234567 y 0501234567 en tres sistemas diferentes, y la coincidencia falla. Lo que se necesita antes de la conexión: 1. **Formato unificado** - E.164 como estándar, con conversión en la entrada y no durante la búsqueda. 2. **Orden de búsqueda definido** - Primero Contacto, luego Cuenta, luego Caso abierto por número. El orden determina qué se muestra cuando hay varias coincidencias. 3. **Manejo de múltiples coincidencias** - Pantalla de selección breve, sin adivinanzas. En las centralitas empresariales y los números de centralita de clientes corporativos, esta es la situación habitual, no la excepcional. 4. **Manejo de la no identificación** - Pantalla de creación rápida, para que la llamada no finalice sin documentación. Los principios de identificación y unificación de registros se detallan en [Deduplicación y unificación de registros](/es/insights/salesforce-data-deduplication). ## Qué ocurre cuando la llamada no fluye sin problemas Los escenarios límite son los que determinan si el centro de contacto confía en el sistema: * **Transferencia entre agentes** - ¿El caso se transfiere con la llamada o se abre uno nuevo? Una transferencia que genera un segundo caso distorsiona la métrica FCR y la experiencia del cliente, que repite la historia dos veces. * **Corte en medio de la llamada** - Se requiere una regla de devolución de llamada con una ventana de tiempo, de lo contrario, las consultas desaparecen sin dejar rastro. * **Llamada saliente** - ¿Se contabiliza y se asocia al caso? Sin esto, los datos de la carga de trabajo del agente carecen de un tercio. * **Cola de espera y abandono** - Los abandonos deben estar disponibles en Salesforce, no solo en los informes de la centralita, de lo contrario, la imagen operativa es parcial. Cada uno de estos cuatro escenarios debe escribirse como un escenario de prueba de extremo a extremo antes de la puesta en marcha. La prueba de una llamada solo funcional no demuestra nada. ## Grabación, transcripción y privacidad La transcripción automática se ha vuelto accesible y económica, por lo que la tentación de aplicarla a todo es grande. Tres preguntas que deben responderse antes de proceder: ¿Cuál es la base legal para la grabación y el procesamiento? ¿Cuánto tiempo se guarda la transcripción y quién puede buscar en ella? ¿Y se utiliza el contenido para entrenar modelos? La transcripción es información sensible; incluye detalles que el cliente proporcionó verbalmente y que no habría introducido en un formulario. La restricción de acceso a nivel de campo y una política de retención definida son parte de la implementación, no una tarea posterior. ## Medición después de la activación | Métrica | Por qué es importante | | --- | --- | | Porcentaje de identificación automática | Medida directa de la calidad de los datos y la conexión | | Tiempo hasta Screen Pop | Más de dos segundos se percibe como lentitud | | Llamadas sin caso asociado | Revela lagunas en la documentación | | Casos duplicados al transferir | Revela un fallo en la continuidad | | Abandono en cola | Indicación de un fallo de asignación o dotación de personal | ## Resumen Una conexión CTI exitosa no se mide por la instalación del adaptador, sino por el hecho de que el agente inicie la llamada sabiendo quién está en la línea y qué está abierto, y que todos los escenarios anómalos (transferencia, desconexión, múltiples coincidencias) se hayan definido de antemano. La decisión sobre la ubicación del enrutamiento es la primera que debe cerrarse, ya que de ella se derivan el modelo operativo y el costo. ### Preguntas y respuestas **¿Cuál es la diferencia entre Service Cloud Voice y un adaptador CTI estándar?** Un adaptador CTI muestra la telefonía dentro de Salesforce, pero la asignación de llamadas permanece en la centralita. Voice traslada el enrutamiento directamente a Omni-Channel y proporciona transcripciones y datos de llamadas como registros. La diferencia fundamental radica en dónde se toma la decisión de asignación. **¿Por qué a veces no se activa el Screen Pop?** Generalmente, porque el número de la persona que llama no está normalizado: prefijo internacional, ceros iniciales o un formato diferente entre sistemas. Es un problema de datos, no de integración. **¿Qué se hace cuando un mismo número está asociado a varios clientes?** Es recomendable configurar previamente una pantalla de selección breve para el agente, en lugar de una suposición automática. Una selección automática errónea es peor que la falta de identificación, ya que genera documentación para el cliente incorrecto. **¿Es obligatorio grabar y transcribir todas las llamadas?** No, y en la mayoría de las organizaciones no es lo más adecuado. La grabación masiva requiere una política de retención, una base legal y control de acceso. Es preferible empezar con categorías definidas. **¿Quién es responsable cuando la llamada entra pero el registro no se crea?** Esto debe definirse por escrito antes del lanzamiento. Sin un único responsable de la ruta de principio a fin, cualquier incidencia se convierte en una disputa entre el proveedor de telefonía y el equipo de CRM. --- ## Red de Champions de Salesforce: Cómo construir un motor de adopción interna URL: https://hpi.pro/es/insights/salesforce-champions-network Un Champion que es solo un título simbólico no genera cambios. Le mostramos cómo seleccionar representantes locales, cuánto tiempo asignarles, qué incluye exactamente el rol, cómo incentivar y cómo evitar que la red se desvanezca después de dos meses. ## La respuesta breve La red de Champions es la infraestructura de distribución para la adopción en la organización. Los usuarios se dirigen a un colega cercano antes de abrir una solicitud de soporte, y confían más en este compañero que en un comunicado de la dirección. La red aprovecha esta dinámica en lugar de luchar contra ella. Sin embargo, un Champion sin una asignación de tiempo, sin una definición de rol y sin una influencia real en las prioridades es un título vacío. Estos tres componentes determinan si la red perdurará un año o se desvanecerá en un trimestre. ## Quién es adecuado — y quién no | Criterio | Por qué es importante | Señal de alerta | | --- | --- | --- | | Confianza de los compañeros | Determina si se acercan a él | Alguien asignado por estar disponible | | Experiencia en el proceso de negocio | Permite dar una respuesta correcta, no solo técnica | Conocimiento del sistema sin comprensión operativa | | Genuina disposición | Un rol voluntario genera compromiso | Nombramiento forzado por parte del gerente | | Respaldo del gerente directo | Determina si habrá tiempo para el rol | Acuerdos verbales únicamente | El error común es elegir al usuario más técnico. Este dará respuestas precisas que nadie pidió, y no identificará que el verdadero problema es que el proceso no es lógico. ## Definición de rol por escrito Sin una definición escrita, el rol se interpreta como "a quien se le muestran los fallos". La definición incluye cuatro responsabilidades: 1. **Soporte local** — Primera respuesta a preguntas del equipo y documentación de problemas recurrentes. 2. **Recopilación de feedback** — Transmisión de obstáculos y necesidades al foro central, incluyendo aquello que nadie informa oficialmente. 3. **Pruebas preliminares** — Participación en UAT y pruebas de cambios antes de su lanzamiento al equipo. 4. **Comunicación de cambios** — Explicación verbal de las novedades, en el lenguaje del equipo. Junto con las responsabilidades, también se define la asignación: de cuatro a seis horas semanales durante el período de lanzamiento. Si el gerente directo no aprueba la asignación por escrito, el rol se eliminará ante la primera situación de presión. ## El foro central es el corazón Una reunión quincenal de 45 minutos con una estructura fija: lo que surgió del campo, lo que se corrigió desde la reunión anterior, lo que se lanzará próximamente, y una pregunta abierta. Los dos primeros elementos son el motor: un Champion que ve que su solicitud fue implementada y comunicada en su nombre traerá cinco solicitudes adicionales. Un Champion cuyas tres solicitudes desaparecieron dejará de reportar. El foro también sirve como un canal de alerta temprana: quejas recurrentes que se escuchan allí llegan al Dashboard solo dos meses después. La conexión con la medición se detalla en [Salesforce Adoption Metrics](/es/insights/salesforce-adoption-metrics). ## Qué se ofrece a cambio Incentivos efectivos, según el orden de su eficacia comprobada: - **Influencia** — Un lugar permanente en la determinación de las prioridades para el próximo lanzamiento. - **Acceso temprano** — Visibilidad de los cambios antes que nadie y autoridad para decir "todavía no". - **Exposición gerencial** — Presentación de resultados a la gerencia una vez por trimestre. - **Desarrollo profesional** — Financiación de una certificación Salesforce o participación en una conferencia. - **Reconocimiento** — Mención nominal en cada actualización sobre una corrección originada por ellos. La recompensa económica es rara y no esencial. Lo que mata a las redes es la falta de influencia, no la falta de un bono. ## El rol de la red en el lanzamiento y la operación diaria Durante las dos semanas posteriores al "Go Live", los Champions son la primera línea de soporte en terreno, por lo que reciben capacitación una semana antes que los demás. La estructura se describe en [Salesforce Role-Based Training](/es/insights/salesforce-role-based-training). En la operación diaria, el rol cambia: incorporación de nuevos miembros, identificación de fricciones acumuladas y prueba de cambios antes del lanzamiento. Aquí, la red pasa de ser un mecanismo de lanzamiento a un mecanismo de mantenimiento que previene el retroceso y alimenta las correcciones discutidas en [Salesforce UX Simplification](/es/insights/salesforce-ux-simplification). ## Señales de declive y qué hacer | Señal | Causa común | Corrección | | --- | --- | --- | | Baja asistencia al foro | Las solicitudes no se implementan | Lanzar dos correcciones de su lista de inmediato | | Un Champion pide renunciar | Presión de objetivos en su puesto principal | Renovar la asignación con el gerente | | No hay solicitudes nuevas | La red se ha convertido solo en un canal de anuncios | Abrir un debate sobre obstáculos, no sobre actualizaciones | | Todas las solicitudes de un solo equipo | Representación parcial | Añadir un Champion en áreas carentes | ## Medición Tres métricas son suficientes: el número de problemas planteados a través de la red por trimestre, su tasa de implementación y la brecha de adopción entre equipos con un Champion activo y equipos sin él. Esta brecha es la justificación presupuestaria de todo el programa. La red en sí es un componente dentro de un [Salesforce Change Management Plan](/es/insights/salesforce-change-management-plan). ## Resumen Elija basándose en la confianza y no en el conocimiento técnico, formalice la asignación de tiempo por escrito con el gerente directo, celebre un foro quincenal donde las solicitudes realmente se implementen y recompense con influencia. Una red que siente que está cambiando el sistema perdurará años; una red simbólica desaparecerá en un trimestre. ### Preguntas y respuestas **¿Cuántos Champions son necesarios?** Una proporción común es un Champion por cada 15 a 25 usuarios, y al menos uno en cada equipo autónomo o ubicación geográfica. Menos Champions crean un cuello de botella; más dificulta el mantenimiento de la red. **¿Cuánto tiempo semanal se debe asignar a un Champion?** De cuatro a seis horas semanales durante el período de lanzamiento, y dos horas después. La asignación debe ser acordada con el gerente directo y restarse de los objetivos habituales; de lo contrario, el rol será el primero en ser descuidado. **¿Un Champion debe ser un usuario técnicamente avanzado?** No. El criterio más importante es la confianza de los compañeros y la experiencia en el proceso de negocio. El conocimiento del sistema se puede enseñar; la influencia social en el equipo no se puede asignar. **¿Cómo se incentiva a los Champions sin presupuesto?** Exposición a la gerencia, influencia real en la hoja de ruta (Roadmap), formación o certificación pagada por la organización y reconocimiento nominal en las actualizaciones. La influencia sobre las prioridades es, en la práctica, el incentivo más potente. **¿Qué hacer cuando la red de Champions disminuye después de dos meses?** Se deben verificar tres aspectos: si sus solicitudes se implementan realmente, si el gerente directo respalda la asignación de tiempo y si existe un foro regular. El declive casi siempre se debe a que el canal ha dejado de tener impacto. --- ## Optimización UX en Salesforce: Menos Campos, Menos Clics y Más Adopción URL: https://hpi.pro/es/insights/salesforce-ux-simplification Cada campo superfluo es un impuesto diario para cada usuario. Una metodología práctica para simplificar las interfaces en Salesforce: auditoría de uso de campos, la regla de los tres clics, diseño de layouts por rol y medición del tiempo de tarea antes y después. ## La respuesta corta Cinco segundos adicionales por cada entrada, multiplicados por treinta entradas al día, por cien usuarios, equivalen a una jornada laboral completa que se pierde diariamente debido a una interfaz recargada. La simplificación de la Experiencia de Usuario (UX) suele ser la acción con el Retorno de Inversión (ROI) más alto que se puede implementar en un sistema existente y, casi siempre, se basa en la eliminación más que en la construcción. Bastan tres herramientas: auditoría del uso de campos, prueba de los tres clics para cada tarea principal y adaptación del Layout según el rol y la etapa. ## Por qué las pantallas se hinchan Nadie diseñó una pantalla con 80 campos. Esta se desarrolló a partir de siete años de solicitudes puntuales, cada una de las cuales era razonable por sí misma. Tres mecanismos recurrentes: - **La solicitud de "solo un campo"**: el costo marginal parece nulo, el costo acumulado es enorme. - **Un campo que persiste después de un cambio de proceso**: nadie es responsable de eliminarlo. - **Un campo "cajón de sastre de seguridad"**: "quizás lo necesitemos para un informe futuro". Por lo tanto, la simplificación no es un proyecto único, sino una práctica constante: cada solicitud de un nuevo campo requiere la eliminación de otro o una justificación explícita. ## Paso 1 – Auditoría del uso de campos Para cada objeto principal, se genera una tabla con cuatro columnas: porcentaje de llenado en los últimos 12 meses, uso en informes, uso en automatizaciones e integraciones, y propietario del proceso declarado. | Hallazgo | Interpretación | Decisión | | --- | --- | --- | | Llenado inferior al 10%, sin uso en informe | Campo abandonado | Eliminación del Layout | | Llenado alto, sin uso en informe | Trabajo no consumido por nadie | Consulta con el propietario del proceso | | Llenado bajo, campo obligatorio | Los usuarios introducen un valor arbitrario | Eliminar la obligatoriedad o cambiar a picklist | | Llenado alto y uso en informe | Campo activo | Mantener, quizás reubicar al principio | La tercera fila es la más arriesgada: un campo obligatorio que se llena con un valor ficticio contamina los datos y erosiona la confianza. ## Paso 2 – Prueba de los tres clics Para cada tarea principal (actualizar etapa, documentar una llamada, cerrar un Case), se cuenta el número de clics y pantallas desde el inicio de la intención hasta su finalización. Más de tres clics para una tarea diaria justifican una corrección. Las herramientas disponibles son: Quick Actions en lugar de abrir un registro completo, edición desde una lista, Path con campos guía para cada etapa y componentes que aparecen solo en el contexto relevante. La pregunta guía es siempre la misma: ¿qué viene a hacer el usuario aquí y qué se interpone en su camino? ## Paso 3 – Layout según el rol y no según el objeto Una pantalla uniforme para todos los roles es una consolidación de todas las necesidades, lo que significa que es deficiente para todos. Un representante de ventas necesita ocho campos; un gerente de operaciones necesita otros cinco; el Back Office necesita campos de aprobación que no corresponden a los dos primeros. La separación por Record Type y perfil, combinada con Dynamic Forms para una visualización condicional según la etapa, reduce una pantalla de 60 campos a una de 12 campos relevantes. Importante: la visualización condicional no sustituye la decisión de negocio sobre lo que realmente se necesita. ## Paso 4 – La página de inicio como lista de trabajo La primera pantalla que el usuario ve debe responder a la pregunta "¿qué debo hacer ahora?", no mostrar gráficos generales. Una lista de tareas priorizadas, elementos estancados y excepciones que requieren atención. Este es el Retorno de Inversión (ROI) diario que justifica la entrada de datos, y es el factor clave para recuperar la adopción. Ver [Mejorar la adopción de Salesforce](/es/insights/recover-salesforce-user-adoption). ## Medición: antes y después Antes de la corrección, se mide el tiempo promedio de realización para tres tareas clave, con cinco usuarios reales y un cronómetro. Después de la corrección, se mide nuevamente con el mismo método. Una reducción del 30% o más en el tiempo de la tarea es un resultado aceptable en la primera fase de simplificación. Además, se monitorea la calidad de los datos y la tasa de ejecución de la acción principal, según los [KPIs de adopción de Salesforce](/es/insights/salesforce-adoption-metrics). Una simplificación auténtica mejora ambos; si el tiempo disminuye, pero la calidad se ve afectada, significa que se eliminó un campo necesario. ## Objeciones y cómo responderlas "Pero necesitamos el campo para un informe": ¿quién generó ese informe en el último año? "El gerente X lo solicitó": ¿el proceso que lo justificaba sigue existiendo? "Puede que lo necesitemos en el futuro": se puede restaurar en una hora, y los datos históricos se conservan incluso después de eliminarlo del Layout. Estas objeciones se gestionan dentro del proceso de cambio organizacional, no como una discusión técnica. Véase [Gestión del cambio en Salesforce](/es/insights/salesforce-change-management-plan). ## Resumen Realice una auditoría del uso de campos, elimine los abandonados, reduzca los campos obligatorios a dos por etapa, cree un Layout por rol y transforme la página de inicio en una lista de trabajo. Mida el tiempo de la tarea antes y después; esta es la evidencia que justificará la siguiente fase. ### Preguntas y respuestas **¿Cómo saber qué campos se pueden eliminar?** Ejecute un informe de uso de campos: porcentaje de registros completados en los últimos 12 meses y uso en informes y automatizaciones. Un campo con bajo nivel de llenado que no aparece en ningún informe o automatización es candidato a ser eliminado. **¿Es mejor eliminar campos o solo ocultarlos?** Comience por eliminar el campo del layout, manténgalo así durante un trimestre y solo entonces elimínelo definitivamente. La eliminación del layout ofrece el máximo beneficio al usuario sin riesgo de pérdida de datos históricos. **¿Cuántos campos obligatorios son razonables en una pantalla?** Un máximo de cinco en total a lo largo de todo el proceso, y no más de dos en cada etapa. Cualquier campo obligatorio adicional debe tener un propietario que justifique su necesidad y quién utiliza ese dato. **¿Los Dynamic Forms resuelven el problema?** Son una herramienta excelente para la presentación condicional según la etapa o el perfil, pero no sustituyen una decisión de negocio. Una pantalla saturada que ha sido parcialmente oculta con Dynamic Forms sigue ocultando un proceso que no ha sido consensuado. **¿Cuánto tiempo toma un proyecto de simplificación?** La auditoría y planificación toman entre dos y tres semanas, y la implementación de la primera fase entre tres y cuatro semanas. Este es uno de los proyectos con la mejor relación impacto-esfuerzo en Salesforce. --- ## ¿Cómo recuperar la adopción de Salesforce después de un lanzamiento fallido? URL: https://hpi.pro/es/insights/recover-salesforce-user-adoption Un lanzamiento fallido no es un problema de capacitación. Esta guía de rehabilitación práctica le muestra cómo diagnosticar la causa del abandono, qué corregir en los primeros 30 días y cómo restaurar la confianza sin anunciar un 'relanzamiento', así como cuándo es mejor reducir el sistema en lugar de expandirlo. ## La respuesta breve Cuando los usuarios abandonan Salesforce, la razón casi nunca es "no entendieron el sistema". La razón es que el sistema les exigía más de lo que les devolvía. La recuperación de la adopción comienza con un diagnóstico del precio que paga el usuario, no con capacitación adicional. La secuencia práctica: dos semanas de diagnóstico, 30 días de reparaciones perceptibles y luego un ciclo de gestión regular basado en los datos. La capacitación solo se introduce después de que el sistema ya vale el tiempo invertido en él. ## Cinco razones de abandono y cómo distinguirlas | Causa | Señal de identificación en el campo | Corrección adecuada | | --- | --- | --- | | Carga de ingreso | Formularios largos, campos obligatorios sin comprador | Eliminación de campos, valores predeterminados, automatización | | Desconfianza en los datos | Todos mantienen hojas de cálculo "en la sombra" | Limpieza de datos + fuente única de verdad declarada | | Falta de valor recurrente | El usuario ingresa y no recibe nada a cambio | Listas de trabajo, vistas personalizadas, alertas | | Gestión no basada en el sistema | Revisión semanal desde un archivo externo | Traslado del foro a un Dashboard | | Rendimiento e interfaz | Pantallas lentas, navegación confusa | Optimización y simplificación del Layout | El diagnóstico en sí lleva dos semanas: diez conversaciones con usuarios reales (no representantes de usuarios), una hora de observación del trabajo real de tres roles, y extracción de datos de uso real según el enfoque descrito en [Métricas de Adopción de Salesforce](/es/insights/salesforce-adoption-metrics). ## La ley del retorno: lo que el usuario obtiene en 30 segundos Esta es la prueba central. Abra la pantalla principal de un rol que abandona y pregunte: ¿Qué recibe aquí que no obtendría sin el sistema? Si la respuesta es "nada, solo ingresa datos", el abandono es completamente lógico. Retornos que funcionan en la práctica: la lista de tareas del día ordenada por prioridad; un historial completo del cliente sin buscar en correos electrónicos; un recordatorio automático antes de una reunión; un formulario de propuesta que se genera con un solo clic. Cada uno de ellos ahorra tiempo real y, por lo tanto, genera uso sin necesidad de cumplimiento forzoso. ## La primera ola de correcciones: 30 días Seleccione solo entre cinco y ocho correcciones, todas ellas perceptibles en el día a día, todas entregables en un mes. Composición recomendada: 1. Eliminación del 30%-50% de los campos en el formulario central, con evidencia de que nadie los utiliza. 2. Un máximo de dos campos obligatorios en cada etapa del proceso. 3. Una vista de "Mi trabajo de hoy" para cada rol principal. 4. Corrección de tres problemas de calidad de datos que los usuarios citan como prueba de que no se puede confiar en el sistema. 5. Una automatización que elimina el trabajo manual repetitivo. 6. Optimización de la pantalla más lenta. Lo que no entra en esta ola: nuevas funcionalidades, módulos adicionales, nuevas integraciones. La expansión en un momento de crisis de confianza agrava el daño. La dirección correcta en esta etapa es la simplificación, como se describe en [Simplificación de la UX en Salesforce](/es/insights/salesforce-ux-simplification). ## Reconstruir la confianza La confianza no vuelve con un correo electrónico. Vuelve con tres patrones recurrentes: correcciones entregadas en el tiempo prometido, transparencia sobre lo que no se hará y reconocimiento a quien planteó el problema. Un mecanismo simple que funciona: una lista de solicitudes abierta a toda la organización con su estado, una liberación quincenal y un breve mensaje que detalla lo que se corrigió y gracias a quién. En seis semanas, esto cambia la conversación de "el sistema no funciona" a "he presentado una solicitud". La red humana que lleva este mensaje es la red de Champions, y su construcción se detalla en [Red de Champions en Salesforce](/es/insights/salesforce-champions-network). ## El ciclo de gestión es la herramienta más poderosa El factor más influyente en la adopción es lo que el gerente directo supervisa. Mientras este gestione el equipo desde un archivo externo, el sistema es opcional. En el momento en que la revisión semanal del Pipeline o los Casos se realiza desde un Dashboard en vivo, la actualización se convierte en un interés personal del representante. Este es un cambio de gestión que requiere el respaldo de un Sponsor, y por lo tanto es parte del plan de gestión del cambio y no del plan de trabajo técnico. Véase [Gestión del Cambio en Salesforce](/es/insights/salesforce-change-management-plan). ## Cuándo reducir en lugar de expandir Si el sistema contiene módulos sin usar, procesos construidos para escenarios teóricos y automatizaciones que nadie entiende, el paso correcto es una contracción controlada. La desactivación de lo que no se usa reduce la carga cognitiva, acorta pantallas y disminuye el mantenimiento. Muchas organizaciones descubren que la mejora más significativa en la adopción provino de la eliminación, no de la construcción. ## Métricas para la recuperación Mida solo cuatro durante el trimestre: tasa de ejecución de la operación principal por rol, tiempo promedio para completar el proceso central, tasa de uso de archivos "en la sombra" (revisado manualmente), y una métrica de calidad de datos. Un aumento en los tres primeros sin mejora en el cuarto significa que se llenó el sistema más rápido, no mejor. ## Resumen La recuperación de la adopción es un proyecto de eliminación de fricciones y retorno de valor, no un proyecto de convicción. Diagnostique el precio que paga el usuario, entregue una ola de correcciones perceptibles en 30 días, traslade la gestión al sistema, y solo entonces regrese a la capacitación y expansión. ### Preguntas y respuestas **¿Cuánto tiempo lleva rehabilitar la adopción después de un lanzamiento fallido?** El diagnóstico toma dos semanas, la primera ola de correcciones 30 días y la estabilización medible dentro de un trimestre. Recuperar la confianza gerencial toma más tiempo, generalmente dos trimestres en los que los resultados se presentan de manera consistente. **¿Deberíamos anunciar un 'relanzamiento'?** Generalmente no. Un anuncio repetido les recuerda a los usuarios el fracaso y eleva las expectativas. Es preferible una ola de correcciones discretas que se sienta en el trabajo diario, seguida de la comunicación de los resultados. **¿Qué hacer cuando los gerentes continúan trabajando en Excel en paralelo?** Eliminar Excel como fuente legítima para la discusión gerencial. Mientras la revisión del Pipeline se realice a través de un archivo, no hay un incentivo real para actualizar el sistema. Es una decisión gerencial, no técnica. **¿Es mejor reemplazar el sistema que rehabilitarlo?** Casi nunca. En el 80% de los casos, la causa del fracaso es el proceso, los datos o la interfaz, y todos se trasladarán con usted al siguiente sistema. Un reemplazo solo se justifica cuando la brecha es en la capacidad básica del producto. **¿Quién debe liderar la rehabilitación?** Un propietario de proceso de negocio senior con el mandato de cambiar el proceso, no solo un gerente de TI. La mayoría de las correcciones requeridas son decisiones comerciales: qué dejar de exigir, quién es responsable de un dato y qué se mide. --- ## ¿Reparar o Reconstruir Salesforce? Un Marco de Decisión para Sistemas Existentes URL: https://hpi.pro/es/insights/salesforce-rebuild-vs-refactor La decisión entre una corrección puntual, una refactorización o una reconstrucción a menudo se toma por "sensación", razón por la cual el problema reaparece dos años después. Esta guía presenta cuatro pruebas objetivas, explica por qué la reconstrucción casi siempre supera la estimación inicial y describe una hoja de ruta para una sustitución gradual. ## La respuesta corta Las tres opciones no se encuentran en un mismo continuo. **Repair** aborda el síntoma, **Refactor** modifica una implementación sin alterar el comportamiento, y **Rebuild** cambia el modelo subyacente. La decisión se basa en una pregunta clave: ¿el problema reside en cómo se implementaron las cosas, o en lo que se definió inicialmente? Si el modelo de datos es sólido y el problema se presenta en automatizaciones complejas y permisos intrincados, entonces es un Refactor. Si el mismo objeto se utiliza en tres procesos contradictorios y no se puede generar informes sobre él, esto indica un problema de raíz, y en ese caso, Rebuild entra en consideración. ## Cuatro pruebas decisivas | Prueba | Apunta a Refactor | Apunta a Rebuild | | --- | --- | --- | | Modelo de datos | Válido, sufre de exceso de campos | Objetos que sirven a propósitos contradictorios | | Origen del problema | Rendimiento, duplicidad de automatizaciones | Imposibilidad de generar informes o de extender | | Alcance de los usuarios afectados | Parcial, se puede aislar | Universal en todos los procesos | | Costo de las pruebas de regresión | Se puede probar un área específica | Cualquier cambio requiere regresión completa | Tres indicadores que apuntan en la misma dirección son suficientes para tomar una decisión. Una división entre los indicadores generalmente significa que el problema es más local de lo que parece. ## Por qué un Rebuild es más costoso de lo estimado La estimación habitual considera la reconstrucción. Sin embargo, casi siempre omite cuatro elementos: la migración de datos históricos con todas sus excepciones acumuladas, la reconstrucción de las integraciones, cada una acordada con terceros, un período de funcionamiento en paralelo donde conviven ambos sistemas, y una capacitación completa y nueva para todos los usuarios. En la práctica, estos cuatro elementos suelen constituir más de la mitad del costo. Una organización que considera un Rebuild y no los ha valorado está comparando una manzana con media naranja. ## El camino práctico: Reemplazo gradual Incluso cuando la decisión es Rebuild, ejecutarlo como un proyecto de "detener y reemplazar" es un riesgo en sí mismo. El enfoque que funciona es un reemplazo área por área: 1. **Se construye el nuevo modelo junto al antiguo** - nuevos objetos, sin tocar lo existente. 2. **Se transfiere un proceso completo** - con sus usuarios, datos e informes. 3. **Se desactiva el equivalente antiguo** - este es el paso que la mayoría de las organizaciones postergan, y es lo que duplica el proyecto. 4. **Se repite** hasta que el sistema antiguo esté vacío. El tercer paso es la prueba. Un sistema donde tanto lo antiguo como lo nuevo coexisten en paralelo durante un año ha aumentado los costos y no ha reducido la deuda. ## Lo que debe cambiar en cualquier caso Ambos enfoques fallan si el mecanismo de cambio permanece inalterado. Una gobernanza mínima —quién aprueba un cambio en el modelo, qué pruebas son obligatorias antes de la implementación, y quién es el propietario de cada área— es la condición necesaria para evitar regresar al mismo punto. La priorización de la deuda se detalla en [Priorización de la deuda técnica de Salesforce](/es/insights/salesforce-technical-debt-prioritization), y los signos de advertencia previos en [8 señales de una actualización de Salesforce](/es/insights/salesforce-system-upgrade-signs). ## Resumen La elección no es entre "reparar" o "empezar de nuevo", sino entre corregir una implementación o corregir una definición. En la mayoría de los casos que parecen ser un Rebuild, se esconde un modelo de datos sólido que ha sido enterrado bajo una década de automatizaciones; esto se limpia en fases, no mediante una eliminación total. ### Preguntas y respuestas **¿Cuándo es la reconstrucción realmente la opción correcta?** Cuando el modelo de datos en sí mismo es defectuoso, por ejemplo, un solo objeto que sirve a tres procesos diferentes, y su corrección requiere una migración de todos modos. Si la raíz del problema son solo automatizaciones complejas, una refactorización es significativamente menos costosa. **¿Un nuevo Org resuelve el problema?** Solo si la causa del caos fue la falta de gobernanza. Sin reglas de cambio, pruebas y propiedad clara, un nuevo Org llegará a la misma situación en dos años, esta vez con dos sistemas en paralelo. **¿Cuánto tiempo lleva una refactorización seria?** Para un alcance mediano, de tres a seis meses en fases, no como un proyecto único. Cada fase debe ofrecer una mejora medible por sí misma, de lo contrario, la financiación se detendrá a mitad de camino. **¿Qué se hace con el desarrollo continuo durante el trabajo?** Solo se congela el área bajo tratamiento, no todo el sistema. Una congelación general genera presión empresarial que conduce a soluciones alternativas, y cada solución alternativa añade nueva deuda precisamente donde se está limpiando. **¿Cómo se convence a la dirección para financiar una limpieza que no añade nuevas funcionalidades?** Traduciendo la deuda en un costo operativo medible: horas de soporte, fallos de integración, tiempo prolongado para cada cambio. La deuda presentada como tiempo y no como calidad de código obtiene financiación. --- ## Priorización de deuda técnica en Salesforce: qué arreglar primero y por qué URL: https://hpi.pro/es/insights/salesforce-technical-debt-prioritization Una lista de deuda técnica de cien líneas no es una herramienta, sino una fuente de frustración. Esta guía presenta un sistema de puntuación de cuatro dimensiones que genera un orden claro, explica qué tipo de deuda debe priorizarse independientemente de la puntuación y cómo traducir la deuda a un lenguaje que consiga financiación. ## La respuesta corta La deuda técnica no se mide por la calidad del código, sino por el coste que impone a cualquier cambio futuro. Por lo tanto, la priorización no es sobre "lo que es más antiestético", sino sobre **lo que encarece más el próximo trabajo**. La regla de clasificación rápida: un elemento que hace que cualquier cambio en su área requiera pruebas de regresión extensas, es el primero en ser abordado. Multiplica el coste de cualquier otra actividad del programa. ## Puntuación en cuatro dimensiones | Dimensión | Pregunta | Ponderación | | --- | --- | --- | | Exposición de negocio | ¿Qué sucede si falla en un momento de máxima carga? | Alta | | Frecuencia | ¿Cuántas veces al día se accede a este elemento? | Alta | | Dependencia | ¿Cuántas otras áreas están bloqueadas debido a esto? | Media | | Esfuerzo | ¿Cuánto cuesta corregirlo en un entorno controlado? | Inversa | La puntuación no es una ciencia exacta. Su valor real reside en que obliga a una conversación explícita entre quien conoce el riesgo técnico y quien conoce el impacto en el negocio, generando un orden defendible ante los directivos. ## Tres tipos de deuda que se saltan la cola Independientemente de la puntuación, tres tipos de deuda se abordan primero: 1. **Deuda que bloquea las pruebas** - Ausencia de un entorno Sandbox funcional o datos de prueba. Cualquier otra corrección realizada sin esto se hace a ciegas. 2. **Deuda de permisos** - Un modelo de visibilidad que ha perdido coherencia es una exposición regulatoria activa, no una mera inconveniencia. 3. **Deuda concentrada en una sola persona** - Cuando solo una persona entiende un componente, el riesgo no es técnico, sino organizacional. ## Cómo presentar la deuda para obtener presupuesto La dirección no financia "la limpieza de automatizaciones". Financia la reducción de tiempo y costes. La traducción se realiza en tres líneas por cada elemento: cuántas horas de soporte consume por trimestre, cuántos días añade a cada cambio en su área, y cuál es la exposición si falla. Quien presenta "tres solicitudes de cambio por trimestre, cada una prolongada dos semanas debido al mismo componente" obtiene aprobación. Quien presenta un diagrama de dependencias, no. ## Cuota fija, no operación única El patrón que fracasa: un gran proyecto de limpieza cada dos años. El patrón que funciona: una cuota fija del 15% al 20% de cada ola dedicada a la deuda, establecida de antemano y no negociable en cada sprint. Además de la cuota, es necesaria al menos una regla de prevención; por ejemplo, la prohibición de añadir nuevas automatizaciones a un objeto que ya tiene varias antes de consolidarlas. Sin prevención, la velocidad a la que se genera deuda supera la velocidad de limpieza. La relación con la infraestructura de desarrollo se detalla en la [Estrategia de Sandboxes y DevOps](/es/insights/salesforce-sandbox-devops-strategy). ## Resumen Priorizar la deuda técnica es un ejercicio de economía y no de estética: se corrige lo que encarece el siguiente cambio, se anticipa lo que bloquea las pruebas y lo que genera exposición, y se establece una cuota que previene su reaparición. Una lista de diez elementos clasificados vale más que cien elementos mapeados. ### Preguntas y respuestas **¿Qué porcentaje de la capacidad actual se debe destinar a la deuda técnica?** Entre el 15% y el 20% de cada ciclo, como asignación fija. Una asignación variable según la presión desaparecerá en dos trimestres, ya que siempre habrá algo más urgente. **¿Qué tipo de deuda no se debería arreglar en absoluto?** La deuda en un área que se prevé reemplazar o eliminar en el próximo año, y la deuda que no se traduce en un costo operativo medible. La limpieza por el mero hecho de limpiar compite con los mismos recursos. **¿Cómo se mide si la priorización ha sido efectiva?** Con tres métricas: tiempo promedio para implementar una solicitud de cambio, cantidad de errores de producción recurrentes y número de áreas que requieren una regresión completa en cada lanzamiento. La mejora en estas es la prueba. **¿Qué hacer cuando la deuda se genera más rápido de lo que se elimina?** Esto no es un problema de capacidad, sino de gobernanza. Sin una regla que prohíba agregar nuevas automatizaciones a un objeto antes de consolidar las existentes, cualquier limpieza es temporal. **¿La falta de documentación se considera deuda técnica?** Sí, y con un alto nivel de riesgo cuando el conocimiento se concentra en una sola persona. No se ve en los informes, pero es lo que hace que cada cambio dependa de la disponibilidad de alguien específico. --- ## Optimización del rendimiento de Salesforce en grandes organizaciones: diagnóstico, planificación y medición URL: https://hpi.pro/es/insights/salesforce-performance-optimization La lentitud en Salesforce rara vez se debe a un único problema, sino a la acumulación de una pantalla sobrecargada, consultas no selectivas y automatizaciones redundantes. Esta guía presenta un método de diagnóstico por capas —navegador, pantalla, servidor, datos, integración— y métricas que permiten demostrar una mejora tangible. ## La Respuesta Breve El bajo rendimiento en Salesforce es un síntoma acumulativo: una página de registro con 14 componentes, tres automatizaciones que se ejecutan en el mismo evento de guardado, una consulta que escanea un millón de registros y una integración que extrae datos en horas pico. La única manera de mejorar sin malgastar el presupuesto es medir por capas, identificar la capa dominante y abordarla —y luego volver a medir. ## Las Cinco Capas y Qué Medir en Cada Una | Capa | Síntoma Típico | Herramienta de Medición | Acción Común | | --- | --- | --- | --- | | Navegador y Red | Lentitud solo en algunos usuarios | Aplicación Lightning Usage por usuario | Latencia organizacional, versión del navegador, VPN | | Página y Componentes | EPT alto en una página de registro central | EPT por Página, Modo Depuración | Reducción de componentes, carga diferida, pestañas (Tabs) | | Automatización | Guardado lento, tiempo de espera (Timeout) en actualizaciones masivas | Registros de depuración (Debug Logs), Flujos ejecutados (Flow Interviews) | Consolidación de Flows, transición a asíncrono | | Datos y Consultas | Informes que fallan, vista de lista (List View) atascada | Plan de Consulta (Query Plan), Trabajos de Apex (Apex Jobs) | Filtrado selectivo, Índice, Archivación | | Integración | Picos de carga en horas fijas | Monitoreo de Eventos (Event Monitoring), Uso de API (API Usage) | Bulk API, ventanas de ejecución, Throttling | ## Trabajo con Grandes Volúmenes de Datos Por encima de aproximadamente un millón de registros en un objeto (Object), las reglas del juego cambian. La asimetría de datos (Data Skew) —por ejemplo, 200 mil cuentas (Accounts) asignadas al mismo propietario (Owner) o padre (Parent)— crea bloqueos de fila y ralentiza cada actualización masiva. La solución es distribuir la propiedad, no agregar hardware, que de todos modos no está bajo su control. Al mismo tiempo, conviene considerar la archivación: los registros cerrados de hace cinco años que nadie consulta encarecen cualquier consulta que realice un escaneo. ## Páginas: Menos es Más Rápido La página de registro (Record Page) promedio en una organización de Salesforce con antigüedad acumula componentes a razón de dos o tres por año, porque cada parte interesada solicita "un widget más". Cada componente Lightning realiza sus propias llamadas. Dos acciones generan la mayor mejora: mover componentes secundarios a pestañas (Tabs) separadas que se cargan solo al hacer clic, y aplicar visibilidad de componentes (Component Visibility) según el tipo de registro (Record Type) o el rol, de modo que el usuario solo vea lo que le es relevante. La combinación de ambos reduce el EPT en decenas de puntos porcentuales sin cambios en el código. ## El Orden de Acciones que Funciona Comenzar con una semana de medición sin cambios, para establecer una línea base (Baseline) fiable para cinco páginas centrales y tres procesos clave. Luego, abordar las páginas, que es lo más económico y rápido. En la tercera etapa, consolidar las automatizaciones por objeto (Object), y solo en la cuarta etapa intervenir en las consultas y el modelo de datos. Las integraciones se abordan en paralelo, si la medición ha demostrado que son el factor causante. La lógica de este orden es económica: las primeras capas son económicas y reversibles, las últimas son costosas y requieren pruebas de regresión. Una expansión sobre este tema aparece en [Salesforce Health Check](/es/insights/salesforce-health-check-guide) y en [Señales para la Actualización del Sistema](/es/insights/salesforce-system-upgrade-signs). ## Riesgos Comunes y Acciones Preventivas El mayor riesgo es la optimización sin una línea base (Baseline): se realizan diez cambios, los usuarios siguen quejándose y no hay forma de saber qué ayudó. Medir antes y después de cada cambio significativo es una condición, no un lujo. Un segundo riesgo es abordar el síntoma más ruidoso. La página de la que más se quejan no es necesariamente la más lenta; a veces, es simplemente la que se abre más veces al día. Un tercer riesgo es modificar las automatizaciones sin cobertura de pruebas: la consolidación de Flows es la acción con mayor potencial para romper silenciosamente la lógica de negocio. ## Cómo Medir el Éxito Cuatro métricas son suficientes: EPT promedio en las cinco páginas principales, tiempo de guardado (Save) en el proceso de negocio principal, número de fallos de tiempo de espera (Timeout) y límites de gobernador (Governor Limit) por mes, y el porcentaje de consultas que tardan más de cinco segundos. Una quinta métrica —complementaria y no técnica— es el número de quejas de rendimiento en el Service Desk, que debería disminuir con la mejora efectiva. ### Preguntas y respuestas **¿Por dónde empezar cuando los usuarios se quejan de que 'el sistema está lento'?** Empiece por medir, no por adivinar. La aplicación Lightning Usage revela qué pantallas y usuarios experimentan lentitud, y el EPT por página de registro señala el componente problemático. Una queja general sin mediciones a menudo conduce a corregir el componente equivocado. **¿Qué es una consulta no selectiva y por qué es crítica?** Es una consulta cuyo filtro no está soportado por un índice, forzando un escaneo de una tabla grande. Con más de un millón de registros, falla por tiempo de espera o ralentiza cualquier proceso que dependa de ella. La solución: filtrar por campos indexados, evitar NULL y LIKE abiertos, y solicitar un índice personalizado. **¿Cuándo se justifica una Skinny Table?** Cuando existe un informe o vista de lista central que extrae pocos campos de un objeto con millones de registros, y el filtrado ya es óptimo. Esto es una solicitud al Soporte de Salesforce, no una configuración autónoma, y resuelve la lectura, no la escritura ni la automatización intensiva. **¿La sustitución de Process Builder por Flow mejora el rendimiento?** Generalmente sí, pero no por la herramienta en sí, sino por la consolidación. El verdadero beneficio proviene de reducir el número de automatizaciones que se ejecutan en el mismo objeto y de trasladar las cargas de trabajo pesadas al procesamiento asíncrono, no por el mero cambio. **¿Qué mejora es razonable esperar?** En un proyecto de diagnóstico y optimización focalizada, una reducción del 30% al 50% en el tiempo de carga de las pantallas más pesadas en seis a diez semanas es un objetivo realista. Mejoras más significativas suelen requerir un cambio en el modelo de datos o la arquitectura de integración. --- ## Implementación de Salesforce en su organización: La guía completa desde el diseño hasta el Go Live URL: https://hpi.pro/es/insights/salesforce-implementation-guide La mayoría de las implementaciones de Salesforce no fallan en el desarrollo, sino entre etapas: un paso apresurado del Discovery a la construcción, una migración sin un ensayo general y un UAT sin un verdadero responsable. Esta guía detalla el camino completo por fases, entregables y validaciones. ## 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](/es/insights/replace-crm-with-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](/es/insights/crm-implementation-mistakes). ## 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](/es/insights/salesforce-project-team-roles). ### 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](/es/insights/salesforce-sandbox-devops-strategy). ## 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](/es/salesforce-implementation) 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 ### Preguntas y respuestas **¿Cuánto tiempo toma una implementación completa de Salesforce en una empresa mediana?** Para una empresa con 30-80 usuarios y procesos básicos de ventas y servicio, una implementación completa desde el Discovery hasta el Go Live oscila entre 10 y 16 semanas. Los proyectos con integraciones complejas a sistemas ERP o de facturación se extienden a 20-24 semanas, principalmente debido a la migración y las pruebas. **¿Cuál es la diferencia entre el Diseño de Solución y la documentación de requisitos estándar?** El Diseño de Solución incluye el modelo de datos, el mapa de permisos, el diagrama de integraciones y las decisiones arquitectónicas con alternativas descartadas. La documentación de requisitos estándar describe lo que el usuario desea; el Diseño de Solución describe cómo el sistema lo construirá en la práctica y el costo de cada elección. **¿Se puede omitir la fase de UAT cuando los plazos son ajustados?** Se puede reducir su alcance, pero no se debe prescindir de ella. Una versión mínima del UAT implica probar 5-8 escenarios críticos de extremo a extremo con los dueños del proceso. La omisión total casi siempre traslada los problemas a las primeras semanas después del Go Live, cuando el costo de corrección es mayor. **¿Quién es responsable de la calidad de los datos en la migración desde Excel o un sistema antiguo?** La responsabilidad profesional sobre las reglas de conversión y limpieza recae en el equipo de implementación, pero la responsabilidad sobre la exactitud del contenido empresarial permanece con el propietario de los datos en la organización. Por lo tanto, se recomienda nombrar a un 'Data Owner' por objeto, quien aprueba el resultado de la migración antes de que se cargue en el entorno de producción. **¿Qué sucede realmente durante el período de Hypercare?** Generalmente, de dos a cuatro semanas durante las cuales el equipo de implementación está disponible para soporte cercano, monitoreando registros de errores y la adopción diaria, y corrigiendo fallas de alta prioridad dentro de un día hábil. Al final del período, la responsabilidad se transfiere formalmente al equipo de mantenimiento rutinario o al soporte interno. --- ## Arquitectura Salesforce para empresas: cómo diseñar un sistema escalable URL: https://hpi.pro/es/insights/crm-architecture-guide Una organización que añade objetos personalizados, flujos o integraciones punto a punto sin una arquitectura documentada acumula una deuda técnica que se revela solo al intentar incorporar un nuevo negocio o país. Este artículo desglosa la arquitectura en seis capas prácticas. ## La respuesta corta Una buena arquitectura de Salesforce no se mide por la cantidad de componentes construidos, sino por la capacidad de la organización para incorporar un nuevo negocio, producto o mercado sin desmantelar lo que ya funciona. El problema más común que observamos no es una elección tecnológica incorrecta, sino la ausencia de una capa de decisiones documentada: quién es el propietario de cada objeto, por qué se eligió Flow en lugar de Apex, y por qué existen cinco integraciones separadas en lugar de una única capa de Middleware. Este artículo desglosa la arquitectura en seis capas que deben planificarse en conjunto y no de forma aislada: modelo de datos y objetos, Sharing y permisos, automatización, integraciones, estrategia de Org y DevOps con Scalability. Una explicación ampliada sobre el manejo de errores de integración se encuentra en [Monitoreo de integraciones de Salesforce](/es/insights/salesforce-integration-error-handling). ## Modelo de datos y objetos: la base sobre la que todo se apoya Un error recurrente en muchas organizaciones: se crea un nuevo Custom Object para cada requisito que proviene del negocio, sin verificar si se puede usar un campo adicional en un objeto existente o un Record Type. El resultado después de dos o tres años es un Org con 80-120 objetos personalizados, algunos de ellos duplicados en significado, sin documentación que explique el propósito de su creación. El principio rector es preguntar antes de crear cualquier objeto: quién es el propietario del negocio, cuál es la fuente de la verdad (Salesforce o un sistema externo), y qué sucede cuando un registro se elimina o se duplica. Las empresas que gestionan un catálogo de productos complejo, por ejemplo, suelen crear un Object separado para cada categoría en lugar de usar Record Types en Product2, lo que genera una carga de mantenimiento innecesaria en cada actualización. Tabla útil para evaluar la madurez del modelo de datos: | Componente | Pregunta de verificación | Señal de advertencia | | --- | --- | --- | | Objetos personalizados | ¿Existe un objeto similar que pueda extenderse? | Dos objetos con prácticamente los mismos campos | | Campos | ¿Se utiliza el campo para más de un proceso? | Más de 800 campos en un objeto central | | Relaciones | ¿Se eligió Master-Detail o Lookup intencionalmente? | Master-Detail elegido "por defecto" | | External ID | ¿Cada objeto sincronizado tiene una clave única? | Sincronización solo por nombre o fecha | ## Sharing y permisos: la capa que se rompe silenciosamente Un modelo de permisos laxo no se detecta de inmediato; se revela cuando alguien ve un dato que no debería ver, o cuando un informe de gerencia muestra menos filas de lo esperado porque una Sharing Rule bloquea el acceso. La elección entre Role Hierarchy, Organization-Wide Defaults, Sharing Rules y Permission Sets debe derivarse de la estructura organizativa real, no de la estructura jerárquica oficial en el organigrama. Un anti-patrón común: otorgar "View All" o "Modify All" a nivel de perfil para "resolver" un problema de permisos bajo presión de tiempo, sin luego volver y restringirlos. Esto funciona a corto plazo y crea una amplia exposición de información a largo plazo, especialmente en regulaciones como finanzas o salud. Permission Set Groups permiten construir permisos modulares que se pueden agregar y quitar sin tocar el perfil base, y esta es la forma más segura de abordar una organización en crecimiento. Las Criteria-Based Sharing Rules en objetos con millones de registros requieren una prueba de carga antes de Production; hay casos en los que una regla de Sharing aparentemente inofensiva provoca una Recalculation que dura horas y bloquea los procesos nocturnos. ## Automatización: Flow vs. Apex La pregunta "Flow o Apex" no es una cuestión de gusto, sino de complejidad, volumen y ciclo de vida. Flow es más legible para un equipo operativo, se construye y mantiene rápidamente, y es adecuado para la lógica de negocio cambiante. Apex es necesario cuando hay Bulk Processing en miles de registros en una sola transacción, cuando se requiere un control preciso del orden de ejecución frente a otros Triggers, o cuando se necesita una prueba automática (Test Coverage) para fines de regulación o gestión formal de cambios (Change Management). Un anti-patrón común en organizaciones en crecimiento: cadenas de Flow que se llaman entre sí (Flow que activa Flow que activa Flow), sin un mapa central que muestre el orden de ejecución. Cuando algo falla, nadie sabe qué Flow se ejecutó primero. Un ejemplo del mundo real: una organización con 14 Flows activos en Opportunity, tres de ellos con la misma lógica de actualización de estado, escritos en diferentes épocas por diferentes personas sin verificar lo que ya existía. Regla general práctica: si hay más de 5-6 condiciones complejas en una lógica de negocio, o si se requiere una llamada externa dentro de un bucle, es preferible Apex. Fuera de eso, Flow es preferible porque es accesible para el mantenimiento incluso cuando el desarrollador original ya no está en la empresa. ## Integraciones: de Point-to-Point a una capa gestionada Una organización que comienza con dos conexiones externas (ERP y sistema de pago, por ejemplo) generalmente las construye directamente, Point-to-Point, y esto es razonable en esta etapa. El problema comienza cuando se agrega una tercera, cuarta y quinta conexión, cada una con su propia lógica de Retry, manejo de errores y mapeo de campos, sin un estándar común. En esta etapa, cualquier cambio en un sistema de origen rompe una o más conexiones sin que nadie lo sepa de antemano. La transición a una capa de Middleware (MuleSoft, o una capa de Integration Layer personalizada) no tiene por qué ser un proyecto masivo; se puede comenzar con la conexión más frágil o más costosa de mantener y hacer la transición gradualmente. Principios a adoptar en cada nueva integración: Idempotency (una llamada duplicada no crea un registro duplicado), External ID para una identificación certera, y un log que permita reproducir exactamente lo que sucedió en cada llamada. Una ampliación sobre los patrones de integración se encuentra en [Conectando Salesforce a un ERP](/es/insights/salesforce-erp-integration) y [Patrones de integración de Salesforce](/es/insights/salesforce-integration-patterns). ## Estrategia de Org: Single Org, Multi-Org o segmentación por unidad de negocio Esta es una de las decisiones más costosas de cambiar a posteriori. Un Single Org con segmentación por unidad de negocio (utilizando Record Types, Sharing y Permission Sets para la separación lógica) es adecuado para la mayoría de las organizaciones, ya que mantiene una única fuente de verdad y métricas de informes unificadas. Un Multi-Org es apropiado cuando las unidades de negocio requieren modelos de permisos fundamentalmente contradictorios, cuando hay una fusión o adquisición que trae un Org existente, o cuando la carga real de permisos afecta el rendimiento. La transición entre modelos una vez que la organización ya está construida es un proyecto pesado: fusión de datos, redefinición de permisos y, a menudo, pérdida de historial. Un desglose completo de los criterios de decisión se encuentra en [Salesforce Multi Org](/es/insights/salesforce-single-org-vs-multi-org). ## DevOps y Scalability: Cómo mantener la capacidad de cambio Una organización que desarrolla directamente en Production, sin un Sandbox ordenado y sin herramientas de CI/CD (como Copado, Gearset o SFDX), llega rápidamente a una situación en la que cualquier cambio es arriesgado. Un proceso de DevOps adecuado incluye al menos un Sandbox para desarrollo, un Sandbox para pruebas, control de versiones para Metadata y un proceso de Deployment automático con pruebas de regresión. Tabla de decisiones arquitectónicas clave y sus implicaciones a largo plazo: | Decisión | Beneficio inmediato | Implicación en 2-3 años | | --- | --- | --- | | Custom Object para cada requisito | Solución rápida para una necesidad puntual | Org con decenas de objetos duplicados, difícil de mantener | | Permisos "View All" temporales | Resuelve un problema en minutos | Amplia exposición de información difícil de detectar y cerrar | | Flow que llama a Flow | Desarrollo rápido sin código | Cadenas difíciles de seguir y probar | | Integración Point-to-Point adicional | Conexión rápida entre dos sistemas | Red de conexiones donde cada cambio rompe algo más | | Desarrollo directo en Production | Ahorra tiempo en la configuración del proceso | Alto riesgo para cada cambio, dificultad en la recuperación | | Single Org sin separación lógica | Informes unificados desde el primer día | Dificultad para añadir una unidad de negocio con necesidades diferentes | ## Caso de ejemplo organizacional Una empresa de distribución con tres unidades de negocio trabajó durante cuatro años en un único Org, donde cada unidad añadió sus propios objetos, Flows e integraciones según la necesidad inmediata. Cuando la gerencia decidió añadir una cuarta unidad, se descubrió que no existía un documento que explicara quién era el propietario de cada objeto, y tres integraciones diferentes sincronizaban clientes con el sistema contable con lógicas contradictorias. El equipo arquitectónico realizó un mapeo completo: identificó 23 objetos sin un Owner claro, seis cadenas de Flow superpuestas y dos integraciones que creaban registros duplicados debido a la falta de un External ID consistente. La solución no fue una reconstrucción, sino una documentación gradual, la unificación de la lógica de Sharing bajo Permission Set Groups y la migración de integraciones críticas a una única capa de Middleware. En dos trimestres, el tiempo para agregar una nueva unidad de negocio se redujo de varios meses a aproximadamente seis semanas. ## Anti-patrones comunes en organizaciones en crecimiento - **Custom Object para cada solicitud** - Se crea un nuevo objeto sin verificar si ya existe uno similar. - **Permisos amplios "temporales"** - Se otorgan bajo presión y nunca se restringen nuevamente. - **Flow-in-Flow sin mapeo** - Cadenas de automatización sin un diagrama de ejecución central. - **Point-to-Point sin Governance** - Cada nueva conexión se construye por separado sin un estándar común. - **Desarrollo en Production** - Cambios directos sin un Sandbox, pruebas o control de versiones. - **Ausencia de External ID** - Sincronización por nombre o correo electrónico que crea registros duplicados. ## Lista de verificación para evaluar la madurez arquitectónica - ☐ Cada objeto personalizado tiene un propietario de negocio documentado. - ☐ El modelo de Sharing se prueba bajo una carga de datos real. - ☐ Existe un mapa central de todas las cadenas de automatización. - ☐ Cada integración tiene un External ID, Retry y registro de errores. - ☐ Existe un proceso ordenado de Sandbox a Production con pruebas de regresión. - ☐ Se ha decidido explícitamente entre Single Org y Multi-Org con una justificación escrita. - ☐ Los Governor Limits se verifican frente a la previsión de crecimiento de tres años. Cuando la arquitectura de Salesforce requiere acompañamiento profesional y no solo un marco de trabajo independiente, este es el ámbito de [Servicio de Arquitectura CRM](/es/crm-architecture). ## Recursos profesionales - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Arquitectura CRM — https://hpi.pro/crm-architecture - HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data ### Preguntas y respuestas **¿Cuál es la diferencia entre Flow y Apex al elegir la capa de automatización?** Flow es adecuado para lógica de negocio que cambia frecuentemente, con interacción del equipo operativo y menos de 5-6 condiciones ramificadas. Apex es necesario para transacciones complejas, bucles con llamadas externas, procesamiento masivo de miles de registros o cuando se requieren pruebas automáticas (Test Classes) para cumplir con regulaciones. **¿Cuándo es el momento de pasar de una única organización (Single Org) a múltiples organizaciones?** Cuando diferentes unidades de negocio requieren modelos de permisos contradictorios, la carga de permisos afecta el rendimiento, o una fusión/adquisición introduce una organización separada. La transición es costosa y compleja. Es recomendable verificar primero si la segmentación por unidades de negocio o la multidivisa resuelven el problema dentro de una sola organización. **¿Cómo se construye un modelo de uso compartido (Sharing) que no colapse bajo carga?** Primero se mapea la estructura organizacional y los grupos de usuarios. Luego, se elige entre la jerarquía de roles (Role Hierarchy), las reglas de uso compartido (Sharing Rules) y los conjuntos de permisos (Permission Sets), según el alcance de las excepciones. Las reglas de uso compartido basadas en criterios que operan sobre millones de registros requieren una prueba de rendimiento antes de pasar a producción, no después. **¿Qué hacer con las integraciones antiguas punto a punto que se han acumulado a lo largo de los años?** Se mapean todas las conexiones existentes, se identifican duplicidades lógicas entre sistemas y se construye un plan de transición gradual hacia una capa de Middleware o una arquitectura orientada a eventos. No se reemplaza todo de una vez; se empieza por la integración más frágil o la de mantenimiento más costoso. **¿Cómo se verifica que la arquitectura perdurará en tres años?** Se verifican los límites de gobernador (Governor Limits) frente al volumen de crecimiento esperado, el número de objetos personalizados, la profundidad de las cadenas de automatización y el número de integraciones activas. Una organización con más de 15 Triggers en un solo objeto o con cadenas de Flow que se invocan mutuamente es una señal de advertencia temprana. --- ## Documentación técnica de CRM antes de Salesforce: los entregables imprescindibles antes de empezar a construir URL: https://hpi.pro/es/insights/crm-discovery-guide Un Discovery que termina en una presentación bien redactada no es un Discovery. Al final de la fase de documentación técnica, siete entregables deben estar sobre la mesa, listos para ser construidos, presupuestados y validados. Esta guía detalla el contenido de cada entregable, cómo saber si está completo y el tiempo razonable para dedicarle. ## ¿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](/es/insights/salesforce-implementation-guide). ## 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](/es/insights/salesforce-roi-kpis). ## 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](/es/insights/crm-implementation-mistakes), y su impacto en el cronograma se explica en la [Guía de Duración de Proyectos Salesforce](/es/insights/salesforce-project-timeline). ## 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](/es/insights/replace-crm-with-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. ### Preguntas y respuestas **¿Cuánto tiempo debería durar la fase de documentación técnica de CRM antes de un proyecto de Salesforce?** No hay una cifra única, pero sí una proporción razonable: la fase de documentación técnica suele ocupar entre una décima y una quinta parte del tiempo total del proyecto, y depende principalmente del número de procesos interdepartamentales y de sistemas de origen. Una documentación que dure más de lo esperado generalmente no sufre por falta de tiempo, sino por la ausencia de una figura con autoridad para decidir entre diferentes puntos de vista. **¿Cuál es la diferencia entre la documentación técnica de un CRM y un documento de requisitos?** Un documento de requisitos describe lo que los usuarios solicitaron. Una documentación técnica describe qué proceso de negocio se ejecutará, sobre qué modelo de datos, con qué permisos, frente a qué sistemas y cómo se demostrará su funcionamiento. Un mismo requisito puede implementarse de cinco maneras diferentes en Salesforce, y la función de la documentación técnica es elegir y justificar la mejor opción. **¿Es posible realizar la documentación técnica con el proveedor que luego implementará?** Es posible, y en muchos casos resulta eficiente. El riesgo es que la documentación se incline hacia lo que le resulte más conveniente al proveedor construir. Este riesgo se puede mitigar asegurando que los entregables se presenten a la organización en un formato no propietario, que las decisiones arquitectónicas se justifiquen con alternativas consideradas y que la cotización para la fase de documentación técnica sea independiente de la cotización para la implementación. **¿Qué hacer cuando los responsables del proceso no están de acuerdo con la definición del mismo?** No se cierra la disputa con un texto ambiguo. Se registra como una decisión abierta con un responsable, una fecha límite y un impacto en el alcance, y se eleva a la autoridad competente para que decida. Una documentación técnica que forja un consenso artificial generará costosos cambios de requisitos en una etapa posterior, cuando el código ya se esté construyendo. **¿Es necesario documentar todos los procesos antes de empezar a construir?** No. Es necesario documentar en profundidad los procesos del primer ciclo e identificar a nivel de título el resto para que el modelo no se vea obstaculizado más adelante. Lo único que debe decidirse de antemano para todo el panorama es el modelo de datos central y el modelo de permisos, ya que modificarlos a posteriori es mucho más costoso que cambiar una pantalla. --- ## Los 10 errores más comunes en la implementación de CRM y Salesforce (y cómo evitarlos) URL: https://hpi.pro/es/insights/crm-implementation-mistakes La mayoría de los fallos en proyectos CRM no se deben a problemas técnicos, sino a decisiones postergadas. Aquí desglosamos diez errores recurrentes en proyectos de Salesforce, la señal temprana que los identifica a tiempo y la acción preventiva que resulta económica si se ejecuta pronto, pero muy costosa si se realiza después del lanzamiento (Go-Live). ## Cómo Interpretar esta Lista Las diez fallas que se presentan a continuación no están ordenadas por frecuencia, sino por su aparición en la línea de tiempo de un proyecto. Para cada una, se detallan tres elementos: la señal temprana que puede identificarse en tiempo real, la acción preventiva, y la etapa a partir de la cual la corrección se vuelve significativamente más costosa. La idea es sencilla: casi cualquiera de estas fallas tiene un costo muy bajo si se aborda en las dos semanas adecuadas. ## 1. Empezar por una Lista de Funcionalidades en lugar de un Proceso La señal: El documento de requisitos está estructurado como una tabla de capacidades deseadas, y ninguna de sus filas describe un resultado de negocio. Lo que sucede en la práctica: El proyecto genera un sistema que cumple con la lista, pero no modifica la forma de trabajar. Un año después, la gerencia pregunta qué ha cambiado y no hay una respuesta medible. Prevención: A cada requisito se le asocia el proceso al que sirve y la métrica que debería impactar. Los requisitos sin respuesta a estas dos preguntas pasan a una lista de espera. El conjunto de entregables que evita este patrón se detalla en la [Guía de Descubrimiento de CRM](/es/insights/crm-discovery-guide). ## 2. Ausencia de un Único Dueño de Proceso La señal: En las reuniones, asisten cuatro personas del mismo departamento, y ninguna de ellas está autorizada para decir "así será". Lo que sucede en la práctica: Cada decisión se resuelve mediante un compromiso que intenta complacer a todos, es decir, construyendo dos caminos en lugar de uno. El sistema se vuelve el doble de complejo de lo necesario. Prevención: Asignar un nombre a cada proceso con una sola persona responsable. La distribución de roles recomendada se detalla en la [Guía de Roles del Equipo de Proyecto de Salesforce](/es/insights/salesforce-project-team-roles). ## 3. Postergar Decisiones de Arquitectura para el Final La señal: El equipo avanza en la construcción de pantallas mientras la pregunta "¿cuál es la fuente de verdad para el cliente?" sigue abierta. Lo que sucede en la práctica: Cuando la decisión finalmente se toma, contradice lo que ya se ha construido. Parte del trabajo se desecha, y la estimación inicial del proyecto ya no es relevante. Prevención: Identificar al inicio las tres a cinco decisiones que son costosas de cambiar —modelo de datos central, fuente de verdad, modelo de permisos— y asignarles una fecha de resolución antes de comenzar la construcción. ## 4. Importar la Deuda del Sistema Anterior La señal: La especificación de migración contiene todos los campos del sistema anterior, incluidos aquellos cuyos nombres terminan en "_old_2". Lo que sucede en la práctica: La nueva plataforma nace con doscientos campos que nadie mantiene, informes que se basan en datos poco fiables, y usuarios que interpretan esto como una señal de que el nuevo sistema tampoco es serio. Prevención: Cada campo que se migre debe tener un propietario y un uso comprobado en el último año. El resto pasa a un archivo legible y no al sistema en vivo. ## 5. Medir el Progreso por Historias de Usuario Cerradas La señal: El informe semanal muestra altos porcentajes de completitud, pero nadie ha logrado ejecutar un proceso completo de principio a fin. Lo que sucede en la práctica: El proyecto aparece en el gráfico como un éxito hasta la semana previa al lanzamiento, y luego se descubre que todas las partes funcionan de forma independiente y nadie ha verificado la conexión. Prevención: Definir un hito de "primer proceso en vivo de principio a fin" lo antes posible, incluso si cubre solo un escenario. Hasta que no se logre, los porcentajes de completitud no son información relevante. ## 6. Campos Obligatorios como Substitutos de la Disciplina de Datos La señal: La pantalla de creación de registros incluye doce campos obligatorios, de los cuales nadie sabe quién se supone que conoce sus valores. Lo que sucede en la práctica: Los usuarios seleccionan el primer valor de la lista para avanzar. Los informes reciben datos completamente completos y también completamente erróneos. Prevención: Un campo solo es obligatorio si es necesario para una decisión en el momento en que se solicita. Los campos requeridos en etapas posteriores del proceso se hacen obligatorios en ese momento. ## 7. Construir Automatización antes de que el Proceso sea Estable La señal: Existen tres mecanismos de automatización que operan sobre el mismo objeto, y nadie sabe cuál es su orden de ejecución. Lo que sucede en la práctica: Efectos secundarios inesperados, bucles de actualización y, sobre todo, la incapacidad de cambiar un proceso sin temor a romper algo. Prevención: Ejecutar un proceso manual o semi-manual durante varias semanas antes de automatizarlo. La automatización fija una decisión; es mejor que la decisión sea correcta. ## 8. UAT Realizado por Quienes Construyeron el Sistema La señal: Los escenarios de prueba fueron escritos por el mismo equipo de desarrollo, y cubren principalmente el camino feliz. Lo que sucede en la práctica: Los problemas que llegan a producción son precisamente los casos excepcionales: cancelaciones, abonos, clientes duplicados, usuarios que abandonaron un proceso a mitad. Prevención: Las pruebas son realizadas por el personal del proceso, con datos similares a los reales, y con una responsabilidad definida para la aprobación o el rechazo. ## 9. Capacitación como Evento Único La señal: El plan de implementación incluye dos talleres la semana anterior al lanzamiento y nada más después. Lo que sucede en la práctica: Los usuarios aprenden pantallas, no procesos, olvidan en dos semanas y recurren a colegas o a una hoja de Excel. La tasa de uso disminuye gradualmente sin que nadie se dé cuenta. Prevención: Capacitación por rol, lo más cercana posible al momento en que el empleado realmente realizará la acción, con un punto de soporte disponible en las primeras semanas. ## 10. Ausencia de Propietarios después del Go Live La señal: El plan del proyecto no incluye una línea que describa quién gestionará el sistema en el tercer mes. Lo que sucede en la práctica: Las solicitudes de cambio se acumulan sin respuesta, los pequeños errores se convierten en prácticas de trabajo alternativas y el sistema envejece rápidamente. Prevención: Definir la propiedad operativa, un mecanismo de recepción de solicitudes y una cadencia de lanzamiento regular antes del lanzamiento y no después. En organizaciones grandes, esto se hace generalmente a través de un modelo de gobierno estructurado, como se describe en la [Guía de Implementación de Salesforce en una Organización Empresarial](/es/insights/enterprise-salesforce-implementation). ## Costo de la Corrección por Etapa | Falla | Corrección en el Diseño | Corrección en la Construcción | Corrección después del Go Live | |---|---|---|---| | Modelo de datos incorrecto | Modificación en el diagrama | Reconstrucción del objeto | Migración interna y revisión completa | | Ausencia de propietario de proceso | Nombramiento | Paradas y resoluciones repetidas | Proceso duplicado que se mantiene indefinidamente | | Deuda del sistema antiguo | Filtrado de la lista de campos | Limpieza antes de la carga | Limpieza en el sistema en vivo | | Campos obligatorios innecesarios | Decisión en el diseño de pantalla | Cambio de configuración | Limpieza de datos erróneos acumulados | | Ausencia de propiedad operativa | Definición en el plan | Contratación o capacitación | Recuperación de la confianza de los usuarios | ## Ejemplo Ilustrativo: Compañía de Seguros Mediana El escenario es hipotético y tiene fines ilustrativos. Una compañía de seguros lanzó Salesforce para la gestión de agentes. Tres meses después, se descubrió que la tasa de actualización de los registros de los agentes era baja. La investigación no encontró ningún fallo técnico: se identificaron tres de las fallas mencionadas anteriormente simultáneamente: campos obligatorios innecesarios en la pantalla de creación, ausencia de un propietario para el proceso de contratación de agentes, y una capacitación que se impartió dos meses antes de que los primeros nuevos agentes ingresaran al sistema. La corrección no fue técnica. Se eliminaron seis campos obligatorios, se nombró a un único propietario del proceso del departamento de operaciones, y la capacitación se dividió en segmentos cortos que se enviaron la semana en que cada grupo comenzó a trabajar. El único cambio arquitectónico requerido fue posponer la obligatoriedad de dos campos a una etapa posterior del proceso. ## Qué Hacer con la Lista Revise las diez fallas y marque si la señal temprana de alguna de ellas está presente en su organización en este momento. Tres o más señales en un proyecto que aún no ha sido lanzado son motivo para una breve pausa y corrección, no para acelerar. Esas mismas tres señales en un sistema que ya está en vivo justifican un diagnóstico estructurado antes de añadir nuevas funcionalidades sobre una base inestable. ### Preguntas y respuestas **¿Cuál es el error más costoso de corregir en una implementación de Salesforce?** Un error en el modelo central de datos. Modificar el objeto que gestiona el proceso de negocio después de haber cargado datos y construido automatizaciones e informes requiere una migración interna, reescritura de lógica y una revalidación de permisos. Los errores en la interfaz de usuario, en cambio, suelen corregirse en cuestión de días. **¿El exceso de campos obligatorios realmente afecta la adopción?** Sí, y es uno de los mecanismos más directos. Cada campo obligatorio que no es esencial para una decisión añade fricción en cada registro. El resultado más común son valores de relleno incorrectos, elegidos solo para avanzar, que luego contaminan precisamente los informes para los que se solicitó el campo. Es preferible exigir un campo en una etapa posterior del proceso, no en la de creación. **¿Cuándo se suele descubrir que una implementación ha fallado?** Generalmente entre el segundo y el cuarto mes después del Go-Live, cuando finaliza el soporte intensivo. Hasta entonces, los usuarios cuentan con acompañamiento cercano y la dirección ve actividad. La señal real es una disminución continua en la actualización de registros, junto con un aumento en el uso de archivos externos de Excel. **¿Es posible corregir un proyecto de Salesforce que ya ha sido lanzado con deficiencias?** Casi siempre, pero el orden de las operaciones difiere de un proyecto nuevo. Primero, se estabiliza lo que interrumpe el trabajo diario; luego, se limpian los datos; y solo al final, se retoma la planificación de procesos. Intentar corregir todo simultáneamente mientras el sistema está en uso suele prolongar la crisis. **¿Quién es el responsable de prevenir estos errores, la organización o el proveedor?** La mayoría se evitan solo con colaboración. Un proveedor puede señalar un riesgo arquitectónico, pero no puede decidir quién es el dueño del proceso en la organización, qué información se considera fiable o quién está autorizado a renunciar a un requisito. Los proyectos que fracasan casi siempre sufrieron por la falta de una entidad organizacional con autoridad de decisión, no por la falta de conocimiento técnico. --- ## Servicios Salesforce: Cómo elegir entre consultoría, implementación, Health Check y acompañamiento URL: https://hpi.pro/es/insights/salesforce-services-guide La mayoría de las organizaciones se acercan a un proveedor en busca de una "implementación", incluso cuando lo que realmente necesitan es un diagnóstico o un acompañamiento. Elegir el tipo de servicio incorrecto es la razón más común de proyectos que terminan con un resultado que nadie solicitó. Aquí, un mapeo por síntoma: qué solicitar en cada situación, cuál será el producto final y cuáles son las señales de advertencia. ## 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](/es/insights/salesforce-consulting-guide). ## 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í: 1. Consultoría breve para decidir la idoneidad — días, no semanas. 2. Definición funcional enfocada para la primera fase. 3. Implementación en fases. 4. Un período de estabilización definido después del lanzamiento. 5. Acompañamiento continuo. 6. 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](/es/insights/choose-salesforce-implementation-company). ## 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](/es/insights/salesforce-rfp-guide), y las cláusulas que deben incluirse en el acuerdo en sí se detallan en la [Guía de Contrato y SOW de Salesforce](/es/insights/salesforce-sow-contract-clauses). ## 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. ### Preguntas y respuestas **¿Cuál es la diferencia entre consultoría y 'Discovery' en las propuestas de los proveedores de Salesforce?** En la mayoría de los proveedores, estos términos se usan indistintamente, por lo que es crucial examinar los resultados en lugar de solo los títulos. Un 'Discovery' profesional culmina en un modelo de datos principal, un modelo de permisos, un mapa de sistemas y criterios de aceptación. Si la propuesta promete "talleres de definición" sin especificar un resultado medible, estará comprando horas, no un documento estructural. **¿Se puede solicitar solo un Health Check sin comprometerse a una continuación?** Sí, y es la práctica más saludable. Un Health Check es un servicio independiente cuyo resultado es un informe de hallazgos priorizados. Si un proveedor condiciona la auditoría a un compromiso de implementación, surge un conflicto de intereses: la misma entidad diagnostica y vende la "cura". Es preferible, al menos comercialmente, separar el diagnóstico de la solución. **Para una organización pequeña, ¿es realmente necesario un servicio externo o es suficiente con un administrador interno (Admin)?** Un administrador interno es suficiente para el mantenimiento, cambios de configuración y soporte. Sin embargo, generalmente no es adecuado para decisiones que definen la arquitectura: el modelo de datos central, el modelo de exposición o los límites entre sistemas. La regla práctica es recurrir a un acompañamiento externo para decisiones que son costosas de modificar a posteriori, y mantener el resto internamente. **¿Qué son exactamente los Managed Services para un entorno Salesforce?** Es un modelo en el que un proveedor externo se encarga del mantenimiento continuo, la gestión de solicitudes de cambio, las entregas periódicas y la supervisión, dentro de un alcance de horas acordado. Es adecuado para organizaciones sin un equipo interno, pero requiere una definición precisa de qué se incluye: la corrección de errores y el desarrollo menor son muy diferentes en términos de costo. **¿Se pueden contratar todos los servicios a un solo proveedor?** Es posible y común, pero es aconsejable separar, al menos, la fase de consultoría inicial o la auditoría periódica. La razón no es la desconfianza, sino un sesgo inherente: un proveedor que implementó un sistema tiene dificultades para diagnosticar que una decisión arquitectónica previa fue errónea. Una segunda opinión en los puntos de inflexión es económica en comparación con el costo de una corrección tardía. --- ## Consultoría Salesforce: ¿Cuándo necesita un consultor y qué debe esperar del proceso? URL: https://hpi.pro/es/insights/salesforce-consulting-guide Un consultor de Salesforce es esencialmente necesario cuando los errores pueden resultar costosos, no solo para consultas técnicas. Este artículo identifica cinco detonantes clave que justifican la consultoría externa, diferencia entre consultores, arquitectos y administradores, y detalla los entregables imprescindibles para asegurar que su inversión se traduzca en decisiones sólidas, no solo en reuniones. ## Cuándo la consultoría externa es una ventaja y cuándo es un despilfarro Un consultor de Salesforce no es necesario para responder preguntas que pueden resolverse con la documentación o el conocimiento de un administrador experimentado. Se le requiere en los puntos donde la decisión es costosa de modificar, atraviesa múltiples departamentos, o cuando no hay una figura neutral en la organización que pueda dirimirla. Cinco detonantes justifican una consultoría externa: 1. **Decisión de plataforma** — Si Salesforce es adecuado en absoluto, y frente a qué alternativas. 2. **Decisión arquitectónica costosa de revertir** — Modelo de datos central, organización única frente a múltiple, fuente de la verdad. 3. **Disputa interna entre unidades** que no tiene un árbitro natural. 4. **Proyecto estancado** donde se necesita una parte no involucrada políticamente para determinar la causa. 5. **Situación previa a un compromiso comercial grande** — Antes de firmar una propuesta de millones de séqueles, una opinión independiente es relativamente económica. Lo que no justifica una consultoría: añadir campos, construir informes, preguntas operativas diarias. Estas son responsabilidades de un administrador, y la consultoría que se desvía a estas tareas se convierte rápidamente en un costoso refuerzo de personal. ## Tres roles que suelen confundirse | Rol | Pregunta que responde | Horizonte | Cuando se le contrata incorrectamente | | --- | --- | --- | --- | | Consultor | Qué hacer y en qué orden | Meses a años | Se obtiene una estrategia en lugar de una solución a un problema | | Arquitecto | Cómo implementar sin generar deuda técnica | El proyecto y el sistema | Se obtiene un diseño detallado para un problema no definido | | Administrador | Cómo operar y mantener en el día a día | Semanas | Se obtiene una solución puntual que consolida una gran decisión | El fallo común es la tercera fila: una decisión arquitectónica que toman de facto los administradores, porque llegó como una pequeña solicitud. ## Qué debe obtenerse de un proceso de consultoría Un proceso de consultoría que termina con una presentación de resumen es un proceso sobre el que no se puede actuar. Los entregables que conviene solicitar por escrito, antes de la firma, son: * **Documento de decisiones** — Para cada decisión: la pregunta, las alternativas consideradas, la recomendación, la justificación y la implicación si se decide lo contrario. * **Suposiciones y dependencias** — Lo que el consultor asumió sin verificar, y qué sucede si la suposición es incorrecta. * **Mapa de riesgos** enfocado en la organización, no una lista genérica. * **Recomendación de secuencia de acciones** con dependencias, no una lista de deseos. * **Qué no hacer** — La recomendación negativa es a menudo la parte de mayor valor, y casi siempre falta. El último punto es una buena prueba de calidad: un consultor capaz de decir "no construyan esto ahora" vende una decisión, no horas. ## Cómo evaluar a un consultor antes de contratarlo Las preguntas que conviene hacer no son sobre certificaciones sino sobre el modo de pensamiento: * Describa una decisión arquitectónica que recomendó y de la que se arrepintió. ¿Qué aprendió? * ¿En qué caso recomendaría no usar Salesforce? * ¿Cómo decide entre configuración y desarrollo? * ¿Qué solicita a la organización para que la consultoría tenga éxito, y qué sucede si no lo recibe? * ¿Quién de su equipo continuará manteniendo el producto después de que usted se retire? Un conjunto más amplio de preguntas para evaluar a un proveedor se encuentra en la [Guía de preguntas antes de elegir un integrador Salesforce](/es/insights/questions-before-choosing-salesforce-integrator). ## Conflicto de interés — no siempre malo, siempre debe conocerse Un proveedor que asesora y luego implementa no es necesariamente problemático; a veces es el método más eficiente, ya que el conocimiento no se pierde en la transferencia. El problema comienza cuando la recomendación afecta el alcance del trabajo de ese mismo actor y no hay un mecanismo de equilibrio. Tres mecanismos de equilibrio sencillos: * Tarifación separada para la fase de consultoría, no condicionada a la continuación. * Derecho de la organización a realizar una licitación después de la fase de consultoría, con los entregables de su propiedad. * Requisito de que cada recomendación se presente con una alternativa más económica y la razón por la que fue descartada. El tercero es el más eficaz, y también el que genera las conversaciones más útiles. ## Ejemplo ilustrativo: empresa de infraestructura de propiedad pública El escenario es hipotético y tiene fines ilustrativos. Una empresa de infraestructura consideró un gran proyecto de CRM para gestionar consultas públicas y de autoridades. Dos proveedores propusieron una arquitectura con una organización de Salesforce separada para cada una de las dos audiencias, argumentando la separación de información regulatoria. La consultoría externa contratada examinó el requisito regulatorio en sí y encontró que dictaba la separación de acceso, no la separación de sistemas. La conclusión cambió completamente el panorama comercial: una única organización con un modelo de exposición minucioso en lugar de dos entornos que requerirían sincronización y mantenimiento duplicado. El entregable de mayor valor en el proceso no fue una recomendación sobre qué construir, sino la prueba de que la suposición principal de las dos propuestas no se había verificado. ## Cómo esto se conecta con la decisión comercial Una buena opinión de consultoría cambia lo que usted solicita a los proveedores, por lo que debe llegar antes de las propuestas y no después. A partir de ahí, la decisión se mueve en dos planos: la elección del modelo de precios adecuado para el nivel de incertidumbre restante, como se detalla en la [Guía de modelos de precios de proyectos Salesforce](/es/insights/salesforce-project-pricing-models), y la comparación entre las ofertas que se recibirán, como se detalla en la [Guía para comparar ofertas](/es/insights/compare-salesforce-proposals). Los criterios para evaluar la empresa que realizará el trabajo real se resumen en la [Guía para elegir una empresa de implementación Salesforce](/es/insights/choose-salesforce-implementation-company). ## Prueba rápida antes de contratar una consultoría Responda tres preguntas: ¿cuál es la decisión que necesita tomar?, ¿quién en la organización la aprobará?, y ¿qué pasará si la toma incorrectamente? Si la respuesta a la tercera pregunta es "corregiremos más adelante a bajo costo", es probable que no necesite un consultor. Si la respuesta es "volveremos a construir", ese es precisamente el punto en el que una consultoría externa recupera su costo. ### Preguntas y respuestas **¿Cuál es la diferencia entre un consultor y un arquitecto Salesforce?** Un consultor se enfoca en determinar qué es lo más adecuado y en qué orden, considerando factores empresariales, organizacionales y comerciales. Un arquitecto se encarga de cómo implementar esa visión correctamente en la plataforma: modelo de datos, exposición, límites del sistema e integridad técnica. En proyectos pequeños, una misma persona puede asumir ambos roles, pero para decisiones importantes, es preferible contar con ambas perspectivas. **¿Cuánto tiempo debe durar un proceso de consultoría Salesforce?** La consultoría para evaluar la idoneidad de una solución generalmente se mide en pocos días. Una consultoría que acompaña una definición se mide en semanas. Una consultoría que dura meses sin entregar resultados concretos suele ser más un refuerzo de personal; debe ser gestionada y presupuestada como tal. **¿Puede un consultor externo trabajar con un equipo interno de Salesforce ya existente?** Sí, y a menudo este es el modelo más eficiente. La clave es una clara definición de responsabilidades: qué decisiones toma el consultor, qué recomienda solamente y quién en la organización lo aprueba. Sin esta delimitación, puede surgir tensión donde el equipo interno defiende lo que ha construido y el consultor se comunica directamente con la dirección. **¿Qué hacer si el consultor recomienda una solución a la que el equipo interno se opone?** Es fundamental solicitar que la recomendación se presente junto con las alternativas consideradas y los criterios de decisión, en lugar de como una conclusión final. La oposición de un equipo interno suele basarse en conocimiento contextual al que el consultor no ha tenido acceso. Si persiste la discrepancia tras presentar las alternativas, la decisión recae en quien asume el riesgo, no en quien tiene la razón técnica. **¿Cuánto cuesta una consultoría Salesforce en [País/Región]?** El costo se deriva de la cantidad de horas, el nivel de senioridad y la responsabilidad del consultor sobre el entregable, variando significativamente entre proveedores. Lo que se debe comparar no es la tarifa por hora, sino el costo total para llegar a una decisión: una consultoría más costosa por hora que culmina en dos semanas con un documento de decisiones puede ser más económica que una consultoría barata que se extiende por dos meses. --- ## Preparación para Agentforce: una lista de verificación organizacional para datos, permisos y procesos URL: https://hpi.pro/es/insights/agentforce-salesforce-ai-guide Antes de construir su primer agente de IA, es recomendable responder una pregunta importante: ¿su organización está realmente preparada? Esta guía presenta una evaluación de preparación basada en cinco ejes fundamentales: procesos, datos, conocimiento, permisos y operación. Incluye una puntuación para cada eje, un umbral mínimo para proyectos piloto y recomendaciones sobre cómo abordar brechas identificadas. ## La respuesta concisa Una evaluación de preparación para Agentforce toma solo unas semanas; un piloto fallido cuesta meses y la confianza interna. Por lo tanto, vale la pena responder de antemano a cinco preguntas clave: ¿Existe un proceso definido con un responsable asignado? ¿Son fiables los datos en los que se basará el agente? ¿Existe una base de conocimiento actualizada y mantenida? ¿Es claro el modelo de permisos? Y, ¿hay alguien que gestione al agente después de su lanzamiento? La evaluación no es una cuestión de sí o no. Genera una puntuación para cada eje y un mapa de las brechas, lo que permite una decisión más precisa: empezar, reducir el alcance (Scope), o posponer y cerrar primero una brecha específica. El marco de decisión sobre la idoneidad del caso de uso (Use Case) se encuentra en [Agentforce para empresas](/es/insights/agentforce-for-enterprises). ## Los cinco ejes de preparación | Eje | La pregunta decisiva | Señal de debilidad | Umbral mínimo para un piloto | | --- | --- | --- | --- | | Proceso | ¿Está el proceso definido y tiene un responsable asignado? | Cada equipo lo ejecuta de manera diferente y no hay documentación | Un proceso documentado con un Propietario (Owner) y volumen conocido | | Datos | ¿Son fiables los campos que leerá el agente? | Campos vacíos o rellenados con texto libre | 90% de completitud en los campos críticos para el proceso | | Conocimiento | ¿Existe una fuente aprobada para las respuestas? | Artículos antiguos o contradictorios | 20 artículos actualizados para los escenarios comunes | | Permisos | ¿Está claro lo que cada usuario puede ver y hacer? | Permisos amplios y no controlados | Mapeo de perfiles (Profiles) y conjuntos de permisos (Permission Sets) para el proceso | | Operación | ¿Quién monitoriza, corrige y aprueba los cambios? | No hay un responsable después del lanzamiento | Un Propietario operativo (Operational Owner) y revisión semanal | ## Eje 1: El Proceso El fallo más común no es tecnológico. Las organizaciones eligen un proceso sin un responsable asignado, y entonces no hay quien decida sobre las preguntas que surgen durante la construcción: qué sucede en una excepción, cuándo escalar, qué se considera una respuesta correcta. Sin una decisión, el equipo técnico inventa las reglas y el negocio evalúa según otra expectativa. Una prueba práctica: solicite la descripción del proceso por escrito a cuatro personas que lo ejecuten. Si se obtienen cuatro versiones significativamente diferentes, el proceso no está listo para la automatización de un agente; está listo para ser documentado y acordado primero. También necesita volumen. Un proceso que ocurre diez veces al mes no justificará el costo de construcción y mantenimiento, por molesto que sea. Un buen candidato es un proceso con un volumen significativo, alta repetibilidad y variabilidad en la formulación de la solicitud, precisamente donde las reglas estrictas se rompen. ## Eje 2: Los Datos No se requiere una calidad de datos perfecta en toda la organización (Org). Se requiere calidad en los campos que el agente leerá o actualizará en el proceso seleccionado. La evaluación es estrecha y medible: se toma la lista de campos relevantes y se mide la completitud, la consistencia de los valores y las duplicidades en los registros relacionados. Tres pruebas que proporcionan una respuesta rápida: el porcentaje de campos críticos completados, el número de registros duplicados en el objeto central y el porcentaje de casos en los que la información necesaria proviene de un sistema externo y no de Salesforce. La tercera prueba es la que sorprende, ya que revela una dependencia de una integración que no ha sido presupuestada. El texto libre es una bandera roja especial. Cuando la información esencial reside en un campo de comentarios, el agente tendrá que deducirla, y ahí es precisamente donde se generan errores difíciles de rastrear. El orden recomendado para abordar las brechas de datos se detalla en [Métricas de calidad de datos en Salesforce](/es/insights/salesforce-data-quality-metrics).

Eje 3: El Conocimiento

El conocimiento se evalúa no por cantidad, sino por cobertura y validez. Se toman las veinte solicitudes más comunes y se verifica para cada una: si hay un artículo aprobado, cuándo se actualizó y quién es el propietario. Una cobertura de la mitad de los escenarios con artículos actualizados es preferible a una cobertura completa con artículos antiguos. Una señal de debilidad fácil de pasar por alto: artículos escritos exclusivamente para uso interno y que se utilizan simultáneamente para responder a los clientes. Contienen formulaciones, precios o excepciones que no deben ser expuestos externamente, y la separación debe realizarse antes de la conexión. ## Eje 4: Los Permisos El agente opera en nombre de un usuario, por lo que el modelo de permisos existente se convierte en el modelo de seguridad de la IA. Si los permisos son amplios y no controlados hoy, el agente aumentará la exposición en lugar de crearla. La evaluación examina tres aspectos: quién puede leer los datos en el proceso, qué operaciones de escritura son necesarias y quién aprueba una operación sensible. Para cada acción que el agente realice, es necesario definir si es reversible. Una acción irreversible (un crédito financiero, el cierre de un caso, el envío de un mensaje al cliente) requiere un punto de aprobación humano en la primera etapa, y por lo tanto afecta la planificación del proceso y no solo la configuración. La planificación de puntos de aprobación por riesgo se detalla en [Human-in-the-Loop en Agentforce](/es/insights/agentforce-human-in-the-loop). ## Eje 5: La Operación Un agente no es un proyecto con fecha de finalización. Es un componente que requiere la monitorización de trazas (Traces), la gestión de fallos, la actualización de contenido y el control de costes. Una organización que no tenga a alguien que realice estas tareas, aunque sea a tiempo parcial, experimentará una disminución gradual de la calidad en un trimestre. El mínimo: un propietario operativo (Operational Owner) nombrado, una rutina de revisión semanal de las llamadas que fallaron, un proceso de cambio acordado para actualizar las instrucciones (Instructions) y un presupuesto mensual supervisado. Si ninguna de estas cuatro condiciones existe, la brecha en este eje es mayor de lo que parece inicialmente. ## Traducción de la puntuación en decisión | Estado | Interpretación | Acción recomendada | | --- | --- | --- | | Todos los ejes en el umbral o superior | Preparación completa | Piloto en un proceso con criterios Go/No-Go | | Debilidad solo en la operación | Puede compensarse con acompañamiento | Piloto con acompañamiento externo y desarrollo de capacidad interna en paralelo | | Debilidad solo en el conocimiento | Brecha de contenido específica | Cuatro a seis semanas de formación en Conocimiento, y luego piloto | | Debilidad en datos o permisos | Riesgo significativo | No iniciar con el agente; cerrar la brecha como un proyecto separado | | Debilidad en tres o más ejes | La organización no está madura | Elegir un subproceso más limitado y reevaluar | ## Escenario: Una organización financiera que descubrió que se eligió el proceso incorrecto Una organización financiera solicitó un agente para gestionar solicitudes de cambio de datos de clientes. Durante la evaluación de preparación, se descubrió que el proceso pasaba por dos sistemas externos, que cada cambio requería aprobación regulatoria y que el volumen mensual era modesto. Los ejes de permisos y datos obtuvieron una puntuación baja. En esa misma evaluación, surgió otro proceso en el que nadie había pensado: la respuesta a preguntas de estado sobre solicitudes existentes. Este se basaba en un campo fiable en Salesforce, no implicaba operaciones de escritura y su volumen era ocho veces mayor. El piloto se trasladó a este nuevo proceso. El resultado práctico de la evaluación no fue "listos o no listos", sino un cambio de candidato. Esta es la principal contribución de una evaluación de preparación: es lo suficientemente económica como para realizarla en tres candidatos y elegir el que tenga las dependencias más pequeñas. ## Lista de verificación de preparación - ☐ Se ha seleccionado un único proceso candidato con un propietario asignado. - ☐ Se ha medido el volumen mensual y la tasa de repetibilidad. - ☐ Se ha verificado la completitud de los campos críticos para el proceso. - ☐ Se han verificado las duplicidades en el objeto central. - ☐ Se han identificado las dependencias en sistemas externos. - ☐ Se ha mapeado la cobertura de Knowlegde para las veinte solicitudes más comunes. - ☐ Se ha separado el contenido interno del contenido permitido para el cliente. - ☐ Se han mapeado los permisos de lectura y escritura para el proceso. - ☐ Se han clasificado las acciones reversibles frente a las irreversibles. - ☐ Se ha definido un propietario operativo y una rutina de revisión posterior al lanzamiento. Cuando se requiere un tercero para realizar la evaluación y traducirla en un plan de acción (Roadmap), el [servicio Agentforce e IA](/es/agentforce-ai) es la ruta práctica a seguir. ### Preguntas y respuestas **¿Cuánto tiempo toma una evaluación seria de preparación?** Entre dos y cuatro semanas para una organización mediana. La primera semana se dedica al mapeo del proceso candidato y a entrevistas, la segunda al muestreo de datos y conocimiento, y la tercera a la verificación de permisos y la formulación de brechas. Más de un mes generalmente indica que se seleccionó un alcance de prueba demasiado amplio. **¿Es posible iniciar un piloto con una puntuación de preparación media?** Sí, siempre y cuando la brecha identificada no se encuentre en los ejes de datos o permisos. Una debilidad en el eje operativo puede compensarse con un acompañamiento cercano en los primeros meses. Sin embargo, una base de conocimiento deficiente o un modelo de permisos poco claro harán que el piloto fracase, independientemente de la calidad de su implementación. **¿Quién debe liderar la evaluación de preparación: TI o el negocio?** El propietario del proceso de negocio debe liderar, ya que será quien deba justificar el resultado. TI y seguridad de la información aportan en los ejes de datos y permisos. Una evaluación liderada únicamente por TI tiende a examinar las capacidades de la plataforma en lugar de determinar si el proceso en sí es apto para la automatización. **¿Qué hacer si la evaluación revela que la organización no está preparada?** Cada brecha debe traducirse en un elemento de la hoja de ruta con un responsable y una fecha límite. Luego, se debe elegir un proceso candidato alternativo que requiera menos dependencias. En la mayoría de los casos, hay un subproceso estrecho que sí cumple con el umbral y puede convertirse en el piloto, mientras que las brechas mayores se cierran en paralelo. **¿Debe adquirirse la licencia de Agentforce antes de la evaluación?** No. La evaluación de preparación se enfoca en el proceso, los datos y los permisos, elementos que existen independientemente de la licencia. La adquisición de licencias antes de identificar un caso de uso maduro puede resultar en licencias sin usar y la presión de mostrar resultados demasiado rápido. --- ## Salesforce Health Check: qué se evalúa, cuándo y qué obtiene al finalizar URL: https://hpi.pro/es/insights/salesforce-health-check-guide Un Health Check es más que una encuesta: es un diagnóstico basado en evidencia sólida, analizando metadatos, registros, datos de uso y observación directa de usuarios reales. Esta guía detalla los siete pilares de evaluación, la metodología de calificación de gravedad y la estructura del informe final que facilita la toma de decisiones presupuestarias. ## La respuesta breve El Health Check es un diagnóstico basado en evidencias con una duración de dos a seis semanas, que culmina en tres entregables: una lista de hallazgos clasificados por severidad, un plan de "Quick Wins" a 30 días y una hoja de ruta para inversiones profundas. Lo que lo hace valioso no es la amplitud del escaneo, sino la evidencia adjunta a cada hallazgo —un número, un log o una grabación de pantalla—, ya que sin ella la discusión se convierte de nuevo en un debate de opiniones. ## Los siete ejes de revisión | Eje | Qué se revisa en la práctica | Fuente de la evidencia | | --- | --- | --- | | Proceso y Adopción | ¿El proceso documentado es el proceso ejecutado? | Historial de inicio de sesión, uso de campos, observación de usuarios | | Modelo de Datos | Objetos redundantes, campos sin uso, relaciones duplicadas | Uso de campos, Metadata API, consultas de muestreo | | Automatizaciones | Solapamientos entre Flows, Triggers y Process Builder antiguo | Metadatos, Logs de depuración, análisis del orden de ejecución | | Permisos y Seguridad | Perfiles sobrecargados, Reglas de Compartición contradictorias, acceso excesivo | Security Health Check, asignaciones de Permission Sets | | Integraciones | Límites de API, fallos recurrentes, manejo de errores | Monitoreo de Eventos, logs de Middleware | | Rendimiento | Tiempos de carga, consultas pesadas, Batch atascado | Lightning Usage App, Apex Jobs | | Costo y Licencias | Licencias no utilizadas, Almacenamiento, servicios duplicados | Informe de licencias, factura vs. uso real | ## Cómo se califica la severidad Una calificación arbitraria hace que el informe carezca de valor. La metodología efectiva es la siguiente: cada hallazgo recibe dos puntuaciones del 1 al 5 — impacto (qué sucede al negocio si no se aborda) y frecuencia (cuántas veces al mes se manifiesta). El producto de estas puntuaciones determina la prioridad, no una estimación de cuán "feo" sea el código. Un hallazgo con una puntuación de 20 o más se aborda de inmediato; entre 12 y 19 se incluye en el próximo trimestre; por debajo de 12 se registra y no se aborda, a menos que su corrección sea económica mientras se realiza otro trabajo. La distinción más importante en el informe es entre síntoma y raíz. "Los usuarios no completan el campo de razón de pérdida" es un síntoma; la raíz podría ser que el campo no es obligatorio, que los valores no son relevantes para el área, o que nadie revisa el informe basado en él. Corregir solo el síntoma —haciendo el campo obligatorio— genera datos deficientes en lugar de datos ausentes. ## Qué se obtiene al finalizar Un entregable adecuado incluye un documento de hallazgos con evidencia para cada línea, una matriz de severidad, un plan a 30 días donde cada elemento es ejecutable sin cambios arquitectónicos, y una hoja de ruta para uno o dos trimestres con estimaciones de esfuerzo aproximadas. Además, se requiere un Registro de Decisiones de tres a cinco determinaciones que la organización debe tomar —por ejemplo, si consolidar dos unidades de negocio en una sola Org—, ya que sin ellas la hoja de ruta carecería de fundamento. Una ampliación sobre la decisión posterior al diagnóstico se encuentra en [Reescribir frente a Refactorizar](/es/insights/salesforce-rebuild-vs-refactor) y en [Priorización de la deuda técnica](/es/insights/salesforce-technical-debt-prioritization). ## Riesgos comunes y acciones preventivas El primer riesgo es un informe que se interpreta como una lista de acusaciones. Si los hallazgos se formulan como críticas a un equipo interno, la organización se pone a la defensiva y no corrige. Una formulación correcta se centra en la situación y el costo de la inacción, no en responsabilidades históricas. El segundo riesgo es una revisión que termina sin un responsable asignado. Cada hallazgo debe tener el nombre de una persona y una fecha límite, de lo contrario, el informe se une a una carpeta que nadie abre. El tercer riesgo es una amplitud excesiva: un diagnóstico que intenta cubrir siete ejes con total profundidad en dos semanas genera una imagen superficial de todos ellos. Es preferible elegir tres ejes para profundizar y marcar el resto para la siguiente ronda. ## Cómo se mide el éxito Un Health Check es exitoso si, en un plazo de 60 días, se ha ejecutado al menos el 70% de los elementos del plan de 30 días, si la dirección ha aprobado un presupuesto para al menos una inversión profunda, y si dos indicadores operativos —por ejemplo, el índice de fallos de integración o el tiempo de carga de una pantalla clave— han mejorado de forma medible respecto a la base establecida al inicio del diagnóstico. ## El siguiente paso Antes de solicitar una revisión, es recomendable preparar tres elementos: una lista de los procesos de negocio críticos, acceso de lectura a los logs y metadatos, y los nombres de tres usuarios reales cuyo trabajo pueda ser observado. Estos tres puntos acortan el diagnóstico en aproximadamente una semana y mejoran significativamente la calidad de los hallazgos. ### Preguntas y respuestas **¿Cuánto tiempo toma un Health Check?** Para una organización mediana con una sola instancia (Org): de dos a tres semanas. Esto incluye aproximadamente una semana para la recopilación de evidencia y observación, y una semana para el análisis y la redacción. Una Org multi-unidad de negocio con decenas de integraciones requerirá de cuatro a seis semanas. Más allá de eso, ya no es un diagnóstico, sino un proyecto. **¿Es necesario otorgar acceso de Administrador completo al consultor externo?** No es imprescindible. Para la mayoría de las evaluaciones, permisos como 'Ver configuración y personalización' (View Setup and Configuration), 'Ver todos los datos' (View All Data) de forma limitada y acceso de lectura a los registros (logs) son suficientes. Si existen datos sensibles, trabajamos en un Sandbox actualizado y complementamos en Producción solo aquellas métricas imposibles de replicar. **¿Cuál es la diferencia entre un Health Check y la herramienta nativa Security Health Check de Salesforce?** La herramienta de Salesforce evalúa la configuración de seguridad frente a un punto de referencia y devuelve una puntuación. Un diagnóstico completo abarca también procesos, el modelo de datos, automatizaciones, integraciones, adopción y costos, siendo la herramienta nativa solo uno de los insumos en nuestra evaluación. **¿Qué se hace con un hallazgo que requiere una reescritura fundamental?** No se incluye en el plan de 'Quick Wins'. Se marca como una decisión de inversión separada, con una estimación de esfuerzo, el riesgo de inacción y una fecha límite para su reevaluación. Se gestiona de forma independiente del tratamiento principal de los hallazgos urgentes. **¿Un Health Check se justifica incluso cuando el sistema funciona correctamente?** Sí, en dos situaciones clave: antes de una inversión importante, para asegurar que la base es sólida; y después de dos o tres años de cambios acumulados, cuando nadie en la organización tiene una visión completa de las automatizaciones y los permisos. --- ## Trademark Disclosure Salesforce® and Agentforce® are trademarks of Salesforce, Inc. HPI Pro is an independent consultancy and does not present itself as an official Salesforce partner unless explicitly stated on the site.