Home » Archivi per collaboration

Mar
15

Le 3 velocità della collaborazione in azienda

Quando si parla di collaborazione in azienda si rischia sempre di fare un po’ di confusione tra livelli, strumenti e significati diversi. Dopo tutto si collabora parlando, telefonando, passandosi documenti, e in tanti tanti altri modi. E per questo parlare di “strumenti di collaborazione” o di “intranet collaborativa” rischia spesso di confondere ciò che dovrebbe invece contribuire a chiarire.

Ora, in genere si riconsoce un buon modello esplicativo quando non solo riesce ad illuminare in modo chiaro pezzi di realtà, ma anche quando riesce a farlo in modo elegante e possibilimente semplice. E il modello delle tre velocità, proposto da Davide “folletto” Casali (lo ha proposto per la prima volta nel libro curato da Hugo Messer) ha proprio questo pregio.

Il modello, in sintesi è questo: la collaborazione in ogni organizzazione avviene *sempre* (e questo è importante) su tre piani diversi, corrispondenti a 3 diverse “velocità”:

  • collaborazione realtime;
  • collaborazione asincrona;
  • collaborazione “documentale” (se così posso tradurre “storage”).

Questi tre livelli sono presenti in ogni ambito che preveda collaborazione, e vengono “agiti” di volta in volta con strumenti più o meno adeguati (a partire dalle triade infernale telefono – email – dischi di rete).

Davide ne elenca diversi (da Hangout a Yammer, da Sharepoint a WordPress) ed il pregio del modello è proprio quello di poter collocare in modo funzionalmente corretto un buon numero di soluzioni che oggi affollano il mercato e vangono frettolosamente classificate sotto il termine-ombrello di “strumento per la collaborazione”.

Ancora più interessanti sono a mio modo di vedere alcuni principi strategici che Davide elenca e che dovrebbero essere cultura comune per ogni progettista di ambienti di collabroazione interni:

  1. Una strategia di collaborazione deve sempre affrontare tutti e tre i livelli (e nessun tool è in grado da solo di affrontmarli tuti e tre).
  2. E’ bene non mettere in compitizione più strumenti per lo stesso livello (ad esempio Skype e Hangout, tanto per dire).
  3. E’ importante permettere forme di integrazione tra gli strumenti ai diversi livelli.

Interesante vero? Ecco la presentazione di Davide che, oltre al suo articolo sul tema, permette di approfondire meglio la questione.

Buona lettura (e buona collaborazione).

Feb
22

Gli incentivi aziendali e il problema della candela

Consiglio a tutti di mettersi comodi e di guastarsi questo intervento di Daniel Pink alle TED confercence. Qualcosa di fa-vo-lo-so. In 18 minuti Dan ci spiega perché gli incentivi economici e, più in generale, gli incentivi “esterni” non siano più adatti a garantire l’eccellenza nelle prestazioni lavorative del 21° secolo.

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.

Feb
2

Una manciata di link su collaborazione, ruolo di H.r. microblogging interno, community management e molto altro

Vi segnalo un po’ di link interessanti in ordine sparso: riguardano argomenti un po’ disparati (e-learning, collaborazione, ruolo di h.r. ecc)  ma sempre legati al tema centrale di questo blog.

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.

Google Analytics - 1/1/2008 to 12/31/2008

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.

RH 2.0   HR 2.0

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

Employee_Engagement_This_is_how_it_is2

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 :-)

Gen
29

Portare la nuvola in azienda: il mio intervento al Kublaicamp

Vi segnalo la presentazione che farò domani pomeriggio al Kublaicamp (mi hanno un po’ tirato in mezzo, ma va bene, se non non andrei mai da nessuna parte). Il tema della sessione è  molto interessante: “Lavorare sulla nuvola“.

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ì?

Gen
28

Dai canali alle piattaforme. La buccia di banana delle notifiche

C’è un tema che attraversa trasversalmente tutti i progetti di collaboration aziendale e che, spesso cacciato dalla porta, rientra dalla finestra sotto forma di lamenti, mugugni, ostilità latenti. Si tratta del tormentato rapporto con le email, ovvero con il più tirannico, pervasivo, usato e abusato strumento di comunicazione inventato dall’uomo.

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.

Gen
21

Dal team alla community. E ritorno

