El horror no euclidiano (antipatrón de la cadena de suministro)

Por Joannès Vermorel, junio de 2015

El horror no euclidiano ha surgido de las profundidades de los sistemas de TI de la empresa. Observar fijamente durante demasiado tiempo el horror no euclidiano puede desencadenar un estado permanente de pérdida de la cordura.

Categoría: organización

Problema: A lo largo de los años, la empresa ha establecido diferentes sistemas. Ahora cuenta con un ERP, un WMS (sistema de gestión de almacenes), un CRM (gestión de relaciones con el cliente), un cubo BI (inteligencia de negocios), una plataforma de e-commerce, etc. Entre las implementaciones de todos estos sistemas, también se han desarrollado componentes in-house para realizar tareas más especializadas. La complejidad del entorno de TI ha aumentado drásticamente con los años, ya que cada aplicación adicional necesita comunicarse con todas las demás aplicaciones ya implementadas por la empresa. Todas las divisiones perciben los efectos, pero la cadena de suministro, que se entre entre Ventas, Compras, Finanzas y Producción, es la más afectada. Los cambios son muy lentos, y casi ninguna iniciativa de cadena de suministro logra cumplir con los plazos establecidos. Ya nadie entiende realmente lo que está sucediendo dentro de los sistemas de la empresa.

Evidencia anecdótica: El movimiento físico de un almacén a otro cercano puede hacerse en dos semanas. Sin embargo, en lo que hace al software, la migración de TI real necesaria para integrar el nuevo almacén llevará más de seis meses.

Contexto: Hace mucho tiempo, cada división de la empresa había comenzado con su propia solución de software. La integración era escasa y, finalmente, se decidió que se establecería un sistema ERP para gobernarlos a todos. El sistema ERP se implementó, pero no logró seguirle el ritmo a los acelerados cambios de la industria de software. En cuanto a la cadena de suministro, se estableció un WMS (sistema de gestión de almacenes) para mejorar la productividad y la fiabilidad, algo que, en cambio, sí funcionó relativamente bien. Otras divisiones dieron pasos similares estableciendo sus propias aplicaciones específicas de dominio, que resultaban ser más adecuadas que el ERP original. Sin embargo, los negocios están cambiando más rápidamente que nunca, y hoy en día, tener operaciones de cadena de suministro más inteligentes implica una miríada de interacciones entre todas estas aplicaciones diferentes.

Solución hipotética: Cada vez que aparece un nuevo desafío, los sistemas de TI se ajustan lo mínimo indispensable para entregar los resultados esperados. Para los fines de la cadena de suministro, se han establecido una integración ad-hoc con el CRM para recopilar información del equipo de Ventas, y otra integración ad-hoc con el cubo BI, porque es el único modo de obtener datos numéricos que sean coherentes con los utilizados por Finanzas. Los servicios de logística y los proveedores han necesitado bastantes integraciones propias. Como resultado, el equipo de la cadena de suministro ha aprendido que cuanto mayor es el cambio de TI, más probabilidades habrá de que se supere el presupuesto y no se cumpla con los plazos establecidos. Por lo tanto, ahora se prefieren los cambios graduales reducidos antes que cualquier evolución sustancial.

Contexto resultante: El mapa del metro de Tokio parece simple comparado con la representación de las diferentes interacciones de TI dentro del negocio. Existen cientos de dependencias sutiles entre los sistemas dentro de la empresa. La imagen de conjunto del entorno de TI es, en el mejor de los casos, muy confusa. En la cadena de suministro, se lucha constantemente para obtener acceso a toda la información relevante, como nuevos productos, promociones, pedidos de compra que están casi finalizados, historial de niveles de stock y desabastecimientos, etc. Cada pequeña revisión de las operaciones de cadena de suministro, en las que se mejorará un proceso aprovechando un dato adicional, parece un proceso de nunca acabar. Las entradas de datos son inconsistentes, los sistemas fallan constantemente y aparecen por todas partes excepciones que deben gestionarse en forma manual.

Fuerzas seductoras: La empresa ha aprendido por las malas que cuanto mayor es la iniciativa de TI, mayor es la probabilidad de que falle. Por lo tanto, todas las prácticas evolucionan gradualmente hacia iniciativas más reducidas y concentradas, que son más fáciles de implementar, permiten respetar el presupuesto y cumplir con los plazos establecidos. La empresa logró alcanzar éxitos tempranos precisamente a través de iniciativas de pequeña escala, con resultados positivos que se obtuvieron con presupuestos reducidos.

Por qué esto lleva al fracaso: Cada cambio gradual aumenta el costo y la complejidad de cualquier cambio ulterior. Debido a que las prácticas de la empresa favorecen cambios que sean lo más pequeños y graduales posible, se genera una falta de preocupación por la imagen global. En cierta medida , este es un caso de la tragedia de los comunes, en la que los intereses individuales (las divisiones individuales de la empresa) no están alineados con los intereses comunes de la empresa en conjunto. El problema se hace más grave porque los efectos negativos generalmente se observan solo mucho tiempo después de que se ha realizado el cambio. Si bien cada cambio parece ser rentable, la empresa sigue acumulando deuda técnica, lo que convierte las ganancias a corto plazo en pérdidas en el largo plazo.

Patrones positivos para abordar el problema: En su esencia, la implementación de cambios graduales es un abordaje razonable por adoptar. Sin embargo, cada cambio debería ser ejecutado de modo tal que todo cambio subsiguiente resultara más económico o más simple (ambas propiedades están íntimamente relacionadas en la práctica). Esto implica que cada iniciativa debe pagar el impuesto de los comunes, donde no solo se cumple el objetivo primario de la iniciativa, sino también el objetivo secundario, que consiste en hacer que los procesos se vuelvan más sencillos durante los cambios futuros.

