Realization and Roll-Out

Il processo di Realization and Roll-Out è il cuore del processo di Upgrade della Suite Remedy ITSM, basti pensare che su 190 giornate stimate da Gantt, 131 sono dedicate al tale processo. È il processo in cui sono state implementate tutte le attività operative, tutti i moduli e le configurazioni, senza dimenticare delle fasi di test incrociati con il cliente, le integrazioni e tutti i meeting di continuo allineamento e monitoraggio di processo.

Dato che il processo è alquanto complesso si cercherà di andare per ordine, con la premessa per cui molte delle attività, in particolare quelle di installazione, sono state replicate per ciascuno dei tre ambienti, dunque a meno che diversamente specificato ciascuna fase si intende ripetuta tre volte, quanti sono gli ambienti.

Il processo di Realization and Roll-Out ha avuto inizio intorno alla metà di luglio, quasi in parallelo con la finalizzazione del processo di validazione iniziale, descritto nel paragrafo precedente.

Come specificato nella sezione dedicata alla pianificazione di dettaglio, le attività di Realization and Roll-Out hanno subito delle modifiche in termini di pianificazione, fino a giungere alle due date obiettivo, ovvero il Technical Go-Live ed il Real Go-Live. La prima data di rilascio ha valenza tecnica, dunque rappresenta la scadenza in corrispondenza della quale l’intero sistema deve essere considerato pronto dal punto di vista tecnico e funzionale, con l’eccezione delle ultime attività di allineamento rispetto alla current situation realizzata con la fase di Delta Data Migration dalla Current Production alla New Production.

Come spiegato in precedenza, il processo di Upgrade è stato realizzato e portato avanti su macchine completamente nuove, permettendo dunque agli utenti dell’organizzazione con sede centrale in Belgio di non interrompere le normali attività. Di conseguenza a pochi giorni del Real Go-Live è stata implementata l’ultima di una serie di incrementali Delta Data Migration avvenuti al fine di migrare i dati dal vecchio al nuovo ambiente agendo sul Database di Produzione. Questo ha facilitato sicuramente il processo di accettazione della piattaforma normalmente utilizzata e di impattare il meno possibile sui processi interno.

87

Le attività che si sono state realizzate all’interno dei vari team di progetto sono descritte qui di seguito, seguendo il percorso promosso e collaudato dalla software House BMC.

Le prime attività sono state svolte sull’ambiente definito Clone secondo quanto stabilito nel processo di Solution Design, ovvero in sintesi è stato preparato un ambiente clone al vecchio ambiente di Development e la stessa cosa è stata fatta per il DB dela vecchia produzione. Sul clone è stato svolto l’upgrade ed in questo modo si è ottenuta una macchina vecchia, ma un DB nuovo aggiornato all’ultima versione 9.1.03.

A questo punto sono stati preparati i tre nuovi ambienti in cui iniziare il processo reale di Upgrade, operando in ambiente DEV, poi passando in QACC ed infine in PROD.

1.

Preparazione dell’ambiente

Il primo step necessario per iniziare un processo di upgrade eseguito su macchine fresh è la preparazione dell’ambiente, che rispetti fedelmente i requisiti definiti in fase di definizione dell’architettura. Per il progetto in questione gli ambienti sono stati predisposti dal gruppo del sistema che responsabile delle infrastrutture IT. Dal punto di vista progettuale è stato comunque necessario eseguire dei test su tali ambienti per accertarsi della rispondenza ai requisiti definiti nel documento Design Specification e a livello architetturale.

2. Installazioni

Una volta accertatisi della conformità ai requisiti del nuovo ambiente, sono state richieste le licenze necessarie da parte di BMC e quindi hanno avuto inizio le installazioni, che sono state suddivise in due macro fasi, ovvero installazione della Platform ed installazione delle Application, seguendo tale sequenza secondo quanto indicato da BMC.

In particolare, l’installazione della Platform implica l’installazione di

- AR System Server, ovvero il server implementato in back-end, il quale riceve i dati dai server lato cliente e li riversa a livello di Database.

88

- Atrium Core (CMDB), il quale si occupa principalmente di immagazzinare e gestire i Configuration Item (CI) singoli e le loro relazioni all’interno dell’ambiente. Contiene infatti tutte le informazioni sulle componenti che formano il sistema IT di un’organizzazione e le relazioni tra di loro. L’aggiornamento del CMDB garantisce un incremento della comprensione delle risorse IT presenti in azienda, delle loro relazioni e dell’impatto di un cambiamento dell’ambiente IT sulle attività di business.

- Server del Mid Tier

Questi rappresentano gli elementi essenziali di Remedy, il fulcro centrale. A conclusione di tale fase è best practice eseguire una snapshot delle macchine virtuali ed un backup del DB (nuovo) dell’ambiente.

Successivamente si passa all’installazione delle Application, secondo la seguente sequenza:

- IT Service Management (ITSM), che comprende a sua volta i moduli di: o BMC Incident Management

o BMC Problem Management o BMC Asset Management o BMC Change Management o BMC Knowledge Management - Service Request Management (SRM) - Service Level Management (SLM)

Come per le installazioni precedenti si esegue la snapshot delle macchine virtuali ed il backup del DB.

A questo punto, prima di procedere con le ultime installazioni è stata realizzata l’attività di restore del DB dell’ambiente a monte sul nuovo ambiente. Quindi, finite le installazioni suddette per l’ambiente di DEV, è stato realizzato il restore del DB del clone sul DB del DEV e così progressivamente per gli altri due ambienti in maniera iterativa.

Come ultime installazioni sono state svolte quelle delle due interfacce utente MyIT e SmartIT. A questo punto la Suite Remedy è pronta, ma vuota.

89

3. Configurazioni

Terminate le installazioni, l’ambiente è stato configurato, il che vuol dire che sotto stretta collaborazione con il team belga sono stati definiti i flussi attualmente presenti nell’ambiente di produzione e sono stati ricreati nel nuovo ambiente. Successivamente sono state implementati flussi più coerenti possibili alla soluzione out of the box messa a disposizione da Remedy e quando questo non è stato possibile sono state implementate delle soluzioni custom. Tendenzialmente, si cerca di evitare soluzioni troppo custom in quanto hanno il forte limite di essere difficilmente mantenibili sul lungo periodo e di rendere complesso il processo di successivi upgrade e update di sistema.

Oltre alle attività direttamente sulla nuova piattaforma sono state implementate le integrazioni con i sistemi di terzi fornitori al fine di permettere la comunicazione e il funzionamento dei flussi e degli scambi informativi fra Remedy ed altri sistemi. La fase di restore del DB del Clone sul nuovo DB dell’ambiente di DEV ha permesso la migrazione di tutte le configurazioni presenti nella current Production, corredata di flussi di lavoro e record (people, company, department, support group, asset, ecc). Successivamente sono state svolte tutte le configurazioni necessarie per garantire un corretto collegamento fra Database e Virtual Machine, per rettificare alcune configurazioni migrate, aggiungerne di nuove, modificare flussi custom e sostituendoli con flussi out of the box.

Una volta svolta la maggior parte delle attività di configurazione in ambiente DEV, non è stato necessario replicare il tutto anche nei due successivi ambienti in quanto il restore da DB di DEV a DB di QACC ha garantito la migrazione di tutte le configurazioni complessive. E poi da quest’ultimo a cascata è stato svolto il restore nel DB di PROD.

4. Test

L’attività di testing è una delle più importanti quando si implementano soluzioni relative a sistemi informatici. Un attento studio delle imperfezioni, degli scostamenti rispetto a quanto pianificato è vitale per la corretta implementazione di un sistema informatico in generale, discorso valido anche per Remedy, per

90

assicurarsi che il prodotto in tutte le sue funzionalità, caratteristiche e livelli di performance soddisfi le esigenze del cliente.

