Orrore non euclideo (antipattern della catena logistica)

di Joannes Vermorel, Giugno 2015

L'orrore non euclideo emerge dalle profondità dei sistemi informatici aziendali. Più lo si analizza, e più si mette a rischio la propria salute mentale.

Categoria: organizzazione

-Vi presento Edgar, il nostro architetto di processo. È riuscito nell'eroica impresa di decifrare il nostro manuale.

Problema: nel corso degli anni, l'azienda ha fatto ricorso a molti sistemi diversi. Al momento, sono in uso un ERP, un WMS (warehouse management system), un CRM (customer relationship management), un BI (business intelligence), una piattaforma e-commerce e diversi altri. Tra un'implementazione e l'altra, sono stati sviluppati anche dei componenti interni per operazioni più mirate. Il paesaggio informatico è dunque diventato sempre più complesso col passare del tempo, perché ogni applicazione deve comunicare con le altre già implementate. Ogni reparto è coinvolto, ma il reparto logistico, che si trova a intersecare vendite, acquisti, finanza e produzione, è quello più direttamente interessato. I cambiamenti procedono a rilento e quasi ogni iniziativa legata alla catena logistica supera i termini fissati. Nessuno, in realtà, capisce più cosa sta succedendo nei sistemi aziendali.

Prova aneddotica: è possibile spostare le scorte fisicamente da un magazzino a un altro nelle vicinanze in due settimane. A livello di software, però, il procedimento di migrazione informatica per integrare il nuovo magazzino può richiedere più di sei mesi.

Contesto: molto tempo fa, ogni reparto dell'azienda aveva il proprio software dedicato. L'integrazione lasciava a desiderare; così, si decise di adottare un sistema ERP con cui gestirli tutti. Il sistema ERP, una volta implementato, non è riuscito a tenere il passo con i rapidi cambiamenti dell'industria del software. Per la logistica è stato quindi introdotto un WMS, al fine di aumentare produttività e affidabilità, che ha anche dato buoni risultati. Allo stesso modo, anche gli altri reparti hanno adottato delle applicazioni specifiche, che avrebbero potuto adattarsi meglio del più generico ERP. Tuttavia, considerando i ritmi a cui evolvono oggi le attività commerciali, per un funzionamento più intelligente della logistica servono migliaia di interazioni tra le varie applicazioni.

Presunta soluzione: ogni volta che una nuova sfida appare all'orizzonte, i sistemi informatici vengono regolati, anche in misura minima, per poter offrire i risultati sperati. In termini di catena logistica, è stata configurata un'integrazione ad hoc con il software CRM per raccogliere gli input del reparto vendite; una seconda integrazione è stata poi predisposta con il cubo BI, poiché questo è l'unico modo per ottenere dati coerenti con quelli utilizzati dal reparto amministrativo. I servizi logistici e i fornitori, infine, hanno avuto bisogno di un'altra serie di integrazioni specifiche. Di conseguenza, il reparto logistico ha capito che, maggiore è il cambiamento a livello informatico, più sono alte le probabilità che l'iniziativa sfugga di mano, gonfiando i costi e oltrepassando le scadenze fissate. A questo punto, quindi, l'azienda preferisce piccole modifiche graduali alle trasformazioni di più ampio respiro.

Contesto risultante: se le varie interazioni tra le applicazioni informatiche dell'azienda venissero rappresentate graficamente, apparirebbero probabilmente più complesse della metropolitana di Tokyo. Tra tutti i sistemi in uso esistono infatti centinaia e centinaia di legami. Per usare un eufemismo, la panoramica generale del paesaggio informatico è piuttosto confusa. Il reparto logistico deve ormai lottare continuamente per accedere a tutte le informazioni di cui ha bisogno (nuovi prodotti, promozioni, ordini di acquisto "quasi" finalizzati, storico di livelli di scorte e rotture di stock, ecc.). Anche la più insignificante revisione delle operazioni logistiche, in cui un processo va migliorato attraverso una nuova informazione appena acquisita, sembra richiedere un tempo infinito. Gli input dei dati sono contraddittori, i sistemi non danno i risultati attesi e spuntano ovunque delle eccezioni da gestire manualmente.

Forze seduttive: l'azienda ha imparato a proprie spese che i progetti informatici, più sono grandi, e più tendono a fallire. Per questo ha deciso di mettere in pratica solo iniziative più circoscritte, che risultano più facili da sviluppare, senza che il budget e le scadenze siano fuori controllo. L'azienda riesce quindi a ottenere alcuni primi successi proprio attraverso queste iniziative, con investimenti ridotti.

Perché questa è la strada verso il fallimento: ogni modifica graduale aumenta il costo e la complessità della modifica successiva. Poiché l'azienda favorisce cambiamenti piccoli e incrementali il più possibile, il quadro generale sembra passare sempre in secondo piano. In un certo senso, si tratta di una "tragedia dei beni comuni", dove gli interessi individuali (cioè dei singoli reparti dell'azienda) non sono allineati con gli interessi comuni dell'azienda. Il problema tende ad acutizzarsi poiché gli effetti negativi sono osservabili solo a distanza di molto tempo dai cambiamenti. Se ogni cambiamento in sé appare redditizio, l'azienda continua però ad accumulare "debito tecnico", trasformando i profitti a breve termine in perdite a lungo termine.

