Il blog di un CIO in outsourcing

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.

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).

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.

Compiti per le vacanze.

E’ difficilissimo mantenere una linea di condotta aderente agli obiettivi prefissati a inizio anno mentre si lavora, per svariati motivi che (solo) chi lavora (sul serio) conosce.

E allora perché non usare un pezzetto delle proprie preziose ferie, per valutare dove siamo e ripensare la priorità dei progetti che stiamo seguendo?

Non sarà facile mettere ordine nelle cartelle cartacee ed elettroniche, analizzare i risultati raggiunti, i compiti posticipati e poi dimenticati, etc etc … ma sarà utile e soprattutto potrete farlo senza “fretta”, questa “emozione” che sta rovinando il mondo.

Aiutatevi riscrivendo gli obiettivi su un foglio di carta o in alternativa, se avete un netbook, con una mappa mentale.

Se lavorate nel mio settore, e soprattutto se volete continuare a farlo come consulenti, seguite questa piramide

L’ho trovata in questo interessantissimo articolo su TechRepublic.

Si commenta da sola. Sono sicuro che il ragionamento di fondo (le cose “importanti”, quelle veramente importanti, si fanno prima) si applica ad ogni “sistema”.

Come al solito i il riscontro positivo da parte del committente, si avrà nel lungo e medio periodo. Troppo spesso imprenditori poco illuminati, o frettolosi, ci fanno commettere degli errori che noi, per ragioni di visibilità o di un qualche tornaconto personale (non necessariamente di tipo economico, parlo della soddisfazione che si prova nel fare delle cose anziché altre), facciamo troppo poco per evitare.

Le fondamenta sono “importanti”. Smettiamola di costruire grattacieli su delle palafitte. Pretendiamo il “tempo necessario” per la realizzazione di infrastrutture solide.

Tanto prima o poi i debiti si pagano, ma se non si rispetta una gerarchia nei progetti ICT (e probabilmente anche quelli di altra natura), i conti tornano più “salati”.

Buone vacanze a tutti!

PS. La mia idea di “fretta”

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.

Sono ancora quì. Finalmente è iniziata!!!

L’avventura imprenditoriale che mi ha tenuto lontano dal mio neonato blog (e da altro), intervallata da una breve vacanza per festeggiare l’anniversario di matrimonio in quel di Capo Verde, ha il nome di Granturismo S.p.A., nuova concessionaria BMW e MINI della famiglia Di Mauro.

 
foto prelevata da NapoliToday

Giovedì 17 Giugno si è tenuta la conferenza stampa e la festa di inaugurazione che si sono volute far coincidere con la presentazione della BMW Serie 5 Touring e della MINI Countryman. Per dettagli sulla serata e sulle dichiarazioni del direttore vendite BMW Fabrizio Longo,  cliccate qui.

Le attività necessarie per far startare un concessionaria BMW dal punto di vista ICT? A scopo esemplificativo, ma non esaustivo, ve le elenco qualcuna di seguito.

• Studio architettura funzionale casa madre e definizione fabbisogno;
• Ordine rack, materiale elettrico, apparati di rete, linee dati, server, software ERP, etc.;
• Montaggio rack, gestione allaccio linee, configurazione switch, montaggio e configurazioni server;
• Installazione e configurazione centralino (sviluppo IVR);
• Montaggio postazioni (video, PC, telefoni VoIP, stampanti locali e di rete, etc.);
• Supervisione installazione server e client del software gestionale, e formazione tecnica e utente;
• Analisi e gestione integrazioni varie fra sistemi della casa madre e sistema gestionale (ancora in corso …);
• Installazione software e configurazione prodotti legati al progetto di casa madre denominato ISPI (Integrated Service Process Initiative), quali l’ISIS (Integrated Service Information Server), l’ISID (Integrated Service Information Display), l’ICOM (Integrated Communication Optical Module), l’IMIB (Integrated Measurement Box), etc

Con tutte queste cose da fare resta davvero poco tempo per altro e, soprattutto, per scrivere qualcosa di veramente utile e/o interessante.

Ricomincio da oggi (o perlomeno ci proverò).

Riprendiamo la nostra carrellata sui processi / servizi da implementare per governare il reparto ICT utilizzando il framework FITS (The BECTA Framework for ICT Technical Support) sviluppato dalla British Eductional Communications and Technology Agency (basato su ITIL).

La gestione degli incidenti (incident management) è un processo definito per la loro registrazione e risoluzione.

L’obiettivo è quello di ripristinare un servizio andato giù, nel più breve tempo possibile. Ciò si realizza molto spesso mediante una correzione temporanea e/o soluzione parziale, piuttosto che con una soluzione permanente.

La ricerca di una soluzione definitiva ad un problema è compito di una altro processo, ovvero appunto la gestione dei problemi (problem management).

Le cose da fare per implementare tale processo sono, in estrema sintesi:

• Assegnare ruoli e responsabilità;
• Elaborare la documentazione necessaria agli utenti ed al Service Desk per operare;
• Preparare gli utenti, il Service Desk, e il personale di supporto tecnico (interno e/o esterno);
• Decidere in che modo il Service Desk deve eventualmente “scalare” gli incidenti ai tecnici;
• Implementare e testare un sistema di Knowledge Management (gestione della conoscenza) per una tempestiva condivisione e gestione di incidenti ricorrenti (necessario per l’individuazione dei problemi);
• Decidere come il sistema di Knowledge Management deve essere alimentato (dal Service Desk e/o dai tecnici e/o da entrambi);
• Definire un piano di comunicazione dettagliato per tenere aggiornati gli utenti durante tutto il ciclo di vita dell’incidente;
• …

I puntini sospensivi sono d’obbligo … ci sarebbe tanto da scrivere … appunto …

Il puerile giuoco di parole che da il titolo al post del “ritorno”, perché è ormai da tanto che non scrivo più sul blog, è volutamente provocatorio.

Nell’’ultimo periodo ho seguito la fase di start up di un nuova azienda (di cui scriverò in un prossimo post), ancora non terminata tra l’altro, che ha assorbito quasi tutte le mie risorse psicofisiche.

Lo stress è sollecitato, oltre che dal lavoro in se, anche da altre cause che posso sintetizzare così:

• gli “scleri” degli operatori che non hanno ancora funzionanti tutti i loro strumenti informatici, e che per questo si sentono in diritto di sbraitare e, soprattutto, di poter sbagliare;
• i ritardi dei fornitori esterni / la loro gestione;
• il pressing della Direzione sulle scadenze.

In questo caso tutte le scadenze che avevo programmato sono saltate.

Senza entrare nel merito, mi sento di consigliare di moltiplicare per tre i tempi dei lavori stimati sulla base del “se tutto va bene, il tempo per portare il lavoro a termine è …”, se si è in presenza di una direzione tecnica cieca agli sforzi profusi per abbattere le resistenze, interne ed esterne, alla riuscita di un progetto.

Attenzione alle catene!

Se avete delle scadenze, ribaltatele sui fornitori esterni e/o in subappalto. Se non potete farlo (nel mio caso è stato così) da contratto, considerate in programmazione, un delta di tempo per effettuare i solleciti alle lavorazioni e soprattutto “scalate” le Vs richieste alla Direzione / Proprietà.

Siamo “obiettivi”?

La domande alla quali, quando avrò un momento in più per pensare, dovrò fornire risposta sono:

1. Riusciamo ad essere obiettivi nel fissare una scadenza quando ci troviamo di fronte a fornitori “ingestibili”?
2. Il rispetto assoluto di una scadenza, non può rappresentare un ostacolo alla realizzazione di un obiettivo (mi riferisco alla qualità del risultato di progetto)?

Sono bene accetti consigli e considerazioni di merito.

Ringrazio in anticipo chi interverrà.

Iniziamo la nostra carrellata sui processi / servizi da implementare per governare il reparto ICT utilizzando il framework FITS (The BECTA Framework for ICT Technical Support) sviluppato dalla British Eductional Communications and Technology Agency (basato su ITIL).

Un Service Desk è un sistema di persone, processi e prodotti che si pone come interfaccia unica tra gli utenti e tutti i servizi ICT aziendali, e gestisce tutte le fasi della richiesta di assistenza. Le richieste che esulano dalle competenze dei suoi membri, vengono passate al fornitore e/o gruppo di persone in grado di risolvere il problema. Differisce da un help desk tradizionale in quanto supporta tutti i servizi ICT (anziché uno solo), semplificando la vita agli utenti finali ed il controllo della gestione ICT.

A quali problemi risponde un Service Desk?

A livello aziendale l’aumento del numero e della complessità dei servizi presi in gestione dal reparto ICT, produce i seguenti problemi:

• Tempi di attesa più lunghi per la risoluzione dei problemi, anche gestiti da fornitori esterni;
• Mancanza di condivisione della conoscenza;
• Gradimento dei servizi ICT scarso, con conseguente cattiva informazione e gestione dei problemi ad esso legati ("non funziona niente …" è un’affermazione troppo ricorrente, ed allo stesso tempo generica, che non contribuisce in alcun modo alla risoluzione di un problema).

Cosa fa un Service Desk?

In estrema sintesi è possibile affermare che un Service Desk svolge le seguenti attività:

• Registrazione incidenti, problemi e richieste di cambiamento;
• Risoluzione incidenti e problemi;
• Gestione dei cambiamenti;

(Diamo delle definizioni)

L’approccio è volutamente sintetico e allo stesso tempo incomprensibile, se non fornendo alcune definizioni.

In particolare è opportuno specificare che:

• un incidente è un evento imprevisto che causa l’interruzione di un servizio;
• un problema dipende da ragioni infrastrutturali. Tipicamente è un problema la causa di un incidente;
• un cambiamento è una qualsiasi modifica alla situazione attuale (AS IS).

(Facciamo un esempio)

Es. Richiesta di assistenza

L’operatore lamenta il fatto che il suo PC non va più in rete. L’analisi dell’incidente da parte del Service Desk individua che in effetti la porta fisica alla quale il PC è collegato, è raccordata su una porta dello switch che risulta bruciata (non funzionante). L’incidente si risolve utilizzando una porta libera dello switch.

L’incidente è: “Si è “bruciata” una porta dello switch.”

Il problema è: “Lo switch è obsoleto ed usurato.”

Il cambiamento è (sarà?): “Lo switch è stato (sarà?) sostituito.”

Come si realizza un Service Desk? 

I passi principali da seguire per implementare un processo / servizio del genere non sono pochi. Ovviamente ogni punto di seguito riportato, apre un capitolo che è necessario approfondire per produrre un risultato concreto e tangibile. L’elenco è quindi da ritenersi esemplificativo ma non esaustivo.

• Identificare i servizi / le applicazioni da prendere in carico;
• Identificare gli utenti / le attrezzature;
• Identificare il personale interno / esterno che dovrà gestire le richieste di assistenza;
• Identificare il luogo fisico del Service Desk;
• Documentare le procedure di inoltro delle richieste di assistenza in outsourcing (per i servizi esternalizzati) – Formazione del personale
• Documentare le procedure di inoltro delle richieste di assistenza al Service Desk – Formazione degli utenti;
• Formare il personale di supporto tecnico e gli utenti del Service Desk;
• Documentare le soluzioni a tutti i problemi noti;
• Documentare le soluzioni a tutti gli incidenti ricorrenti;
• Definire delle metriche per valutare l’impatto degli incidenti (priorità);
• Definire delle metriche per monitorare il carico di lavoro;
• Predisporre uno strumento per la registrazione delle chiamate;
• Predisporre un piano di comunicazione per il lancio del Service Desk;
• … etc …

Tanti altri step sono necessari. Primo fra tutti, la creazione di un database delle configurazioni (CMDB – Configuration Management Data Base). Tuttavia è più opportuno, a mio avviso, riportare tale azione nella To Do list da mettere in atto per implementare altri processi con i quali, inevitabilmente, il Service Desk si interseca.

Auspico di riuscire a presentare in futuro, sulle pagine di questo blog, un caso reale di realizzazione. Nel frattempo … spero comunque di esservi stato utile a fare un po’ d’ordine.

Governare l’ICT è compito del Chief Information Officer.

Per non perdere la bussola (e ridursi ad avere un ufficio simile alla foto) è necessario innanzitutto stabilire i principi sui quali fondare la gestione di quella che, il più delle volte, è una azienda nell’azienda. Se siamo fortunati (o sfortunati … dipende dai casi), tali linee guida ci vengono imposte da uno standard al quale dobbiamo semplicemente adeguarci. Sto pensando a tutte quelle aziende che hanno una qualche certificazione di qualità che comprende la gestione dell’ICT nel loro manuale.

Se siamo sfortunati (o fortunati … dipende dai casi) e queste linee guida dobbiamo dettarle noi che facciamo?

Come spesso accade non dobbiamo inventarci la ruota ma solo scegliere. Esistono infatti differenti framework (insieme di processi) di best pratice (azioni pratiche da compiere) specifici per la gestione ICT.

