Credo che nel nostro campo ogni iniziativa del genere sia una boccata d’aria fresca: dobbiamo cominciare a fare rete in tutti i posti disponibili, perché le intranet e i progetti Enterprise 2.0 stanno dietro i firewall aziendali e questo rende le cose molto, molto più complicate.

Tra le ultime segnalazioni del gruppo vi evidenzio la discussione riguardante il design della home page e quella sulle applicazioni killer della intranet. Inoltre qualche giorno fa Kevin Cody ha segnalato un PDF dedicato ai fallimenti dei progetti intranet. Potete scaricare il PDF da qui.

Buona lettura e buona iscrizione :-)

La tesi di Nielsen è condivisibile sia nelle sue premesse sia nella sua conclusione (anche se debole nelle sue argomentazioni): dato che le intranet sia basano principalmente su alcuni precisi task dei dipendenti,  la presenza di piattaforme precostituite non ci esime dall’attività di progettazione e di design. E se esaminiamo alcune intranet costruite a partire da Sharepoint ci accorgiamo immediatamente delle differenze, in barba alle funzionalità native che può presentare l’applicazione.

In realtà le obiezioni di Nielsen all’idea (così come alla perversa aspirazione) che una piattaforma come Sharepoint possa ridurre tutti gli ambienti a cloni di se stessi sono fin troppo lievi: per Nielsen a parità di piattaforma varieranno in modo consistente sia l’architettura informativa (o meglio le label) sia i contenuti in evidenza in home page. Ma questa obiezione non tocca il cuore del problema, perché è scontato che questi elementi saranno diversi da azienda ad azienda e non è su lor che va misurata l’eterogeneità radicale dei due elementi di design da una parte e piattaforma dall’altra.

Il fatto è che le aziende, come ho sottolineato più volte, non operano in un “vuoto di tecnologie” che la intranet dovrebbe occupare. E non operano neanche in un “vuoto di pratiche”, che la intranet sarebbe chiamata ad abilitare. Al contrario, le aziende sono già piene di tecnologie stratificate: email, dischi di rete, client della più diversa natura, bizzarre applicazioni, siti web abusivi, database estemporanei che diventano, anche in mancanza di alternative, elementi strutturali dei processi. A questo caleidoscopico orizzonte dobbiamo aggiungere le pratiche quotidiane delle persone, stratificate in abitudini, comportamenti, processi di fatto e così via.

Progettare una intranet significa guardare in faccia questa situazione, per così dire, spigolosa e disegnare – all’apparenza in astratto, ma in fine dei conti in modo molto più concreto di quanto le piattaforme possano offrire in modo nativo – un’applicazione che ne sia la sintesi. In tutto questo le piattaforme entrano fino a un certo punto e a dire il vero le migliori intranet dissimulano la loro origine, ovvero le piattaforme, perché sono sempre un oggetto ibrido che deve mettere insieme cose assai diverse tra di loro.

Il processo di design riguarda l’architettura informativa, certo, e lo schema delle pagine, ovviamente, ma anche la collocazione dell’ambiente in un ecosistema più ampio, nel quale la piattaforma si colloca come attore al pari degli altri. In alcuni casi certe funzionalità della piattaforma andranno completamente riscritte, in altri casi sarà affiancata da altre applicazioni che si integreranno ad essa. A volte metà della home sarà occupata dal motore di ricerca, in altri casi la presenza di CRM, wiki o sistemi di e-learning dovrà rubare posto ad altri elementi. Per non parlare delle pagine interne o di applicazioni verticali come il cercapersone. In questo Sharepoint o i suoi fratelli non ci possono aiutare e lo dimostrano le tante aziende che si sono portati a casa queste tecnologie per poi ritrovarsi ai dire ” e mo” che facciamo?”.

Anche la migliore piattaforma, in definitiva, resta qualcosa di più astratto del peggior design perché, mentre quest’ultimo si confronta comunque con i reali problemi dei dipendenti di un’organizzazione, la prima definisce uno standard buono per tutti e per nessuno, a cui bisognerà, nel migliore dei casi, “rimettere mano”.

Ciò non toglie, ovviamente, che molte intranet si assomiglino tra di loro, ma questo avviene meno per la presenza di piattaforme che uniformano i contenuti e più per il ricorrere di problemi comuni alle aziende, che, fortunatamente, possono essere trasformati in pattern di design. oggi i menù di navigazione principali tendono ad essere collocati in alto e il design tende ad essere a due colonne; sappiamo dove mettere il motore di ricerca e come, grossomodo, deve essere fatta la scheda di un dipendente.

Questo rende più semplice, ma non elimina il problema del design. Che eccede sempre le piattaforme per collocarsi in un territorio neutro nel quale tecnologie, pratiche, esigenze e pattern diventano progetto concreto.

P.S. Scusate lo stile fortemente ipotattico, ma mi sono accorto di essere ancora in modalità libro. Tornerò in modalità blogger dopo un sano periodo di disintossicazione :-)

