La direzione IT: il governo della tecnologia e i suoi sette mestieri

Ho visto un progetto Dynamics 365 F&O arrivare all’adozione in otto paesi - Italia, Germania, Francia, Spagna, Stati Uniti, Brasile, Argentina e Cina - senza un giorno di caos, e il merito non stava in un fornitore particolarmente bravo. Stava nella direzione IT, che teneva insieme i consulenti esterni e i key user - gli utenti esperti che parlano per i reparti - di ogni paese: fusi orari, localizzazioni, priorità che ogni sede considerava ovviamente le proprie. I consulenti cambiavano, i reparti parlavano lingue diverse in tutti i sensi; la regia interna teneva il filo, e l’adozione fu fluida perché qualcuno, dentro l’azienda, sapeva sempre a che punto era ogni pezzo del progetto.

Questo è il primo approfondimento della serie sugli errori nei progetti ERP: non un settimo errore, ma la figura che i sei pezzi hanno incontrato a ogni curva senza mai fermarsi a guardarla. Il pezzo sulle persone l’ha presentata con un elenco di sette mestieri; qui ognuno di quei mestieri ha la sua sezione.

Le decisioni informatiche

Che cosa governa la direzione IT: le scelte che decidono il costo del progetto e il futuro del sistema.

La parola «IT», in azienda, copre due mestieri diversi, e conviene separarli subito. Il primo è l’esercizio: far funzionare ogni giorno l’infrastruttura e le applicazioni - le reti, i salvataggi, gli accessi, l’assistenza a chi lavora. Il secondo è il governo, ed è quello di cui parla questo pezzo. La direzione IT, in questo senso, è la funzione interna che decide sulle questioni informatiche, o che prepara le decisioni per chi deve firmarle. Sono decisioni informatiche molto concrete: personalizzare una funzione o tenerla standard; collegare un sistema esistente o spegnerlo; quale cantiere fare prima e quale dopo; quando installare un aggiornamento. Un criterio distingue la direzione IT da chiunque altro sieda a quel tavolo: prende queste decisioni guardando soltanto l’interesse dell’azienda. Il fornitore, per quanto bravo e onesto, guarda anche il proprio.

Queste decisioni contano tanto perché un progetto ERP ne è fatto: prima ancora di essere un’installazione di software, è una lunga catena di decisioni come quelle. Ogni decisione presa bene evita un costo preciso, di quelli che il pezzo sul costo totale ha elencato: la personalizzazione inutile che poi si ripaga a ogni aggiornamento, l’interfaccia costruita due volte, il fermo arrivato nel momento peggiore. E le decisioni che nessuno prende non restano in sospeso: le prendono gli eventi. Se nessuno decide quando aggiornare, l’aggiornamento arriva quando lo decide il produttore, magari in piena chiusura contabile. Non decidere è comunque una decisione, e di solito la più cara.

Quanto vale il governo

I tre presìdi propri della direzione IT - architettura, investimenti, sicurezza - e i numeri, con le fonti, di che cosa succede quando mancano.

Tre presìdi devono appartenere alla direzione IT, e le fonti permettono di dirlo coi numeri invece che per principio:

• il governo dell’architettura: quali sistemi l’azienda ha, e come si parlano fra loro;
• il controllo degli investimenti informatici: che cosa si compra, perché, e che cosa rende;
• la sicurezza: gli accessi, i dati, la continuità operativa.

Sono i tre compiti che nessun reparto può rivendicare e che il fornitore può solo eseguire, non possedere.

