Cuando el software intenta decidir por la empresa
Digitalizar no te ahorra una decisión estratégica. Más bien la deja más expuesta, y si la metes antes de tiempo, además te sale más cara. La tecnología sí puede acelerar una organización, pero también puede amplificar sus vacíos cuando la dirección todavía no ha definido hacia dónde va.
Y aquí viene la tentación de siempre en tecnología: si un proceso ya existe, parece lógico llevarlo al software y darlo por cerrado. El problema es que muchas veces la organización todavía no tiene claro qué parte de su negocio quiere estabilizar y cuál prefiere seguir explorando. En ese punto, la herramienta termina cargando con una ambigüedad que, en realidad, seguía siendo del negocio.
Ese matiz cambia el proyecto por completo. Hace unos meses estuve viendo una consultora de RR. HH. que venía de operar con papel, Excel, macros y presentaciones. Digitalizar tenía sentido, sí, pero el modelo que debía sostener esa digitalización seguía abierto. El equipo empezó a construir mientras todavía flotaban dudas bastante básicas sobre qué se monetizaba, qué se automatizaba, qué debía conservar flexibilidad y qué riesgos comerciales iba a asumir el nuevo sistema.
Desde la óptica de un CTO, eso enciende una alarma bastante clara. Cuando el negocio no ha fijado sus hipótesis críticas, el software deja de ejecutar una decisión y pasa a explorarla a un coste alto. Ahí empiezan el retrabajo, los cambios de arquitectura, la deuda técnica y la fricción contractual, y todo eso se va regando por la organización. La rapidez aparente del arranque casi siempre termina convirtiéndose en una carga operativa difícil de deshacer.
Eso fue lo que ocurrió aquí. El equipo técnico era sólido, había trazabilidad y la tecnología elegida tenía sentido. Aun así, cada decisión de negocio tardaba semanas o meses en cerrarse mientras el sistema seguía avanzando. Un ajuste pequeño podía tocar diagnósticos, formularios, informes y dashboards. La ingeniería no estaba mal planteada. El problema era otro: las reglas todavía no habían agarrado suficiente estabilidad.
La tensión creció cuando el cliente pasó de un servicio puntual a un modelo recurrente, con igualas, pagos con tarjeta y nuevas vías comerciales. Ese cambio no era un ajuste funcional. Era otro negocio. Y una plataforma diseñada para digitalizar un proceso no debería cargar, por defecto, con la responsabilidad de redefinir la dirección comercial. Cuando esa frontera se borra, la tecnología termina tomando decisiones que le tocaban a la estrategia.
La lección para cualquier líder tecnológico es sencilla, pero no precisamente cómoda. Antes de escribir la primera línea de código, conviene cerrar qué se quiere fijar y qué se quiere descubrir. El diagnóstico, la monetización, el alcance y los criterios de cambio son decisiones de gobierno. Cuando eso no está resuelto, el backlog acaba ocupando el lugar de la estrategia. Y ese intercambio suele salir caro, porque lo que se posterga es justamente la claridad que la organización necesitaba desde el inicio.
No siempre hace falta construir menos. A veces hace falta decidir mejor. El software no corrige la ambigüedad. La convierte en coste, casi siempre demasiado tarde.
