Archive for agosto 2009

Outsourcing 2.0: modelli di organizzazione e comunicazione

agosto 23, 2009

La letteratura.

Le relazioni che intercorrono tra fornitore e cliente nel corso di un servizio di outsourcing sono generalmente rappresentate con un modello organizzativo, noto anche con il nome di Demand-Supply Model, distribuito su 3 livelli:

  • Un livello strategico, nel quale le relazioni sono condotte da rappresentanti del management di entrambi i partner, orientate a delineare le strategie di medio lungo termine, in modo da massimizzare la cooperazione tra le aziende per il raggiungimento degli obiettivi, appunto, strategici;
  • Un livello tattico, focalizzato sul controllo dell’erogazione dei servizi che appartengono al perimetro o ambito di uno o più contratti di servizio, composto da referenti di entrambe le aziende;
  • Un livello operativo, nel quale sono protagoniste le componenti tecniche necessarie per l’erogazione quotidiana dei servizi.

Fig. 1 – Modello Organizzativo Demand/Supply

Come si può osservare nella precedente figura, nella quale i servizi oggetto del contratto di outsourcing sono evidentemente riferiti ad un application management SAP, i canali di comunicazione tra le parti, per ognuno dei tre livelli, sono formali e predeterminati:

  1. I Contratti, al livello strategico, determinano le "regole di ingaggio" tra le parti, i ruoli e le responsabilità, ciò che è compreso e che appartiene alla baseline dei servizi e ciò che non lo è, gli aspetti economici e di rendicontazione dei servizi.
  2. I Livelli di Servizio, o SLA, che rappresentano il principale canale di comunicazione a livello tattico, descrivono in modo oggettivo i criteri di misurazione dei servizi erogati.
  3. Le Procedure impiegate al livello operativo sono infine lo strumento primario di controllo e di gestione dei servizi erogati per le attività giornaliere, si pensi per esempio ad una procedura per effettuare il back-up di una base dati o la procedura per abilitare un nuovo utente ad alcune funzionalità applicative.

E’ del tutto ovvio che modelli, processi e procedure dettano le linee guida; le relazioni che si instaurano tra i gruppi di lavoro di entrambe le parti, a maggior ragione nel corso di servizi che hanno una durata contrattuale di più anni, sono spesso informali e basate sulla fiducia guadagnata dalle persone "sul campo" che comunicano tra loro direttamente, al telefono o via email.

Mettiamo un po’ di Web 2.0 nei modelli organizzativi.

Accade così che nell’epoca di twitter, dei "mood" di facebook, dell’integrazione dei sistemi di social networking con i dispositivi mobili, della facilità d’uso degli aggregatori di informazioni, dei "nativi digitali" che entrano nelle aziende, si renda necessario arricchire gli schemi monolitici dei modelli organizzativi, come quello precedentemente rappresentato, con nuovi strumenti, fruibili in mobilità ed adattati al contesto.

Non si tratta soltanto di individuare ed adottare gli strumenti giusti, ma anche di maturare la consapevolezza in azienda che, grazie all’analisi dei fenomeni "sociali", può essere opportuno avviare politiche mirate ad incentivare i comportamenti che migliorano o semplificano alcuni processi. Facciamo qualche esempio:

Nella precedente figura nel livello operativo abbiamo due gruppi di lavoro, uno lato supply, cioè dalla parte del fornitore di servizi, l’altro dalla parte demand, cioè dalla parte di chi usufruisce dei servizi. I gruppi di lavoro sono identificati rispettivamente come area leader per il lato supply e key user per il lato demand. Se applichiamo alle persone che compongono ognuno dei gruppi un metodo di analisi delle relazioni utilizzato per misurare la densità e la qualità dei contatti in una rete sociale, possiamo scoprire per esempio che alcune persone lato supply godono di grande fiducia da parte di colleghi e clienti, frequentemente contattate per le loro competenze: stiamo parlando dei broker, i "nodi" centrali delle reti di comunicazione sociale. Naturalmente anche lato demand possono essere messi in evidenza i key user con le capacità di aggregare o fornire soluzioni più di altri.

Fig. 2 – Evidenza dei broker nel modello Demand/Supply

