Vai al contenuto
Riflessioni

Service Management: il vero obiettivo non è gestire servizi.

Quando si parla di service management, la prima immagine che viene in mente è spesso molto operativa.

Ticket da classificare.
Procedure da seguire.
SLA da rispettare.
Dashboard da controllare.
Processi da documentare.
Riunioni in cui qualcuno chiede perché un indicatore è peggiorato rispetto al mese precedente.

Tutto corretto, almeno in apparenza.

Eppure, se ci fermiamo a questa immagine, rischiamo di perdere completamente il punto. Perché il vero obiettivo del service management non è gestire servizi. O almeno, non nel senso più riduttivo del termine.

Il vero obiettivo del service management è creare valore attraverso i servizi.

La differenza sembra sottile, ma cambia tutto.

Gestire un servizio può voler dire mantenerlo attivo, rispondere alle richieste, correggere gli errori, garantire continuità operativa e rispettare determinati livelli di servizio. Creare valore, invece, significa chiedersi se quel servizio stia davvero aiutando qualcuno a raggiungere un risultato nel modo migliore possibile.

Non è la stessa cosa.

Un servizio può essere tecnicamente disponibile e allo stesso tempo essere percepito come inutile, complicato o frustrante. Può rispettare tutti gli SLA contrattuali e lasciare comunque l’utente con la sensazione di non essere stato aiutato. Può essere ben documentato nei processi interni e risultare incomprensibile per chi lo utilizza ogni giorno.

Ed è proprio qui che il service management diventa interessante.

Perché non si limita a chiedere: “Il servizio funziona?”

La domanda più importante è un’altra:

“Il servizio sta producendo valore per chi lo utilizza, per chi lo eroga e per l’organizzazione che lo sostiene?”

Questa è la domanda che dovrebbe guidare ogni riflessione seria sulla gestione dei servizi IT e digitali.

Perché il service management è molto più della gestione operativa.

In molte organizzazioni, il service management viene ancora confuso con la gestione operativa del supporto.

Se c’è uno strumento di ticketing, allora si pensa di avere un modello di service management. Se esistono procedure per aprire richieste, gestire incident, approvare cambiamenti e produrre report mensili, allora si pensa che il servizio sia sotto controllo.

Ma controllo e valore non sono sinonimi.

Un servizio può essere controllato e non generare valore.
Può essere misurato e non essere compreso.
Può essere formalmente corretto e praticamente inefficace.

Questo accade perché spesso si guarda il servizio dall’interno dell’organizzazione, non dall’esperienza reale di chi lo utilizza.

Dall’interno, un servizio appare come un insieme di componenti: persone, strumenti, processi, fornitori, ruoli, metriche, documentazione. Dall’esterno, invece, il servizio appare come un’esperienza unica.

L’utente non vede il processo.
Non vede il modello organizzativo.
Non vede il flusso di escalation.
Non vede la distinzione tra team applicativo, infrastrutturale, sviluppo, sicurezza, fornitore esterno e service desk.

Vede solo una cosa: se riesce oppure no a raggiungere il proprio obiettivo.

Quando apre un ticket, non sta “attivando un processo di supporto”. Sta cercando di tornare a lavorare. Quando chiede una nuova utenza, non sta “richiedendo l’erogazione di una service request”. Sta cercando di accedere a uno strumento necessario. Quando segnala un malfunzionamento, non sta “contribuendo alla rilevazione di un incident”. Sta vivendo una frizione che interrompe il suo lavoro.

Il service management serve proprio a colmare questa distanza tra ciò che l’organizzazione gestisce e ciò che l’utente vive.

Per questo non può essere ridotto alla sola gestione dei ticket o all’applicazione meccanica di un framework. I processi sono necessari, ma non bastano. Le metriche sono utili, ma non bastano. Gli strumenti sono fondamentali, ma non bastano.

Il service management diventa maturo quando riesce a tenere insieme tre dimensioni:

la progettazione del servizio;

l’erogazione quotidiana del servizio;

la percezione di valore generata dal servizio.

Se manca una di queste dimensioni, il sistema si sbilancia.

