✕ Chiudi e torna alla Home
ITIL4 & Service Management

ITIL4 è noioso da spiegare. Quindi ho usato un backstage fotografico.

Scritto da Riccardo Dall'Amico · Post #5
Illustrazione concettuale Riccardo Dall'Amico: la gestione dei flussi organizzativi ITIL4 descritta attraverso la pianificazione di un set fotografico

Spiegare il framework ITIL4 in azienda è il modo più rapido per far addormentare un'intera platea di non tecnici. I manuali ufficiali sono densi di definizioni astratte, acronimi e tabelle di flussi che sembrano progettati appositamente per rendere complicato ciò che in realtà è pura logica organizzativa. Per questa ragione, ho scelto di applicare le sue tre pratiche pilastro direttamente sul campo di un backstage fotografico.

L'obiettivo di ITIL4 non è appesantire il lavoro con passaggi burocratici, ma evitare che l'improvvisazione permanente diventi l'unico Piano B dell'organizzazione. Nel mio quotidiano, sia che gestisca un'anomalia di rete LAN multisito, sia che coordini un set editoriale di precisione, il metodo operativo rimane identico.

L'analogia: Un set fotografico complesso condivide la stessa struttura di un servizio IT: ci sono risorse fisse, finestre temporali rigide dettate dalla luce o dalle disponibilità dei partner e un deliverable che deve soddisfare requisiti stringenti. Gestire l'imprevisto in questi due mondi richiede gli stessi identici strumenti mentali.

1. Incident Management: Quando la luce salta a metà shooting

Se durante una sessione fotografica un flash si spegne o un trigger smette di dialogare con l'otturatore, non c'è spazio per il panico o per lunghe speculazioni teoriche sulla causa termica del guasto. Devi portare a casa lo scatto con le risorse disponibili nell'immediato. Questa urgenza è la definizione esatta di Incident Management: ripristinare il corretto livello del servizio il più rapidamente possibile, riducendo al minimo l'impatto sul business (o sulla modella che sta posando).

Apri il kit di emergenza, usi una luce continua ausiliaria di ripiego, documenti il disservizio nei tuoi appunti e prosegui. Non hai risolto il problema di fondo, ma hai aggirato il sintomo per salvare il go-live del progetto.

2. Change Management: Modificare il brief in corso d'opera

A metà shooting il partner artistico osserva il monitor di controllo e dice: "L'atmosfera è bellissima, ma adesso vorrei cambiare completamente schema e passare a una luce drammatica ad alto contrasto". In ITIL4 questo scenario si chiama Change Request.

Non si modificano i parametri hardware in produzione senza aver prima valutato l'impatto. Devi calcolare al volo i tempi necessari per ritarare l'esposimetro, verificare se i nuovi modificatori di luce o le gelatine colore andranno in conflitto con le texture del gioiello e valutare se la finestra temporale residua consente la variazione dello scope. Se l'analisi del rischio dà esito positivo, approvi la modifica ed esegui con metodo, aggiornando la documentazione di set.

3. Problem Management: Capire la causa radice

Una volta terminata la giornata lavorativa e archiviati i file RAW in sicurezza sul cloud aziendale, inizia la fase del Problem Management.Ti siedi al tavolo di diagnostica con calma e analizzi il flash che è saltato durante la prima fase.

L'obiettivo qui non è più aggirare il sintomo, ma identificare la Root Cause (la causa radice). Smonti l'hardware, controlli i log d'errore e verifichi se il problema risiedeva in un surriscaldamento del firmware o in un difetto elettrico del condensatore. Sostituisci il pezzo o aggiorni il microcodice: solo in questo momento puoi chiudere definitivamente il ticket permanente, garantendo che quell'anomalia non si ripresenterà mai più sul prossimo set critico.

Il Service Catalog del quotidiano

Ogni attrezzatura catalogata nella borsa fotografica, con i suoi tempi di ricarica, pesi e limiti di focale, costituisce a tutti gli effetti un Service Catalog. Sapere esattamente cosa può fare ogni singolo strumento e in quali tempi ti evita di promettere scatti macro da copertina usando un grandangolo grandioso ma inadatto al microscopico.

I framework di processo non nascono per limitare l'estro creativo dell'IT Manager o del fotografo. Esistono per strutturare il caos del backend, permettendoti di operare in sicurezza anche quando l'ambiente esterno cambia improvvisamente regole.

E nella tua trincea?

Di fronte a un guasto improvviso nei tuoi sistemi, operi seguendo una procedura di ripristino ordinata e tracciabile o ti affidi all'adrenalina del momento, rimandando la ricerca della causa a quando avrai tempo (ovvero mai)?