IT bimodale no grazie

“Metti un tigre nel motore” — pubblicità Esso

Il concetto di IT bimodale è stato reso popolare nel mondo IT da Gartner qualche anno fa, nel 2014. Un concetto che ha avuto il merito di enfatizzare la necessità di evolvere le modalità organizzative interne alla Direzione IT. La tesi è semplice: l’IT deve muoversi a due velocità. Per le iniziative sperimentali e innovative deve essere veloce e flessibile, privilegiando l’adattabilità. Per le applicazioni core aziendali deve invece garantire stabilità, sicurezza e performance, utilizzando logiche collaudate. E’ facile seguire questo ragionamento e si possono fare suggestivi paragoni: la Direzione IT deve poter essere uno sprinter (o una gazzella), quando conta la velocità, e allo stesso tempo un maratoneta (o un elefante), quando conta l’affidabilità. Perchè ciò accada è necessario disporre di una organizzazione duale, con metodologie, competenze, processi distinti, da utilizzare di volta in volta in base alle caratteristiche del singolo progetto. Quando quel che conta è la velocità e l’addattabilità sono le metodologie agili quelle che vengono impiegate, mentre quando è importante la stabilità si riccore alla tradizionale metodologia waterfall.

Questo concetto ha avuto molto successo e se ne è scritto e parlato molto. E’ stata però l’applicazione nella realtà e l’esperienza che molte aziende ne hanno fatto a darne un giudizio realistico. Un giudizio impietoso: non solo l’IT bimodale si basa su presupposti teorici che oggi sappiamo essere scorretti, è anche pericoloso applicarlo perchè blocca l’innovazione organizzativa dell’IT.

Non abbiamo più bisogno di elefanti…

Se consideriamo il nostro portafoglio applicativo diviso in due mondi distinti vuol dire che le prestazioni prioritarie che vogliamo ottenere cambiano da applicazione a applicazione. Ma oggi la trasformazione digitale impone un nuovo passo a tutta l’azienda: sfruttare le opportunità offerte dalle nuove tecnologie, rendere flessibili i processi, creare nuovi modelli di business, sono tutti concetti correlati e trasversali. Velocità e flessibilità non si possono relegare alla periferia del nostro portafoglio applicativo, vanno portati direttamente al suo centro, perchè è lì che possono fare la differenza. Un Sistema Informativo capace di supportare e abilitare la trasformazione digitale dell’impresa è capace di evolversi velocemente nei suoi elementi core a supporto del business aziendale. Come facciamo quindi a scegliere, dato un progetto o un ambito applicativo, cosa merita di essere fatto in un modo e cosa in un altro? La scelta è senz’altro discrezionale e poco oggettiva, è difficile da compiere a priori e può rilevarsi errata.

Pensare che le metodologie agili siano adatte solo ad alcuni ambiti e non si possano applicare ad altri è oggi largamente smentito dall’esperienza. Alcuni ostacoli che spesso vengono addotti sono in realtà relativi agli aspetti più superficiali delle metodologie agili (modalità di coordinamento, ruoli, tempistiche), che vengono scambiati per fini e non per mezzi. Sono i principi fondanti dell’agile quelli che occorre applicare, declinandoli in modalità concrete sulla base delle specificità della propria azienda e del proprio business.

Sapendo quindi che le metodologie agili sono adatte ad ogni contesto applicativo, e ci consentono di essere più rapidi e flessibili, cosa ci ostacola ad applicarle al nostro intero portafoglio?

