1. Introduzione

Chiedete a un reparto IT come sta andando e risponderà nella propria lingua: disponibilità a tre nove, il service desk entro i propri obiettivi, la migrazione secondo i piani, l’audit superato, la roadmap in linea. Chiedete alle persone che il reparto esiste per servire come sta andando l’IT e la risposta sarà in una lingua del tutto diversa: la cosa di cui avevano bisogno ha richiesto una settimana, il nuovo portale ha un passaggio in più rispetto a quello vecchio, il report da cui dipendono è un foglio di calcolo che tengono fuori dal sistema, e il modo più veloce per ottenere qualcosa è conoscere la persona giusta. Entrambe le risposte possono essere vere nello stesso momento, e quando lo sono il reparto ha una condizione che questo articolo nomina e analizza: si è rivolto verso l’interno e ha scambiato il proprio mondo per il mondo.

Prendiamo in prestito la parola solipsismo di proposito. In filosofia è la posizione secondo cui solo la propria mente esiste con certezza e tutto il resto è un’inferenza che potrebbe essere errata. Un’organizzazione non può letteralmente nutrire questa convinzione, ma può comportarsi come se lo facesse. Un reparto IT si comporta in modo solipsistico quando i propri artefatti — i sistemi che gestisce, le metriche che tiene, la roadmap che difende, l’architettura verso cui sta costruendo — diventano le cose che tratta come reali, e gli utenti, il lavoro e i risultati diventano un’inferenza che ricava dai propri strumenti, perlopiù dai ticket. L’inferenza è lacunosa, e il reparto non si accorge della perdita, perché gli strumenti continuano a segnare verde. Non è stupidità ed è raramente malafede. È la deriva naturale di qualsiasi gruppo che viene misurato sulla propria attività, isolato dalle persone che serve da uno strato di ticket e account manager, e premiato da una gerarchia che vede gli stessi numeri rivolti verso l’interno che vede lui.

Lo schema non è esclusivo dell’IT. È un fallimento riconosciuto delle organizzazioni in generale, talvolta chiamato solipsismo aziendale: un’azienda che agisce come se il proprio marchio, le proprie metriche e i propri obiettivi interni fossero il centro della vita dei suoi clienti, fuori contatto con le persone e le realtà al di fuori delle sue mura. La campagna di marketing che entusiasma il consiglio di amministrazione e muore sul mercato, la riorganizzazione che ottimizza l’organigramma e non il lavoro, l’ossessione per il controllo di alto livello su un’astrazione mentre il lavoro di base che tiene in piedi l’azienda viene ignorato, sono tutte la stessa svolta verso l’interno. Questo articolo traspone quello schema al reparto IT, dove assume forme caratteristiche proprie, propri strumenti di autoinganno e, come sosterremo, una propria cura.

Il contributo è un vocabolario e un piccolo modello, non una nuova teoria. Il vocabolario consiste in quattro manifestazioni (Sezione 3), ciascuna la forma IT di un originale aziendale. Il modello (Sezione 4) separa il valore che l’impresa realizza dal lavoro che il reparto conta, e mostra il meccanismo — la failure demand — con cui i due possono muoversi in direzioni opposte, cosicché il reparto appare più in salute sulle dashboard proprio dove serve peggio. Dal modello ricaviamo un insieme di indicatori di allarme precoce e le loro alternative rivolte verso l’esterno (Sezione 5). La domanda che l’articolo pone è dunque: come arriva un reparto IT a scambiare i propri strumenti per l’impresa che serve, come può accorgersene e come riorienta lo sguardo verso l’esterno?

L’articolo è scritto per la situazione olandese, che mostra lo schema con insolita chiarezza (Sezione 6). L’idea portante della governance IT olandese degli ultimi quindici anni — la regieorganisatie che separa un’organizzazione della domanda da una dell’offerta — istituzionalizza esattamente la distanza tra il reparto e il lavoro che alimenta la svolta verso l’interno; e un decennio di revisioni pubbliche, dall’inchiesta parlamentare sull’ICT all’organo di revisione permanente che ne è seguito, è in gran parte un resoconto di progetti IT pubblici che hanno servito la propria logica anziché quella del cittadino. La Sezione 7 ripercorre un caso costruito. Le Sezioni da 8 a 11 presentano la cura, rispondono alle obiezioni, enunciano i limiti e concludono.

2. Contesto e lavori correlati

2.1 Il solipsismo come metafora organizzativa

Che le organizzazioni perdano il contatto con il proprio esterno è un’osservazione antica, sotto molti nomi. Janis (1972) descrisse il groupthink, la tendenza di un gruppo coeso a convergere su una visione che ne preserva l’armonia interna a spese della verifica con la realtà. Beer (1979) costruì un’intera cibernetica del management sul principio che un’organizzazione è vitale solo se il suo modello interno del mondo viene corretto da canali che fanno entrare l’esterno, e fallisce quando quei canali si atrofizzano; il suo assioma secondo cui lo scopo di un sistema è ciò che fa, non ciò che dice di fare, è la diagnostica che questo articolo applica alle dashboard. Weick (1995) mostrò come le organizzazioni mettano in atto l’ambiente che poi danno per acquisito, cosicché un’unità rivolta verso l’interno non si limita a interpretare male il proprio mondo, ma in parte ne fabbrica le letture. Nessuno di questi autori scrisse di reparti IT, ma ciascuno descrisse il meccanismo per cui un gruppo arriva a vivere dentro il proprio racconto delle cose.

