La manutenzione dell'ottimizzazione

Joannes Vermorel

Le tariffe che Lokad addebita ai suoi clienti aziendali sono semplici¹: una tariffa mensile fissa per una combinazione di software+esperti². Con sorpresa per alcuni, le nostre tariffe mensili tendono a rimanere fisse nel tempo, anziché diminuire bruscamente al termine della fase di onboarding. La maggior parte, tuttavia, non si stupisce, poiché assistere a un’altra preposterata dimostrazione di avidità da parte di un fornitore è solo un lunedì in più nel mondo del enterprise software. Tuttavia, questo non è un esempio da manuale di avarizia sfrenata. Piuttosto, questa tariffa è ciò che serve per ottenere una supply chain performance duratura.

Il percorso più redditizio per i fornitori di software aziendale è, ed è sempre stato, prendere i soldi e scappare. Le tariffe di licenza anticipate sono paragonabili a stampare denaro. Rispetto alla licenza, l’integrazione è più ardua. I rischi sono maggiori e i margini più sottili. Di conseguenza, i grandi fornitori di solito esternalizzano completamente questa parte, affidandosi a una rete di integratori che ne sopportano le conseguenze. Tuttavia, la parte meno redditizia, dal punto di vista del fornitore, è - di gran lunga - la manutenzione. In termini aneddotici, è per questo motivo che i fornitori, nonostante addebitino tariffe di manutenzione sostanziose, impongono comunque aggiornamenti per i loro clienti. Le tariffe di manutenzione, pur essendo rilevanti, non si avvicinano a ciò che servirebbe al fornitore per supportare il proprio legacy.

Ottimizzazione della supply chain è un caso particolare, tuttavia, poiché i fornitori (non Lokad) hanno “riuscito” a eliminare la manutenzione. Questo “successo”, però, non è certamente quello che i loro clienti avevano immaginato.

Dal 1980, i fornitori (come Lokad, ma decenni prima) hanno fornito software per automatizzare le decisioni della supply chain³. Da allora, quasi ogni grande azienda ha acquisito non una, ma spesso diverse di queste soluzioni. Anche gli ERP, che significano Enterprise Resource Planning, hanno ottenuto il loro nome negli anni ‘90 grazie a questa ambizione di automatizzare la parte di “planning”. Altrimenti, gli ERP sarebbero stati chiamati ERM, indicanti l’Enterprise Resource Management.

Tuttavia, l’automazione delle supply chain decisions non si è concretizzata. I sistemi sono stati implementati, ma stanno semplicemente raccogliendo polvere o eludendo la loro missione originale⁴. Di conseguenza, la stragrande maggioranza delle supply chain è ancora gestita tramite spreadsheets, dimostrando che, anche se quelle soluzioni di ottimizzazione erano inizialmente considerate un successo, qualcosa è andato storto nella manutenzione.

Quei fallimenti risultano redditizi per quanto riguarda i fornitori di software. Il fornitore ottiene le tariffe di licenza, possibilmente sotto forma di un impegno pluriennale (nel caso del SaaS). Poiché le soluzioni non funzionano – almeno non la parte di ottimizzazione – è richiesta poca o nessuna manutenzione. I clienti non sono preoccupati dalle capacità del software che non utilizzano comunque e, di conseguenza, non fanno molta pressione sul fornitore. Della soluzione originale, ne resta solo un frammento in uso - solitamente, un sottile gateway per l’inserimento dati destinato a gestire regole basilari di automazione integrate nei sistemi aziendali (ad es., impostazioni min/max per gli SKU).

Dall’altro lato dello spettro, Lokad riesce a fornire decisioni automatizzate per la supply chain di livello produttivo. Tuttavia, è necessario un impegno continuo da parte di una task force dedicata al cliente - i supply chain scientists nel gergo di Lokad - per farlo accadere. Il supply chain scientist è responsabile di ideare, e successivamente mantenere, la ricetta numerica che genera le decisioni di interesse per la supply chain.

La ricetta numerica risultante può essere lasciata incustodita. Questo è, in sostanza, ciò che significa l’automazione a livello di produzione nel contesto dell’ottimizzazione della supply chain. Così, il supply chain scientist può essere rimosso dal quadro in qualsiasi momento senza arrecare danno all’azienda.

