/
/

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 bug Contesto ambientale Sintomi Workaround
BUG-001 Windows 10 + VPN v1.2.3 La VPN si disconnette dopo 5 minuti Disattivare 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

Componente Valore
Formato del catalogo strutturato Fa 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 ricercabile Fornisce 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 forma Semplifica 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 ticket Rafforza la cultura della documentazione collegando gli incidenti reali alle voci del catalogo, creando una storia tracciabile dei problemi ricorrenti.
Etichettatura Accelera la risoluzione dei problemi consentendo ai tecnici di filtrare e trovare istantaneamente le soluzioni pertinenti, anche sotto pressione.
Audit trimestrali Mantieni 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?

Termini e condizioni NinjaOne

Cliccando sul pulsante “Accetto” qui sotto, dichiari di accettare i seguenti termini legali e le nostre condizioni d’uso:

  • Diritti di proprietà: NinjaOne possiede e continuerà a possedere tutti i diritti, i titoli e gli interessi relativi allo script (compreso il copyright). NinjaOne ti concede una licenza limitata per l’utilizzo dello script in conformità con i presenti termini legali.
  • Limitazione d’uso: Puoi utilizzare lo script solo per legittimi scopi personali o aziendali interni e non puoi condividere lo script con altri soggetti.
  • Divieto di ripubblicazione: In nessun caso ti è consentito ripubblicare lo script in una libreria di script appartenente o sotto il controllo di un altro fornitore di software.
  • Esclusione di garanzia: Lo script viene fornito “così com’è” e “come disponibile”, senza garanzie di alcun tipo. NinjaOne non promette né garantisce che lo script sia privo di difetti o che soddisfi le tue esigenze o aspettative specifiche.
  • Assunzione del rischio: L’uso che farai dello script è da intendersi a tuo rischio. Riconosci che l’utilizzo dello script comporta alcuni rischi intrinseci, che comprendi e sei pronto ad assumerti.
  • Rinuncia e liberatoria: Non riterrai NinjaOne responsabile di eventuali conseguenze negative o indesiderate derivanti dall’uso dello script e rinuncerai a qualsiasi diritto legale o di equità e a qualsiasi rivalsa nei confronti di NinjaOne in relazione all’uso dello script.
  • EULA: Se sei un cliente NinjaOne, l’uso dello script è soggetto al Contratto di licenza con l’utente finale (EULA) applicabile.