/
/

Come gli MSP possono creare un catalogo di “workaround noti” per una risoluzione dei problemi più rapida

di Raine Grey, Technical Writer   |  
translated by Chiara Cavalletti
Come gli MSP possono creare un catalogo di "workaround noti" per una risoluzione dei problemi più rapida immagine del banner del blog

Per quanto puoi configurare bene il dispositivo Windows, è possibile che in tutti gli ambienti client si verifichino anomalie persistenti, come ad esempio l’interruzione della connessione VPN o l’impossibilità di stampare in remoto. Senza un registro o un database centrale, i tecnici IT possono perdere molto tempo a reinventare le soluzioni o ad applicare soluzioni incoerenti.

È qui che un catalogo di workaround può rivelarsi utile. Organizzando le soluzioni in  categorie strutturate di SOP, gli MSP possono convertire la risoluzione dei problemi ad hoc in una knowledge base condivisa e ricercabile. Questa struttura consente a ogni tecnico di risolvere i problemi in modo più rapido, coerente e meno frustrante.

In sintesi:

  • Che cos’è un catalogo di workaround? È un archivio centrale che memorizza i problemi tecnici ricorrenti e le relative soluzioni alternative temporanee.
  • Il catalogo dei workaround aumenta l’efficienza: i tecnici possono evitare di perdere tempo a reinventare soluzioni per problemi comuni.
  • Perché le categorie SOP sono importanti: l’organizzazione delle voci in categorie chiare migliora la ricercabilità e la coerenza.
  • Metodi di acquisizione facili: l’uso di moduli semplici assicura ai tecnici una rapida registrazione delle riparazioni come parte del loro flusso di lavoro.
  • Esaminare regolarmente i cataloghi dei workaround: le verifiche periodiche mantengono il catalogo accurato, affidabile e degno di essere utilizzato.

📌 Prerequisiti:

Prima di iniziare, assicurati di avere:

  • Una piattaforma di documentazione condivisa: può trattarsi di un foglio di calcolo cloud (Google Sheets, Excel Online), di uno strumento di documentazione (Confluence, Notion) o di un sistema di documentazione IT come NinjaOne Documentation.
  • Accordo sulla struttura del catalogo e sulla proprietà: decidi in anticipo come saranno organizzate le voci (colonne, tag, formato Bug ID) e chi manterrà il catalogo. Idealmente, un tecnico senior dovrebbe supervisionare la struttura, gli standard di denominazione e la pulizia periodica.
  • Un metodo di acquisizione per semplificare l’aggiunta di nuove voci da parte dei tecnici. Un modulo di Google legato a un foglio è un’opzione semplice, ma se il tuo team preferisce script, PowerShell o moduli interni, possono funzionare altrettanto bene.
  • Una cadenza di revisione: stabilisci un ritmo di revisione regolare (ad esempio, audit trimestrali). Durante le revisioni, assicurati che le soluzioni siano ancora valide, rimuovi i duplicati e segnala le correzioni che sono diventate permanenti. Con il tempo, questo processo renderà il tuo catalogo più affidabile e attendibile.

Fase 1: Imposta un semplice catalogo di soluzioni alternative tabellare

Inizia con una tabella chiara e strutturata. Il formato del foglio di calcolo funziona bene perché è flessibile, facile da modificare e familiare alla maggior parte dei tecnici. Ecco un esempio:

ID del bugContesto ambientaleSintomiWorkaround
BUG-001Windows 10 + VPN v1.2.3La VPN si disconnette dopo 5 minutiDisattivare il risparmio energetico della NIC: powercfg -change -standby-timeout-ac 0

Questo formato assomiglia a un database di errori noti ITIL (KEDB). Acquisendo l’ambiente, i sintomi e le soluzioni alternative, è più facile per chiunque nel tuo team identificare rapidamente i problemi ricorrenti e applicare le soluzioni in modo coerente.

💡 Suggerimento: mantieni gli ID dei bug brevi e sequenziali (ad esempio, BUG-001, BUG-002). I sistemi di numerazione complessi possono confondere i tecnici IT.

Fase 2: Archiviare in un formato collaborativo e ricercabile

Un foglio di calcolo è ottimo per la semplicità, ma con l’aumentare delle voci si potrebbe desiderare una piattaforma con funzionalità di ricerca e collegamento più efficaci.

Raccomandiamo:

  • Fogli Google/Excel online: queste opzioni gratuite sono veloci, facili da configurare e adatte a team di piccole e medie dimensioni.
  • Confluence/Wiki interno: queste opzioni sono migliori per i team più grandi, dove la ricerca, le autorizzazioni e i collegamenti tra i documenti sono importanti.
  • IT Glue o strumenti ITSM simili: questi strumenti sono progettati per la documentazione degli MSP e spesso sono già integrati nei flussi di lavoro. Se vuoi altri suggerimenti, consulta la nostra guida “I 10 migliori strumenti ITSM nel 2025.”

