Organizzazione, AI e digitale

81. Capability organizzativa — Una capacità che abita nell'organizzazione e non in una testa sola: distribuita su più persone (ridondanza), codificata quanto basta (procedure, checklist, casi), esercitata dentro riti istituzionali, mantenuta da un owner. È ciò che sopravvive al ricambio — e ciò che si vende, si scala e si eredita. In pratica: il test è la domanda "dove abita?" — se la risposta a "siamo forti in X" è un nome proprio, X è un talento in prestito, prezioso e fragile; la trasformazione da talento a capability è un progetto di 6–12 mesi, una capacità alla volta. → Capability organizzativa.

82. Conoscenza tacita — Il sapere che non si riesce a mettere per iscritto: il colpo d'occhio dell'esperto, la sensibilità sul cliente, il "sentire" che qualcosa non va. Si distingue dal sapere codificabile (che va in procedure) e si trasferisce solo per pratica affiancata su casi veri. In pratica: il mito della proceduralizzazione totale ha prodotto più archivi morti che capability — la strategia giusta è mista: codificare il codificabile ad alto rendimento, strutturare l'affiancamento per il tacito, con perimetri e traguardi invece di "stagli vicino e impara". → Capability organizzativa, Trasferimento di conoscenza (voce 83).

83. Trasferimento di conoscenza — Il processo con cui il sapere passa da chi lo possiede a chi dovrà usarlo: la combinazione di codifica (checklist, mappe dei rischi, casi commentati) e affiancamento strutturato, con responsabilità crescente e verifiche. In pratica: l'ostacolo tipico non è tecnico ma politico — al talento, insegnare erode l'indispensabilità; le aziende che riescono fanno il patto esplicito: la seniority si ridefinisce (e si paga) come capacità di generare capability, non di custodire sapere. → Capability organizzativa, Single point of failure (voce 62).

84. Margine cognitivo — Lo spazio mentale non consumato dall'operatività: la capacità residua di gestire l'eccezione, notare il segnale debole, imparare. È il buffer applicato all'attenzione — la risorsa più scarsa dell'organizzazione — e la sua erosione degrada prima le funzioni alte: giudizio, vigilanza, apprendimento. In pratica: un'organizzazione satura può solo ripetere ciò che già fa, sempre un po' peggio; e la manovra d'uscita è contro-intuitiva — ridurre il carico prima di chiedere miglioramento, perché ogni programma di cambiamento è banda aggiuntiva richiesta. → Margine cognitivo.

85. Debito organizzativo — L'accumulo di scorciatoie strutturali mai sistemate: ruoli sedimentati e mai ridisegnati, deleghe implicite, processi-tampone diventati organi, decisioni rimandate che vincolano quelle future. Come ogni debito, paga interessi quotidiani — attriti, lentezze, dipendenze — invisibili perché spalmati. In pratica: il debito organizzativo si contrae nei picchi e nelle crescite ("per ora facciamo così") e si ripaga solo deliberatamente; è ciò che un assessment strutturato quantifica come attrito per area — dare un numero al debito è il primo passo per deciderne il rientro. → Isteresi organizzativa, Debito di processo (voce 14).

86. Organizational design — La progettazione deliberata dell'organizzazione: come si raggruppano le attività, come si riportano le persone, dove stanno i diritti decisionali, come si coordinano le parti. Non coincide con l'organigramma: il disegno vero include i flussi, le deleghe e i meccanismi di coordinamento. In pratica: la sequenza corretta è processi e decisioni prima, scatole poi — riorganizzare l'organigramma sopra flussi confusi sposta la confusione di casella; e ogni disegno va collaudato sulle code: come si comporta nei giorni che non assomigliano agli altri? → Architettura decisionale, Span of control (voce 87).

87. Span of control — Il numero di persone che riportano direttamente a un capo. Non esiste il numero giusto universale: dipende da quanto il lavoro è standardizzato (più standard = span più ampio) e da quanta attenzione individuale serve. In pratica: lo span racconta la delega — il titolare con quindici riporti diretti non ha uno span ampio: ha quindici canali di escalation verso l'unico decisore; e lo span si allarga in salute solo costruendo deleghe e standard, non semplicemente togliendo caselle intermedie. → Decision rights, guida Come delegare decisioni.