Tutto quello che sappiamo sulla logica del bastone e della carota, così cara a livello manageriale, ha senso solo per prestazioni elementari ma, man mano che aumenta la necessità di pensiero divergente e visione sistemica, non ha più alcuni significato. Anzi, è dannosa e peggiora le prestazioni. Tutto provato, anche se apparentemtne controintuitivo.

Il video è sottotitolato anche in italiano per cui…Buona visione. Ah, per la cronaca: il video l’ho trovato in un che, coerentemente, parla di come aumentare il valore dei progetti enterprise 2.0 tramite gioco e motivazione.

Come sapete (perché vi ho fatto una capa tanta) credo che il tema delle domande-risposte dentro l’organizzazione sia una delle cose più promettenti e interessanti sul tappeto perché è un argomento capace di produrre molto valore con uno sforzo minore che per altre iniziative. Il motivo di questa relativa facilità credo risieda in alcune caratteristiche proprie di questi progetti:

- Intercettano n bisogno comune a tutti: tutti abbiamo bisogno di chiedere qualcosa a qualcuno durante la nostra giornata lavorativa, e lo stesso fanno gli altri con noi.

- Mappano online una pratica già consolidata: non si tratta di far fare alle persone qualcosa di nuovo (come scrivere un documento in parallelo tra più persone) ma di portare online qualcosa che le persone conoscono bene.

- La proposta è semplice: il tipo di progetto è facile da capire, in altre parole, nei termini di Clay Shirky, promessa, strumenti e patto sono assolutamente chiari a tutti fin dall’inizio.

- L’applicazione è semplice da imparare: non richiede sofisticati layer e bottoni, ma è sufficiente, lato utente, un form per inviare la domanda e una bacheca per leggere domande e risposte, e questo abbassa  la curva di apprendimento. Certo, ci saranno tag e altre opzioni; certo, il codice per inviare le domande agli esperti magari sarà sofisticato, ma lato utente la cosa è molto semplice e comprensibile.

Il tema delle domande/risposte è quindi davvero esplosivo e in rete ci sono molti esperti che cominciano a parlarne e a riportare casi interessanti (leggete ad esempio questo post di Gil Geuda dedicato al problema di trovare esperti in azienda e alla sua analisi di ArdWark, applicazione per fare, guarda un po’, domande/risposte in rete agli esperti. L’applicazione tra l’altro è stata comprata la settimana scorsa da Google e la cosa la dice lunga sugli investimenti e l’attenzione in questo campo).

Dato che Sabre è uno dei vincitori dell’Intranet Award 2009 i ragazzi di Steptwo hanno fatto l’intervista al coordinatore del progetto e l’hanno pubblicata su youtube. Credo valga la pena.

Alcune preoccupazioni attorno al microblogging interno. Oscar Berg affronta alcune tipiche obiezioni (poche persone orientano le discussioni, arriva lo spam, c’è il rischio di essere fraintesi). Interessante anche un suo articolo precedente:  “Il microblogging interno può intimidire“.

—

L’importanza di un community management attivo, provata con i dati.  L’esperienza di un community manager nel corso di un anno di gestione; i numeri mostrano che cosa succede quando le communty vengono lasciate sole. Appassiscono.

—

Come cambia il ruolo di H.R. con il web 2.0. Una tabella interessante (in francese). Sul tema leggete anche il post di Jon Husband.

—

L’organizzazione tradizionale è una macchina e noi invece siamo esseri umani. Questo articolo prosegue il tema del rapporto tra orgnanizzazione e processi informali, tra struttura e flusso. Aspettiamo gli altri articoli della serie

—

Il lato oscuro dell’enterprise 2.0. E’ bene che qualcuno ricordi non solo le promesse ma anche i rischi. Anche perché sono quelli che i manager vedono per primi. Bella anche la presentazione.

12 motivi per i quali l’e-learning è così efficace. Vale la pena ripassarseli.

—

Tecnologia e processi collaborativi negli ambienti di ricerca e sviluppo. Interessante esplorazione dei mutamenti nei tema di lavoro legati alla ricerca con l’arrivo delle tecnologie di social networking per i team.

—

Un bel caso di studio su un blog interno. E alcune regole per farlo funzionare bene.

—

E per finire, alcuni dubbi sull’efficacia effettiva dei sistemi online per la ricerca di esperti interni. Il senso è: magari li trovo più facilmente, ma se sono straimpegnati che ci faccio? In risposta a questo articolo, un po’ troppo agiografico.

–

Buona lettura :-)

La mia presentazione (10 minuti) è dedicata alla mia esperienza personale e soprattutto a quella di portare “la nuvola” in azienda (la slide 11 è venuta male su Slideshare:  erano 2 screenshot dei miei blog).  Ci vediamo lì?

