Cuándo hacer una auditoría técnica Salesforce

Una auditoría técnica Salesforce no debería ser el paso automático ante cualquier incidencia o petición de mejora. Si un ajuste concreto está bien acotado, tiene un responsable claro y afecta a pocos componentes, suele ser más eficiente analizarlo y ejecutarlo directamente. La revisión amplia cobra sentido cuando la organización ya no puede estimar con fiabilidad el impacto de los cambios, los despliegues generan incidencias o el CRM depende de procesos que nadie entiende del todo.

Para un responsable de IT, CRM u operaciones, el problema no es solo técnico. Un flujo de ventas detenido, una discrepancia entre Salesforce y el ERP o una automatización que asigna mal los casos se traduce en trabajo manual, datos poco fiables y decisiones aplazadas. El objetivo de la auditoría es convertir esa incertidumbre en un alcance de trabajo priorizado, con dependencias y riesgos visibles.

Qué revisa una auditoría técnica Salesforce

Una revisión técnica analiza cómo está construido y operado el entorno, no solo si las pantallas funcionan. Debe relacionar la configuración con los procesos de negocio que soporta: captación, venta, servicio, operaciones de campo, facturación o relación con distribuidores, según el caso.

El alcance exacto depende del motivo de la revisión. En una organización con problemas de entrega, el foco puede estar en los cambios, los entornos y la automatización de despliegues. Si el problema está entre CRM y ERP, habrá que revisar interfaces, mensajes fallidos, mecanismos de reintento, propiedad de los datos y conciliación. Antes de una migración o de incorporar nuevas capacidades, puede ser más relevante entender el modelo de datos, las personalizaciones y las dependencias de las integraciones.

El marco oficial Salesforce Well-Architected ofrece preguntas y criterios para valorar la calidad de una solución y hacer explícitos sus compromisos de diseño. Puede orientar la revisión, adaptando sus principios al contexto y al alcance acordados.

Habitualmente se revisan cuatro áreas conectadas:

• El modelo de datos, la calidad de los registros, los permisos y las reglas que condicionan quién puede modificar cada información.
• Las automatizaciones declarativas y el código a medida, incluidos flujos, reglas, clases, desencadenadores y procesos que se solapan.
• Las integraciones con ERP, herramientas de soporte, plataformas de datos u otros sistemas, atendiendo a contratos, errores y trazabilidad.
• La forma de gestionar cambios: repositorios, entornos, pruebas, despliegues, documentación y dependencia de personas concretas.

No se trata de producir un inventario extenso para archivarlo. Una auditoría útil selecciona la evidencia necesaria para responder preguntas de decisión: qué se puede cambiar con riesgo controlado, qué conviene estabilizar antes de añadir funcionalidades y qué dependencias deben resolverse antes de comprometer un presupuesto o una fecha.

Síntomas que justifican una revisión acotada

Un backlog grande no demuestra por sí solo que exista deuda técnica. Puede deberse a falta de priorización de negocio, a recursos limitados o a solicitudes que nunca se han definido bien. Sin embargo, hay patrones que sí aconsejan detenerse a revisar la base técnica antes de seguir acumulando cambios.

Uno de los más habituales es que una modificación aparentemente sencilla requiera muchas validaciones manuales porque nadie conoce todos sus efectos. Otro es que el equipo use hojas de cálculo para corregir datos que deberían sincronizarse entre sistemas. También conviene revisar cuando varios flujos actúan sobre el mismo objeto, cuando las incidencias reaparecen tras cada despliegue o cuando solo una persona sabe publicar cambios sin interrumpir la operación.

Un escenario hipotético ayuda a concretarlo. Una empresa de distribución registra oportunidades y pedidos en Salesforce, pero el ERP es el sistema que confirma disponibilidad y facturación. Si la integración falla de forma intermitente, operaciones puede terminar validando pedidos por correo y corrigiendo registros manualmente. Añadir una nueva automatización comercial sin revisar los estados, identificadores y errores de integración podría aumentar el volumen de excepciones. La prioridad no sería rediseñar todo el CRM, sino determinar dónde se rompe el flujo y qué cambios mínimos restauran control y trazabilidad.

La documentación oficial de patrones de integración de Salesforce contempla el tratamiento de errores y la recuperación según el patrón elegido. Por eso, la revisión debe aclarar qué sistema detecta los fallos y cuál asume los reintentos y la conciliación.

La misma lógica aplica a iniciativas de automatización avanzada o IA aplicada. Antes de plantear recomendaciones, clasificación de casos o asistencia comercial, conviene verificar la calidad de los datos, el proceso que los genera, los permisos y la integración con los sistemas que contienen la información relevante. La capacidad tecnológica no sustituye esas condiciones previas.