Gli articoli di Oscar Berg sono sempre molto interessanti (Oscar è uno svedese che si occupa di enterprise 2.0 e ha lavorato anche per l’IKEA) e come al solito anche gli schemi fanno la differenza.

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”.

Gen
2

Far entrare i blog interni nel flusso di lavoro

Come ho detto in altre occasioni, i blog interni possono essere essere un’ottima occasione per mettere alla prova dei progetti, testare le beta-versioni,  condividere l’avanzamento di un progetto con i destinatari, ricevere feed-back. Qualche tempo fa ho anche postato quello che a mio parare era un’ottimo caso di studio a riguardo.

Oggi vedo che quest’idea di utilizzo dei blog interni ha trovato altri sostenitori, in particolare Patric Walsh, che ha scritto un altro caso di studio riportando un’esperienza simile. La sua idea è chiara: le ricerche sugli utenti coprono mediamente la fase che viene prima della progettazione, mentre i test di usabilità coprono la fase che viene dopo la progettazione. I blog interni possono agevolmente coprire tutto ciò che avviene durante la progettazione (e questo utilizzo dei social media per coprire fasi che stanno “nel flusso” di lavoro delle persone mi appassiona particolarmente) . In questo modo, grazie alla triade:

1) user research

2) blog di progetto

3) test di usabilità

abbiamo la possibilità di raggiungere un pieno coinvolgimento di tutti in tutte le fasi del progetto.

Aggiungo anche che, dato che in genere questi progetti toccano la vita lavorativa delle persone, il coinvogimento e la partecipazione all’interno dei blog non hanno bisogno di essere “pompati” artificialmente: le persone partecipano perché sanno che il loro contributo è anche un contributo all miglioramento della loro vita lavorativa.

Set
20

Forza e debolezza nei legami aziendali

Ok, ecomi qui. Non credo di essermi ancora ripreso da questa ripresa lavorativa. Il rientro mi è venuto addosso schiaffegiandomi ripetutamente; cosa che avevo ampiamente previsto, del resto, e ciò costituisce certo una magra consolazione dato che tale puntale previsione è servita unicamente a tormentare sottilmente le mie ferie senza peraltro proteggermi dall’inevitabile.

E così, mentre dalla mia camera d’albergo a Mestre, in attesa del prossimo corso da tenere, rifletto sulle tante variabili da trasformare in costanti attraverso il sapiente lavorio e la paziente pianificazione, mentre il trasloco nella mia nuova casa incombe con le sue innumerevoli necessità, mentre il pensiero sugli anni che passano e su quanto le abitudini si siano trasformate in una sorta di destino senza aura alcuna – quall’aura che tutte le cose avevano prima di trasformarsi in cose, – mentre questo pensiero diventa sempre più segreto, e illegittimo (ok, adesso finisco la frase, ve lo prometto, ma ho giurato a Philiph Roth che gli avrei fatto un omaggio, e questa era l’occasione, grazie Philiph anche se so bene che non potrò mai competere con le tue sublimi subordinate), insomma in tutto questo tiraemmolla tra meccanica e desiderio (e desideri meccanici) mi torna in mente che una delle soddisfazioni più grandi di questa estate è stato aver finito – in tre giorni – La voce e il fenomeno di Derrida, riuscendo anche a seguire per la gran parte il filo del ragionamento. In realtà è stato un regalo che ho voluto fare al ragazzo che ero.

Ora, per non lasciare che questo post di rientro deragli fatalmente, voglio segnalarvi una cosa a mio parere interessante che riguarda i processi di collaborazione e che ho pescato grazie all’ultimo report di Nielsen dedicato, guarda un po’, ai social network interni.

Nielsen cita un video di Andrew Mcafee nel quale il professiore distingue 4 situazioni possibili relativamente ai lagami tra dipendenti all’interno dell’organizzazione. McAfee distingue tra legami forti (i colleghi di stanza, il capo, il team ecc), legami deboli (progetti occasionali, rapporti saltuari ecc), legami potenziali (legami ancora non presenti che che potrebbero svilupparsi) e assenza di legami, identificando per  ciascuna situazione degli strumenti tipici (anche se credo ci siano, su questo punto, ampie sovrapposizioni e integrazioni possibili).

Ho schematizzato la cosa in questo disegno (ripreso dal video)