Ovviamente una promessa, implicita o esplicita, dei progetti di collaboration aziendale è quella di ridurre il volume di mail o per lo meno di associarsi ad esse in un ecosistema di informazioni che stanno in parte sui PC e in parte nella “nuvola” aziendale. Ma spesso si fanno i conti senza l’oste, ovvero la massa di persone che ha impiegato anni a passare dai vecchi sistemi (dal fax alla telescrivente) alle mail e che ora si trova a gestire – ovviamente in modo forsennato, frustrante, surreale – il volume di comunicazioni che arrivano sulla posta elettronica.

Ma come? ora la mail è diventata il nostro archivio, la nostra chat, il nostro sistema documentale, il nostro social network, che cos’altro volete da noi? Dobbiamo cambiare un’altra volta?

Ovviamente si, devono cambiare un’altra volta; ma hanno ragione, dal loro punto di vista. E proprio per questo il lavoro di accompagnamento dai vecchi sistemi ai nuovi, dai canali alle piattaforme, non può avvenire in un “vuoto” progettuale: vanno costruiti dei ponti e quello delle notifiche è sicuramente il principale.

Nella mia esperienza mi è capitato tante volte di sentirmi dire: “ci andrei, ma non so mai se c’è qualcosa di nuovo e non vengo avvisato”, oppure “ormai ci sono troppi contenuti, dovrei avere un sistema per ritrovare quelli che mi interessano”. Insomma, capita troppo spesso di costruire piattaforme dimenticandoci dell’aspetto – essenziale – del collegamento delle stesso con i vecchi sistemi, email in primis.

Ormai ho capito che qualunque piattaforma di condivisione interna dovrebbe avere – di default – altert di notifica via email per *tutto*:

- per i nuovi post nei blog a cui sono iscritto
- per i commenti ai miei commenti
- per i therad e le discussioni nei forum a cui  sono iscrtitto
- per gli archivi documentali a cui sono iscritto
- per le pagine wiki a cui sono iscritto
- per i contenuti generali dai miei gruppi di lavoro
- per commenti e domande ai materiali che ho caricato

Eccetera eccetera. Perché ci si pensa così poco  quando le si progetta? Mah, forse perché la email è alla fine un oggetto così ambiguo e ormai così prosaico da non destare più alcun luccichio negli occhi di nessuno, casomai un moto di fastidio. Ma dobbiamo guardare il mostro in faccia, e affrontarlo a viso aperto fin dall’inizio per evitare che si trasformi in una buccia di banana progettuale che vanifica gli sforzi di tutti.

Vorrei aggiungere una considerazione per quanti ritengono che in questo modo non si riduce il volume della email, anzi lo si aumenta e tanto basta a considerare inefficienti queste applicazioni. Sono d’accordo: il volume delle email forse non cambierà, e anzi può darsi che aumenti. Ma quello che cambia è lo statuto di queste mail: sono avvisi, non contenuti. Il contenuto (ovvero la ciccia) sta nella piattaforma, ed è questo  che conta.

La mail si svuota così dei gravosi compiti a quali è stata sottoposta (comunicazione, archivio, condivisione, coordinamento, avviso, discussione in real time) ed assume il ruolo modesto ma fondamentale di neutro indicatore di contenuti. E cestinarle è molto, molto più veloce.

Quanti sono questi attori e quali sono questi ruoli? Proviamo a definire questo elenco: una intranet aggrega in un insieme applicazioni e tool che supportano:

• me come dipendente (es: servizi online)
• i team interfunzionali (es: gruppi di lavoro virtuali)
• i settori/dipartimenti (es: canali di settore)
• le community (es: forum tematici)
• le reti informali (es: social network)
• i processi (es: form online)
• l’azienda come sistema di conoscenze (es: wikipedia interna)

Si potrebbero, come ovvio, aggiungere altri esempi per ogni tipo di utilizzo, e va anche detto che, alla fine, ognuno di questi utilizzi supporta il singolo dipendente. Aggiungiamo il fatto che a volte alcune applicazioni stanno a cavallo di queste distinzioni, ma credo lo stesso sia davvero importante distinguere preliminarmente, e a livello astratto, questi possibili utilizzi, perché determinano le funzionalità che vanno pensate, progettate e poi realizzate sulla intranet.

La intranet è grande, e c’è posto per tutti,  ma è importante non confondere le mele con le pere anche per essere in grado di misurare successi e insuccessi. In particolare mi ha sempre affascinato e spaventato allo stesso temo il tema dei team interfunzionali.

Questo tema infatti è una reale sfida per il progettista ed un banco di prova tra i più seri per il progetto intranet: i team interfunzionali devono infatti arrivare a dei risultati, hanno in genere bisogni precisi, hanno una storia di collaborazione alle spalle che le nuove tecnologie tenderanno in parte a ridefinire, usano tecnologie che entrano direttamente nel flusso di lavoro.

