Home » Archivi per gennaio 2010

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
29

Tecniche per far fallire il blog interno dell’AD

In un interessante post il blog Intranet matter riporta un caso di studio relativo al fallimento di un progetto di blogging interno per i manager di un’azienda (non si sa molto di più). E’ molto interessante la lista di errori fatti in quell’occasione, perché ci dice molto sulla progettazione di queste iniziative e su quanto tali progetti procedano sempre su una lama di rasoio.

Ecco la lista degli errori evidenziati (leggete bene che c’è da ridere):

  • presumere che il progetto funzionerà a prescindere (ehi, dopo tutto, è roba web 2.0…);
  • predisporre un solo blog per tutti i manager aziendali (in modo da ostacolare il tratto personale del blog);
  • permettere commenti anonimi dei dipendenti in un ambiente potenzialmente esplosivo;
  • non rispondere ai temi negativi emergenti nei commenti critici (in modo da assicurarsi che riemergeranno ancora e ancora);
  • non spiegare ai manager come usare lo strumento al meglio;
  • dire ai manager che non è un problema si il settore Comunicazione scrive i post al posto loro (assicurandosi così perdita di spontaneità e autenticità);
  • non cambiare rotta quando si vede che la cosa non funziona, ma lasciarla morire per conto proprio in silenzio (così da partire col piede giusto quando mai si penserà ad un’iniziativa analoga);

La lista fa abbastanza sorridere, se non fosse che è tutto vero. Aggiungo alla lista qualche altro errore basato sulla mia esperienza:

  • pensare che il blog sia fatto di un post solo, o di una comunicazione all’anno;
  • ragionare in termini di marketing, scrivendo cose con 600 punti esclamativi, minando la credibilità del tutto
  • obbligare le persone a commentare (capita anche questo)
  • selezionare i commenti e pubblicare solo quelli positivi
  • pubblicare solo cose positive dell’azienda e non temi “caldi” o problematici.

Ecco –  lo dico ai manager nostrani –  se dovete fare un blog interno con queste premesse,  potete anche evitarvi questa fatica. Sono blog, non pozioni magiche.

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
27

Enterprise microblogging matrix (by Pistachio)

Non so perché ma credevo di averla già segnalata. Si tratta di una ricerca di Pistachio consulting dedicata ad alcuni tool per il microblogging interno.

Pistachio ha creato una matrice di comparazione molto interessante, e di alcune applicazioni non ne avevo minimamente sentito parlare.

Potete scaricare tutto il report da qui.

Oppure leggerlo su Scribd.

Enterprise Micro Sharing Tools Comparison 11032008

Gen
25

Supportare i team virtuali? Non è un gioco.

Quando pensiamo ad intranet non dobbiamo immaginare uno spazio monolitico con certe funzionalità definite e un tipo predeterminato di utilizzo: dobbiamo invece pensare ad uno spazio polifunzionale, che supporta diversi attori durante la giornata; attori che, in momenti diversi possono avere ruoli e bisogni differenti.

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:

grafico tecnologie usate a supproto dei team virtuali

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.

Gen
25

Intranet o enterprise 2.0? Guarda la governance e lo saprai

Man mano che passa il tempo mi si fa sempre più chiara la differenza tra i progetti intranet ed enterprise 2.0. In genere mi capita di collaborare ad entrambi e capisco sempre di più che le differenze riguardano – ovviamente – meno gli strumenti che i modelli di governance sottostanti (ne ho già parlato più sotto, comunque).

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 .

Gen
25

11 principi per spiegare l’enterprise 2.0 ai nostri manager

Era un po’ che volevo segnalare questo post che mi ha inviato Cristiano, perché mi sembra un’ottima sintesi dei principi che stanno dietro e attraversano i progetti intranet innovativi ed enterprise 2.0 in generale.

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.

Gen
22

Il prezzo del coordinamento. Il video di Clay Shirky

Chi ha un po’ di dimestichezza con l’inglese e conosce un po’ le idee di Clay Shirky apprezzerà questo video tratto delle TED conference, nel quale Clay parla della difficoltà del coordinamento istituzionale (quello delle imprese) rispetto ai sistemi di condivisione online.

Il senso è che nelle organizzazioni fisiche il coordinamento ha un costo, e questo costo deve essere compensato da output adeguati. Questo taglia fuori la possibilità di usare la coda lunga della partecipazione. Cosa che non succede online, ovviamente.

