El horror no euclidiano (Antipatrón de supply chain)
El horror no euclidiano ha emergido de las profundidades de los sistemas informáticos de la empresa. Mirar demasiado tiempo al horror no euclidiano 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 implementado muchos sistemas diferentes. Ahora cuentan con un ERP, un WMS (sistema de gestión de almacenes), un CRM (gestión de relaciones con clientes), un cubo BI (inteligencia de negocios), una plataforma e-commerce, 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 informático ha aumentado drásticamente a lo largo de los años, ya que cada aplicación adicional necesita comunicarse con todas las demás aplicaciones ya implementadas por la empresa. Cada división se ve afectada, pero supply chain, que se sitúa entre ventas, compras, finanzas y producción, es la que más se ve impactada. Los cambios son lentos, y casi todas las iniciativas de supply chain no cumplen sus plazos. Nadie entiende realmente lo que ocurre dentro de los sistemas de la empresa.
Evidencia anecdótica: Mover físicamente de un almacén a otro cercano se podía hacer en dos semanas. Sin embargo, en lo que concierne al software, la migración informática necesaria para integrar el nuevo almacén va a tardar más de 6 meses.
Contexto: Hace mucho tiempo, cada división de la empresa comenzó con su propia solución de software. La integración era deficiente, y finalmente se decidió que se implementara un sistema ERP para “gobernarlos a todos”. Se implementó el sistema ERP, pero no logró mantenerse al día con el rápido ritmo de cambio en la industria del software. En lo que respecta a supply chain, se instaló un WMS (sistema de gestión de almacenes) para mejorar la productividad y la fiabilidad; y esto funcionó relativamente bien. Otras divisiones hicieron movimientos similares al implementar sus propias aplicaciones específicas de dominio que se ajustaban mejor que el ERP original. Sin embargo, el negocio está cambiando más rápido que nunca, y hoy en día, tener unas operaciones de supply chain más inteligentes implica una miríada de interacciones entre todas estas diferentes aplicaciones.
Solución supuesta: Cada vez que surge un nuevo desafío, los sistemas informáticos se ajustan a un nivel mínimo para entregar los resultados esperados. Para fines de supply chain, se ha establecido una integración ad hoc con el CRM para recopilar aportes del equipo de ventas, y se ha implementado otra integración ad hoc con el cubo BI, ya que es la única manera de disponer de cifras que sean coherentes con las utilizadas por finanzas. Los servicios logísticos y los proveedores han requerido bastantes integraciones propias. Como resultado, el equipo de supply chain ha aprendido que, cuanto mayor es el cambio en TI, es más probable que la iniciativa se salga del presupuesto y no cumpla con los plazos. Por lo tanto, se prefieren fuertemente los cambios incrementales y estrechos sobre cualquier evolución sustancial.
Contexto resultante: El mapa del metro de Tokio se ve simple en comparación con la representación de las diferentes interacciones de TI dentro del negocio. Existen cientos de dependencias sutiles entre todos los sistemas de la empresa. La visión general del panorama informático es, en el mejor de los casos, muy difusa. Para supply chain, 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 faltante de stock, etc. Cada pequeña revisión de las operaciones de supply chain, en la que se debe mejorar un proceso aprovechando un extra de información, parece alargarse interminablemente. 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 es la iniciativa de TI, más probable es que fracase. Así, todas las prácticas evolucionaron gradualmente hacia iniciativas más pequeñas y focalizadas, que son más fáciles de implementar manteniendo el presupuesto y los plazos bajo control. La empresa logró alcanzar éxitos tempranos precisamente a través de tales iniciativas a pequeña escala, obteniendo resultados positivos con presupuestos mínimos.
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 tan pequeños e incrementales como sea posible, siempre hay una falta de preocupación por la “visión global”. En cierto modo, se trata de un caso de la “tragedia de los comunes”, donde los intereses individuales (las divisiones separadas de la empresa) no se alinean con los intereses comunes de la empresa en su conjunto. El problema se acentúa porque los efectos negativos generalmente se observan únicamente mucho tiempo después de que se produce el cambio. Aunque cada cambio parece rentable, la empresa sigue acumulando “deuda técnica”, convirtiendo las ganancias a corto plazo en pérdidas con el tiempo.
Patrones positivos para abordar el problema: Fundamentalmente, implementar cambios incrementales es un enfoque razonable. Sin embargo, cada cambio debe ejecutarse de manera que cada cambio posterior se vuelva más barato o más sencillo; siendo estas dos propiedades altamente correlacionadas en la práctica. Esto implica que cada iniciativa debe pagar el peaje de los comunes, en el que 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 un líder nacional en e-commerce en Alemania en un segmento B2C específico. La empresa comenzó a operar a principios de los años 2000, desarrollando en ese momento un front-end hecho a la medida; este front-end es la “app” que permite a las personas comprar en línea. En los primeros años de la empresa, casi todas sus necesidades de TI se resolvían a través de un front-end en constante crecimiento. Sin embargo, gestionar proveedores y órdenes de compra resultaba ser demasiado para esta aplicación hecha a la medida. Consecuentemente, Contoso decidió invertir en un ERP para el mercado mediano y trasladar todos los procesos de back-office a este sistema ERP, incluyendo la mayor parte de las nacientes prácticas de supply chain. Durante un tiempo, los niveles de stock se gestionaron tanto en el front-end como en el ERP, pero al resultar ser un lío, Contoso finalmente logró separar exitosamente el front-end de sus responsabilidades excesivas.
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 lograba mantenerse al día con todos los requerimientos del negocio. Los reportes eran insuficientes, y finanzas decidió implementar su propio portal BI (Business Intelligence), mientras que la mayoría de las otras divisiones lanzaron aplicaciones similares propias. Supply chain lanzó una serie de integraciones EDI para enviar sus órdenes de compra a sus proveedores, pero encaminar todo al ERP se volvió cada vez más frustrante porque el ERP simplemente no podía captar todas las sutilezas de las operaciones de supply chain de Contoso.
A medida que Contoso se convirtió en un líder nacional, ahora tenía acceso a una amplia gama de opciones de aprovisionamiento. Los distribuidores locales alemanes que inicialmente habían jugado un papel clave en el éxito temprano de Contoso ahora resultaban ser cada vez más caros, ya que los competidores de Contoso estaban bajando los precios. Los días en que los clientes estaban dispuestos a pagar “más” por las compras en línea quedaron muy atrás. Como resultado, Contoso tuvo que integrar gradualmente opciones alternativas de aprovisionamiento en su flujo de trabajo, utilizando típicamente los servicios de proveedores más distantes, a veces del extranjero. Después de unos meses de lucha infructuosa tratando de incorporar la lógica de multi-sourcing en su ERP, el equipo de supply chain decidió que era el momento de establecer su propio sistema, separado del ERP. El equipo de supply chain optó por una aplicación avanzada de aprovisionamiento, pero la implementación tomó mucho más tiempo de lo esperado. La nueva solución no tuvo la culpa, fue la integración con el ERP lo que condujo a una serie de dificultades inesperadas. Por ejemplo, tres meses después del lanzamiento de la nueva solución, los equipos de supply chain se dieron cuenta de que los retrasos en los envíos mostrados en el sitio web del cliente no eran gestionados por el ERP, sino que aún dependían del front-end. Por lo tanto, esos “retrasos en los envíos mostrados” fluían desde el front-end hacia el ERP, pero no se había hecho nada para respaldar el flujo inverso. Como resultado, inyectar los retrasos de envío revisados –actualizados dinámicamente en función del proveedor seleccionado para suministrar el producto– en el ERP no tuvo ningún impacto en las cifras mostradas en el sitio web. El ERP ya se había convertido en un conjunto bastante complejo, 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, los equipos de supply chain y de TI decidieron conjuntamente que la solución de aprovisionamiento inyectaría los retrasos de envío revisados directamente en el front-end.
El enfoque resultó algo desordenado, y aunque originalmente se planeó desplegar la aplicación de aprovisionamiento en 3 meses, se tardó 9 meses completos en hacerla “live”. Sin embargo, valió la pena la inversión, ya que el multi-sourcing terminó por reducir los precios de compra promedio en un 15%, lo cual fue un impulso considerable para el negocio.
Avanzando hasta el día de hoy. El equipo de compras de Contoso, ahora separado de la división de supply chain, ha negociado acuerdos favorables, pero desafortunadamente complejos, con sus mayores proveedores. 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 supply chain lanzó una iniciativa para tener en cuenta dichos acuerdos al seleccionar el 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 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 de la empresa se está involucrando. La moral es baja, y las personas se están enfocando cada vez más en su siguiente asignación, ya que no se vislumbra un resultado positivo.