De todas las confusiones que me tocó desarmar en estos años, hay una que vuelve más que ninguna y casi siempre con las mismas palabras: proceso y workflow usados como sinónimos. Alguien dice que va a «armar el proceso» y lo que en realidad quiere decir es que va a configurar una automatización. Nadie lo corrige, porque en la superficie suenan parecido: algo que ocurre, en cierto orden, sin que haya que empujarlo. Debajo hay dos cosas distintas, y una es condición de la otra.
Un proceso es una decisión sobre cómo trabaja la empresa: qué pasa, en qué orden, con qué criterio y quién responde cuando no ocurre. Se toma en la mesa donde se decide el negocio, no en una pantalla de configuración. Un workflow es otra cosa, más modesta y más útil de lo que parece: la ejecución automática de una parte de ese proceso. El primero se diseña. El segundo se configura. Y el segundo no existe sin el primero, aunque la herramienta te deje crearlo igual.
Un workflow no decide nada. Ejecuta la decisión que ya tomaste o, si no la tomaste, ejecuta su ausencia.
La diferencia se nota en una reunión mucho antes que en ninguna herramienta. Cuando alguien pide «un workflow para que el vendedor cargue el motivo de pérdida», la conversación parece de automatización y no lo es. Si el vendedor no lo carga, el problema no es que se lo pidan de forma manual. Es que nadie definió qué cuenta como motivo de pérdida, para qué se va a usar esa información y a quién le importa que falte. Un recordatorio automático no responde ninguna de esas preguntas: consigue el campo lleno y no consigue el dato.
Ahí está el costo real de automatizar sin haber decidido. El workflow no corrige lo que estaba mal: lo multiplica, y de paso lo vuelve invisible. Un criterio improvisado, mientras lo sostienen personas, deja rastro: alguien se queja, alguien pregunta, alguien lo improvisa distinto y se nota. Cuando ese mismo criterio pasa a ejecutarse de forma automática, deja de tener autor. Ya no hay a quién preguntarle por qué se hace así, porque no lo hace nadie. Se dispara.
Por eso, antes de configurar, hay unas pocas respuestas que conviene tener escritas. Qué tiene que ser cierto para que esto ocurra. Quién decidió que ese sea el criterio y con qué autoridad. Qué pasa con los casos donde no aplica. Y quién se entera si deja de funcionar. Ninguna es una pregunta técnica; las cuatro son de negocio. Si esas respuestas no existen, el workflow no las espera: las inventa, y la empresa termina operando con un criterio que nunca discutió.
El que sí se diseñó bien tampoco es para siempre. Un workflow que nadie revisa sigue ejecutando una decisión que la empresa ya dejó de tomar. Cambió el equipo, cambió el segmento al que le vende, cambió la forma de cobrar, y esa regla sigue moviendo registros con el criterio de hace dos años. Se acumulan, se pisan entre ellas, y llega el punto en que nadie se anima a apagar ninguna porque nadie sabe qué depende de qué. Eso ya no es automatización: es deuda, y se paga como cualquier otra.
Nada de esto es un argumento contra automatizar, al contrario. Cuando el proceso está decidido, el workflow es la forma más barata que conozco de sostenerlo: hace que el criterio se cumpla siempre igual, sin depender de la memoria ni del ánimo de nadie, y libera a las personas de la parte que nunca necesitó juicio. Lo que no puede hacer es reemplazar la conversación donde ese criterio se define. El orden no es un detalle de implementación.
Así que cuando me piden automatizar algo, devuelvo siempre la misma consigna: contame el proceso sin nombrar la herramienta. Quién hace qué, en qué momento, con qué criterio, y qué pasa si no se cumple. Si se puede contar así, configurarlo es cuestión de días. Y si no se puede contar, ya sabemos las dos partes que lo que falta no es un workflow.
Diseñar es decidir cómo trabaja tu empresa. Configurar es pedirle a un sistema que repita esa decisión sin cansarse. Son dos trabajos distintos, y solo uno de los dos es delegable.
Un workflow hace exactamente lo que le pediste. El problema aparece cuando no sabías qué le estabas pidiendo.