2.2 L’inside view e l’outside view

La descrizione più esatta dell’errore cognitivo si deve a Kahneman e Lovallo. L’inside view prevede l’esito di un progetto a partire dai dettagli del progetto stesso — il piano, il team, il diagramma di Gantt; l’outside view lo prevede a partire dallo storico di progetti simili, la maggior parte dei quali è andata in ritardo (Lovallo & Kahneman, 2003). L’inside view sembra più rigorosa perché è costruita su ciò che chi pianifica può vedere, ed è regolarmente sbagliata, perché ciò che chi pianifica può vedere è il meccanismo interno del reparto e non il tasso di base del mondo. Un reparto IT che pianifica, misura e rendiconta dall’inside view è solipsistico nel senso tecnico preciso: ragiona a partire dai propri contenuti e tratta l’esterno come un’inferenza. La cura che gli autori propongono — ancorarsi allo storico esterno — è la cura che questo articolo propone per le metriche.

2.3 Il valore così come l’utente lo sperimenta

Una letteratura parallela insiste sul fatto che il valore non viene creato da un fornitore e poi spedito, ma realizzato da un utente nell’uso. La service-dominant logic (Vargo & Lusch, 2004) lo afferma in generale: il fornitore può solo offrire una proposta di valore, e il valore è co-creato e determinato dal beneficiario nel proprio contesto. La tradizione dei jobs-to-be-done lo rende operativo: le persone non vogliono un prodotto, lo ingaggiano per fare progressi su un compito (job) che sorge nella loro vita, e l’unità di analisi è il job, non il prodotto (Christensen et al., 2016; Ulwick, 2005). Von Hippel (1986) mostrò che gli utenti all’avanguardia di un bisogno sono spesso una fonte migliore su cosa costruire rispetto alla pianificazione del fornitore stesso. La tradizione progettuale di Norman (2013) dice lo stesso dal lato dell’uso: un sistema dovrebbe essere modellato attorno agli obiettivi dell’utente e alla struttura del suo compito, e un sistema modellato attorno al modello che il fornitore ha di se stesso è il modo consueto di produrre qualcosa di inutilizzabile. Lette insieme, queste posizioni affermano che l’output di un reparto IT non sono i sistemi, ma il lavoro che quei sistemi permettono alle persone di fare, e che il reparto non può vedere quell’output dall’interno.

2.4 Il divario tra il piano e il lavoro

Infine, una tradizione nei sistemi informativi ha documentato, ripetutamente, che il sistema formale e il lavoro reale divergono, e che è nella divergenza che il valore vive o muore. Suchman (1987) mostrò che l’azione umana è situata, improvvisata a fronte delle particolarità del momento e governata solo in modo lasco dai piani che dovrebbero dirigerla, cosicché un sistema costruito a partire dal piano non si adatta al lavoro. Ciborra (2002) descrisse come i sistemi informativi reali derivino (drift) dalle intenzioni dei loro progettisti man mano che le persone li fanno funzionare attraverso bricolage e soluzioni di ripiego, e sostenne che la soluzione di ripiego è un dato sul disadattamento, non disobbedienza. Markus (1983) e Keen (1981) mostrarono che la resistenza degli utenti a un sistema è di solito una risposta razionale al modo in cui il sistema ridistribuisce fatica e potere, e quindi un segnale da leggere anziché un ostacolo da superare. Orlikowski (2000) riformulò la tecnologia come qualcosa che si costituisce nell’uso anziché incorporarsi nell’artefatto. La conclusione comune è che la verità di fondo di un sistema IT è nelle mani delle persone che lo usano, che è esattamente il luogo in cui un reparto solipsistico non guarda. I sistemi ombra che ne risultano — i fogli di calcolo e gli strumenti non autorizzati — sono diventati un proprio campo di studio (Haag & Eckhardt, 2017); li leggiamo nella Sezione 3 come il messaggio più chiaro che l’azienda invia sul disadattamento, e quello più spesso frainteso.

3. Quattro manifestazioni

Individuiamo quattro forme che la svolta verso l’interno assume in un reparto IT. Si sovrappongono e si rafforzano a vicenda, ma ciascuna ha un segnale distintivo, e nominarle separatamente consente a un reparto di capire quale ha. La Tabella 1 affianca a ciascuna il suo originale aziendale e il suo segno a livello di base.

3.1 L’illusione di centralità

La prima manifestazione è la convinzione che l’azienda pensi all’IT più o meno quanto l’IT pensa a se stesso. Il reparto ha un marchio ai propri occhi: un nome, un portale, un catalogo dei servizi, un insieme di valori appesi a una parete, una roadmap di cui va fiero. Immagina l’utente arrivare al portale con attenzione e intento, leggere l’annuncio, apprezzare la nuova funzionalità, interessarsi a quale release sia. L’utente non fa nulla di tutto ciò. L’utente è nel mezzo di una giornata che riguarda la chiusura di una vendita, la cura di un paziente, la prenotazione di una spedizione o una lezione a una classe, e il sistema è una cosa attraverso cui deve passare per andare avanti, idealmente senza accorgersene. La sua interazione con l’IT è breve, strumentale e malvolentieri, uno di decine di strumenti che si contendono una scheggia della sua attenzione, e il sentimento con cui vi si avvicina è nel migliore dei casi neutro e nel peggiore l’irritazione di un’interruzione.

