ICT Procurement: istruzioni per l’uso Una serie di approfondimenti sulle procedure di approvvigionamento ICT per affrontare con successo le sfide connesse all'innovazione tecnologica

ICT Procurement: istruzioni per l'uso

Con questo articolo presentiamo una serie di approfondimenti relativi a un argomento che negli ultimi anni è stato oggetto di importanti dibattiti sia in Italia che nella maggior parte dei paesi industrializzati: l’ICT Procurement, ovvero l’insieme di procedure che determinano l’acquisto e la vendita di forniture informatiche da parte di aziende pubbliche e private.

In questa prima parte ci dedicheremo all’introduzione dell’argomento, mettendone a fuoco il contesto e le principali definizioni: negli approfondimenti successivi ci dedicheremo all’analisi delle principali linee guida pubblicate in Italia (dall’Agenzia dell’Italia Digitale) e in Europa (dalla Commissione UE) in tema di ICT Procurement, con l’obiettivo di fornire un quadro completo delle metodologie che regolano i processi relativi agli appalti elettronici e delle best practice attualmente in vigore.

Definizioni

Come sempre quando si affronta un argomento complesso è opportuno partire dalla sua definizione: nel caso specifico, poiché il tema trattato è denotato da un termine inglese, occorrerà fare un ulteriore passo indietro e partire dalla traduzione.

Il termine inglese procurement, adottato in pianta stabile all’interno della lingua italiana già da diversi anni, è traducibile in italiano come approvvigionamento: da un punto di vista prettamente semantico/lessicale, dunque, l’ICT Procurement indica l’attività di approvvigionamento di beni e servizi informatici. Tuttavia, per estensione, il termine è oggi utilizzato in riferimento a tutto l’insieme di pratiche che rendono possibile lo svolgimento di tale attività. In particolare, l’ICT Procurement comprende anche:

  • La definizione delle clausole generali e SLA che regolano i contratti da stipulare (accordo quadro)
  • La gestione dei processi di approvvigionamento (procurement management)
  • La gestione dei rischi connessi alla selezione del fornitore (risk management)
  • I processi di individuazione e classificazione delle vulnerabilità di sicurezza del prodotto o sistema acquistato (vulnerability assessment)

Esistono poi una serie di temi di carattere generale che tale attività richiede, come la conoscenza delle norme relative alla protezione dei dati; i concetti-base di sicurezza informatica volte a minimizzare l’impatto di possibili vulnerabilità (hardening); il servizio di locazione operativa, gestione e manutenzione del parco di apparecchiature hardware da predisporre in conseguenza di  un acquisto (fleet management); e così via.

Quello richiesto dall’ICT Procurement è dunque un approccio olistico, che prevede un forte livello di preparazione da parte dei responsabili del progetto sui principali temi ICT.

Risk assessment

Tra le molteplici task che le funzioni di ICT Procurement sono chiamate a svolgere e che abbiamo appena individuato, particolare enfasi merita il processo di analisi, controllo e mitigazione dei rischi (risk assessment, risk management & risk remediation), che ormai da anni costituisce il cuore pulsante su cui si orientano tutte le principali ISO che definiscono le procedure di qualità (ISO 9001:2015) e di gestione dei sistemi informatici (l’intera famiglia ISO/IEC 27000).

L’implementazione di adeguati piani di gestione del rischio è particolarmente necessaria per corredare l’attività di ICT procurement dei necessari protocolli di sicurezza, nonché per dotarla di un registro dei casi di successo/insuccesso che possa orientare le parti coinvolte verso una cultura basata sulla previsione delle incertezze e sulla prevenzione. Le caratteristiche principali da osservare in un processo di gestione dei rischi connesso all’ICT Procurement prevedono:

  • una conoscenza approfondita dell’organizzazione, del contesto in cui si muove e dei suoi obiettivi principali;
  • una corretta identificazione delle funzioni, dei processi e degli asset aziendali, corredata da un adeguato piano di gestione del cambiamento delle stesse (change management);
  • una attività di classificazione continua, nonché costantemente aggiornata, dei processi critici e dei dati trattati, con l’adozione delle necessarie contromisure volte a mitigare i possibili rischi (data classification);
  • una documentazione formale (policy), costantemente aggiornata e periodicamente somministrata agli addetti ai lavori mediante apposite sessioni di addestramento (training);
  • una procedura di verifica periodica volta a misurare l’efficacia delle policy e del training, possibilmente supportata dalla pianificazione di audit periodici interni ed esterni;