Quando si progetta senza ascoltare l’operatività, si creano servizi eleganti sulla carta ma fragili nella realtà. Quando si eroga senza misurare, si lavora molto ma si capisce poco. Quando si misura senza interpretare la percezione degli utenti, si rischia di celebrare numeri che non raccontano davvero la qualità del servizio.

Il service management non serve quindi a rendere l’organizzazione più burocratica. Serve a rendere il servizio più consapevole.

Cosa significa davvero creare valore attraverso un servizio.

Per capire il service management bisogna prima chiarire cosa intendiamo per valore.

Nel linguaggio aziendale, la parola “valore” viene usata spesso. A volte troppo. Si parla di valore per il cliente, valore per il business, valore generato, valore percepito, valore aggiunto. Il rischio è che diventi una formula generica, buona per qualsiasi presentazione ma poco utile nella pratica.

Nel contesto dei servizi, invece, il valore ha un significato molto concreto.

Un servizio crea valore quando aiuta qualcuno a raggiungere un risultato desiderato senza costringerlo a farsi carico direttamente di tutti i costi, i rischi e la complessità necessari per ottenerlo.

Pensiamo a un servizio di trasporto.

Quando prendiamo un treno, non stiamo acquistando rotaie, manutenzione, personale, sistemi di sicurezza, pianificazione delle tratte e gestione delle stazioni. Stiamo acquistando la possibilità di spostarci da un punto a un altro in un certo tempo, con un certo livello di affidabilità, comfort e prevedibilità.

Il valore non sta solo nel movimento fisico. Sta nel risultato che quel movimento rende possibile: arrivare a una riunione, andare in vacanza, rientrare a casa, rispettare un impegno.

Lo stesso vale per i servizi digitali.

Quando usiamo una piattaforma di streaming, non ci interessa davvero l’infrastruttura cloud, l’algoritmo di raccomandazione, il sistema di autenticazione, la rete di distribuzione dei contenuti o il modello di licenze. Ci interessa trovare rapidamente qualcosa da guardare, con una buona qualità, senza interruzioni, possibilmente con suggerimenti coerenti con i nostri gusti.

Il valore non è il prodotto tecnico. Il valore è l’esperienza resa possibile dal servizio.

Questo è un passaggio fondamentale per chi lavora nel service management.

Perché spesso, all’interno delle organizzazioni IT, si tende a innamorarsi del mezzo. Lo strumento, la piattaforma, il processo, il sistema, il workflow, la dashboard. Tutte cose importanti, certo. Ma nessuna di queste coincide automaticamente con il valore.

Il valore nasce quando quelle risorse permettono a qualcuno di ottenere un risultato.

Un portale self-service non crea valore perché è moderno. Crea valore se riduce la fatica dell’utente, accelera l’accesso al supporto, migliora la qualità delle informazioni raccolte e permette al team di lavorare meglio.

Una knowledge base non crea valore perché contiene articoli. Crea valore se viene consultata, aggiornata, compresa e utilizzata per risolvere problemi reali.

Un processo di change management non crea valore perché esiste una procedura di approvazione. Crea valore se riduce il rischio dei cambiamenti senza bloccare inutilmente l’evoluzione del servizio.

Una dashboard non crea valore perché mostra indicatori. Crea valore se aiuta a prendere decisioni migliori.

Il service management, quindi, non dovrebbe mai partire dalla domanda: “Quale processo dobbiamo implementare?”

Dovrebbe partire da una domanda più semplice e più difficile:

“Quale valore vogliamo rendere possibile?”

Servizio, prodotto e valore: tre concetti che vengono spesso confusi.

Uno dei motivi per cui il service management viene frainteso è che spesso si confondono servizio, prodotto e valore.

Sono concetti collegati, ma non equivalenti.

Un prodotto è una configurazione di risorse. Può includere tecnologia, persone, fornitori, documentazione, processi, infrastrutture, applicazioni, interfacce, contratti e competenze. È ciò che l’organizzazione mette insieme per rendere possibile qualcosa.

Un servizio, invece, è il modo in cui quella configurazione di risorse abilita un risultato per il consumatore.

Il valore è ciò che emerge dall’utilizzo del servizio, dalla percezione che ne deriva e dal modo in cui quel servizio contribuisce al raggiungimento degli obiettivi.

Facciamo un esempio semplice.

Una compagnia aerea non offre solo aerei. Gli aerei sono parte del prodotto. Insieme agli equipaggi, ai sistemi di prenotazione, ai controlli di sicurezza, agli aeroporti, alla manutenzione, ai fornitori, alla gestione dei bagagli e ai canali di assistenza.

Il servizio è il trasporto di passeggeri da un luogo a un altro.

Il valore, però, può cambiare a seconda della persona.

Per un viaggiatore business, il valore potrebbe essere arrivare puntuale a una riunione. Per una famiglia, potrebbe essere viaggiare in sicurezza e senza stress. Per chi paga il biglietto, potrebbe essere il rapporto tra costo, affidabilità e comfort. Per l’azienda che organizza la trasferta, potrebbe essere la prevedibilità della spesa e la facilità di gestione amministrativa.

Stesso servizio. Valori percepiti diversi.

Questo è un punto spesso sottovalutato.

Il valore non è una proprietà fissa del servizio. È il risultato di una relazione.

Dipende da chi utilizza il servizio, da cosa si aspetta, dal contesto in cui lo usa, dalle alternative disponibili, dal momento specifico e dall’esperienza complessiva che vive.

Ecco perché un servizio può essere considerato ottimo da un gruppo di utenti e mediocre da un altro. Perché non tutti cercano lo stesso valore.

Nel mondo IT questo accade continuamente.

Un sistema interno può essere valutato positivamente dal management perché riduce i costi di gestione, ma essere odiato dagli utenti perché è lento e complicato. Una procedura può essere apprezzata dal team di sicurezza perché aumenta il controllo, ma essere percepita come un ostacolo dai gruppi operativi. Un nuovo sistema di ticketing può essere utile per produrre report migliori, ma peggiorare l’esperienza di chi deve aprire una richiesta.

Il service management deve tenere insieme queste prospettive.

Non può limitarsi alla visione del fornitore del servizio. Deve comprendere anche la prospettiva del consumatore, dell’utente, dello sponsor, dei team interni, dei partner e di tutti gli stakeholder coinvolti.

Perché il valore non si dichiara. Si verifica nella relazione tra chi eroga e chi consuma il servizio.

Perché il valore non viene creato da una sola parte.

Uno dei concetti più importanti del service management moderno è la co-creazione del valore.

La parola può sembrare teorica, ma nella pratica descrive qualcosa di molto concreto: il valore di un servizio non viene prodotto soltanto dal fornitore. Viene costruito attraverso l’interazione tra più soggetti.

Un’organizzazione può progettare un servizio eccellente, ma se gli utenti non lo utilizzano correttamente, se non forniscono feedback, se aggirano i canali ufficiali o se non condividono le proprie esigenze reali, una parte del valore si perde.

Allo stesso modo, gli utenti possono avere bisogni chiari e legittimi, ma se l’organizzazione non li ascolta, non li interpreta o non li traduce in miglioramenti concreti, il servizio resta distante dalla realtà.

La co-creazione del valore nasce proprio da questo incontro.

Chi progetta il servizio porta competenze tecniche, organizzative e operative.
Chi utilizza il servizio porta esperienza reale, aspettative, frustrazioni e bisogni.
Chi finanzia il servizio porta vincoli economici e priorità strategiche.
Chi lo supporta ogni giorno porta segnali, anomalie, ricorrenze e percezioni raccolte dal campo.
Chi lo governa deve trasformare tutte queste informazioni in decisioni.

Quando queste parti non comunicano, il servizio si impoverisce.

Non necessariamente smette di funzionare. Spesso continua a funzionare, ma in modo meno efficace, meno fluido, meno aderente alla realtà.

È qui che nascono molte distorsioni organizzative.

Il team tecnico migliora una componente senza sapere che sta complicando il lavoro del service desk. Il management introduce una metrica senza considerare i comportamenti che quella metrica incentiverà. Il cliente chiede una funzionalità, ma non esplicita il problema reale che vuole risolvere. Il service desk raccoglie ogni giorno segnali preziosi, ma nessuno li trasforma in informazioni utili per migliorare il servizio.

Il risultato è un servizio che si muove, ma non apprende.

E un servizio che non apprende è destinato a creare sempre meno valore nel tempo.

Per questo il service management non può essere una disciplina chiusa dentro un singolo team. Non appartiene solo all’IT. Non appartiene solo al service desk. Non appartiene solo ai process owner o ai manager.

È una responsabilità distribuita.

Naturalmente, questo non significa che tutti debbano decidere tutto. Significa che il valore nasce solo quando le informazioni circolano, i ruoli sono chiari e le decisioni vengono prese tenendo conto dell’intero ecosistema del servizio.

Un buon modello di service management non elimina la complessità, ma la rende leggibile.

Aiuta l’organizzazione a capire chi deve essere coinvolto, quando, con quale livello di dettaglio e per quale obiettivo. Aiuta a distinguere ciò che è operativo da ciò che è strategico. Aiuta a trasformare feedback, ticket, dati e osservazioni in miglioramenti concreti.

In altre parole, crea le condizioni perché il valore possa emergere.

Il ruolo del service management nella creazione di valore.

A questo punto possiamo tornare alla domanda iniziale: che ruolo ha davvero il service management?

Il service management non è semplicemente l’insieme dei processi con cui un’organizzazione gestisce i propri servizi IT. Questa definizione può essere corretta, ma rischia di essere troppo fredda.

Il service management è la disciplina che permette a un’organizzazione di progettare, erogare, governare e migliorare servizi capaci di creare valore.

Questa definizione contiene alcune parole importanti.

Progettare, perché il valore non nasce per caso. Un servizio deve essere pensato a partire dagli obiettivi che deve abilitare, dalle persone che lo utilizzeranno, dai vincoli dell’organizzazione e dal contesto in cui dovrà funzionare.

Erogare, perché un servizio non vive nei documenti. Vive ogni giorno nella sua esecuzione reale, nelle interazioni con gli utenti, nei problemi che emergono, nei canali di supporto, nei tempi di risposta, nella qualità delle comunicazioni e nella capacità di adattarsi.

Governare, perché senza responsabilità chiare il servizio diventa una somma di attività sparse. Qualcuno lo sviluppa, qualcuno lo supporta, qualcuno lo usa, qualcuno lo misura, ma nessuno lo guida davvero.

Migliorare, perché nessun servizio resta uguale a sé stesso. Cambiano gli utenti, cambiano le aspettative, cambiano le tecnologie, cambiano i rischi, cambiano i vincoli economici e organizzativi.

Creare valore, perché tutto il resto è un mezzo.

Questa prospettiva è importante soprattutto oggi, in un contesto in cui le organizzazioni si affidano sempre di più a servizi digitali, automazioni, piattaforme cloud, strumenti di collaborazione, sistemi integrati e soluzioni basate sull’intelligenza artificiale.

La tecnologia offre opportunità enormi, ma non garantisce valore automaticamente.

Un servizio può essere tecnologicamente avanzato e organizzativamente fragile. Può usare strumenti moderni e produrre un’esperienza pessima. Può essere automatizzato, ma automatizzare un processo confuso significa solo rendere più veloce la confusione.

Per questo il service management non può essere sostituito dalla tecnologia.

La tecnologia abilita.
Il service management orienta.

La tecnologia esegue.
Il service management dà senso.

La tecnologia può accelerare.
Il service management deve decidere in quale direzione accelerare.

Senza questa consapevolezza, le organizzazioni rischiano di scambiare il progresso tecnologico per miglioramento del servizio. Ma non sono la stessa cosa.

Un nuovo strumento non è automaticamente un servizio migliore. Un nuovo portale non è automaticamente una migliore esperienza utente. Un chatbot non è automaticamente un supporto più efficace. Una nuova dashboard non è automaticamente una gestione più consapevole.

Il valore nasce quando tecnologia, persone, processi e obiettivi sono allineati.

Ed è qui che il service management diventa decisivo.

ITIL e il sistema del valore del servizio.

Quando si parla di service management, prima o poi si arriva a ITIL.

ITIL è uno dei framework più diffusi per la gestione dei servizi IT e nel tempo si è evoluto proprio per rispondere alla crescente complessità delle organizzazioni moderne. Ma anche qui bisogna fare attenzione a un equivoco.

ITIL non dovrebbe essere visto come un manuale di burocrazia.

Non è una raccolta di regole da applicare in modo rigido. Non è un linguaggio per rendere più complicato ciò che potrebbe essere semplice. Non è una certificazione da esibire per dimostrare competenza.

Nella sua interpretazione più utile, ITIL è una lente.

Aiuta a osservare il servizio in modo più ampio. Aiuta a capire come persone, processi, tecnologie, partner, informazioni e decisioni contribuiscono alla creazione di valore. Aiuta a evitare che ogni parte dell’organizzazione lavori isolata dalle altre.

Uno dei concetti centrali di ITIL è il Service Value System, cioè il sistema del valore del servizio.

L’idea di fondo è semplice: un’organizzazione riceve input sotto forma di opportunità, bisogni, domanda, problemi o aspettative e deve essere in grado di trasformarli in valore.

Questo passaggio, però, non avviene automaticamente.

Tra il bisogno e il valore ci sono decisioni, attività, pratiche, persone, tecnologie, comunicazioni, priorità, vincoli e responsabilità. Il Service Value System serve proprio a rappresentare questa trasformazione.

In altre parole, non basta sapere che esiste una richiesta. Bisogna essere in grado di gestirla, comprenderla, inserirla in un contesto, valutarne l’impatto, coordinarla con le altre attività e trasformarla in qualcosa che abbia senso per il cliente, per l’utente e per l’organizzazione.

I principi guida di ITIL si inseriscono dentro questa logica.

Focalizzarsi sul valore.
Partire dallo stato attuale.
Procedere in modo iterativo con feedback.
Collaborare e promuovere la visibilità.
Pensare e lavorare in modo olistico.
Mantenere semplicità e praticità.
Ottimizzare e automatizzare.

Se li osserviamo bene, questi principi non parlano soltanto di processi IT.

Parlano di buon senso organizzativo.

Dicono di non perdere di vista il valore. Di non buttare via ciò che esiste senza averlo compreso. Di non provare a cambiare tutto in una volta. Di ascoltare. Di collaborare. Di vedere il sistema nel suo insieme. Di semplificare prima di complicare. Di automatizzare solo dopo aver ottimizzato.

Sono principi che funzionano perché spostano l’attenzione dal “fare attività” al “creare valore”.

Ed è esattamente ciò che dovrebbe fare un buon modello di service management.

Perché tecnologia, persone e processi non bastano se non sono allineati.

C’è una frase che, nelle organizzazioni, si sente spesso:

“Abbiamo persone competenti, buoni strumenti e processi definiti.”

Ottimo. Ma non basta.

Il problema non è quasi mai la presenza isolata di persone, strumenti o processi. Il problema è il modo in cui questi elementi lavorano insieme.

Un team può essere competente, ma bloccato da procedure inutilmente complesse. Un processo può essere ben disegnato, ma ignorato perché poco pratico. Uno strumento può essere potente, ma configurato in modo distante dalle esigenze reali. Una metrica può essere corretta, ma incentivare comportamenti sbagliati. Una comunicazione può essere formalmente completa, ma incomprensibile per chi la riceve.

Il valore non nasce dalla somma degli elementi. Nasce dalla loro integrazione.

Questo è uno dei punti più importanti del service management.

Pensare che basti aggiungere tecnologia per migliorare un servizio è una scorciatoia pericolosa. Pensare che basti scrivere una procedura per cambiare i comportamenti è ingenuo. Pensare che basti misurare un indicatore per governare la qualità è riduttivo.

La gestione dei servizi richiede allineamento.

Allineamento tra ciò che il cliente si aspetta e ciò che l’organizzazione può realmente offrire.
Allineamento tra ciò che il management misura e ciò che gli utenti percepiscono.
Allineamento tra ciò che i processi prescrivono e ciò che le persone riescono davvero a fare.
Allineamento tra automazione e comprensione del processo.
Allineamento tra obiettivi strategici e operatività quotidiana.

Quando questo allineamento manca, il servizio comincia a produrre attrito.

A volte l’attrito è visibile: incident ricorrenti, ticket aperti male, escalation continue, utenti insoddisfatti, tempi fuori controllo.

Altre volte è meno evidente: persone che aggirano i processi, team che non condividono informazioni, strumenti usati solo perché obbligatori, report che nessuno legge davvero, riunioni in cui si parla molto ma si decide poco.

Sono tutti segnali.

Il service management maturo non li considera semplici fastidi operativi. Li considera informazioni.

Perché ogni frizione racconta qualcosa del servizio.

Un ticket ricorrente può indicare un problema di progettazione. Una richiesta compilata male può indicare un canale poco chiaro. Un utente che contatta sempre la persona “di fiducia” invece di usare il portale può indicare sfiducia nello strumento. Un processo aggirato può indicare che quel processo è troppo pesante rispetto al valore che produce.

Il service management serve anche a questo: leggere i segnali deboli prima che diventino problemi strutturali.

Il service desk come punto di contatto tra servizio e realtà.

Dentro questo quadro, il service desk ha un ruolo particolarmente importante.

Non perché debba risolvere tutto.
Non perché debba farsi carico di ogni inefficienza.
Non perché debba essere il contenitore finale di ogni problema organizzativo.

Il service desk è importante perché si trova nel punto in cui il servizio incontra la realtà.

È lì che emergono le frizioni tra ciò che è stato progettato e ciò che viene effettivamente vissuto. È lì che gli utenti trasformano la propria esperienza in richieste, segnalazioni, dubbi, lamentele, domande, feedback. È lì che la distanza tra promessa e percezione diventa visibile.

Per questo un’organizzazione che vuole fare service management in modo serio non può considerare il service desk solo come una funzione di risposta.

Il service desk è un sensore.

Raccoglie segnali sul funzionamento del servizio, sulla chiarezza dei processi, sull’efficacia della comunicazione, sulla qualità della documentazione, sull’impatto dei cambiamenti, sulle difficoltà ricorrenti e sulle aspettative degli utenti.

Naturalmente, questi segnali non diventano valore da soli.

Se restano chiusi nei ticket, servono solo a risolvere casi singoli. Se vengono analizzati, discussi e collegati al governo del servizio, possono diventare materiale prezioso per migliorare.

Qui si vede la differenza tra un’organizzazione che “gestisce ticket” e una che “governa servizi”.

La prima conta quante richieste entrano ed escono.
La seconda si chiede cosa stanno raccontando quelle richieste.

La prima misura il carico operativo.
La seconda interpreta il comportamento del servizio.

La prima punta a chiudere.
La seconda punta ad apprendere.

Questo non significa rallentare l’operatività o trasformare ogni ticket in un’indagine strategica. Significa costruire un modello in cui le informazioni raccolte dal service desk possano risalire verso chi progetta, governa e migliora il servizio.

Perché se il service desk vede ogni giorno lo stesso problema, ma quel problema non entra mai nelle decisioni di miglioramento, il servizio non sta imparando.

Sta solo resistendo.

Dal risultato finale al modo in cui viene raggiunto.

Una delle trappole più diffuse nelle organizzazioni è concentrarsi esclusivamente sul risultato finale.

Il servizio è attivo.
Il ticket è chiuso.
Il progetto è consegnato.
La richiesta è stata evasa.
L’indicatore è rispettato.

Tutto vero. Ma il service management dovrebbe aggiungere una domanda:

“A quale costo organizzativo?”

Non solo costo economico. Anche costo operativo, relazionale, cognitivo, esperienziale.

