Innamorati del problema, non della soluzione
Ogni singolo SKU richiede decisioni quotidiane banali, come spostare più stock o cambiare l’etichetta del prezzo sottostante. Naturalmente, attenersi a un processo completamente manuale per queste decisioni è laborioso e le aziende hanno adottato soluzioni di automazione basate su software varie. La strategia di progettazione più comune per queste soluzioni rimane il tentativo di replicare - attraverso il software - qualcosa di essenzialmente simile alla pratica “umana” esistente.
Questo approccio non è nuovo. Si potrebbe argomentare che è stata la prospettiva enfatizzata dai sistemi esperti che sono caduti in disgrazia durante il secondo inverno dell’IA alla fine degli anni ‘80 e all’inizio degli anni ‘90. Eppure, mentre il termine di moda sistemi esperti non esiste più - non penso che ci sia ancora un (significativo) fornitore di software che si definisca ancora come fornitore di “sistemi esperti” al giorno d’oggi - non posso fare a meno di notare che la prospettiva sottostante rimane prevalente nella maggior parte dei settori.
Infatti, la maggior parte dei fornitori di software e la maggior parte delle iniziative interne rimangono bloccati nella prospettiva di replicare la pratica esistente, che a sua volta è emersa imitando il processo manuale completamente originale. Il vecchio sistema esperto potrebbe essere stato sostituito da un algoritmo di deep learning più moderno, ma il paradigma complessivo rimane (quasi) intatto.
Nella supply chain, questo modello è sorprendente perché quasi tutta la pratica rimane bloccata su approcci che sono emersi in un mondo in cui i computer semplicemente non esistevano ancora. Ad esempio, molte - la maggior parte - delle aziende ancora distinguono il team di pianificazione, le persone che stabiliscono la previsione della domanda per ogni prodotto, dal team di approvvigionamento, le persone che passano gli ordini di acquisto in base alla previsione della domanda. Questo approccio è emerso da una prospettiva taylorista in cui gli dipendenti dovevano essere il più specializzati possibile per essere massimamente performanti nel loro lavoro.
Tuttavia, quando si tratta di ottimizzazione della supply chain, il taylorismo è in contrasto con la realtà della supply chain. La realtà impone che la domanda futura non sia indipendente dalle decisioni presenti. Se viene passato un ordine di acquisto molto più grande - ottenendo un prezzo di acquisto unitario molto più basso - il prezzo di vendita può essere abbassato anche esso, potenzialmente superando il mercato e aumentando così notevolmente la domanda. In un mondo senza computer, il taylorismo era l’opzione meno peggiore perché, sebbene non fosse molto efficiente, era estremamente scalabile. Tuttavia, in un mondo con computer, la situazione richiede un approccio più integrato che tenga conto, anche in modo approssimativo, di tali retroazioni. Come dice il proverbio, meglio essere approssimativamente giusti che esattamente sbagliati.
Quando si indagano i clienti o i potenziali clienti su questa questione, la situazione è spesso poco chiara. Le soluzioni - originariamente progettate per replicare un processo puramente manuale - sono state in uso per così tanto tempo che le persone hanno perso di vista gli aspetti più fondamentali del problema che stanno cercando di risolvere. Troppo spesso, le persone sono diventate specialiste della soluzione in atto, piuttosto che diventare specialiste del problema affrontato dall’azienda. Pertanto, quando si cerca di migliorare la situazione, tutti i pensieri sono letteralmente “ancorati” a ciò che viene percepito come i difetti della soluzione attuale. A causa di questo pregiudizio, gli approcci che riconsiderano il problema in profondità sono percepiti come “rischiosi” sia dalla direzione che dai loro team. Al contrario, l’opzione di migliorare incrementalmente la soluzione esistente viene considerata “sicura”; o almeno molto più “sicura”.
Guardando indietro, la storia del software aziendale è purtroppo piena di storie di fornitori che impongono il loro “nuovo modo” di fare le cose, che si sono rivelate molto più tediose e rigide dei processi precedenti; producendo guadagni di produttività nulli o addirittura negativi. Anedotticamente, osservo che la maggior parte delle aziende che gestiscono grandi supply chain non ha ridotto in modo sostanziale il proprio personale impiegatizio - a supporto delle loro supply chain - negli ultimi due decenni, mentre i lavoratori manuali sono stati aggressivamente automatizzati attraverso impianti migliori o magazzini migliori. Questi eventi sfortunati hanno iniettato una sana dose di scetticismo nell’ecosistema contro quelle esaurienti “riorganizzazioni” per diventare conformi a una nuova soluzione software.
Tuttavia, noto anche che i dirigenti della supply chain di solito sottovalutano ampiamente i rischi associati a qualsiasi software “intelligente” - cioè qualsiasi software la cui correttezza non può essere completamente e concisamente specificata. Infatti, la maggior parte del software aziendale non è altro che applicazioni CRUD, ovvero diligenti contabili di elenchi banali come: fatture, fornitori, prodotti, pagamenti, ecc.
Raggiungere il successo aziendale con un software “stupido” è già abbastanza difficile - molte aziende di e-commerce hanno già difficoltà a mantenere un buon uptime per il loro frontend web - ma quando sono coinvolti componenti di software delicati come l’apprendimento automatico, raggiungere il successo diventa molto più difficile. Pochi aziende comunicano apertamente su questa questione, ma quando è coinvolto l’apprendimento automatico, i fallimenti dominano il campo. Tuttavia, la situazione non è così cupa come sembrerebbe, perché gli svantaggi sono limitati, mentre i vantaggi no.
Pertanto, nel lungo periodo, le aziende che provano e falliscono di più sono anche quelle che hanno più successo.
Tuttavia, i rischi del software sono molto reali e non ha senso aumentare ulteriormente questi rischi. Tuttavia, attenersi al paradigma di replicare una pratica manuale ormai defunta comporta inevitabilmente una serie di complicazioni accidentali. Ad esempio, poiché il team di pianificazione e il team di approvvigionamento sono distinti, emerge un’intera classe di problemi allo scopo di mantenere quei team sincronizzati. Come regola generale nello sviluppo del software, l’aumento dei requisiti del 25% aumenta i costi del 200%. La risoluzione di queste complicazioni aumenta drasticamente i costi e quindi, nella pratica, il rischio, poiché le aziende tendono a interrompere - una reazione sana - iniziative che fanno esplodere i loro budget o le loro scadenze.
Pertanto, quando ci si trova di fronte alla domanda cinquantennale di adattare il software all’organizzazione o di adattare l’organizzazione al software, è saggio iniziare intellettualmente da un foglio bianco e capire innanzitutto quali sono i problemi di alto livello che devono essere risolti. La performance viene misurata in percentuali? O in dollari? Stiamo considerando correttamente le implicazioni a lungo termine? Come addestrare i clienti a comprare solo durante i saldi. L’approccio sfrutta gli input umani o li consuma semplicemente? La pratica è guidata dalle abitudini o dalla necessità imperiosa? Come ad esempio due collezioni di moda all’anno, rispetto a due raccolti all’anno.
La comprensione intima del problema da risolvere - che differenzia chiaramente il problema stesso dalla sua soluzione attuale - è la chiave per capire se la soluzione esistente vale la pena di essere preservata o se dovrebbe essere semplificata come nuove capacità software che richiedono una risoluzione più semplice e diretta del problema.
