Lo stesso incidente non dovrebbe essere risolto da zero due volte. Con Trupeer, puoi risparmiare ore sulla documentazione di supporto iniziando con un modello di database degli errori noti (KEDB) gratuito, personalizzandolo con le tue linee guida del brand e registrando ogni soluzione alternativa come un breve video che il tuo team di supporto può seguire.

Cos'è un modello di database degli errori noti (KEDB)?

Un modello di database degli errori noti (KEDB) è una struttura già pronta per registrare gli errori noti: problemi la cui causa radice o soluzione alternativa è stata identificata ma non ancora risolta in modo permanente. Ogni voce indica al service desk come riconoscere l'errore, come aggirarlo e cosa si sta facendo per risolverlo definitivamente. Viene anche chiamato registro degli errori noti, registro degli errori noti o database dei problemi noti.

Il KEDB è al centro della gestione dei problemi nei framework di gestione dei servizi IT come ITIL. Quando si verifica un nuovo incidente, il personale di supporto cerca prima nel KEDB. Se l'errore è già noto, applicano la soluzione alternativa documentata e risolvono l'incidente in pochi minuti invece di indagare nuovamente.

Cos'è un errore noto?

Tre termini vengono spesso confusi, quindi è utile separarli:

• Incidente: un'interruzione imprevista o un degrado di un servizio, ad esempio "gli utenti non possono inviare fatture".

• Problema: la causa alla base di uno o più incidenti, che potrebbe non essere ancora nota.

• Errore noto: un problema la cui causa radice, soluzione alternativa, o entrambe, sono state identificate e documentate.

Un errore noto rimane nel KEDB finché non viene implementata una correzione permanente, di solito tramite una modifica. Successivamente viene contrassegnato come risolto e archiviato.

Quando serve un KEDB?

Un KEDB ripaga ovunque si ripresentino gli stessi problemi e più di una persona se ne occupi:

• Service desk IT, dove il personale di prima linea ha bisogno di risposte rapide agli incidenti ricorrenti.

• Servizi di gestione delle applicazioni (AMS), in cui un provider supporta ERP, CRM o applicazioni personalizzate per un cliente.

• Transizioni AMS, in cui il supporto per un'applicazione si sposta da un fornitore o team interno a un altro.

• Team di supporto prodotto, dove i bug noti richiedono una soluzione alternativa coerente finché una versione non li risolve.

• Ambienti regolamentati, in cui i revisori si aspettano prove di come vengono gestiti i problemi ricorrenti.

Anteprima del modello KEDB

Il modello si apre con una breve sezione sulla governance: chi possiede il KEDB, come vengono approvate le voci e con quale frequenza vengono riviste. La parte principale è il record dell'errore noto, con campi per ID, titolo, sintomi, servizio interessato, causa radice, soluzione alternativa, correzione permanente e stato, oltre ai collegamenti al problema correlato, agli incidenti e alla modifica. Un elenco degli stati e un registro delle revisioni chiudono il modello. Ogni campo è modificabile, in modo da poterlo adattare al proprio strumento ITSM.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la vista del modello

Se necessario, espandi la vista del modello per vedere chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le impostazioni correlate

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente, se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello KEDB puoi:

• Risolvere gli incidenti ricorrenti più rapidamente: il personale di supporto applica una soluzione alternativa documentata invece di indagare di nuovo.

• Aumentare le percentuali di risoluzione al primo tentativo: gli agenti di prima linea possono gestire errori che prima venivano inoltrati ai livelli superiori.

• Proteggere la conoscenza nelle transizioni: le soluzioni alternative in possesso di pochi esperti diventano una risorsa condivisa.

• Rimanere in linea con il brand: applica il tuo logo, i tuoi font e i tuoi colori con il kit del brand di Trupeer.

• Mostrare le soluzioni alternative, non solo descriverle: trasforma ogni soluzione alternativa in una breve videoguida.