Che cosa succede quando questi presìdi mancano è documentato. Il rapporto del GAO - l’ufficio del Congresso americano che controlla i conti federali, la fonte più citata di questa serie - esaminando i fallimenti dei grandi sistemi gestionali trova esattamente le tre assenze speculari fra le famiglie di cause ricorrenti: architetture senza governo, investimenti senza controllo, sicurezza trascurata. E lo studio di McKinsey con l’Università di Oxford su oltre 5.400 progetti informatici presenta il conto: i progetti grandi - lo studio misura quelli sopra i 15 milioni di dollari, ma sono le proporzioni, più che le cifre, a parlare anche alle imprese più piccole - sforano in media del 45% il bilancio, consegnano all’azienda circa metà del valore promesso (il 56% in meno), e quasi uno su sei va così male da minacciare l’esistenza stessa dell’azienda. Quando lo stesso studio elenca i rimedi, i primi due chiamano in causa l’azienda e non il fornitore: governare la strategia e le persone interessate, e tenersi stretti i talenti che capiscono sia il mestiere sia la tecnica. Sono rimedi di governo, non di tecnica.

E quando i presìdi ci sono, si vede nei conti. Weill e Ross, del centro di ricerca sui sistemi informativi dello Sloan, studiando 250 imprese, hanno trovato che quelle che assegnano con chiarezza i diritti di decisione informatici - chi decide gli investimenti, chi le architetture, chi le priorità - hanno oltre il 25% di profitti in più a parità di obiettivi strategici. E la loro lezione, prima ancora della statistica, è il metodo: il governo si progetta assegnando le decisioni una per una, invece di lasciarle a chi alza la voce. È la delega effettiva del pezzo sulla pianificazione - l’autorità vera data a chi sa entrare nel merito - applicata all’informatica. Con un prerequisito organizzativo che nessuno schema di deleghe sostituisce: la direzione IT siede al tavolo della direzione. Una funzione che riporta soltanto come centro di costo verrà trattata da centro di costo, e comprimerla sarà sempre la mossa più facile del bilancio.

A chi deve rispondere la direzione IT?

Uno studio su MIS Quarterly - Banker, Hu, Pavlou e Luftman, su dati di due decenni - ha confrontato le due scelte più comuni, il CIO sotto l’amministratore delegato e il CIO sotto il direttore finanziario. Il risultato: non esiste un riporto giusto in assoluto, esiste quello allineato alla strategia. Chi compete differenziandosi rende di più col CIO che risponde al vertice; chi compete sui costi, col CIO che risponde alla finanza; a penalizzare i risultati è il disallineamento fra riporto e strategia.

Per un’azienda che compra un ERP per crescere, la conseguenza è netta: mettere il governo della tecnologia sotto chi ha il mandato di contenere i costi orienterà ogni decisione al risparmio. E un progetto di trasformazione guidato dal solo risparmio consegna quello che promette: un sistema più economico, non un’azienda migliore.

Il valore, insomma, non scaturisce dalle macchine ma dalle decisioni giuste, prese dalla figura giusta: e quelle decisioni le prende la direzione IT.

Cosa si può delegare e cosa deve rimanere

L’ufficio può essere piccolo e molto si può delegare; decidere, verificare e rispondere no.

A questo punto la domanda è legittima: serve per forza un ufficio IT? Non basterebbero un altro ufficio, un fornitore forte, il cloud che promette di non richiedere gestione interna?

L’ufficio può essere piccolo - in una media impresa i sette mestieri stanno in poche persone, e il nome sulla porta conta poco - ma è un mestiere. Chiede competenza aggiornata, di chi la tecnologia la pratica; il mandato per decidere, cioè quella delega effettiva; e nessun interesse in comune col fornitore da giudicare, perché dall’altra parte del tavolo siedono professionisti che fanno solo quello. Conoscere i processi interni e avere buone relazioni con la direzione non basta: chi porta solo quello finisce per firmare ciò che il fornitore propone.

Il fornitore, del resto, non può essere l’arbitro di se stesso: chi propone una personalizzazione non può valutarne da solo il costo per l’azienda, chi consegna non può verificare le proprie date, chi costruisce non può firmare il proprio collaudo. In ogni pezzo di questa serie il fornitore siede da un lato del tavolo, e serve qualcuno seduto dall’altro: da solo non diventa disonesto, diventa l’unico a decidere - e in buona fede ottimizza anche per sé.

