Il ruolo dell'IT

Joannes Vermorel

In molte, probabilmente nella maggior parte, le grandi aziende che operano un supply chain, il dipartimento IT ha anni di arretrato. L’arretrato è composto da una miriade di anomalie, incongruenze o fragilità che potrebbero essere risolte ma non lo sono. Oltre a generare enormi oneri burocratici, questa interminabile serie di fastidi inutili demotiva tutti. Il supply chain, situato proprio nel mezzo del panorama applicativo, è particolarmente colpito. Aneddoticamente, la porzione di supply chain¹ rappresenta frequentemente la metà dell’intero arretrato IT dell’azienda.

Peggio, l’arretrato è frequentemente oscurato da una sorta di Grand Transition, tipicamente un aggiornamento ERP. Questa è la diretta conseguenza dell’aspettativa che il Grand Transition risolva tutti i problemi trascurati nell’ultimo decennio. Eppure, questa aspettativa è infondata. Infatti, il Grand Transition, anche se completato con successo² mezzo decennio dopo, avrà introdotto molte nuove problematiche, anche se riesce a eliminare alcune di quelle vecchie.

Il Grand Transition comporta due effetti collaterali: in primo luogo, mette a tacere tutte le divisioni - tranne l’IT - quando si tratta di questioni software; in secondo luogo, agisce come un buco nero che assorbe tutti i budget e tutte le energie. Il secondo è una conseguenza del primo.

Per sua natura intrinsecamente tecnica, il Grand Transition è altamente specializzato. Nessuno - tranne gli specialisti IT - comprende davvero le clausole fini della migrazione da un sistema di database a un altro, e le sottili incompatibilità esistenti tra i due. Una volta che gli altri dipartimenti sono messi a tacere, non vi è alcuna resistenza a indirizzare tutto verso il Grand Transition. Gli altri dipartimenti di solito collaborano per la speranza erronea che acceleri il Grand Transition. Non lo farà. Al contrario, più grande è il budget, più lenta è l’iniziativa.

Tra le grandi aziende, questo approccio è prevalso negli ultimi due decenni. I risultati sono pessimi. Le aziende pagano ancora tariffe esorbitanti per le CRUD apps³ che avrebbero dovuto essere commoditized – tramite open source – più di un decennio fa. I ritardi nell’implementazione non sono mai stati così lunghi. Ciliegina sulla torta: le prestazioni e la reattività del software aziendale sono ancora pessime come sempre, mentre l’hardware sottostante è 1000 volte più capace di quanto lo fosse due decenni fa.

Questa situazione richiede una soluzione radicale: il dipartimento IT deve smettere di comportarsi come il Grand Architect per conto di tutti gli altri dipartimenti. Invece, il dipartimento IT deve diventare un coach per gli altri dipartimenti, concentrandosi esclusivamente sull’infrastruttura⁴, lasciando tutto il resto ai dipartimenti stessi con una mentalità di enabler.

La posizione del Grand Architect è insostenibile: anche collettivamente, l’IT non può sapere tutto quello che c’è da sapere su finanza, marketing, vendite, paghe, produzione, contabilità, trasporti, pianificazione, conformità, legale, ecc. Il tuttofare rovina la maggior parte delle iniziative intraprese. Ogni consegna a metà conduce a ulteriori problematiche che richiederanno risoluzione successiva. La generazione di arretrato è sia inevitabile che infinita. Con il passare degli anni, man mano che il software diventa sempre più onnipresente, l’arretrato diventa ogni anno sempre più ingestibile.

La soluzione è semplice⁵: abbandonare il ruolo di Grand Architect e riposizionare il dipartimento IT come enabler e mentore per tutte le iniziative legate al software eseguite dagli altri dipartimenti. Affidare ai dipartimenti, come il supply chain, la responsabilità delle proprie iniziative software li costringe a rivedere le proprie ambizioni: niente più capri espiatori per un arretrato fuori controllo. Il dipartimento è responsabile sia dei propri successi che dei propri fallimenti.

Tuttavia, la soluzione viene quasi mai implementata.

Riposizionare l’IT come enabler significherebbe ridurre i suoi budget della metà o più, diretta conseguenza di un’impronta operativa notevolmente ridotta all’interno dell’azienda. Ciò è inaccettabile per il responsabile del dipartimento IT la cui posizione spesso si equipara, in termini di potere, a quella del CEO durante il Grand Transition.

Ciò significherebbe anche che i responsabili dei dipartimenti dovrebbero essere ritenuti responsabili delle proprie iniziative software - o della loro assenza. È comodo poter scaricare la colpa sull’IT ogni volta che un progetto va storto - un evento comune nel software. Inoltre, ciò permette ai dipartimenti di evitare il difficile problema dell’assunzione di talenti IT, una sfida che dura da decenni.

Tuttavia, man mano che il software aziendale si sposta verso il SaaS (Software as a Service), la prospettiva del Grand Architect sta gradualmente diventando irrilevante, poiché i fornitori si occupano di hosting, backup, aggiornamenti, ecc. Di conseguenza, sebbene in maniera incidentale, i responsabili dei dipartimenti sono progressivamente costretti a rendersi responsabili delle loro decisioni software, e il dipartimento IT è gradualmente costretto a rinunciare alle sue vecchie responsabilità.

Il software aziendale è arrivato con un decennio di ritardo alla festa del SaaS. Prevedo che ci vorrà un altro decennio prima che la maggior parte delle grandi aziende abbandoni la mentalità del Grand Architect.