Information Technology Infrastructure Library (ITIL) è un insieme di linee guida ispirate dalla pratica (Best Practice) nella gestione dei servizi IT (IT Service Management) e consiste in una serie di pubblicazioni che forniscono indicazioni sull’erogazione di servizi IT di qualità e sui processi e mezzi necessari a supportarli.

Sebbene sia stato sviluppato negli anni ottanta, ITIL non è stato largamente adottato fino alla metà degli anni novanta. Questa più larga adozione e conoscenza ha condotto all’emissione di standard a supporto, incluso ISO/IEC 20000 (precedentemente British Standards | BS 15000), il quale è uno standard internazionale che ricopre molti degli elementi di ITIL per la gestione dei servizi IT.

ITIL viene spesso considerato a fianco di altri framework di best practice quali Information Services Procurement Library (ISPL), Application Services Library (ASL), Dynamic Systems Development Method (DSDM), Capability Maturity Model (CMM/CMMI), e viene spesso collegato con l’IT governance attraverso Control Objectives for Information and related Technology (COBIT).

L’IT Service Management in quanto concetto è relativo ma non equivalente a ITIL. ITIL contiene una sezione specificatamente dedicata all’"IT Service Management" (la combinazione dei volumi sul Service Support e Service Delivery i quali sono uno specifico esempio di un framework ITSM), è comunque importante evidenziare che esistono altri framework.

Alternative

Oltre ITIL, esistono altri approcci all’IT Service Management, quali The BECTA Framework for ICT Technical Support (FITS) che è stato sviluppato dalla British Eductional Communications and Technology Agency ed è basato su ITIL ma è più snello per essere adottato nelle scuole secondarie e primarie britanniche (le quali hanno spesso dipartimenti IT molto piccoli). Similmente, The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps dichiara di essere basato su ITIL ma di essere specificatamente focalizzato sul più grande degli elementi di ITIL quello di "dare valore ai soldi".

fonte: http://it.wikipedia.org/wiki/ITIL

Per chi volesse approfondire il discorso, la migliore risorsa online per ITIL in italiano, a mio avviso, è presente nel mio CIOROLL di fianco.

L’approccio utilizzato dalle alternative si adatta meglio a situazioni nelle quali le risorse, umane e tecnologiche, sono limitate. Tale condizione è tipica delle nostre PMI (o almeno di quelle al Sud).

“The Visible OPS Handbook”, redatto da ITPI (Information Technology Process Initiative, organizzazione no profit impegnata in attività di ricerca e sviluppo in ambito manageriale ICT), consiglia di implementare l’IT Service Management in 4 mosse:

1. Stabilizzare il paziente. Oltre l’80% delle interruzioni derivano da problemi organizzativi. Bisogna individuare, documentare ed analizzare i rischi dovuti ai cambiamenti e i processi per la gestione dei problemi, al fine di ridurre i tempi di ripristino di un servizio.
2. Prendere e lasciare. Spesso l’infrastruttura esistente non consente un miglioramento. Per esserne certi e capire cosa salvare, dobbiamo inventariare gli asset (hardware, software e contratti), le configurazioni e i servizi e decidere tempestivamente cosa salvare e dove investire.
3. Definire e documentare processi ripetibili. Creiamo processi ripetibili di gestione dei cambiamenti e dei guasti, per il maggior numero di asset e servizi.
4. Abilitare un continuo miglioramento. In questa fase costruiamo gli indici / metriche necessarie per consentire un continuo miglioramento e capire se stiamo raggiungendo gli obiettivi definiti con la Direzione (Controllo di gestione).

FITS (The BECTA Frameworkfor ICT Technical Support) implementa un sottoinsieme dei processi ITIL.

Di seguito un elenco:

1. Service Desk
2. Incident Management
3. Release Management
4. Change Management
5. Configuration Management
6. Problem Management
7. Availability & Capacity Management
8. Service Level Management
9. Service Continuity Management
10. Financial Management

Riuscire a implementare tali processi (che cercherò di descrivere in post futuri) / seguire queste best practice, che altro non sono che “buon senso schematizzato e applicato”, è quanto di più difficile si possa fare ma, al tempo stesso, è l’obiettivo che ogni responsabile ICT deve perseguire con forza e volontà.

E’ chiaro che la scelta del framework da adottare dipende dalla tipologia di cliente che si segue. Nel mio caso utilizzo spesso FITS … e voi?