L'Orrore Non Euclideo (Supply Chain Antipattern)

L’orrore non euclideo è emerso dalle profondità dei sistemi IT aziendali. Fissare l’orrore non euclideo troppo a lungo potrebbe portare a una perdita permanente della sanità mentale.

Categoria: organizzazione

Problema: Nel corso degli anni, l’azienda ha implementato molti sistemi differenti. Adesso dispone di un ERP, un WMS (sistema di gestione del magazzino), un CRM (customer relationship management), un cubo BI (business intelligence), una piattaforma 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 singola app aggiuntiva deve comunicare con tutte le altre già implementate dall’azienda. Ogni divisione ne risente, ma la supply chain, situata tra vendite, acquisti, finanza e produzione, è la più colpita. I cambiamenti sono lenti e quasi tutte le iniziative della supply chain non rispettano le scadenze. Nessuno riesce più a capire cosa stia succedendo nei sistemi aziendali.

Evidenza aneddotica: Spostarsi fisicamente da un warehouse a un altro nelle vicinanze poteva essere fatto in 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 “regolare tutti i processi”. Il sistema ERP è stato implementato, ma non è riuscito a tenere il passo con il ritmo frenetico del cambiamento nell’industria del software. Per quanto riguarda la supply chain, è stato implementato un WMS (sistema di gestione del magazzino) per migliorare la produttività e l’affidabilità; e questo ha funzionato relativamente bene. Altre divisioni hanno adottato approcci similari, implementando le proprie app specifiche per 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 operations più intelligenti comporta una miriade di interazioni tra tutte queste diverse app.

Soluzione presunta: Ogni volta che si presenta una nuova sfida, i sistemi IT vengono adeguati al minimo livello per ottenere i risultati attesi. Per la supply chain, è stata implementata un’integrazione ad hoc con il CRM per raccogliere i contributi del team di vendita, e un’altra integrazione ad hoc è stata predisposta con il cubo BI perché è l’unico modo per ottenere dati coerenti con quelli usati dalla finanza. I servizi logistici e i fornitori hanno richiesto parecchie integrazioni proprie. Di conseguenza, il team della supply chain ha imparato che più grande è il cambiamento IT, maggiori sono le probabilità che l’iniziativa esca dal budget e non rispetti le scadenze. Pertanto, ora si preferiscono fortemente cambiamenti incrementali piuttosto che 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. Esistono centinaia di sottili dipendenze tra tutti i sistemi. La visione d’insieme del panorama IT è al massimo confusa. Per la supply chain, c’è una continua lotta per accedere a tutte le informazioni rilevanti, come nuovi prodotti, promozioni, ordini d’acquisto “quasi” finalizzati, la cronologia dei livelli di stock e degli stock-out, ecc. Ogni piccola revisione delle operazioni della supply chain, dove un processo viene migliorato sfruttando un’informazione extra, sembra durare in eterno. Gli input dei dati sono incoerenti, i sistemi continuano a fallire e ci sono eccezioni da gestire manualmente ovunque.

Forze seducenti: L’azienda ha imparato a proprie spese che più grande è l’iniziativa IT, maggiori sono le probabilità che l’iniziativa fallisca. Di conseguenza, tutte le pratiche si sono gradualmente evolute verso iniziative più piccole e mirate, che sono più facili da implementare mantenendo budget e scadenze sotto controllo. L’azienda è riuscita a ottenere successi precoci proprio tramite tali iniziative su piccola scala, ottenendo risultati positivi con budget ridotti.

Perché questo 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, si trascura costantemente il “quadro generale”. In un certo senso, si tratta della “tragedia dei beni comuni”, dove gli interessi individuali (le singole divisioni aziendali) non sono allineati con quelli comuni dell’azienda. Il problema si aggrava ulteriormente poiché gli effetti negativi vengono solitamente osservati molto tempo dopo il cambiamento. Sebbene ogni modifica sembri profittevole, l’azienda continua ad accumulare “debito tecnico”, trasformando i profitti a breve termine in perdite col passare del tempo.

Modelli positivi per affrontare il problema: Fondamentalmente, implementare cambiamenti incrementali è un approccio ragionevole. Tuttavia, ogni cambiamento dovrebbe essere eseguito in modo tale che ogni modifica successiva diventi più economica o più semplice; le due proprietà sono altamente correlate in pratica. Ciò implica che ogni iniziativa debba contribuire al bene comune, non solo raggiungendo l’obiettivo primario, ma anche facilitando le successive modifiche.

