L'Orrore Non Euclideo (Antipattern della Supply Chain)

L’orrore non euclideo è emerso dalle profondità dei sistemi IT aziendali. Guardare troppo a lungo l’orrore non euclideo può causare una perdita permanente della sanità mentale.

Categoria: organizzazione

Problema: nel corso degli anni, l’azienda ha implementato molti sistemi diversi. Ora hanno un ERP, un WMS (sistema di gestione del magazzino), un CRM (gestione delle relazioni con i clienti), un cubo BI (business intelligence), una piattaforma di e-commerce, ecc. Tra l’implementazione di tutti questi sistemi, sono stati sviluppati anche componenti interni per svolgere compiti più specializzati. La complessità del panorama IT è aumentata notevolmente nel corso degli anni, poiché ogni nuova app deve comunicare con tutte le altre app già implementate dall’azienda. Ogni divisione è coinvolta, ma la supply chain, che si trova tra vendite, acquisti, finanza e produzione, è la più colpita. I cambiamenti sono lenti e quasi tutte le iniziative della supply chain non riescono a rispettare le scadenze. Nessuno sa più cosa sta succedendo nei sistemi aziendali.

Evidenza aneddotica: Spostarsi fisicamente da un magazzino ad un altro nelle vicinanze potrebbe richiedere due settimane. Tuttavia, per quanto riguarda il software, la migrazione IT effettiva necessaria per integrare il nuovo magazzino richiederà più di 6 mesi.

Contesto: molto tempo fa, ogni divisione aziendale aveva iniziato con la propria soluzione software. L’integrazione era scarsa e alla fine si decise di implementare un sistema ERP per “dominarli tutti”. Il sistema ERP fu implementato, ma non riuscì a tenere il passo con il rapido cambiamento dell’industria del software. Per quanto riguarda la supply chain, fu istituito un WMS (sistema di gestione del magazzino) per migliorare produttività e affidabilità; e questo funzionò relativamente bene. Altre divisioni fecero mosse simili creando le proprie app specifiche per il dominio che si adattavano meglio rispetto all’ERP originale. Tuttavia, il business sta cambiando più velocemente che mai e oggi, avere operazioni di supply chain più intelligenti implica una miriade di interazioni tra tutte queste diverse app.

Soluzione presunta: Ogni volta che sorge una nuova sfida, i sistemi IT vengono adattati a un livello minimo per ottenere i risultati attesi. Per scopi di supply chain, è stata istituita un’integrazione ad hoc con il CRM per raccogliere i dati dal team delle vendite e un’altra integrazione ad hoc è stata istituita con il cubo BI perché è l’unico modo per avere dati coerenti con quelli utilizzati dalla finanza. I servizi logistici e i fornitori hanno richiesto diverse integrazioni. Di conseguenza, il team della supply chain ha appreso che maggiore è il cambiamento IT, più probabile è che l’iniziativa superi il budget e non rispetti le scadenze. Pertanto, ora si preferiscono fortemente cambiamenti incrementali ristretti rispetto a evoluzioni sostanziali.

Contesto risultante: La mappa della metropolitana di Tokyo sembra semplice se confrontata con la rappresentazione delle diverse interazioni IT all’interno dell’azienda. Ci sono centinaia di sottili dipendenze tra tutti i sistemi all’interno dell’azienda. L’immagine generale del panorama IT è al massimo molto sfocata. Per la supply chain, c’è una lotta costante per ottenere accesso a tutte le informazioni rilevanti come nuovi prodotti, promozioni, ordini di acquisto “quasi” finalizzati, storico dei livelli di stock e stock-out, ecc. Ogni piccola revisione delle operazioni della supply chain, in cui un processo deve essere migliorato sfruttando un’informazione aggiuntiva, sembra trascinarsi all’infinito. Gli input dei dati sono inconsistenti, i sistemi continuano a fallire e ci sono eccezioni che devono essere gestite manualmente ovunque.

Forze seducenti: L’azienda ha imparato a sue spese che maggiore è l’iniziativa IT, più probabile è che l’iniziativa fallisca. Pertanto, tutte le pratiche si sono evolute gradualmente verso iniziative più piccole e mirate, che sono più facili da implementare mantenendo sotto controllo budget e tempi. L’azienda è riuscita a ottenere successi precoci proprio attraverso tali iniziative su piccola scala, con risultati positivi ottenuti con budget ridotti.

Perché ciò porta al fallimento: Ogni cambiamento incrementale aumenta il costo e la complessità di tutti i cambiamenti successivi. Poiché le pratiche aziendali favoriscono cambiamenti il più piccoli e incrementali possibile, c’è una costante mancanza di preoccupazione per la “visione d’insieme”. In un certo senso, si tratta di un caso di “tragedia dei beni comuni”, in cui gli interessi individuali (le divisioni separate dell’azienda) non sono allineati con gli interessi comuni dell’azienda nel suo complesso. Il problema diventa più acuto perché gli effetti negativi vengono tipicamente osservati solo molto tempo dopo che il cambiamento ha avuto luogo. Mentre ogni cambiamento sembra essere redditizio, l’azienda continua ad accumulare “debito tecnico”, trasformando i profitti a breve termine in perdite nel tempo.

Modelli positivi per affrontare il problema: Fondamentalmente, implementare cambiamenti incrementali è un approccio ragionevole da adottare. Tuttavia, ogni cambiamento dovrebbe essere eseguito in modo tale che ogni cambiamento successivo diventi più economico o più semplice; le due proprietà sono altamente correlate nella pratica. Ciò implica che ogni iniziativa deve pagare la tassa dei beni comuni, in cui non solo l’obiettivo principale dell’iniziativa deve essere raggiunto, ma anche l’obiettivo secondario, che consiste nel rendere le cose più facili per i cambiamenti futuri.