Detto questo, la supply chain è una bestia in continua evoluzione, che porta naturalmente con sé effetti a catena. Sebbene i nostri algoritmi possano gestire flussi che variano in entità, non disponiamo ancora di algoritmi in grado di affrontare tutti gli altri cambiamenti sottili necessari per mantenere la ricetta numerica a livello produttivo.

Di conseguenza, i supply chain scientists si trovano ad affrontare una serie di compiti che devono essere risolti una volta che Lokad è in produzione:

• Dati più recenti diventano disponibili⁵, e la ricetta numerica deve essere aggiornata per sfruttare questi nuovi dati. Al contrario, alcune fonti di dati vengono eliminate, e le dipendenze numeriche devono essere interrotte di conseguenza. Nelle aziende di grandi dimensioni, il panorama applicativo è in continua evoluzione, non solo durante l’aggiornamento dell’ERP.

• La strategia dell’azienda cambia. La ricetta numerica è il riflesso dell’intento strategico del cliente, e questo riflesso va ben oltre la semplice scelta di valori per una manciata di parametri. Non è comune che il supply chain scientist riscriva intere sezioni della ricetta per adattarsi alle variazioni della strategia, ma ciò accade occasionalmente.

• La fiducia deve essere mantenuta. La leadership della supply chain ha bisogno che il supply chain scientist fornisca prove continue che la ricetta numerica funzioni correttamente. Al scientist ci si aspetta non solo di produrre nuove strumentazioni per rappresentare indicatori di performance, sia anche di rispondere a qualsiasi domanda la leadership possa avanzare.

• La trasparenza deve essere mantenuta. Il scientist è responsabile di rendere trasparente la ricetta numerica (procedendo con il “white-boxing”). Ciò implica formare i team affinché acquisiscano un livello adeguato di comprensione, permettendo loro di sfruttare al meglio l’automazione offerta dalla ricetta numerica. Con la rotazione dei team, i nuovi ingressi devono essere (ri)formati.

Se falliamo in uno qualsiasi di questi compiti, gli operatori della supply chain non avranno altra scelta che ritornare ai loro spreadsheets.

Pertanto, sebbene la ricetta numerica possa essere lasciata incustodita per settimane⁶, la sua rilevanza inesorabilmente si deteriora nel tempo. Di conseguenza, sono necessarie risorse ingegneristiche continue per mantenere la ricetta numerica rilevante. Nonostante i recenti progressi nell’intelligenza artificiale, progettare un software in grado di auto-mantenersi rimane ben al di là degli attuali limiti della tecnologia. Può sembrare controverso, ma il compito appare arduo quanto la sfida di raggiungere un’intelligenza artificiale generale.

Anche se i contributi continui del supply chain scientist sono necessari, si potrebbe erroneamente pensare che tali sforzi diminuiranno una volta che la ricetta numerica sarà in produzione. La nostra esperienza ha dimostrato il contrario. La complessità della ricetta numerica si espande inesorabilmente per adattarsi a qualsiasi livello di risorse ingegneristiche disponibili⁷.

Negli ultimi dieci anni, abbiamo ripetutamente osservato un punto di svolta per quanto riguarda l’investimento in risorse. Se le risorse inizialmente investite nella configurazione della ricetta⁸ superano quelle che l’azienda prevede di investire annualmente nella sua manutenzione, la ricetta non riceve il livello adeguato di cura necessario per preservarne lo status produttivo. Il sintomo più frequente di questa negligenza è un arretrato esteso in tutti gli aspetti importanti, ma non immediatamente critici: documentazione, revisioni del codice, pulizia del codice, strumentazione, ecc.

Nessuna tecnologia o processo garantisce il successo aziendale⁹, ma una manutenzione inadeguata è una ricetta collaudata per riportare un’azienda al punto di partenza - prima di sommergerla in un mare di spreadsheets. Non permettere che la tua azienda diventi un altro dato nel nostro crescente registro di fallimenti della supply chain perfettamente evitabili.