Software Frankensteinisation nella Supply Chain

00:00:04 Introduzione alla Frankensteinizzazione del software.
00:00:35 Impatto della Frankensteinizzazione del software sul software B2B.
00:01:31 Come le richieste dei clienti influenzano la Frankensteinizzazione del software.
00:02:32 ‘Cicatrici’ sul software e le loro implicazioni.
00:05:33 Costi di manutenzione della Frankensteinizzazione del software.
00:08:00 Sfide e costi delle nuove funzionalità software.
00:08:57 Funzionalità senza complessità: approfondimenti B2C.
00:10:36 Problemi con l’approccio B2B alle soluzioni software.
00:13:18 Esperienza di Lokad: corretto vs veloce e debito tecnico.
00:15:14 Envision: la soluzione di Lokad alla complessità.
00:16:30 Scripting specifico del dominio: evitare limitazioni e conflitti.
00:17:43 Affrontare il bloatware del software nelle supply chain.
00:18:01 Strategie per semplificare il software complesso.
00:20:54 Gestire la ‘massa tecnologica’ nei sistemi software.
00:22:00 Sinergia IT, supply chain, marketing nei cambiamenti di sistema.
00:22:43 Problemi con la personalizzazione eccessiva del software.
00:23:48 Testare l’integrità del fornitore di software tramite la personalizzazione.
00:24:00 Ottenere influenza sulla strategia di sviluppo del prodotto.
00:26:08 Scegliere un software snello e focalizzato per evitare la personalizzazione.

Riassunto

Su Lokad TV, Joannes Vermorel introduce il concetto di Frankensteinizzazione del software, facendo riferimento al modo in cui il software B2B si evolve attraverso modifiche caotiche che non si allineano al suo design originale. Egli paragona questi cambiamenti a ‘cicatrici’, che contribuiscono alla creazione di un sistema software composito ed evoluto. Gli ERP vengono presentati come esempio, sottolineando il dilemma tra mantenere l’architettura del software e soddisfare nuove richieste. Vermorel mette in guardia contro decisioni affrettate, che spesso portano a cicatrici software e ad un aumento dei costi di manutenzione. Pur riconoscendo la complessità inevitabile nella gestione del software, Vermorel sottolinea l’importanza di imparare dai modelli B2C per controllare le interazioni delle funzionalità. La risposta di Lokad a questo problema è “Envision”, un linguaggio di programmazione specifico del dominio che separa i problemi infrastrutturali da quelli specifici del dominio.

Riassunto Esteso

Nell’ultimo episodio di Lokad TV, la conversazione ruota attorno al concetto di Frankensteinizzazione del software, un termine introdotto da Joannes Vermorel, fondatore di Lokad. Egli utilizza questo termine per rappresentare la trasformazione del software B2B nel tempo, in particolare il software a lunga durata di vita e per la supply chain, poiché si evolve attraverso continue negoziazioni e grandi accordi tra fornitori di software e i loro clienti.

Vermorel spiega che la Frankensteinizzazione del software avviene quando vengono apportate modifiche al software in risposta alle richieste dei clienti. Questi cambiamenti spesso sono incoerenti con l’architettura, la filosofia e il design originale del software. Di conseguenza, il software accumula queste modifiche, o “cicatrici”, nel tempo, trasformandolo in quello che Vermorel descrive come un “mostro di Frankenstein” - un sistema software composito e stranamente evoluto.

Egli sottolinea inoltre che questo fenomeno è particolarmente evidente nel software per la supply chain, ma è comune anche in molti altri tipi di software B2B. Tuttavia, precisa che il termine “cicatrice” non dovrebbe essere frainteso come intrinsecamente negativo. Queste modifiche possono migliorare il software aggiungendo nuove funzionalità, migliorandone così la funzionalità.

Vermorel fornisce un esempio di software di Enterprise Resource Planning (ERP), che assume che la stagionalità possa essere catturata utilizzando profili fissi di 52 settimane. Questo design funziona bene fino a quando non si presenta una domanda che non si adatta a questo framework, come la modellazione del Capodanno cinese, del Ramadan o della Pasqua, che seguono calendari diversi e cambiano date annualmente.

In tali casi, il fornitore di software si trova di fronte a un trade-off. Possono soddisfare la nuova domanda integrando una soluzione “hackish”, che non si adatta perfettamente all’architettura del software ma fornisce la funzionalità richiesta. Tuttavia, questo approccio spesso porta a ulteriori “cicatrici”, contribuendo alla Frankensteinizzazione del software.