• Supportare gli audit: mostra come vengono identificati, tracciati e risolti i problemi ricorrenti.

Cosa deve contenere un modello KEDB

Ogni record di errore noto dovrebbe includere questi campi. Il modello seguente segue lo stesso ordine.

1. ID errore noto: un riferimento univoco, come KE-0142.

2. Titolo: una descrizione breve e ricercabile dell'errore.

3. Sintomi: ciò che vedono gli utenti e gli agenti, inclusi i messaggi di errore esatti.

4. Servizio o applicazione interessata: il sistema, il modulo e l'ambiente.

5. Causa radice: cosa causa l'errore, se noto.

6. Soluzione alternativa: istruzioni dettagliate per ripristinare il servizio, con screenshot o un video.

7. Correzione permanente: la risoluzione pianificata, il riferimento alla modifica e la data obiettivo.

8. Stato: ad esempio, aperto, soluzione alternativa disponibile, correzione pianificata, risolto, archiviato.

9. Record correlati: ID del problema, ID degli incidenti e ID della modifica.

10. Proprietario: la persona o il team responsabile della voce.

11. Date: creazione, ultima revisione e risoluzione.

12. Parole chiave di ricerca: termini che gli agenti probabilmente digiteranno, inclusi i codici di errore.

Modello KEDB gratuito: la struttura da copiare

Copia la struttura seguente nel tuo documento o strumento ITSM, oppure aprila in Trupeer e personalizzala.

1. Governance. Proprietario KEDB: [problem manager]. Approvazione: le nuove voci vengono riviste da [team] prima della pubblicazione. Cadenza di revisione: ogni voce viene rivista ogni [X] settimane. Archiviazione: le voci vengono archiviate quando la correzione permanente viene implementata e verificata.

2. Record dell'errore noto.

3. Definizioni degli stati.

4. Registro delle revisioni. Data, revisore, voci riviste, voci aggiornate, voci archiviate.

Esempio di KEDB: supporto per l'applicazione SAP order-to-cash

Ecco il modello compilato per un esempio illustrativo. Un team AMS supporta il processo SAP order-to-cash per un'azienda manifatturiera, Corvane Industrial, e tiene un KEDB per i problemi ricorrenti.

KE-0142 in dettaglio.

• Sintomi: gli ordini cliente per un cliente rimangono bloccati con un messaggio di stato del credito, anche dopo che l'amministrazione finanziaria ha aumentato il limite di credito del cliente.

• Servizio interessato: gestione del credito SAP SD e FI, produzione.

• Causa radice: l'esposizione creditizia non viene ricalcolata automaticamente dopo una modifica del limite per i clienti in uno specifico segmento di credito.

• Soluzione alternativa: confermare il nuovo limite con l'amministrazione finanziaria, aprire l'ordine bloccato nella schermata di gestione del credito, eseguire nuovamente il controllo del credito e sbloccare l'ordine. Link al video passo-passo.

• Correzione permanente: modifica della configurazione per attivare il ricalcolo sugli aggiornamenti dei limiti, pianificata per la prossima versione.

• Record correlati: problema PRB-0388, otto incidenti nell'ultimo mese, modifica CHG-1021.

• Proprietario: responsabile AMS order-to-cash.

I dettagli in questo esempio sono illustrativi; sostituiscili con le tue applicazioni e i tuoi record.

Come scrivere una soluzione alternativa che gli agenti possano effettivamente seguire

La soluzione alternativa è il campo che decide se un KEDB viene utilizzato o meno. Una buona soluzione consente a un agente di prima linea di ripristinare il servizio senza escalation:

• Inizia con come confermare che si tratta di questo errore. Elenca i sintomi esatti e i codici di errore, in modo che gli agenti non applichino la soluzione alternativa errata.

• Scrivi passaggi, non riassunti. Un'azione per passaggio, in ordine, indicando la schermata, il campo o il comando esatto.

