Il ruolo dell'IT

Joannes Vermorel

In molte, probabilmente nella maggior parte, delle grandi aziende che operano una supply chain, il dipartimento IT ha anni di arretrato. L’arretrato è costituito da una miriade di problemi, incongruenze o fragilità che potrebbero essere risolti ma non lo sono. Oltre a creare enormi oneri burocratici, questa infinita serie di fastidi senza senso demotiva tutti. La supply chain, che si trova proprio al centro del paesaggio applicativo, ne è particolarmente influenzata. Aneddoticamente, la porzione della supply chain¹ rappresenta spesso la metà dell’intero arretrato IT dell’azienda.

Peggio ancora, l’arretrato è spesso oscurato da una Grande Transizione, tipicamente un aggiornamento ERP. Questa è la conseguenza diretta del fatto che ci si aspetta che la Grande Transizione risolva tutti i problemi che sono stati trascurati negli ultimi dieci anni. Tuttavia, questa aspettativa è sbagliata. Infatti, la Grande Transizione, anche se completata con successo², mezzo decennio dopo, avrà introdotto molti nuovi problemi, anche se riuscirà ad eliminare alcuni dei vecchi.

La Grande Transizione comporta due effetti collaterali: in primo luogo, silenzia 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 l’energia. Il secondo è una conseguenza del primo.

A causa della sua stessa natura, la Grande Transizione è altamente tecnica. Nessuno - tranne gli specialisti IT - comprende veramente i dettagli della migrazione da un sistema di database a un altro e le sottili incompatibilità che esistono tra i due. Una volta che gli altri dipartimenti vengono silenziati, non c’è resistenza nel canalizzare tutto verso la Grande Transizione. Gli altri dipartimenti di solito collaborano nella speranza sbagliata che accelererà la Grande Transizione. Non lo farà. Succede il contrario: più grande è il budget, più lenta è l’iniziativa.

Tra le grandi aziende, questo approccio è stato predominante negli ultimi due decenni. I risultati sono disastrosi. Le aziende continuano a pagare tariffe stravaganti per le app CRUD³ che avrebbero dovuto essere commoditizzate - tramite open source - più di un decennio fa. I ritardi di implementazione non sono mai stati così lunghi. Ciliegina sulla torta: le prestazioni e la reattività del software aziendale sono ancora scarse come sempre, mentre l’hardware sottostante è 1000 volte più potente di quanto non fosse due decenni fa.

Questa situazione richiede una soluzione profonda: il dipartimento IT deve smettere di agire come il Grande Architetto per conto di tutti gli altri dipartimenti. Invece, il dipartimento IT deve diventare un coach per gli altri dipartimenti, con un focus esclusivo sull’infrastruttura⁴, lasciando tutto il resto ai dipartimenti stessi con una mentalità abilitante.

La posizione del Grande Architetto è insostenibile: anche collettivamente, l’IT non può sapere tutto ciò che c’è da sapere su finanza, marketing, vendite, paghe, produzione, contabilità, trasporti, pianificazione, conformità, legale, ecc. Il tuttofare rovina la maggior parte delle iniziative che intraprende. Ogni consegna approssimativa porta a ulteriori problemi che devono essere risolti successivamente. La generazione di arretrato è inevitabile e senza fine. Man mano che il software diventa sempre più diffuso ogni anno, l’arretrato diventa sempre più ingestibile ogni anno.

La soluzione è semplice⁵: rinunciare al Grande Architetto e riposizionare il dipartimento IT come facilitatore e mentore per tutte le iniziative legate al software eseguite dagli altri dipartimenti. Mettere i dipartimenti, come la supply chain, responsabili delle proprie iniziative software li costringe a rivedere le proprie ambizioni: niente più capri espiatori per l’arretrato che sfugge al controllo. Il dipartimento è responsabile sia dei suoi successi che dei suoi fallimenti.

Tuttavia, la soluzione viene quasi mai implementata.

Riposizionare l’IT come facilitatore significherebbe ridurre i suoi budget di almeno la metà, con la conseguenza diretta di una presenza operativa molto ridotta all’interno dell’azienda. Questo è inaccettabile per il responsabile del dipartimento IT, la cui posizione spesso si confronta, in termini di potere, con quella del CEO durante la Grande Transizione.

Ciò significherebbe anche che i responsabili dei dipartimenti dovrebbero essere responsabili delle proprie iniziative software, o della mancanza di esse. C’è un certo comfort nel poter scaricare la colpa sull’IT ogni volta che un progetto va storto, una situazione comune nel settore del software. Inoltre, permette ai dipartimenti di evitare il problema spinoso di assumere talenti IT, che è una sfida da decenni.

Tuttavia, man mano che il software aziendale si sposta verso il SaaS (Software as a Service), la prospettiva del Grande Architetto sta gradualmente svanendo nell’irrilevanza, poiché i fornitori si occupano di hosting, backup, aggiornamenti, ecc. Così, seppur incidentalmente, i responsabili dei dipartimenti sono gradualmente costretti a diventare responsabili delle proprie decisioni software, e il dipartimento IT è gradualmente costretto a rinunciare alle sue precedenti responsabilità.

Il software aziendale è arrivato in ritardo di un decennio alla festa del SaaS. Prevedo che ci vorrà un altro decennio affinché la maggior parte delle grandi aziende esca dal mindset del Grande Architetto.