En muchas, probablemente la mayoría, de las grandes empresas que operan una cadena de suministro, el departamento de tecnología de la información tiene años de retraso acumulado. El retraso está compuesto por una miríada de fallas, inconsistencias o fragilidades que podrían solucionarse pero no lo están. Además de crear una gran burocracia, esta interminable serie de molestias sin sentido desmotiva a todos. La cadena de suministro, que se encuentra justo en el medio del paisaje aplicativo, se ve particularmente afectada. De manera anecdótica, la porción de la cadena de suministro1 representa con frecuencia la mitad de todo el retraso acumulado de TI de la empresa.

El papel de la tecnología de la información en tu cadena de suministro

Peor aún, el retraso a menudo se ve oscurecido por alguna Gran Transición, típicamente una actualización de ERP. Esta es la consecuencia directa de que se espera que la Gran Transición resuelva todos los problemas que se han dejado sin abordar durante la última década. Sin embargo, esta expectativa es equivocada. De hecho, la Gran Transición, incluso si se completa con éxito2, introducirá muchos problemas nuevos, incluso si logra eliminar algunos de los antiguos, medio siglo después.

La Gran Transición tiene dos efectos secundarios: primero, silencia a todas las divisiones, excepto a TI, cuando se trata de asuntos de software; segundo, actúa como un agujero negro que absorbe todos los presupuestos y energía. El segundo es una consecuencia del primero.

Debido a su propia naturaleza, la Gran Transición es altamente técnica. Nadie, excepto los especialistas en TI, comprende realmente los detalles de la migración de un sistema de base de datos a otro y las sutiles incompatibilidades que existen entre ambos. Una vez que los otros departamentos son silenciados, no hay resistencia para canalizar todo hacia la Gran Transición. Los demás departamentos suelen colaborar debido a la esperanza equivocada de que acelerará la Gran Transición. No lo hará. Ocurre lo contrario: cuanto mayor es el presupuesto, más lenta es la iniciativa.

Entre las grandes empresas, este enfoque ha sido predominante durante las últimas dos décadas. Los resultados son desastrosos. Las empresas siguen pagando tarifas extravagantes por aplicaciones CRUD3 que deberían haberse convertido en productos básicos, a través del código abierto, hace más de una década. Los retrasos en la implementación nunca han sido más largos. Para colmo de males, el rendimiento y la capacidad de respuesta del software empresarial siguen siendo tan deficientes como siempre, mientras que el hardware subyacente es 1000 veces más capaz que hace dos décadas.

Esta situación requiere una solución profunda: el departamento de TI debe dejar de actuar como el Gran Arquitecto en nombre de todos los demás departamentos. En cambio, el departamento de TI debe convertirse en un entrenador para los demás departamentos, con un enfoque exclusivo en la infraestructura4, dejando todo lo demás en manos de los departamentos mismos con una mentalidad de facilitador.

La posición de Gran Arquitecto es insostenible: incluso colectivamente, TI no puede saber todo lo que hay que saber sobre finanzas, marketing, ventas, nóminas, producción, contabilidad, transporte, planificación, cumplimiento, legal, etc. El “hombre para todo” arruina la mayoría de las iniciativas que emprende. Cada entrega a medias resulta en más problemas que necesitan ser solucionados más adelante. La generación de retraso acumulado es tanto inevitable como interminable. A medida que el software se vuelve más ubicuo con cada año que pasa, el retraso acumulado se vuelve cada vez más inmanejable cada año.

La solución es sencilla5: renunciar al Gran Arquitecto y reposicionar el departamento de TI como un facilitador y mentor para todas las iniciativas relacionadas con el software ejecutadas por otros departamentos. Al poner a los departamentos, como la cadena de suministro, a cargo de sus propias iniciativas de software, se les obliga a revisar sus propias ambiciones: no más chivos expiatorios por el descontrol del retraso acumulado. El departamento es responsable tanto de sus éxitos como de sus fracasos.

Sin embargo, casi nunca se implementa la solución.

Reposicionar a TI como un facilitador significaría reducir sus presupuestos a la mitad o más, como consecuencia directa de una huella operativa mucho más reducida en la empresa. Esto es inaceptable para el jefe del departamento de TI, cuya posición a menudo rivaliza, en términos de poder, con la del CEO durante la Gran Transición.

Esto también significaría que los jefes de departamento tendrían que ser responsables de sus propias iniciativas de software, o de la falta de ellas. Hay comodidad en poder desviar la culpa a TI cada vez que un proyecto se desvía, lo cual es algo común en el software. También permite a los departamentos evitar el espinoso problema de contratar talento en TI, lo cual ha sido un desafío durante décadas.

Sin embargo, a medida que el software empresarial se mueve hacia SaaS (Software como Servicio), la perspectiva del Gran Arquitecto se está desvaneciendo gradualmente, ya que los proveedores se encargan del alojamiento, las copias de seguridad, las actualizaciones, etc. Así, aunque incidentalmente, los jefes de departamento se ven gradualmente obligados a ser responsables de sus decisiones de software, y el departamento de TI se ve gradualmente obligado a renunciar a sus antiguas responsabilidades.

El software empresarial llegó una década tarde a la fiesta de SaaS. Preveo que tomará otra década para que la mayoría de las grandes empresas abandonen la mentalidad del Gran Arquitecto.


  1. El retraso acumulado en la cadena de suministro adopta muchas formas: la TI en la sombra es desenfrenada, Excel está en todas partes, las operaciones / clientes / proveedores se mantienen en la oscuridad, los stocks / pedidos / envíos no están correctamente sincronizados entre los sistemas, predominan las entradas manuales en lugar de la automatización, etc. ↩︎

  2. En estas Grandes Transiciones, solo hay un ganador: el proveedor de software que lidera el proceso. En 15 años, nunca he visto ninguna actualización de varios años que aporte algo más que mejoras mínimas. Sin embargo, he visto una y otra vez a los proveedores de software obtener retornos espectaculares en esas operaciones. ↩︎

  3. Crear, Leer, Actualizar, Eliminar. Las aplicaciones CRUD son el pan y la mantequilla del software empresarial. Casi todas las aplicaciones de flujo de trabajo y aplicaciones transaccionales son CRUD. ↩︎

  4. Redes, federación de identidad, sistemas operativos, copias de seguridad, etc. ↩︎

  5. Hasta la década de 2000, era difícil unir software empresarial a través de Internet. Por lo tanto, traer software dispar y conectarlos después no era una opción antes de la década de 2000; ciertamente no una opción económica. Los primeros sistemas empresariales comenzaron como monolitos por necesidad, no por elección. Por lo tanto, la “solución” presentada anteriormente solo se convirtió en una opción realista a principios de la década de 2010. ↩︎