Per tale ragione, in più punti (può essere visibile da Gantt) sono stati inseriti dei punti di controllo continui, data la mole di dati e la complessità delle integrazioni. In questa fase non solo rientrano i singoli test sul sistema, ma anche eventuali interventi per risolvere eventuali problematiche evidenziate non solo dal team interno di progetto ma anche dal gruppo di lavoro belga e dagli altri stakeholder. A tal proposito, durante le attività nei vari ambienti è stata richiesta la collaborazione da parte di stakeholder selezionati, che hanno avuto la possibilità in momenti opportuni di testare il nuovo ambiente e di segnalare eventuali anomalie o semplicemente proporre delle modifiche per rendere i processi più in linea con quelli della current situation.

5. Delta Data Migration (DDM)

Al termine delle attività di installazione, configurazione, integrazione e testing per step successivi sono state implementate delle sessioni di Delta Data Migration, che consiste nell’allineamento dei dati dal DB della Current Production con i nuovi ambienti. Per l’esecuzione della è stato utilizzato uno strumento compatibile con le soluzioni Remedy che ha consentito la migrazione con successo di tutti i record. Il DDM finale ovviamente è stato eseguito durante i giorni del Real Go-Live, in cui occorreva allineare perfettamente i due ambienti di produzione, quello current ed il new.

6. Validazione

Come già anticipato nella sezione appositamente dedicata alla validazione, questo processo è stato svolto per garantire la piena conformità delle attività coinvolte nel processo di Upgrade e delle soluzioni implementate rispetto alle procedure interne. Rispetto alle attività di validazione realizzate nella fase preliminare del processo, questa ha lo scopo in particolare di testare che le soluzioni implementate e soprattutto installate siano conformi rispetto a quanto descritto nel Design Specification e che permettono di raggiungere i livelli di qualità concordati. Tale procedura è stata ovviamente gestita internamente dal cliente in Belgio, il contributo di Alten è stato appunto quello fornire supporto e continui feedback in

91

merito alle attività e fornire inoltre la documentazione necessaria che sarebbe servita come input al processo di validazione.

In particolare, tale procedura è stata attivata al termine delle installazioni di ciascun ambiente per fornire evidenza di quanto installato, in quali server ed altro.

I documenti necessari che hanno determinato l’input a tale processo sono stati fondamentalmente due:

▪ Installation Procedure: si tratta di un documento che ripercorre step by step tutto il processo di installazione sui vari server, per evidenziarne l’aspetto procedurale.

▪ Installation Report: è un documento che certifica l’avvenuta installazione e fornisce dettagli in merito alla tipologia di installazione, dunque se riferita alla platform o all’application e per ciascuna di queste si illustrano:

o Server in cui l’installazione è stata effettuata; o Data e durata dell’installazione;

o Esecutore dell’installazione (nome e azienda);

o Procedure utilizzate per l’esecuzione dell’installazione;

o Percorso su macchine che indica la location del file di installazione o Esito dell’installazione ed eventuali log file

o Firma dell’esecutore.

A partire da questo momento è interessante illustrare il processo implementato lato cliente per testare quanto sopra specificato.

La procedura alla base del processo di validazione utilizza il sistema HP Application Lifecycle Management (HPALM), utile per casi di sistemi regolamentati da standard GxP, come in questo caso e si esplica nelle seguenti fasi:

1- Creazione di Test Script;

2- Review e approvazione dei Test Script; 3- Esecuzione dei Test Script;

4- Defect Management; 5- Test Removal

6- Audit Trial.

Per la realizzazione delle seguenti attività è stato predisposto un team specifico che si è assunto la responsabilità delle attività elencate precedentemente. Il team in

92

questione si è in particolar modo occupato della preparazione dei test case, dell’esecuzione dei test e della revisione dei risultati. In particolare, il team di validazione interno all’organizzazione del cliente ha necessità di garantire che tutti gli step siano eseguiti, che i requirement sono corretti ed in caso di comparsa di errori o comportamenti analoghi, intraprendere le azioni necessarie secondo quanto descritto nel Defect Management.

L’esito di tale processo è stato quindi comunicato al team Alten e questo ha permesso la prosecuzione delle attività nell’ambiente subito a valle.

Il processo di validazione in questione si dettaglia secondo tre livelli differenti di rispondenza ai requisiti, dettagliati nel documento prodotto preliminarmente, ovvero il Test Plan.

