ITSM IT Service Management: Guida [2026]

Il PC non funziona, chiami il "ragazzo dell'IT", lui arriva quando può, risolve (forse), e nessuno sa cosa è successo. Vi suona familiare? È così che funziona il supporto IT nella maggior parte delle PMI italiane. L'ITSM è l'alternativa: un modo strutturato per gestire i servizi IT che trasforma il caos in un processo misurabile. BullTech Informatica, MSP fondato nel 2009 a Vimercate (MB), gestisce il supporto IT di oltre 200 aziende con un SLA del 99,2%. Non perché siamo geni, ma perché usiamo l'ITSM ogni giorno. In questa guida ti spiego cos'è, come funziona e come può aiutare anche la tua azienda.

Cos'è l'ITSM (spiegato senza sigle)

ITSM sta per IT Service Management, e in italiano si traduce con "gestione dei servizi IT". Ma cosa significa in pratica? Significa trattare l'IT come un servizio, non come un costo. Significa avere processi chiari per gestire incidenti, richieste, cambiamenti e problemi. Significa sapere chi fa cosa, entro quando e con che risultato.

Pensa al tuo IT come a un ristorante. Senza ITSM, è come una trattoria senza menu: il cliente ordina "qualcosa di buono", il cuoco fa quello che gli pare, e nessuno sa quanto tempo ci vuole. Con l'ITSM, hai un menu (catalogo dei servizi), un cameriere (service desk), una cucina organizzata (processi), e sai che il primo arriva in 15 minuti (SLA).

L'ITSM non è un software da comprare. È un modo di organizzare il lavoro IT. Il software (il tool di ticketing, il CMDB, il portale self-service) è solo lo strumento che supporta i processi. Puoi avere il miglior tool ITSM del mondo, ma se non hai processi definiti, stai solo digitalizzando il caos.

ITIL 4: il framework di riferimento

Quando si parla di ITSM, si parla inevitabilmente di ITIL. ITIL (Information Technology Infrastructure Library) è il framework più diffuso al mondo per il service management IT. La versione 4, rilasciata nel 2019, è molto più flessibile e moderna rispetto alle versioni precedenti.

I 7 principi guida di ITIL 4

ITIL 4 si basa su 7 principi guida che sono di una semplicità disarmante. E funzionano.

• Focus on value: tutto quello che fai deve generare valore per qualcuno. Se un processo non genera valore, eliminalo.
• Start where you are: non buttare via tutto e ricominciare da zero. Parti da quello che hai, migliora gradualmente.
• Progress iteratively with feedback: non pianificare per 2 anni. Fai piccoli passi, misura i risultati, correggi la rotta.
• Collaborate and promote visibility: l'IT non è un'isola. Collabora con il business, condividi le informazioni, rendi visibile quello che fai.
• Think and work holistically: i servizi IT sono interconnessi. Una modifica al server email impatta gli utenti, il backup, la sicurezza. Pensa al sistema, non al singolo componente.
• Keep it simple and practical: se un processo ha 47 step, nessuno lo seguirà. Semplifica. Se puoi eliminare uno step senza perdere valore, fallo.
• Optimize and automate: prima ottimizza il processo (elimina gli sprechi), poi automatizza. Automatizzare un processo inefficiente significa solo fare cose inutili più velocemente.

Le 4 pratiche ITSM essenziali per una PMI

ITIL 4 ha 34 pratiche. Per una PMI, ne servono 4. Le altre sono utili, ma queste quattro sono il minimo indispensabile.

1. Incident management

Un incidente è qualsiasi evento che interrompe o degrada un servizio IT. Il PC che non si accende, la stampante che non stampa, il gestionale che va in errore, la mail che non arriva. L'incident management è il processo che gestisce questi eventi dalla segnalazione alla risoluzione.

Il processo base è semplice: identificazione (l'utente segnala il problema), registrazione (si apre un ticket con tutti i dettagli), categorizzazione (di che tipo è? rete, hardware, software, sicurezza?), prioritizzazione (P1 critico, P2 alto, P3 medio, P4 basso — basata su impatto e urgenza), diagnosi e risoluzione, chiusura (conferma dell'utente che il problema è risolto).

Il punto chiave: senza un sistema di ticketing, l'incident management non esiste. Se le segnalazioni arrivano via email, WhatsApp, telefono e passaparola, non hai un processo — hai il caos.

2. Service request management

Una richiesta di servizio è diversa da un incidente: non è un problema, è una richiesta. "Ho bisogno di un nuovo account email", "Posso avere accesso alla cartella condivisa?", "Mi serve un nuovo laptop". Il service request management definisce come queste richieste vengono gestite: chi può approvare cosa, entro quanto tempo, con che priorità.