Sottolineando il rapido ritmo delle negoziazioni con i clienti chiave nel settore del software, Vermorel avverte che l’urgenza può portare involontariamente a “cicatrici software”. Egli definisce questo come un processo in cui le funzionalità implementate in modo frettoloso aumentano la complessità e il costo di manutenzione del software nel tempo.

Spiegando le complessità dell’architettura del software, Vermorel osserva che ogni riga di codice o funzionalità richiede manutenzione. Man mano che vengono aggiunte più funzionalità, le interconnessioni diventano più complesse, portando a un “problema di complessità quadratica”. Fondamentalmente, le interazioni potenziali aumentano in modo esponenziale all’aumentare del numero di componenti, causando una serie di potenziali problemi come bug, crash e minacce alla sicurezza.

Vermorel sottolinea l’importanza di un’architettura del software meticolosa per controllare il numero di interazioni tra le funzionalità. Egli afferma che l’obiettivo dovrebbe essere quello di raddoppiare solo la quantità di manutenzione richiesta se il numero di funzionalità viene raddoppiato, invece di quadruplicare o più che spesso accade quando lo sviluppo viene affrettato.

Quando gli viene chiesto come le aziende di software possono introdurre nuove funzionalità senza aggiungere eccessiva complessità, Vermorel suggerisce di imparare dalle aziende di software B2C come Google e Netflix. Dedicate del tempo per capire i problemi specifici che stanno cercando di risolvere e progettare soluzioni che affrontino una vasta categoria di problemi simili. Egli contrasta questo approccio con il mondo B2B, dove i clienti spesso arrivano non solo con problemi, ma anche con le loro soluzioni proposte.

Riguardo a come Lokad gestisce questi problemi, Vermorel rivela la loro lotta iniziale nel bilanciare tra fare le cose correttamente e soddisfare rapidamente le richieste dei clienti. Hanno notato un aumento del debito tecnologico nei primi anni, che Vermorel riconosce come dannoso. Hanno capito che aggiungere funzionalità per accontentare singoli clienti potrebbe sembrare vantaggioso nel breve termine, ma porta a un prodotto complesso, incoerente e difficile da gestire nel lungo termine.

In reazione a questa consapevolezza, Lokad ha ideato una soluzione unica: un linguaggio di programmazione specifico per il dominio chiamato “Envision”. Lo scopo di Envision è separare i problemi infrastrutturali dai problemi specifici del dominio, consentendo a Lokad di gestire l’aggiunta e la manutenzione di nuove funzionalità in modo più efficace senza aggiungere eccessiva complessità.

Vermorel continua a elaborare su come i prodotti software, specialmente nell’industria della gestione della supply chain, spesso affrontino un problema di gonfiore a causa della personalizzazione estensiva per ogni cliente. Mentre la personalizzazione mira a fornire soluzioni su misura, spesso si traduce in un sistema complesso e difficile da gestire che richiede uno sforzo significativo per la manutenzione e l’aggiornamento. Per evitare ciò, Vermorel condivide come Lokad utilizzi uno script specifico per il dominio, Envision, per creare soluzioni altamente personalizzate, ma gestibili, per i loro clienti.

Affrontando il tema della complessità del software, Chandler chiede cosa possano fare le aziende software per evitare il bloatware. Vermorel risponde che lo scenario dipende dal fatto che un’azienda abbia accesso al proprio software. Se non lo ha, l’azienda deve fare i conti con la complessità del software acquisito. Tuttavia, se l’accesso è disponibile, il software può essere semplificato identificando e rimuovendo gli elementi inutilizzati, riducendo notevolmente la complessità.

Cambiando il focus sulle responsabilità dei responsabili IT e degli scienziati della supply chain, Vermorel osserva che mentre il personale IT di solito ha le competenze tecniche, spesso manca loro la comprensione del valore commerciale di determinate funzionalità. Ciò porta a una disconnessione tra funzionalità necessarie e non necessarie. Pertanto, i decision maker aziendali devono collaborare strettamente con l’IT per guidare la prioritizzazione e la semplificazione del sistema.