legami_professionali

Trovo questa distinzione molto intelligente ma soprattutto molto utile nell’identificare il campo di lavoro possible all’interno delle aziende. Spesso nei progetti intranet di nuova generazione si hanno in mente cose diverse quando si discute di “collaborazione”, e questo avviene perché si ha in mente uno specifico tipo di legami da supportare.

Perché è ovvio che nelle organizzazioni sono sempre presenti *tutte* queste situazioni, ma  per realizzare degli obiettivi specifici dobiamo sempre capire a chi ci rivolgiamo e – soprattutto – ipotizzare come si comporterà in una data situazione.

Per inciso, rilevo che questa distinzione non si sovrappone a quella di “Comunità di pratica” di E. Wenger: una comunià di pratica può infatti avere legami forti, deboli, potenziali e anche, paradossalmente, conservare “in figura” anche un’assenza di legami (ad esempio il gruppo di operatori che “non ha mai visto la dirigenza”).

ok, eccovi il video.

Lug
28

Non tutti i contenuti sono uguali

Una decina di giorni fa Mark Morrell (l’intranet manager di BT, che è un’azienda di  110.000 persone), ha pubblicato un post molto interessante, a mio parere più acuto e profondo di quanto l’autore stesso possa aver immaginato (non lo dico per offendere Mark, ovviamente, ma per provare ancora una volta che il testo ha sempre una sua autonomia rispetto all’autore, in accordo con il buon Paul Ricoeur).

E insomma, il post prova a classificare il tipo di contenuti che possono trovarsi su di una intranet “evoluta”, vedendoli dal punto di  vista sia del loro “statuto” che dei loro modi di produzione. Mark riferisce in specifico questa classificazione alla situazione interna a BT, ma credo che il modello abbia una sua universalità di fondo e si presti in modo molto plastico ad una serie di ragionamenti collaterali a mio modo di vedere assai interessanti (per inciso, credo che questa versatilità immaginativa sia il segno, in genere, delle classificazioni ben riuscite).

Mark divide i contenuti in:

Ufficiali, ovvero prodotti da una redazione, o anche da referenti di una ipotetica redazione allargata

Di team, ovvero prodotti all’interno di gruppi di lavoro più o meno chiusi e in ogni caso con un perimetro di visibilità ben definito e con scopi legati alla produzione “dentro il flusso dell’operatività”

Crowd, ovvero prodotto all’interno della più ampia comunità aziendale, all’interno di spazi e piattaforme di condivisione pubbliche, quali ad esempio un forum tecnico, una bacheca, uno spazio di social networking

Personali, ovvero prodotti da singole persone dell’azienda, ad esempio tramite un blog personale.

Ho provato a elencare questo tipo di contenuti nello schema seguente:

Schema tipi di contenuti intranet

Come vedete la classificazione consente di ospitare agevolmente buona parte dei tipici contenuti e progetti intranet. Il suo pregio, inoltre, risiede nel non confinare uno strumento ad un solo tipo di classificaizone: un wiki può essere di tema o crowd a seconda degli scopi e del “patto” che lo strumento riassume nell’organizzazione.

In questo contesto ci si può anche divertire a tracciare diversi scenari per le diverse proporzioni che tali insieme di contenuti possono avere in una intranet

Ad esempio, una intranet totalmente dominata dai contenuti ufficiali (queste sono le intranet per le quali che in genere viene chiesto oggi il mio intervento):

Intranet dominata dai contenuti ufficiali

Ecco ora una intranet con primi segni di apertura verso altri tipi di contenuti , anche se ancora timidamente. In questo caso ho ipotizzato che i contenuti di team si affaccino per primi, perché sono i maggiormente controllabili e quelli meglio vendibili internamente per giustificare la spesa

contenuti2b

Ed ecco invece una intranet nella quale i contenuti di team la fanno da padroni, con un’apertura verso contenuti crowd e contenuti personali. Queste sono le intranet costruite maggiormente attorno ad alcuni processi operativi che vengono supportati con spazi online (per inciso: in questi si usa spesso MOSS).

contenuti3

Ecco infine una intranet dominata da contenuti crowd, ad esempio in progetti di Knowledge management o applicazioni di social networking estese ecc.

Schema intranet dominata da contenuti crowd

