Archive for the ‘Consulenza informatica’ Category.

Service Level Management

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

sla_management

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.

Availability & Capacity Management

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.

network_monitoring

Manutenzione programmata (Preventivate Manteinance)

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

preventive_maintance 

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.

Problem Management

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.

problem_management

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.

1 anno di blog

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.

Handbook online

Che cos’è un handbook?

Handbook è la parola inglese che identifica il nostro manuale utente.

Quando ho aperto questo spazio, tra i vari miei intenti, c’era quello di fornire supporto agli utenti delle aziende presso le quali presto la mia opera. Uno dei miei obiettivi era appunto creare un canale di comunicazione interattivo con loro.

Se analizzo questo primo anno di attività, non posso non ammettere che l’obiettivo è completamente fallito. Per quale motivo? Non posso divulgare sul web informazioni attinenti alla gestione ICT dei clienti, sia per motivi di privacy, che di tutela dell’investimento (che è poi la cosa che mi sta più a cuore). Cosa fare allora?

Agosto porta consiglio … per risolvere definitivamente il problema ho implementato un’area riservata sul blog.

Sei un utente delle aziende appartenenti al Gruppo Di Mauro e/o della GI.VI. costruzioni? Allora registrati utilizzando il link di fianco.

Cosa troverai nel tuo handbook? Le risposte alle domande più frequenti che tu, e i tuoi colleghi, mi rivolgete.

Categorie:

  • Servizi
    L’elenco di tutti i servizi ICT esistenti, compresi software e attrezzature quali telefoni VoIP, stampanti di rete, POS, etc. Descriverò quali sono e dove sono.
  • Procedure
    Istruzioni per la segnalazione degli incidenti, la richiesta di attrezzature / attivazioni, etc.
  • Checklist
    Istruzioni necessarie per svolgere una autodiagnosi dei problemi che si verificano, mantenere in buono stato le apparecchiature, etc.
  • Incidenti
    Informazioni dettagliate su come vengono prese in carico le richieste di supporto, informazioni sugli incidenti risolti, etc.
  • Contatti
    Riferimenti telefonici dei vari fornitori ICT, procedure di escalation, numeri di emergenza, etc.
  • Guide
    Informazioni circa l’installazione e l’uso di alcuni software di uso aziendale, etc.
  • Sicurezza
    Regolamento informatico aziendale, policy di gestione dei dati, procedure per mantenere le misure minime di sicurezza, etc

Non riesci a registrarti? Contattami ( sai sicuramente come trovarmi ;-) )

Date una priorità ai vostri progetti

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

priorita-progetti 

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

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

configuration_management

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.

Change Management

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.

change_management

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

Granturismo

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.

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

Release management

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.

release_management

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

Get Adobe Flash playerPlugin by wpburn.com wordpress themes