Vermorel fornisce consigli per i responsabili della supply chain che desiderano investire in nuovi software. Mette in guardia contro la richiesta di personalizzazioni eccessive, in quanto può causare ulteriori problemi. Invece, i dirigenti dovrebbero mantenere un contatto regolare con i responsabili prodotto o i CTO del fornitore per comunicare direttamente le proprie esigenze. Piuttosto che imporre specifiche funzionalità in un contratto, l’obiettivo dovrebbe essere quello di presentare problemi a coloro che sono in grado di trovare soluzioni ingegneristiche.

Infine, Vermorel consiglia alle aziende di scegliere software che eccellano in una cosa, invece di optare per soluzioni complete. Questo approccio focalizzato facilita il miglioramento e riduce la complessità causata da una moltitudine di funzionalità interconnesse. Rimanendo vicini a coloro che controllano la roadmap e scegliendo software attentamente focalizzati, le aziende possono gestire meglio la complessità e migliorare la produttività.

Trascrizione completa

Kieran Chandler: Oggi affronteremo il tema della Frankensteinizzazione del software. Quindi, Joannes, questo è un argomento piuttosto difficile da pronunciare, quindi probabilmente te lo lascerò a te. Immagino che oggi non stiamo parlando di un grande mostro verde. Di cosa stiamo parlando esattamente?

Joannes Vermorel: Stiamo parlando di un processo che guida l’evoluzione del software, in particolare del software B2B e ancora più specificamente del software per la supply chain. Si applica principalmente al software B2B a lunga durata. Questo processo, che io chiamo “Frankensteinizzazione”, fa evolvere il software nel corso degli anni con un flusso continuo di grandi accordi negoziati tra i fornitori di software e i loro clienti. La cosa interessante, da cui deriva il termine “Frankensteinizzazione”, è che ogni grande accordo negoziato tra il fornitore e uno dei suoi grandi clienti lascia probabilmente una cicatrice nel software.

È un processo graduale in cui un fornitore negozia con una grande azienda. La grande azienda ha delle richieste e, per soddisfare tali richieste, vengono apportate modifiche al software che non si adattano all’architettura complessiva, alla filosofia o al design originale. La funzionalità viene aggiunta, ma in modo un po’ approssimativo. Questa è una cicatrice. Il problema è che se si ripete questo processo per anni, ciò che si ottiene in termini di software è, in un certo senso, un mostro di Frankenstein. È una creatura fatta di molte cicatrici che sembrano piuttosto orribili e super composite. Si evolve in modi strani, ed è così che si finisce con questi mostri di software Frankenstein. Questo è qualcosa che accade nella maggior parte dei database, ma nel software per la supply chain è come se fosse su steroidi.

Kieran Chandler: Parliamo di queste cicatrici, come le chiami tu. Come sono fatte? Voglio dire, stanno migliorando il software, giusto? Stanno aggiungendo funzionalità extra. Non è una cosa così negativa, vero?

Joannes Vermorel: Sì, ovviamente è un compromesso. Si desidera migliorare il proprio software, ma un pezzo di software è un oggetto molto complicato. Non è come un edificio in cui è possibile aggiungere un piano o espandersi in modo ordinato. Il software viene fornito con molte assunzioni di progettazione inviolabili fatte molto presto che conferiscono al software una certa integrità - integrità architettonica.

Prendiamo molti ERP come esempio, che sono stati costruiti intorno all’idea di catturare la stagionalità con profili che sono esattamente 52 settimane, rappresentando un determinato anno. Quindi, hai letteralmente una tabella con 52 colonne, una colonna per settimana, e hai tutti questi profili di stagionalità che puoi applicare a qualsiasi articolo che stai producendo o vendendo. Ma cosa succede se vuoi modellare qualcosa come il Capodanno cinese? Non si adatta a questa griglia di 52 settimane perché si sposterà dall’anno successivo secondo il calendario tradizionale cinese, non il calendario gregoriano. Affronterai problemi simili con il Ramadan o anche con la Pasqua.

Hai questa assunzione molto bella che può crollare quando ti trovi di fronte a una domanda che non si adatta al tuo framework. E ciò può assumere molte forme. Il problema è che come fornitore di software, in realtà non hai il tempo di riscrivere l’intero stack di software in modo che queste nuove funzionalità si integrino nella tua architettura in modo completamente nativo. Alla fine, è un po’ approssimativo.