In una PMI ben organizzata, le richieste più comuni (reset password, accesso a cartelle, installazione software standard) sono automatizzate con un portale self-service. L'utente clicca, la richiesta parte, e se non richiede approvazione viene eseguita automaticamente. Zero telefonate, zero email, zero attese.

3. Change enablement

Ogni modifica all'infrastruttura IT è un rischio. Un aggiornamento del server, una nuova regola sul firewall, un cambio di provider email — tutto può andare storto. Il change enablement (in ITIL 3 si chiamava change management) è il processo che gestisce i cambiamenti in modo controllato.

Il concetto base: ogni cambio deve essere registrato (chi lo chiede, perché, cosa cambia), valutato (che rischi comporta? che impatto ha? serve un piano di rollback?), approvato (da chi ha l'autorità, non da chi ha le credenziali di admin), implementato (in una finestra di manutenzione concordata), e verificato (funziona tutto? l'utente conferma?).

Sembra burocrazia? Non lo è. Il 60% dei downtime è causato da cambiamenti non controllati (fonte: Gartner 2025). Un tecnico che fa un "aggiornamento veloce" al server di produzione alle 14:30 di mercoledì senza avvisare nessuno è la prima causa di disastri IT nelle PMI.

4. Knowledge management

La knowledge base è la memoria dell'IT. Come si risolve quel problema con il gestionale? Qual è la procedura per configurare la VPN? Come si resetta la password di Active Directory? Se questa conoscenza è solo nella testa del tecnico, hai un single point of failure umano.

Il knowledge management è il processo che cattura, organizza e condivide la conoscenza IT. Ogni incidente risolto diventa un articolo nella knowledge base. Ogni procedura documentata riduce il tempo di risoluzione del prossimo ticket simile. Noi di BullTech abbiamo oltre 500 procedure documentate nella nostra knowledge base interna — è il motivo per cui il nuovo tecnico può risolvere il 70% dei ticket dal primo giorno.

Tool ITSM a confronto: quale scegliere

Il tool non fa l'ITSM, ma un buon tool aiuta enormemente. Ecco i principali a confronto per le PMI italiane.

Il nostro consiglio: se hai 1-3 tecnici IT, parti con Jira Service Management (gratis fino a 3 agenti) o Zammad (open source). Se hai 3-10 tecnici, Freshservice è un ottimo compromesso. ServiceNow lo consigliamo solo ad aziende con 500+ dipendenti e budget IT adeguato — per una PMI è come comprare un TIR per fare la spesa.

SLA management: misurare per migliorare

Uno SLA (Service Level Agreement) è un accordo che definisce i livelli di servizio attesi. Senza SLA, non puoi misurare se il tuo IT funziona bene o male. Con SLA, hai numeri concreti.

Come definire gli SLA

Gli SLA si definiscono su due dimensioni: tempo di risposta (entro quanto il tecnico prende in carico il ticket) e tempo di risoluzione (entro quanto il problema è risolto). Entrambi variano in base alla priorità.

Ecco un esempio realistico per una PMI:

• P1 (critico): server giù, email bloccata per tutti, ransomware. Risposta: 30 minuti. Risoluzione: 4 ore.
• P2 (alto): gestionale lento, stampante di reparto guasta, VPN non funziona. Risposta: 1 ora. Risoluzione: 8 ore.
• P3 (medio): PC singolo lento, problema con un'applicazione, richiesta software. Risposta: 4 ore. Risoluzione: 24 ore.
• P4 (basso): richiesta informazioni, configurazione non urgente, miglioramento estetico. Risposta: 8 ore. Risoluzione: 5 giorni lavorativi.

L'errore più comune: definire SLA troppo aggressivi che non puoi rispettare. È meglio promettere "risposta entro 1 ora" e rispondere in 30 minuti, che promettere "risposta entro 15 minuti" e bucare costantemente lo SLA. La credibilità si costruisce mantenendo le promesse, non facendone di irrealistiche.

Problem management: andare alla radice

L'incident management risolve i sintomi. Il problem management cerca le cause. Se la stampante si blocca ogni lunedì mattina, l'incident management la sblocca ogni volta. Il problem management indaga il perché: forse il driver è incompatibile con l'ultimo aggiornamento di Windows, forse la rete si satura quando tutti accendono i PC alle 8:30, forse la stampante ha un difetto hardware.

La differenza tra un IT reattivo e un IT proattivo sta tutta qui. Un IT reattivo spegne incendi. Un IT proattivo elimina le cause degli incendi. Noi di BullTech monitoriamo i ticket ricorrenti: se lo stesso problema si presenta 3 volte in un mese, apriamo un "problem" e indaghiamo la root cause. Il risultato è meno incidenti, meno ticket, utenti più contenti.

