Innamorati del problema, non della soluzione
Ogni singolo SKU richiede decisioni quotidiane banali, come rifornire lo stock o modificare il prezzo di base. Naturalmente, affidarsi a un processo manuale per tali decisioni è molto dispendioso in termini di lavoro, e le aziende hanno adottato varie soluzioni di automazione basate su software. La strategia progettuale più comune per queste soluzioni consiste nel tentare di replicare - tramite software - qualcosa di essenzialmente simile alla pratica “umana” esistente.
Questo approccio non è nuovo. Si potrebbe dire che rappresentasse la prospettiva enfatizzata dai sistemi esperti, che in gran parte caddero in disgrazia durante il secondo inverno dell’IA alla fine degli anni ‘80 e all’inizio degli anni ‘90. Eppure, sebbene il termine di moda sistemi esperti non esista più - non credo che oggi esista qualche fornitore di software (significativo) che si presenti come fornitore di “sistemi esperti” - 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 essa stessa è emersa imitando il processo originariamente completamente manuale. Il vecchio sistema esperto potrebbe essere stato sostituito da un omologo basato su un algoritmo di deep learning più moderno, ma il paradigma complessivo rimane (quasi) intatto.
Nella supply chain, questo modello è sorprendente perché quasi l’intera pratica rimane ancorata ad approcci emersi in un mondo in cui i computer semplicemente non esistevano ancora. Per esempio, molte - per lo più - aziende distinguono ancora il planning team, le persone che stabiliscono la previsione della domanda per ogni prodotto, dal supply team, le persone che emettono gli ordini di acquisto basandosi sulla previsione della domanda. Questo approccio nacque da una prospettiva taylorista in cui i dipendenti dovevano essere quanto più specializzati possibile per essere massimamente performanti nel loro lavoro.
Eppure, quando si tratta di supply chain optimization, il taylorismo è in contrasto con la realtà della supply chain. La realtà impone che la domanda futura non sia indipendente dalle decisioni prese nel presente. Se viene emesso un ordine di acquisto molto più grande - ottenendo un prezzo unitario d’acquisto molto inferiore - anche il prezzo di vendita può essere abbassato, potenzialmente superando la concorrenza e aumentando notevolmente la domanda. In un mondo senza computer, il taylorismo era l’opzione meno negativa perché, pur non essendo molto efficiente, era tremendamente scalabile. Eppure, in un mondo con computer, la situazione richiede un approccio più integrato che tenga conto, anche se in maniera grezza, di tali retroazioni. Come si suol dire, meglio essere approssimativamente giusti che esattamente sbagliati.
Nel sondare clienti o potenziali clienti su questo tema, la situazione risulta frequentemente poco chiara. Le soluzioni - originariamente progettate per replicare un processo completamente manuale - sono in uso da così tanto tempo che le persone hanno perso di vista gli aspetti più fondamentali del problema che cercano di risolvere. Troppo spesso, le persone sono diventate specialiste della soluzione esistente, piuttosto che diventare specialiste del problema affrontato dall’azienda. Così, nel tentativo di migliorare la situazione, tutti i ragionamenti risultano letteralmente ancorati a ciò che viene percepito come un difetto della soluzione attuale. A causa di questo pregiudizio, gli approcci stanno rivalutando in profondità il problema e sono quindi percepiti come rischiosi sia dalla direzione che dai rispettivi team. Al contrario, l’opzione di migliorare in modo incrementale la soluzione esistente è considerata sicura; o almeno molto più sicura.
A guardare indietro, la storia del software enterprise è purtroppo piena di storie di fornitori che hanno imposto il loro “nuovo modo” di fare le cose, che si sono rivelati molto più tediosi e rigidi rispetto ai processi di un tempo; portando a guadagni di produttività nulli o addirittura negativi. Aneddoticamente, osservo che la maggior parte delle aziende che gestiscono grandi supply chain non ha ridotto sostanzialmente il personale impiegatizio - che supporta le loro supply chain - negli ultimi due decenni, mentre i lavoratori operai sono stati aggressivamente sostituiti dall’automazione grazie a impianti migliori o a magazzini più efficienti. Questi eventi sfortunati hanno iniettato una sana dose di scetticismo nell’ecosistema contro quelle estenuanti “reorgs” fatte per conformarsi a una nuova soluzione software.
Tuttavia, noto anche che Supply Chain Scientist in genere sottovaluta ampiamente i rischi associati a qualsiasi software “smart” - ossia, a qualsiasi software la cui correttezza non possa essere completamente e concisamente specificata. Infatti, la maggior parte del software enterprise non è altro che app CRUD, ovvero scrivani diligenti di elenchi banali come: fatture, fornitori, prodotti, pagamenti, ecc.
Raggiungere il successo aziendale con software “dumb” è già abbastanza difficile - molte aziende di ecommerce faticano già a mantenere un buon uptime per il loro frontend web - ma ogni volta che intervengono pezzi di software esigenti come componenti di machine learning, ottenere successo diventa molto più arduo. Poche aziende comunicano apertamente su questo tema, ma ogni volta che il machine learning è coinvolto, i fallimenti dominano il settore. Tuttavia, la situazione non è così cupa come potrebbe sembrare, perché gli svantaggi sono limitati, mentre i vantaggi non lo sono.
Così, a lungo termine, le aziende che provano e falliscono di più sono anche quelle che ottengono i maggiori successi.
Tuttavia, i rischi del software sono molto reali, e sicuramente non ha senso aumentarli ulteriormente. Eppure, aderire al paradigma di replicare una pratica manuale ormai superata porta inevitabilmente a una serie di complicazioni accidentali. Per esempio, dato che il planning team e il supply team sono distinti, intera categorie di problemi emergono esclusivamente per mantenere in sincronia quei team. Come regola empirica nello sviluppo del software, un ingrandimento dei requisiti del 25% aumenta i costi del 200%. La risoluzione di tali complicazioni aumenta drasticamente i costi, e quindi in pratica il rischio, poiché le aziende tendono a terminare - una reazione sensata - iniziative che fanno esplodere i loro budget o le loro scadenze.
Pertanto, quando ci si trova di fronte alla questione, vecchia di mezzo secolo, di adattare il software all’organizzazione oppure l’organizzazione al software, è saggio partire intellettualmente da una pagina bianca e prima individuare quali sono i problemi ad alto livello che devono essere risolti. La performance viene misurata in percentuali? O in dollari? Stiamo considerando correttamente le implicazioni a lungo termine? Ad esempio, addestrare i clienti a comprare solo durante i saldi. L’approccio sfrutta gli input umani o li consuma semplicemente? La pratica è guidata da abitudini o da una necessità imperiosa? Come due collezioni di moda all’anno, contro due raccolti all’anno.
La comprensione profonda del problema da risolvere - che chiaramente differenzia il problema stesso dalla sua soluzione attuale - è la chiave per capire se la soluzione esistente valga la pena di essere preservata, o se debba essere semplificata a favore di capacità software più nuove che richiedono una risoluzione del problema più semplice e diretta.