Kieran Chandler: Stai negoziando con un cliente importante, quindi non hai anni per chiudere l’affare. E poi, non hai anni per consegnare il futuro. Quindi, le cose devono essere fatte in una situazione di emergenza relativa ogni volta, solo a causa del fatto che in realtà è una negoziazione più grande del solito per chiudere una vendita. Le cose sono quasi sempre affrettate per design. Ma quando qualcosa diventa una cicatrice e quando qualcosa diventa una buona funzionalità? Perché tutti questi software devono evolversi, devono cambiare, devono funzionare per i loro clienti. Quindi, cosa differenzia i due? Come si fa a sapere che qualcosa che si sta sviluppando non diventerà una cicatrice?

Joannes Vermorel: La domanda è quanto costerà in termini di manutenzione? Ogni singola riga di codice che esiste nel tuo grande software aziendale è qualcosa che dovrai mantenere. Una cosa che le persone non sempre si rendono conto, anche i professionisti del software, è che il software è come una macchina intricata in cui ogni singola parte deve interagire in qualche modo con tutte le altre parti. Hai un problema di complessità quadratica.

Cosa significa? Significa che se ho dieci parti, ho fondamentalmente circa 100 interazioni potenziali, sai, 10 x 10. Se ho mille parti e tutte interagiscono, allora ho 1.000 per 1.000 interazioni. Ogni interazione potenziale è una ricetta per tutti i tipi di problemi: problemi di sicurezza, bug, crash, risultati errati o semplicemente rallentamenti massicci nel software.

Quando aggiungi più parti, aumenti il numero di interazioni potenziali tra le parti nel tuo software, e aumenta molto più rapidamente rispetto al numero di parti. E quando dico parti, puoi pensare a funzionalità, capacità, schermate, opzioni di dati o voci.

Se sei molto attento con l’architettura del tuo software, puoi preservare il numero di interazioni tra le tue funzionalità per mantenerlo sotto controllo. Se raddoppi il numero di funzionalità nel tuo software, non vuoi moltiplicare il numero di interazioni per 4, perché significa che quando raddoppi il numero di funzionalità, quadruplichi effettivamente la quantità di manutenzione che devi fare.

Ma è molto difficile. Quando sei di fretta, quando raddoppi il numero di funzionalità, moltiplichi effettivamente per 4 o anche di più la quantità di sforzo che devi investire nella manutenzione. Nel tempo, il costo della manutenzione aumenta vertiginosamente, la tua capacità di lanciare nuove cose diminuisce sempre di più. Ogni volta che introduci una nuova funzionalità, scatena un’intera serie di incompatibilità e strane interazioni non intenzionali tra diverse parti, perché non è stata completamente pensata. Il dolore aumenta nel tempo.

Kieran Chandler: Ok, quindi pensiamo alle cose dal punto di vista di quella società di software. Come possono introdurre queste nuove funzionalità? Come possono implementare queste funzionalità per mantenere i loro clienti felici, senza introdurre questo ulteriore livello di complessità? Cosa possono fare?

Joannes Vermorel: Penso che la lezione venga dal mondo del software B2C. Google non introduce nuove funzionalità per la ricerca di Google, o Netflix non introduce nuove funzionalità per Netflix solo perché sta acquisendo un nuovo cliente. Non prendono nuovi clienti e iniziano a discutere con loro e a dire: “Oh, se non abbiamo quelle funzionalità, allora non ti iscriverai con noi, quindi dobbiamo farlo ora”.

Non funzionano così. Pensano a quale è il dominio, quale è il problema specifico che stanno cercando di risolvere. Cercano di avere una prospettiva molto ampia su questo problema e poi pensano.

Kieran Chandler: Discuti un approccio che mira a generare soluzioni per un’intera categoria di problemi, anziché un singolo micro problema. Questo comporta la ristrutturazione del software per affrontare un’ampia gamma di problemi simili. E questo succede tutto il tempo. Quando interagisci con i clienti, ascolti i loro problemi, non le loro soluzioni proposte. In confronto, nel mondo B2B, i clienti tendono a presentare non solo il loro problema, ma anche una soluzione. Questa soluzione potrebbe o potrebbe non adattarsi alla tua stack software esistente o all’evoluzione di questo problema. Quindi, si tratta di non ascoltare davvero?

Joannes Vermorel: Esattamente, si tratta più di comprendere realmente il problema principale anziché fissarsi su una soluzione particolare. Grandi aziende come Google e Netflix sono ottimi esempi di questo.