💡 Suggerimento: testa sempre la ricercabilità del tuo catalogo. Prova a cercare le voci per sintomo, ambiente o tag per vedere quanto è facile recuperare i risultati.

Fase 3: Acquisizione di workaround con l’uso di input basati su moduli

La sfida più grande per qualsiasi knowledge base è quella di convincere le persone a contribuire. Se i tecnici devono aprire un foglio di calcolo, cerca la riga giusta e digita i dettagli, lo eviteranno, soprattutto quando devono gestire più ticket.

Ecco perché l’utilizzo di un semplice modulo è un vero e proprio cambiamento di rotta. Invece di modificare direttamente il catalogo, i tecnici rispondono a poche domande e il sistema si occupa del resto.

Ecco come funziona in pratica:

  1. Un tecnico risolve un problema ricorrente. Ad esempio, una VPN che cade dopo pochi minuti.
  2. Prima di chiudere il ticket, compila un breve modulo con campi quali:
    • Ambiente (ad esempio, Windows 11 + Cisco VPN client v2.5)
    • Sintomi (ad esempio, la VPN si disconnette dopo essere stata inattiva)
    • Soluzione (ad esempio, disabilitare il risparmio energetico della NIC)
    • Tags ([VPN], [Windows 11])
  3. Non appena il modulo viene inviato, viene creata automaticamente una nuova riga nel catalogo.

Opzioni dello strumento per l’acquisizione delle voci

  • Google Form + Fogli: come descritto nella fase precedente, queste opzioni sono in genere preferite all’inizio perché sono gratuite. Ogni invio di modulo diventa una nuova riga nel foglio di calcolo del catalogo condiviso.
  • Componenti aggiuntivi del service desk: alcuni sistemi di ticketing (come Zendesk, Autotask o ConnectWise) consentono di creare moduli che vengono inseriti direttamente nella knowledge base.
  • Script: puoi automatizzare i prompt con PowerShell o Python, in modo che dopo la chiusura di un ticket venga chiesto al tecnico di inserire i dettagli del workaround.

L’utilizzo di un modulo di input (o di un modello) riduce l’attrito, perché i tecnici non devono preoccuparsi della formattazione o di dove inserire le informazioni: devono solo riempire gli spazi vuoti. Questo non solo garantisce la coerenza (in quanto ogni voce viene acquisita con la stessa struttura e lo stesso ordine), ma riduce anche in modo significativo l’errore umano.

Fase 4: Incorporare il collegamento degli incidenti durante la chiusura dei ticket

Quando si chiude un ticket, è consigliabile aggiungere una nota rapida che colleghi l’incidente al catalogo, come ad esempio: “Workaround registrato come BUG-002 nel catalogo.” In questo modo si crea un chiaro collegamento tra i ticket attivi e la base di conoscenza condivisa.

Questa abitudine non solo rafforza l’idea che la documentazione faccia parte del flusso di lavoro dell’assistenza, ma crea anche uno storico dei problemi ricorrenti e delle relative soluzioni. Collegando i biglietti agli ID dei bug, faciliterai la stesura dei rapporti e mostrerai il valore aggiunto del catalogo nel tempo.

Fase 5: Etichettatura e categorizzazione per una rapida ricerca

Aggiungi una colonna Tag al tuo catalogo, in modo che i tecnici possano filtrare e cercare rapidamente. Mantieni i tuoi tag brevi, chiari e coerenti. Per esempio:

  • [VPN] per problemi di connessione
  • [Citrix] per gli errori delle applicazioni remote
  • [Stampa] per le stranezze dei driver
  • [Windows 11] per i bug specifici del sistema operativo

Questo passaggio semplifica la funzionalità di ricerca. Puoi vedere la situazione da questo punto di vista: Quando un tecnico IT è sotto pressione, non ha il tempo di scorrere decine di voci. Tag e categorie SOP coerenti rendono il catalogo molto più ricercabile e riducono le perdite di tempo.

💡 Suggerimento: crea e condividi un elenco master di tag con il proprio team. In questo modo si evitano duplicati come [VPN] vs. [VPN Issue], che possono interrompere le ricerche. Aggiorna l’elenco durante le revisioni trimestrali, in modo che i tag si evolvano con il tuo ambiente.

Fase 6: Audit e convalida periodica

L'”ultima” fase è un processo continuo. Tieni presente che la tua knowledge base sugli errori noti deve essere una risorsa viva. È buona norma programmare revisioni trimestrali per:

  • Verificare nuovamente i workaround funzionano ancora con le versioni più recenti del sistema operativo, delle patch o delle app.
  • Rimuovere le voci obsolete che non sono più valide.
  • Consolidare i duplicati in modo che problemi simili siano raggruppati in un unico ID dei bug.
  • Aggiornare le note e i tag per riflettere nuovi ambienti o terminologia.

Sintesi delle best practice

