Il processo di ticket IT come modello di calcolo pronto

Ingresso: 24 000 ticket all'anno, quindi circa 96 in un giorno lavorativo, con una dispersione giornaliera del 28% e un fattore di picco di 1,35 nell'8% dei giorni. Montaggi, rollout, guasti.

La colonna «Percentuale» è il motivo per cui questo modello si legge diversamente dagli altri: il secondo livello vede solo un terzo dei ticket. Se si confronta il suo utilizzo con l'intero volume, si ottiene il 155% e si considera sovraccaricato un passo che invece mostra 57%.

La constatazione decisiva. Probabilità di collo di bottiglia per passo su 20 000 esecuzioni:

La colonna somma a 100%: in ogni esecuzione si conta esattamente un passo vincolante, quello con il più alto utilizzo in quel giorno.

Il secondo livello, indicato internamente come causa dei lunghi tempi di processo, lo è nel 14% delle esecuzioni. Il Servicedesk, il punto in cui un ticket viene solo registrato per cinque-dieci minuti, lo è nel 75%. Il processo perde tempo prima del lavoro, non durante.

Ed è qui che una tabella fallisce: cinque minuti per ticket passano inosservati. 96 volte cinque-dieci minuti non lo sono.

1. Ticket per giorno lavorativo. Ticket dell'ultimo anno ÷ giorni lavorativi. È nel report dell'helpdesk, e precisamente dove vengono contati anche i ticket duplicati e collettivi. Usare la stessa definizione che userà in seguito per la misurazione.
2. Fattore di picco. Quanti ticket arrivano nel giorno più intenso rispetto a un giorno normale? Lunedì, il giorno dopo un rollout, il giorno di una interruzione. Un fattore 1,3–2 è usuale. Senza questo valore si calcola un Servicedesk che non è mai sotto carico, mentre il carico è lo stato normale per i ticket.
3. Persone nel Servicedesk e loro ore per la triage. Non il numero di teste del team. Chi risponde anche al telefono non ha otto ore per la registrazione.
4. Intervallo di lavorazione della triage. Estremo inferiore e superiore. Cinque minuti per una password, venti per una segnalazione di guasto che va prima ricostruita. È proprio questo intervallo a generare il tempo di attesa.
5. Percentuale di risolti immediatamente. Nella base 65 contro 35. Questo numero figura in ogni report dell'helpdesk come «First Contact Resolution» ed è l'unico che si possa realmente misurare. Sposta il carico tra i rami, non davanti ad essi.
6. Tariffe full-cost per ruolo. Stipendio lordo × 1,5–1,8, diviso per circa 1 500 ore produttive all'anno. Con 24 000 pratiche all'anno ogni euro di differenza nella tariffa pesa; una tariffa ingenua calcolata come stipendio ÷ 2 080 ore rende la stima in euro contestabile.

