Scenario di esempio: Gestione delle modifiche e delle attività

Data di pubblicazione: luglio 2016

Si applica a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Questo scenario di esempio per System Center 2012 - Service Manager aiuta a raggiungere l'obiettivo della gestione di modifiche e attività attraverso diversi scenari end-to-end. È possibile considerare questo scenario di esempio come un case study che aiuta a collocare nel contesto i singoli scenari e procedure.

Nello scenario che comprende l'inizializzazione e la classificazione di una richiesta di modifica, Julia, l'analista di supporto per la messaggistica, desidera proporre una modifica e tenerne traccia. A tale scopo crea una richiesta di modifica per catturare le informazioni che lei ed altri potranno utilizzare per esaminare, pianificare, sviluppare, testare, distribuire e valutare le modifiche. Julia comincia con l'inizializzazione della richiesta di modifica e quindi ne identifica la priorità e la categoria.

Negli scenari di gestione eventi imprevisti Phil ha creato un evento in cui un utente presenta un problema di messaggistica che viene da lui sottoposto a una prima investigazione. In questo scenario Julia continua a investigare lo stesso evento imprevisto. Riscontra che la causa è un problema noto che è stato risolto in Microsoft Exchange Server 2010 SP1. Determina inoltre che il service pack va applicato a tutti i server di Exchange, non a un solo server. Quindi, Julia esamina la mappa del servizio per l'elemento di configurazione servizio Exchange che richiede il Service Pack e apre una richiesta di modifica nel modulo dell'elemento della configurazione del servizio. Infine Julia allega alla richiesta di modifica un'immagine dello schermo che potrebbe tornare utile in seguito, durante la revisione della richiesta di modifica.

Dopo la creazione della richiesta di modifica, i revisori della modifica presso Woodgrove Bank dovranno approvarla e coloro che la implementeranno dovranno completare le azioni richieste. Le fasi di revisione e implementazione sono definite nella richiesta di modifica come set di attività di revisione e di attività manuali.

Nello scenario che comprende l'approvazione di una richiesta di modifica, Garret desidera assicurare l'applicazione del processo aziendale di Woodgrove Bank, che prevede che ogni modifica dell'infrastruttura IT venga approvata prima della distribuzione. A tale scopo utilizzerà Service Manager per associare attività di revisione alla richiesta di modifica. Grazie alla richiesta di approvazione, la richiesta di modifica verrà implementata solo dopo che i responsabili di Woodgrove Bank ne avranno riconosciuto la necessità. Garret può impostare diversi metodi di revisione, quali il voto unanime, una percentuale di voti favorevoli o l'approvazione automatica.

Le procedure correlate a questo scenario descrivono la modifica all'infrastruttura IT di Woodgrove Bank approvata prima della distribuzione.

Durante la revisione di una richiesta di modifica, Garret può scegliere occasionalmente di sospenderla per poi riprenderla in seguito. Si immagini ad esempio che Julia abbia creato una richiesta di modifica. Tale richiesta di modifica dipende dal lavoro di un team esterno. Garret può decidere di sospendere la richiesta di modifica fino al completamento del lavoro del team esterno. La richiesta di modifica verrà ripristinata successivamente. Garret può inoltre voler occasionalmente sbloccare le richieste di modifica non riuscite.

Una volta testate e approvate le modifiche all'infrastruttura IT di Garret per la distribuzione, la fase finale consisterà nel completare le attività manuali restanti associate alla richiesta di modifica. Un'attività manuale deve essere designata come completata o non riuscita. Quando tutte le attività manuali sono state completate, la richiesta di modifica viene impostata automaticamente come completata e viene visualizzata nella vista Richieste di modifica: completate. Se un'attività manuale non riesce, la richiesta di modifica viene impostata automaticamente come non riuscita e visualizzata nella vista Richieste di modifica: non riuscite. Quando la richiesta di modifica verrà visualizzata in una delle due viste, Garret potrà chiuderla. Dopo la chiusura di una richiesta di modifica non sarà possibile riaprirla.

Nello scenario che comprende l'implementazione e la chiusura delle richieste di modifica, Aaron svolge un'attività manuale di revisione di garanzia. Quindi, Garret imposta le attività manuali rimanenti come Completate e chiude la richiesta di modifica. Garret apre una seconda richiesta di modifica esistente, imposta l'attività manuale di post-implementazione su Non riuscita e chiude la richiesta di modifica.

Gestione delle modifiche e delle attività in System Center 2012 - Service Manager