88. Governance informale — Il sistema di regole non scritte che governa davvero: chi viene consultato anche se non è previsto, quali sì contano davvero, quali argomenti non si toccano, chi può dire no senza dirlo. Coesiste sempre con quella formale — e nei conflitti tra le due, vince quasi sempre l'informale. In pratica: la governance informale non si abolisce, si fa emergere — la rilevazione multi-ruolo la rende visibile (le decisioni passano davvero di lì?) — e le sue parti sane si formalizzano, quelle tossiche si smontano nominandole. → Governance, Triangolazione.

89. Cultura come processo — La lettura per cui la cultura aziendale non è un'essenza da predicare ma il risultato osservabile di ciò che l'organizzazione rende facile e costoso ogni giorno: l'ombra aggregata dei suoi dispositivi, riti e reazioni. Ne segue che la cultura non si cambia con i valori affissi: si cambia modificando i meccanismi che la generano. In pratica: chi vuole leggere la cultura vera di un'azienda non chieda i valori — guardi i dispositivi: cosa succede a chi porta una brutta notizia, quanto costa segnalare un difetto, cosa viene premiato davvero. → Microfondazioni.

90. Microfondazioni — I meccanismi di grana fine — comportamenti individuali, interazioni ricorrenti, dispositivi di situazione — che generano le proprietà visibili a livello aziendale ("siamo lenti", "qui la qualità cala"). Il principio: non si cambia una proprietà macro agendo al livello macro — si cambiano i meccanismi che la producono. In pratica: il test dell'osservabilità — la microfondazione è identificata quando si può andare a vederla accadere, in un luogo e un momento; "la mentalità" non passa il test, "il modulo di segnalazione da 15 minuti" sì. → Microfondazioni.

91. Adozione AI — Il percorso con cui l'azienda introduce strumenti di intelligenza artificiale nei propri flussi: dalla sperimentazione individuale non governata ("ognuno usa quello che vuole") all'uso deliberato — casi d'uso scelti, perimetri definiti, risultati misurati. In pratica: la domanda giusta non è "quanta AI usiamo?" ma "come è governata?" — quali decisioni tocca, chi ha deliberato le soglie, cosa succede quando sbaglia; e la sequenza vale come per ogni sistema: prima i processi leggibili e i dati decenti, poi l'accelerazione. → Collasso di latenza, Output di modello come input decisionale.

92. Automazione — La delega di un'attività o di una decisione a un sistema: dal riordino automatico al riprezzamento alla risposta al cliente. Ogni automazione è una delega a un non-umano e merita la stessa grammatica delle deleghe umane: perimetro, soglie, escalation, rendiconto — più una revisione periodica, perché l'automazione continua a eseguire con precisione anche un mondo che non c'è più. In pratica: lo strumento cardine è il registro delle automazioni — una pagina: cosa decide da solo il software, entro quali soglie, chi ne è owner, quando si rivede. → Collasso di latenza, Decision rights.

93. Readiness CRM/ERP — Il grado di prontezza dell'azienda a un sistema gestionale: processi in versione unica, responsabilità chiare sui punti di alimentazione, anagrafiche pulite con un owner, problemi definiti senza nominare il sistema. Il software codifica ciò che trova — accelera l'ordine, congela la confusione. In pratica: il test pre-firma in tre liste — verde (si parte), gialla (prerequisiti sistemabili in 60–90 giorni), rossa (cosa non implementare ancora, con il perché) — vale una frazione del prezzo del sistema e ne decide il destino. → guida Come capire se un ERP è prematuro.

94. Architettura dati — Il disegno di dove i dati nascono, chi li possiede, come si chiamano e come circolano tra i sistemi: quale fonte è quella "vera" per ogni informazione (il cliente, il prezzo, la giacenza), chi la alimenta, chi può usarla. In pratica: nelle PMI il sintomo tipico è la stessa informazione in tre posti con tre valori — e ogni report che inizia con "dipende da dove guardi" segnala un'architettura mai decisa; la cura parte dal designare, per ogni dato critico, una fonte unica e un owner. → Data quality (voce 79), guida Come capire se un ERP è prematuro.

95. Tech debt — Il debito tecnico: l'accumulo di soluzioni informatiche rapide e mai sistemate — il foglio Excel diventato gestionale, le personalizzazioni stratificate, l'integrazione tenuta insieme da una persona sola. Come ogni debito, si contrae in fretta e paga interessi per sempre: fragilità, lentezza dei cambiamenti, dipendenze. In pratica: il tech debt va inventariato come i rischi — dove sta, quanto costa al mese, cosa succede se cede — e il suo rientro va deciso, non sperato; ogni "per ora funziona" è una riga di quel registro. → Debito organizzativo (voce 85), Single point of failure (voce 62).

96. Collasso di latenza — Ciò che accade quando la tecnologia comprime il tempo di osservare (dati in tempo reale) e di eseguire (automazione) ma non quello di decidere, che resta umano: il giudizio diventa il punto dove tutto si accumula — o il passaggio che si salta. Accelerare senza governance non rende più veloci: rende più fragili, in scala. In pratica: i due sintomi da sorvegliare — l'accumulo (alert e dashboard che nessuno smaltisce) e il bypass non deliberato (il software che decide da solo perché così era configurato); la cura è posizionare il giudizio per eccezione, dentro soglie decise. → Collasso di latenza.

97. Digital transformation — La trasformazione dei modi di operare dell'azienda attraverso il digitale — che nella versione seria è trasformazione organizzativa abilitata dalla tecnologia, e nella versione fallimentare è acquisto di tecnologia sopra un'organizzazione immutata. In pratica: la parola d'ordine è sequenza — leggibilità dei processi, governance delle decisioni, qualità dei dati, poi gli strumenti; ogni progetto "digitale" che promette di mettere ordine sta invertendo la freccia causale, e il conto arriva in personalizzazioni e adozione mancata. → guida Come capire se un ERP è prematuro, Collasso di latenza.

98. Agentic workflow — Un flusso di lavoro in cui sistemi di AI (agenti) eseguono catene di azioni in autonomia: leggono, decidono passi intermedi, usano strumenti, producono risultati — con l'umano a monte (mandato) e a valle (verifica), non dentro ogni passaggio. In pratica: l'agente è un delegato non-umano con iniziativa, e alza la posta di tutte le regole dell'automazione: perimetro esplicito di ciò che può fare, soglie che fermano e chiamano, tracce complete di ciò che ha fatto (audit trail), e un owner che risponde della delega — perché la catena autonoma sbaglia in sequenza, più in fretta di quanto si controlli a mano. → Collasso di latenza, Output di modello come input decisionale, Audit trail (voce 80).

99. No-code e low-code governance — Il governo degli strumenti che permettono a chiunque di costruire applicazioni e automazioni senza programmare: moduli, flussi, integrazioni fatte dai reparti. Democratizzano la costruzione — e moltiplicano i sistemi clandestini: automazioni che nessuno censisce, dati duplicati, dipendenze da chi le ha fatte. In pratica: vietare è inutile e perdere il censimento è pericoloso; la via di mezzo è un registro leggero (cosa esiste, cosa tocca, chi ne risponde) e poche regole — quali dati si possono usare, quando serve una revisione — perché lo shadow IT non governato è tech debt che si scrive da solo. → Tech debt (voce 95), Automazione (voce 92).

100. Output di modello come input decisionale — Il principio che chiude il glossario: il risultato di un modello — previsione, scoring, testo generato — entra nel processo decisionale come input autorevole ma fallibile (con le sue assunzioni, il suo errore, il suo perimetro), non come comando. La promozione a comando è una decisione di governance esplicita, per categorie delimitate — mai uno scivolamento. In pratica: la carta d'identità dell'output (su cosa è costruito? quanto sbaglia, misurato da noi? chi risponde della decisione?) e la dissidenza protetta — contraddire il sistema dev'essere legittimo e tracciato, perché la configurazione pericolosa non è la macchina che sbaglia: è la macchina che sbaglia mentre tutti se n'erano accorti e nessuno aveva convenienza a dirlo. → Output di modello come input decisionale.