L’illusione è costosa perché fissa l’obiettivo sbagliato. Un reparto che crede di occupare uno spazio nella mente dell’utente progetta per l’engagement: portali con notizie, dashboard per tutti, funzionalità che invitano all’esplorazione, notifiche che si annunciano. Un reparto che comprende di occupare un istante concesso malvolentieri progetta per la scomparsa: il minor numero di passaggi, i default più forti, il sistema che fa la cosa ovvia senza che glielo si chieda e poi si toglie di mezzo. I due costruiscono cose opposte, e solo il secondo serve un utente la cui attenzione è altrove. L’illusione di centralità è il motivo per cui così tanti strumenti interni sono progettati come destinazioni quando dovrebbero essere progettati come porte di passaggio.

3.2 La camera dell’eco interna

La seconda manifestazione è una governance che seleziona ciò che compiace il reparto anziché ciò che serve il lavoro. Un’idea — una nuova piattaforma, uno standard, un portale self-service, una riorganizzazione del supporto — nasce dentro l’IT e deve sopravvivere a una trafila di organi interni: un comitato di architettura, un change advisory board, un comitato direttivo, la riunione dello staff del CIO. Ciascun organo giudica l’idea in base a criteri interni — eleganza, standardizzazione, strategia di fornitura, ripartizione dei costi, controllo — e un’idea che lusinga quei criteri passa, raccogliendo sponsor man mano che sale. Quando raggiunge l’azienda è stata rifinita per mesi a fronte delle preferenze di persone che non la useranno mai, e incontra il lavoro per la prima volta al lancio, dove fallisce, non perché l’ingegneria fosse scadente ma perché nessun canale esterno è mai stato sul suo percorso. Il portale che nessuno ha chiesto, lo strumento self-service che genera più chiamate di quante ne eviti, la migrazione che ha risolto un problema dell’IT e ne ha creato uno all’azienda, sono tutti prodotti di un processo di revisione senza alcuna finestra sull’esterno.

La camera dell’eco è la forma IT della campagna fuori sintonia che entusiasma la sala del consiglio e muore sul mercato. La sua firma è che il fallimento sorprende. Un reparto le cui idee sono messe alla prova a fronte del lavoro si aspetta che alcune falliscano e impara a buon mercato; un reparto le cui idee sono messe alla prova a fronte di se stesso resta ripetutamente stupefatto, perché tutti coloro che ha consultato erano d’accordo. Il rimedio non sono comitati migliori ma un cancello diverso: un’idea dovrebbe incontrare un utente reale che svolge un lavoro reale prima di accumulare sponsor interni, non dopo, cosicché l’esterno possa ucciderla mentre ucciderla costa ancora poco.

3.3 Il distacco dall’astrazione

La terza manifestazione è l’attenzione che la dirigenza riserva al controllo e all’astrazione di alto livello a scapito del lavoro di base che tiene in piedi l’impresa. La conversazione ai vertici verte sull’architettura di destinazione, sulla single source of truth, sulla piattaforma, sulla postura cloud, sulla strategia dei dati, sul single pane of glass — astrazioni che sono attraenti proprio perché promettono il controllo dall’alto senza contatto con il disordine di sotto. Nel frattempo l’impresa di fatto funziona su un substrato che l’astrazione non modella: il batch notturno che una sola persona comprende, la riconciliazione che qualcuno fa a mano ogni mese, l’integrazione tenuta insieme da un export schedulato, la conoscenza tribale di quale sistema fidarsi quando due sono in disaccordo. Questo lavoro è invisibile dall’alto perché non compare nel diagramma dell’architettura, e un reparto in balìa dell’astrazione tratta il diagramma come se fosse il territorio.

Il distacco è pericoloso esattamente nei momenti in cui l’astrazione dovrebbe aiutare. Un consolidamento su un’unica piattaforma, pianificato a partire dal diagramma, scopre troppo tardi che il sistema dismesso era portante in un modo che nessun diagramma mostrava, perché il suo ruolo reale viveva in una soluzione di ripiego. La mappa ometteva il ponte che il traffico usava davvero. L’enterprise architecture come disciplina non è il problema; il problema è l’architettura praticata come un atto rivolto verso l’interno, che disegna il sistema che il reparto vorrebbe gestire anziché scoprire il sistema che gestisce. La cura è etnografica prima che architettonica: andare a osservare il lavoro, trovare le riconciliazioni fatte a mano e i fogli di calcolo portanti, e trattarli come la specifica di ciò che la piattaforma non deve rompere.

3.4 La lente rivolta verso l’interno

La quarta manifestazione sta alla base delle altre tre: l’abitudine di guardare tutto attraverso metriche che descrivono l’operato del reparto stesso anziché il risultato per l’utente. Disponibilità, tempo medio di risoluzione, ticket chiusi, tasso di successo dei change, milestone di progetto raggiunte, aderenza al budget, rilievi di audit chiusi — questi sono gli strumenti appesi alla parete, e ognuno di essi misura qualcosa che accade dentro l’IT. Nessuno di essi misura se una persona sia stata in grado di svolgere il proprio lavoro, quanto sia durato davvero il suo compito dall’inizio alla fine, quanta parte del suo sforzo sia andata a combattere gli strumenti, o se la cosa di cui aveva bisogno esista affatto. La lente punta verso l’interno, e ciò che non può vedere non può gestirlo.

