La trappola del make or buy nei progetti IT

Make or buy. Una delle questioni fondamentali quando si progetta qualcosa di nuovo. In teoria, dovrebbe essere una decisione basata su analisi fredda e razionale. Nella pratica dei progetti IT disfunzionali, si trasforma in una barzelletta dove l’azienda è la protagonista involontaria.

La domanda apparentemente semplice si arricchisce di variabili meravigliosamente irrazionali. Manager che hanno letto un articolo su una tecnologia emergente durante un volo e sono convinti sia la soluzione universale. Responsabili che ripetono “non reinventiamo la ruota” mentre chiedono di modificare così tanto la ruota acquistata che somiglia più a un dodecaedro.

Buy and destroy

L’opzione buy raramente significa comprare e usare così com’è. Nel settore IT, buy è l’inizio di buy and destroy: acquistiamo un prodotto perfettamente funzionante per poi massacrarlo con personalizzazioni fino a renderlo irriconoscibile.

Le personalizzazioni iniziano con “vorremmo solo cambiare questa etichetta”. Proseguono con “il flusso dovrebbe essere diverso”. E prima che qualcuno possa dire “incremento di budget”, ci si ritrova in un progetto di diciotto mesi per modificare qualcosa che funzionava il giorno dell’acquisto.

Dopo mesi, il prodotto è sepolto sotto personalizzazioni che rendono impossibili gli aggiornamenti. Il supporto non può aiutare perché il sistema è troppo modificato. Gli aggiornamenti di sicurezza non possono essere applicati senza rompere tutto.

L’ossessione del rebranding

La prima richiesta classica è: “Possiamo togliere il logo del prodotto e mettere il nostro?” Questa ansia di brandizzare il software altrui è inspiegabile. Lo stesso manager guida un’auto aziendale col logo della casa automobilistica, non quello dell’azienda. Ma il software deve essere brandizzato.

Questa richiesta apre la porta a modifiche sempre più invasive. Se possiamo cambiare il logo, perché non i colori? Se i colori, perché non il layout? Ogni passo sembra piccolo, ma la somma è catastrofica. Il risultato è un prodotto che ha perso tutti i vantaggi dell’essere software commerciale maturo, mantenendo gli svantaggi di non essere stato progettato specificamente per l’azienda.

L’illusione del make

L’opzione make ha il suo fascino perverso. C’è un’irresistibile sensazione di potere nel dire “lo costruiremo noi”. Come se ogni azienda avesse un team di geni pronti a battere specialisti che hanno lavorato su quel prodotto per anni.

È l’equivalente di dire “potrei costruire questa casa da solo” dopo aver montato una mensola. La sottovalutazione della complessità di sviluppare software enterprise è sistematica. Lo sviluppo interno parte con stime ottimistiche. Sei mesi diventano dodici, poi diciotto. Nel frattempo, il prodotto commerciale è arrivato alla versione 3.0 con funzionalità che non verranno mai implementate internamente.

I processi unici che non esistono

La giustificazione per personalizzazioni massive è “dobbiamo adattarlo ai nostri processi unici”. Processi che, a un’analisi onesta, sono esattamente gli stessi di qualsiasi altra azienda del settore. Solo con nomi diversi per far sentire speciale il management.

“Il nostro workflow è completamente diverso” significa che chiamano “validazione” quello che altri chiamano “approvazione”. La pretesa di unicità nasconde resistenza al cambiamento. Se un prodotto commerciale è leader di mercato, probabilmente incorpora le best practices. Dire “non funziona per noi” spesso significa “non vogliamo cambiare”.

Le scelte senza competenza

Poi c’è il classico “prendiamo questo prodotto” detto da chi non ha competenza in materia. Per poi scoprire che il prodotto non soddisfa i requisiti. È un capriccio di chi ha letto un post sui social.

“Ho visto che tutti usano blockchain/AI/IoT” mentre il team IT si scambia sguardi terrorizzati. Implementare blockchain per le presenze in mensa potrebbe essere eccessivo. Ma spiegarlo a chi è convinto che ogni problema si risolva con la buzzword del momento è impresa disperata.

Il prodotto visto in demo perfetta non può magicamente integrarsi con i ventisette sistemi legacy. “L’ha fatto anche la concorrenza” è l’argomento definitivo, ignorando che la concorrenza ha speso tre anni e venti milioni.

Le dinamiche interne prevalgono

Queste decisioni non vengono prese sulla base delle reali necessità tecniche. Prevalgono dinamiche interne insensate. Il responsabile IT vuole giustificare il suo dipartimento optando per lo sviluppo interno. Il manager vuole la demo vista “con il nostro tocco”. Il consulente propone la soluzione con più ore fatturabili.

Ogni stakeholder ha un’agenda nascosta. Il risultato è un compromesso che non soddisfa nessuno. Nessuno ha il coraggio di dire “questo prodotto fa ciò di cui abbiamo bisogno, compriamolo e usiamolo così com’è”. Si preferiscono progetti lunghi, complessi e dolorosi.

L’adattamento impossibile

La risposta giusta sarebbe spesso un semplice buy seguito da adattamento dell’organizzazione al software, non viceversa. Ma questa opzione viene raramente considerata perché richiede ammettere che i processi aziendali potrebbero non essere ottimali.

Il ragionamento dovrebbe essere: se il prodotto è stato creato sulle esigenze del mercato globale, basandosi su centinaia di implementazioni, forse il problema non è il prodotto. Forse è il processo aziendale inefficiente.

Ma no. “Noi siamo diversi. Adatteremo il software a come lavoriamo noi, che è l’unico modo giusto.” Tutti gli altri sono stupidi. È un atteggiamento che precede regolarmente fallimenti aziendali.

Il ciclo infinito

Il ciclo si ripete. Si acquista un prodotto, si personalizza, le modifiche crescono esponenzialmente. Il prodotto diventa impossibile da aggiornare. Le vulnerabilità si accumulano. La frustrazione cresce.

Dopo anni, arriva un nuovo manager. Decide che il vecchio sistema è inadeguato. Si valutano nuove opzioni. E il ciclo ricomincia, con gli stessi errori. La lezione non viene mai imparata perché chi decide non subisce le conseguenze.

La scelta dell’inferno

Discutere se sviluppare internamente, acquistare o personalizzare non è solo una decisione tecnica. È scegliere la propria versione dell’inferno di Dante. Con la differenza che Dante è uscito dall’inferno, mentre il progetto IT potrebbe rimanerci per l’eternità, intrappolato in personalizzazioni infinite, workaround su workaround, meeting senza fine.

Verso decisioni razionali

La soluzione più semplice è spesso la migliore. Ma nel mondo IT, semplice è sinonimo di noioso. Si preferisce complicare. Nel meraviglioso universo della tecnologia aziendale, il vero valore non è nella soluzione, ma nel viaggio doloroso, costoso e spesso inutile.

Serve coraggio per dire: “Questo prodotto fa quello che ci serve. Lo usiamo così com’è.” Serve umiltà per riconoscere che i processi potrebbero non essere ottimali. Serve pragmatismo per resistere alle personalizzazioni. Ma queste qualità sono rare dove la politica interna prevale sulla logica tecnica.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT