Indice
Nella maggior parte delle aziende l’IT viene ancora chiamato solo quando il palazzo è già in fiamme.
Un utente non riesce a stampare, il CRM è giù, la VPN non risponde, un server si pianta nel mezzo di una chiusura contabile. Parte il ticket, parte la telefonata, parte la mail in caps lock: “È urgente”. Il team IT corre, spegne l’ennesimo incendio, rimette in piedi il sistema e passa al prossimo problema.
Questa è la normalità in tante organizzazioni. Ma è una normalità tossica.
Per il business, perché il costo di questa modalità di lavoro resta in gran parte invisibile.
Per i team IT, perché li condanna a un mestiere fatto solo di reazioni e pressione continua.
Nella conversazione con Enrico Maccarone di NinjaOne, che ho ospitato al CTO Show, abbiamo messo a fuoco cosa significa passare da questo modello reattivo a una gestione proattiva dell’IT basata su monitoraggio e automazione. In questo articolo vado oltre l’intervista e ragiono su cosa implica davvero questo cambio di paradigma per chi guida tecnologia e operations.
Dal modello “ticket-driven” al modello “visibility-driven”
L’IT reattivo è semplice da descrivere: ci si muove solo quando qualcuno segnala un problema.
Un utente non può lavorare → apre un ticket o chiama il supporto → l’IT indaga → trova la causa → applica una correzione manuale → chiude il ticket. È un modello interamente costruito su esperienze negative: qualcuno è già fermo, il danno è già in corso, il costo è già in maturazione.
Questo schema presenta diversi problemi strutturali:
- La priorità la decide il rumore, non l’impatto sul business. Chi urla di più passa davanti.
- L’IT lavora “a strappi”, inseguendo emergenze, senza il tempo di ragionare su prevenzione e strategia.
- L’azienda vede l’IT come un centro costi di supporto, non come una leva per ridurre rischi e aumentare produttività.
Il modello proattivo ribalta la logica:
la domanda non è più “che problema devo risolvere oggi?”, ma “che cosa sta succedendo davvero alla mia infrastruttura e cosa posso prevenire prima che diventi un problema?”.
Questo approccio si regge su un pilastro: visibilità centralizzata.
Parliamo di sapere in ogni momento:
- quali endpoint, server e dispositivi di rete esistono nella rete aziendale
- in che stato sono (performance, errori, saturazioni, spazio disco, patch…)
- quali software girano su quali macchine
- quali metriche stanno andando oltre soglia prima che l’utente se ne accorga
Senza questa visibilità, l’IT resta cieco e condannato alla reattività.
Con questa visibilità, cambia tutto: non aspetti che sia l’utente a segnalare il problema, sei tu il primo a vederlo.
Il costo del downtime (e del ritardo decisionale) è un tema di business, non di IT
Nell’episodio citiamo un dato che arriva da un’analisi condotta sul mercato americano: anche un downtime minimo – nell’ordine dello 0,05% di indisponibilità l’anno per un server – può valere decine di migliaia di dollari l’anno in costi complessivi per una piccola impresa.
Che il numero esatto sia 55.000 dollari o meno, il punto è un altro:
il downtime ha un costo reale, misurabile, spesso sottostimato.
E questo costo è fatto di diversi strati:
- Productivity loss: ore buttate di persone che non possono lavorare.
- Cost of delay: progetti spostati, iniziative che slittano, opportunità perse.
- Stress organizzativo: escalation, riunioni d’emergenza, reputazione interna dell’IT che si erode.
- Rischio reputazionale ed economico: quando il downtime impatta clienti esterni, partner, fornitori.
Se allarghiamo lo sguardo, la gestione reattiva dell’IT non è solo un problema tecnico.
È un problema di allocazione del capitale e di gestione del rischio operativo.
Dal mio punto di vista, questo è il linguaggio che dobbiamo usare con il management:
meno discorsi su “CPU all’80%” e più ragionamenti su costo del fermo, probabilità di incidente e costo del ritardo nel mettere in produzione un certo tipo di automazione o monitoraggio.
Proattività = monitoraggio + automazione (non solo più grafici)
Parlare di proattività non significa solo riempirsi di dashboard e alert.
Se bastasse questo, saremmo tutti proattivi da anni.
Il modello efficace ha due facce:
- Monitoraggio e alerting
- Automazione delle risoluzioni ricorrenti
Sul primo punto, un sistema RMM o comunque una piattaforma di monitoraggio moderna ti permette di:
- vedere in un’unica dashboard endpoint, server e dispositivi di rete
- definire soglie e regole di alert (CPU, memoria, stato dischi, spazio su disco, servizi di sistema, traffico di rete…)
- collegare gli alert a ticket, notifiche push, mail, SMS, ecc.
Ma il valore vero arriva quando colleghi il monitoraggio all’automazione.
Prendiamo l’esempio banale ma reale citato in puntata:
il servizio di spooler di stampa che si blocca.
Nel modello reattivo:
– l’utente non stampa, apre un ticket, aspetta il tecnico
– il tecnico si collega, identifica il servizio fermo, lo riavvia, testa, chiude il ticket
– se lo stesso problema colpisce più utenti, ripete lo stesso giro N volte.
Nel modello proattivo:
- il sistema monitora lo stato del servizio spooler
- quando lo vede fermo, genera un alert e fa partire in automatico uno script di riavvio
- l’utente o non si accorge del problema, o lo vive per uno-due minuti, non per mezz’ora
- il tecnico non spreca più il suo tempo su questa classe di problemi.
Lo stesso vale per:
- spazio disco quasi esaurito → pulizia automatica di file temporanei, log e cache
- patch management → scansione, pianificazione e deployment automatizzato fuori orario lavorativo
- setup di nuovi device → provisioning automatizzato per dipartimenti con profili standard
La logica è sempre la stessa:
identifica i problemi ricorrenti e a basso valore che mangiano il tempo del team e trattali come candidati per l’automazione.
Alert fatigue: quando la proattività si trasforma in rumore
C’è però un rischio che vedo spesso nei dipartimenti IT che muovono i primi passi verso il monitoraggio massivo: la alert fatigue.
Si configurano decine di alert “per stare tranquilli”, si manda tutto via mail, magari a più persone, e dopo poco tempo succede una cosa molto semplice: nessuno li guarda più.
Un alert che scatta ogni ora per condizioni non critiche diventa rumore di fondo.
E quando poi arriva un alert davvero importante, rischia di perdersi nello stesso mare di notifiche.
La proattività non è “più alert per tutti”.
È meno alert, più intelligenti e strutturati.
Dal punto di vista manageriale, questo significa:
- distinguere tra alert critici, warning e informativi
- definire canali diversi per livelli diversi (es. SMS o app mobile solo per incidenti gravi, mail o dashboard per warning)
- misurare il rapporto tra alert aperti e azioni effettive
- rivedere periodicamente le regole per eliminare alert inutili o ridondanti
Se non gestisci bene questa parte, il rischio è che il progetto di monitoraggio si trasformi in un altro flusso di rumore che il team IT impara a ignorare per sopravvivere.
Persone, non solo tool: satisfaction e retention del team IT
Un aspetto che spesso viene trascurato è l’impatto della proattività sulla vita delle persone che lavorano nell’IT.
Quando il team passa le giornate:
- a riavviare servizi
- a cancellare file temporanei
- a gestire le solite stampanti
- a rispondere in emergenza a incidenti prevedibili
si crea un mix tossico di:
- frustrazione (“sto facendo un lavoro che potrebbe fare uno script”)
- burnout (“sono sempre in emergenza”)
- fuga delle persone più capaci verso contesti più maturi.
La gestione proattiva, se fatta bene, libera tempo cognitivo e spazio mentale.
Significa:
- ridurre il volume di ticket banali
- dare al team la possibilità di lavorare su progetti di miglioramento reale
- far crescere competenze di automazione, architettura, sicurezza
- rendere il lavoro dell’IT più vicino a quello di un team di ingegneria del servizio che a un semplice service desk.
In un mercato in cui è difficile attrarre e trattenere talento tech, questo non è un dettaglio.
Cybersecurity: prevenzione, superficie d’attacco e manutenzione
C’è poi il tema sicurezza, che in molte aziende viene ancora affrontato solo come “layer in più” (l’ennesimo firewall, l’ennesimo antivirus) invece che come conseguenza diretta di una buona manutenzione operativa.
Una parte non banale degli incidenti avviene perché:
- le macchine non sono patchate
- servizi inutili restano attivi
- software non autorizzati girano indisturbati sugli endpoint
- nessuno si accorge in tempo di comportamenti anomali (es. CPU costantemente alta per processi sospetti).
Un RMM usato bene, integrato con strumenti di sicurezza e con una politica chiara di monitoraggio, diventa anche una leva di riduzione della superficie d’attacco.
Non sostituisce il lavoro di security, ma gli fornisce:
- un inventario aggiornato
- segnali precoci su anomalie
- un modo strutturato per distribuire patch e configurazioni di hardening.
Come vendere la proattività al management
Qui torniamo a un punto che per me è centrale: non basta avere ragione dal punto di vista tecnico.
Se sei un CTO, un IT Manager, un Head of Infrastructure, il tuo lavoro non è solo progettare la soluzione giusta. È anche farla approvare, finanziare e adottare.
Il management non compra “monitoraggio e automazione”.
Compra:
- meno downtime su servizi core
- meno tempi morti per persone costose
- meno probabilità di incidenti critici
- un IT che sostiene la crescita invece di frenarla.
Di conseguenza, il modo giusto di presentare un progetto di proattività è:
- portare numeri sullo storico (ticket ricorrenti, ore uomo spese su classi di problemi ripetitivi, downtime totali)
- stimare il costo annuo di questi problemi
- costruire un business case dove il costo della piattaforma e del progetto è messo a confronto con il risparmio e il rischio evitato (anche solo in parte).
Se non traduciamo il discorso in questi termini, la proposta resta percepita come “spesa IT” e rientra nel calderone dei costi comprimibili.
Da dove iniziare: una roadmap essenziale verso l’IT proattivo
Riassumendo, una possibile roadmap pratica potrebbe essere:
- Mappare la situazione attuale
- Quali sono le categorie di ticket più frequenti?
- Quali sono state le principali interruzioni di servizio negli ultimi 12 mesi?
- Quanto tempo uomo viene speso su attività ripetitive?
- Introdurre un monitoraggio strutturato
- Scegliere una piattaforma adeguata (RMM o simili)
- definire un set iniziale di metriche e alert, limitato ma significativo
- integrare il monitoraggio con il sistema di ticketing esistente.
- Selezionare poche automazioni ad alto impatto
- spooler di stampa
- pulizia spazio disco
- setup standard dei nuovi device
- patch management per una prima classe di sistemi.
- Misurare e comunicare i risultati
- riduzione dei ticket su quelle categorie
- tempo risparmiato
- minor downtime su specifici servizi.
- Iterare e ampliare il perimetro
- aggiungere nuove automazioni
- raffinare alerting e soglie
- coinvolgere gradualmente altri team (es. sicurezza, operations, business unit).
L’obiettivo non è essere perfetti al primo colpo.
L’obiettivo è uscire dalla logica dell’incendio continuo e costruire un IT che previene, non solo che cura.
