Sicuramente qualcuno di voi avrà già letto l’interessante post Drop the Pilot in cui Andrew McAfee, padre fondatore dell’Enterprise 2.0, muove pesanti critiche all’approccio di lancio dei progetti finora promosso da buona parte degli esperti in questo dominio. A dire la verità, la posizione adottata da Andrew non è particolarmente originale dato che prima di lui Michael Idinopulos di Socialtext aveva sostenuto lo stesso punto di vista, suscitando parecchio rumore all’interno della community.

In ambito Enterprise 2.0, per me un pilot è

una modalità di costruzione e diffusione di un percorso di adozione di nuove pratiche collaborative che risponde ad una logica iterativa, incrementale, partecipata e di contenimento delle resistenze organizzative

In altri termini, si tratta di una strategia pensata per garantire sonni tranquilli al management e soprattutto per ingaggiare gli utenti facendo ruotare intorno a loro la co-progettazione di contenuti e servizi presenti all’interno della community.

Quali sono le critiche principali mosse da Andrew?

• Il numero di persone coinvolte: i pilot sono generalmente limitati ad un numero ridotto di persone (di norma una piccola percentuale del numero totale di dipendenti)
• La scarsa diversità dei partecipanti: lanciare pilot dipartimentali o su gruppi che operano in un contesto fisico e operativo ben delimitato significa andare a pescare individui fortemente connessi, il cui delta personale di conoscenza rispetto al gruppo è  marginale

Ancora più dei criteri di selezione dei pilot, alla base dell’osservazione di McAfee c’è la convinzione che l‘Enterprise 2.0 sia innanzitutto e soprattutto una questione di serendipity:

The more I learn about and think about the value of emergent social software platforms, the more I suspect that the deep meta-benefit they provide is technology-enabled serendipity, defined as ‘good luck in making unexpected and fortunate discoveries.’ Serendipity is possible when we’re collaborating with our close colleagues on a well-defined project, but that’s probably when it occurs least often. It’s much more likely during wide forays and broad searches, the kind that are so easy to do with current technologies.

Se fosse tutto qui, Andrew avrebbe assolutamente ragione ed i pilot non sarebbero in nessun caso rappresentativi della massa critica necessaria a scatenare e rendere evidenti all’organizzazione le dinamiche esponenziali di interazione tipiche delle comunità online. Ma, a mio avviso, l’Enterprise 2.0 non è solo ed esclusivamente serendipity.

Riprendendo il mio Enterprise 2.0 Framework, elaborato proprio a partire dal Bull’s Eye di McAfee, si evince chiaramente come aldilà della forza dei legami tra i partecipanti, ciò che fa la differenza è anche l’obiettivo aziendale per cui il progetto viene lanciato:

Se intercettare l’intelligenza collettiva e capitalizzare expertise non codificate in modo emergente è certamente uno dei contributi originali più importanti dell’Enterprise 2.0, il permettere a persone lontane di trovarsi, rimanere in contatto, collaborare asincronamente, lasciando traccia degli output anche parziali e massimizzando la riutilizzabilità di questi asset nel tempo, non dovrebbe essere per nulla ignorato. Questi tra l’altro sono gli scenari più frequentementi applicabili nella piccola e media Enterprise che costituisce buona parte del mercato italiano ed europeo.

Scartare i pilot come inutili mirando dal giorno 1 all’adozione su larga scala introduce allora grosse barriere:

• Si rischia di perdere di vista i benefici dell’Enterprise 2.0 esistenti a livello di team, di gruppo e di dipartimento (almeno il 50% del diagramma di sopra)
• Si introducono dannose paure e resistenze da parte del management in termini di budget, rischio, esposizione negativa. Per cui invece di raggiungere l’intera azienda, si potrebbe finire per non provare per nulla.
• Si sollevano problemi politici ed organizzativi ancora prima di mostrare la validità degli approcci partecipativi, perché se il progetto non è un pilot allora tutte le funzioni aziendali dovranno necessariamente essere coinvolte dall’inizio
• Si rinuncia alla possibilità di partire veramente dal basso nell’identificare i reali problemi delle diverse componenti dell’azienda e nel coinvolgere le persone come owner del progetto, mettendo a repentaglio lo stesso meccanismo di adozione su larga scala che si vuole raggiungere eliminando i pilot

Qual è allora l’approccio più efficace per lanciare e coltivare un progetto Enterprise 2.0 fino a raggiungere l’intera organizzazione?

A mio avviso purtroppo la risposta in generale non è esiste, ma al contrario dipende dal tipo di obiettivo (e quindi ancora prima dal tipo di bisogno) a cui si vuole dare risposta. Se per la collaboration un piccolo gruppo è assolutamente appropriato, per gli altri livelli si deve in effetti raggiungere la massa critica. Mentre però per l’intelligenza collettiva questi numeri sono necessariamente importanti, per i livelli intermedi a volte è sufficiente partire con 30-50 persone.

Molto dipende anche dalla preesistenza di barriere organizzative, culturali, geografiche tra i partecipanti al pilot, in quanto più queste barriere sono alte e maggiore sarà il valore generato dal mettere in condizione le persone di lavorare insieme. Infine conta moltissimo anche la posizione e la reputazione delle persone che si vanno ad invitare nei pilot: per esempio scegliendo attentamente influencer, gatekeeper, connector nella rete degli scambi informali, si avrà molta più probabilità di diffondere in tempi brevi il cambiamento anche con uno sforzo limitato.

Pilot si? Pilot no? Meglio non generalizzare. Dipende!

This post is also available in: Inglese