Le interruzioni informatiche costano alle aziende italiane 425 milioni di euro l’anno, con una media di undici ore di fermo per ciascuna, e nella maggior parte dei casi coinvolgono sistemi critici per le vendite, le operazioni e il bilancio.
Dietro quella cifra c’è quasi sempre la stessa scena, ripetuta migliaia di volte al giorno in aziende diverse, un operatore che scansiona un collo e il sistema non risponde oppure una schermata di carico che si blocca a metà operazione.
In un magazzino o su una flotta di trasporto, quella scena non resta un errore isolato, si propaga. SIGEP Logistics e SIGEP Transport governano il ricevimento della merce, la movimentazione, le operazioni di banchina, il tracciamento delle spedizioni, e ogni fase è collegata alla successiva. Se il sistema non registra lo scarico di un camion, quel camion resta fermo al portone, la banchina resta occupata, e l’ordine successivo in coda deve aspettare il suo turno.
È per questo che GEP Informatica costruisce il proprio servizio di assistenza attorno a un’idea semplice, la logistica non si ferma, e per chi lo richiede l’Help Desk resta attivo 24 ore su 24, 7 giorni su 7. Dietro quella disponibilità, però, non c’è mai una persona sola davanti a un telefono che risponde come capita, c’è un modello pensato apposta per reggere il peso di un’emergenza.
Ma cosa succede davvero dietro le quinte da quando un cliente segnala un problema a quando quel problema smette di esistere? Lo abbiamo chiesto a chi in GEP si occupa ogni giorno di questo passaggio, dal primo campanello d’allarme fino al momento in cui il cliente torna a lavorare come se nulla fosse successo.
C'è un team dedicato che si occupa di queste emergenze, o dipende da chi capita?
Non capita mai per caso, e questo è il punto.
Chi risponde in un momento di emergenza segue un percorso che GEP ha costruito apposta, così che ogni cliente riceva la stessa attenzione, che il problema sia semplice o richieda una competenza più specialistica. Il primo livello è il punto di contatto immediato, riceve il ticket, lo classifica e se rientra tra le situazioni già conosciute lo risolve subito, senza passaggi inutili. Quando invece serve qualcosa in più, una configurazione da verificare, un comportamento anomalo dell’applicativo, una causa che non emerge a un primo sguardo, il ticket arriva dritto a chi ha una competenza più specialistica, quello che chiamiamo secondo livello.
Il vantaggio si vede soprattutto nei momenti peggiori, un problema serio non gira da una persona all’altra finché qualcuno per caso lo risolve, arriva subito a chi sa già come affrontarlo.
Come si riconosce tra decine di segnalazioni quella che non può aspettare?
Non è la complessità tecnica a decidere l’urgenza di una segnalazione, ma quello che sta succedendo dall’altra parte.
Un ticket può descrivere un errore piccolissimo e restare comunque il primo della lista se quell’errore sta bloccando un’attività che il cliente deve svolgere in quel preciso momento, un carico che deve partire, una banchina che deve liberarsi. Pensiamo a un ordine che deve lasciare il magazzino prima del taglio orario di un corriere, o a una banchina che resta occupata perché il sistema non registra più lo scarico.
In quei casi il ticket non racconta solo un errore software, ma racconta un camion che aspetta, una squadra che non sa come procedere, un orario che si sta esaurendo. Ecco perché, più che la gravità dell’errore in sé, guardiamo a cosa sta bloccando, se dietro c’è un’attività che il cliente non può rimandare, quella segnalazione supera tutte le altre, anche quelle arrivate prima.
Chi parla con chi, mentre un problema resta ancora aperto?
La comunicazione durante un’urgenza corre su due canali distinti, e nessuno dei due può mancare. Da una parte i colleghi, chi segue il ticket dal primo momento e chi se ne occupa nell’analisi più approfondita si scambiano in tempo reale quello che stanno scoprendo, così nessuno dei due passaggi riparte da zero o lavora su una versione diversa della stessa situazione.
Dall’altra il cliente, che non riceve solo un messaggio di apertura e uno di chiusura, ma un aggiornamento a ogni stadio di avanzamento, così sa sempre a che punto siamo, anche prima che la soluzione sia arrivata. Non è un dettaglio secondario, è tenere il cliente dentro il percorso, sapere che qualcuno se ne sta occupando conta quasi quanto la soluzione stessa, soprattutto nei minuti in cui l’attività è ancora bloccata.
Quando si può dire davvero che un ticket è chiuso?
Non chiudiamo un ticket perché da parte nostra il problema sembra risolto. Lo chiudiamo quando è il cliente stesso a certificare che è ripartito, che l’operazione che si era bloccata, un ordine, una spedizione, un’anagrafica, sta di nuovo scorrendo come previsto, magari con la stessa persona che aveva segnalato il blocco a confermare che il picking è tornato a girare. È quella certificazione, non un controllo interno, a dirci che il lavoro è davvero finito. Solo a quel punto il ticket si chiude per davvero, e non con un semplice avviso che “il problema è stato preso in carico”.
Undici ore di fermo l’anno raccontano un costo, ma non raccontano la parte più importante della storia.
Quella si vede quando il sistema si rompe davvero, e qualcuno dall’altra parte si assume la responsabilità di rimetterlo in piedi prima che un magazziniere debba spiegare a qualcun altro perché il camion è ancora fermo al portone. È lì, in quei minuti che si capisce se un servizio di assistenza vale il nome che porta.