Insomma, con le tecnologie a supporto dei team non si scherza, e la progettazione sconta sempre il dilemma se assecondare le vecchie abitudini – disfunzionali – o inaugurare nuove modalità che rischiano di  non essere adottate. Il dilemma permanente – diasporico e contraddittorio – del progettista.

In generale, direi che le tecnologie a supporto dei team virtuali si dividono i tre categorie:

- Tecnologie di comunicazione (mail, telefono, Instant messaging, videoconferenza, micro-blogging, voice over IP, ecc.)
- Tecnologie di condivisione (news, blog, document sharing, wiki, forum, ecc.)
- Tecnologie di cordinamento (calendari, project management, ecc.)

Come usarle e in quel mix presentare ai team è – appunto – tema della progettazione di questi ambienti.

A questo riguardo vi segnalo una bella ricerca sui team virtuali condotta recentemente su più di 400 aziende europee (ecco il pdf da scaricare – 879 kb)  che racconta le difficoltà e le caratteristiche della collaborazione a distanza tra i team aziendali.

Tra tutti i dati vale la pena riportare il grafico sulle tecnologie utilizzate:

Mi sembra che emerga come le tecnologie di comunicazione siano ancora, tra le tre, le più utilizzate. Un altro dei risultati che emergono dalla ricerca riguarda il management di queste iniziative: perché abbiano successo è infatti molto importante sia una gestione attenta e meticolosa da parte dei capi progetto sia un insieme di regole rigorose da rispettare (ad es: devi rispondere entro 48 ore e cose così) proprio perché i membri del team non hanno a disposizione molti elementi per “correggere il tiro” fisicamente se qualcosa va storto o un membro del team non dà segni di se per giorni e giorni.

Insomma, un tema affascinante, che va ben oltre le tecnologie a supporto.

Chi organizza un progetto di enterprise 2.0 ha di fronte a se, in genere, due soggetti:

- i committenti/sponsor
- i dipendenti (che si divideranno poi in champions e tutti gli altri).

A volte il progetto si allarga ad altri dipartimenti, ma resta comunque animato da questa bipartizione fondamentale (un esempio abbastanza charo di questa impostazione è un recente post di Betrand Duperrin).

Chi invece organizza un progetto  intranet (“tradizionale”, ma anche innovativa) ha di fronte a se, fin dall’inizio, per lo meno tre soggetti:

- i committenti/sponsor
- i dipendenti
- i referenti/redazione allargata/contributori/owners

Tralascio naturalmente la galassia di attori che gravitano attorno alle tecnologie, che sono gli stessi per entrambe le dimensioni (IT, consulenti, fornitori ecc).

Ora, questo terzo livello è particolarmente delicato, perché coinvolge figure di diversa natura, di diverso peso e a diverso titolo. Son inclusi in esso:

- Referenti della comunicazione
- Redattori istituzionali
- Responsabili di siti intranet locali
- Detentori di contenuti particolari
- Responsabili di applicazioni
- Capi ufficio sparsi per l’organizzazione
- Responsabili forum, blog, FAQ per le applicazioni interattive

Naturalmente la composizione, il ruolo e i contenuti variano da azienda ad azienda ma la sostanza resta che nei progetti intranet dobbiamo fare i conti con questa massa di persone, le quali determinano alla lunga il successo o l’insuccesso del progetto. E questo perché tutte queste persone hanno il compito di fornire contenuti ufficiali e aggiornati, di gestire la qualità delle risposte e delle discussioni, di coprire tutte le esigenze informative della loro popolazione di riferimento.

Una faticaccia.

Naturalmente anche i progetti enterprise 2.0 hanno i loro bei problemi e non ci voglio tornare sopra adesso; ora volevo solo ribadire come spesso questo livello di governance sia la vera discriminante tra le due dimensioni.

A questo proposito vi segnalo un bel post di Jane McConnell che da alcuni consigli sulla governance, e un altro post  di J. Boye su come supportare al meglio i “content owner” nei progetti intranet che coinvolgano una migrazione di contenuti .

L’autore sintetizza il passaggio di prospettiva in questi progetti attraverso 11 principi oppositivi (anche se il titolo dice 10) . Praticamente una slide perfetta (o anche 10 slide perfette, se usate un approccio “zen” ortodosso nelle presentazioni) per chi si occupa di consulenza o formazione:

Eccoli:

- Conversazione vs. Broadcast
- Bottom up vs. Top-down
- Reputazione vs. gerarchia
- Emergenza vs. Struttura
- Folksonomie vs. Tassonomie
- Agilità Vs. Burocrazia
- Trasparenza vs. Sicurezza
- Reti intrecciate vs. Silos funzionali
- Semplicità vs. Complessità
- Tecnologie user-oriented vs. IT Governance
- Fiducia vs. Controllo

Niente di speciale, nulla di realmente dirompente: poche parole semplici che devono solo aiutare i manager a capire di che cosa stiamo parlando.

Può servire.