Il primo step è quello dell’Installation Qualification, ovvero la certificazione dell'installazione dello strumento.

In tal senso, un nuovo sistema viene validato per verificare se esso sia grado di produrre il risultato desiderato secondo quanto previsto dal Design Qualification, ma le performance in uno scenario real-word dipendono dalla procedura di installazione seguita.

Lo step successivo si basa sulla Operational Qualification, ovvero la certificazione dello strumento con utilizzo di procedure validate e standard certificati. Una volta che ciascun protocollo di IQ viene seguito, le OQ hanno lo scopo di per verificare che le performances del sistema siano coerenti con gli user requirement. In questa fase, tutti gli item riportati nel test plan vengono sottoposti ad analisi individualmente e i rispettivi risultati vengono documentati. Quest’ultima è un prerequisito della technical acceptance del sistema/applicativo.

Lo scopo principale della OQ è quello di identificare dei features inaspettati che possano influenzare in qualche modo il livello di qualità del prodotto.

Infine, l’ultimo step è quello della Performance Qualification.

Si tratta dello step finale ed implica la verifica e la conferma documentata che l’applicativo sta funzionando in maniera ripetibile all’interno di un certo intervallo di tempo. Invece di testare singolarmente il singolo strumento, vengono testati insieme complessivamente come parte di un processo globale.

93

La rispondenza ai requisiti e la certificazione della conformità del sistema installato ed implementato ha consentito il passaggio nell’ambiente subito a valle.

7. User Acceptance Test

Gli User Acceptance Test rappresentano uno step fondamentale nell’ambito del progetto di upgrade della Suite ITSM in quanto permette ai principali utenti finali che si interfacciano con il sistema ITSM di testare le funzionalità nell’ambiente di Quality Acceptance affinché possa essere comprovata la rispondenza ai requisiti d’uso del servizio.

Concluse le attività di configurazione ed integrazione nell’ambiente di Quality Acceptance è richiesto al cliente di predisporre di un team di Key Users che avrebbero dovuto garantire la completa disponibilità all’esecuzione degli User Acceptance Test prima del passaggio nell’ambiente di Produzione per un periodo di tempo definito in fase di definizione e pianificazione delle attività. I Key User in particolare rappresentano un campione selezionato di utenti finali che sono coinvolti nel processo di implementazione del sistema Remedy e che hanno una conoscenza approfondita dei flussi di lavoro tradizionali dell’organizzazione. Non solo la loro importanza è legata al fatto di rappresentare un campione di prova durante il processo di UAT, ma sono stati appositamente formati per fare in modo che una volta in Produzione siano in grado di formare il resto degli utenti.

Proprio per questo motivo è importante che i Key User vengano selezionati partendo dall’analisi dei gruppi di lavoro che si occupano ognuno di una parte specifica del sistema. Dunque, ci sarà un gruppo di Key User che si occuperà in particolar modo della gestione degli Asset, un altro che invece è impegnato sulla gestione del Knowledge ad esempio.

Con l’affiancamento degli esperti Alten, i Key Users hanno potuto accedere agli ambienti secondo quanto descritto di seguito e testare le funzionalità della nuova Suite ITSM seguendo gli step disponibili nei documenti Test Case. Ciascuno di questi ultimi contiene le indicazioni per testare l’ambiente e si differenzieranno a seconda del modulo ITSM interessato. Si richiede inoltre che i membri del team siano orientati al dettaglio ed essere diligenti nella raccolta di documentazione adeguata a supportare i risultati dei test.

94

Durante gli User Acceptance Test l’utente cosiddetto chiave ha avuto la possibilità di inserire il proprio feedback nel documento in corrispondenza di ciascuno step, indicando se il risultato corrispondesse alle aspettative o in caso contrario descrivendo il tipo di errore/malfunzionamento.

La pianificazione dell’attività di UAT è stata realizzata dal team Alten e condivisa in fase di Project Preparation con il team del cliente attraverso il GANTT.

Di seguito è riportato il periodo di UAT in corrispondenza del quale l’intero Team UAT, definito preliminarmente, avrebbe dovuto essere a completa disposizione per l’esecuzione dei test.