Esempio: Contoso è un leader nazionale nell’e-commerce in Germania in un segmento specifico B2C. L’azienda ha iniziato ad operare nei primi anni 2000, sviluppando un front-end su misura all’epoca; il front-end era l’app che permetteva di acquistare online. Nei primi anni, quasi tutte le esigenze IT venivano risolte tramite un front-end in costante espansione. Tuttavia, gestire i fornitori e gli ordini d’acquisto risultava semplicemente troppo complesso per questa app su misura. Di conseguenza, Contoso decise di investire in un ERP per il mercato medio e di delegare tutti i processi di back-office a questo sistema ERP, inclusa la maggior parte delle nascenti pratiche della supply chain. Per un certo periodo, i livelli di stock venivano gestiti sia all’interno del front-end che nell’ERP, ma, essendo questa soluzione disordinata, Contoso alla fine riuscì a liberare il front-end dalle responsabilità eccessive.

L’ERP inizialmente adempiva alla sua funzione, ma man mano che l’azienda cresceva, e nonostante i migliori sforzi del team tecnico responsabile degli sviluppi ERP, non riusciva a stare al passo con tutte le esigenze del business. I report erano insufficienti, e il reparto finanza decise di implementare il proprio portale BI (Business Intelligence), mentre la maggior parte delle altre divisioni lanciò app simili. La supply chain avviò una serie di integrazioni EDI per inviare gli ordini d’acquisto ai fornitori, ma convogliare tutto nell’ERP divenne sempre più frustrante poiché quest’ultimo non era in grado di catturare tutte le sottigliezze delle operazioni della supply chain di Contoso.

Poiché Contoso è divenuta un leader nazionale, ora aveva accesso a una vasta gamma di opzioni di approvvigionamento. I distributori locali tedeschi, che inizialmente avevano giocato un ruolo chiave nel successo dell’azienda, si sono rivelati sempre più costosi poiché i concorrenti abbassavano i prezzi. I tempi in cui i clienti erano disposti a pagare un “extra” per gli acquisti online erano ormai finiti. Di conseguenza, Contoso ha dovuto integrare gradualmente opzioni di approvvigionamento alternative nel suo flusso di lavoro, tipicamente avvalendosi di fornitori più distanti, talvolta esteri. Dopo alcuni mesi di tentativi falliti di integrare la logica del multi-sourcing nel loro ERP, il team della supply chain decise che era il momento di creare un sistema separato dall’ERP. Il team optò per un’app avanzata di approvvigionamento, ma l’implementazione richiese molto più tempo del previsto. La nuova soluzione non era da biasimare, era l’integrazione con l’ERP a generare una serie di difficoltà inaspettate. Per esempio, tre mesi dopo il lancio della nuova soluzione, i team della supply chain si resero conto che i ritardi di spedizione visualizzati sul sito web del cliente non erano gestiti dall’ERP ma ancora dal front-end. Di conseguenza, questi “ritardi di spedizione visualizzati” fluivano dal front-end verso l’ERP, senza che venisse predisposta una gestione inversa. L’ERP era già diventato un sistema piuttosto complesso, e poiché il team IT di Contoso si sentiva molto più a suo agio con il front-end sviluppato internamente, i team della supply chain e IT decisero insieme che la soluzione di approvvigionamento avrebbe iniettato i ritardi di spedizione rivisti direttamente nel front-end.

L’approccio si è rivelato alquanto complicato, e sebbene inizialmente si prevedesse di attivare l’app di approvvigionamento in 3 mesi, sono voluti ben 9 mesi per renderla “live”. Eppure, l’investimento è valsa la pena, poiché il multi-sourcing ha portato a una riduzione dei prezzi medi d’acquisto del 15%, un vantaggio considerevole per l’azienda.

Avanzando fino ai giorni nostri. Il team acquisti di Contoso, ora separato dalla divisione della supply chain, ha negoziato accordi favorevoli, ma purtroppo complessi, con i suoi maggiori fornitori. Ad esempio, il fornitore potrebbe restituire somme considerevoli di denaro alla fine di ogni trimestre se vengono rispettate determinate quote, tipicamente basate su una combinazione di volumi di vendita in euro e quantità di unità acquistate. Dodici mesi fa, il team della supply chain ha lanciato un’iniziativa per considerare tali accordi nella selezione del fornitore più redditizio per ogni ordine d’acquisto. Tuttavia, l’iniziativa è rimasta sostanzialmente bloccata. I termini contrattuali del fornitore sono presenti nel sistema acquisti, gli elementi finanziari si trovano esclusivamente nei sistemi BI, mentre alcune altre informazioni relative ai fornitori rimangono nel front-end, e non è mai stato completato alcun aggiornamento interno per mettere insieme i diversi pezzi di questo puzzle. Il cambiamento effettivamente necessario è minimo, ma sembra che ogni singolo sistema aziendale vi partecipi. Il morale è basso e le persone sono sempre più concentrate sul loro prossimo incarico, poiché non si intravede alcun esito positivo.