Vale la pena, già che ci siamo, segnalare anche la sua presentazione su Slideshare dedicata al tema.

In due post Oscar prova ad analizzare le sfumature organizzative della collaborazione: in azienda siamo abituati a pensare a team e task force, molto meno a gruppi informali o comunità – reali o potenziali – di pratiche e interessi.

E infatti molte tecnologie e progetti si concentrano sull’idea di team, ovvero:

- un gruppo di persone ristretto
- un gruppo di persone con un obiettivo preciso e output visibili
- un gruppo di persone con ruoli definiti
- un gruppo di persone con scadenze e task precisi

Ok, questo è il team, e molti software e tecnologia sono in grado, mediamente, di supportare questo tipo di situazione. Ma che cosa succede se il gruppo non è ristretto, non ci sono obiettivi precisi, le persone non hanno ruoli definiti e non hanno scadenze e task precisi?

Tutto quello che avviene in questa situazione non è più, in senso stretto, collaborazione, ma piuttosto cooperazione collettiva. Berg prova in questo post a tracciarne i confini.

Ma la cosa importante è che, anche in questo caso non è corretto pensare in termini di distinzioni e opposizioni. Qualunque team che funzioni si appoggia su reti di cooperazione collettiva, e all’interno delle reti di cooperazione collettiva avvengono fenomeni di organizzazione e definizione dei ruoli che portano verso una maggiore istituzionalizzazione.

Berg prova a rappresentare le cose così:

Fase 1: il team di crea da varie fonti organizzative

Fase 2: il team sviluppa un pensiero comune

Fase 3: i membri sono in contatto con altre fonti esterne

Fase 4: le fonti diventano esplicite ed entrano in gioco

Fase 5: si sviluppano hub

Fase 6: si sviluppano tecnologie per filtrare e supportare le informazioni prodotte nella rete

D’accordo, forse non è corretto parlare di “fasi”, perché in realtà molte cose avvengono in contemporanea o magari non nella stessa sequenza. Ma quello che è importante non è tanto questo, a mio parare, ma il fatto che team e community, collaborazione e cooperazione collettiva sono spesso due elementi che vanno di pari passo.

Possiamo creare tecnologie per i team, ma preso avremo bisogno di espanderle per dare “linfa” ai team, così come ogni social network interno che si rispetti ha bisogno, prima o poi, di strumenti per la produttività per quando le cose si fanno “serie”.

In questo caso propone tre modelli per rappresentare l’integrazione degli ambienti e delle applicazioni in intranet (chiamate ora web workplace). La domanda è:  la intranet è la porta d’ingresso comune al web interno o ci sono altre porte laterali verso ambienti specifici? Gli schemi parlano da soli, credo:

Modello 1: Frammentato (presente nel 30% dei casi)

Modello due: ibrido (55% dei casi)

Modello tre: unificato (15% dei casi)

Devo dire che, al di là della qualità dei dati, come al solito è tutto piuttosto deprimente.

Naturalmente ogni idea per migliorare questo fondamentale task degli utenti sulle intranet è di enorme importanza, e nelle aziende veramente grandi significano minuti-ore-giorni uomo risparmiati all’anno. Per questo mi ha molto colpito l’articolo di Vivek Deshmuk, pubblicato su Boxes and arrows, dedicato proprio ad un suo progetto di miglioramento del cercapersone interno.

Vivek ha tenuto traccia di tutte gli errori di digitazione fatti sulle singole persone dagli utenti dell’azienda, per poi comporli automaticamente in pattern che vengono presentati come alternative all’utente. Così, se cerco De Rossi, il sistema non trova nulla ma mi chiede: “forse volevi dire De’ Rossi?

E il bello è che tutto questo non viene fatto con tabelle prestabilite a priori, ma basandosi sui concreti input degli utenti, rispettando quindi le loro intuizioni rispetto ai cognomi. Il risultato è una cosa di questo tipo:

Molto intelligente e user centred, no? :-)

Primo frammento:  del ricostruire la Germania e del sistemare i quadri

C’è un passo di Daniel Cohen che mi è rimasto impresso e mi torna spesso alla mente; il tema è l’apparente “miracolo” della ricostruzione della Germania nel dopoguerra; Cohen parte de un lavoro di Mancur Olson:

“La sua teoria [...] sostiene che le nazioni “nuove” o “distrutte” siano percorso da uno stesso progetto collettivo: ricostruire il Paese. Non vi è, pertanto, alcuna reale difficoltà nell’individuare le modalità di un’azione cooperativa, collettiva. Quanti ospedali e scuole bisogna costruire? Quale deve essere la durata legale della giornata lavorativa? Sono solo alcune delle domande a cui si risponde senza grandi contrasti [...] Nel caso della Germania del dopoguerra, la società non è da inventare, bensì da ricostruire. Il modo di tagliare i capelli, di curare i malati, di educare i bambini…fanno parte della cultura condivisa dai tedeschi. Mancano “solo” le infrastrutture, “l’equipaggiatura”. In poche parole, il capitale. Ma questa è poca roba rispetto al sapere comune.”