Controllo incrociato, prima di calcolare: Conti i ticket aperti nel sistema e li divida per i ticket che chiude in un giorno (Little's Law). Se ne risulta il tempo di percorrenza che conosce, il modello è utilizzabile. Se differisce molto, manca una coda; per i ticket quasi sempre lo stato «in attesa di riscontro dall'utente».

Cosa non contiene il modello. Il tempo di percorrenza è lavorazione più coda in giorni lavorativi. La priorizzazione non è modellata: il modello lavora in ordine di arrivo. Chi ha una vera prioritizzazione la rappresenti come un secondo ramo con capacità propria; altrimenti il modello calcola troppo lento per i ticket urgenti e troppo veloce per gli altri. Non sono inoltre incluse: pause in cui un ticket attende l'utente.

Leva 1. Un modulo in ingresso. Campi obbligatori per dispositivo, applicazione, sintomo e priorità. La triage passa da 5–10 a 3–6 minuti perché non serve più ricostruire la richiesta. Effetto: il P90 del tempo di attraversamento da 4,9 a 0,22 giorni lavorativi, il carico nel giorno di punta da 129 % a 77 %. La leva più economica sul campo e l’unica che non richiede personale.

Leva 2. Una terza persona al service desk. Produce anch’essa un effetto netto (0,38 giorni), ma costa un posto di lavoro. Il rapporto con la leva 1 è il vero messaggio di questa tabella.

Leva 3. Knowledge base che intercetta il 20 % dei ticket. Meno ticket è sempre meglio, ma non risolve il collo di bottiglia: nella maggior parte (75 %) delle simulazioni la triage resta il passo vincolante, la sua saturazione scende solo da 129 % a 103 % nel giorno di punta. Un quinto in meno di volume porta appena oltre la linea un passo, non di più.

Leva 4. Più ticket risolti al primo livello. La constatazione più interessante di non-beneficio. Alzare la first-contact-resolution dal 65 al 75 % è la raccomandazione standard nel supporto, e funziona: il costo di lavoro per ticket scende da 28,82 € a 25,34 €, perché minuti costosi di secondo livello vengono sostituiti da minuti più economici di primo livello. Il tempo di attraversamento non diminuisce; anzi cresce leggermente a 5,0 giorni. La leva fa risparmiare soldi, non tempo. Chi la vende come misura per ridurre i tempi sta vendendo il messaggio sbagliato sulla stessa misura giusta.

Calcoli le quattro singolarmente e le ordini per effetto rispetto allo sforzo. La leva 1 è un modulo, la leva 2 un posto, e nel modello sono distanti 0,16 giorni.

Come da 20 000 esecuzioni si ricava una percentuale per passo è spiegato nell’articolo Monte-Carlo-Simulation für Prozesse; perché già l’85 % di saturazione è troppo, in Engpass berechnen.

Dallo stato attuale, da una leva modificata e da una seconda esecuzione il confronto mostra:

• Tempo di attraversamento prima/dopo come P50 e P90. Un impegno di servizio si dà rispetto al P90, non rispetto alla mediana. Proprio qui una dichiarazione SLA si distingue da un'affermazione sulla media: la mediana dice 0,08 giorni, e tuttavia l’impegno viene mancato un giorno ogni dieci.
• Saturazione per passo nel giorno di punta e il nuovo collo di bottiglia dopo la misura. In questo modello si sposta al primo livello per due delle quattro leve.
• Throughput come ticket per settimana rispetto agli arrivi: 455 di 480 nello stato attuale. La differenza è l’arretrato che il service desk si crea ogni settimana.
• Costi di lavoro per ticket e per anno, calcolati da volumi, tempi e costi completi. Con 24 000 processi qui conta ogni centesimo, il modello usa 28,82 € per ticket.
• La lista delle assunzioni con ogni input stimato. La frase «Priorisierung und Ruhezeiten sind nicht modelliert» toglie la punta alla domanda più severa prima che venga posta.

Viene emesso come due PDF: offerta per il decisore, documentazione per la tracciabilità, con la Sua intestazione se ne ha caricata una.

La stessa base, due domande. Questa pagina risponde alla domanda di calcolo: da dove vengono il 75% e perché un quinto dei ticket in meno non risolve il collo di bottiglia. L’altra domanda (cosa si consiglierebbe e quanto costa un ticket che resta aperto) appartiene al metodo e non allo strumento. Si trova nell’Archivio analisi di Flowrefy, insieme al Procedimento da cui queste basi sono nate. Un set di dati, due domande, due pubblici.

• Il processo di evasione ordini va dall'ordine fino alla conferma d'ordine. Il caso con un ruolo condiviso: due attività che singolarmente appaiono leggere sono il pomeriggio della stessa persona.
• Il processo di offerta è il caso in cui il tempo di attraversamento influisce sul fatturato invece che sui costi.
• Il rilascio fatture è il caso di volatilità: in media sotto la capacità, alla fine del mese sopra.
• Nel reclamo il collo di bottiglia è fuori dall'azienda, e la raccomandazione onesta perciò non è «automatizzare».
• Il onboarding dei dipendenti ha poco volume e molti partecipanti, e un'attività trattiene l'86 % delle esecuzioni.
• Il ticket IT è questa pagina.

Ogni modello si apre nella finestra di benvenuto tramite Visualizza modelli. La prima volta conviene aprirne uno prima di iniziare un proprio modello. Altrimenti si costruisce troppo nel dettaglio.