Kieran Chandler: Quindi, stai dicendo che le aziende non stanno davvero ascoltando. Ma cosa diresti di quei fastidiosi pop-up che chiedono un feedback? Qualcuno li sta davvero guardando?

Joannes Vermorel: I pop-up a cui ti riferisci sono tipicamente funzionalità indesiderate. Ma bisogna dare credito a aziende come Google. Questi pop-up, in cui devi accettare i termini, non sono stati scelti da loro. Sono stati costretti ad implementarli a causa di vincoli normativi. Quindi, anche se può sembrare una funzionalità bizzarra, non è stata loro scelta. Inoltre, se guardi chi ha vinto sul web, non sono state le aziende con annunci super fastidiosi. Sono state quelle come Google che avevano annunci puliti e non invasivi. Pensavano ai loro clienti invece di svalutare il loro prodotto con qualcosa di così fastidioso. Si prendono il tempo per pensare alle loro funzionalità.

Kieran Chandler: Nelle aziende di software B2B, in particolare nella supply chain, c’è molta diversità. Ci possono essere centinaia di scenari e spesso all’ultimo minuto, le persone negoziano molte funzionalità che quasi sempre si rivelano cattive idee sei mesi dopo. Quindi, saresti d’accordo nel dire che la Frankensteinizzazione del software è una cosa negativa? E se sì, cosa hai fatto di diverso in Lokad per evitare questo problema?

Joannes Vermorel: Assolutamente, la Frankensteinizzazione del software è un problema. Durante i primi anni in Lokad, abbiamo affrontato questo stesso problema. È stata una scelta difficile. Se vuoi farlo nel modo giusto, può richiedere uno o due anni, il che è troppo lento. Se non lo fai nel modo giusto, puoi concludere in poche settimane o mesi, ma poi ti ritrovi con una grande cicatrice, un brutto hack. Finisci per accumulare debiti tecnici. Quindi, per i primi anni di Lokad, non avevamo una soluzione, ma eravamo sempre più consapevoli del problema. Anche come startup, il debito tecnologico stava aumentando, il che era una situazione preoccupante. È stato a questo punto che ho capito che la tendenza era sfavorevole. Guardando un paio di decenni avanti, potevo vedere come i concorrenti, con il loro software ingombrante per l’ottimizzazione della supply chain, stavano solo aggiungendo sempre più funzionalità senza alcuna coerenza.

Kieran Chandler: Sembra che le aziende di software stiano sempre aggiungendo nuove funzionalità e il risultato finale può essere un prodotto confuso e ingombrante. Puoi parlare del tuo approccio a questo problema in Lokad?

Joannes Vermorel: Assolutamente. Il modo in cui il software tende ad ingombrarsi è aggiungendo una cattiva funzionalità alla volta. Se continui su questa strada per 20 anni, finisci con un prodotto mostruoso. Non è che gli sviluppatori siano incompetenti o sciocchi, stanno semplicemente facendo un buon lavoro incrementalmente, cercando di conquistare un cliente alla volta. Tuttavia, questo approccio rovina il software un cliente alla volta e il risultato finale è tipicamente molto, molto cattivo.

Quindi, abbiamo deciso di adottare un approccio completamente diverso in Lokad, e questo ha portato alla nascita di Envision, il nostro linguaggio di programmazione specifico per il dominio. Con Envision, abbiamo effettivamente separato tutti i problemi. Abbiamo separato l’infrastruttura, l’infrastruttura dei dati e l’infrastruttura di machine learning. Questi sono prodotti a lunga durata che vogliamo mantenere e aggiornare, e ogni volta che decidiamo di cambiarli e aggiornarli è un impegno pluriennale.

Poi, separatamente, per ogni singolo cliente, creiamo un’implementazione completamente personalizzata scritta in script in Envision. Poiché Envision è specificamente progettato per l’ottimizzazione della supply chain, potremmo scrivere qualcosa completamente personalizzato per ogni singolo cliente, con alta produttività, rendendolo completamente su misura.

Quindi, partiamo da un foglio bianco, lo personalizziamo completamente e poi non dobbiamo affrontare una situazione in cui il cliente ci chiede qualcosa che non supportiamo. Grazie alle capacità programmatiche di Envision, se dobbiamo fare qualcosa di speciale per un cliente, il peggiore dei casi è che lo script che scriviamo non sarà compatto come al solito. Tuttavia, possiamo comunque beneficiare di un’infrastruttura progettata per rendere facile risolvere determinati tipi di problemi.