Capire dove appendere i quadri in casa è un’operazione che può durare dei mesi (o degli anni). Una volta però che si è deciso questo sapere resta sedimentato; in seguito a una ristrutturazione o a un’imbiancatura non sarà difficile rimettere i chiodi e riappenderli: il lavoro materiale in questo caso è ben poca cosa rispetto a ciò che abbiamo capito sulla loro disposizione e all’”istituzione” che abbiamo inaugurato.

(ora che ci penso questo mi fa venire in mente la nozione di “traccia istituita” di Derrida per richiamare l’idea che ogni movimento significante avviene a partire da una sorta di istituzione profonda e immotivata – la famosa archi-scrittura).

In entrambi i casi il vero nodo, la vera questione, è la produzione – e riproduzione – di un sapere condiviso ed il suo congelamento, la sua cristallizzazione in qualche sorta di “istituzione” . Questo sapere opera a vari livelli e si sedimenta come patrimonio comune di ogni comunità: la nostra capacità di muoverci nel Mondo dipende da esso e quando bisogna “ricominciare” emerge come il vero capitale che un gruppo possiede.

Questo spostamento di baricentro dal materiale all’immateriale e dal fisico al cognitivo opera ovviamente anche nel mondo del lavoro di oggi (produrre la nuova molecola di un farmaco è un’operazione compessa e costosa, ma la sua riproduzione ha dei costi marginali tendenti a zero).

Secondo frammento: quello che i bancari si urlano tra loro

Sono in banca a Rieti, per sistemare parecchie questioni riguardanti il mio mutuo, il nuovo conto, il bancomant, la banca online, la banca telefonica eccetera. La funzionaria è una persona molto competente e di esperienza (si vede) e ha libero accesso a tutti i sistemi gestionali della banca. Non c’è coda e siamo comodamente seduti nel suo ufficio. Tutto liscio, giusto? E invece no, perché di fronte a una serie di questioni specifiche la funzionaria non è in grado di andare avanti, ha dei dubbi sul sistema, sbaglia le opzioni.

A questo punto inizia un minuetto vocale con la collega della stanza a fianco (“Che faccio premo F3?” “Si, poi scegli l’opzione 2″, “Mi chiede il codice, ma è quello  del cliente?”, “No, è quello che appare nella schermata prima, torna indietro e segnatelo sul foglietto”). E così via per circa 10 minuti, urlandosi richieste e consigli da una stanza all’altra. E alla fine ne veniamo – ovviamente – a capo.

Ma la funzionaria ha ancora un dubbio e ad un certo punto si ricorda di una collega di Milano con cui ha lavorato  e che è “l’esperta” della Banca telefonica. La cerca al centralino e la chiama; dopo gli affettuosi saluti (“Quanto tempo!”, “Tutto bene?” eccetera), la collega le dà una serie di indicazioni sulle password della banca telefonica.

Tutto a posto dunque, ma riesaminiamo i fatti: quanti saperi sono entrati in gioco? Perlomeno 6:

- L’esperienza e il sapere pregressi della funzionaria
- Le procedure informatiche bancarie
- Le conoscenze della collega di stanza
- Lo scambio urlato di informazioni tra le colleghe
- La relazione pregressa della funzionaria con la collega di Milano
- Il sapere della collega di Milano

E probabilmente un sociologo del lavoro come si deve ne avrebbe trovati molti altri.

Attenzione a non fraintendere quello che è avvenuto: queste situazioni non sono un’eccezione, ma costituiscono la norma di ogni organizzazione sufficientemente complessa.  Non sono una stortura oraganizzativa, ma il modo in cui il sapere che fa funzionare l’azienda viene organizzato e distribuito attraverso canali non perfettamente codificato. Solo che sono talmente frequenti e pervasive che difficilmente ci si fa caso.

Naturalmente questa dinamica non è visibile guardando solo l’organizzazione formale: l’organizzazione formale è fatta dall’organigramma, dalle procedure informatiche codificate e dal ruolo codificato della funzionaria. Tutto il resto, formalmente, non esiste. E invece esiste, eccome. E quando l’ho fatto notare alla funzionaria ci abbiamo riso sopra.

E quando penserò a che cosa deve servire un progetto intranet mi ricorderò di questa situazione.

Terzo frammento: la premodernità della Sabina

La cosa probabilmente più difficile da assimilare andando a vivere in un paesino in mezzo alla campagna non ha a che fare con la – retorica – preoccupazione della solitudine o della lontananza e via discorrendo; il vero problema, nonché vero spartiacque rispetto alla città riguarda il modo con cui ci procuriamo le informazioni necessarie al nostro quotidiano. Dove troviamo un laboratorio di analisi? Chi ci può tagliare le siepi? E il ferramenta, il fabbro, il rivenditore di legna, il meccanico bravo, gli orari dell’autobus, le strade migliori, la pizzeria buona, un trattorista?

