Nei commenti dell’ultimo post c’è stato uno scambio interessante sulla migliore o più efficace modalità per introdurre approcci sociali e partecipati all’interno di un’impresa. In quell’occasione Thomas Christel faceva notare come a suo avviso non ci fosse in fondo una grande differenza tra l’Enterprise 2.0 ed un progetto IT tradizionale.
Ma è veramente così? Cosa emerge dalle esperienze di coloro che hanno lanciato effettivamente progetti Enterprise 2.0 in aziende di grandi dimensioni? In che modo il roll-out di iniziative 2.0 si differenzia dalla più diffusa introduzione di software enterprise?
Più che centrare la discussione sulle mie esperienze, preferisco ancora una volta dare visibilità ad un report del 2.0 Adoption Council, il primo gruppo peer-to-peer nato per discutere in modo aperto e trasparente le esperienze dei responsabili dei maggiori progetti Enterprise 2.0 in tutto il mondo. Il documento è intitolato A Framework for 2.0 Adoption in the Enterprise ed è pensato proprio per far emergere i pattern di adozione e le best practices che caratterizzano i roll-out 2.0 di successo. Il report è a pagamento, ma il suo valore è innegabile per le aziende che si stanno chiedendo quale sia il modo più efficace di procedere in un terreno nuovo ed ad altissimo potenziale come l’Enterprise 2.0. Ringrazio Susan Scrupski per avermelo fornito ai fini di questo post.
Le indicazioni che seguono sono state prodotte in modo collaborativo dai membri del Council, confrontando le loro esperienze e cercando di identificare delle pratiche ricorrenti in grado di guidare praticamente il processo di adozione.
Semplificando al massimo, quando un’azienda decide di introdurre un nuovo CRM o un ERP, l’approccio seguito si muove di norma con un andamento top-down, a cascata, in cui il progetto nasce sotto la sponsorship di un senior executive, con una roadmap preliminare delle fasi messa poi in pratica sequenzialmente dal gruppo di IT. Il web 2.0 dimostra però come sia possibile una via diversa, in sostanza opposta, in cui gli impiegati più intraprendenti cercano proattivamente ed in modalità bottom-up (dal basso) approcci e strumenti migliori di lavoro che poi si diffondono viralmente. Dal Council emerge invece che nessuna di queste due vie è da sola in grado di garantire un roll-out ottimale di iniziative che attraversano dipartimenti o intere country:
- Il processo di roll-out dovrebbe riprendere gli stessi comportamenti che si vogliono far emergere dall’iniziativa. Per ottenere una partecipazione volontaria e corposa da parte degli utenti (senza cui come abbiamo sempre detto introdurre strumenti è assolutamente inutile), questa partecipazione va attivata dall’inizio, nello stesso lavoro di definizione e progettazione dell’iniziativa
- Alla partenza del progetto è quasi impossibile sapere con precisione a quali comportamenti dobbiamo mirare dato il taglio pesantemente organizzativo, la novità, la rapida maturazione, la forte componente culturale dei progetti Enterprise 2.0
- I roll-out tradizionali limitano l’agilità e la possibilità di cambiare strada in corsa, mentre questa capacità è necessaria per rispondere alle esigenze degli utenti ed agli stimoli di un mercato in continua evoluzione
- L’approccio bottom-up sembra giocare un ruolo importante all’inizio del processo di adozione, ma non scala. Senza il supporto dell’organizzazione con un team leader, la sponsorship del management, un team che guidi il progetto, si rischia di non andare sufficientemente lontano, limitando la collaborazione all’interno del singolo team o introducendo una miriade di strumenti diversi, quindi difficilmente gestibili e poco collegati ad un complessivo lavoro di cambiamento organizzativo. Nessuno degli intervistati ha dichiarato di aver utilizzato solamente un approccio dal basso
Per tutte queste ragioni, secondo le aziende intervistate, il processo di adozione di strumenti (e di evoluzione di una cultura) 2.0 è drasticamente diverso dalle pratiche finora adottate per altri strumenti enterprise, prima di tutto per l’approccio centrato sulle persone che deve guidare l’intero lavoro. Pur partendo da un processo tradizionale a cascata, il 2.0 Adoption Council è arrivato in fretta alla conclusione che esso non rappresentava affatto un modello realistico di cosa era stato fatto nei progetti. La realtà è purtroppo meno sequenziale, più variabile e caotica di così.
Cosa manca alla waterfall per essere efficace quando applicata all’Enterprise 2.0? Che pattern emerge dal 2.0 Adoption Council? Ecco la risposta, con gli attori principali da coinvolgere, le fasi ed iterazioni necessarie ed i checkpoint che marcano un processo organizzativo d’insieme:
Il diagramma può essere letto da sinistra verso destra in questo modo:
- L’adozione parte spesso da una scintilla iniziale che può essere data da dipendenti che iniziano autonomamente ad utilizzare nuovi strumenti poi sistematizzati dall’azienda, un manager che vede un’opportunità colmabile tramite un approccio collaborativo o una storia di successo che riguarda un competitor. C’è da dire che la diffusione del web 2.0 fuori dalle aziende oggi aiuta molto a stimolare aspettative e risposte autonome dei dipendenti
- Per far scalare una buona idea serve quindi un champion, un project leader (IT, business line, comunicazione interna, etc) con autorevolezza, influenza, potere decisionale e capacità di attraversare le barriere organizzative dell’azienda. Comprendere le peculiarità ed i bisogni organizzativi dell’impresa in cui ci si muove, oltre che le sfide tecniche, è sicuramente un fattore critico di successo del progetto
- Un champion da solo non basta per contaminare ogni angolo dell’azienda, serve un team di adozione che grazie alla sua diversità (gerarchica, geografica, doti sociali, nel background professionale) consenta di raccogliere i bisogni e tirare a bordo tutte le parti dell’organizzazione, facendo da ponte tra l’iniziativa 2.0 e le aspettative di ogni divisione e mostrando ai dipendenti gli impatti sui processi a cui sono abituati
- Coinvolto il business deve essere coinvolto anche l’IT per affrontare i problemi tecnici e di integrazione. Ciò può essere fatto inserendo un rappresentante dell’IT direttamente nel team di adozione, con il project leader che riporta all’IT, impiegando due team paralleli (IT e Business)
- In questa fase è importante coinvolgere anche l’HR e le funzioni di risk management, legali e di sicurezza a seconda delle condizioni organizzative e politiche al contorno
- Per garantire budget, supporto e continuità al progetto il Project Manager deve prepararsi per ottenere il buy-in dal management affrontando questioni legate ai costi, alla tempistica, ai potenziali ritorni, ai rischi. Finché non viene ottenuta un’approvazione formale dagli executive, l’iniziativa potrebbe essere vista come contraria a policy interne, altre iniziative corporate o interessi politici. Ci si può aiutare richiedendo consulenze esterne, utilizzando ricerche, analisi competitive rispetto al settore di appartenenza
- Quando tutto è pronto da un punto di vista organizzativo e tecnologico, si è pronti per lanciare un pilot al fine di testare in un ambiente protetto (come numero di utenti, come visibilità, come numero di funzionalità rese disponibili, etc) gli impatti dell’iniziativa, i problemi che potrebbero generarsi, i risultati. Da qui parte il lavoro del community manager.
- Facendo tesoro delle lezioni apprese nel pilot, si passa al roll-out su larga scala facendo leva sul team di adozione che a propria volta può coinvolgere altre figure all’interno della propria divisione in base alla dimensione ed alla struttura dell’azienda
- Mentre l’adozione inizia a prendere piede, si preparano le necessarie policy e linee guida anche qui in modo collaborativo, non minatorio, ma piuttosto incoraggiando gli utenti verso i comportamenti attesi e cercando di alimentare la fiducia nei propri dipendenti
Come si intravede, l’approccio complessivo è iterativo, quasi agile ed in un certo senso virale per diffondere attesa, interesse e voglia di partecipare dal basso attraverso tutta l’azienda.
Il processo condiviso è a mio avviso abbastanza solido, ma aggiungerei alcune osservazioni:
- Si dovrebbe forse mettere maggiormente l’enfasi sul valore assoluto del co-design e dell’ascolto nel collegare l’iniziativa sia ai bisogni del business che a quelli dei singoli utenti, garantendo a questi ultimi un ruolo ancora più forte nella progettazione di contenuti, servizi e nell’organizzazione degli spazi
- Si rimane ad un livello un pò troppo astratto (ma il report è volutamente una generalizzazione di pattern emersi da più aziende). Vengono descritte essenzialmente le macrofasi del lavoro, ma non è facile comprendere quale siano le singole attività e gli output da queste prodotte. In particolare consiglierei di ragionare dall’inizio sulle metriche e dare più spazio al centrale lavoro di community management, troppo spesso sottostimato dalle aziende
- Non è totalmente chiaro in che modo raccogliere le necessità più sentite in azienda ed a cui l’Enterprise 2.0 può dare risposta o come collegare le community alla socializzazione dei processi esistenti. Tutti temi di dettaglio su cui è necessario tornare in un progetto reale
Ciò nonostante, nel complesso il lavoro del Council ci fornisce forse la prima visione reale di come alcune delle più importanti aziende al mondo si sono rapportate alle sfide introdotte dall’Enterprise 2.0, rivelando linee guida che sono spesso molto distanti dalle modalità adottate all’interno di progetti IT tradizionali e che pertanto richiedono attenzione ed ancora una volta un salto di mentalità importante da parte degli attori coinvolti.
Oltre ad andare molto più nel dettaglio su ogni singola fase, con utili citazioni dalle persone intervistate, il report mette in guardia anche su una serie di rischi espressi dagli intervistati nella gestione delle aspettative del management, nell’allocazione delle risorse, nella formazione degli utenti e nell’integrazione tecnologica.
Una ragione in più per farlo acquistare alla vostra azienda ed utilizzarlo all’interno del vostro progetto Enterprise 2.0.