E’ un condensato del Shirky-pensiero e troverete alcuni temi dominanti della sua riflessione: l’abbassamento dei costi di transazione nei sistemi online, la coda lunga e l’inutilità dei valori medi, la difficoltà a rendere istituzionale la collaborazione della folla, la ridefinizione del concetto di professionalità.

Credo che sia una riflessione molto importante per chi si occupa di gestire il cambiamento organizzativo dai sistemi burocratico-gerarchici ai sistemi a rete dentro le aziende. Buona visione.

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
21

Workplace: i tre modelli di Jane

Come sempre, quando un modello o uno schema sono ben fatti valgono oro e arricchiscono qualsiasi contributo. E’ il caso di questi schemi tratti dall’ultimo report di Jane McConnel sui trend 2010 per le intranet. Jane realizza la più vasta indagine annuale sullo stato dell’arte delle intranet e i dati che emergono sono sempre interessanti.

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)

Workplace-a

Modello due: ibrido (55% dei casi)

Workplace-b

Modello tre: unificato (15% dei casi)Workplace-c

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

Gen
21

Procedure o micro-blogging? Appunti per uscire da un falso dilemma

Bertrand Duperrin torna a parlare delle molte virtù del micro-blogging interno e io lo segnalo volentieri perché questa cosa degli aggiornamenti di stato per fare domande e ricevere risposte tecniche all’interno di un’impresa mi sembra l’utilizzo più interessante e promettente.

Bertand parla esplicitamente di questo uso attraverso la metafora del messaggio nella bottiglia. Riporto un brano del post:

One of the best use of these new tools and practices is “bottle in the sea”. The famous “who knows ? Who has any information about ?”. Notice that there are also implicit bottles, those we don’t throw consciously and that are in every status update, despite of us. For instance when we say “going to meet such prospect”, we don’t expect anything back. But someone can answer “I know them well / I already worked on similar cases / etc…”. In brief, a status update can also be seen as an implicit question, adressing the sphere of the “unknown unknown” that sounded quite funny in Rumsfeld’s mouth but that is not so far from our concerns.

Secondo Bertrand questo approccio alla gestione conoscenza funziona bene per le informazioni strutturate e codificate (e quindi meglio trasmissibili), ma per le quali le persone non hanno idea di dove andare a pescarle.

In this case, if search is too tedious, or if I ignore the very existence of the tools that may help me, I need one of my peers to direct me to this information which existence and location he knows.

L’unico problema è questo: e le se persone non sono disponibili? Ovvio che il bel sistemone informativo è sempre a disposizione mentre i colleghi che sanno la risposta no. Eppure tutto questo discorso non mi convince; in fondo i sistemi informativi non sono sempre disponibili e anche quando lo sono non sempre hanno la risposta.

E’ ovvio che siamo in genere molto più disponibili ad affidarci a tali sistemi piuttosto che ad un sistema di reti di colleghi informale, perché ovviamente su di essi ricadono aspettative –  retoriche – di affidabilità, serietà, disponibilità eccetera. Tutte le caratteristiche che cerchiamo invano negli esseri umani.

Ma tutta questa discussione ci manda fuori strada perché si basa su alternative fittizie che vengono contrapposte artificialmente. O i sistemi o le persone, o le informazioni strutturate o i consigli informali, o l’evanescenza del real time o la permanenza dei manuali e delle procedure.

Ma se osserviamo come interagiscono le persone nella loro attività quotidiana e che uso fanno delle risorse a loro disposizione ci accorgiamo che queste alternative di fatto collassano l’una nell’altra. Provate ad osservare da vicino un pony express, un muratore sul tetto, un tranviere, una commessa dei grandi magazzini, un operatore di call center, un funzionario di banca: vi accorgerete che ciascuno di loro fa un suo continuo e mescolato di risorse cognitive personali, valutazioni ambientali, interazioni coi colleghi, uso di tecnologie strutturate, uso di tecnologie di comunicazione, procedure codificate, soluzioni non codificate.

Quello che le persone hanno a disposizione è in genere un vero e proprio ecosistema, di cui ovviamente il micro-blogging può (o no) rappresentare un elemento. Ed è bene che questo ecosistema, come tutti gli ecosistemi, sia sufficientemente ricco per permettere lo sviluppo e la salute dei suoi partecipanti.

I nuovi media non sostituiscono i vecchi media, le nuove procedure convivono con le vecchie, i vincoli e le possibilità di un nuovo ambiente si mescolano con le conoscenze pregresse delle persone che lo abitano. A volte il micro blogging funzionerà, a volte no, a volte i sistemi di incepperanno e a volte andranno alla grande, a volte il collega di stanza di manderà a cagare e a volte invece sarà disponibile.

