Servicios Salesforce
Auditoría de Salesforce
Una revisión de cómo está planteado tu Salesforce y de qué está impidiendo que aporte lo que debería. No es un informe técnico para archivar: es un diagnóstico con un plan priorizado de dónde actuar y por qué en ese orden.
Sirve tanto si notas que el sistema se ha quedado corto como si estás a punto de invertir en él y quieres saber desde dónde partes.
Cuándo tiene sentido
Seis situaciones en las que una auditoría ahorra dinero
No hace falta que algo esté roto. La auditoría es especialmente útil justo antes de decidir, cuando todavía se puede cambiar el rumbo sin coste.
El equipo trabaja fuera del sistema
Los datos que importan siguen en hojas de cálculo, en el correo o en la cabeza de cada comercial. Salesforce está, pero no es donde se trabaja.
Vas a decidir una inversión
Hay un proyecto nuevo, una ampliación de licencias o un cambio de alcance sobre la mesa y necesitas saber desde dónde partes antes de comprometer presupuesto.
Has heredado la instalación
Entras en la organización, o asumes la responsabilidad del CRM, y nadie sabe explicar por qué está configurado como está ni qué depende de qué.
Estás revisando el partner
Quieres una lectura independiente del estado de tu Salesforce antes de renovar, cambiar o ampliar la relación con quien lo mantiene.
Los costes no cuadran con el uso
Pagas licencias, complementos y almacenamiento que no sabes si se usan, y no tienes forma de justificar el coste frente al valor que da el sistema.
Cada cambio cuesta demasiado
Modificar algo pequeño obliga a tocar muchos sitios, o rompe cosas que funcionaban. Es el síntoma habitual de deuda acumulada en la configuración.
Qué revisamos
Ocho ámbitos, y cómo se relacionan entre ellos
Los problemas de un Salesforce rara vez viven en un solo sitio. Una adopción baja suele explicarse por un proceso mal modelado, que a su vez obliga a mantener datos a mano porque falta una integración. Revisamos los ocho ámbitos y, sobre todo, cómo se encadenan.
Procesos frente a configuración
Cómo vende, atiende y opera realmente la organización, y en qué medida lo que hay configurado en Salesforce se corresponde con eso. Es la parte que explica la mayoría de los problemas de adopción.
Modelo y calidad de datos
Objetos, relaciones y campos frente a la información que el negocio necesita. Duplicados, campos obsoletos, campos obligatorios que nadie rellena y datos que se mantienen a mano en dos sitios.
Automatizaciones y lógica
Qué automatiza el sistema, con qué herramienta, en qué orden se ejecuta y qué se solapa. Aquí es donde suelen aparecer las reglas que nadie recuerda haber creado.
Integraciones
Qué sistemas intercambian datos con Salesforce, en qué dirección, con qué frecuencia y qué pasa cuando fallan. Y qué datos se están copiando a mano porque la integración no existe.
Permisos y seguridad
Quién ve qué y quién puede modificar qué. Perfiles y conjuntos de permisos acumulados, accesos heredados de personas que ya no están y reglas de visibilidad que ya no responden a la organización.
Licencias y coste
Qué licencias y complementos tienes contratados, cuáles se usan de verdad y qué capacidades estás pagando sin aprovechar. También lo contrario: lo que estás resolviendo a mano y ya tienes pagado.
Adopción real
Quién entra, con qué frecuencia y para qué. Qué funcionalidad se usa y cuál se abandonó. Y sobre todo, qué está haciendo el equipo por fuera porque el sistema le resulta más lento.
Informes y decisiones
Si los informes y cuadros de mando responden a las preguntas que se hace la dirección, y si los datos que los alimentan son fiables. Un informe que nadie se cree no lo usa nadie.
Cómo la hacemos
Del síntoma a la causa, y de la causa a un orden
Una auditoría que solo lista hallazgos técnicos no sirve para decidir. La nuestra tiene que terminar en una conversación de negocio: qué se resuelve primero, qué cuesta, y qué pasa si no se hace.
Hablamos con quien lo usa
Antes de mirar la configuración, entrevistamos a los equipos que trabajan con el sistema a diario y a quien decide sobre él. Lo que cuenta un usuario que se pelea con una pantalla vale más que cualquier informe de metadatos.
Revisamos la instalación por dentro
Con acceso de solo lectura recorremos configuración, modelo de datos, automatizaciones, integraciones, permisos y uso. No es una lista de comprobación genérica: buscamos por qué el sistema se comporta como se comporta.
Separamos síntoma de causa
Muchos problemas que se describen como falta de formación son en realidad un proceso mal modelado, y muchos que se describen como falta de funcionalidad se resuelven quitando cosas. Distinguirlo es el trabajo.
Priorizamos por impacto
El resultado es un plan ordenado: qué resolver primero porque desbloquea al equipo, qué puede esperar, qué conviene dejar como está y qué no compensa arreglar. Con el criterio explicado, no solo la conclusión.
Qué te llevas
El entregable
Un documento que puedas usar para decidir y para explicar la decisión a quien la tiene que aprobar.
El estado actual descrito en términos de negocio, no de metadatos: qué procesos están cubiertos, cuáles a medias y cuáles fuera del sistema.
Los hallazgos ordenados por impacto, cada uno con su causa, el esfuerzo estimado de resolverlo y lo que ocurre si se deja como está.
Un plan por fases con lo que recomendamos hacer primero y el motivo, distinguiendo lo que desbloquea al equipo de lo que solo mejora el sistema por dentro.
Lo que recomendamos no hacer: personalizaciones que conviene retirar, automatizaciones que se solapan y licencias o complementos que no se están usando.
Una sesión de presentación con los equipos implicados para revisar el diagnóstico y ajustar prioridades con vosotros.
Empecemos por saber dónde estás
Cuéntanos qué te hace pensar que tu Salesforce puede dar más y en qué contexto está funcionando hoy. A partir de ahí acordamos el alcance de la revisión.
Preguntas frecuentes
Preguntas frecuentes
¿Qué incluye el entregable de una auditoría de Salesforce?
El entregable de una auditoría de Salesforce es un documento con el estado actual descrito en términos de negocio, los hallazgos ordenados por impacto (cada uno con su causa, el esfuerzo de resolverlo y lo que ocurre si se deja como está), un plan por fases y una lista de lo que conviene no hacer: personalizaciones que retirar, automatizaciones que se solapan y licencias sin uso. Se cierra con una sesión de presentación con los equipos implicados.
¿Qué necesitáis del cliente para auditar su Salesforce?
Dos cosas: acceso a la organización para revisar cómo está configurada, y tiempo de las personas que la usan. Antes de mirar la configuración entrevistamos a los equipos que trabajan con el sistema a diario y a quien decide sobre él, porque lo que cuenta un usuario que se pelea con una pantalla vale más que cualquier informe de metadatos.
¿En qué se diferencia una auditoría de un proyecto de evolución?
Una auditoría diagnostica y ordena: dice qué está pasando, por qué y en qué orden conviene actuar. Un proyecto de evolución ejecuta ese orden. Auditar primero tiene sentido cuando no está claro dónde está el problema o cuando hay que justificar la inversión ante dirección; si la causa ya está identificada, se puede ir directo a la evolución.
¿Sirve una auditoría si mi Salesforce lo implantó otro partner?
Es uno de los casos más habituales. Buena parte de las auditorías que hacemos son sobre instalaciones heredadas (de otro partner o de un equipo interno que ya no está) donde nadie documentó por qué se tomaron las decisiones que hay montadas. La revisión no juzga al partner anterior: reconstruye qué hace hoy el sistema y qué le falta para lo que el negocio necesita ahora.