Business Impact Analysis

A loro volta, le attività di Risk Assessment non possono prescindere da una analisi di impatto (Business Impact Analysis o BIA) volta a determinare l’impatto e le ricadute sul business aziendale di eventi interni o esterni che potrebbero provocare l’interruzione della produzione o dell’erogazione di servizi.

L’analisi di impatto si iscrive in un più ampio contesto di gestione della continuità operativa (Business Continuity), di cui costituisce una delle attività più complesse e impegnative. Vista la complessità dell’argomento in questa fase ci limiteremo ad illustrare sommariamente le metodologie applicative necessarie per effettuarla nel modo corretto, rimandando la trattazione delle modalità operative e degli strumenti utilizzabili a un approfondimento ad-hoc di prossima pubblicazione.

Mappatura dei processi

Gli approcci metodologici più comuni alla Business Impact Analysis enfatizzano l’importanza della mappatura dei processi, attività da cui è quasi sempre opportuno partire. Tale mappatura deve descrivere per ogni processo la sua suddivisione in sotto-processi e relative fasi: inoltre, per ogni sotto processo deve essere individuato il relativo process owner, ovvero la persona su cui ricade la responsabilità di gestione e tenuta del processo stesso. Per ciascun elemento di analisi occorre identificare gli impatti economici, normativi e reputazionali connessi a una sua eventuale interruzione; la portata di tali impatti andrà analizzata sia in modo “atomico”, ovvero relativamente agli effetti prodotti dall’interruzione del singolo sotto-processo, che in modo “organico”, ovvero estendendo la valutazione agli effetti prodotti “a cascata” sugli altri sotto-processi e processi che risultino ad esso più o meno collegati.

A seguito di questa prima analisi sarà possibile identificare gli elementi maggiormente rilevanti, ovvero quelli su cui si concentrano gli impatti (e di conseguenza i rischi) principali: saranno proprio questi elementi ad essere oggetto di un secondo e più approfondito livello di analisi, che si porrà l’obiettivo di determinare le modalità di ripristino degli stessi in caso di disastro a seconda dei possibili scenari di crisi. Le varie modalità di ripristino individuate dovranno quindi essere oggetto di una valutazione il più possibile accurata dei tempi di ripristino e riallineamento dei processi alla condizione di normalità, utilizzando due parametri:

  • Recovery Time Objective (RTO), ovvero il tempo che occorre per il totale recupero dell’operatività del sistema.
  • Recovery Point Objective (RPO), ovvero il tempo massimo che intercorre tra la produzione di un dato e la sua messa in sicurezza, ad esempio mediante l’adozione di procedure di backup.
Sia il RTO che il RPO sono comunemente espressi in unità temporali definite (tipicamente giorni, ore o minuti, a seconda delle procedure di backup e disaster recovery definite). Ad esempio, un RTO di 24 ore in caso di incendio sta a significare che l’azienda è in grado di riprendere la normale attività operativa dopo 24 ore; similmente, un RPO di 12 ore significa che, in caso di crash dei sistemi o di catastrofe naturale, l’azienda rischia di perdere un massimo di 12 ore di dati (presumibilmente per via del fatto che il sistema prevede 2 backup al giorno).

Un compito fondamentale da svolgere in questa seconda analisi è la valutazione della continuità operativa garantita dagli outsourcer, ovvero dai fornitori informatici i cui processi siano correlati a quelli critici dell’azienda: in questi casi potrebbe essere difficile stabilire RTO e RPO sufficientemente precisi a meno che il fornitore non accetti di sottostare a degli specifici Service Level Agreement (SLA) che garantiscano il rispetto di valori RTO e RPO prestabiliti anche da parte sua.

