MANAGING OUTSOURCING RISKS

Il continuo ricorso all’outsourcing, a fronte di logiche di contenimento costi e di focalizzazione sul core business aziendale, ha dato a tale fenomeno delle dimensioni molto grandi per gestire le quali occorre condividere un modello comune che consenta alle aziende di centrare l’obiettivo senza “sorprese” dopo la firma del contratto. Una standardizzazione in termini di approccio procedurale è quella della International Association of Outsourcing Professional (IAOP) che ha predisposto un Body of Knowledge per tutti i professional che lavorano nell’outsourcing (OP-BOK).

Un implementazione di successo dell’outsourcing in azienda richiede un’analisi secondo una metodologia a fasi, ciascuna delle quali richiede un approccio metodologico standardizzato mediante opportuni template e documenti a supporto.

All’interno del suddetto framework ogni azienda, in particolare se multinazionale, può calare le proprie policy e procedure anche, a volte ridefinendo quanto stabilito da IAOP per una singola fase.

In particolare assumiamo per il proprio progetto di outsourcing la seguente lista di fasi secondo quanto prescritto del OP-BOK:

1. Comunicazione interna delle varie opzioni possibili (shared services, offshoring etc etc)
2. Preparazione del Business Plan e Feasibility Assessment
3. Creazione dell’outsourcing Decision Matrix e valutazione dell’integrazione nella business strategy aziendale
4. Creazione dell’outsourcing project team
5. Preparazione e pubblicazione dei requisiti (Baseline dei costi, RFP, RFQ etc etc)
6. Selezione dei fornitori e attribuzione dei punteggi
7. Analisi dei benefici e del financial case da parte del top management
8. Negoziazione e contrattualizzazione
9. Gestione della transizione
10. Governance dell’outsourcing

Nel trattare problematiche di sicurezza contestualizzate nell’area ICT, ci concentreremo su aspetti decisionali e di risk management (fase 3). Quest’ultimi non solo forniscono un input fondamentale prima della creazione del team di progetto.ma aiutano per individuare eventuali costi nascosti.

FASE DECISIONALE

In tale fase viene valutata l’opportunità di adottare un modello basato sull’outsourcing per il ramo di azienda o servizio da esternalizzare.

Questa fase necessita di un valutazione dei criteri alla base dell’outsourcing in temini di importanza del servizio da esternalizzare (commodity o differenziator) e dell’efficacia in termini di impatto sul mercato

Tale differenziazione porta alla definizione dei quadranti in figura.

Immagine Fonte IAOP- OP-BOK

Questa fase si conclude quindi con la decisione di passare o meno alla creazione del team di progetto e quindi di far partire o no il progetto di Outsourcing. Si noti come un criterio generale è quello di valutare il valore aggiunto del servizio e muoversi senza dubbi solo nel caso di servizio di commodity.

Per quanto riguarda la fornitura di prodotti s’intende per commodity la fornitura di un bene per cui c’è domanda ma che è offerto senza differenze qualitative sul mercato ed è fungibile, cioè il prodotto è lo stesso indipendentemente da chi lo produce. Un tipico esempio è la fornitura dei Personal Computers oppure delle stampanti di rete.

Per quanto riguarda la fornitura dei servizi per commodity s’intende un servizio standardizzato basato su procedure ben documentate. In alcuni contesti molto ben strutturati si ritiene che l’operation della infrastruttura IT possa considerarsi una commodity mentre la progettazione architetturale di un nuovo sistema possa considerarsi un servizio a valore aggiunto.

Un’altra modalità per stabilire se un servizio possa essere considerato una commodity è quello di prefigurarsi il rapporto fra cliente e futuro fornitore dei servizi di outsourcing. Tale rapporto si può collocare in un continuum fra due estremi:

• Rapporto transazionale, se governato dai tipici meccanismi negoziali e contrattuali che regolano le transazioni di mercato.
• Rapporto Evoluto, quando sono previste logiche di collaborazione e condivisione obiettivi.

In altri termini, nel momento in cui è richiesto uno scambio di know how con un’integrazione tecnica/operativa, occorre verificare se si riesce a ricondurre a vincoli contrattuali ben definiti l’attività, altrimenti un rapporto di partnership con la condivisione degli obiettivi è sicuramente preferibile rispetto all’outsourcing.

RISK MANAGEMENT

Il risk management è un’attività di importanza cruciale anche in considerazione del fatto che consente al management di intraprendere una serie di azioni preventive volte ad evitare i problemi durante la vita del contratto. Non è un’attività molto seguita nelle aziende ed è spesso vista come uno step procedurale con scarso valore aggiunto. Pregiudizio assolutamente da sfatare.

Immagine Fonte IAOP- OP-BOK

 

Risk Identification

La prima fase del risk management è quello della Risk Identification in cui viene prodotta una lista dei rischi

Per identificare i rischi occorre partire dalle applicazioni e dai dati da essa gestiti (Application Security Assessment and Compliance)

