Non è un segreto che a partire da un certo livello di maturità nelle aziende IT iniziano a registrare le richieste in appositi sistemi, tracker. Ciò ti consente di capire chi sta facendo cosa, analizzare la situazione attuale e il lavoro già svolto e molte cose utili: con il modo giusto di avviare l'attività, i vantaggi superano notevolmente la burocrazia. L'ordine di esecuzione delle richieste è disciplinato da priorità.
Per molti, molti anni di lavoro nel supporto di vari sistemi IT, mi è piaciuto molto il sistema delle quattro priorità, che verrà discusso di seguito. Questo sistema si è dimostrato così efficace nella pratica in un'ampia varietà di progetti che sono sinceramente sorpreso quando mi imbatto in altri approcci alle priorità. Quindi sono disposto a fare un certo sforzo per divulgare queste priorità. In modo che siano più usati da tutti e più spesso trovati nella vita.
Se non hai ragioni particolari (che sei pronto a formulare chiaramente per iscritto), usa le seguenti priorità nel supportare i sistemi IT:
| # | Priorità | Definizione | Definizione informale |
| 1 | Critico | Il problema comporta l'arresto o la perdita completa del sistema prestazione. Le funzioni principali del Sistema diventano non disponibili e la situazione è critica | Tutto è rotto. Le parti interessate rinunciano a tutte le altre cose e iniziano a risolvere questo problema, di solito il lavoro viene svolto in modalità di emergenza (cioè 24 ore su 24). |
| 2< /b> | Alto | Il problema comporta una perdita significativa delle prestazioni del sistema. Le funzioni critiche del sistema diventano non disponibili e non esiste una soluzione alternativa applicabile, tuttavia, il sistema rimane operativo in misura limitata e il lavoro sulla soluzione verrà svolto durante l'orario lavorativo. | Il problema è davvero critico, ma non tutto è così male da entrare in modalità di emergenza. |
| 3 | Moderato | < td>Il problema comporta una perdita insignificante delle prestazioni del sistema, che si traduce in disagi sul lavoro o nella necessità di utilizzare soluzioni alternative o alternativeIl problema è critico, ma consente soluzioni manuali o di altro tipo | |
| 4 | Basso | Questo problema non comporta una perdita delle prestazioni del sistema. Questo è un errore minore o un inconveniente, un errore nella documentazione, ecc., che non interferisce con lo svolgimento delle operazioni nel Sistema. | Il problema dovrebbe essere risolto, ma non è critico. Stranamente, la maggior parte delle richieste va qui. |
Queste priorità devono essere comprese e utilizzate correttamente da tutti i dipendenti IT coinvolti nel processo di manutenzione.
Agli utenti aziendali dei sistemi IT dovrebbe essere assegnata automaticamente la priorità in base alle proprietà di query specificate, in base a proprietà pertinenti ma oggettive. Ad esempio, su criticità e grado di influenza:
| Priorità | Totale | Per reparto | Per utente |
| Alto | 1 | 2 | 3 |
| Medio | 2 | 3 | 4 |
| Basso | 3 | 4 | 4 |
Inoltre, per impianti specifici, la criticità può essere indicata proprio lì . Ad esempio, per un sistema ERP, questi possono essere intervalli di perdite attese: oltre 100 milioni, da 1 a 100 milioni, fino a 1 milione. Potrebbe essere opportuno utilizzare modificatori come "persona VIP coinvolta" che aumentano o diminuiscono la priorità. La matrice di corrispondenza dovrebbe essere mantenuta semplice e trasparente, ma non dovrebbe consentire priorità elevate non necessarie.
Il motivo di questa apparente "discriminazione" è discusso di seguito.
Quando scriviamo i regolamenti noi stessi, stabiliamo noi stessi le "regole del gioco". E ha senso stabilire tali regole, non solo comunque, ma per renderlo il più conveniente ed efficiente possibile. Questa è una questione di esperienza, ma devi iniziare a ballare da qualcosa. Inoltre, è già a punto sul posto. Parliamo di come stabilire le priorità. Iniziamo come al solito con la cosa principale - con la risposta alla domanda "perché è necessario".
Abbiamo bisogno di priorità per distinguere dalla massa totale delle richieste quelle per le quali vogliamo un'azione più attiva. Pertanto, possiamo:
Semplificare il lavoro dell'esecutore: i compiti con una priorità più alta dovrebbero essere risolti prima. Introdurre diverse metriche di destinazione nello SLA, a seconda della priorità, che, da un lato, mostrerà che le attività con una priorità più elevata vengono risolte con maggiore urgenza e, dall'altro, consentirà di valutare quanto bene queste regole sono in corso di attuazione.
È conveniente avere 3-5 priorità. Di solito questo è sufficiente per tutte le occasioni, un numero diverso di priorità è piuttosto esotico. Affinché le priorità funzionino correttamente, dovrebbero esserci 5-10 volte meno richieste con una priorità più alta rispetto alla precedente. Si scopre una specie di scala caratteristica (vedi fig.). E quindi la richiesta con una priorità più alta, a causa del suo esotismo, attirerà l'attenzione naturale su se stessa e non si perderà nella massa generale di richieste di un particolare artista. Si presume che, in condizioni di carico normale, ogni artista abbia una media di 5-15 richieste aperte e la metà di esse richieda l'intervento di qualcun altro. Quindi, con priorità elevate, ogni esecutore avrà in media non più di 1-2 richieste, ed è completamente chiaro da quale fine devi metterti al lavoro.
Vorrei anche che queste priorità fossero logiche e ben comprese da tutti i partecipanti al processo. Perché cambiare troppo la priorità può cambiare le metriche delle prestazioni target e se una delle parti non è d'accordo, allora ci sarà un conflitto che vorremmo evitare. I cambiamenti nelle priorità dovrebbero verificarsi quando cambia la portata del problema da risolvere o quando appaiono nuove informazioni che modificano significativamente l'impostazione iniziale del problema.
Secondo la mia pluriennale esperienza, un sistema di quattro priorità è molto conveniente. Li ho già indicati nell'articolo "Come scrivere un buon SLA". Bene, all'inizio di questo articolo. Si tratta di tre priorità principali (Basso, Medio, Alto) e una straordinaria (Massimo) proprio per quei casi in cui tutti mollano tutto e iniziano ad affrontare solo questo problema ad oltranza.
Questo sistema di priorità è piuttosto intuitivo. Meno di tre priorità regolari da utilizzare non vanno bene, si ridimensionano male. Più di tre non sono più realmente necessarie, e Ockam non l'ha ordinato.
Resta da giustificare la definizione delle priorità. Questo può essere fatto in diversi modi. Puoi semplicemente definire senza alcuna giustificazione. Puoi anche giustificarti. Senza pretendere di essere universale, darò uno degli approcci. È interessante solo perché può essere ripetuto per altre condizioni specifiche. L'approccio sarà il seguente. Troveremo un criterio che ci permetterà di individuare quelle che richiedono più attenzione dalla massa totale delle richieste. Quindi, tra questi selezionati, scegli quelli che richiedono un'attenzione ancora maggiore. Il filo del pensiero, spero, è chiaro. E poi faremo la definizione delle priorità da questi criteri. Per rendere chiare le definizioni, cercheremo ogni volta di scegliere tale criterio in modo che sia il più semplice e comprensibile possibile.
Noto subito che, per impostazione predefinita, le richieste dovrebbero essere sempre aperte con la priorità più bassa, e le priorità più alte dovrebbero essere giustificate nella richiesta. In caso contrario, la scala desiderata non funzionerà. Richiedere una giustificazione scritta per la priorità più alta è importante perché costringe il richiedente a chiedersi se il problema è davvero critico. Provalo tu stesso e vedrai che questo è un ottimo filtro.
Torniamo alla prioritizzazione. Prima di tutto, dividiamo tutte le richieste in importanti e non importanti. Tutti quelli senza importanza vengono chiusi senza pietà.
Non ci sono richieste non importanti. Se il problema non è importante per nessuno, non perdere tempo. È una questione di efficienza. Il modo più efficace per risolvere problemi non importanti è ammettere che il problema è inutile e chiudere la richiesta. Non lasciare mai i problemi aperti per dopo. Quando sarai pronto per affrontarli, inizierai. E se improvvisamente non ricordi, significa che non era necessario. Chiudere. Altrimenti, nessuno SLA aiuterà. Il mondo è imperfetto, non c'è niente per cercare di eliminare tutte le ingiustizie in esso (vedi fig.). Anche se è difficile essere d'accordo con questo. Anche il mio perfezionista interiore ha obiettato, ma esattamente fino a quando non l'ho confrontato con il fatto che avremmo fatto un lavoro non necessario nel nostro tempo libero dal lavoro principale. Se la tua coscienza è così tormentosa, contrassegna tali richieste chiuse in modo da poterle tornare in seguito. Quando, ad esempio, hanno improvvisamente eliminato un mucchio di tutti i problemi attuali e non c'era nient'altro da fare. Ma questo non dovrebbe accadere, se non c'è niente da fare su base regolare, allora questo significa che alcune risorse devono essere liberate per qualcos'altro, più utile.
Ora che abbiamo tutte le richieste importanti, individuiamo quelle urgenti e quelle critiche. Perché non tutte le questioni importanti devono essere urgenti o critiche. Al contrario, i problemi critici o urgenti non si presentano molto spesso. Se per qualche motivo ti sembra che tutti i problemi siano urgenti e critici, allora prova a formulare per iscritto qual è l'importanza e la criticità di ciascuno. Questi sono quelli per i quali non devi lottare per trovare una ragione per l'importanza o prenderla impudentemente (tu stesso non capisci, questo è molto critico!), Quelli saranno critici.
Ora, tra quelli urgenti e quelli critici, sceglieremo quelli che non hanno soluzioni alternative per risolvere il problema. Sì, non è così raro che una situazione particolare possa essere affrontata senza risolvere il problema originario. Contare con le mani su un pezzo di carta, raccogliere un report in Excel, eseguire un'operazione manuale anziché una normale, ecc. Sono tutte soluzioni alternative. Nessuno sostiene che sia scomodo farlo e che sia necessario risolvere il problema, perché perché abbiamo bisogno di un sistema informatico se non funziona. Ma se c'è una soluzione alternativa, puoi dedicare più tempo alla soluzione. Pertanto, se esiste una soluzione alternativa, dovrebbe essere utilizzata immediatamente. Mentre l'esecutore sta cercando di risolvere il problema in generale, l'iniziatore immediatamente, senza perdere tempo, inizia a utilizzare una soluzione alternativa. E se l'iniziatore può permettersi di aspettare la soluzione del problema, allora molto probabilmente il problema non è così importante o urgente, per il quale ha cercato di farlo passare, puoi abbassare la priorità.
Questo principio di parità è generalmente molto importante nel processo di manutenzione di qualsiasi sistema IT. Nessuna delle due parti del processo dovrebbe aver bisogno di più dell'altra. Ci deve essere parità. Se una parte dice "bene, allora tu stesso e io vado a casa, al mattino in modo che tutto sia fatto", allora la priorità deve essere abbassata immediatamente e anche andare a casa. Qual è il punto di lavorare sodo, trovare una soluzione a tarda notte, in modo che rimanga non reclamata fino al giorno lavorativo successivo? O lavoriamo tutti o non siamo d'accordo. Questa regola funziona particolarmente bene in modalità di emergenza. Avral e hai bisogno di andare a lavorare tutto il giorno? Ok, il dipartimento IT è pronto, se necessario, a lavorare in questa modalità, per questo è stato creato. L'impresa è pronta? .. Non considero nemmeno la situazione opposta (quando l'azienda ne ha bisogno, ma l'IT non è pronto). Tale IT deve essere immediatamente disperso in piena forza, poiché il dipartimento IT, che non capisce chi sta lavorando per chi, è incompetente.
Torniamo alle priorità. Hai bisogno di dare la priorità a qualcosa di ancora più importante? Sì, sembra non essere più necessario. Poi solo un lavoro urgente.
Così, siamo riusciti a dividere tutte le richieste in classi, e ogni classe successiva di richieste è più rara e richiede maggiore attenzione e risposta più rapida, che è quello che volevamo:
E ovviamente la super priorità:
lasciamo perdere tutto e affrontiamo solo questo problema senza dormire e riposare.
Quest'ultima priorità viene solitamente assegnata dalla riga generale per il motivo che ci lavorano 24 ore su 24, a differenza di tutte le precedenti, per le quali il lavoro viene svolto durante l'orario di lavoro. Fermo restando il principio della parità di necessità, questa priorità non ha nemmeno bisogno di essere determinata in modo particolare. Nessuno nel suo buon senso avvierà una modalità 24 ore su 24, se davvero non la disattiverà.
In totale, abbiamo quattro chiare priorità. La formulazione delle definizioni sull'ufficio (in modo che tu possa prenderla nel tuo regolamento e correggerla sul posto), vedi la piastra sopra.
Puoi prendere i nomi suggeriti da me, oppure puoi prendere quelli numerici neutri - il primo (il più alto), il secondo, il terzo e il quarto. E capita che la mano di qualcuno non si alzi per aprire le richieste con una priorità chiamata "Bassa". Ad esempio, sono abituato a usare entrambi.
Tutto quanto sopra sulle priorità si applica a quelle persone che forniscono supporto tecnico in servizio. Il personale di supporto dovrebbe avere familiarità con il panorama IT generale ed essere in grado di stabilire le priorità in modo obiettivo e coerente in conformità con le normative interne. È meglio per gli utenti aziendali dei sistemi IT non dare l'opportunità di scegliere una priorità, ma di impostarla automaticamente. Una buona approssimazione è l'impatto diagonale e la matrice di criticità dalla classica definizione di priorità ITIL. Un esempio è già stato fatto sopra.
Perché? Non si tratta di sfiducia negli utenti, dicono, sono vecchi e poveri. È solo che per l'utente del sistema IT, qualsiasi problema che interferisca con lui personalmente sarà sempre della massima priorità. Perché gli impedisce di fare il proprio lavoro, e in questo momento sta interferendo. E dopotutto, come sempre, si è rotta nel momento sbagliato, proprio quando ce n'era bisogno. In caso contrario, l'utente non sarebbe entrato nel sistema e, inoltre, non avrebbe contattato il servizio di assistenza. Ha già qualcosa da fare dai suoi doveri ufficiali diretti. Se avesse avuto molte richieste, allora avrebbe potuto dare loro la priorità. Ma nella maggior parte dei casi, l'utente ha solo una richiesta di supporto. E il quadro generale dell'IT gli è sconosciuto e non è interessato, a differenza del personale di supporto.
E un utente normale non contatta spesso il servizio di supporto e, anche cercando di essere obiettivo, può semplicemente compilare la richiesta in modo errato, indicando la priorità sbagliata, o addirittura non specificandola affatto, o indicando un priorità più alta per ogni evenienza (è meglio sbagliarsi nella propria direzione). E così via.
Pertanto, gli utenti metteranno qualsiasi priorità, ma non quella che dovrebbe essere, e non c'è una forza ragionevole che li obbligherebbe a impostare le priorità corrette. Quindi è meglio non dare loro l'opportunità di commettere errori. È meglio inserire un paio di attributi obbligatori nella richiesta e l'output sarà qualcosa di abbastanza buono che sembra una priorità.
< !-- wp:heading --> La tabella seguente è una vista parziale della matrice di priorità che è possibile creare nell'applicazione Matrice di priorità. Se il gruppo di servizi è stato installato con estensioni di contenuto, è disponibile una matrice di priorità predefinita con valori simili a quelli riportati nella tabella. Nota che le variabili nella matrice di priorità hanno sia valori numerici che descrittivi.
Puoi creare una matrice di priorità in l'applicazione Matrice di priorità. La matrice di priorità predetermina le priorità interne per i passaporti del gruppo di servizi, che definiscono le combinazioni date di impatto e urgenza. Dopo che l'agente del gruppo di servizi ha compilato i campi Impatto e Urgenza nel record del passaporto, il campo Priorità interna viene compilato automaticamente in base ai valori "" nella matrice di priorità. I valori di priorità interna "per i record del passaporto aiutano a determinare l'ordine in cui verranno elaborati i passaporti.
La matrice di priorità è "basata sul concetto ITIL (Information Technology Infrastructure Library) che dà la priorità all'impatto e all'urgenza nel determinare la priorità relativa con cui devono essere elaborati gli elementi di una sequenza, come i passaporti del gruppo di servizi.< /p>
L'impatto è il potenziale impatto che un problema irrisolto ha sulla capacità di un'impresa di continuare a svolgere efficacemente le proprie operazioni o fornire servizi. Ad esempio, un guasto del server che supporta un numero elevato di clienti può essere considerato un impatto critico per l'azienda.
Urgenza è definita come la velocità ritenuta sufficiente per risolvere un problema dovuto ad un determinato impatto. Ad esempio, un problema irrisolto con un alto potenziale di interruzione delle operazioni aziendali (alto impatto) può avere una bassa urgenza se è disponibile una soluzione temporanea o una soluzione alternativa.
La priorità del passaporto interno è la priorità assegnata dal servizio agente di gruppo in base all'impatto e all'urgenza. Oltre alla priorità interna, le voci del passaporto includono anche la priorità segnalata e la priorità specificata. La priorità segnalata è la priorità segnalata dal dipendente che ha segnalato il problema al team di assistenza. La priorità indicata è la priorità assunta del passaporto, che viene inserita automaticamente in base alla classificazione assegnata. I valori "" di questi tipi di priorità aggiuntivi forniscono una guida all'agente del gruppo di servizi nel determinare quali valori di impatto e urgenza "" assegnare a un particolare passaporto.