La lente rivolta verso l’interno non è soltanto incompleta; è attivamente fuorviante, perché le metriche interne possono essere ottimizzate in modi che danneggiano il risultato esterno. Un service desk misurato sui ticket chiusi e sul tempo di chiusura impara a chiudere ticket, che non è la stessa cosa che risolvere problemi; una chiusura rapida e superficiale che non risolve la questione di fondo produce un secondo ticket, e il reparto che conta entrambi come throughput vede produttività dove l’utente vede un problema che ha richiesto due chiamate. Questo è il meccanismo che la prossima sezione modella, ed è la ragione per cui un reparto può essere verde su ogni dashboard mentre l’impresa che serve non lo è. La progettazione centrata sull’utente è, in fondo, l’istruzione di capovolgere questa lente: partire dall’obiettivo dell’utente e guardare indietro verso l’IT, anziché partire dall’operato dell’IT e inferire l’utente.

4. Un modello minimo: il divario del solipsismo

Le quattro manifestazioni condividono una conseguenza misurabile: un divario tra ciò che il reparto conta e ciò che l’impresa realizza. Questa sezione presenta un piccolo modello di quel divario, quanto basta per mostrare perché i due possano divergere e perché la divergenza si autoalimenti. Il modello è uno schizzo pensato per rendere esplicito il meccanismo, non una calibrazione.

4.1 Due tipi di domanda

Seguendo la tradizione del service management, dividiamo il lavoro che arriva a un reparto IT in due tipi (Seddon, 2008). La value demand è lavoro che l’azienda vuole davvero sia fatto: una nuova capacità, un cambiamento reale, una domanda che necessita di risposta. La failure demand è lavoro creato dal precedente fallimento del reparto stesso nel fare qualcosa, o nel farlo bene: l’utente che richiama perché la prima soluzione non ha tenuto, la richiesta di una soluzione di ripiego per un sistema che non avrebbe dovuto averne bisogno, il ticket riaperto, la seconda visita. Sia la domanda totale in un periodo

e definiamo il rapporto di solipsismo come la quota del lavoro del reparto che riguarda i propri fallimenti precedenti,

Il rapporto è ben denominato. Un reparto con un $\sigma$ elevato spende gran parte del proprio sforzo nel rispondere alle conseguenze del proprio lavoro — un letterale ripiegamento verso l’interno dell’attività — eppure ogni unità di quello sforzo compare nelle metriche interne come un ticket gestito e un problema chiuso.

4.2 Perché i numeri e il valore divergono

Sia l’output misurato del reparto — la quantità che la lente interna riporta — il lavoro totale che esso processa, che in prima approssimazione è tutto $D$: ogni ticket chiuso, di valore o di fallimento, conta. Sia il valore realizzato — la quantità che l’impresa sperimenta — la value demand effettivamente soddisfatta, al netto dell’attrito che i fallimenti impongono, cosicché cala al crescere di $\sigma$. Scrivendo $M$ per l’output misurato e $V$ per il valore realizzato come funzioni del throughput $T$ del reparto e del rapporto $\sigma$,

dove $q \in (0,1]$ è quanto bene il lavoro erogato si adatta al job effettivo dell’utente, la quantità che le manifestazioni della Sezione 3 degradano. Il divario tra ciò che è contato e ciò che è realizzato,

cresce con il throughput, con il rapporto di fallimento e con il disadattamento. Il reparto può aumentare $M$ aumentando $T$ — lavorando di più, chiudendo più in fretta — mentre $V$ resta piatto o cala, e le dashboard mostreranno lo sforzo come progresso. La Figura 1 traccia le due quantità al crescere dell’orientamento verso l’interno: la performance misurata sale mentre il valore realizzato declina, una coppia di lame che si incrociano nel punto in cui il reparto appare più in salute proprio mentre comincia a servire peggio.

4.3 Perché si autoalimenta

Il divario sarebbe soltanto un problema di misurazione se $\sigma$ fosse fisso. Non lo è, perché ottimizzare la metrica interna lo alimenta. La pressione a chiudere i ticket più in fretta abbassa l’adattamento $q$ di ogni chiusura e aumenta la probabilità che il problema di fondo ritorni come failure demand, cosicché il $\sigma$ del periodo successivo è più alto. Sia lo sforzo di ottimizzazione interna $e$, l’attenzione che il reparto riserva alle proprie metriche, e sia l’ascolto verso l’esterno, l’attenzione che riserva al lavoro, $\ell$. Un semplice aggiustamento cattura il ciclo:

con $\alpha,\beta>0$. Quando la pressione interna domina ($\alpha e > \beta \ell$) il rapporto sale a un punto fisso elevato: uno stato stabile e autosostenuto in cui il reparto è permanentemente occupato con se stesso, permanentemente verde sui propri strumenti e permanentemente alla deriva rispetto al lavoro. Quel punto fisso è il solipsismo organizzativo come stato stazionario, e l’unico parametro che sposta il reparto da esso è $\ell$, l’attenzione che riserva all’esterno. Ogni manifestazione della Sezione 3 è un modo di mantenere $\ell$ vicino a zero.

5. Indicatori di allarme precoce

Il modello dice che un reparto non può accorgersi di rivolgersi verso l’interno a partire dalle proprie metriche interne, per costruzione. Può accorgersene a partire da un secondo insieme di indicatori, ciascuno dei quali affianca un segnale interno che appare in salute alla realtà esterna che nasconde e alla misura esterna che la rivelerebbe. La Tabella 2 li raccoglie. Gli indicatori sono diagnostici, non meramente retorici: ciascuno nomina un numero che il reparto potrebbe iniziare a raccogliere domani, e l’atto stesso di raccoglierlo è la prima rotazione della lente.