Cuándo no hace falta una auditoría completa

Una auditoría amplia consume tiempo de usuarios de negocio y especialistas técnicos. Por eso, no siempre es la opción proporcionada. Si se va a corregir un campo, ajustar una validación conocida o incorporar una mejora funcional aislada, un análisis de impacto limitado suele bastar.

La diferencia está en el nivel de incertidumbre. Si el equipo puede identificar los componentes afectados, el criterio de aceptación, los datos implicados y el procedimiento de prueba, hay base para presupuestar y ejecutar una mejora concreta. Si esas respuestas no existen o entran en contradicción entre áreas, una revisión acotada puede evitar que una estimación inicial se convierta en una cadena de supuestos.

Tampoco conviene confundir esta revisión con mantenimiento ordinario. El mantenimiento resuelve incidencias, peticiones recurrentes y pequeñas evoluciones. La auditoría sirve para decidir cómo ordenar un problema más estructural o preparar un cambio con dependencias relevantes. Ambos trabajos pueden coexistir, pero sus entregables y su forma de medir avance son distintos.

Entregables que permiten decidir

Antes de contratar una revisión, merece la pena pedir que se defina qué se va a examinar y qué recibirá la organización al finalizar. Un documento genérico con observaciones no permite priorizar ni preparar una fase posterior.

En un alcance proporcionado, los entregables deberían incluir un mapa de los componentes y flujos revisados, una relación de hallazgos con su evidencia, una valoración de impacto operativo y técnico, y una priorización recomendada. Cuando existen integraciones, resulta especialmente útil reflejar qué sistema es responsable de cada dato, dónde se producen transformaciones y cómo se detectan los fallos.

Las recomendaciones deben separar acciones inmediatas de decisiones que requieren diseño. Por ejemplo, retirar una automatización duplicada puede ser una corrección concreta tras validar su uso. Replantear la sincronización de clientes entre CRM y ERP exige, en cambio, acordar reglas de negocio, propietarios de datos y tratamiento de excepciones. Presentar ambas cosas como una sola lista de tareas oculta sus compromisos.

También conviene que el resultado indique qué no se ha revisado. Si el análisis se centra en automatizaciones comerciales, no puede concluir sobre el estado de todas las integraciones corporativas. Esta delimitación protege la calidad de la decisión y evita interpretar una revisión focalizada como una certificación general del entorno.

Cómo evaluar el alcance y al proveedor

La primera conversación debería empezar por el impacto, no por una lista de tecnologías. Conviene describir qué proceso se ve afectado, qué equipos intervienen, qué ocurre cuando falla y qué cambio se quiere habilitar. Con esa información es posible decidir si hace falta una revisión de configuración, arquitectura, integración o entrega.

Al evaluar una propuesta, hay varias preguntas prácticas. ¿Qué fuentes se revisarán y con qué nivel de acceso? ¿Cómo se validarán los hallazgos con negocio y con el equipo técnico? ¿Qué criterios se usarán para priorizar? ¿Qué decisiones podrá tomar la organización al finalizar? ¿Qué dependencias quedarían fuera del alcance? Las respuestas deben ser concretas, especialmente cuando intervienen ERP, middleware, repositorios de código o proveedores externos.

En consultoría Salesforce, el valor de la revisión no está en señalar que existen componentes antiguos o configuraciones mejorables. Está en conectar esos hallazgos con una secuencia viable: entender el estado real, mejorar los puntos que bloquean la operación y establecer una forma sostenible de mantener y evolucionar la plataforma. En ocasiones será necesario separar estabilización técnica y evolución funcional para no mezclar una urgencia operativa con un rediseño de mayor alcance.

Preparar la primera conversación

La organización puede preparar la primera conversación reuniendo información disponible, sin intentar documentar todo antes de pedir ayuda. Son útiles los ejemplos recientes de incidencias, las solicitudes de cambio que se han bloqueado, una relación de sistemas conectados, los responsables de cada proceso y cualquier documentación de despliegue existente. También ayuda identificar qué decisiones están pendientes: una migración, una integración nueva, la reducción de trabajo manual o la preparación de una iniciativa de datos o IA aplicada.

No hace falta esperar a que el entorno esté perfectamente inventariado para empezar. La conversación inicial sirve para comprender la necesidad y valorar el encaje; no constituye una auditoría técnica. Si hace falta una revisión, se acuerdan su alcance, entregables y presupuesto antes de comenzar.

Si necesitáis valorar qué revisar antes de mejorar Salesforce, podéis comentar vuestro caso con SENVORA.