El Horror No Euclidiano (Antipatrón de la Cadena de Suministro)
El horror no euclidiano ha surgido de las profundidades de los sistemas de TI de la empresa. Mirar fijamente el horror no euclidiano durante demasiado tiempo puede resultar en una pérdida permanente de la cordura.
Categoría: organización
Problema: a lo largo de los años, la empresa ha establecido muchos sistemas diferentes. Ahora tienen un ERP, un WMS (sistema de gestión de almacenes), un CRM (gestión de relaciones con los clientes), un cubo de BI (inteligencia de negocios), una plataforma de comercio electrónico, etc. Entre la implementación de todos estos sistemas, también se han desarrollado componentes internos para realizar tareas más especializadas. La complejidad del panorama de TI ha aumentado considerablemente a lo largo de los años, ya que cada aplicación adicional debe comunicarse con todas las demás aplicaciones ya implementadas por la empresa. Todas las divisiones se ven afectadas, pero la cadena de suministro, que se encuentra entre las ventas, las compras, las finanzas y la producción, es la más afectada. Los cambios son lentos y casi todas las iniciativas de la cadena de suministro no logran cumplir con sus plazos. Nadie entiende realmente lo que está sucediendo dentro de los sistemas de la empresa.
Evidencia anecdótica: Físicamente, mudarse de un almacén a otro cercano podría hacerse en dos semanas. Sin embargo, en cuanto al software, la migración de TI necesaria para integrar el nuevo almacén va a llevar más de 6 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 deficiente y finalmente se decidió establecer un sistema ERP que “los gobernara a todos”. Se implementó el sistema ERP, pero no logró mantenerse al ritmo acelerado de cambio en la industria del software. En lo que respecta a la cadena de suministro, se estableció un WMS (sistema de gestión de almacenes) para mejorar la productividad y confiabilidad; y esto funcionó relativamente bien. Otras divisiones hicieron movimientos similares al establecer sus propias aplicaciones específicas del dominio que eran más adecuadas que el ERP original. Sin embargo, los negocios están cambiando más rápido 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 supuesta: Cada vez que surge un nuevo desafío, los sistemas de TI se ajustan a un nivel mínimo para ofrecer los resultados esperados. Para fines de la cadena de suministro, se ha establecido una integración ad hoc con el CRM para recopilar información del equipo de ventas, y otra integración ad hoc se ha establecido con el cubo de BI porque es la única forma de tener cifras consistentes con las utilizadas por las finanzas. Los servicios logísticos y los proveedores han requerido varias integraciones propias. Como resultado, el equipo de la cadena de suministro ha aprendido que cuanto mayor sea el cambio de TI, es más probable que la iniciativa se salga del presupuesto y no cumpla con los plazos. Por lo tanto, ahora se favorecen estrechos cambios incrementales sobre cualquier evolución sustancial.
Contexto resultante: El mapa del metro de Tokio parece simple en comparación con la representación de las diferentes interacciones de TI dentro del negocio. Hay cientos de dependencias sutiles entre todos los sistemas de la empresa. La imagen general del panorama de TI es muy confusa en el mejor de los casos. Para la cadena de suministro, hay una lucha constante por acceder a toda la información relevante, como nuevos productos, promociones, órdenes de compra que están “casi” finalizadas, historial de niveles de stock y faltantes de stock, etc. Cada pequeña revisión de las operaciones de la cadena de suministro, donde se busca mejorar un proceso aprovechando una pieza adicional de información, parece prolongarse indefinidamente. Las entradas de datos son inconsistentes, los sistemas siguen fallando y hay excepciones que deben ser gestionadas manualmente en todas partes.
Fuerzas seductoras: La empresa ha aprendido por las malas que cuanto mayor sea la iniciativa de TI, es más probable que la iniciativa fracase. Por lo tanto, todas las prácticas evolucionaron gradualmente hacia iniciativas más pequeñas y enfocadas, que son más fáciles de implementar manteniendo el presupuesto y los plazos bajo control. La empresa logró obtener éxitos tempranos precisamente a través de tales iniciativas a pequeña escala, con resultados positivos obtenidos con presupuestos reducidos.
Por qué esto conduce al fracaso: Cada cambio incremental aumenta el costo y la complejidad de todos los cambios posteriores. Dado que las prácticas de la empresa favorecen cambios lo más pequeños e incrementales posible, hay una falta constante de preocupación por la “imagen general”. De alguna manera, este es un caso de la “tragedia de los comunes”, donde los intereses individuales (las divisiones separadas de la empresa) no están alineados con los intereses comunes de la empresa en su conjunto. El problema se vuelve más agudo porque los efectos negativos generalmente se observan mucho tiempo después de que se realiza el cambio. Si bien cada cambio parece ser rentable, la empresa sigue acumulando “deuda técnica”, convirtiendo las ganancias a corto plazo en pérdidas a lo largo del tiempo.
Patrones positivos para abordar el problema: Fundamentalmente, implementar cambios incrementales es un enfoque razonable. Sin embargo, cada cambio debe ejecutarse de tal manera que cada cambio posterior sea más barato o más simple; las dos propiedades están altamente correlacionadas en la práctica. Esto implica que cada iniciativa debe pagar el impuesto de los comunes, donde no solo se debe cumplir el objetivo principal de la iniciativa, sino también el objetivo secundario, que consiste en facilitar los cambios futuros.
Ejemplo: Contoso es líder nacional de comercio electrónico en Alemania en un segmento específico B2C. La empresa comenzó a operar a principios de la década de 2000, desarrollando un front-end personalizado en ese momento; el front-end es la “aplicación” que permite a las personas comprar en línea. En los primeros años de la empresa, casi todas sus necesidades de TI se resolvieron a través de un front-end en constante crecimiento. Sin embargo, gestionar proveedores y órdenes de compra era simplemente demasiado para esta aplicación personalizada. En consecuencia, Contoso decidió invertir en un ERP de mercado medio y descargar todos los procesos de back-office a este sistema ERP, incluida la mayor parte de las prácticas incipientes de la cadena de suministro. Durante un tiempo, los niveles de stock se gestionaron tanto en el front-end como en el ERP, pero como esto resultó ser un desastre, Contoso finalmente logró eliminar con éxito las responsabilidades excesivas del front-end.
El ERP cumplió su función inicialmente, pero a medida que la empresa seguía creciendo, y a pesar de los mejores esfuerzos del equipo técnico a cargo de los desarrollos del ERP, el ERP no cumplía con todos los requisitos del negocio. Los informes eran insuficientes y finanzas decidió establecer su propio portal de BI (Inteligencia de Negocios), con la mayoría de las otras divisiones implementando aplicaciones similares propias. La cadena de suministro lanzó una serie de integraciones EDI para enviar sus órdenes de compra a sus proveedores, pero canalizar todo hacia el ERP se sentía cada vez más frustrante porque el ERP simplemente no podía capturar todas las sutilezas de las operaciones de la cadena de suministro de Contoso.
A medida que Contoso se convirtió en líder nacional, ahora tenía acceso a una amplia gama de opciones de abastecimiento. Los distribuidores locales alemanes que inicialmente desempeñaron un papel clave en el éxito temprano de Contoso ahora resultaban ser cada vez más caros, ya que los competidores de Contoso estaban reduciendo los precios. Los días en que los clientes estaban dispuestos a pagar “extra” por las compras en línea habían quedado atrás. Como resultado, Contoso tuvo que integrar gradualmente opciones de abastecimiento alternativas en su flujo de trabajo, utilizando típicamente los servicios de proveedores más distantes, a veces en el extranjero. Después de unos meses de lucha infructuosa tratando de encajar la lógica de múltiples abastecimientos en su ERP, el equipo de la cadena de suministro decidió que era hora de establecer su propio sistema, separado del ERP. El equipo de la cadena de suministro optó por una aplicación avanzada de abastecimiento, pero la configuración llevó mucho más tiempo de lo esperado. La nueva solución no fue la culpable, fue la integración con el ERP la que llevó a una serie de dificultades inesperadas. Por ejemplo, tres meses después del lanzamiento de la nueva solución, los equipos de la cadena de suministro se dieron cuenta de que los retrasos en el envío que se mostraban en el sitio web del cliente no eran gestionados por el ERP, sino aún por el front-end. Por lo tanto, estos “retrasos en el envío mostrados” fluían desde el front-end hacia el ERP, pero no se había hecho nada para admitir lo contrario. Como resultado, inyectar retrasos de envío revisados, actualizados dinámicamente según el proveedor seleccionado para proporcionar el producto, en el ERP no tenía ningún impacto en las cifras mostradas en el sitio web. El ERP ya se había convertido en una configuración bastante compleja y, como el equipo de TI de Contoso se sentía mucho más cómodo con el front-end que se había desarrollado internamente, el equipo de la cadena de suministro y el equipo de TI decidieron conjuntamente que la solución de abastecimiento inyectaría los retrasos de envío revisados directamente en el front-end.
El enfoque resultó ser algo desordenado y, aunque originalmente se planeó implementar la aplicación de abastecimiento en 3 meses, tomó 9 meses completos para que estuviera “en vivo”. Sin embargo, valió la inversión, ya que el abastecimiento múltiple resultó en una reducción del 15% en los precios de compra promedio, lo cual fue un impulso considerable para el negocio.
Avancemos hasta el día de hoy. El equipo de compras de Contoso, ahora separado de la división de cadena de suministro, ha negociado acuerdos favorables, pero desafortunadamente complejos, con sus proveedores más grandes. Por ejemplo, el proveedor podría devolver cantidades sustanciales de dinero al final de cada trimestre si se cumplen ciertas cuotas, generalmente involucrando 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 dichos acuerdos al seleccionar al proveedor más rentable para cada orden de compra. Sin embargo, la iniciativa está en gran medida estancada. Los términos contractuales del proveedor se encuentran en el sistema de compras, los elementos financieros solo se pueden encontrar en los sistemas de BI, mientras que otra información relacionada con el proveedor permanece en el front-end, y nunca se ha completado una actualización interna para unir las diferentes partes de este rompecabezas. La cantidad de cambio realmente necesaria es pequeña, pero parece que cada sistema dentro de la empresa está involucrado. La moral está baja y las personas están cada vez más enfocadas en su próxima asignación, ya que no se vislumbra ningún resultado positivo.