Se dal punto di vista teorico sfugge quindi il vantaggio di avere un IT Bimodale, è dal punto di vista dell’applicazione pratica all’interno delle Direzioni IT che sorgono i principali problemi:

  • Si rischia di distinguere fra progetti di serie A e progetti di serie B, con annesse risorse di serie A e risorse di serie B. Alcune persone lavorano in modalità innovativa su tematiche anch’esse innovative, mentre per gli altri non ci sono prospettive di crescita e cambiamento, costretti a lavorare in una maniera che considerano, rispetto all’evidente evoluzione del mondo IT, sempre più obsoleta e demotivante.
  • In teoria si vorrebbero portare le persone più innovative e portate al cambiamento, quindi spesso le più competenti e motivate, verso queste nuove modalità. Di fatto però queste persone sono concentrate sugli applicativi più critici e core per l’azienda (che secondo l’IT bimodale richiedono un approccio tradizionale) e vengono tenuti stretti dai rispettivi manager.
  • La modalità agile diventa allora terreno dei progetti meno importanti e più marginali, dove ci si può permettere di sbagliare e sperimentare, mentre le risorse più brave rimangono dov’erano. Si assiste allora ad un capovolgimento: quello che all’inizio poteva essere visto come stimolante diventa in realtà marginale e ad alto rischio, da serie A passa direttamente in serie C.
  • Applicare nuove modalità di gestione dei progetti richiede un elevato sforzo, e quindi è per tutti comodo relegarle a progetti isolati e piccoli a piacere. Questi progetti diventano il primo alibi per poter dire di essere innovativi senza avere in realtà cambiato nulla.
  • Anche nel caso si riuscisse a mantenere equilibrate le due modalità di lavoro, ci sarebbero forti problemi organizzativi. La Direzione IT dovrebbe conciliare al suo interno due organizzazioni parallele, con processi, stili di management, modalità di lavoro e di gestione delle risorse estremamente diversi, che fra l’altro dovrebbero collaborare con unità di staff che devono rimanere univoche (ad esempio l’ufficio architetti o l’IT Governance). Ancor più difficile diventerebbe relazionarsi con le unità organizzative esterne all’IT, in particolare con le Line of Business, che si troverebbero anch’esse a lavorare in modalità differenti a seconda dei progetti. Il rischio di “schizofrenia” è concreto e non è certo un modello di riferimento accettabile.

Questi sono tutti i rischi dell’IT Bimodale, che certamente possono essere attenuati con una gestione molto attenta, ma per quale motivo dovremmo affrontarli?

Il rischio vero è che la coesistenza di un modello organizzativo affermato con uno nuovo, più complesso e che deve ancora farsi strada, mettendo in discussione nel suo cammino competenze e posizioni manageriali, vada tutto a sfavore di quest’ultimo. L’agile diventa allora l’ennesima moda, che si segue con il minimo sforzo possibile per poter affermare che si è innovativi o per poter dimostrare che è destinata a fallire o che è inapplicabile nella propria azienda.

Apriamo la gabbia dell’innovazione

Parlando con tanti CIO, che stanno oggi affrontando la prospettiva di una profonda trasformazione della propria direzione, vediamo due prospettive. C’è chi afferma di essere bimodale perchè ha fatto qualche piccolo progetto in modalità agile, e pensa di aver terminato il proprio percorso di trasformazione. C’è invece chi capisce che la trasformazione non è così banale, non è reversibile e soprattutto deve riguardare tutto l’IT, non solo qualche progetto di facciata.

L’IT bimodale è purtroppo diventato una scusante per muoversi nella prima modalità, dimenticandosi della vera entità del problema. E’ un concetto corretto se lo si considera un primo passo e non un punto di arrivo, perchè non si può cambiare il modo di lavorare complessivo in un attimo e occorre vivere un transitorio non banale di coesistenza di modalità distinte. Ma il punto finale non deve vacillare, l’obiettivo deve essere chiaro: attuare un cambiamento complessivo e da cui non ha più senso tornare indietro. Perchè la posta in gioco è importante, e riguarda tutta l’azienda. Se il digitale sta velocemente riplasmando economie, prodotti, mercati e modalità lavorative, la lentezza, la burocrazia e la scarsa flessibilità tipiche dell’IT tradizionale non possono essere più tollerate, sono il primo ostacolo per una azienda che vuole cambiare.

Bisogna allora avere il coraggio di abbracciare questa rivoluzione organizzativa, togliendola dalla gabbia dove spesso l’abbiamo relegata per comodità o paura. Se riusciamo a liberare le potenzialità dell’IT possiamo guidare l’intera azienda nel suo percorso di trasformazione digitale. Per fare questo l’agile è un alleato formidabile: se hai una tigre non tenerla in gabbia, mettila nel motore!

Un uomo camminava nella foresta quando vide una volpe ferita. “Come può nutrirsi?”, pensò. In quel momento, si avvicinò una tigre, con un animale fra i denti. Saziò la sua fame e lasciò alla volpe quanto era avanzato. “Se Dio aiuta la volpe, aiuterà anche me”, rifletté l’uomo. Quindi tornò a casa, si chiuse dentro e rimase ad aspettare che i Cieli gli dessero da mangiare. Non accadde nulla. Quando ormai era troppo debole per uscire e lavorare, comparve un angelo. “Perché hai deciso di imitare la volpe ferita? — domandò l’angelo — Alzati, prendi i tuoi attrezzi e imbocca il cammino della tigre
Paulo Coelho