Tre di essi meritano una parola. Il primo è la failure demand come quota del volume: la maggior parte dei reparti misura il volume dei ticket e si rallegra quando riesce a gestirlo, ma non lo scompone, e la scomposizione è il singolo numero più rivelatore che un service desk possa tenere, perché una quota crescente significa che il reparto è sempre più occupato con se stesso. Il secondo è il censimento dello shadow IT: un reparto solipsistico tratta il foglio di calcolo mantenuto fuori dal sistema autorizzato come un problema di conformità da estirpare, quando invece è un messaggio preciso su dove il sistema autorizzato non si adatta al lavoro; contare i sistemi ombra e leggerli come specifiche trasforma una minaccia nella migliore ricerca gratuita che il reparto otterrà mai. Il terzo è il time-to-task, non il time-to-ticket: il reparto misura quanto velocemente chiude i propri record, ma l’utente misura quanto è durato l’intero lavoro, comprese le parti prima che un ticket fosse aperto e dopo che è stato chiuso, e solo il tempo dall’inizio alla fine è la cosa che l’utente sente davvero.

6. La situazione olandese

Lo schema è generale, ma il contesto olandese gli conferisce una forma insolitamente chiara, per due ragioni istituzionali e una di mercato.

6.1 La regieorganisatie e la distanza che crea

L’idea dominante nella governance IT olandese degli ultimi quindici anni è stata la regieorganisatie: una deliberata separazione di un’organizzazione della domanda, che possiede la relazione con l’azienda e decide ciò che si vuole, da un’organizzazione dell’offerta, spesso un fornitore esterno, che lo costruisce e lo gestisce. La separazione ha virtù reali, e non siamo contrari a essa. Ma istituzionalizza esattamente la distanza che alimenta la svolta verso l’interno. Il lato della domanda arriva a misurarsi sulla gestione dei fornitori — contratti rispettati, livelli di servizio rendicontati, riunioni di governance tenute — e il lato dell’offerta sull’erogazione dei servizi come specificati, entrambe attività rivolte verso l’interno, mentre il lavoro effettivo dell’utente si colloca al di là di entrambi, raggiunto solo attraverso la documentazione che passa tra loro. Una regieorganisatie che non è deliberatamente connessa al lavoro misura la relazione tra due organizzazioni IT e la chiama performance. La cura della Sezione 8 si applica con particolare forza qui: il vero compito dell’organizzazione della domanda è far entrare l’esterno, e se si misura sulla governance dei fornitori è diventata silenziosamente la cosa che doveva prevenire.

6.2 Un decennio di revisioni pubbliche

Lo Stato olandese ha tenuto un resoconto insolitamente pubblico dell’IT rivolta verso l’interno. L’inchiesta parlamentare sui progetti ICT del governo (Tweede Kamer, 2014) riscontrò uno schema di grandi progetti trainati dal proprio slancio e dalla propria logica interna, insufficientemente ancorati al problema che dovevano risolvere o alle persone che ne avrebbero usato il risultato, e raccomandò un organo permanente per mettere alla prova i progetti a fronte della realtà prima e durante la costruzione. Quell’organo, oggi l’Adviescollege ICT-toetsing, esiste proprio perché l’inside view non si autocorregge: un canale esterno di esperti deve essere costruito e finanziato, perché i reparti lasciati ai propri strumenti non ne acquisiscono uno. La lezione si generalizza oltre il governo. La ragione per cui la cura di questo articolo è istituzionale — un cancello, un censimento, una misura — anziché un’esortazione a prendersi cura degli utenti, è che prendersi cura non è l’input scarso; l’input scarso è un canale che fa entrare l’esterno che il reparto lo voglia o no.

6.3 La relazione di managed services

Nel mid-market olandese, dove noi di Nashua lavoriamo, la maggior parte delle organizzazioni non gestisce affatto un grande reparto IT interno; si affida a un fornitore di managed services. Questo cambia la forma del rischio ma non la sua natura. Un fornitore è misurato sui propri livelli di servizio e sul proprio contratto, che sono metriche interne al mondo del fornitore, e un fornitore che si attiene solo a quelle può riferire una relazione in salute mentre il personale del suo cliente aggira i sistemi. La disciplina verso l’esterno che un buon fornitore deve al proprio cliente è la stessa che un reparto interno deve alla propria azienda: misurare il completamento dei compiti del cliente e non solo l’uptime del fornitore, leggere le soluzioni di ripiego del cliente come specifiche, e contare la quota del proprio lavoro che è failure demand. Un fornitore che fa questo trasforma la distanza della relazione da passività in vantaggio, perché vede il lavoro di molti clienti e può portare l’outside view tra loro. Un fornitore che non lo fa diventa un reparto IT solipsistico a distanza, con un contratto al posto di una coscienza.

7. Un caso costruito

Il caso seguente è costruito, non osservato. Esiste per mostrare le manifestazioni e il modello in un unico contesto; le sue cifre sono illustrative. Descrive un’organizzazione olandese di medie dimensioni con un reparto IT interno di circa quaranta persone al servizio di all’incirca mille dipendenti tra operations, vendite e finanza.