Nemmeno il cloud scioglie la funzione: toglie le macchine, non le decisioni. Il calendario degli aggiornamenti lo detta il produttore - il settimo mestiere ci tornerà - e serve qualcuno in casa che legga i piani di rilascio, scelga le finestre, prenoti le verifiche. E la responsabilità non trasloca: il modello di responsabilità condivisa che i fornitori cloud stessi pubblicano lascia al cliente, qualunque sia il servizio comprato, i dati, i dispositivi, gli account e gli accessi, conformità compresa. Il cloud toglie le macchine dalla sala server; la responsabilità resta dov’era.

Fuori, quindi, possono andare le macchine e i servizi (al cloud), la manutenzione (all’AMS, il servizio che manutiene il sistema a progetto chiuso), la costruzione (all’integratore). Con un’eccezione fisica: l’edge e l’on-premises - i sistemi a ridosso della produzione e i server che restano in sede, perché latenza, continuità o vincoli non li fanno salire in cloud - abitano dentro il confine, e il loro esercizio resta un compito di casa. In casa resta il governo della tecnologia - decidere, verificare, rispondere, disegnare il futuro - che pesa poco in organico, una o due persone dedicate più il tempo prenotato dei key user, e pesa tutto in conseguenze. E dove la figura piena non è sostenibile, esiste la competenza frazionaria: un direttore IT a tempo parziale, condiviso fra più imprese o temporaneo, purché con il mandato vero e senza legami col fornitore da giudicare. L’alternativa non è fra l’ufficio grande e niente: è fra un governo dimensionato e nessun governo.

La ragione ultima è strutturale: il fornitore passa - l’integratore consegna e va al prossimo progetto, i consulenti ruotano, il contratto di supporto cambia mani - mentre la direzione IT resta: è l’unica figura che attraversa per intero l’arco dai requisiti al ciclo di vita. I suoi mestieri, lungo quest’arco, sono sette.

Il primo mestiere: la conduzione

Il quotidiano della regia: fornitori, calendario e dipendenze fra i cantieri.

Il primo mestiere è il meno visibile e il più continuo: condurre. Il progetto è fatto di cantieri che si aspettano l’un l’altro - la configurazione aspetta i requisiti, la migrazione aspetta la pulizia, i test aspettano tutti - e qualcuno deve tenere il calendario delle dipendenze, coordinare l’integratore di sistema e i fornitori minori, accorgersi per primo che un ritardo a monte sta scivolando a valle. Il pezzo sui test ha mostrato il caso più duro: le consegne del fornitore verso le finestre prenotate dei key user meritano un impegno contrattuale, e chi lo fa rispettare, giorno per giorno, è la direzione IT. La conduzione, peraltro, comincia prima del cantiere: il capitolato, la rosa dei candidati, la prova su casi propri - la scelta del fornitore raccontata nel pezzo sul costo totale - sono già regia, solo con un altro nome.

Gli strumenti sono pochi e noti, e valgono per la costanza con cui si usano: un piano che qualcuno aggiorna davvero, una riunione di avanzamento breve e a cadenza fissa con l’integratore, un registro dei rischi e delle decisioni - perché fra un anno nessuno ricorderà perché si scelse così, e la memoria scritta è metà del governo. Quanto renda lo dice l’appendice del rapporto GAO, che riprende dalla letteratura di settore una stima severa: il progetto medio spende circa l’80% del tempo in rilavorazioni non pianificate - correggere errori fatti prima - e la conduzione serve esattamente a barattare gli errori grandi e subiti con errori piccoli e pianificati.

Il secondo mestiere: il filtro dei conflitti

Ciò che è tecnico si scioglie qui; ai vertici sale soltanto ciò che li richiede davvero.

Il secondo mestiere è decidere che cosa sale ai vertici e che cosa si ferma prima. Un ERP fa emergere conflitti di continuo - un campo conteso fra due reparti, una priorità di sviluppo, il tracciato di un’interfaccia - e la maggior parte è tecnica: si scioglie con una decisione di merito presa in fretta, al livello giusto. La catena della guida, descritta nel pezzo sulle persone, regge se ogni gradino trattiene ciò che gli spetta: la direzione IT filtra, e alla sponsorship sale soltanto ciò che ridistribuisce lavoro o potere fra i reparti, cioè ciò che richiede davvero i vertici. Un filtro debole produce vertici intasati di dettagli tecnici; un filtro invadente produce scelte politiche prese dai tecnici. Entrambi si pagano.