Un ticket può essere chiuso nei tempi previsti, ma dopo tre passaggi inutili tra team. Una richiesta può essere evasa, ma costringendo l’utente a fornire informazioni già presenti in altri sistemi. Un cambiamento può essere rilasciato, ma senza comunicare adeguatamente l’impatto a chi dovrà supportarlo. Un’automazione può ridurre un’attività manuale, ma rendere più difficile capire cosa accade quando qualcosa va storto.

Il punto non è solo arrivare al risultato.

Il punto è come ci si arriva.

Nel service management il “come” conta moltissimo, perché il modo in cui un servizio viene erogato influenza direttamente la percezione di valore.

Un utente non valuta solo se il problema è stato risolto. Valuta quanto è stato semplice chiedere aiuto, quanto è stata chiara la comunicazione, quanto tempo ha dovuto aspettare, quante volte ha dovuto ripetere le stesse informazioni, quanto si è sentito ascoltato, quanto il supporto è stato coerente con le sue aspettative.

Questo vale anche all’interno dell’organizzazione.

Un processo che raggiunge il risultato ma consuma energie eccessive non è sostenibile. Un modello di gestione che funziona solo grazie alla buona volontà di alcune persone non è robusto. Un servizio che si regge su workaround informali non è davvero governato.

Il service management maturo cerca di rendere il valore sostenibile.

Non si accontenta dell’eroismo operativo. Non costruisce il servizio sulla disponibilità infinita delle persone. Non considera normale che ogni problema venga risolto solo grazie all’esperienza individuale di chi “sa dove mettere le mani”.

Un servizio sano deve poter funzionare bene senza dipendere costantemente dall’eccezione.

Questo non significa eliminare il contributo umano. Significa valorizzarlo meglio.

Le persone dovrebbero essere usate per comprendere, decidere, migliorare, collaborare, interpretare. Non per compensare continuamente processi fragili, strumenti confusi e responsabilità poco chiare.

Il vero obiettivo del service management.

Alla fine, il vero obiettivo del service management non è avere processi perfetti.

Non è avere lo strumento migliore.
Non è produrre report più belli.
Non è riempire l’organizzazione di procedure.
Non è usare un linguaggio più sofisticato.
Non è nemmeno applicare ITIL in modo impeccabile.

Il vero obiettivo è permettere ai servizi di generare valore in modo consapevole, sostenibile e migliorabile.

Consapevole, perché l’organizzazione deve sapere quale valore vuole creare, per chi, attraverso quali servizi e con quali priorità.

Sostenibile, perché un servizio non può funzionare solo spremendo persone, moltiplicando eccezioni o nascondendo complessità dietro la buona volontà dei team.

Migliorabile, perché ogni servizio vive in un contesto che cambia. E se non viene osservato, ascoltato e adattato, prima o poi smette di rispondere alle esigenze reali.

Questa è la differenza tra gestire servizi e fare service management.

Gestire servizi può significare mantenere in piedi qualcosa.
Fare service management significa chiedersi continuamente se quel qualcosa sta ancora creando valore.

È una disciplina tecnica, certo. Ma è anche una disciplina organizzativa, relazionale e culturale.

Richiede processi, ma anche buon senso.
Richiede metriche, ma anche interpretazione.
Richiede tecnologia, ma anche ascolto.
Richiede governance, ma anche collaborazione.
Richiede automazione, ma solo dopo aver compreso e semplificato ciò che si vuole automatizzare.

Per questo il service management non dovrebbe essere percepito come una sovrastruttura burocratica.

Dovrebbe essere visto come un modo per rendere il servizio più leggibile, più utile e più vicino alla realtà di chi lo utilizza.

La domanda finale, allora, non è:

“Stiamo gestendo correttamente il servizio?”

La domanda finale è:

“Stiamo aiutando qualcuno a raggiungere il proprio obiettivo nel modo migliore possibile?”

Se la risposta è sì, il service management sta facendo il suo lavoro.

Se la risposta è no, non importa quanti processi abbiamo disegnato, quante dashboard abbiamo costruito o quanti ticket abbiamo chiuso.

Il servizio non sta ancora creando abbastanza valore.