• Specifica chi può farlo. Nota qualsiasi livello di accesso, approvazione o firma aziendale necessaria prima di applicare la soluzione alternativa.

• Indica il risultato atteso. Di' all'agente cosa dovrebbe vedere quando la soluzione alternativa ha funzionato.

• Includi il ripristino. Se la soluzione alternativa potrebbe peggiorare le cose, spiega come annullarla.

• Aggiungi un video. Una breve registrazione dell'applicazione della soluzione alternativa elimina la maggior parte delle ambiguità nei passaggi scritti.

• Indica quando passare al livello superiore. Se la soluzione alternativa non funziona, indica all'agente a chi passarla e cosa includere.

Come si colloca il KEDB nella gestione dei problemi

Nella gestione dei problemi in stile ITIL, il KEDB collega tre attività. L'identificazione dei problemi individua gli incidenti ricorrenti e apre un record del problema. Il controllo del problema ne analizza la causa e ne documenta una soluzione alternativa, a quel punto il problema diventa un errore noto ed entra nel KEDB. Il controllo degli errori gestisce quindi l'errore noto fino a quando non viene implementata una correzione permanente tramite la gestione delle modifiche, dopodiché la voce viene risolta e archiviata.

Ciò significa che il KEDB non è una libreria separata. È l'output visibile della gestione dei problemi, e la parte di essa che il service desk utilizza ogni giorno.

KEDB per le transizioni AMS

Quando i servizi di gestione delle applicazioni si spostano da un fornitore a un altro, o da un team interno a un fornitore, il KEDB è uno degli elementi di trasferimento della conoscenza più preziosi. Gran parte di ciò che rende efficace un team AMS esperto è sapere quali errori si ripetono, cosa li causa e quale soluzione alternativa funziona. Se questa conoscenza non viene acquisita, il team in arrivo la riscopre ticket dopo ticket, e i livelli di servizio calano durante il periodo di ipercura (hypercare).

Un KEDB pronto per la transizione si costruisce in quattro passaggi:

1. Raccogli dalla cronologia dei ticket. Esamina gli incidenti e i problemi degli ultimi 6-12 mesi nello strumento ITSM per trovare i problemi ricorrenti.

2. Registra le soluzioni alternative. Chiedi agli ingegneri di supporto del fornitore uscente di registrare sullo schermo ogni soluzione alternativa mentre la spiegano, in modo che nulla dipenda dalla loro memoria.

3. Valida durante l'affiancamento (shadowing). Quando si verifica un errore noto durante l'esecuzione in parallelo, il team in arrivo applica la soluzione alternativa documentata mentre il fornitore uscente osserva, e la voce viene corretta se necessario.

4. Rendilo un criterio di accettazione. Concorda che il trasferimento di conoscenza per ciascuna applicazione non sia completo finché il relativo KEDB non è stato esaminato e accettato dal team in arrivo e dal cliente.

In una transizione AMS da fornitore a fornitore, il cliente dovrebbe essere il proprietario del KEDB, in modo che sopravviva al successivo cambio di fornitore. Per il metodo di transizione più ampio, consulta il nostro modello di SOP di transizione e le guide sul trasferimento di conoscenza nella transizione da fornitore a fornitore e sul periodo di hypercare della transizione.

Come creare un KEDB a partire dalle registrazioni

Scrivere le soluzioni alternative a mano è lento, e il risultato è spesso costituito da poche righe di testo che un agente non riesce a seguire sotto pressione. Un approccio basato prima sulla registrazione è più rapido e chiaro.

1. Registra la soluzione alternativa mentre viene eseguita. L'ingegnere che conosce la correzione registra il proprio schermo con il registratore dello schermo AI di Trupeer mentre la applica, spiegando ogni passaggio.

2. Genera i passaggi automaticamente. Carica la registrazione e Trupeer la trasformerà in un documento passo-passo con screenshot, oltre a un video narrato, utilizzando il creatore di SOP.

3. Aggiungilo al record dell'errore noto. Incolla i passaggi nel campo della soluzione alternativa e collega il video.