Sui propri strumenti il reparto vive il suo anno migliore. La disponibilità sui sistemi core è del 99.9 per cento. Il service desk chiude l’ottantacinque per cento dei ticket entro l’obiettivo, e il volume totale è salito del dodici per cento, che il report trimestrale presenta come produttività in crescita. Il consolidamento pluriennale della piattaforma è in linea: tre sistemi legacy dismessi, tutto in migrazione verso l’unica suite. Il sondaggio annuale di soddisfazione sull’IT restituisce un punteggio rispettabile. Ogni slide è verde, e la dirigenza del reparto, leggendo fedelmente i propri strumenti, crede di andare bene.

Sotto ogni numero verde c’è una realtà non verde che gli strumenti non trasmettono. L’aumento del dodici per cento nel volume dei ticket è perlopiù failure demand: la nuova release della suite ha cambiato una schermata che il team vendite usava cinquanta volte al giorno, e la confusione che ne è derivata genera un flusso costante di ticket, ciascuno chiuso rapidamente e bene secondo i parametri del desk, nessuno dei quali tocca la causa. La disponibilità è misurata per sistema, ma il compito order-to-cash ora attraversa tre sistemi e due passaggi di consegne, e il tempo trascorso per il compito è cresciuto da ore a due giorni, un numero che nessuna dashboard mostra perché nessuna dashboard misura il compito. Il consolidamento ha dismesso un vecchio strumento di reporting il cui ruolo reale, non documentato, era un export notturno da cui dipendeva la riconciliazione di fine mese del team finanza; la finanza lo ha ricostruito come un foglio di calcolo mantenuto da un solo analista, che il reparto, quando se ne accorge, registra come shadow IT da eliminare. Il sondaggio di soddisfazione ha ottenuto un buon punteggio perché chiedeva se il service desk fosse cortese e se i sistemi fossero disponibili, e non se qualcuno fosse riuscito a svolgere il proprio lavoro.

Il reparto è, per la definizione di questo articolo, solipsistico, e la cosa sorprendente è che nessuno al suo interno sta facendo un cattivo lavoro. Il desk è davvero rapido e cortese. Gli ingegneri hanno davvero realizzato il consolidamento. L’architettura è davvero più pulita. Ogni persona sta ottimizzando la metrica che ha davanti, e ogni metrica punta verso l’interno, cosicché la somma di un lavoro competente e ben intenzionato è un reparto che ha voltato le spalle all’azienda credendo di esserle di fronte. Il modello della Sezione 4 nomina lo stato con precisione: il throughput $T$ è salito, il rapporto $\sigma$ sta crescendo, l’output misurato $M$ sale con il throughput mentre il valore realizzato $V$ cala con $\sigma$, e i due strumenti che al reparto mancano — la failure demand come quota del volume e il time-to-task — sono esattamente i due che glielo avrebbero mostrato.

8. Riorientare lo sguardo verso l’esterno

La cura non è prendersi più cura. Le persone del caso costruito già si prendono cura, e il prendersi cura instradato attraverso strumenti interni produce lavoro interno. La cura è costruire canali che facciano entrare l’esterno che qualcuno si ricordi o meno di guardare, e cambiare ciò che si misura affinché l’ottimizzazione stessa del reparto lo tiri verso il lavoro anziché allontanarlo. Dal modello e dalle manifestazioni discendono cinque mosse.

Misurare il compito, non il ticket. Aggiungere almeno una misura di risultato a ogni misura interna: il time-to-task accanto al tempo di risoluzione, il completamento del compito accanto alla disponibilità, l’adozione accanto alle funzionalità rilasciate. Il punto non è scartare le metriche interne, che sono utili per far funzionare l’operatività, ma negare loro il monopolio sull’attenzione che lascia aprire inosservato il divario della Sezione 4.

Scomporre e monitorare la failure demand. Classificare il lavoro in arrivo come value demand o failure demand e monitorare il rapporto $\sigma$ nel tempo. È la diagnostica meno costosa di questo articolo e la lettura più diretta della svolta verso l’interno, perché misura quanta parte dello sforzo del reparto è una reazione a se stesso.

Leggere lo shadow IT come specifica. Tenere un censimento dei fogli di calcolo e degli strumenti non autorizzati, e trattare ciascuno come un’esposizione precisa di dove i sistemi autorizzati non si adattano al lavoro. La soluzione di ripiego è l’azienda che scrive requisiti nell’unica lingua che le è rimasta; un reparto che la estirpa sta distruggendo la propria migliore ricerca.

Mettere un utente sul percorso prima degli sponsor. Cambiare il cancello di governance in modo che un’idea incontri presto un utente reale che svolge un lavoro reale, mentre ucciderla costa poco, anziché dopo che ha scalato la gerarchia interna e accumulato sponsor. Questo è il rimedio strutturale per la camera dell’eco: inserisce un canale esterno a monte di quelli interni.

Andare a osservare il lavoro. Prima di ogni consolidamento o dismissione, mandare qualcuno a osservare il lavoro di base che l’astrazione non modella, e a trovare le riconciliazioni fatte a mano e i fogli di calcolo portanti. Trattare ciò che trova come la specifica di ciò che la nuova piattaforma non deve rompere. Questo è il rimedio strutturale per il distacco dall’astrazione, ed è etnografico prima che architettonico.

Nessuna di queste mosse è costosa, ed è questo il punto. Il solipsismo organizzativo non si cura con un budget o una riorganizzazione; si cura con una manciata di canali esterni deliberatamente costruiti e tenuti aperti, perché la tendenza naturale di un gruppo isolato e misurato verso l’interno è di chiuderli.

9. Obiezioni e risposte