Sul campo, il filtro è un tavolo tecnico a cadenza fissa, coi key user dei reparti coinvolti, e una regola di salita scritta: sale ai vertici ciò che sposta perimetro, costi o equilibri fra reparti; resta al tavolo tutto il resto. L’esempio classico è l’anagrafica articoli, contesa fra produzione e vendite: chi la possiede, chi codifica, chi può modificare. Decisa al tavolo, con le due parti sedute, è una regola di lavoro; lasciata ai corridoi diventa una guerra di confine che risale fino alla direzione con mesi di ritardo, e ci arriva ingrossata.

Il terzo mestiere: la copertura dei requisiti

Ogni requisito ha una risposta e una prova, e il filo che li lega ha un nome: tracciabilità.

Il terzo mestiere è tenere un filo. Ogni requisito raccolto deve avere una risposta dichiarata - una configurazione, una personalizzazione, o una rinuncia messa per iscritto - e una prova che lo verifica. Questo filo si chiama tracciabilità dei requisiti, ed è pratica codificata da decenni: l’appendice sui processi disciplinati del rapporto GAO la elenca fra le caratteristiche dei buoni requisiti, il legame mantenuto fra i documenti a ogni livello di dettaglio. In concreto è un registro che vive quanto il progetto: quando un requisito cambia, la risposta e la prova cambiano con lui, e quando il collaudo arriva, il piano dei test ha già l’elenco di ciò che deve coprire. Un requisito senza prova è una promessa; un requisito perso per strada diventa, fra sei mesi, una procedura ombra: un lavoro che si fa fuori dal sistema.

Che questo filo valga oro non lo dice solo il mestiere. La stessa appendice del GAO riprende due numeri classici della letteratura: correggere un requisito all’inizio costa da 50 a 200 volte meno che correggerlo a sistema realizzato (lo studio di Boehm e Papaccio), e fra il 40 e il 60 per cento dei difetti di un progetto software risale a errori fatti nella fase dei requisiti (Leffingwell). Lo strumento, in confronto, costa pochissimo: una matrice governata - requisito, risposta, prova, stato - purché qualcuno la tenga e i cambi passino di lì. E a progetto chiuso non si butta: diventa la base del registro del miglioramento, perché le richieste nuove si confrontino con ciò che fu deciso, e col perché.

Il quarto mestiere: le interfacce e i dati

I flussi coi sistemi di terzi e la mappatura ripetibile: il confine tecnico dell’azienda è suo.

Il quarto mestiere è presidiare il confine tecnico dell’azienda. Le integrazioni con i sistemi di terzi - censite nel pezzo sul costo totale, riprese in quello sulla migrazione - sono flussi permanenti, e la direzione IT ne risponde due volte: al passaggio, quando cambiano canale senza che i terzi debbano accorgersene, e per sempre, a ogni modifica di uno dei due lati. Il rapporto GAO è netto sul metodo: le interfacce si provano da un capo all’altro, non a pezzi. E lo stesso vale per i dati: la mappatura della migrazione dev’essere una procedura ripetibile - scritta, rieseguibile, provata - perché è la condizione delle migrazioni di prova, e perché quella stessa mappatura tornerà utile a ogni futura integrazione.

Anche qui lo strumento è un inventario vivo: per ogni interfaccia il proprietario, il formato, la frequenza, il comportamento in caso d’errore, e il nome di chi risponde dall’altra parte. In esercizio le interfacce si guardano al mattino - le code, gli scarti, i flussi che non sono arrivati - perché un’interfaccia ferma di rado apre una segnalazione: semplicemente, da qualche parte, un magazzino non spedisce. E l’inventario è la prima pagina che si apre a ogni novità: la prossima integrazione, il prossimo cambio di listino, la prossima società acquisita partiranno da lì.

