Il blog di un CIO in outsourcing

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.

Riprendiamo la carrellata sui processi FITS. 

Il change management è il processo per la gestione dell’attuazione delle modifiche all’infrastruttura ICT, è può quindi riguardare hardware, software o servizi, e la relativa documentazione.

Il suo scopo è quello di minimizzare il danno ai servizi di ICT causati dai cambiamenti, e di assicurare che le informazioni relative all’hardware, al software, ai servizi e alla documentazione siano tenute aggiornate.

Cosa genera un cambiamento?

Può essere il risultato di un guasto tecnico o di un problema infrastrutturale. In alternativa se si tratta di implementare un nuovo software o installare un nuovo hardware per rispondere ad una nuova esigenza funzionale, è necessario gestire l’attività con il processo di release management, discusso in un precedente post.

Alcuni esempi di cambiamento

• Upgrade hardware / software PC;
• Assegnare una licenza software ad un altro operatore;
• Installare nuova memoria RAM in un server;
• Aggiornare / revisionare la documentazione di una procedura;
• etc.

Cosa fare in sintesi?

• Assegnare ruoli e responsabilità;
• Preparare tutti i materiali necessari per il processo (regolamenti, moduli di richiesta cambiamento, etc.);
• 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;
• Effettuare, se possibile, un cambio pilota prima come prova

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

E’ dura la vita del CIO vero? Allora “aiutati che FITS ti aiuta” …

Nelle puntate precedenti ho elencato brevemente i processi di “Service Desk” e “Incident Management”.

Altrettanto brevemente, per consentire una lettura agevole di questi post introduttivi, è necessario fornire una definizione del processo di Release management.

Release Management è il processo di progettazione, costruzione, test e deployment di un nuovo hardware e/o software. Implementa il controllo di versione e aggiorna l’inventario hardware/software. L’obiettivo che si pone, è quello di fornire un metodo, coerente e ripetibile, per la distribuzione di un aggiornamento / novità all’interno della preesistente infrastruttura ICT.

Grossa enfasi viene data alle fasi di pianificazione e di preparazione dei nuovi servizi.

Le aziende che utilizzano tale processo, difficilmente impattano in ritardi di progetto, in quanto l’approccio strutturato consente di definire in anticipo le risorse necessarie per la realizzazione dell’obiettivo, e nel contempo riduce al minimo gli incidenti che interessano gli utenti ogniqualvolta viene introdotta una novità.

Di seguito una figura riepilogativa delle fasi del processo.

Definita la politica di rilascio (fondamentalmente bisogna rispondere alle domande “quando e come?”), pianficato / sviluppato / debbugato il servizio / applicazione, la fase di rollout consiste nella distribuzione / installazione dell’aggiornamento, e nel test in work dello stesso, che riguarda sia aspetti tecnici, che funzionali (rispetto dei requisiti “funzionali” forniti dal committente).

Il processo si interfaccia con quello di “Change Management” (attuazione del piano) e con quello di “Configuration Management” (aggiornamento della “situazione” parco macchine e/o del catalogo dei servizi).

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?

Nelle famose riunioni di cui parlavo al seguente post, i nuovi progetti software si promuovono quasi da soli, in quanto derivano da esigenze manifestate dalla Direzione e/o dall’esperto direzionale. I progetti infrastrutturali, viceversa, sono quelli per i quali diventa difficile, se i rapporti non sono ottimali e/o se qualcosa è andato storto l’anno prima, stabilire l’importanza e l’urgenza.

Come agiamo allora?

Partiamo dall’analisi delle cause. Un progetto infrastrutturale è difficile da vendere internamente perché il management non vede l’infrastruttura, ma meravigliosi report (torte, pile, istogrammi, etc) che gli occorrono per concentrarsi sul proprio business, dimenticando, o non sapendo, tutto il lavoro che c’è dietro. E poi perché l’infrastruttura ICT, nonostante la progressiva riduzione dei costi dell’hardware e l’adozione di sistemi operativi con licenze open, soprattutto lato server, ha comunque un costo elevato in termini di ore/uomo necessarie per l’implementazione di architetture solide.

Pertanto non si tratta di essere più o meno entropici, perché per quanto possiate sforzarvi avrete di fronte persone che percepiscono solo i costi e non i benefici di ciò che state proponendo, e la maggior parte di esse non potrà mai capire veramente le infrastrutture (voi avete studiato tanto per farlo).

Se voi foste imprenditori, investireste in qualcosa che non capite e/o controllate? Credo di no … quindi spostiamo il focus della discussione … parliamo di soldi!!!

Presentiamo un caso aziendale comprensibile al Titolare e/o al Direttore esecutivo, evidenziando quali sono i benefici apportati al business in termine di riduzione dei costi e ottimizzazione delle prestazioni (e quindi di aumento della produttività).

Cerchiamo, ad esempio, di dimostrare che attuando il piano descritto nel progetto infrastrutturale che intendiamo far approvare, riusciremo a:

• Assicurare la business continuity e/o tempi di down dei servizi accettabili;
• Ottenere un risparmio sui costi;
• Migliorare la produttività;
• Mitigare e/o evitare rischi;
• Essere conformi a standard qualitativi;
• Etc.

In sintesi spieghiamo PERCHE’ bisogna procedere con l’investimento, e non COME.

Un buon punto di partenza può essere fornito dall’elencare i costi da sostenere in caso di un incidente implicante il dowtime di un servizio importante.

Solitamente vi sono:

• Costi fissi per la manutenzione e supporto nella gestione dell’attività;
• Costi NON fissi per la risoluzione del guasto (software / sistemistici);
• Costi NON fissi per la sostituzione di parti guaste (hardware);
• Costi indiretti legati alla riduzione della produttività;
• Costi incalcolabili, legati al morale del personale che utilizza i servizi per lavorare e/o PEGGIO, a quello dei clienti finali dell’azienda;
• Etc.

Ora dimostrate che il Vs progetto porta dei benefici che vanno in direzione opposta a questi costi e giustificano l’investimento. Se ci riuscite, allora avrete qualche possibilità di venderlo … in bocca al lupo!