Naturalmente, come tutte le classificazioni, anche questa presenta delle strane intersezioni empiriche un po’ paradossali, ma la cui paradossalità, paradossalmente, aiuta a capire meglio la natura degli oggetti che abbiamo a disposizione.

Qualche esempio:

– Il blog dell’Amministratore Delegato è personale o ufficiale?

– Se un team di lavoro si allarga in modo consistente ad altri partecipanti legati professionalmente, lo spazio è ancora di team o diventa crowd?

– Se nel social network interni sono presenti informazioni aziendali prese dai sistemi ufficiali, il sistema è crowd o ufficiale?

Insomma, le strane sovrapposizioni possibili sono molte, ma questo – ripeto – non è necessariamente un difetto.

Concludo con una domanda: riuscite a disegnare la intranet della vostra azienda sulla base di questa classificazione?

Lug
26

Segnalazioni su collaborazione, conoscenza e altre amenità

Ecco un po’ di segnalazioni in ordine sparso di articoli, post e interventi su diversi aspetti collegati al tema delle intranet e della collaborazione (ne ho tantissime, questa è solo una prima parte)

L’enterprise 2.0 va bene solo per i wkowledge worker? Un bell’articolo che spiega come diversi tipi di strumento e diversi tipi di iniziative possano, a diverso titolo, riguardare tutta l’organizzazione e non solo le èlite interne.

spectrum of social software participation

Otto buone ragioni di business per adottare una intranet. Un bell’articolo e un bello schema riassuntivo

CIBA intranet model

Esiste qualcosa come “il miglior CMS per il mio settore merceologico”?. Un bell’articolo di Tony Byrne prova a spiegare perché questa è una domanda fuori luogo. Le specifiche di un CMS hanno un rapporto solo marginale con il tipo di attività e di prodotti dell’azienda, e ne hanno uno molto più stretto con i processi interni della specifica organizzazione.

44 guiedline per la vostra intranet. Senza pretese, un articoletto con un po’ di punti chiave da tenere a mente.

– I punti di contatto tra Enterprise 2.0 e Enterprise content Management. Oscar Berg prova ad affrontare una questione che emerge sempre più potentemente all’interno del discorso teorico sull’adozione di questi strumenti

– Quando usare i PDF e quando i form in una intranet. Un bell’articolo che spiega come impostare un uso sostenibile dei (tanti) PDF che affollano le nostre intranet.

– Enterprise 2.0 come volano. La metafora del volano applicata ai progetti enterprise 2.0. E’ citato anche il caso della Toyota (ma è di qualche anno fa) con tanto di PDF.

– Quando l’1.5 è meglio del 2.0. Un post che prova a problematizzare la tematica dei contenuti generati dagli utenti. A volte una forma di supervisione e di controllo è assolutamente necessaria. E questo è un tema davvero pertinente per tutti i progetti interni.

Buona lettura.

:-)

Giu
26

Altre risorse sui wiki interni

Recentemente Matthew C. Clarke ha pubblicato su Boxes and Arrows un bel caso di studio che raconta il loro percorso di adozione dei wiki interni nella sua società, la Corvu.  Stiamo parlando di migliaia di persone che si occupano di Software per aziende (performance management).

Il loro problema era trovare un sistema per ottimizzare la redazione di documentazione tecnica che poi viene rilasciata al cliente, su ciascuno dei prodotti commercializzati così come sui prodotti in fase di sviluppo.

L’articolo si intitola significativamente Control and Community: A Case Study of Enterprise Wiki Usage, e vi consiglio caldamente una lettura attenta, perché entra nel merito di molte questioni concrete quali i permessi, le revisioni, il controllo, le motivazioni individuali che stanno dietro ad un progetto collaborativo di questo tipo.

Wiki Workflow Diagram

