Il blog di un CIO in outsourcing

Anche la creazione dell’area riservata per l’erogazione delle informazioni attinenti all’ICT aziendale dei miei clienti, si è rilevata un vero flop. Pochi iscritti, soprattutto distratti, confermano che il brand / il nome del dominio / il senso di appartenenza sono fondamentali anche nella comunicazione interaziendale.

Pertanto il mio handbook online lo sarà, ma in blog dedicati, implementati presso i service provider dei clienti. Visto il continuo successo dei Social Network, per non “appiattire” troppo le discussioni che si innescano nell’affrontare i problemi, ho deciso di utilizzare lo stesso approccio per l’erogazione dei contenuti informativi & formativi. L’idea è nata dall’aver sperimentato la possibilità di creare un Social Network privato mediante l’utilizzo di software open source, in particolare WordPress e Buddypress. L’occasione mi è stata data, come di consueto, dal Gruppo Di Mauro che ha finanziato il progetto per la creazione di un social network privato.

Già tre clienti, compresa la Di Mauro stessa, mi hanno chiesto, visionata la piattaforma, di implementare i medesimi meccanismi per il loro business. L’altra sfida di quest’anno sarà quella di integrare strumenti di groupware nel medesimo ambiente, al fine di creare quello che dagli addetti ai lavori viene definito Social Business.

Info di servizio.
La giovane area riservata di questo sito, per i motivi sopra esposti, cessa di esistere (era nata in Agosto) nei termini in cui era nata (ovvero come riservata agli operatori dei clienti), e si trasforma (o meglio si trasformerà), in un area per contenuti premium (in fase di lavorazione). Anche le categorie ed i TAG subiranno in queste ore una razionalizzazione (speriamo solo che“Google” non mi “danneggi” molto ). Il Web Service Desk, diventa anch’esso uno strumento orientato al committente finale (quelli diretti al suo operatore verranno opportunamente implementati sui rispettivi domini… vale lo stesso discorso dell’handbook).

Anche il sito aziendale subirà alcune modifiche riguardanti l’organizzazione del contenuto che spero possano, nel complesso, facilitare la navigazione dei lettori.

Buon anno e buon lavoro a tutti.

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.

Buon rientro dalle vacanze a tutti.

Quando questo articolo verrà pubblicato (questo è un post programmato), io probabilmente sarò ancora in vacanza (sono iniziate in ritardo quest’anno). Tuttavia come da tradizione della blogsfera più agguerrita, non potevo non “augurarmi” buon compleanno in tempo, seppur da “lontano”

All’inizio di quest’avventura, iniziata esattamente 1 anno fa, i miei obiettivi erano (mi autocito):

In questo spazio spero di poter condividere le mie esperienze con i "colleghi" che vorranno leggermi, fornire risorse ai miei clienti più fidelizzati, chiarire il mio lavoro ai miei potenziali clienti e … perchè no? mostrare qualcosa di personale.

A chi mi chiede: “Perché lo fai?”

Un anno dopo, rispondo: “Per gli stessi motivi di un anno fa (non credo di esserci ancora riuscito anche se qualcosa si muove)”.

Insomma sono ancora in barca a vela contromano, e poi … che fastidio vi do.