Certo, possiamo andare in esplorazione, ma ci accorgeremo ben presto che le informazioni sono nascoste, per non dire inesistenti. Certo, le informazioni ci sono,  ma sono per così dire, “appiccicate” alle persone del circondario. Sono loro che ci sanno consigliare.

Ora, secondo Antony Giddens una delle caratteristiche della modernità, e uno dei fattori di disaggregazione tipici del moderno, è la presenza pervasiva di sistemi esperti che garantiscono l’accesso a sistemi di sapere codificati indipendenti dai loro portatori: l’esempio più tipico è il medico di base, terminale ultimo di un sapere neutrale costituito da un sistema organizzato (università, ospedali, ASL, comunità scientifica) a cui il medico attinre. Ma anche un semplice orario dei bus, consultabile da chiunque, è un esempio di sistema esperto.

Giddens dice a riguardo: “I sistemi esperti sono meccanismi di disaggregazione perché – in comune con gli elementi simbolici – enucleano le relazioni sociali dalle immediatezze del contesto. Entrambi i tipi di meccanismi di disaggregazione presuppongono, e anzi favoriscono, la separazione del tempo dallo spazio come condizione della distanziazione spazio-temporale che essi promuovono.”

Capito? Andiamo dal medico di base, a prescindere dalla città, perché in ogni punto è garantito un unico accesso allo stesso sapere, mentre nella condizione premoderna tale accesso era molto più vincolato al contesto (il medico di Paese con il quale si sviluppava un rapporto personale di fiducia). Nei sistemi esperti la fiducia è posta più nelle regole generali di funzionamento che nelle singole persone.

Ora, le necessità di tornare a rivolgersi alle persone per avere delle informazioni fa della Sabina (e con essa tutte le zone non metropolitane italiane) una zona, nei termini di Giddens, attraversata da dinamiche premoderne.

Questo è molto interessante perché produce la necessità – a questo punto fisiologica – di un maggiore attaccamento alla comunità (o al proprio contesto di riferimento). Paradossalmente, in campagna è molto più difficile essere “eremiti” perché la necessità di sapere produce la necessità di relazione e la relazione produce coesione sociale.

Dopo che Sergio, il trattorista, mi ha sistemato la strada di accesso a casa gli ho detto che lo avrei pagato al più presto, il tempo di andare in banca. Mi ha risposto “Non c’è problema, ora sei dei nostri”.

E così, se nell’ambito di intranet si discute di come migliorare il publishing decentrato o come rendere attivi e partecipi gli autori, nell’ambito enterprise 2.0 si discute di come gestire e organizzare la massa di contributi che arriva da tutti i dipendenti. E una cosa piuttosto buffa, nel complesso, e che produce in entrambi i casi contributi di qualità.

Nel primo caso voglio segnalarvi un post di Jane McConnel che si intitola “7 principi per il publishing decentrato“, un articolo interessate per chiunque sia alle prese con una intranet a modello “redazione diffusa”. I 7 principi di Jane sono in sinstesi questi:

- Definire la responsabilità dei contenuti al più basso livello possibile in cui esista una reale responsabilità (va bene il capoufficio, non va bene lo smanettone occasionale)
- Distinguere tra responsabili del contenuto e responsabili del publishing
- Rendere visibile vicino al contenuto il suo content owner
- Definire diversi livelli di apporvazione dei contenuti sulla base delle specifiche esigenze delle business unit
- Evitare workflow troppo complessi
- Aiutare i content owners a decidere i livello di profilazione delle informazioni
- Definire un rappresentate intranet per ogni settore aziendale

Più o meno sullo stesso tema vale la pena segnalare anche  un articolo di Catherine Grenfell: “Come coinvolgere gli autori“. Catherine fornisce tanti consigli, e provo a sintetizzarli:

- Creare una comunità di pratica tra gli autori
- Sessioni di training guidato
- Tutoring temporaneo
- Ownership delle diverse business unit
- semplificare il processo di publishing
- Migliorare gli skill sul web writing
- Aggiornare gli autori sulle best practice interne
- Fornire template e tools predefiniti
- Creare un supproto ad hoc
- Definire ed esplicitare il modello di governance
- Monitorare costantemente il lavoro dei publisher
- Creare un centro di risorse online
- Usare scenari e personas nelle decisioni di redesign
- Premiare i contributori migliori
- Fare intervenire i capi qualche volta

Infine ecco un altro articolo di Toby ward dedicato ai modelli di governance distribuita della intranet.

Ok, sembrerebbe tutto a posto, se non fosse che queste sono soluzioni all’interno di uno specifico paradigma, ovvero quello che recita, più o meno: “la intranet è uno spazio web gestito da una redazione diffusa”.

