Il blog di un CIO in outsourcing

Senza tanti giri di parole, notifico la chiusura del mio blog.

Questo è l’ultimo post.

Non ho più tempo di “progettarlo” e manutenerlo in modo adeguato e, soprattutto, il suo titolo, “Il blog di un CIO in outsourcing”, non è più rappresentativo per il mio lavoro, ed essendo nato il blog principalmente per spiegare meglio quest’ultimo ai non addetti, capite che ne decade il senso.

La crisi finanziaria ed economica spinge il mercato a richiedere “informatici” con un elevato grado di specializzazione, ma l’approfondimento “tecnico” distoglie dalle problematiche e dalle tematiche che un CIO dovrebbe affrontare (comunicazione aziendale, conoscenza del business, strategia, selezione dei fornitori, budget, programmazione e motivazione del personale, gestione dei progetti, … etc.).

Questo blog è stato un susseguirsi di promesse mancate. Rileggendolo mi sono accorto della frenesia che invade la mia professione (e che mi invade). Non fraintendetemi! Da grande voglio fare il CIO, ma ho una famiglia da sfamare, e certi “investimenti” (soprattutto di tempo) non me li posso più permettere…

Prima di salutarvi, vi segnalo un’ultima risorsa su ITIL che mi è stata notificata via sito da un collaboratore della società che l’ha prodotto. E’ un video che trovo veramente ben fatto, in grado di comunicare ad un personale non tecnico, con un esempio concreto, gli obiettivi dell’ITSM.

Il futuro? Per fortuna non lo conosciamo! Personalmente mi sto concentrando sul Business Process Management e le sue Suite… stay tuned… chissà… un giorno potrei aprire un altro blog per i miei pochi lettori

Saluti

Nel precedente post abbiamo ragionato circa l’utilizzo del PDCA per tutti i processi di gestione.

“Controllare” e “Azionarsi per il miglioramento” sono attività per nulla semplici. Tale complessità del resto giustifica la differenza di stipendio esistente tra i controllori e i controllati (che sono quelli che producono e “danno a mangiare a tutti” … un buon manager non dovrebbe mai dimenticarlo).

I Manager di oggi sono comunque più fortunati di quelli di appena due / tre decenni fa. In loro aiuto infatti, per lo svolgimento delle attività suddette, arrivano le cosiddette soluzioni di Business Intelligence.

In uno dei prossimi post, che sarà sicuramente più lungo di questo, cercherò di spiegare semplicemente che cos’è la Business Intelligence.

Il primo del 2011? chissà … dipenderà dalle ferie che riesco a concedermi ).

In questo articolo su ITIL-Italia si afferma che:

Lo standard ISO/IEC 20000 raccomanda l’utilizzo del ciclo PDCA (Plan – Do – Check – Act) per l’implementazione di tutti i processi, e definisce le varie fasi come segue:

• Pianificazione (Plan): identificazione degli obiettivi e dei processi necessari per fornire i servizi in accordo con le necessita’ dei clienti e le politiche aziendali
• Implementazione (Do): l’effettiva implementazione del
• Controllo (Check): il monitoraggio e la misura dei risultati conseguiti rispetto agli obiettivi predeterminati
• Azione e Miglioramento (Act): L’attuazione delle azioni necessarie per rendere definitivo e/o migliorare il processo.

La domanda che mi faccio (e che vi faccio) è la seguente: Ma tale ciclo non va seguito per l’implementazione di tutti i processi (quelli FITS, ITIL, etc.)? Io credo di si.

Pianificare vuol dire pensare “come fare”, implementare equivale a “trovare e/o utilizzare e/o creare uno strumento”, controllare implica “la costruzione di una strumentazione per la verifica e/o misurazione dei risultati”, e migliorarsi comporta “l’analisi dei risultati” e la “definizione delle azioni da compiere” (decisioni della Direzione). Tutto segue questo flusso.

Questo è un post segnalibro di risorse interessanti per tutti i consulenti interessati ad intraprendere un’attività di management ICT senza reinventarsi la ruota.

Schema processi ITIL:

• http://www.itil-italia.com/itilv2.htm (v2)
• http://www.itil-italia.com/itilv3.htm (v3)

Le differenze tra le due versioni di ITIL sono esemplificate ottimamente in questo articolo di Stefano Rossini su Javaportal.

Spero di avere fornito due buoni punti di partenza per avviare lo studio di questo framework.

Mediante il processo di Financial Management (“gestione finanziaria”) si vogliono fondamentalmente monitorare due cose:

• i costi per la fornitura dei servizi ICT (es. elettrici, hardware, software, canoni linee, etc.);
• i costi di supporto tecnico.

Registrare correttamente i costi sostenuti per l’erogazione dei servizi ICT aziendali aiuta a:

• creare un bilancio dedicato;
• migliorare il processo di budgeting;
• identificare i costi non preventivati;
• individuare i costi che sono stati superiori alle previsioni;
• individuare la causa dei costi;
• identificare le aree di possibile riduzione dei costi;
• applicare un modello di controllo dei costi.

L’implementazione del processo segue il flusso in figura (dalla stessa è possibile banalmente desumere l’interazione di questo processo con quello di Service Level Management)

To do list

• Analizzare le metodologie per ridurre i costi ICT;
• Analizzare periodicamente l’offerta del mercato ICT;
• Standardizzare e razionalizzare l’infrastruttura ICT;
• Applicare economie di scala per gli acquisti;
• Formare gli utenti per un corretto utilizzo delle apparecchiature e dei servizi ICT;
• Migliorare il processo di incident management per ridurre il numero di interventi dei fornitori esterni;
• etc.

Con la presentazione del processo di “gestione finanziaria” di FITS, si conclude una veloce carrellata in merito ad un framework di gestione ICT, che non aveva alcuna pretesa di essere esaustiva.

Esaustiva è solo la pratica.

Spero di poter riuscire a trovare in futuro il tempo per mostrarvi come ho attuato FITS sui miei clienti (intendo step-by-step e con quali strumenti).

Service Continuity Management (“gestione della continuità del servizio”) è il processo mediante il quale si pianificano i piani di emergenza da attuare in casi di eventi catastrofici che dovessero compromettere seriamente, e/o mandare “down”, servizi ICT. Implica in primo luogo l’analisi dei rischi e l’implementazione di contromisure per ridurre al minimo la probabilità di tali eventi.

Il processo segue il workflow in figura

To do list

• Identificare i servizi
  I servizi sono “infrastrutture” ICT a disposizione degli utenti, a differenza delle apparecchiature hardware | software che lo assemblano / compongono, quali connessione internet, email, stampa, erp, etc.;
• Identificare gli asset
  Un asset sono i componenti che implementano il servizio. Es. hardware, software, linee dati, database, contratti con i fornitori, etc.;
• Identificare i rischi
  Pensate a tutto ciò che può danneggiare un servizio ICT. Es. attacco virus, allagamento, caduta linea dati, guasto, sabotaggio, mancanza di energia elettrica, etc.;
• Identificare le minacce
  Considerate quanto sia probabile che accada un evento, valutando ad es. i sistemi di sicurezza in essere;
• Implementare le contromisure
  Per quanto possibile riducete il numero di minacce ad es aumentando il livello di sicurezza, programmando le manutenzioni, monitorando i possibili colli di bottiglia e/o punti di failure, creando backup di sistemi, etc.;
• Realizzare i piani di emergenza
  Siate pronti ad affrontare gli eventi disastrosi, implementando opportuni piani di backup & recovery.

Quanto costa la business continuity?

E’ una domanda alla quale è difficile fornire una risposta, in quanto il costo può variare in funzione di diversi fattori, in particolare:

• Investimenti
  Necessari per l’acquisto di asset di backup, di consulenza per la definizione dei rischi e dei piani di emergenza, per l’acquisto di infrastrutture esterne, etc.;
• Persone
  Varie sono le figure che ruotano nell’ambito della definizione dei piani dei rischi / backup / recovery;
• Tempo 
  La quantità di tempo necessaria per l’implementazione di tale processo, sarà direttamente proporzionale al grado di maturità di altri processi visti in precedenza (la sequenza dei post di presentazione di FITS non è casuale).

In generale il costo della business continuity dei servizi dovrebbe essere controbilanciato dal valore aggiunto dello stesso e/o dal potenziale costo che si registrerebbe in caso di guasto.

Ho già parlato di questo argomento in un vecchio post ("Come si vende un progetto di infrastruttura ICT ?" ), e lo farò in futuro.

Il processo di Service Level Management (“gestione del livello di servizio”) ha come obiettivo quello di garantire che tutti i servizi ICT (connessione internet, fonia, email, software gestionale, etc.) siano mantenuti “up” per un “periodo accettabile”.

L’estensione di tale periodo definisce il “livello” del servizio.

E’ in pratica il processo che disegna il trade-off (compromesso) tra capacità e disponibilità.

Tale compromesso va sottoscritto in accordo con tutte le parti, tipicamente:

• Direzione;
• Responsabili di reparto;
• Una rappresentanza degli utenti finali;
• Fornitori esterni.

Esempio

La Di Mauro srl ha un’officina dislocata presso una sede distaccata. In virtù della complessità dei servizi ICT offerti dalla sede centrale, in ambito di disegno dell’architettura di rete, si è optato per una Virtual Private Network, implementata su firewall di proprietà aziendale, al fine di garantire il collegamento tra le due sedi.

I punti di failure, in un contesto del genere, sono:

• Connessioni internet;
• Hardware di rete (firewall, router, switch, etc.).

Vista l’assoluta necessità di mantenere il collegamento VPN sempre “up” durante le ore lavorative, si sono presi accordi con alcuni fornitori di hardware sul territorio, e si è deciso di dotarsi due linee XDSL per sede, una primaria e una di backup. Si sono poi presi SLA (Service Level Agreement – Accordi sui Livelli di Servizio) con il provider di connettività, del tipo:

• Caduta collegamento primario => “up” backup in 1 ora + Risoluzione guasto in 8 ore;
• Caduta collegamento primario + backup => Risoluzione guasto in 5 ore.

To do list

Di seguita una immagine riepilogativa della To do list da attuare per implementare il processo

I passi sono i seguenti:

• Documentare e concordare i servizi (catalogo dei servizi) con la Direzione / Responsabili di reparto;
• Far accettare e pubblicare i livelli di servizio in funzione delle capacità aziendali;
• Definire e attuare i contratti con i fornitori esterni;
• Monitorare e rivedere livello di servizio periodicamente.

La “gestione della disponibilità e delle capacità” viene implementata in ITIL mediante l’utilizzo di due processi distinti.

Obiettivo del processo di “gestione della disponibilità” è quello di garantire che i servizi ICT abbiano downtime (tempo di malfunzionamento) bassi, soprattutto nelle ore necessarie.

Anche questo processo risulta essere caratterizzato da una fase proattiva, ed una fase reattiva:

• proattiva – progetto del availability plan (piano di disponibilità);
• reattiva – attuazione del recovery plan (piano di recupero), il cui scopo è quello di essere di ausilio all’individuazione ed alla risoluzione dei problemi che si verificano;

Obiettivo del processo di “gestione delle capacità” è quello di aiutarvi a garantire che i componenti delle infrastrutture ICT siano in grado di supportare i servizi richiesti.

Esempi di capacità sono:

• spazio su disco per l’archiviazione di file;
• potenza di elaborazione;
• memoria;
• banda minima garantita;
• etc.

Questo processo risulta essere caratterizzato prevalentemente da una fase proattiva, che comporta la pianificazione della crescita necessaria di capacità, in funzione del cambiamento dei servizi / SLA, e l’individuazione di problemi di capacità potenziale (prima del loro verificarsi).

Tuttavia ci sono due temi comuni alla gestione delle disponibilità e a quella delle capacità: il rilevamento e la prevenzione. FITS razionalizza e semplifica l’approccio di ITIL, sulla base di questa comunanza, esemplificando due sotto-processi.

Monitoraggio di rete (Network monitoring)

Monitorare la rete vuol dire rilevare tutte le attività in essere, e l’impatto che le stesse hanno sull’infrastruttura. Monitorare le capacità, i picchi di richiesta / uso, ricercare punti di failure e/o colli di bottiglia, sono tutte azioni incluse in questo sotto-processo che può essere sintetizzato nella figura che segue.

Manutenzione programmata (Preventivate Manteinance)

La manutenzione programmata (o preventiva) è incentrata sull’utilizzo intelligente delle informazioni risultanti dal monitoraggio di rete.

In sintesi si cerca di individuare i miglioramenti che possono essere svolti per evitare problemi di disponibilità e di capacità prima che accadano.

To do list

• Progettare l’infrastruttura di rete / CED per ridurre al minimo le possibilità di failure;
• Attuare un piano di modifiche interfacciandosi con il processo di Change Management;
• Adottare tutti i sistemi di sicurezza disponibili per proteggere rete (firewall) e postazioni (software antivirus / antimalware);
• Dotarsi di un magazzino per le parti di ricambio dei software / hardware identificati come killer application (si pensi ad es. alla scheda di flusso primario di un centralino VoIP);
• Dismettere apparecchiature con capacità non adeguate alle nuovi richieste;
• Configurare gli elementi in modo standardizzato;
• Mantenere aggiornata una documentazione della rete e della sua architettura / dimensione;
• Creare un programma di manutenzione per l’ottimizzazione delle postazione ed il continuo tuning dei servizi di rete;
• etc.

Riprendiamo i lavori continuando la rapida carrellata su FITS, e affrontando nuovamente (lo abbiamo già fatto quì) il processo di Problem Management.

Nel post citato volli evidenziare, utilizzando un esempio banale, la differenza tra i due processi che, a prima vista, in virtù del nostro vocabolario ridotto (parlo di noi “tecnici”), possono apparire identici.

In realtà l’obiettivo del processo di “gestione dei problemi” è quello di ridurre al minimo sia il numero che la gravità degli incidenti.

Risulta pertanto essere un processo caratterizzato da una fase proattiva, ed una fase reattiva:

• proattiva – individuare e risolvere i problemi e gli errori noti prima che gli incidenti si verifichino;
• reattiva – individuare la soluzione dei problemi quando uno o più incidenti si verificano.

Se esiste un dipartimento ICT con risorse di personale e finanziarie adeguate, la fase “reattiva” del processo differisce dall’obiettivo della “gestione degli incidenti”, in quanto tenta dal principio di ripristinare il servizio al cliente, seppur il più rapidamente possibile, ma cercando di attuare da subito una soluzione permanente.

Incidenti Vs problemi. L’ultima “battaglia”

Un incidente si verifica quando qualcosa non funziona nel modo previsto.

Le espressioni maggiormente utilizzate sono:

• “si è verificato un guasto”;
• “si è verificato un errore”;
• “il sistema non funziona”;
• “si è verificato un problema”.

Tuttavia il termine usato con FITS è “incidente“.

Un problema può essere:

• il verificarsi più volte dello stesso incidente;
• un incidente che colpisce molti utenti.

Quindi un problema può esistere senza avere un impatto immediato per l’utente, mentre gli incidenti sono di solito più visibili e l’impatto sull’utente è più immediato.

To do list

• Assegnare ruoli e responsabilità;
• Preparare gli utenti, Service Desk e personale di supporto tecnico (fornitori esterni);
• Decidere come il service desk passerà i problemi tecnici (strumenti, dipartimenti, priorità, etc.);
• Predisporre una documentazione di tutte le fasi del progetto;
• Decidere chi sarà ad analizzare le tendenze degli incidenti per individuare i problemi di fondo;
• Decidere come verranno registrate le risoluzioni dei problemi e valutare l’utilizzo di un sistema di Knowledge Management.

Continuiamo la rapida carrellata sui processi FITS.

La gestione della configurazione è il processo di creazione e mantenimento delle informazioni rilevanti di ogni oggetto/elemento che costituisce l’infrastruttura ICT.

In altri termini è l’insieme di azioni che è necessario svolgere per mantenere costantemente aggiornato l’inventario hardware / software / servizi ICT.

Per mettere in atto il processo è indispensabile dotarsi di un CMDB, ovvero di un database estendibile, in grado di memorizzare tutte le informazioni di interesse degli oggetti di configurazione, denominati Configuration Item (CI).

Dal sito di Tecnoteca, che ha sviluppato e promuove CMDBuild, ovvero un CMDB Open Source tutto italiano, vi riporto alcuni passaggi chiave che meglio fanno comprendere di cosa stiamo parlando.

Chi utilizza il CMDB
Le organizzazioni per le quali è strategico avere sempre sotto completo controllo la situazione degli elementi informatici utilizzati(Gestione della Configurazione), conoscendone in ogni momento la composizione, la dislocazione e le relazioni funzionali.
Informazioni mancanti o non aggiornate significano costi inutili, operazioni ridondanti, ritardo nella risoluzione dei problemi, intralcio alle attività aziendali.
Le parole chiave di un CMDB sono: velocità di risposta < – > controllo del sistema
Quali elementi informatici gestisce il CMDB

• hardware: computer, periferiche, sistemi di rete, apparati di telefonia
• software: di base, di ambiente, applicativo
• documenti: progetti, contratti, manualistica
• altre risorse, interne ed esterne

A quali domande risponde il CMDB

• dove si trova un CI (configuration item) ?
• chi lo usa ?
• di cosa fa parte ?
• da cosa è composto ?quali sono e dove si trovano altri CI analoghi ?
• ho licenze sufficienti per l’utilizzo del software ?
• cosa è successo nella vita del CI ?
• su quali altri CI impatta una eventuale modifica ?

Un CMDB consente di:

• ridurre i problemi al proprio sistema informatico
• risolvere più velocemente i problemi residui
• disturbare meno frequentemente il personale più esperto

In altre parole diminuzione dei costi e miglioramento della qualità dei servizi.
Per contro gestire il sistema IT in modo controllato vuol dire anche:

• disporre nel posto giusto delle informazioni necessarie
• dotarsi di un sistema informatico di gestione
• utilizzare risorse che mantengano il sistema sempre aggiornato

Cosa fare in sintesi?

• Assegnare ruoli e responsabilità;
• Definire gli elementi / oggetti di configurazione (CI) ed il livello di dettaglio adeguato all’organizzazione;
• Definire gli attributi dei CI;
• Alimentare il CMDB;
• Definire un metodo per l’aggiornamento del CMDB;
• Preparare tutti i partecipanti (dettagliare le operazioni del processo step-by-step);
• Impostare una data di inizio per il processo che permetta il tempo di prepararsi;
• Comunicare il piano al team di implementazione e informare gli utenti;
• Implementare, se possibile, il processo solo su un reparto che faccia da pilota per le procedure di manutenzione del CMDB.