Approcci positivi per affrontare il problema: implementare cambiamenti incrementali è, in fondo, un approccio sensato. Tuttavia, ogni cambiamento deve essere eseguito in modo che quello successivo sia più semplice e meno costoso (dato che le due proprietà sono strettamente connesse nella pratica). Questo significa che ogni iniziativa è tenuta a pagare la tassa dei beni comuni: occorre dunque raggiungere non solo l'obiettivo primario dell'iniziativa, ma anche quello secondario, che consiste nel semplificare la situazione in vista di eventuali cambiamenti futuri.

-Edgar, come si fa per ottenere i dati sugli ordini di acquisto? - Gli dèi dell'ERP chiedono un sacrificio!!

Esempio: Contoso è un'azienda leader dell'e-commerce in Germania per uno specifico segmento B2C. L'azienda è nata intorno al 2000, sviluppando un sistema front-end (ossia un'applicazione che permette ai clienti di acquistare online) personalizzato. All'inizio, quasi tutte le esigenze informatiche venivano soddisfatte allargando il sistema front-end. Gestire fornitori e ordini di acquisto è però troppo complicato per l'applicazione. Costoso decide allora di investire in un ERP di medio livello per eseguire tutti i procedimenti amministrativi, incluse le pratiche logistiche, ancora agli albori. Per qualche tempo, i livelli di scorte vengono gestiti sia attraverso il sistema front-end, sia attraverso l'ERP: poiché questa soluzione è troppo confusionaria, Contoso prende finalmente la decisione di non utilizzare più l'applicazione front-end per scopi che esulano dalle sue possibilità.

L'ERP serve al suo scopo, almeno inizialmente, ma l'azienda continua a crescere e, nonostante tutti gli sforzi dei tecnici, il sistema non riesce a stare dietro a tutte le esigenze dell'attività. Visto che i report sono troppo pochi, il reparto finanziario decide di adottare un proprio portale di business intelligence (BI), mentre gli altri reparti sviluppano altre applicazioni simili. Il reparto logistico avvia una serie di integrazioni EDI per inviare gli ordini di acquisto ai fornitori, ma inserire tutti i dati nell'ERP è sempre più frustrante, perché il sistema non riesce a catturare tutte le sottigliezze della catena logistica di Contoso.

Diventata leader a livello nazionale, Contoso ha ora accesso a numerose fonti di sourcing alternative: i distributori locali tedeschi, che avevano avuto un ruolo fondamentale quando l'azienda iniziava a muovere i suoi primi passi, si rivelano ora sempre più costosi, considerando che i competitor fanno a gara per abbassare i prezzi; inoltre, i giorni in cui i clienti erano disposti a pagare un extra per fare acquisti online sono ormai finiti da un pezzo. Di conseguenza, Contoso ha dovuto integrare gradualmente opzioni alternative di sourcing, usufruendo dei servizi di altri fornitori, a volte con sede in altri continenti. Dopo mesi di tentativi fallimentari nel cercare di introdurre una logica di multisourcing nell'ERP, il reparto logistico decide di mettere a punto un proprio sistema, indipendente dall'ERP: la scelta ricade su un'applicazione avanzata di sourcing, la cui configurazione richiede però più tempo del previsto. Il problema non è certo la nuova soluzione, ma l'integrazione con l'ERP, che ha portato a difficoltà inattese: tre mesi dopo il lancio della nuova soluzione, il reparto logistico si accorge che i tempi di spedizione apparsi sul sito web cliente non erano gestiti attraverso l'ERP, ma ancora attraverso la vecchia applicazione front-end. I tempi di spedizione visualizzati venivano quindi trasmessi dal front-end all'ERP, ma niente era stato fatto per assicurare che avvenisse anche il contrario: se dunque i tempi di spedizione venivano rivisti (e aggiornati in modo dinamico sulla base del fornitore selezionato per il prodotto) e modificati nell'ERP, i dati mostrati sul sito web rimanevano comunque invariati. Visto che l'ERP è ormai diventato piuttosto complesso, e che il reparto informatico si sente molto più a suo agio con la soluzione front-end interna, i reparti logistico e informatico decidono insieme di utilizzare la soluzione di sourcing per inserire i tempi di consegna rivisti direttamente nell'applicazione front-end.

L'approccio si rivela piuttosto complicato: se in origine si prevedeva di iniziare a usare l'applicazione di sourcing entro 3 mesi, in realtà ora ce ne vogliono 9. Certo, l'investimento è valso la pena, perché grazie al multisourcing i prezzi di acquisto medi sono diminuiti del 15%, ridando slancio al business.

Facciamo un salto in avanti nel tempo. Il reparto acquisti di Contoso, che si è staccato dal reparto logistico, è riuscito a negoziare accordi favorevoli, ma purtroppo complessi, con i maggiori fornitori. Ad esempio, il fornitore può rimborsare quantità di denaro notevoli alla fine del trimestre se vengono raggiunte determinate soglie, di solito combinando volumi di vendita in euro e quantità di unità acquistate. 12 mesi fa, il reparto logistico aveva avviato un'iniziativa per tenere conto di questi accordi durante il processo di selezione del fornitore più conveniente per ogni ordine di acquisto: l'iniziativa si è però bloccata, perché i termini contrattuali applicati dai fornitori si trovano nel sistema per gli acquisti, gli aspetti finanziari sono reperibili solo nei sistemi BI, mentre le altre informazioni relative ai fornitori sono nel front-end, e nessuno ha mai pensato a un aggiornamento interno per rimettere insieme tutti i pezzi del puzzle. Le modifiche che sarebbero necessarie, in realtà, sono piuttosto limitate: il problema è che coinvolgono tutti i sistemi in uso nell'azienda. Il morale dei dipendenti è a terra, ognuno preferisce focalizzarsi sulle sue incombenze più urgenti e non ci sono risultati positivi in vista.