Segnalo solo alcuni spunti:

  • Il senso di appartenenza come veicolo per una anarchia sostenibile nei wiki pubblici
  • La moderazione come elemento importante nei wiki aziendali, per gestire l’alto numero dei contributori che spesso non hanno vincoli reciproci
  • La necessità nei wiki interni di gestire le risorse centralmente, evitando il proliferare di wiki autonomi di singoli settori (questo è un problema loro; in Italia, ma quando mai?)
  • Il vantaggio di creare una navigazione familiare e comprensibile (nel loro caso era l’elenco dei prodotti)
  • L’opportunità di segnalare in evidenza chi è l’autore primario della singola pagina, ovvero il creatore
  • in alcuni casi la necessita di avere pagine che solo un gruppo scrive (nel loro caso gli ingegneri di Ricerca & sviluppo) e gli altri possono solo commentare
  • La ricerca costante di sponsorship al più alto livello possibile
  • Lavorare con i champions
  • Identificare le persone-chiave che devono contribuire dando cose di qualità e dando anche autorevolezza allo spazio
  • Nel loro caso, l’importanza di coinvolgere dei revisori finali del materiale che poi va in mano ai clienti
  • L’importanza dell’integrazione con LDAP e del single sign-on
  • Ovviamente le funzionalità WYSIWYG
  • La possibilità di aggiungere allegati documentali alle pagine
  • L’importanza della creazione di una massa critica di contributori e di contenuti
  • L’importanza di imparare a spedirsi link invece di contenuti. Se qualcuno chiede qualcosa via mail la persona risponde creando una pagina wiki e poi mandando il link

Insomma, leggetevi l’articolo perché nel vale la pena.

Risorse Wiki

Steward Mader elenca una serie di prodotti per enterprise wiki che rispettano i requisiti necessari per creare wiki in azienda. Il problema è che sono tutti proprietari. A parte uno, ovvero  Mindtouch – Deki, l’unico prodotto distribuito anche in open source e che è abbastanza solido (per Mader) per le necessità aziendali.

Andatevi comunque a leggere la scheda dedicata a Mindtouch su Wikimatrix.

Altri articoli interessanti (tutti tratti da FutureChanges)

E per finire…

una bella presentazione su Slideshare dedicata al progetto wiki della John Hopkins University

Apr
28

Enterprise 2.0 in salsa svedese

La premiata coppia Oscar Berg / Henrik Gustafsson, che si occupano di Enterprise 2.0 in quel di Svezia (e hanno un ricchissimo blog) , hanno pubblicato una presentazione molto bella sull’Enterprise 2.0. Gli schemi, in particolare, sono assai efficaci, e sappiamo quanto conti l’aspetto di visual design per la comprensione dei concetti, dai più astratti ai più legati all’esperienza.

P.S. Aahh, quanto tempo era che volevo fare un titolo con “..in salsa qalche cosa”, come nelle migliori pubblicazioni geek di casa nostra  :-)

Mar
17

Risorse per smanettoni

Come al solito Cristiano mi passa sempre delle risorse interessanti. Quest’utlima, tratta dal noto Boxesandarows, affronta il tema delle interfacce e della User experience negli ambienti di collaborazione 2.0.

L’autore (Mattew C. Clarke) ammette che ad oggi non esistono indicazioni precise, e che il suo è solo un contributo ad un dibattito in corso, ma il tema è interessante (e controverso), perché dalla soluzione di questo dibattito dipenderà la costruzione di ambienti veramente performanti per la collaborazione online tra colleghi e gruppi di lavoro.

I suoi consigli finali sull’uso di metafore coerenti, sull’architettura aperta delle applicazioni, sull’uso massiccio di script dinamici e su una focalizzazione spinta sui meccanismi di recupero della “storia” della collaborazione possono essere presi come indicazioni-quadro per lo sviluppo delle prossime interfacce collaborative.

Ma la cosa interessante dell’articolo, che Mattew dà per scontata ma che scontata non è (almeno per me), sono i suoi riferimenti a risorse e directory online verso strumenti di colalboration e CMS vari.

CMS Matrix. Questa la conoscenvo anche io: la più completa directory di CMS, con possibilità di fltraggio sulle singole caratteristiche. Da studiare attentamente prima di comprare qualunque cosa, MOSS in primis.

La directory di Capterra, che elenca quasi 200 applicazioni per la collaboration, sia web based che da scaricare. E c’è veramente dei tutto: action planning, brainstorming, cooperative Writing, document Management, calendari, task Management…

Beh, buon lavoro a tutti!

p.s. già che ci siamo, qualcuno ha provato Kentico?

Mag
21

Segnalazioni

Non provate a bollire l’oceano (di contenuti) – by Column two

Le intranet non sono una discarica di informazioni – By Gerry McGovern