Il catalogo dei servizi: cosa offri e a chi

Il catalogo dei servizi è la lista dei servizi IT offerti all'organizzazione. Non è un documento tecnico per il reparto IT — è un menu per gli utenti. Cosa posso chiedere? A chi? Entro quanto tempo?

Un esempio per una PMI: gestione postazioni (setup nuovi PC, installazione software, sostituzione hardware), gestione email (nuovi account, distribuzione liste, configurazione mobile), gestione rete (accesso Wi-Fi, VPN, condivisione file), supporto applicativo (gestionale, CRM, Office 365), sicurezza (antivirus, backup, MFA, incident response).

Per ogni servizio, il catalogo specifica: descrizione, SLA, costo (se applicabile), come richiederlo, chi lo approva. Sembra banale? Il 70% delle PMI non ha un catalogo dei servizi IT formalizzato. Il risultato è che gli utenti non sanno cosa possono chiedere, il supporto IT riceve richieste improprie, e nessuno sa quanto tempo ci vuole per ottenere qualcosa.

ITSM e help desk outsourcing

Molte PMI non hanno un team IT interno (o ne hanno uno di 1-2 persone). In questo caso, l'ITSM viene implementato dall'MSP che gestisce il supporto IT in outsourcing. È esattamente quello che facciamo noi di BullTech.

Il vantaggio: il cliente ottiene un service desk strutturato con processi ITSM maturi senza doverli costruire da zero. Il nostro service desk ha già i processi di incident management, change enablement, knowledge management e SLA management operativi. Il cliente apre un ticket (via portale, email o telefono), e il processo parte automaticamente.

Lo svantaggio: se cambi MSP, perdi il service desk. Per mitigare questo rischio, noi forniamo report mensili dettagliati e documentazione completa dell'infrastruttura del cliente. Se un giorno il cliente decide di portare l'IT in-house o cambiare fornitore, ha tutto quello che serve per una transizione pulita.

Come implementare l'ITSM in una PMI

Un piano realistico in 4 fasi per una PMI con 30-100 dipendenti.

Fase 1: ticketing (settimane 1-2)

Scegli un tool (Freshservice, Jira SM, Zammad) e configuralo. Definisci le categorie dei ticket, le priorità, gli SLA base. Addestra il team IT a usarlo. Da questo momento, tutte le richieste IT passano dal ticketing. Zero eccezioni. Se non è un ticket, non esiste.

Fase 2: incident management (settimane 2-4)

Definisci il processo di incident management: come si apre un ticket, come si categorizza, come si assegna la priorità, chi lo prende in carico, entro quanto deve rispondere e risolvere. Scrivi le procedure per gli incidenti più comuni (reset password, PC che non si accende, problemi di rete). Forma il team IT.

Fase 3: catalogo e SLA (settimane 4-6)

Crea il catalogo dei servizi. Definisci gli SLA per ogni tipo di richiesta. Comunica il tutto agli utenti: "ecco cosa potete chiedere, ecco come chiederlo, ecco entro quando rispondiamo". Questo passo è fondamentale per gestire le aspettative: se l'utente sa che un P3 viene risolto entro 24 ore, non chiamerà 5 volte in un'ora.

Fase 4: knowledge base e miglioramento (settimane 6-12)

Inizia a costruire la knowledge base: documenta le soluzioni degli incidenti ricorrenti, le procedure standard, le FAQ. Analizza i dati dei ticket: quali sono gli incidenti più frequenti? Quali violano gli SLA? Dove ci sono pattern ricorrenti che richiedono un problem investigation? Questo è il ciclo di miglioramento continuo che trasforma un help desk reattivo in un service desk proattivo.

Come BullTech usa l'ITSM

Non vendiamo ITSM come prodotto. Lo usiamo come metodo per gestire i nostri clienti. Ecco come funziona il nostro service desk:

• Canali di contatto: portale web, email, telefono (039 6099 023). Tutti i canali convergono nel sistema di ticketing.
• SLA differenziati: P1 (risposta 30 min, risoluzione 4h), P2 (risposta 1h, risoluzione 8h), P3 (risposta 4h, risoluzione 24h), P4 (risposta 8h, risoluzione 5gg). SLA complessivo: 99,2%.
• Knowledge base: 500+ procedure documentate, aggiornate continuamente. Il tecnico che risolve un nuovo problema documenta la soluzione prima di chiudere il ticket.
• Change management: ogni modifica all'infrastruttura del cliente viene registrata, valutata e approvata prima dell'esecuzione. Niente "aggiornamenti a sorpresa".
• Report mensili: ogni cliente riceve un report con: numero di ticket aperti/chiusi, SLA rispettati, trend degli incidenti, raccomandazioni di miglioramento.

Domande frequenti sull'ITSM