ComponenteValore
Formato del catalogo strutturatoFa in modo che ogni workaround sia documentato allo stesso modo, riducendo la confusione e rendendo le voci più facili da analizzare e confrontare.
Archiviazione condivisa ricercabileFornisce accesso immediato ai workaround durante la risoluzione dei problemi dal vivo, evitando ai tecnici di scavare nelle e-mail, negli appunti o nella memoria.
Aggiornamenti basati sulla formaSemplifica il processo di aggiunta di nuove voci, in modo che i tecnici possano acquisire le correzioni in pochi secondi senza interrompere il loro flusso di lavoro.
Utilizzo legato al ticketRafforza la cultura della documentazione collegando gli incidenti reali alle voci del catalogo, creando una storia tracciabile dei problemi ricorrenti.
EtichettaturaAccelera la risoluzione dei problemi consentendo ai tecnici di filtrare e trovare istantaneamente le soluzioni pertinenti, anche sotto pressione.
Audit trimestraliMantieni il catalogo accurato e affidabile, eliminando le correzioni obsolete e garantendo che i tecnici continuino ad affidarsi ad esso con fiducia.

Esempio di touchpoint di automazione

Ecco una configurazione pratica che utilizza Google Forms + Fogli:

  1. Un tecnico risolve un problema (ad esempio, un client Citrix che si blocca all’accesso).
  2. I pazienti inviano un modulo Google con l’ambiente, i sintomi, i rimedi e i tag.
  3. La voce del modulo si aggiunge automaticamente al foglio condiviso con un nuovo ID del bug.
  4. Altri tecnici fanno riferimento al foglio durante i futuri ticket, cercando per tag o sintomi.
  5. Trimestralmente, colui che si occupa della KB rivede il foglio per eliminare i duplicati, aggiornare i tag e verificare le soluzioni.

💡 Suggerimento: utilizza la formattazione condizionale o un semplice codice colore nel foglio (ad esempio, verde per verificato, giallo per in attesa di revisione, rosso per obsoleto). Questo fornisce ai tecnici indicazioni visive immediate sull’affidabilità di ogni voce.

Come utilizzare NinjaOne per le categorie SOP

Sebbene NinjaOne non includa un catalogo di workaround integrato, è comunque possibile utilizzare la piattaforma di gestione degli endpoint nei propri flussi di lavoro.

Ecco alcuni suggerimenti:

  • Inserimento del link al catalogo: aggiungi un link diretto al tuo catalogo di workaround (foglio Google, pagina Confluence, ecc.) nei campi della documentazione di NinjaOne, in modo che i tecnici possano accedervi senza lasciare la console. Leggi la nostra guida “Capire l’importanza della documentazione per una gestione IT efficace” per ulteriori informazioni.
  • Utilizza campi personalizzati: crea un campo “ID workaround” nei moduli di incidente/richiesta. In questo modo è facile etichettare i ticket con ID del bug e collegarli alle voci del catalogo.
  • Riferimento ai workaround negli script o negli avvisi: quando si creano script di automazione o si configurano gli avvisi, includere nelle descrizioni le note di catalogo o gli ID dei bug. Questo aiuta i tecnici a collegare più velocemente gli avvisi con i problemi noti.
  • Report sull’utilizzo del catalogo: traccia il numero di ticket risolti utilizzando soluzioni documentate. In questo modo dimostrerai alla direzione (e ai clienti) il ritorno di investimento del mantenimento del catalogo.

Creare KEDB per una più rapida risoluzione dei problemi

Una knowledge base degli errori noti trasforma l’assistenza MSP da lotta reattiva alle emergenze in un processo ripetibile e basato sulla conoscenza. Documentando le correzioni, archiviandole in un formato condiviso e ricercabile e rafforzandone l’utilizzo attraverso i ticket, il team costruisce una risorsa affidabile che diventa sempre più preziosa nel tempo.

Argomenti correlati:

FAQs

Un database di errori noti è stato progettato per accelerare la risoluzione degli incidenti, offrendo ai tecnici un luogo centrale dove consultare i problemi ricorrenti e le relative soluzioni. Invece di risolvere i problemi da zero ogni volta, i tecnici possono fare riferimento al KEDB per trovare soluzioni collaudate, applicarle in modo coerente e ridurre al minimo i tempi di inattività delle operazioni IT. Per gli MSP, inoltre, aiuta a standardizzare l’assistenza tra i diversi clienti e ambienti.

Una soluzione alternativa o workaround è una soluzione temporanea che consente di continuare le normali operazioni anche se la causa principale del problema non è stata risolta. Come suggerisce il nome, un workaround per errori noti non elimina il bug in modo permanente, ma ne ripristina la funzionalità fino a quando non sarà disponibile una soluzione definitiva.

Il KEDB è un concetto della Information Technology Infrastructure Library (ITIL) che agisce come una base di conoscenza specializzata. Memorizza i dettagli degli errori noti, compresi i sintomi, l’ambiente, la causa principale (se nota) e le soluzioni documentate.

You might also like

Pronto a semplificare le parti più complesse dell'IT?