Il quinto mestiere: disponibilità, sicurezza, conformità

I requisiti che nessun reparto chiederà mai nelle interviste.

Il quinto mestiere è portare al tavolo i requisiti senza portavoce. Nessun key user chiederà mai «voglio che il sistema regga la chiusura con tutti collegati» o «voglio i registri dei trattamenti a posto»: se non li porta la direzione IT, non li porta nessuno. Sono tre famiglie. La disponibilità: il sistema deve esserci quando l’azienda lavora, chiusure e picchi stagionali compresi, e il test di carico è la sua prova. La sicurezza: accessi, ruoli, separazione dei compiti, e le regole d’accesso del partner scritte prima, come il pezzo sul go-live ha raccomandato. E la conformità alle norme: il GDPR, il regolamento europeo sulla protezione dei dati personali, perché un ERP tratta dati di dipendenti, clienti e fornitori a ogni transazione; la NIS2, la direttiva europea sulla sicurezza delle reti, che estende gli obblighi di sicurezza a un perimetro più ampio di imprese; e l’AI Act, il regolamento europeo sull’intelligenza artificiale, che entra in gioco se il sistema incorpora funzioni di quel tipo. Il progetto è il momento più economico per farci i conti: la conformità aggiunta dopo costa come una personalizzazione, e si riverifica come lei.

In pratica, quattro abitudini. Il calendario dei fermi si concorda coi reparti, mai un aggiornamento in chiusura mensile. I ruoli si disegnano con la separazione dei compiti - chi crea un fornitore in anagrafica non ne paga le fatture - e si riverificano a ogni riorganizzazione, perché i diritti crescono per accumulo e nessuno li toglie mai da solo. I registri dei trattamenti si tengono aggiornati insieme a chi in azienda risponde della protezione dei dati. E ogni funzione di intelligenza artificiale che il produttore aggiunge al sistema si valuta prima di accenderla, perché l’AI Act ragiona per usi e per rischi, non per marchi: la stessa funzione può essere innocua in un processo e regolamentata in un altro.

Il sesto mestiere: l’AMS, disegnato prima

Efficiente per chi usa, sostenibile per chi paga: le due misure si tengono solo se il disegno è precoce.

Il sesto mestiere è disegnare il dopo mentre il dopo è ancora lontano. L’AMS (Application Management Services, il servizio che gestisce e manutiene il sistema a progetto chiuso) vive fra due misure che tirano in direzioni opposte: dev’essere efficiente per chi il sistema lo usa - risposte in tempi noti, coi key user come primo filtro - e sostenibile nei costi per l’azienda. Le due misure si tengono insieme solo se il disegno comincia nel progetto, come il pezzo sul go-live ha mostrato con la guida Microsoft alla mano: chi supporterà si allena durante i collaudi, il perimetro del contratto si scrive, e il passaggio all’esercizio ha consegne e una firma. Un AMS comprato all’ultimo mese è un servizio preso a listino: costa il massimo e conosce il minimo.

Il perimetro, poi, si scrive: che cosa è compreso (la correzione dei difetti, l’assistenza agli utenti), che cosa si paga a consumo (l’evolutivo), i livelli di servizio per gravità con le vie di scalata, e una riunione di servizio a cadenza fissa coi numeri del pannello sul tavolo. E una scelta va fatta a occhi aperti: se l’AMS lo tiene lo stesso partner che ha costruito il sistema, si guadagna la conoscenza e si perde un controllo, perché il manutentore giudica il lavoro del costruttore, cioè il proprio. Si può fare, sapendolo: con verifiche indipendenti nei punti che contano, e con la direzione IT a leggere i numeri del servizio ogni mese.

Il settimo mestiere: il ciclo di vita del sistema

Versioni e aggiornamenti hanno un calendario che l’azienda non decide: si governa, non si subisce.