Valutazione del fornitore

Questo tema è molto importante perché consente di introdurre un altro aspetto estremamente importante in ambito ICT Procurement: la valutazione del fornitore, che va condotta analizzando le misure di sicurezza da lui applicate nell’erogazione delle sue prestazioni e la conformità alle normative vigenti. Questi controlli possono essere effettuati:

  • prima dell’acquisizione, ovvero in via preventiva, stabilendo i requisiti minimi nei capitolati di gara e, successivamente, negli accordi-quadro ovvero nei contratti di fornitura così da limitare il rischio di incorrere in un fornitore inadeguato;
  • durante l’acquisizione, ovvero nel corso della fase di procurement, verificando la piena rispondenza del fornitore ai requisiti minimi richiesti mediante apposite attività di verifica di quanto dichiarato (assessment, due diligence);
  • dopo l’acquisizione, ovvero successivamente all’erogazione o all’avvio della fornitura, mediante la pianificazione di controlli periodici (audit) ovvero l’utilizzo di strumenti di rilevazione indiretti (feedback).

Inutile dire che, se consideriamo il contesto dell’approvvigionamento ICT, la maggior parte dei controlli tende inevitabilmente a concentrarsi nelle prime due categorie, e in particolare nella prima; in base a questo assunto, i principali strumenti a disposizione per stabilire dei controlli preventivi adeguati sono i documenti di gara (bando, capitolato, etc.), il contratto di fornitura e, nei casi in cui è previsto, l’accordo quadro: ciascuno di questi strumenti sarà trattato in un approfondimento dedicato.

Conclusioni

In un mondo sempre più informatizzato e complesso come quello attuale, dove le esigenze di digitalizzazione e sicurezza informatica crescono in modo esponenziale di anno in anno, dotarsi di adeguate procedure di ICT procurement è una necessità comune a tutte le aziende, siano esse private o parte della Pubblica Amministrazione, sia pure con importanti differenze a seconda del caso di specie:

  • nel caso del privato si tratta di una necessità intrinsecamente connessa ai crescenti requisiti imposti dal mercato, che sempre più spesso punta a richiedere standard di tipo enterprise (si veda a tale proposito l’approfondimento dedicato all’interoperabilità dei sistemi informativi, con particolare riguardo al paragrafo che analizza le problematiche economiche connesse ai costi di adeguamento necessari da parte di realtà modeste come le PMI italiane);
  • nel caso della PA, dove questo tipo di “impulso migliorativo” è indubbiamente meno sentito, si tratta di adottare un’impostazione volta a fornire servizi pubblici digitali sempre più efficienti, nell’ottica del loro ruolo costituzionale di creare “valore pubblico”; è con questo obiettivo che, negli ultimi anni, sono stati prodotti due importanti documenti che contengono linee-guida per l’ICT procurement della Pubblica Amministrazione:

A prescindere dalle differenze di indirizzo, sia il settore pubblico che quello privato hanno oggi la necessità di confrontarsi con le difficoltà connesse alle molteplici trasformazioni economiche e sociali portate dall’innovazione tecnologica; una vera e propria sfida che può essere vinta soltanto dimostrando una grande capacità di adattamento alla trasversalità ed alla complessità di questo mutato contesto tecnologico-culturale, ovvero adeguando i processi interni – con particolare riguardo a quelli decisionali e operativi – al fine di garantire la continuità, la sicurezza e la corretta gestione dei rischi a tutti gli attori coinvolti.

 

About Ryan

IT Project Manager, Web Interface Architect e Lead Developer di numerosi siti e servizi web ad alto traffico in Italia e in Europa. Dal 2010 si occupa anche della progettazione di App e giochi per dispositivi Android, iOS e Mobile Phone per conto di numerose società italiane. Microsoft MVP for Development Technologies dal 2018.

View all posts by Ryan

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.