Le metriche interne contano; non si può far funzionare un’operatività senza di esse. D’accordo, e l’articolo non dice il contrario. La disponibilità e il tempo di risoluzione sono necessari per far funzionare il servizio. L’affermazione è più ristretta e più netta: non sono sufficienti, descrivono il mondo del reparto e non quello dell’utente, e quando sono gli unici strumenti appesi alla parete lasciano aprire inosservato il divario. Il rimedio è un’aggiunta, non una sostituzione.

Gli utenti non sanno cosa vogliono, quindi la centratura sull’utente è una strada verso il caos. La tradizione dei jobs-to-be-done risponde a questo con precisione: gli utenti sono pessimi nello specificare soluzioni ed eccellenti nell’esibire i propri job. L’istruzione non è chiedere agli utenti di progettare il sistema, ma osservare il lavoro, leggere le soluzioni di ripiego e misurare il risultato, nulla di cui richiede che l’utente conosca la risposta, solo che venga osservato mentre svolge il compito.

Questa è solo progettazione centrata sull’utente con una nuova etichetta. In parte, deliberatamente. Il contributo non è un nuovo metodo ma una diagnosi del perché un reparto dotato dei metodi si rivolga comunque verso l’interno, ossia che la sua misurazione e la sua governance puntano entrambe verso l’interno e si rafforzano a vicenda, e un piccolo modello di come ciò produca un divario invisibile dall’interno. L’etichetta nomina la modalità di fallimento affinché un reparto possa riconoscerla in se stesso.

Un fornitore di managed services è strutturalmente esterno all’azienda; questo non si applica. Si applica con più forza, non meno. La distanza è la condizione che alimenta la svolta verso l’interno, e un fornitore misurato sul proprio contratto è capace di solipsismo quanto qualsiasi reparto interno, come sostiene la Sezione 6. Il vantaggio del fornitore è che vede molti clienti e può portare l’outside view tra loro, ma solo se sceglie di misurare il lavoro del cliente anziché i propri livelli di servizio.

10. Limiti e agenda di ricerca

Si tratta di un’analisi rivolta ai professionisti, e i suoi limiti vanno enunciati. Il modello della Sezione 4 è uno schizzo: le sue quantità sono definite in modo abbastanza chiaro da essere misurate, ma le sue forme funzionali sono illustrative, scelte per rendere visibile il meccanismo anziché stimate dai dati. Le quattro manifestazioni sono una tipologia, utile se aiuta un reparto a trovare la propria modalità di fallimento, ma non una partizione dimostrata esaustiva. La lettura olandese è interpretativa. Il caso costruito è costruito.

Le affermazioni sono nondimeno verificabili, e gli indicatori esterni sono gli strumenti con cui verificarle. Quattro studi basterebbero. Primo, misurare il rapporto di solipsismo $\sigma$ in un insieme di reparti e correlarlo con una misura indipendente del valore realizzato dall’azienda; il modello prevede una relazione negativa che le metriche interne non mostrano. Secondo, seguire $\sigma$ e le metriche interne attraverso un periodo di pressione sulle metriche interne; il modello prevede che $\sigma$ salga man mano che i numeri interni migliorano. Terzo, strumentare il time-to-task accanto al tempo di risoluzione lungo un servizio reale e misurare il divario tra i due. Quarto, condurre il cambiamento di governance — un utente sul percorso prima degli sponsor — come intervento controllato e misurare il tasso di fallimento al lancio a fronte del cancello attuale. Ogni studio necessita solo di misure che l’articolo già nomina, e ciascuno sposterebbe l’argomentazione dall’analisi all’evidenza.

11. Conclusione

Un reparto IT si rivolge verso l’interno non per incompetenza o indifferenza, ma attraverso l’ordinario operare dell’essere misurato sulla propria attività, isolato dal lavoro da uno strato di ticket e contratti, e premiato da una gerarchia che legge gli stessi strumenti rivolti verso l’interno che legge lui. Il risultato è un reparto che scambia i propri sistemi, le proprie metriche, la propria roadmap e la propria architettura per il centro dell’impresa e gli utenti per un’inferenza che ricava dai ticket — una versione organizzativa della convinzione che solo la propria mente esista con certezza. Abbiamo nominato quattro manifestazioni — l’illusione di centralità, la camera dell’eco interna, il distacco dall’astrazione e la lente rivolta verso l’interno — e mostrato con un piccolo modello come la failure demand consenta all’output misurato del reparto di salire mentre il valore che l’impresa realizza cala, cosicché le dashboard appaiono più in salute proprio dove il servizio è peggiore.

La cura non è esortazione ma idraulica: una manciata di canali esterni deliberatamente costruiti e tenuti aperti, perché la tendenza naturale di un gruppo isolato e misurato verso l’interno è di lasciarli chiudere. Misurare il compito e non solo il ticket. Scomporre e monitorare la failure demand. Leggere lo shadow IT come una specifica. Mettere un utente sul percorso prima degli sponsor. Andare a osservare il lavoro. Ciascuna è poco costosa, ciascuna fa entrare un pezzo dell’esterno, e insieme riorientano la lente, cosicché un reparto si misura in base al fatto che l’impresa che serve riesca a svolgere il proprio lavoro, che è l’unica misura che sia mai stata reale.

Appendice A. Misurare il divario del solipsismo

Il divario della Sezione 4 può essere approssimato a partire da dati che la maggior parte delle operatività di servizio già possiede, più due misure che di solito non possiede. Tutte possono essere raccolte trimestralmente senza un sondaggio.

