Las organizaciones que tratan el go-live como un cierre suelen encontrarse, un par de años después, implementando desde cero algo que nunca debió necesitarlo.
Gestionar Salesforce como producto significa asumir que la plataforma no termina en el go-live: requiere un product owner con continuidad, un backlog priorizado, presupuesto recurrente para su evolución y medición permanente de su adopción e impacto en el negocio.
La mayoría de las organizaciones se relacionan con Salesforce a través de la lógica de proyecto: hay un alcance definido, un cronograma, un presupuesto, un partner de implementación, y una fecha de go-live que marca el final formal del esfuerzo. Una vez que el sistema está en producción, el proyecto se considera cerrado, el equipo de implementación se desmoviliza, y la organización pasa a un modo de mantenimiento básico: resolver tickets, hacer ajustes menores, atender lo urgente.
Esta lógica, tomada directamente de la gestión de proyectos tradicional, es estructuralmente inadecuada para un sistema como Salesforce, que no tiene un estado final. El negocio sigue cambiando después del go-live, los procesos siguen evolucionando, aparecen nuevas necesidades, cambian las prioridades comerciales, y la plataforma tiene actualizaciones constantes que hay que evaluar y adoptar. Tratar todo esto como “mantenimiento menor” de un proyecto cerrado es la razón más común por la que los CRMs se vuelven obsoletos, desalineados del negocio o abandonados en favor de soluciones paralelas, apenas un par de años después de una implementación exitosa.
¿Qué diferencia hay entre gestionar Salesforce como proyecto o como producto?
Gestionar un proyecto significa optimizar para entregar un alcance definido dentro de un tiempo y presupuesto acotados. El éxito se mide en el cumplimiento de ese entregable. Una vez entregado, el trabajo formalmente termina.
Gestionar un producto significa asumir la responsabilidad continua sobre la evolución de algo que sigue existiendo y siendo usado indefinidamente, con un ciclo permanente de identificar necesidades, priorizar, desarrollar, lanzar y medir impacto, que nunca llega a un cierre definitivo porque el contexto en el que ese producto opera sigue cambiando. El éxito no se mide en un entregable puntual, sino en el valor que el producto sigue generando a lo largo del tiempo.
Salesforce, como cualquier plataforma central de operación de un negocio, se ajusta mucho mejor a la segunda lógica que a la primera. Y sin embargo, la inmensa mayoría de las organizaciones lo gestionan con las herramientas y la mentalidad de la primera.
Qué implica adoptar la lógica de producto en Salesforce
Adoptar una lógica de producto para Salesforce implica cuatro cambios concretos en cómo se organiza el trabajo alrededor de la plataforma:
- Un product owner de Salesforce con continuidad en el tiempo, no solo durante el proyecto de implementación inicial. Ese rol es responsable de mantener el roadmap del CRM, es decir, una visión de hacia dónde debería evolucionar el sistema; de priorizar entre pedidos que compiten por los mismos recursos de desarrollo, y de asegurar que la plataforma siga alineada con los objetivos de negocio, que cambian con el tiempo.
- Un backlog de Salesforce vivo, con mejoras y necesidades sometidas a un proceso de priorización explícito, en lugar de resolver pedidos por orden de llegada o por presión política de quien lo solicita. Un backlog de CRM obliga a comparar el valor relativo de distintas iniciativas, algo que rara vez ocurre cuando cada pedido se trata como un ticket aislado.
- Presupuesto recurrente para la evolución de la plataforma, y no solo para su implementación inicial y su mantenimiento correctivo. Las organizaciones que presupuestan Salesforce como un gasto único de proyecto, seguido de un presupuesto mínimo de soporte, están, en la práctica, decidiendo que la plataforma no va a evolucionar de forma significativa después del primer año, aunque nadie lo diga explícitamente así.
- Medición continua del éxito, con indicadores de adopción de Salesforce, de satisfacción de usuarios internos y de impacto en resultados de negocio, en lugar de medir el éxito una sola vez, en el momento del go-live, y no volver a mirarlo de forma sistemática.
Por qué importa más en Salesforce: releases, cambios de negocio y deuda técnica
Salesforce, como plataforma, tiene características que hacen que la lógica de producto sea todavía más relevante que en otros sistemas. La plataforma publica tres releases al año (Spring, Summer y Winter), con nuevas funcionalidades que pueden generar valor real si se evalúan y adoptan de forma deliberada, o quedar completamente ignoradas si no hay nadie con el mandato y el tiempo de seguir esas actualizaciones.
El negocio que opera sobre la plataforma (ventas, servicio, marketing, operaciones) cambia de forma continua, y cada cambio de proceso de negocio tiene, potencialmente, una implicancia en cómo debería configurarse el sistema. Y la deuda técnica en Salesforce se acumula de forma silenciosa: cada configuración rápida hecha “para resolver esto por ahora” sin revisión posterior se convierte, con el tiempo, en una capa de complejidad que nadie termina de entender del todo, dificultando cualquier evolución futura.
Los costos de seguir en modo proyecto
Cuando una organización sigue tratando a Salesforce como un proyecto cerrado y reduce el trabajo posterior al mantenimiento correctivo, sin mantenimiento evolutivo, los costos aparecen de forma acumulativa y difícil de atribuir a una causa puntual. El sistema empieza a sentirse cada vez más desalineado con cómo opera realmente el negocio, porque el negocio siguió evolucionando y el sistema no. Aparecen soluciones paralelas (planillas, herramientas puntuales adoptadas por áreas específicas) porque el CRM no se adaptó a nuevas necesidades a tiempo. La plataforma acumula complejidad sin que nadie tenga una visión completa de por qué cada funcionalidad fue construida así. Y, en algún momento, aparece la tentación de “empezar desde cero”, como si el problema fuera la plataforma y no la forma en que se la gestionó durante los años posteriores a su lanzamiento inicial.
Un ejemplo de cómo se vive esta diferencia en el día a día
Pensemos en una funcionalidad nueva que Salesforce lanza como parte de uno de sus releases, que podría simplificar significativamente un proceso que hoy la organización resuelve con una automatización personalizada bastante compleja, construida hace algunos años.
En una organización que gestiona Salesforce con lógica de proyecto, es muy probable que nadie esté formalmente encargado de revisar las actualizaciones de la plataforma, y que esta funcionalidad simplemente pase inadvertida: la automatización compleja sigue funcionando, generando el mismo costo de mantenimiento de siempre, mientras la plataforma ya ofrece una forma más simple de lograr el mismo resultado.
En una organización que gestiona Salesforce con lógica de producto, existe alguien con el mandato explícito de revisar cada release relevante de la plataforma, evaluar su aplicabilidad al contexto específico del negocio, y proponerla como parte del backlog de mejoras si genera valor. Esa funcionalidad entra en la conversación de priorización, se compara con otras iniciativas que compiten por el mismo tiempo de desarrollo, y eventualmente se implementa si el valor lo justifica, reemplazando una solución más costosa de mantener por una más simple y sostenida directamente por el proveedor de la plataforma.
La diferencia entre ambos escenarios no es de recursos disponibles, sino de si existe o no un proceso deliberado para capturar ese tipo de oportunidades. Con el tiempo, la brecha entre organizaciones que capturan estas oportunidades de forma sistemática y las que no lo hacen se vuelve sustancial, aunque haya sido invisible en cualquier momento puntual.
El cambio de mentalidad: hacia la evolución continua de Salesforce
Pasar de un modelo de proyecto a un modelo de producto no requiere necesariamente una inversión adicional. Requiere, principalmente, un cambio de mentalidad en cómo la organización piensa su relación con la plataforma: aceptar que la implementación inicial es el comienzo de una relación de largo plazo y no el final de un esfuerzo, asignar responsabilidad continua y no solo puntual, y presupuestar evolución de forma recurrente y no solo mantenimiento.
Las organizaciones que hacen este cambio de mentalidad suelen encontrarse con un sistema que sigue siendo relevante y valorado por sus usuarios.