Più in particolare l’applicazione viene analizzata a livello di “Impact Assessement” e quindi di “Compliance Details”. A valle di queste due fasi l’applicazione viene caratterizzata, attribuendo un punteggio a:

• Business Criticality
• Confidentiality
• Integrity
• Availability
• Assurance Level

Vengono quindi evidenziati i “flags”che legano l’applicazione ad alcuni standard (ad esempio SOX, PCIDSS, Codice Privacy) e lo stato di compliance con le policy interne.

Esaurita la fase di analisi dei dati si effettua un prima prima analisi basata sui ruoli da esternalizzare (sviluppatori, sistemisti, BPO etc etc) e delle applicazioni coinvolte (Outsource Impact Assessment). Molte multinazionali come BT mettono a disposizione sulla intranet aziendale dei tool di self assessment per i propri manager che intendono valutare l’opportunità di un outsourcing. Questi tool automatici forniscono già delle prime indicazioni. Ad esempio la natura dei dati e/o dei ruoli da esternalizzare potrebbe indicare la necessità di utilizzare fornitori di primo livello (tier1) con i quali sono in essere accordi di partnership. Per aziende meno strutturate questa è la fase in cui occorre valutare se il ruolo da esternalizzare è in grado di accedere a dati personali/sensibili/governativi per le applicazioni in ambito.

 

A questo punto individuati i rischi di mancata compliance interna e/o esterna e legati alla scelta del fornitore si completa la risk identification mediante interviste o brainstorming. Di seguito una possibile suddivisione in classi:

• Rischi Strategici (ad esempio legati alla perdita di know how)
• Rischi Operativi (ad esempio legati a performance scadenti dovuti a processi non integrati)
• Rischi di Risultato (ad esempio legati alla mancata condivisione dei risultati)
• Rischi Transazionali (ad esempio legati a problematiche contrattuali intellectual property, liability ecc)

 

Risk Quantification

La totalità dei rischi individuati nelle fasi precedenti vanno classificati definendone l’impatto sul business del rischio (ad esempio un rischio di fermo di un sistema IT che supporta direttamente la produzione di revenue) e la probabilità che accadano.

Tale operazione di quantificazione è tutt’altro che banale perché presuppone la conoscenza completa dello scenario AS IS e una previsione accurata dello scenario TO-BE estraniandosi dai vincoli contrattuali che in questa fase non sono ancora definiti. In altri termini non si deve assumere che il rischio verrà sicuramente gestito a livello contrattuale perché quest’ultima potrebbe essere l’azione per mitigare il rischio.

 

 

Immagine Fonte IAOP- OP-BOK

 

A valle della risk quantification si è in grado di focalizzarsi in prima istanza sui rischi ad alto impatto e con alta probabilità di accadimento collocati nel quadrante in alto a sinistra passando via via ad analizzare le altre tipologie di rischio. Quanto sopra consente o un primo screening a fronte di liste molto corpose oppure una lista di priorità nell’individuare le azioni di mitigations.

 

 

 

Risk Mitigation

Alla fine delle prime due fasi sono noti tutti i costraints che dovranno essere contrattualizzati e, soprattutto se si sta esternalizzando qualcosa che non è pienamente compliant con le policy interne. Tale gap va indirizzato con l’implementazione di “security mitigations”di tipo tecnico o procedurale.

Le pincipali forme di mitigation sono:

• Avoidance – alternate path
• Control- work around
• Assumption – do nothing
• Transfer – sharing of risks

Alcune mitigations potrebbero modificare la lista dei rischi individuati e quindi richiedere una nuova fase di quantificazione.

C’e da dire, per concludere, che un buon sistema di governance del contratto con clausole contrattuali e con una descrizione dei servizi che ben indirizzano i rischi individuati copre la grande maggioranza delle azioni di mitigation.

Per fare qualche esempio, si pensi a tutti gli accorgimenti necessari per garantire nel tempo la PCIDSS (penetration tests, log monitoring etc etc) che richiede sia la descrizione del servizio da effettuare sia la verifica periodica del committente.

Oppure si pensi al rischio di non gestire in modo adeguato i dati personali (dati dei clienti) presenti sui sistemi. Il fornitore deve essere nominato “Responsabile del Trattamento” ai sensi e per gli effetti degli artt. 4.g e 29 del D.Lgs. 196/03 dovendosi pertanto conformare all’integrale rispetto a tutte le norme e gli accordi vigenti. All’interno del processo di governance deve comunque essere previsto un sistema di controllo (ad esempio per la richiesta periodica degli amministratori di sistema). Ammesso che il sistema da esternalizzare non presenti un gap di compliance (ad esempio assenza di log) che deve essere indirizzato con una mitigations volta a colmare tale lacuna con un incremento dei costi di progetto.

Tutte le azioni volte a mitigare o annullare il rischio dovranno essere racchiuse in un Risk Management Plan che rappresenta il principale output del processo descritto. Il piano riporterà la chiara indicazione delle ownership aziendali sia in ambito IT che non (Procurement, HR, Finance) utili per la definizione del team di progetto.