L’importante è che la bio diversità cognitiva e le possibilità a disposizione tendano ad arricchirsi. E allora anche i messaggi nella bottiglia avranno un loro senso, al di là delle – sempre perdenti – aspettative magiche.


Gen
16

Le perle di saggezza di Bernabé

Ieri sera siamo stati qui, a sentire Negroponte e a rivedere un po’ di persone (che saluto ora visto che non le ho viste dopo).

Riporto in ordine sparso alcune perle di saggezza di Bernabè, (AD di Telecom Italia) perché ne vale davvero la pena:

– Il 97% degli italiani oggi hanno connettività. Se non si connettono è un problema di cultura.

– In California la connettività è di scarsa qualità, molto meglio l’Italia di San Diego o San Francisco, dove peraltro abbiamo una sanità che è davvero ottima.

– Telecom investe un casino in infrastrutture

– Siccome l’anziano non va su internet noi gli portiamo internet sul televisore così ci va

– Dei 26 milioni di italiani connessi in Rete almeno 22 sono su Facebook e questa è una popolazione che ha un’alfabetizzazione alta e un uso avanzato della Rete (sic, ma anche sigh, ma anche augh)

– In Italia c’è una sana concorrenza tra operatori telefonici che garantisce libertà di scelta e innovazione

Ok, ne ha detta anche altre che non ho fatto in tempo ad appuntarmi

Aggiungiamo il sorriso serafico, l’aria tranquilla da boss e da guru della Rete (ma chi gli ha dato questo ruolo non si sa), un gruppo di interlocutori che non ha battuto ciglio, a parte qualche timida e reverente osservazione di Sofri e  il povero Negroponte, (non ha caso uno che non riceve soldi da Telecom in forma diretta o indiretta),  che secondo me a un certo punto deve aver pensato che c’erano problemi di traduzione; infine, un quarto d’ora di pippa su Arpanet e le origini di Internet.

Ce ne siamo andati prima.

Gen
15

Strategie di usabilità per il cercapersone

A volte capita che in azienda cerchi sul cercapersone i riferimenti di un collega ma non ti ricordi esattamente il cognome: Rossi? De Rossi? De’ Rossi (con l’apostrofo)? Questo, nei sistemi punitivi delle vecchie applicazioni, crea naturalmente messaggi di errore  (e frustrazione, off course).

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

Gen
3

Frammenti sul sapere, la Sabina, il trasloco

Quelli che seguono sono frammenti che ho raccolto durante questo lungo ed estenuante periodo di lavoro e  di movimento attorno alla mia nuova casa e alla mia nuova condizione di abitante campagnolo; il loro tema comune è il rapporto tra persone e il loro sapere, e come questo sapere influenzi le nostre performance, i nostri rapporti sociali e il nostro “muoverci nell’ambiente che abitiamo”.

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

Gen
3

La collaborazione e il coinvolgimento tra un paradigma e l’altro

Guardando gli interventi e gli articoli sul tema della collaborazione in intranet e nel campo dell’enterprise 2.0 mi rendo conto che davvero ci troviamo sulla soglia di un cambio di paradigma.  La caratteristica dei paradigmi e che tendono a definire il perimetro dei problemi all’interno dei quali trovare una soluzione (Kuhn chiama talvolta questi problemi “rompicapo“). In altre parole è il paradigma che definisce l’ordine del discorso all’interno del quale sviluppare un progressivo lavoro di disvelamento e di soluzione. Una volta che il paradigma si frantuma viene sostituito da un nuovo ordine di problemi e di “fatti rilevanti”.

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.

Gen
3

Microblogging fai-da-te con Socialcast

Sto provando ad utilizzare Socialcast, un servizio online per gestire il lifestreaming aziendale e  e devo dire che è un’applicazione di microblogging interno che promette bene. Il modello di business è il solito: puoi utilizzarla gratuitamente, con funzionalità limitate,  con la mail aziendale tua e dei tuoi colleghi;  se vuoi delle funzionalità aggiuntive (come il question and answers) devi fare richiesta inserendo la tua carta di credito (e questo è un po’ inconsueto in effetti). Per le funzionalità a livello enterprise c’è un prezzo da pagare.

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…

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.

Gen
2

Usare i social network interni con dispositivi mobili: un esempio

Chris Sparshott è (a quanto ho capito) un intranet-evangelist di IBM e nel suo spazio su Slideshare pubblica periodicamente delle piccole finestre sul mondo “Enterprise 2.0” di big Blue.

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.

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