Ejemplo: Contoso es un líder del e-commerce nacional en Alemania con un segmento de B2C específico. La empresa comenzó operando a principios del 2000, desarrollando un front-end, es decir, la aplicación que le permite a la gente comprar en línea, hecho a medida en ese momento. En los primeros años de la empresa, casi todas sus necesidades de TI se resolvían a través de un front-end que crecía constantemente. Sin embargo, la gestión de proveedores y pedidos de compra era simplemente demasiado para la aplicación a medida. Como consecuencia, Contoso decidió invertir en un ERP de mercado medio para pasar la carga de todos los procesos de back-office al sistema ERP, incluido el volumen de prácticas de cadena de suministro emergentes. Por un tiempo, los niveles de stock se gestionaron tanto dentro del front-end como dentro del ERP, pero, dado que resultaba desordenado, Contoso logró finalmente desligar con éxito al front-end de sus extremadamente amplias responsabilidades.

Al principio, el ERP cumplió con su función, pero, a medida que la empresa siguió creciendo, y a pesar de los mejores esfuerzos del equipo técnico a cargo de los desarrollos del ERP, este no lograba seguirle el ritmo a las exigencias del negocio. Los informes eran insuficientes, y Finanzas decidió establecer su propio portal de BI (inteligencia de negocios), mientras que la mayoría de las demás divisiones implementó aplicaciones similares en su campo. La cadena de suministro lanzó una serie de integraciones EDI para enviar sus pedidos de compra a los proveedores, pero canalizar todo en el ERP estaba comenzado a ser frustrante, porque el ERP simplemente no podía captar todas las sutilezas de las operaciones de la cadena de suministro de Contoso.

Cuando Contoso llegó a convertirse en un líder nacional, comenzó a tener acceso a una amplia gama de opciones de abastecimiento. Los distribuidores alemanes locales que habían desempeñado inicialmente un papel clave en el éxito de Contoso ahora resultaban ser cada vez más costosos mientras que los competidores de Contoso disminuían sus precios. Los días en los que los clientes estaban dispuestos a pagar extra por comprar en línea se habían terminado. Como resultado, Contoso tuvo que integrar gradualmente opciones de abastecimiento alternativas en su flujo de trabajo, generalmente utilizando los servicios de proveedores más lejanos, incluso en el extranjero. Al cabo de algunos meses de lucha infructuosa intentado combinar la la lógica multiabastecimiento con el ERP a la fuerza, el equipo de cadena de suministro decidió que había llegado la hora de implementar su propio sistema, separado del ERP. El equipo de cadena de suministro eligió una aplicación de abastecimiento avanzada, pero su implementación llevó más tiempo del esperado. No era culpa de la nueva solución: era la integración con el ERP la que dio lugar a un serie de dificultades inesperadas. Por ejemplo, tres meses después del lanzamiento de la nueva solución, los equipos de cadena de suministro se dieron cuenta de que los retrasos en los envíos mostrados en el sitio web de cliente no eran gestionados por el ERP, sino por el front-end. Por lo tanto, estos retrasos en los envíos mostrados pasaban del front-end al ERP, pero no había nada que respaldara el camino inverso. Como resultado, la introducción de retrasos de envío revisados —actualizados dinámicamente de acuerdo con el proveedor seleccionado para proporcionar el producto— en el ERP no tenía ningún efecto sobre los números que mostraba el sitio web. El ERP ya se había convertido en un sistema bastante complejo, y cuando el equipo de TI de Contoso comenzó a sentirse mucho más a gusto con el front-end que había desarrollado internamente, los equipos de cadena de suministro y de TI decidieron juntos que la solución de abastecimiento introduciría los retrasos de envío revisados directamente en el front-end.

El método resultó ser un tanto desordenado y, si bien se había planificado originalmente implementar la aplicación de abastecimiento en tres meses, estos se convirtieron en nueve. No obstante, valió la pena la inversión, ya que el multiabastecimiento tuvo como resultado la disminución de los precios de compra promedio en un 15 %, lo que implicó un impulso considerable para el negocio.

Adelantémonos hasta el presente. El equipo de compras de Contoso, ahora separado de la división de cadena de suministro, ha negociado acuerdos favorables, pero lamentablemente complejos, con sus proveedores más grandes. Por ejemplo, el proveedor podría devolver montos significativos de dinero al final de cada trimestre si se alcanzan determinadas cuotas, que generalmente implican una combinación de volúmenes de ventas en euros y cantidades de unidades compradas. Hace 12 meses, el equipo de cadena de suministro lanzó una iniciativa para tener en cuenta tales acuerdos al seleccionar los proveedores más rentables para cada pedido de compra. Sin embargo, la iniciativa está, en gran parte, estancada. Los términos contractuales del proveedor se encuentran en el sistema de compra, los elementos financieros solo pueden encontrarse en los sistemas de BI, mientras que otros datos relacionados con el proveedor siguen estando en el front-end, sin que se haya realizado ninguna actualización interna para unir todas las piezas del rompecabezas. La dimensión del cambio necesario es en realidad pequeña, pero parece que cada sistema individual dentro de la empresa está involucrado. El desgano es generalizado y la gente se está concentrando cada vez más en su próxima tarea, ya que no hay ningún resultado positivo a la vista.