Il settimo mestiere è il più lungo: dura quanto il sistema. Un ERP in cloud si aggiorna quando lo decide il produttore: per Dynamics 365, per esempio, la documentazione ufficiale prevede aggiornamenti di servizio con una finestra di manutenzione scelta dal cliente, piani di rilascio noti fino a tre mesi prima, e la possibilità di rinviare al massimo un aggiornamento consecutivo. Il ritmo, insomma, lo detta il cloud; all’azienda resta il governo, coi costi di verifica che il pezzo sul costo totale aveva messo in conto. E oltre i singoli aggiornamenti resta l’orizzonte lungo: il ciclo di vita del sistema - le versioni, la durata del supporto, la fine annunciata o taciuta - va tenuto compatibile con gli obiettivi aziendali, perché è qui che si misura il valore dell’investimento negli anni, ed è qui che matura, quando matura, il costo di uscita. Un sistema che impone all’azienda i suoi tempi, o che l’azienda supera prima di averlo ammortizzato, è una strategia scritta da altri.

La pratica è un rito annuale più che un’attività quotidiana: si leggono le tabelle di marcia del produttore, si pianificano le finestre di aggiornamento dove l’azienda le regge, si tiene un ambiente di prova in cui le verifiche coi key user costino poco, e una volta l’anno ci si fa la domanda vera: il sistema regge ancora la strategia - la nuova società, il nuovo paese, il nuovo canale - o sta cominciando a costare più di quanto rende? È la domanda da cui esce, un giorno, il costo di uscita del pezzo sul costo totale. Meglio farsela per tempo che sentirsela fare.

Il mestiere che contiene gli altri

Chi progetta, sviluppa e governa il futuro dei sistemi informativi: l’architettura, che nessun fornitore può possedere.

I sette mestieri, visti da vicino, producono ciascuno un pezzo di conoscenza: il registro delle decisioni, la matrice dei requisiti, l’inventario delle interfacce, i numeri del servizio, le tabelle di marcia del produttore. Messi insieme, servono alla domanda che decide tutte le altre: chi progetta, sviluppa e governa il futuro dei sistemi informativi dell’azienda? Non il singolo progetto: l’insieme - quali sistemi l’azienda avrà fra cinque anni, come si parleranno fra loro, che cosa si compra, che cosa si costruisce, che cosa si spegne.

Questo disegno ha un nome, l’architettura dei sistemi informativi, e nessun fornitore può possederlo, perché ognuno ne vede il pezzo che vende; e la sua assenza è fra le cause dei fallimenti che il GAO registra. Chi lo lascia al mercato si ritrova un’architettura fatta di cataloghi: coerente coi listini dei fornitori, non con la strategia dell’azienda. È il mestiere che contiene gli altri sette: ognuno produce le sue informazioni, questo le trasforma in una direzione.

Cinque domande per sapere se ce l’avete

Il test del lunedì mattina, per chi decide: se le risposte sono nomi e date, il governo c’è.

Per chi legge dal lato della direzione, il modo più rapido di usare questo pezzo è un test. Cinque domande, da fare lunedì mattina:

• il collaudo: chi ha firmato l’ultimo, con nome e cognome?
• l’aggiornamento: qual è la data del prossimo, e chi ha prenotato le verifiche?
• le interfacce: dov’è l’inventario, e chi risponde se stanotte un flusso si ferma?
• l’ultimo no: qual è l’ultima personalizzazione rifiutata, e con quale motivazione scritta?
• i dati: chi risponde, davanti alle norme, dei dati che il sistema tratta?

Se le risposte sono nomi, date e documenti, il governo della tecnologia c’è, comunque si chiami l’ufficio che lo esercita. Se sono silenzi, alzate di spalle o «il fornitore», questo pezzo era per voi.

Dove la serie li ha già incontrati

I sette mestieri attraversano i sei errori: la mappa dei rimandi.

