El costo de digitalizar un proceso que nadie rediseñó

Un CRM perfectamente configurado sobre un proceso mal diseñado es, en el mejor de los casos, una automatización elegante de un problema.

Cada vez que un proyecto de Salesforce no da los resultados esperados, la primera reacción suele ser mirar la herramienta. Se revisan flujos, se auditan automatizaciones, se cuestiona si el partner elegido hizo bien su trabajo técnico. Rara vez la primera pregunta es: ¿el proceso que estamos digitalizando tenía sentido antes de meterlo en el CRM?

Esa es la trampa. Salesforce es extraordinariamente flexible, y esa flexibilidad tiene un costo silencioso: permite construir sobre procesos rotos sin que nada explote de inmediato. El sistema no falla el día uno. Falla varios meses después, cuando los reportes no cierran, cuando los equipos de ventas empiezan a llevar sus propias planillas paralelas “porque el sistema no refleja la realidad”, cuando la adopción cae y nadie termina de entender por qué.

El síntoma no es el problema

Cuando una implementación no funciona, las señales típicas son conocidas: baja adopción, datos inconsistentes, reportes que no coinciden con lo que el negocio percibe, usuarios que evitan el sistema. La reacción natural de una organización es tratar estos síntomas como problemas de configuración: falta un campo, falta una validación, falta capacitación.

El problema real casi nunca está ahí. Está en que el proceso de negocio que se llevó a Salesforce nunca fue rediseñado; simplemente fue trasladado. Se tomó el Excel que usaba el equipo comercial, con sus columnas, sus criterios ambiguos y sus excepciones informales, y se lo convirtió en objetos y campos. El resultado es un CRM que reproduce fielmente la ineficiencia anterior, ahora con una interfaz más cara y más rígida.

Rediseñar antes de configurar

La secuencia correcta de un proyecto de transformación con Salesforce no empieza en el sistema. Empieza en el proceso. Antes de abrir el Setup, hay preguntas que deberían tener respuesta clara:

• ¿Cuál es el objetivo de negocio detrás de este proceso? No “registrar oportunidades”, sino qué decisión de negocio se toma con esa información y quién la toma.
• ¿Dónde están hoy los cuellos de botella reales? Muchas veces no están donde el equipo cree.
• ¿Qué pasos existen solo por costumbre y no agregan valor? Todo proceso legado acumula pasos que nadie recuerda por qué existen.
• ¿Qué información se necesita realmente para tomar decisiones, y qué información se pide “por si acaso”?

Sin este ejercicio previo, cualquier implementación —sin importar cuán bien ejecutada técnicamente esté— hereda los defectos del proceso original. Un Salesforce perfectamente configurado sobre un proceso mal diseñado es, en el mejor de los casos, una automatización elegante de un problema.

El rol del partner o consultor

Aquí aparece una tensión estructural en la industria: muchos proyectos se venden y se ejecutan como “implementación de Salesforce”, con foco en entregables técnicos —objetos, flows, integraciones, dashboards— y no como proyectos de rediseño de procesos que usan Salesforce como plataforma de ejecución.

Esta diferencia no es semántica. Cambia el tipo de conversación inicial con el cliente, cambia quién debe estar en la sala durante el descubrimiento (no solo IT, sino los dueños de proceso y, sobre todo, los usuarios finales que van a vivir con el sistema todos los días), y cambia cómo se mide el éxito del proyecto. “Salesforce está funcionando técnicamente” y “el negocio está operando mejor” son dos afirmaciones distintas, y la segunda es la única que realmente importa.

Señales de que el proceso, no la herramienta, es el problema

Hay patrones que se repiten en organizaciones que atribuyen a Salesforce fallas que en realidad son de proceso:

• Cuando los usuarios piden “que el sistema haga lo mismo que hacíamos antes, pero en Salesforce”, sin cuestionar si lo que hacían antes tenía sentido.
• Cuando cada área quiere su propio flujo de aprobación distinto para el mismo tipo de proceso, reflejando fragmentación organizacional en lugar de un estándar.
• Cuando la definición de “oportunidad ganada” o “lead calificado” varía según quién responda la pregunta dentro de la misma empresa.
• Cuando existen reportes en Excel que “corrigen” lo que dice el CRM, porque nadie confía en los datos del sistema.

Ninguno de estos síntomas se resuelve con más configuración. Se resuelven con una conversación incómoda sobre cómo debería funcionar el proceso, que probablemente debió pasar antes de tomar el primer ticket.

Qué implica hacerlo bien

Un proyecto que empieza por el proceso suele avanzar más lento al principio y más rápido después. Las primeras semanas se invierten en mapear el estado actual, cuestionar supuestos y acordar un estado futuro con los dueños de negocio, no solo con IT. Esto genera fricción temprana: decisiones que antes se evitaban ahora hay que tomarlas explícitamente.

Pero esa fricción temprana es infinitamente más barata que la fricción tardía. Rediseñar un proceso en una sesión de trabajo cuesta horas. Rediseñarlo después de seis meses de uso, con datos ya cargados, integraciones ya construidas y usuarios ya acostumbrados a rutinas defectuosas, cuesta meses y erosiona la confianza en el proyecto completo.

El costo de posponer el rediseño

Cuando el rediseño de proceso se pospone —porque “no hay tiempo”, o porque implica conversaciones difíciles entre áreas— ese costo no desaparece. Se traslada hacia adelante y, generalmente, se multiplica.

Un proceso mal diseñado que se lleva a producción empieza a generar datos de baja calidad casi de inmediato, porque los usuarios encuentran formas de saltear pasos que no tienen sentido para ellos, o completan campos con información incorrecta solo para poder avanzar. Esos datos de baja calidad, acumulados durante meses, contaminan cualquier reporte, cualquier proyecto de analítica posterior y cualquier intento futuro de automatización sobre esa información. Corregir el proceso en ese punto no solo implica rediseñarlo: implica también limpiar y potencialmente volver a cargar información histórica, un trabajo mucho más costoso que el rediseño inicial que se evitó.

Además, cuando los usuarios ya se acostumbraron a un flujo de trabajo, incluso si es ineficiente, cambiarlo genera una resistencia adicional que no existía antes de que el sistema estuviera en producción. La ventana más barata para rediseñar un proceso es siempre antes de que exista una rutina instalada alrededor de él.

La pregunta que debería abrir todo proyecto

Antes de firmar el alcance de cualquier implementación, la pregunta que debería hacerse una organización no es “¿qué queremos que Salesforce haga?”, sino “¿qué queremos que nuestro proceso logre, y estamos dispuestos a cambiarlo para lograrlo?”

Si la respuesta es que el proceso actual es intocable y Salesforce simplemente debe adaptarse a él tal como está, probablemente no se necesita una transformación: se necesita una migración de formato. Y eso está bien, siempre que la organización lo sepa de entrada y no espere resultados de transformación de un proyecto que nunca se propuso transformar nada.

La herramienta rara vez es el problema. El proceso que se le entrega, casi siempre lo es.