Se introduci capacità programmatiche avanzate specifiche per il dominio nella tua piattaforma, all’improvviso non devi affrettare una negoziazione che danneggerebbe il tuo prodotto. Puoi personalizzare l’ambiente programmabile che è su misura per ogni singolo cliente e poi continuare a rilasciare aggiornamenti per la tua piattaforma secondo il tuo calendario, che molto probabilmente non corrisponderà al calendario dei tuoi clienti.

Kieran Chandler: Hai identificato questo problema molto presto. Quale consiglio daresti ad altre aziende di software che si trovano di fronte a questo tipo di software ingombrante? Possono fare qualcosa al riguardo? Dovrebbero iniziare a rimuovere alcune di queste funzionalità per semplificare le cose?

Joannes Vermorel: La situazione dipende da diversi fattori. Se sei un’azienda di grandi dimensioni che possiede il software, come un WMS, ERP, MRP, ecc., potresti non avere nemmeno accesso al software stesso, potrebbe essere solo un prodotto di un fornitore. Se non hai accesso al prodotto, allora sei bloccato con la complessità del software che hai acquisito.

Se hai accesso al software e vuoi semplificarlo, allora sì, dovresti iniziare guardando tutte le cose che non stai usando e scartandole aggressivamente. Molte persone sono solitamente preoccupate di rimuovere parti di un software esistente perché temono di perdere determinate funzionalità. È vero che se rimuovi funzionalità, perdi quelle funzionalità. Tuttavia, se rimuovi qualcosa che viene utilizzato molto raramente, puoi anche eliminare intere classi di problemi causati dalla presenza stessa di questa piccola funzionalità.

Spesso vediamo implementazioni di ERP presso Lokad con letteralmente migliaia di tabelle. Puoi avere un ERP con, diciamo, cinquemila tabelle. Ogni tabella può avere da 10 a 200 campi, il che comporta una complessità enorme. Anche solo fare il backup dell’ERP può essere incredibilmente complicato.

Kieran Chandler: Perché hai così tante tabelle, hai bisogno di una tabella per memorizzare l’elenco delle tabelle e così via. Questo è il tipo di situazione in cui se puoi identificare tonnellate di tabelle che non vengono più utilizzate, o schermate che non vengono più utilizzate, semplicemente rimuovendole, semplifichi tutto.

Joannes Vermorel: Esattamente, ad esempio, se devi eseguire l’aggiornamento da una versione del tuo database a un’altra, uno dei problemi che puoi incontrare è che devi aggiornare parti di logica che non vengono più utilizzate da nessuno. Ogni singola riga di codice che esiste, sia che si tratti di Java, C Sharp, SQL o altro, è qualcosa che devi mantenere per tutto il tempo in cui la riga di codice esiste. Se rimuovi quella riga, significa che durante la tua prossima integrazione o migrazione, le persone non dovranno chiedersi come migrare questa cosa alla prossima versione del sistema o al prossimo sistema in generale.

E questo è qualcosa a cui i dirigenti della supply chain devono pensare. Quando acquisti un software, dovresti aderire al principio della parsimonia: se non ne hai davvero bisogno, è meglio non avere quella parte del sistema. Sarà solo un peso. È fondamentale prestare costantemente attenzione alla massa tecnologica della soluzione che stai acquisendo e gestendo.

Questa massa tecnologica non è gratuita. Se hai più schermate, hai bisogno di più persone per formarle. Se puoi rimuovere un paio di schermate, ciò significherebbe meno formazione, meno segnalazioni di bug, meno litigi con l’IT e così via. Si tratta di gestire la complessità dell’IT, ma la parte complicata è che tipicamente, l’IT non ne ha idea perché non ha accesso al valore aziendale. Non possono differenziare tra funzionalità che sono davvero necessarie e funzionalità che non sono assolutamente necessarie. Non possono tradurre tabelle, campi, schermate o funzionalità in euro o dollari. Questo è qualcosa che solo le persone della supply chain o del marketing, se stai guardando un sistema diverso, possono fare. Ecco perché l’IT ha bisogno del supporto di queste persone, dei decision maker dell’azienda, per guidare la prioritizzazione e il cambiamento nella semplificazione del sistema.

