Home » L’adozione della intranet 2.0 e i suoi dilemmi

Dic
24

L’adozione della intranet 2.0 e i suoi dilemmi

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.

2 Commenti

  1. Ciao Giacomo,
    intanto auguri anche a te :)

    Due cents al volo: a mio avviso il distinguere community management e SaaS non è in generale appropriato, neanche lungo un continuum.

    Al tuo diagramma, andando da sinistra verso destra, si può sovrapporre rozzamente lo scope, ovvero la portata della comunicazione: a sinistra una comunicazione principalmente 1-to-1, basata su canali, poco riutilizzabile, efficace ma con portata limitata (solo mittente e destinatario possono accedere al contenuto) mentre a destra una comunicazione many-to-many abilitata da piattaforme (vedi la definizione di Davenport e McAfee). Utilizzare un canale è per la maggior parte degli utenti molto più semplice che utilizzare una piattaforma dato che il primo rispecchia più da vicino modalità a cui sono abituati come la mail o l’interazione face-to-face seppur riportata online. Verso destra, invece, essendo la portata del messaggio potenzialmente estesa a tutta l’azienda, subentra la necessità di toni, registri, responsabilità, fiducia, meccanismi di approvazione a cui sia il dipendente che l’azienda non sono ancora oggi abituati.

    Quale strumento/i sia più appropriato dipende dagli obiettivi del progetto e la scelta di norma varia nel tempo e tra i diversi gruppi che sono coinvolti. Ciononostante, la portata rivoluzionaria dell’Enterprise 2.0 rispetto a strumenti più tradizionali come la chat o il teamwork è insita proprio nella capacità di creare relazioni potenziali, di farci scoprire talento e competenze nascoste in persone che non conosciamo, di ricevere risposte in tempo quasi reale da qualunque parte dell’azienda, di co-creare soluzioni in modalità di crowdsourcing. Simili risultati più trasformazionali richiedono quasi sempre un impegno di supporto al cambiamento, coltivazione delle relazioni, creazione di contenuti, etc.

    Altro fattore chiave sono la cultura dell’azienda e la predisposizione degli individui. In una realtà giovane, dinamica ed informatizzata, introdurre un sistema di instant messaging è immediato ed automatico. Per coloro più avanti con gli anni, abituati a lavorare senza computer, questo stesso passaggio può richiedere invece molto più sforzo, formazione, supporto anche se lo strumento è fornito in modalità SaaS (che non significa comunque DIY, self-service). Lo stesso microblogging in alcuni casi funziona quasi senza nessuno sforzo, in altri richiede tempi e lavoro.

    Per chiudere: il tipo di supporto a mio avviso dipende più dagli obiettivi del progetto e dalla maturità dell’azienda (e delle sue persone) che dallo strumento in sè. Il fatto che gli strumenti possano essere messi a disposizione in modo autonomo, a basso costo, senza coinvolgimento dell’IT o del management è un fattore facilitante, ma il cui peso dipende in larga misura dall’obiettivo del progetto. La modalità di deployment (SaaS o on-premise) non è da sola quasi mai sufficiente a garantire l’adozione anche degli strumenti più semplici banalmente perché per gli utenti non è evidente il vantaggio che otterranno a seguito del cambiamento della modalità di lavoro. In questi casi non serve in senso stretto un community management, ma serve comunque qualcuno che aiuti a vedere in che modo lo strumento risolve un problema specifico, a rassicurare gli utenti mentre apprendono un nuovo tool, a rispondere alle domande, etc.

    Ovviamente, nella mia esperienza.

  2. Giacomo Mason ha detto:

    Grazie Emanuele, solo tu potevi prenderti la briga di commentare un post come questo :-)

    A parte gli scherzi, in realtà siamo d’accordo, solo che tu hai messo sul tappeto un tema che io non mi sono neanche sognato di affrontare, ovvero gli obiettivi per cui si fa una scelta o un’altra.

    In questo post questa cosa non mi interessa: non mi interessa stabilire il primato della collaboration sulla unified communication; volevo solo precisare come, quando si parla di “strategia di adozione” vadano intese cose molto diverse a seconda del tipo di strumento.

    Qualcosa è sempre necessario, anche per gli IM, come ho mostrato nello schema (dietro una parola come “tutorial” devi intendere cose anche di una certa complessità). Ma ignorare che gli IM sono in genere molto più facili da implementare indipendentemente dagli obiettivi o dalla azienda significa davvero ignorare la realtà dei fatti che tutti sperimentiamo tutti i giorni. Non sono un determinista tecnologico, mi del solo di quello che vedo.

    Non accetto che si parli, come spesso si fa, di “community management” in generale, quando far compilare un profilo, far commentare un articolo, fare creare un gruppo di lavoro o creare una pagina wiki sono azioni molto diverse, che richiedono strategie diverse e un grado di impegno diverso da parte delle persone.

    Se non facciamo questa distinzione prestiamo il fianco proprio a coloro che dicono “abbiamo fatto l’enterprise 2.0” quando in realtà hanno messo in piedi un sistema di web conference. Tutelare la complessità delle community (con tutto quello che comporta e non voglio entrare nel merito perchè ci ho scritto sopra decine di post) tutelare questa complessità, dicevo, significa isolare questo tema rispetto ad altri che con le community hanno solo un rapporto di parentela (ad esempio commentare una news o iscriversi agli rss di una sezione informativa sulla intranet).

    Lo schema che ho fatto è, appunto, “schematico”, ma mi serve (come quasi tutto quello che scrivo) principalmente a fini didattici.

Lascia un commento

Questa pagina utilizza i cookies, come le pagine di mezzo mondo. I cookies sono una cosa che fa parte della vita, ok? Don't worry http://www.intranetmanagement.it/cookies/

Questa pagina utilizza i cookies, come le pagine di mezzo mondo. I cookies sono una cosa che fa parte della vita, ok? Don't worry

Grazie mille per la pazienza. E' l'Europa che ce lo chiede