Application Management: baseline on demand

Transcript

1 Application Management: baseline on demand Tiziano Salmi Milano, 10 febbario

2 Architecture & Applicazione Solutions Assicurare la valutazione, la progettazione, la realizzazione e l'integrazione delle soluzioni applicative, in collegamento con le altre unità della funzione; Assicurare l'erogazione dei servizi di application management, garantire l'operatività delle applicazioni e la gestione dei disservizi; Proporre e valutare, congiuntamente con le altre unità della funzione, interventi migliorativi del parco applicativo per accrescere efficacia ed efficienza dei servizi erogati;.. 2

3 Application Management: Il modello ENI ICT I servizi di application management: Evolutiva a release Baseline Baseline on demand 3

4 Application Mangement: gestione a release (1) I principali obiettivi che ICT Eni intende perseguire con la razionalizzazione dei rilasci di SW per le applicazioni in gestione sono i seguenti: Miglioramento del processo di raccolta requisiti e definizione delle priorità Analisi costi\benefici sugli sviluppi Sviluppo capacità di pianificazione degli intereventi necessari Ottimizzazione del controllo delle attività di rilascio Maggiore efficienza nei rilasci Armonizzazione con rilasci progettuali Ottimizzazione costi di gestione della configurazione Diminuzione dei costi di change Date certe sui rilasci in produzione (pianificazione sviluppi e rilasci) Gestione integrata delle attività sistemistiche ed infrastrutturali (upgrade, patch, etc.) Pianificazione compatibile delle attività di infrastruttura Presidio puntuale delle attività relative al SOX (compliance) ed in particolare riguardanti i controlli GCC Ottimizzazione dei collaudi e gestione efficiente regressioni Diminuzione di errori di versionamento (dettati da sovrapposizioni di rilasci)

5 Application Mangement: Gestione a release (2) Diminuzione dei costi di change Date certe sui rilasci in produzione (pianificazione sviluppi e rilasci) Gestione integrata delle attività sistemistiche ed infrastrutturali (upgrade, patch, etc.) Pianificazione compatibile delle attività di infrastruttura Presidio puntuale delle attività relative al SOX (compliance) ed in particolare riguardanti i controlli GCC Ottimizzazione dei collaudi e gestione efficiente regressioni Diminuzione di errori di versionamento (dettati da sovrapposizioni di rilasci) Al fine di perseguire tali finalità e con l obiettivo di clusterizzare le tipologie di approccio metodologico è stata effettuata introdotta la seguente classificazione relativamente alle tipologie di release: Release di contenuto Release tecniche 5

6 Release di contenuto Le release di contenuto sono caratterizzate dalle seguenti peculiarità: Applicabilità su filiere di sistemi integrati (i.e. CRM Eni Div G&P con copertura dell intero processo di offertazione cliente, dal Contatto (Sales Force Automation), alla Fatturazione) Necessità, a fronte della numerosità dei sistemi in giuoco, della numerosità degli attori di Business, delle integrazioni in termini di processi e degli impatti reciproci tra gli sviluppi, di un tavolo di coordinamento (Business, ICT) che analizzi le richieste e confezioni opportunamente la release effettuando attività di raccolta, prioritizzazione, analisi d impatto sulla filiera dei sistemi coinvolti, analisi costi benefici e pianificazione degli interventi verificando i calendari sui singoli sistemi. Volumi consistenti in termini di giornate di evolutiva da erogare

7 Release tecniche Le release tecniche sono caratterizzate da volumi minori, in termini di giorni/costi per evolutiva da erogare e, a fronte anche di impatti limitati ai sistemi oggetto di evolutive, si configurano come attività di pianificazione e calendarizzazione dei rilasci con l obiettivo di razionalizzare e rendere quindi più efficienti i momenti di raccolta del fabbisogno utente, le attività di pianificazione, realizzazione e test, preservando la gestione delle attività di configurazione e la diminuzione dei costi di change. Le release tecniche sono quelle che impattano le piattaforme: Siebel, Oracle, Sistemi Operativi, Up grade per la gestione della sicurezza, ect

8 Alcuni assunti del modello La raccolta dei requisiti e la definizione delle priorità avviene con continuità durante tutto l anno. Per ogni applicativo sono definiti i punti di consistenza delle release successive. Per ogni release si prevede un dimensionamento con un battente flat rispetto al budget fornito dal Business, atto a favorire il dimensionamento del GdL e la retention delle competenze. Per il consolidamento delle release è prevista la seguente codifica: AAAA. Rel. X.Y, dove X indica la major release di riferimento ed Y la minor release. La durata della realizzazione per release standard è di circa 2 mesi; il periodo di collaudo avrà una durata indicativa di circa un mese per ogni release. La permanenza di requisiti in ambiente di collaudo per periodi superiori all arco temporale dedicato ai test comporta lo stralcio dello sviluppo dal contenuto del rilascio ed il possibile rework nelle release successive Il coinvolgimento del Business è previsto nelle fasi di Analisi ed User Test.

9 Gestione a Release:straordinarietà e minor release Il modello a release adottato integra la gestione delle straordinarietà di seguito riportate: - adempimenti normativi esterni (i.e. direttive AEEG) o interni (SOX, Audit, etc) - scorpori od incorporazioni societarie - unbundling 9

10 Gestione a Release: il modello 10

11 Gestione a Release: il modello (1) 11

12 Baseline on demand:criteri di applicazioni Rispetto all ipotesi della nuova modalità contrattuale AM on demand, viene suggerito un criterio per la identificazione delle applicazioni potenzialmente convertibili. E stato ipotizzato che questa modalità sia utile per gestire situazioni che hanno una scarsa movimentazione (applicazioni ben consolidate, o solo processi periodici, esiguo numero di utilizzatori..) I parametri presi in considerazione per enucleare questi elementi sono stati: n. di interventi di AM registrati nel corso di tutto il 2009 n. di Utenti dell applicazione N.B. : sono stati presi in considerazione solo gli elementi dell AppCat significativi (es. esclusi i siti istituzionali, le applicazioni dismesse, in sola lettura, previste) 12

13 RISULTATI DEI CRITERI Criterio Utenti ,9 Impatto FTE : 24,7 N applicazioni: ,7 SÍ NO N Appl. FTE Criterio Interventi Criterio: n utenti < 10 Se si considera l intersezione tra i due criteri si ottiene come impatto 20,3 FTE ,9 Impatto FTE : 96,7 N applicazioni: SÍ 96,7 N Appl. FTE 158 NO Criterio: n interventi < 2/mese N.B.: E disponibile il dettaglio delle applicazioni I criteri sono impostati in modo parametrico 13

14 Baseline on demand: 14

15 Grazie dell attenzione Tiziano Salmi 15