All’interno del paradigma “enterprise 2.0″ la musica cambia, perché la intranet diventa uno spazio aperto ai contributi di tutti. E cambiano di consegue3nza anche i problemi da affrontare. Per esempio Jacob Morgan riflette su come segmentare i contributi che arrivano da migliaia di dipendenti in un’organizzazione (geograficamente? Per temi? Per dipartimento?) e Bill Ives risponde in una logica di puro SaaS: “lasciamo che i dipendenti si clusterizzino da soli sulla base degli interessi e progetti e affinità trasversali. Su tutto domina una rilfessione globale sul rapporto tra collaborazione, cultura organizzative e tecnologie a supporto, ben espresso in questo post.

E’ ovvio che tutte queste riflessioni sono corrette relativamente al proprio paradigma di riferimento, e trasportate in un altro non diventano false: semplicemente, perdono di senso.

Le funzionalità e l’interfaccia, ovviamente, scimmiottano un po’ i social network mainstream, ma nel complesso è interessante. C’è qualcuno che vuole fare una prova un po’ più intensiva con un gruppo di colleghi un po’ numeroso? Sarebbe interessante…

Vi segnalo in particolare questa presentazione perché mostra in modo concreto e chiaro il possibile utilizzo di un social network tramite mobile devices. Vi consiglio di guardare in particolare le slide dalla numero 5 alla numero 16, perché sono davvero illuminanti.

Credo che dovremmo cominciare a pensare a questa dimensione del mobile fin dall’inizio di progetti del genere, per non rischiare di ritrovarci in seguito a inseguire esigenze che sono – loro – molto più avanti della nostra capacità di soddisfarle.

James robertson ne identifica 7:

- per evidenziare le news

- per far accedere alla navigazione interna

- per evidenziare le applicazioni chiave

- per evidenziare informazioni-chiave

- per promuovere la cultura interna

- per il marketing interno

- per gli strumenti di collaboration

Riporta poi un esempio per ogni ruolo (di seguito ne riporto due):

Trovo le osservazioni dell’articolo molto corrette, ma credo si sia dimenticato di un ulteriore ruolo, ovvero quello di collettore dei contributi che arrivano dalle community: la home page può infatti ospitare in automatico le ultime cose prodotte all’interno dei diversi spazi di condivisione.

Omettere questo ruolo significa dimenticarsi che la intranet si regge anche su una serie di funzionalità di condivisione e collaborazione che è bene evidenziare in quanto comportamento emergente.

On no?

I primi sistemi erano certamente rozzi: cassette e spazi dove inserire il proprio foglietto. Che cosa non andava? Beh, è abbastanza facile da intuire: nessuna feedback, nessuna possibilità di interazione tra i produttori, nessuna catalogazione, localizzazione definita eccetera.

L’arrivo del web, e del web 2.0 ha permesso di realizzare delle applicazioni molto interessanti proprio dedicate a questo: io stesso ne ho realizzata una nel 2003 usando tecnologie abbastanza grezze (in realtà poco più che un forum). Sotto potete vedere lo screenshot: non era certo la cosa più “cool” della Terra, ma ha funzionato ed era quello che potevamo permetterci sotto tanti punti di vista:

Ora per fortuna le cose sono cambiate in meglio, ma il tema resta lo stesso, ed è cruciale: perché le idee sono dappertutto, perché le persone elaborano continuamente idee e ipotesi sulle cose che maneggiano quotidianamente nei loro luoghi di lavoro, perché il tema del cambiare è all’ordine del giorno in tutte le organizzazioni, perché la visibilità dei propri contributi è una moneta rara e perché non c’è nulla di più naturale che provare a pensare “e se si facesse così”?

Alcune idee sono solo bozze, altre sono immegini visionarie, altre sono frutto di paziende lavoro individuale ossessivo per migliorare un’ipotesi, altre sono nell’ordine naturale delle cose e aspettano solo una spinta per essere realizzate.

Qualche settimana fa Bill Ives ha pubblicato un bel caso di studio dedicato proprio a questo, raccontando il caso dell’applicazione “brainstorm” (nome non molto originale a dire il vero) realizzata da Intuit, un’azienda di 500 persone che opera nel web.

Gli screenshot sono molto interessanti (e potete misurare la distanza dalla “povera” applicazione che realizzai io 6 anni fa):

L’applicazione è molto interessante, a parte la gradevolezza grafica e l’interfaccia estremamente user friendly: le persone possono inserire idee, commentarle, taggarle, iscriversi ai tag, vedere idee affini ecc.

Forse manca solo l’opzione “diventa sponsor dell’idea” che è un’opzione che mi solletica assai: trasformare il “like” in qualcosa di più, ovvero nella potenziale disponibilità fare qualcosa per questa idea.

Ese poi diamo un limite a queste sponsorizzazioni individuali tutto ciò si trasformerebbe anche in un buon prediciton market, giusto?