Kieran Chandler: E quindi, per concludere, hai detto che se sono un dirigente della supply chain che vuole investire in un nuovo software per la mia azienda, sembra che non dovrei chiedere troppa personalizzazione perché ciò comporta problemi. Quindi, cosa dovrei cercare?

Joannes Vermorel: Sì, chiedere personalizzazioni o funzionalità speciali è come una ricetta per generare problemi. Se il tuo fornitore di software non ha abbastanza problemi propri, stai solo creando nuovi problemi che renderanno le cose peggiori. Quindi, davvero, non dovresti farlo. Se puoi effettivamente chiedere personalizzazioni, solo come test, perché se il fornitore si impegna volentieri nella discussione con te sulla personalizzazione, significa che il fornitore non ha integrità. Ciò significa che il fornitore fa questo con ogni singolo altro cliente, il che significa che anche se il prodotto è buono oggi, tra cinque anni sarà un incubo.

In primo luogo, se chiedi personalizzazioni, è bene chiedere e dovresti aspettarti che questa richiesta venga respinta. Se non lo è, allora è un problema.

Kieran Chandler: Una cosa che le persone dovrebbero chiedere sono funzionalità speciali, giusto? Voglio dire, se c’è una cosa da chiedere, potrebbe essere l’accesso al CTO o al product manager del fornitore. Includerlo come parte del contratto, forse? Come voler avere un incontro con questa persona due ore una volta al mese. Perché?

Joannes Vermorel: Se negozi di avere un accesso diretto alle persone che stanno progettando la roadmap del fornitore, puoi semplicemente presentare i tuoi cambiamenti. Non hai bisogno di imporre loro la tua soluzione; presenti solo il tuo problema. Perché, come ingegneri, cosa fanno quando gli viene presentato un problema? Iniziano a lavorare su una soluzione. Se hai un incontro di routine in cui presenti i tuoi problemi, non hai bisogno di negoziare alcuna funzionalità specifica nel contratto. Tra un paio d’anni, inizieranno a comparire nel prodotto funzionalità che sembrano adattarsi al problema stesso che hai esposto.

Kieran Chandler: Puoi spiegare un po’ di più su questo?

Joannes Vermorel: Se fai i calcoli, considera il CTO di un’azienda di software. Quanti incontri può avere questa persona con i clienti in un mese? Diciamo che ne ha un massimo di 20. Se hai un incontro al mese, stai ottenendo essenzialmente circa il cinque percento della capacità mentale del CTO, che sta guidando lo sviluppo tecnologico del fornitore con cui stai lavorando. Ciò significa che i tuoi problemi stanno ricevendo una quantità significativa di attenzione.

Kieran Chandler: Quindi qual è il tuo suggerimento?

Joannes Vermorel: Il mio suggerimento, se vuoi fare le cose intelligentemente, è avvicinarti alle persone che hanno il controllo sulla roadmap. È più intelligente che negoziare in fretta funzionalità difettose che probabilmente scarterai tra sei mesi perché la tua soluzione non era buona o il tuo problema è cambiato. Inoltre, una diversa classe di consigli sarebbe evitare software che fa troppo. Vuoi pensare a un software che fa una cosa e la fa bene, piuttosto che un software con capacità estese che finisce per fare tutto male.

Kieran Chandler: Puoi approfondire ulteriormente questo punto?

Joannes Vermorel: È più facile migliorare un pezzo di software focalizzato che migliorare un framework gigantesco che fa tutto. Ogni volta che devi apportare una modifica, devi considerare il numero quadratico di interazioni. Se hai mille funzionalità e ne aggiungi una, devi considerare tutte le interazioni con le mille funzionalità preesistenti. Quindi, se introduci una funzionalità, devi considerare tutte le mille interazioni. Tuttavia, se hai solo dieci funzionalità e ne aggiungi una undicesima, devi solo rivedere dieci interazioni. Quindi, ancora una volta, concentrati su qualcosa di snello e focalizzato sul problema specifico che stai cercando di risolvere.

Kieran Chandler: Fantastico! Mi dispiace doverla interrompere qui per oggi, ma immagino che ci siano alcuni CEO là fuori che potrebbero non ringraziarla troppo per questo, probabilmente riceveranno qualche telefonata in più adesso. Bene, questo è tutto per questa settimana. Torneremo la prossima settimana con un altro episodio. Fino ad allora, stai bene.

Joannes Vermorel: Grazie.