Activity Estimated Completion Date

Identify UAT Team 22/12/2017

UAT Start 08/01/2018

UAT End 12/01/2018

UAT Sign-Off 12/01/2018

In questa fase e tenendo conto della metodologia Waterfall adottata per la gestione del progetto, la presenza dei Key Users avrebbe dovuto essere garantita per evitare eventuali slittamenti che avrebbero potuto avere ripercussioni sulla pianificazione delle attività successive.

L’efficacia del processo di UAT è garantita dalla sinergia fra canali aperti di comunicazione, documentazione dettagliata e, soprattutto, ruoli e responsabilità chiaramente definiti.

Dal momento che il processo di UAT è in gran parte un processo collaborativo il team Alten si è impegnato nel fornire il miglior supporto possibile ai Key Users, garantendo elevato livello di disponibilità e supportando gli utenti a risolvere problematiche tempestivamente.

Il processo di User Acceptance Test è stato strutturato sulla base dei seguenti documenti:

▪ UAT PLAN

UAT Plan è il documento principale che viene prodotto già in fase di Project Preparation in quanto definisce le tempistiche, gli stakeholder coinvolti, le modalità di esecuzione, i rischi, la documentazione necessaria. Prima degli UAT tale

95

documento è stato condiviso con il PM del cliente che ha accettato le condizioni e iniziato il processo di identificazione del team di Key User.

Il documento UAT Plan contiene in particolare la descrizione di tale processo, in modo tale da allineare il cliente e i vari stakeholder non solo in relazione agli step da eseguire, ma anche riguardo l’importanza insita in tale processo.

Di conseguenza è stata posta molta attenzione sugli obiettivi e sull’importanza del rispetto delle tempistiche.

L’UAT Plan dunque rappresenta una sorta di guide line per l’esecuzione dei test. All’interno è inoltre stato dettagliato il processo di gestione di eventuali defect riscontrati negli applicativi, in quanto è fondamentale gestire in maniera efficace i feedback in particolar modo in caso di malfunzionamenti per poterli gestire il più tempestivamente possibile. I defect devono essere chiaramente raccolti e comunicati assegnando una priorità per poi essere processati e risolti.

96 Il defect lifecycle è descritto di seguito

Test execution Collect the information related to the defect (screenshot, interface name and steps taken)

Insert the information in the UAT issue

log

Notify directly the Project Team in case of any critical

defects Result as expected?

Complete the UAT Test Case

End Resolution of the defect in charge of the Project Team Yes No

97 • UAT Test Case template.

I UAT Test Case template sono documenti Excel che guidano i Key Users durante lo svolgimento dei test e certificano i feedback a seguito di questi.

▪ UAT Sign Off:

Si tratta di un documento formale che determina la fine del processo di UAT e permette al cliente di certificare, per ciascun modulo ITSM testato, quali siano i risultati e se il sistema complessivamente risponde ai requisiti d’uso determinati in fase di progettazione.

L’esito complessivo degli UAT permette al team Alten di procedere con le attività nell’ambiente di Produzione.

Gli UAT Test Case template sono documenti Excel che hanno duplice scopo, ovvero sia quello di guidare step by step i Key User durante l’esecuzione dei test nella Suite ITSM, che quello di lasciare spazio a feedback a seguito del test stesso. Ciascun template contiene i seguent tab:

1. Cover: pagina iniziale in cui si definiscono il modulo ITSM oggetto di verifica, Key e Approver Users, data.

2. Modulo Oggetto di UAT composta delle seguenti colonne: ▪ Test case ID

▪ Requestor test Indicazioni per Key User ▪ Test details

▪ Test interface

▪ Requestor feedback [Ok/NOk]

▪ Error Message (if applicable) Feedback da Key User ▪ Requestor remarks

Ciascuna riga rappresenta un Test Case specifico in cui verranno dettagliati gli step da seguire per ciascuno scenario proposto.

98

3. UAT Defect Log: nel caso in cui durante il test dovessero presentarsi dei malfunzionamenti, dei messaggi d’errore o altri impedimenti alla fine del