C’è un aspetto che riguarda i social software interni e più in generale tutte le funzionalità avanzate di collaborazione e community che, fino a ora, non ero mai riuscito a chiarirmi: quanto dobbiamo lasciare libere le persone di adottare queste funzionalità e quanto invece dobbiamo costruire un contesto adeguato capace di dare un senso operativo a questi strumenti?

Naturalmente conosco bene l’importanza del community management, e io stesso battuto su questo tasto ripetutamente in questi anni. In buona compagnia peraltro: basta leggere ad esempio “Software is not enough“, di Rachel Happe o”6 Keys to Launching Successful Collaborative Intranet Groups“, o ancora “Enabling Participation: More Art Than Science“, solo per citare alcuni esempi, per rendersi conto di quanto sia diffusa la convinzione che sia *sempre* necessaria una qualche strategia di adozione.

Eppure c’è qualcosa che non mi quadra in questa posizione così netta: tutte le volte che un cliente mi parla del successo immediato del nuovo sistema di instant messaging o tutte le volte che leggo di come un qualche software di microblogging sia stato adottato seza problemi all’inerno di una certa realtà organizzativa, un campanello d’allarme suona nella mia testa.

In questo caso infatti non c’è alcuna “strategia di community management”, ma solo una logica Software as a Service (SaaS) nella quale un nuovo sistema viene messo online per fare fare ai dipendenti alcune cose (in genere comunicare) dopodiché vengono esaminati i risultati e i valutati comportamenti.

Come la mettiamo allora, SaaS o community management? Notate che le conseguenze della risposta influenzano l’organizzazione interna, il peso che le tecnologie assumeranno, le strategie di comunicazione e di analisi preliminare.

E la risposta è che queste due alternative non si escludono tra loro, e il dilemma tra “lanciare un software e vedere che effetto fa” e “costruire il contesto perché le persone lo utilizzino” è in realtà falso. Si tratta di capire che le due alternative sono in realtà due estremi di uno stesso spettro, nel quale vanno inseriti i diversi strumenti.

Spero che lo schema seguente mi aiuti a farmi capire:

Lo schema presenta:

  • nella parte alta gruppi di strumenti, in ordine di adottabilità SaaS;
  • nella parte bassa le relative strategie di adozione.

All’estremo sinistro dello spettro abbiamo gli strumenti che possono essere erogati in modalità SaaS, e man mano che ci spostiamo verso destra troviamo strumenti e funzionalità che necessitano sempre di più di modalità gestionali complesse.

Come vedete, all’estremo sinistro troviamo strumenti legati per lo più alla comunicazione, mentre all’estremo destro troviamo iniziative legate per lo più alla partecipazione attiva e alla produzione di contenuti. Come vedete, gli strumenti SaaS come la webmail o l’instant messaging necessitano in genere solo di policy e tutorial, mentre man mano che ci spostiamo verso destra le strategie di adozione diventano sempre più complesse.

Adottare in modalità SaaS un sistema di IM è quindi relativamente più “facile” che adottare gli RSS, che sono più facili della compilazione del profilo personale arrichito, il quale è a sua volta più facilmente adottabile dei commenti ai contenuti e così via, fino ad arrivare ai wiki o ai forum tematici.

Credo che questa soluzione, che vede SaaS e communtiy management lungo una linea di continuità, permetta di superare certe “anomaile di Kuhn” nelle quali talvolta ci capita di imbatterci (almeno per me).

Che ne dite? Intanto buon Natale a tutti.