4. Pubblicalo dove guardano gli agenti. Memorizza le voci KEDB e i video in una base di conoscenza ricercabile, o collegali dal tuo strumento ITSM.

5. Traduci per il supporto globale. Utilizza la traduzione per creare soluzioni alternative nella lingua di ciascun team di supporto.

6. Aggiorna quando la correzione cambia. Registra di nuovo solo il passaggio che è cambiato.

Lo stesso approccio basato prima sulla registrazione funziona su larga scala. Genpact ha registrato le sessioni dei processi MS Teams esistenti e le guide degli esperti (SME), le ha caricate su Trupeer e ha ottenuto SOP e video dimostrativi in cinque lingue: oltre 500 materiali formativi per 140.000 dipendenti in 40 paesi, consegnati in 3 mesi invece di 12. Leggi la storia del cliente Genpact.

Varianti di KEDB per team

La struttura del record rimane la stessa, ma cambia il focus:

KEDB per service desk IT

Focalizzati su problemi degli utenti finali ad alto volume: accessi, dispositivi, e-mail, VPN e applicazioni comuni. Mantieni le soluzioni alternative abbastanza brevi per gli agenti di prima linea e usa parole chiave di ricerca che corrispondano al modo in care gli utenti descrivono il problema.

KEDB per AMS SAP ed ERP

Organizza le voci per modulo o processo aziendale, come order-to-cash o procure-to-pay. Includi codici di transazione, riferimenti di configurazione e l'impatto aziendale, poiché le soluzioni alternative ERP spesso necessitano dell'approvazione aziendale prima di essere applicate.

Database dei problemi noti per il supporto prodotto

Collega ogni problema noto a una versione del prodotto e a un ID bug. Includi una dicitura rivolta al cliente per la soluzione alternativa e archivia le voci quando viene rilasciata la versione correttiva.

KEDB per l'IT del settore pubblico e governativo

I team IT del settore pubblico spesso supportano sistemi legacy con lunghi cicli di correzione e un rigido controllo delle modifiche. Registra le approvazioni necessarie per una soluzione alternativa, eventuali implicazioni sui record o sulla protezione dei dati e le date di correzione previste legate alle finestre di rilascio o ai cicli di budget.

KEDB vs base di conoscenza vs runbook vs record di problema

Il KEDB è spesso una sezione della base di conoscenza più ampia, collegata ai record dei problemi. Vedi il modello di base di conoscenza, il modello di runbook e il modello di guida alla risoluzione dei problemi.

Metriche KEDB da tracciare

Come configurare un KEDB in sei passaggi

1. Scegli un proprietario, di solito il problem manager o il responsabile del supporto.

2. Concorda i campi e gli stati del record, utilizzando il modello precedente.

3. Alimentalo a partire dalla cronologia, iniziando dagli incidenti ricorrenti più frequenti.

4. Registra ogni soluzione alternativa sullo schermo e genera i passaggi.

5. Rendi la ricerca nel KEDB parte della gestione degli incidenti, in modo che gli agenti lo controllino prima di inoltrare il problema.

6. Rivedi e archivia le voci con una cadenza fissa e quando vengono implementate le correzioni.

Lista di controllo KEDB

• Ogni incidente ricorrente ha un record di errore noto.

• Ogni record ha sintomi chiari e parole chiave ricercabili.

• Ogni soluzione alternativa contiene istruzioni dettagliate, con screenshot o video.

• La causa radice e lo stato della correzione permanente sono registrati.

• I record si collegano al problema, agli incidenti e alla modifica correlati.

• Ogni voce ha un proprietario e una data di revisione.

• Gli errori risolti vengono archiviati in modo che gli agenti non applichino vecchie soluzioni alternative.

• In una transizione, il team in arrivo ha esaminato e accettato il KEDB.

Errori comuni da evitare

