La gobernanza del CRM: quién puede editar qué y por qué eso importa
El incidente que detonó la conversación sobre gobernanza del CRM fue específico y con consecuencias reales de negocio: un representante de ventas había modificado el campo de "valor de la oportunidad" de una oportunidad que no era suya para ajustar el número al objetivo de su trimestre. El cambio era visible en el log de auditoría del sistema pero el manager no había revisado ese log porque nadie tenía el hábito de hacerlo de forma regular. La modificación había estado en el sistema durante 3 semanas, había afectado el reporte de pipeline del directorio de esa semana y había producido decisiones de asignación de recursos basadas en un número que no reflejaba la realidad.
El problema no era el comportamiento del representante, que era el síntoma de un problema de presión de objetivos que merecía su propia conversación. El problema era que el sistema permitía esa modificación sin restricción, sin notificación y sin un proceso de revisión que detectara el cambio antes de que afectara los reportes. Era una vulnerabilidad de gobernanza que nadie había anticipado porque nadie había discutido quién debería poder editar qué campos del CRM y bajo qué condiciones.
Diseñé el framework de gobernanza del CRM con 3 categorías de campos según su nivel de protección. Categoría A: campos que solo podían ser modificados por el manager o el administrador del sistema, incluyendo el valor de la oportunidad, la etapa de ventas y la probabilidad de cierre. Cualquier modificación en un campo de Categoría A generaba automáticamente una notificación al manager con el valor anterior y el nuevo valor. Categoría B: campos que el representante responsable de la cuenta podía modificar pero que generaban una notificación al manager. Categoría C: campos de uso operativo que cualquier usuario podía modificar sin restricciones.
El log de auditoría se configuró para revisión automática semanal, con un reporte que mostraba todas las modificaciones de campos de Categoría A de la semana anterior. No como mecanismo de desconfianza sino como mecanismo de verificación de calidad de datos: los cambios en los campos más críticos del pipeline merecían una revisión que garantizara que reflejaban la realidad comercial y no artefactos de gestión de objetivos.
La respuesta del equipo de ventas al framework fue más positiva de lo que esperaba. La mayoría de los representantes reconocieron que la protección de los campos críticos hacía que los datos del sistema fueran más confiables para todos, incluyendo para ellos mismos cuando tomaban decisiones basadas en el pipeline de sus colegas. La gobernanza del CRM no es sobre desconfianza en el equipo. Es sobre proteger la integridad del sistema que todos usan para tomar decisiones. Un sistema cuyos datos pueden ser modificados sin restricción es un sistema en el que nadie puede confiar completamente.