En muchas, probablemente la mayoría, de las grandes empresas que operan una supply chain, el departamento de IT tiene años de backlog. El backlog está compuesto por una miríada de fallos, inconsistencias o fragilidades que podrían ser corregidos pero no lo están. Además de generar enormes cargas burocráticas, esta interminable serie de molestias sin sentido desmotiva a todos. La supply chain, ubicada justo en el medio del paisaje aplicativo, se ve particularmente afectada. Anecdóticamente, la porción de supply chain1 representa frecuentemente la mitad de todo el backlog de IT de la empresa.

El rol de IT en tu supply chain

Peor aún, el backlog frecuentemente queda 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 han quedado sin atender durante la última década. Sin embargo, esta expectativa está equivocada. De hecho, la Gran Transición, incluso si se completa con éxito2 medio decenio después, habrá introducido muchos problemas nuevos, incluso si logra eliminar algunos de los antiguos.

La Gran Transición viene con dos efectos secundarios: primero, silencia a todas las divisiones - excepto IT - cuando se trata de cuestiones de software; segundo, actúa como un agujero negro que absorbe todos los presupuestos y energías. Este segundo efecto es consecuencia del primero.

Debido a su propia naturaleza, la Gran Transición es altamente técnica. Nadie - excepto los especialistas de IT - entiende realmente la letra pequeña de la migración de un sistema de bases de datos a otro, y las sutiles incompatibilidades que existen entre ambos. Una vez que las otras divisiones quedan silenciadas, no hay resistencia para canalizar todo hacia la Gran Transición. Las otras divisiones usualmente colaboran debido a la equivocada esperanza 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 desalentadores. Las empresas todavía pagan tarifas extravagantes por aplicaciones CRUD3 que deberían haberse convertido en productos básicos – a través del open source – hace más de una década. Los retrasos en la implementación nunca han sido mayores. La guinda del pastel: el rendimiento y la capacidad de respuesta del software empresarial sigue siendo tan pobre como siempre, mientras que el hardware subyacente es 1000x más capaz de lo que era hace dos décadas.

Esta situación requiere una solución profunda: el departamento de IT debe dejar de actuar como el Gran Arquitecto en nombre de todas las demás divisiones. En su lugar, el departamento de IT debe convertirse en un coach para las otras divisiones, con un enfoque exclusivo en la infraestructura4, dejando todo lo demás en manos de las propias divisiones con una mentalidad de facilitador.

La posición de Gran Arquitecto es insostenible: ni siquiera colectivamente, IT puede saber todo lo que hay que saber sobre finanzas, marketing, ventas, nóminas, producción, contabilidad, transporte, planificación, cumplimiento, legal, etc. El todoterreno estropea la mayoría de las iniciativas que emprende. Cada entrega a medias resulta en más problemas que luego necesitan solución. La generación de backlog es tanto inevitable como interminable. A medida que el software se vuelve más omnipresente con cada año que pasa, el backlog se vuelve cada vez más inmanejable.

La solución es sencilla5: abandonar al Gran Arquitecto y reposicionar el departamento de IT como un facilitador y mentor para todas las iniciativas relacionadas con el software ejecutadas por otras divisiones. Poner a las divisiones, como la supply chain, a cargo de sus propias iniciativas de software las obliga a revisar sus propias ambiciones: no más chivos expiatorios por un backlog fuera de control. La división es responsable tanto de sus éxitos como de sus fracasos.

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

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

Esto también significaría que los jefes de división tendrían que hacerse responsables de sus propias iniciativas de software - o la falta de ellas. Existe la comodidad de poder desviar la culpa a IT cada vez que un proyecto se descontrola, algo común en el software. También permite que las divisiones eviten el espinoso tema de contratar talentos de IT, lo cual ha sido un desafío durante décadas.

No obstante, a medida que el software empresarial se mueve hacia SaaS (Software as a Service), la perspectiva del Gran Arquitecto está desapareciendo gradualmente, ya que los proveedores se hacen cargo del hosting, respaldos, actualizaciones, etc. Así, aunque de manera incidental, los jefes de división se ven forzados gradualmente a asumir la responsabilidad de sus decisiones de software, y el departamento de IT se ve forzado gradualmente a dejar atrás sus antiguas responsabilidades.

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


  1. El backlog de la supply chain adopta muchas formas: la TI en la sombra está muy extendida, Excel está en todas partes, operaciones / clientes / proveedores se mantienen a oscuras, stocks / pedidos / envíos no se sincronizan adecuadamente entre sistemas, las entradas manuales prevalecen en lugar de la automatización, etc. ↩︎

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

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

  4. Redes, federación de identidades, sistemas operativos, respaldos, etc. ↩︎

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