Quota di failure demand $\sigma$. Per un campione rappresentativo di elementi chiusi, classificare ciascuno come value demand (un bisogno nuovo e genuino) o failure demand (lavoro causato da un precedente fallimento nel fare o nel fare bene), mediante una breve regola di codifica applicata alla chiusura o su un campione retrospettivo. La quota di failure demand è $\sigma$. Insidia: la codifica alla chiusura da parte dello stesso agente che ha chiuso l’elemento la sottostima; usare un campione indipendente.

Adattamento $q$. Approssimare l’adattamento con il complemento del tasso di riapertura e rilavorazione: la frazione di elementi di value demand che sono completati senza un successivo elemento correlato entro una finestra definita. Insidia: una finestra breve lusinga $q$; impostarla sul ciclo dell’utente, non su quello del desk.

Time-to-task. Per un piccolo insieme di percorsi utente rappresentativi, misurare il tempo trascorso per l’intero percorso, dal momento in cui l’utente ha bisogno del risultato al momento in cui lo ottiene, attraverso ogni sistema e passaggio di consegne, indipendentemente dai confini dei ticket. Insidia: misurare dal primo ticket all’ultima chiusura tralascia le parti del compito che non sono mai diventate un ticket, che spesso sono le più lunghe.

Il divario. Con $M$ gli elementi totali processati e $V = M(1-\sigma)q$, il divario del solipsismo è $G = M - V$. Riportato come rapporto $G/M = 1-(1-\sigma)q$, è comparabile tra reparti e nel tempo, e sale quando aumenta la failure demand o il disadattamento, che sono le due cose che le metriche interne nascondono.

Appendice B. Una checklist diagnostica

Le domande seguenti sono raggruppate per manifestazione. Un sì è un sintomo, non un verdetto; diverse risposte affermative in uno stesso gruppo individuano la modalità di fallimento, e il test esterno nell’ultima colonna è la misurazione che la confermerebbe o la respingerebbe. La checklist è deliberatamente rispondibile in un pomeriggio, perché una diagnosi che richiede un progetto non verrà eseguita.

Bibliografia

Beer, S. (1979). The heart of enterprise. John Wiley & Sons. ISBN 978-0-471-27599-1.

Brynjolfsson, E. (1993). The productivity paradox of information technology. Communications of the ACM, 36(12), 66–77. https://doi.org/10.1145/163298.163309

Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Know your customers’ “jobs to be done.” Harvard Business Review, 94(9), 54–62. https://hbr.org/2016/09/know-your-customers-jobs-to-be-done

Ciborra, C. (2002). The labyrinths of information: Challenging the wisdom of systems. Oxford University Press. ISBN 978-0-19-924152-7.

Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319–340. https://doi.org/10.2307/249008

DeLone, W. H., & McLean, E. R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9–30. https://doi.org/10.1080/07421222.2003.11045748

Haag, S., & Eckhardt, A. (2017). Shadow IT. Business & Information Systems Engineering, 59(6), 469–473. https://doi.org/10.1007/s12599-017-0497-x

Henderson, J. C., & Venkatraman, N. (1999). Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, 38(2&3), 472–484. https://doi.org/10.1147/sj.382.0472

Janis, I. L. (1972). Victims of groupthink: A psychological study of foreign-policy decisions and fiascoes. Houghton Mifflin.

Keen, P. G. W. (1981). Information systems and organizational change. Communications of the ACM, 24(1), 24–33. https://doi.org/10.1145/358527.358543

Lovallo, D., & Kahneman, D. (2003). Delusions of success: How optimism undermines executives’ decisions. Harvard Business Review, 81(7), 56–63. https://hbr.org/2003/07/delusions-of-success-how-optimism-undermines-executives-decisions

Markus, M. L. (1983). Power, politics, and MIS implementation. Communications of the ACM, 26(6), 430–444. https://doi.org/10.1145/358141.358148

Norman, D. A. (2013). The design of everyday things (Revised and expanded ed.). Basic Books. ISBN 978-0-465-05065-9.

Orlikowski, W. J. (2000). Using technology and constituting structures: A practice lens for studying technology in organizations. Organization Science, 11(4), 404–428. https://doi.org/10.1287/orsc.11.4.404.14600

Seddon, J. (2008). Systems thinking in the public sector: The failure of the reform regime and a manifesto for a better way. Triarchy Press.

Suchman, L. A. (1987). Plans and situated actions: The problem of human–machine communication. Cambridge University Press. ISBN 978-0-521-33739-7.

Tweede Kamer der Staten-Generaal (2014). Naar grip op ICT: Parlementair onderzoek naar ICT-projecten bij de overheid. Eindrapport van de Tijdelijke commissie ICT-projecten bij de overheid (Commissie Elias). Kamerstukken II 2014/15, 33 326, nr. 5. https://zoek.officielebekendmakingen.nl/kst-33326-5.html

Ulwick, A. W. (2005). What customers want: Using outcome-driven innovation to create breakthrough products and services. McGraw-Hill. ISBN 978-0-07-140867-7.

Vargo, S. L., & Lusch, R. F. (2004). Evolving to a new dominant logic for marketing. Journal of Marketing, 68(1), 1–17. https://doi.org/10.1509/jmkg.68.1.1.24036

von Hippel, E. (1986). Lead users: A source of novel product concepts. Management Science, 32(7), 791–805. https://doi.org/10.1287/mnsc.32.7.791

Weick, K. E. (1995). Sensemaking in organizations. Sage Publications. ISBN 978-0-8039-7177-6.