Esempio: Contoso è un leader nazionale dell’e-commerce in Germania in un segmento specifico B2C. L’azienda ha iniziato a operare nei primi anni 2000, sviluppando un front-end personalizzato all’epoca; il front-end è l’“app” che consente alle persone di acquistare online. Nei primi anni dell’azienda, quasi tutti i suoi bisogni informatici venivano risolti attraverso un front-end in continua crescita. Tuttavia, gestire fornitori e ordini di acquisto era semplicemente troppo per questa app personalizzata. Di conseguenza, Contoso ha deciso di investire in un ERP di fascia media e di scaricare tutti i processi di back-office su questo sistema ERP, compresa la maggior parte delle pratiche emergenti della supply chain. Per un po’, i livelli di stock venivano gestiti sia all’interno del front-end che all’interno dell’ERP, ma poiché ciò si è rivelato confusionario, Contoso è riuscita alla fine a liberare il front-end dalle sue responsabilità eccessive.

L’ERP ha svolto la sua funzione inizialmente, ma man mano che l’azienda cresceva e nonostante i migliori sforzi del team tecnico responsabile degli sviluppi dell’ERP, l’ERP non riusciva a tenere il passo con tutti i requisiti del business. I report erano insufficienti e il reparto finanziario ha deciso di creare il proprio portale BI (Business Intelligence), con la maggior parte delle altre divisioni che hanno lanciato app simili. La supply chain ha avviato una serie di integrazioni EDI per inviare i propri ordini di acquisto ai fornitori, ma l’inserimento di tutto nell’ERP stava diventando sempre più frustrante perché l’ERP non riusciva semplicemente a catturare tutte le sottigliezze delle operazioni di supply chain di Contoso.

Man mano che Contoso è diventata un leader nazionale, ha ora accesso a una vasta gamma di opzioni di approvvigionamento. I distributori locali tedeschi che inizialmente avevano svolto un ruolo chiave nel successo iniziale di Contoso si stavano rivelando sempre più costosi, poiché i concorrenti di Contoso stavano abbassando i prezzi. I giorni in cui i clienti erano disposti a pagare “extra” per gli acquisti online erano ormai passati. Di conseguenza, Contoso ha dovuto gradualmente integrare opzioni di approvvigionamento alternative nel proprio flusso di lavoro, utilizzando tipicamente i servizi di fornitori più lontani, talvolta d’oltremare. Dopo alcuni mesi di lotta infruttuosa nel tentativo di inserire la logica di multi-approvvigionamento nel loro ERP, il team della supply chain ha deciso che era il momento di creare il proprio sistema, separato dall’ERP. Il team della supply chain ha scelto di optare per un’app di approvvigionamento avanzata, ma l’installazione ha richiesto molto più tempo del previsto. La nuova soluzione non era in difetto, era l’integrazione con l’ERP che ha portato a una serie di difficoltà impreviste. Ad esempio, tre mesi dopo il lancio della nuova soluzione, il team della supply chain ha scoperto che i ritardi di spedizione visualizzati sul sito web del cliente non erano gestiti dall’ERP ma ancora dal front-end. Pertanto, questi “ritardi di spedizione visualizzati” fluivano dal front-end verso l’ERP, ma non era stato fatto nulla per supportare il contrario. Di conseguenza, l’inserimento di ritardi di spedizione rivisti - aggiornati dinamicamente in base al fornitore selezionato per fornire il prodotto - nell’ERP non aveva alcun impatto sulle cifre visualizzate sul sito web. L’ERP era già diventato un set-up piuttosto complesso e poiché il team IT di Contoso si sentiva molto più a suo agio con il front-end sviluppato internamente, il team della supply chain e il team IT hanno deciso congiuntamente che la soluzione di approvvigionamento avrebbe inserito i ritardi di spedizione rivisti direttamente nel front-end.

L’approccio si è rivelato un po’ confusionario e, sebbene inizialmente fosse previsto di implementare l’app di approvvigionamento entro 3 mesi, ci sono voluti ben 9 mesi per renderla “operativa”. Tuttavia, è stato un investimento valido, poiché il multi-approvvigionamento ha comportato una riduzione dei prezzi medi di acquisto del 15%, il che è stato un notevole impulso per il business.

Proiettiamoci al giorno d’oggi. Il team di acquisti di Contoso, ora separato dalla divisione della supply chain, ha negoziato accordi favorevoli, ma purtroppo complessi, con i suoi fornitori più grandi. Ad esempio, il fornitore potrebbe restituire ingenti somme di denaro alla fine di ogni trimestre se vengono raggiunte determinate quote, di solito coinvolgendo una combinazione di volumi di vendita in euro e quantità di unità acquistate. 12 mesi fa, il team della supply chain ha avviato un’iniziativa per tenere conto di tali accordi nella selezione del fornitore più redditizio per ciascun ordine di acquisto. Tuttavia, l’iniziativa è in gran parte bloccata. I termini contrattuali del fornitore si trovano nel sistema di acquisto, gli elementi finanziari possono essere trovati solo nei sistemi BI, mentre altre informazioni relative al fornitore rimangono nel front-end e nessun aggiornamento interno è mai stato completato per mettere insieme le diverse parti di questo puzzle. La quantità di cambiamento effettivamente necessaria è minima, ma sembra che ogni singolo sistema all’interno dell’azienda sia coinvolto. Il morale è basso e le persone sono sempre più concentrate sul loro prossimo incarico, poiché non si intravede alcun esito positivo.