• Soluzioni alternative vaghe. "Riavviare il servizio" non è sufficiente; gli agenti hanno bisogno dei passaggi esatti.

• Nessuna parola chiave di ricerca. Se gli agenti non riescono a trovare una voce, per loro non esiste.

• Non archiviare mai le voci. Le vecchie soluzioni alternative applicate dopo una correzione possono causare nuovi problemi.

• Tenere il KEDB separato dalla gestione degli incidenti. Funziona solo se il controllo fa parte del processo.

• Lasciarlo fuori dalle transizioni. Il KEDB è la conoscenza di cui un team di supporto in arrivo ha più bisogno.

Scarica il modello KEDB gratuito

Apri il modello in Trupeer, applica il kit del tuo brand, registra le tue soluzioni alternative e condividi il KEDB con ogni team di supporto. Ottieni il modello KEDB gratuito.

Domande frequenti

Cos'è un database degli errori noti (KEDB)?

Un KEDB è un archivio di errori noti: problemi la cui causa radice o soluzione alternativa è stata identificata ma non ancora risolta in modo permanente. Aiuta i team di supporto a risolvere rapidamente gli incidenti ricorrenti applicando soluzioni alternative documentate.

Cos'è un errore noto in ITIL?

In ITIL, un errore noto è un problema che è stato analizzato e ha una causa radice documentata, una soluzione alternativa o entrambe, ma non è stato ancora risolto in modo permanente.

Quali campi dovrebbe includere un record KEDB?

ID errore noto, titolo, sintomi, servizio interessato, causa radice, soluzione alternativa, correzione permanente, stato, record di problema, incidente e modifica correlati, proprietario, date e parole chiave di ricerca.

Qual è la differenza tra un KEDB e una base di conoscenza?

Una base di conoscenza contiene tutti gli articoli di supporto e le guide pratiche. Un KEDB contiene solo gli errori noti, con le relative soluzioni alternative e lo stato della correzione, ed è spesso una sezione della base di conoscenza più ampia.

Chi è il proprietario del database degli errori noti?

Di solito il problem manager o il responsabile del supporto. Gli ingegneri di supporto creano e aggiornano le voci, e il proprietario le approva ed esegue revisioni regolari.

Cos'è un registro degli errori noti?

Un registro degli errori noti (known error log) è un altro nome per un database degli errori noti. Alcuni team lo utilizzano per un elenco o un foglio di calcolo più semplice di errori noti e soluzioni alternative.

Perché un KEDB è importante in una transizione AMS?

Acquisisce i problemi ricorrenti e le soluzioni alternative noti a un team di supporto esperto. Senza di esso, il team AMS in arrivo riscopre ognuno di essi ticket per ticket, e i livelli di servizio calano durante l'hypercare.

Qual è un esempio di KEDB?

Un esempio di KEDB è il modello compilato con voci reali o illustrative. L'esempio SAP order-to-cash in questa pagina mostra tre record e una voce completa, inclusi sintomi, causa radice, soluzione alternativa e stato della correzione.

Esiste un modello KEDB in Excel?

Excel funziona bene per un semplice registro degli errori noti, con una riga per errore e colonne per ogni campo. Per soluzioni alternative con molti passaggi, collega ogni riga a un documento o a un video.

Esiste un modello KEDB in Word?

Word è adatto per record dettagliati di errori noti e per la sezione di governance. Apri questo modello in Trupeer ed esportalo, oppure copia la struttura sopra in Word.

Esiste un modello KEDB in PDF?

Il formato PDF è adatto per un'istantanea revisionata del KEDB da condividere con un cliente, un revisore o un fornitore in arrivo. Mantieni modificabile il KEDB di lavoro in modo che gli agenti vedano sempre l'ultima versione.

Esiste un modello KEDB in Google Documenti?

Sì. Copia la struttura precedente in Google Documenti o Fogli, oppure apri il modello in Trupeer ed esportalo. Google Fogli funziona bene quando diversi team di supporto aggiornano lo stesso registro.