Ejecutar bien un pedido resuelve la necesidad tal como fue formulada. El criterio estratégico pregunta si esa formulación resuelve el problema real.
En casi todas las organizaciones que usan Salesforce hay personas dedicadas a la plataforma. Administradores que crean usuarios, configuran permisos y construyen flows. Consultores funcionales que relevan requerimientos y los convierten en procesos. Desarrolladores que escriben Apex, construyen componentes y mantienen integraciones. Son roles necesarios y, cuando están bien cubiertos, evitan bastantes problemas operativos.
Pero casi todos comparten la misma lógica: llega un pedido, se traduce a configuración o a código, se entrega. Es una lógica reactiva. Durante años alcanzó, porque ejecutar llevaba tiempo, requería conocimiento técnico y quien lo hacía bien era difícil de reemplazar. Eso está cambiando.
Salesforce e IA: cuando construir es instantáneo, decidir qué construir es lo que importa
Con la inteligencia artificial (IA), generar un flow, una clase de Apex, una fórmula, un componente o una especificación funcional lleva cada vez menos tiempo. Lo que antes eran días de trabajo hoy puede resolverse en una conversación. Esto tiene dos consecuencias para cualquier persona que trabaje con Salesforce.
La primera es que la capacidad de ejecución deja de ser diferencial. Si cualquiera puede producir una configuración correcta en minutos, el valor de un profesional se desplaza: ya no está tanto en saber cómo construir algo, sino en saber si conviene construirlo y de qué forma.
La segunda es que las malas decisiones también se aceleran. Si construir es barato, se construye más, y sin criterio eso significa más campos, más automatizaciones y más dependencias que nadie evaluó en conjunto. La deuda técnica no desaparece con la IA. Se acumula más rápido.
Por eso, en mi forma de verlo, migrar de un rol reactivo a un rol con capacidad estratégica ya no es una aspiración de carrera para unos pocos. Para quien trabaja en el ecosistema Salesforce, en un rol funcional o técnico, es la condición para seguir siendo relevante.
Dos lógicas de trabajo en Salesforce: ejecución y estrategia
La lógica de ejecución parte del requerimiento: lo recibe, lo traduce, lo entrega. En un administrador, eso es configuración. En un consultor funcional, un diseño de proceso. En un desarrollador, código. El éxito se mide en tickets resueltos, tiempos de entrega y estabilidad del sistema. Es imprescindible, pero limitada por diseño: no está en su alcance cuestionar si el requerimiento en sí mismo es una buena idea para el negocio.
La lógica estratégica parte del objetivo de negocio y baja desde ahí hacia la solución. No pregunta “¿cómo construyo esto que me piden?” sino “¿por qué me lo piden, qué problema de negocio resuelve y es esta la mejor forma de resolverlo dentro de la plataforma?”. Esa pregunta, hecha a tiempo, evita años de deuda técnica y de configuraciones que después nadie recuerda por qué existen.
Esta lógica no es exclusiva de un cargo, ni siquiera del arquitecto de Salesforce. Un administrador puede ejercerla, un desarrollador también, un consultor funcional también. Lo que cambia no es el título, sino el punto de partida desde el cual se piensa.
Por qué falta el rol estratégico en la mayoría de las organizaciones
Hay varias razones estructurales por las que las empresas terminan con equipos de ejecución sólidos pero sin criterio estratégico sobre la plataforma.
La primera es que contratar (o desarrollar) para ejecutar es más simple: hay certificaciones claras, un conjunto de habilidades verificable y un mercado de talento relativamente estandarizado. El criterio estratégico es más ambiguo de evaluar: requiere entender el negocio, capacidad de negociación interna y experiencia viendo qué decisiones de arquitectura envejecen bien y cuáles se convierten en un problema.
La segunda es que la función estratégica suele quedar dispersa entre varias personas que no tienen tiempo real ni mandato claro para ejercerla: un poco la asume el gerente de sistemas, un poco el líder comercial que “sabe de Salesforce”, un poco el partner externo durante la implementación inicial, y después nadie. Sin un dueño claro de la visión de largo plazo, las decisiones se toman de forma fragmentada, cada área optimizando para su propio corto plazo.
La tercera, más incómoda, es que el criterio estratégico a veces implica decir que no a pedidos de áreas con poder político dentro de la organización, y eso requiere un mandato explícito de la dirección que pocas empresas otorgan formalmente.
Qué costos genera esta ausencia: deuda técnica en Salesforce
Cuando no existe una función estratégica sobre Salesforce, los costos aparecen de forma diferida, y por eso son difíciles de atribuir a su causa real.
Aparece la proliferación de campos y objetos personalizados que responden a pedidos puntuales de distintas áreas sin una visión integrada. Aparece la falta de estándares: dos equipos de la misma empresa registrando la misma información de formas distintas. Aparecen automatizaciones y código que resuelven un problema puntual pero generan efectos secundarios que nadie anticipó, porque nadie estaba mirando el conjunto. Aparecen integraciones que funcionan por separado pero, sumadas, generan problemas de arquitectura. Y aparece, con el tiempo, un sistema que se percibe lento, complejo y poco confiable, no porque Salesforce tenga esas limitaciones, sino porque nadie ejerció la función de mantener coherencia a lo largo de los años.
Con la IA acelerando la construcción, estos síntomas pueden aparecer en meses en lugar de años.
Un ejemplo de decisión que separa a los dos roles
Supongamos que un área pide que, al cerrarse una oportunidad, los datos se envíen automáticamente a un sistema externo. Desde la lógica de ejecución, se escribe el trigger o el flow con el callout, se prueba y se despliega; con IA, puede estar listo en una tarde. Desde la lógica estratégica, las preguntas son otras: ¿es la primera integración con ese sistema o ya existen otras que conviene unificar? ¿Qué pasa si el sistema externo no responde? ¿Esta lógica debería vivir en Salesforce o en una capa de integración? ¿Quién la va a mantener cuando cambie el proceso?
La diferencia entre ambas lógicas no es que una sea correcta y la otra incorrecta. La ejecución resuelve correctamente el pedido tal como fue formulado. La estrategia cuestiona si el pedido, formulado de esa manera, es la mejor forma de resolver la necesidad real.
Multiplicada por años de pedidos acumulados, esa diferencia explica buena parte de por qué algunos sistemas de Salesforce envejecen de forma ordenada y otros se convierten en un laberinto de objetos, campos y código que nadie recuerda por qué existen.
Qué implica pasar de un rol reactivo a uno estratégico en Salesforce
Para quien trabaja con Salesforce, como administrador, consultor o desarrollador, el cambio empieza por hábitos concretos. Preguntar por el problema antes que por la solución, y entender qué objetivo de negocio hay detrás de cada pedido. Mirar el sistema completo y no solo el ticket: cómo afecta cada cambio a los datos, las automatizaciones, las integraciones y los usuarios de otras áreas. Entender el negocio con la misma profundidad que la plataforma: cómo vende la empresa, cómo atiende a sus clientes, qué métricas le importan a la dirección.
También implica pensar en el mediano plazo antes de construir, preguntándose cómo va a envejecer cada decisión. Usar la IA para liberar tiempo y no solo para producir más: si la ejecución se acelera, el tiempo ganado debería invertirse en análisis y diseño, no en aceptar más pedidos sin filtro. Y aprender a decir que no con argumentos, porque un no fundamentado y acompañado de una alternativa aporta más que un sí que genera deuda.
Cómo instalar el rol estratégico de Salesforce en una organización
Instalar la función estratégica no siempre requiere una nueva contratación inmediata. En organizaciones más pequeñas, puede empezar por darle mandato explícito a quien ya trabaja con la plataforma para que, además de ejecutar pedidos, cuestione activamente los que no tengan sentido, y que la dirección respalde ese cuestionamiento en lugar de percibirlo como una traba burocrática. En organizaciones más grandes, suele requerir separar formalmente la función, con alguien que reporte a un nivel que le permita tener conversaciones de igual a igual con los líderes de negocio que usan el CRM, y no solo con IT. Para las organizaciones que no pueden desarrollar este perfil internamente, la alternativa es incorporarlo desde afuera, como advisor de largo plazo o como parte de un partner que se involucre más allá del proyecto de implementación.
Lo que no funciona, en ningún tamaño de organización, es esperar que el criterio estratégico emerja espontáneamente de alguien sobrecargado de trabajo operativo. La visión de largo plazo requiere tiempo protegido para pensar, y ese tiempo casi nunca existe si no se lo asigna de forma explícita y se lo defiende frente a la presión constante de lo urgente.
Cómo diagnosticar la brecha
Para la organización, la pregunta es: si mañana cualquier área pidiera un cambio grande en Salesforce, ¿quién tiene la autoridad y el criterio para evaluar si ese cambio es una buena idea para todo el negocio en el mediano plazo, más allá de si es técnicamente posible de implementar?
Para cada profesional, la pregunta es más personal: en el último pedido que resolviste, ¿sabías qué problema de negocio estabas resolviendo, o solo qué tenías que construir?