Nella precedente figura 2, in un ipotetico scenario, sono messe in evidenza le relazioni degli attori che partecipano a vario titolo all’erogazione dei servizi, con enfasi su due tipologie di broker o nodi centrali:

  1. il broker istituzionale, che assumere la posizione di nodo centrale per ruolo o autorità;
  2. il broker "de facto", che assume la posizione di nodo centrale per autorevolezza, per competenza.

E’ esattamente quest’ultima figura che è opportuno valorizzare, fornendogli strumenti e linee guida per trovare il giusto equilibrio tra esigenze di riservatezza aziendale e trasparenza ed efficacia nel trovare soluzioni a favore dei colleghi e/o dei clienti.

Gli strumenti abilitanti.

Oltre ai modelli di analisi ONA – Organisation Network Analisys, che come abbiamo appena visto possono essere utilizzati per avere un punto di vista diverso rispetto ad una tradizionale valutazione del delivery di un servizio, si possono sperimentare diverse soluzioni a costi limitati ed a basso rischio. Alcuni strumenti sono semplici da identificare e da implementare, altri richiedono un percorso culturale che obiettivamente è ancora prematuro proporre.

Twitter può essere facilmente utilizzato per dichiarare lo stato di un servizio al variare di una qualche condizione, anche da agenti digitali, oppure per dichiarare un ritardo a causa di un contrattempo verso tutti i follower che devono essere informati.

Una conversazione su una piattaforma di instant messaging o registrata in voip ha la stessa validità di un verbale scritto su word, senza interpretazioni di parte.

Un processo di autorizzazione veicolato su un canale mobile, per esempio su blackberry, consente all’autorizzatore di avere la sintesi delle informazioni necessarie per il suo benestare, ovunque egli si trovi ed in tempo reale.

Una piattaforma di collaborazione estesa, comprensiva di una rete di social networking, attivata tra cliente e fornitore, consente di creare nel tempo una knowledge base personalizzata utile ad entrambe le parti lungo la durata del contratto di servizio.

Conclusioni.

I modelli, le linee guida, gli standard, sono tali quando le condizioni a contorno sono statiche; nel momento in cui il contesto tecnologico è in costante evoluzione anche i modelli devono essere adattati alle nuove condizioni, perchè possano essere realmente efficaci. Gli strumenti che utilizziamo quotidianamente impongono nuove regole, rivedendo le regole si possono creare nuove opportunità.

Stay Tuned!

,,,

Annunci

La transizione dei servizi applicativi

agosto 8, 2009
Ho avuto modo di spiegare tante volte in che cosa consiste un progetto di transizione, producendo negli anni un numero considerevole di slide ed è giunto il momento di condividere questo argomento con un post sul mio blog.
L’ambito di riferimento è ovviamente quello di un outsourcing, più precisamente di selective  outsourcing applicativo, cioè l’ipotesi di delegare le attività di gestione, di manutenzione e di evoluzione di un sistema software ad una entità specializzata. Per il cliente non è mai una passeggiata: si tratta spesso di scelte inevitabili dettate dalle condizioni di mercato che portano al tentativo di ridurre il costo dell’IT, considerata una commodity, meno frequentemente da soluzioni indirizzate da una chiara strategia.
La transizione, nel contesto dei servizi ICT di application management, è un progetto di change management con una precisa durata temporale, che ha lo scopo di portare un servizio da uno stato iniziale , generalmente chiamato Present Mode of Operations o PMO, ad uno stato finale denominato Future Mode of Operations o FMO, seguendo rigorose procedure per minimizzare i rischi e soprattutto per rendere il più possibile indolore il cambiamento agli utilizzatori finali del sistema.
Nel ciclo di vita del sistema applicativo lo “stato iniziale” di un servizio di application management può coincidere con:
  • il rilascio di un sistema applicativo, generalmente noto come go-live, a valle di un progetto di implementazione;
  • il cambio di strategia di sourcing del cliente, quando ad un fornitore di servizi ne subentra uno nuovo, interno o esterno, rispetto al business del cliente;
  • l’introduzione nel servizio a regime di nuovi elementi non pianificabili, che possono essere dettati da normative alle quali il sistema deve conformarsi, nuove opportunità di business, una variazione organizzativa sostanziale.