Il ROI dell’instant messaging in intranet: il caso IBM – By John mell via Emanuele

Team collaboration: 7 punti fermi per lavorare meglio insieme – By Robin Good

Wiki in azienda: il caso di designcommission – By Pbwiki

Il colore delle liste di link in intranet – By Jacob Nielsen

Mar
25

Risorse per collaborare

Raramente segnalo software e applicazioni, anche se mi capita di navigare alla ricerca di particolari soluzioni “tampone” a problemi intranet. Voglio segnalarvi due risorse che ho imparato ad apprezzare nel tempo.

La prima è la sezione Collaborazione online” del noto blogger con la mutanda in testa: sfogliando nell’archivio troverete moltissimi servizi online e softwarini utili per chat, videoconferenze, condivisione risorse, documentazione condivisa, didattica, wiki e tanti altri task legati alla collaborazione. L’aspetto lo penalizza, ma se navigate in archivio troverete un tesoro di segnalazioni.

La seconda risorsa e la sezione “productivity” del noto blogger-segnalatore-compulsivo (scherzo): anche qui, scorrendo in archivio, tantissime segnalazioni utili. A parte gli scherzi, MastroAlberto è veramente un grande…

Ehi, adesso non avete veramente più scuse per collaborare…

Gen
16

Segnalazioni spiripille

Silvano Tagliagambe, filosofo della scienza, ha scritto una bella recensione del libro di Yochai Benkler “La ricchezza della rete. La produzione sociale trasforma il mercato e aumenta le libertà”. Interessante l’accostamento tra Thomas kunh e Etienne Weger.

Qualche cambiamento in arrivo nelle regole di design dei siti web: sembra che l’uso intensivo dei motori di ricerca e dei social media abbia cambiato le proporzioni ideali che nelle pagine web dovrebbero essere assegnate a navigazione, identità del sito e contenuti, sbilanciando la percentuale verso i primi a scapito degli ultimi. Lo afferma Jupiter research (via Punto informatico).

Tanto per rendersi ancora più simpatica, Microsoft crea il software che controllerà tutto quello che facciamo in ufficio, ci misurerà la pressione e calcolerà il nostro livello di appagamento. Questa si che è ua vera Killer application. Già ribattezzata “Grandissimo fratello” (via Visionpost).

Interessante l’ultimo post di di A. Mcaafe, dedicato all’uso operativo/meditativo degli strumenti collaborativi in azienda. Secondo Andrew, che cita il recente blog Trasparent Office, strumenti come i wiki sono usati oggi solo se entrano nel “flusso operativo” delle attività. In caso contrario le persone non li usano. Il problema, ovviamente è definire che cos’è “flusso operativo”. La soluzione di Andrew è abbastanza semplice: perché non fare entrare “a forza” i comportamenti collaborativi nel flusso quotidiano delle persone, magari inserendo la collaoraizone e l’uso degli strumenti tra gli obiettivi individuali? Una soluzone drastica, che dite?

E per finire in bellezza, facciamoci un giro sul blog italiano dedicato a ChucK Norris. Quando qualche anno fa, nella mia ingenuità mediatica, vedevo il famigerato telefilm “Walker Texas Ranger”, alle 8 di sera, inorridivo e mi dicevo che tutta quella violenza contrabbandata come semplice modalità di relazione tra gli esseri umani , quell’universo puerile fatto di cattivoni e difensori della egge non avrebbe portato nulla di buono e avrebbe corrotto le menti. Beh, fortunatamente mi sbagliavo: oltre un cerrto livello, la stupidità prodiuce i suoi anticorpi e le persone sono molto più consapvoli dei meccanismi narrativi usati dai media di quanto gli intelletuali siano disposti ad ammettere. Meno male.

Ott
26

(auto)organizzare la collaborazione

Sempre per la serie “vecchi articoli dimenticati nei bookmark” ecco un bel post di Dave Pollard dedicato alle strategie di collaborazione e all’introduzione di metodi 2.0 nelle aziende.

il metodo è interessante per vari aspetti:

1) identifica come strategica la creazione di figure di “animatori” (i champions) che possano far crescere viralmente il modello di collaborazione aperto

2) Richiede meccanismi di auto-organizzazione e non di governo dall’alto

3) Fa leva sull’entusiasmo, le passioni e le competenze individuali, da mettere in gioco fin da subito.

