Cuando una empresa nos llama para “digitalizar un proceso”, la conversación suele empezar por la herramienta. Qué plataforma, qué integración, si móvil o web, cuánto tarda. Es una conversación cómoda porque todas esas preguntas tienen respuesta y presupuesto.
La pregunta incómoda llega más tarde, y casi siempre la tenemos que hacer nosotros: ¿quién decide hoy, exactamente, en ese proceso? No quién lo ejecuta. Quién decide. Y la respuesta, con una frecuencia que ya no me sorprende, es que no está claro. El proceso funciona porque tres personas se conocen desde hace años, se llaman por teléfono y resuelven. Eso no está escrito en ningún sitio, y por eso funciona: la ambigüedad es lo que lo hace flexible.
Un proceso sin dueño no se arregla poniéndolo en una pantalla
Lo que ocurre al digitalizar ese proceso es predecible. El software obliga a tomar decisiones que antes se podían dejar abiertas. Un formulario tiene que saber qué campos son obligatorios. Un flujo de aprobación tiene que saber quién aprueba. Un estado tiene que existir o no existir.
De golpe, todas las ambigüedades que hacían el proceso llevadero se convierten en decisiones de diseño. Y como nadie las ha tomado a nivel de organización, las acaba tomando quien está construyendo la herramienta: un analista, un desarrollador, alguien que hace una suposición razonable a las siete de la tarde para poder seguir avanzando.
Así se llega al resultado clásico: una aplicación técnicamente correcta que nadie usa, y un equipo que vuelve al Excel porque “la herramienta no contempla los casos reales”. No es que no los contemple. Es que los casos reales nunca se acordaron.
Lo que sí cambia el resultado
De lo que he visto funcionar, tres cosas importan más que la elección de tecnología:
- Nombrar un responsable único del proceso, no del proyecto. El responsable del proyecto se va cuando el proyecto acaba. El del proceso se queda. Si no existe esa figura, la herramienta se degrada en cuanto cambia el negocio.
- Escribir las reglas antes de construirlas. En texto, en una página, en lenguaje de negocio. Si la regla no se puede escribir en una frase que dos departamentos firmen, no está lista para convertirse en código.
- Aceptar que la primera versión va a cambiar el trabajo de alguien. Y decirlo en voz alta. La resistencia a una herramienta nueva casi nunca es resistencia a la tecnología: es a la pérdida de discrecionalidad que la tecnología trae consigo.
Ninguna de las tres es una decisión técnica. Todas se toman antes de abrir un editor de código, y las tres determinan si el proyecto va a servir para algo.
Por qué esto se repite tanto
Porque comprar software es más fácil que reorganizar responsabilidades. Un presupuesto de desarrollo se aprueba en un comité; una conversación sobre quién pierde poder de decisión no se aprueba en ningún sitio y no tiene fecha de entrega.
La tentación, entonces, es tratar la herramienta como si fuera la reforma. Y la herramienta no puede serlo: sólo puede hacer cumplir decisiones que ya se han tomado. Cuando no se han tomado, lo que hace el software es exponer el vacío con mucha más nitidez que antes — y encima con factura.
Esto es también, dicho de paso, la razón por la que tantos proyectos de inteligencia artificial se atascan en el mismo punto: la discusión se va a los modelos cuando el problema está en las decisiones previas. De eso escribí en lo que hay que decidir antes de meter IA en un producto que ya funciona.