Chi ha letto la serie li riconosce tutti. La conduzione e l’impegno del fornitore stanno nel pezzo sui test; il filtro dei conflitti e la catena della guida nel pezzo sulle persone; la copertura dei requisiti lega il pezzo sulla pianificazione al piano dei test; le interfacce attraversano il costo totale e la migrazione; le regole d’accesso del partner e il passaggio all’esercizio stanno nel pezzo sul go-live; gli aggiornamenti obbligatori e il costo di uscita nel pezzo sul costo totale. Questo approfondimento li ha solo riuniti sotto il loro proprietario: la regia interna, che c’era in ogni pezzo e adesso ha un nome su ogni mestiere.

I concetti che questo articolo introduce

Undici voci nuove sull’ambito ERP: il governo della tecnologia, i suoi strumenti e i suoi mestieri.

---

Fonti

• U.S. Government Accountability Office, Financial Management Systems: Additional Efforts Needed to Address Key Causes of Modernization Failures, GAO-06-184, marzo 2006 - il governo dell’informatica come terza famiglia di cause dei fallimenti (architetture, investimenti, sicurezza); nell’appendice sui processi disciplinati, la tracciabilità fra i documenti dei requisiti e le prove delle interfacce da un capo all’altro. Dall’appendice vengono anche, dichiarati lì con gli autori, i tre numeri classici ripresi nel pezzo: correggere un requisito all’inizio costa da 50 a 200 volte meno (Boehm e Papaccio, 1988); dal 40 al 60 per cento dei difetti risale ai requisiti (Leffingwell, 1997); il progetto medio spende circa l’80% del tempo in rilavorazioni non pianificate (McConnell). Sono citazioni di seconda mano attraverso il rapporto, che è la fonte letta qui.
• Rajiv D. Banker, Nan Hu, Paul A. Pavlou e Jerry Luftman, CIO Reporting Structure, Strategic Positioning, and Firm Performance, MIS Quarterly, 2011 - letto qui attraverso la scheda ufficiale con l’abstract, aperta (l’articolo completo è ad accesso chiuso): il riporto del CIO va allineato alla strategia - al vertice per chi si differenzia, alla finanza per chi compete sui costi - ed è il disallineamento a penalizzare i risultati.
• Microsoft, Shared responsibility in the cloud, documentazione ufficiale, aperta e consultata - qualunque sia il tipo di servizio cloud, il cliente conserva sempre la responsabilità dei dati (classificazione, protezione e conformità comprese), dei dispositivi, degli account e degli accessi.
• Michael Bloch, Sven Blumberg e Jürgen Laartz, Delivering large-scale IT projects on time, on budget, and on value, McKinsey, 2012, con il BT Centre for Major Programme Management dell’Università di Oxford - su oltre 5.400 progetti informatici: i progetti grandi sforano in media del 45% il bilancio e consegnano il 56% di valore in meno; il 17% minaccia l’esistenza stessa dell’azienda; fra le quattro dimensioni del rimedio, il governo di strategia e portatori d’interesse e i talenti critici vengono prima delle pratiche tecniche.
• Peter Weill e Jeanne W. Ross, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press - letto qui attraverso la scheda ufficiale del MIT CISR, aperta e consultata: le imprese con un governo dell’IT superiore hanno oltre il 25% di profitti in più a parità di obiettivi strategici, su uno studio di 250 imprese; il governo dell’IT come sistema di diritti di decisione.
• Microsoft, One Version service updates overview, documentazione ufficiale di Dynamics 365, aperta e consultata - gli aggiornamenti di servizio con finestra di manutenzione scelta dal cliente, i piani di rilascio noti fino a tre mesi prima, e il rinvio possibile per al massimo un aggiornamento consecutivo.
• I testi delle norme citate, nelle versioni ufficiali su EUR-Lex: regolamento (UE) 2016/679 (GDPR), direttiva (UE) 2022/2555 (NIS2), regolamento (UE) 2024/1689 (AI Act).
• L’aneddoto degli otto paesi, il filtro dei conflitti, le due misure dell’AMS e le regole pratiche di regia vengono dall’esperienza diretta di progetto di chi scrive, e come tali vanno letti.