Modello_collaborazione_2.0

Ecco il post completo con l’illustrazione della metodologia.

Ott
16

Collaborare o condividere? Problemi (quasi) filosofici

Si ha un bel dire sull’importanza di collaborare, di condividere la conoscenza, di favorire la partecipazione. Queste cose che ho elencato non sono sinonimi: proviamo a fare un passo avanti e guardare meglio la questione.

Mettiamo che creiate un gruppo su Lotusnotes, o un teamsite su Sharepoit, o un team di progetto su yoo+, o anche un gruppo chiuso su google gruppi. Avete creato uno spazio di collaborazione per un gruppo ristretto di persone, all’interno dell’organizzazione. Ora moltiplicate questa operazione per 10, 100, 1000 gruppi: avete ottenuto una frammentazione dell’organizzazione in cluster di interesse, o in gruppi di lavoro.

Ma, nel contempo, avete anche creato dei silos funzionali, (anche se informali) che non permettono alla conoscenza di fluire in modo fluido tra i diversi gruppi.

Ma questa conoscenza può veramente fluire?

Questo è un tema interessante (uno dei più interessanti degli ultimi tempi su questo tema, a dire il vero, ovvero: quanto la collaborazione è un ostacolo alla condivisione?

Detto in altre parole: quanto è necessario un contesto per permettere ad una conoscenza di circolare? E’ ovvio che un documento o un’informazione hanno una loro storia, legata ad un contesto di scambi tra un gruppo: al di fuori di questo contesto non assumono particolare rilevanza. Se quindi prendo un documento elaborato all’interno di un teamsite e lo porto “fuori”, a disposizione di tutti, l’informazione diventa insufficiente e poco significativa.

Insomma, mentre all’interno dei gruppi si produce in gran parte conscenza tacita, difficilmente trasportabile, negli spazi aperti (ad esempio uno spazio per la modulistica o per la manualistica) si condivide conoscenza esplicita, facilmente decontestualizzabile, ma che non ha una storia di collaborazione alle spalle (almeno in forma visibile). Sembra quindi che il grado di collaborazione sia inversamente proporzionale al grado di condivisione possibile: se le informazioni hanno una storia e un contesto, questa storia diventa un insieme denso e non esplicitabile facilmente.

Quali sono le soluzioni a questo problema? Il dibattito è aperto, e io posso solo dare il mio punto di vista.

I gruppi che elaborano conoscenza tacita sono sempre esistiti, e la creazione di gruppi chiusi non fa che prendere atto di questa situazione, fornendo un ambiente adatto alla collaborazione. Ma, allo stesso tempo esistono pratiche di confine che sono quelle che permettono ai gruppi di apprendere al loro interno e di trasportare conoscenza all’esterno. Esiste sempre la figura che connette, che passa da un gruppo all’altro, l’innovatore, colui che frequenta i “confini” delle comunità. Sono queste figure che fanno da ponte cognitivo alle conoscenze prodotte localmente (Mario che arriva nel suo gruppo in ufficio e dice: ehi, quelli del piano di sotto stanno portando avanti una cosa fichissima. Potrebbe esserci utile. Dopo vado dal mio amico che lavora lì e mi faccio spiegare meglio….).

In una intranet che si rispetti dovrebbero convivere queste diverse pratiche legate alla conoscenza: gruppi chiusi che producono collaborazione e conoscenza tacita e contestuale, gruppi aperti che permettono alla conoscena esplicita di circolare (pensiamo ad un forum interno sui problemi di Excel: in questo caso la conoscneza è meno contentuale), e infine, una pratica di “lavoro sui confini” che permette a diverse figure una partecipazione periferica ai diversi gruppi chiusi, in modo da poter fare da ponti cognitivi.

Inoltre non è detto che le conoscenze tacite e contestuali derivate dalla collaborazione non possano, ad un certo punto, trasformarsi in conoscenze esplicite: alcuni prodotti finali possono essere messi a disposizione di tutti poiché hanno raggiunto un livello di esplicitazione tale da poter essere condivise. In questo caso la collaboraizone diventa una sorta di incubatore contestuale per la condivisione.

Di tutto questo (o quasi) si discute in questo articolo, pubblicato da StepTwo.

Buona lettura (e buona riflesisone).

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