Naturalmente ci possono essere altre cause che giustificano il cambiamento, ma per semplificare ho citato i casi più comuni.
ITIL Versione 3 (link) dedica alla Service Transition uno dei suoi 5 libri; non ho l’ambizione di fare altrettanto qui, ma di fornire qualche “pillola” sull’approccio.

Si parte con l’assessment: una fase interessante poichè ci serve a capire in quale ambito ci stiamo muovendo, quali sono gli attori coinvolti nel servizio, quale è il ruolo dell’IT rispetto al business dell’azienda. E’ in questa fase che si prepara il piano di comunicazione, elemento indispensabile per avere il giusto “committment” ed un ragionevole supporto da parte dei rappresentanti della comunità utenti. L’assessment è anche il momento giusto per produrre il piano di dettaglio delle successive fasi della transizione.

La fase di preparation vede protagoniste da un lato le infrastrutture di supporto al servizio che devono essere predisposte se non presenti, dall’altro la predisposizione fine del progetto con il gantt complessivo, le procedure operative, le matrici di responsabilità e la definzione delle metriche di controllo del servizio a regime. Questa fase è  parecchio complessa, perciò è opportuno avvalersi del supporto metodologico  offerto dalle linee guida di ITIL e dal CobIT. Le check list, i cicli di intervista ed un buon tool per pianificare e controllare le attività sono gli attrezzi di lavoro ideali per condurre questa fase.

Discovery è la fase dove si scoprono, letteralmente, le funzionalità del sistema applicativo, si intervistano i responsabili di processo, gli utenti, si ascoltano punti di vista differenti, si studia la documentazione.
Non è solo knowledge transfer; si analizzano anche i punti deboli del servizio preesistente (se esiste), si adattano le procedure operative agli inevitabili vincoli che ogni organizzazione porta con sè, dai cicli di autorizzazione, alla disponibilità delle infrstrutture e delle risorse.

Finalmente si è pronti ad erogare il servizio con la fase di shadowing. Questa fase ha la particolarità di essere divisa in due parti, denominate direct e reverse. In sostanza, si tratta di erogare il servizio secondo il nuovo modello (FMO) ma lo si fa fare agli attori del “vecchio” modello e si osserva (direct shadowing), per poi scambiarsi di posto (reverse shadowing) ripetendo la lezione e verificando se c’è ancora qualcosa da imparare o da mettere a punto. Tutto ciò avviene senza il rispetto formale dei livelli di servizio (grace period). Tutta l’infrastruttura di supporto al servizio è già operativa, per cui gli utilizzatori del sistema applicativo contatteranno un Service Desk, che aprirà loro un ticket sul tool di troubleticketing adottato, registrerà la segnalazione degli utenti, contribuirà a popolare la knowledge base ed a seconda della tipologia della richiesta di intervento, fornità una soluzione, oppure un aiuto funzionale, oppure scalerà la richiesta alla struttura predisposta a risolvere la segnalazione.
Un elemento troppo spesso trascurato è l’importanza di una corretta gestione della configurazione; il configuration management database (CMDB), o la definitive service library, (DSL) collezionano, storicizzano le domande e le risposte date, le modifiche apportate al sistema applicativo, le versioni dei rilasci e delle librerie di supporto. Narrano la storia della applicazione, attraverso la quale si può “leggere” l’evoluzione applicativa e di processo dell’azienda e suggerire modifiche organizzative, di processo o operative.

Nella fase finale, quella che chiude ufficialmente la transizione detta tuning, il ruolo della gestione della configurazione è centrale, poichè serve a mettere a punto le regole del servizio a regime, soggetto al rispetto formale dei livelli di servizio, aiuta a confrontare i volumi delle chiamate attese con i volumi a consuntivo, a valutare se la finestra temporale nella quale il servizio è erogato è sufficiente a coprire le esigenze degli utenti ed infine a verificare se il costo del servizio è proporzionato al beneficio reso.

La transizione, per concludere, è una parte essenziale del ciclo di vita di un sistema applicativo: è ricorsiva, nel senso che si può riproporre lungo la durata di un servizio ad ogni fatto che comporti un significativo cambiamento; è reversibile, in quanto le procedure seguite per mettere in opera un servizio possono essere riutilizzate per dismetterlo.

Stay Tuned.
Giovanni