Home » Archivi per schemi

mar
21

Affinità e divergenze tra la intranet e noi

Oggi è venerdì e vi voglio lasciare con qualcosa di leggero e terribilmente vero: il diagramma delle cose che in genere gli utenti vogliono dalla intranet incrociato con quello che la intranet in genere presenta in home.

La regola aurea del minimum viable product dice di cominciare sempre con quello che sta all’intersezione tra i due cerchi. Quindi, buon appetito a tutti :-)

Fonte: clearbox

 

Collegamento permanente dell'immagine integrata

 

 

apr
29

Gestire online i documenti, gestire offline le persone

Credo che il proposito di cambiare le abitudini dei colleghi rispetto alla gestione dei documenti in azienda sia uno dei più ambiziosi e spesso frustranti: le persone, che lo vogliamo o no, fanno in maniera ostinata e naturale cose come aprire il foglio Excel, mandarlo per email a 10 colleghi per le revisioni, salvarlo su chiavetta per vederlo su un altro PC, farne 10 versioni rinominandole 1,2,3 ecc.

Le persone, oggi, se non educate in altro modo, fanno questo. E’ quindi molto importante, quando si inaugura un nuovo sistema per gestire online i documenti e le varie attività ad essi connesse, accompagnare questo processo con una seria campagna di sensibilizzazione.

In questo ci viene in aiuto un bell’articolo di Pebbleroad, intitolato 10 Document Management Principles For Intranet Users. In esso Manish Nichani ci elenca dieci comportamenti (creazione contenuti, nomi dei file, versioning, diritti di accesso, co-authoring ecc) che un sistema di gestioni in intranet tende a cambiare e sui quali è necessario dare delle regole e diffonderle.

 

 

L’articolo propone anche il PDF dei principi da scaricare e da mettere nella propria intranet. Come si vede da questo banale caso di gestione della documentazione il problema è sempre meno nelle tecnologie e sempre più nelle abitudini, nelle motivazioni e nei comportamenti delle persone.

 

mar
22

La (affascinante) roadmap della community UBM

Vi devo dire la verità, sono rimasto abbastanza colpito dal caso recente pubblicato da Community Roundtable a proposito del progetto di community interna realizzato da UBM nell’arco di tempo che va dal 2008 al 2012.

Ma non tanto per i contenuti del progetto (di fatto si parte da un wiki per poi mettere in piedi un blog del CEO e farlo crescere fino a creare una comunità ramificata), quanto per la bella rappresentazione visuale che ne viene data nel report, e in particolare per la legenda che descrive il tipo di attività che viene fatta nel tempo:

legenda attività community

roadmap costruzione community interna

La legenda, e la rodmap nella quale è inserita, riescono a sintetizzare molto bene quali tipi di attività diverse stiano dietro la costruzione di un processo del genere.

Potete leggere il (breve) report da qui, buona lettura :-)

 

 

gen
16

Il cammino tortuoso della Intranet personalizzabile

Qualche post fa parlavamo del rapporto tra globale e locale in intranet, il che si potrebbe anche tradurre in termini del rapporto tra informazioni profilate e non profilate, in quanto la profilazione definisce i criteri (geografici, dipartimentali, di ruolo, di lingua, di azienda, ecc) che consentono di “localizzare” le informazioni e i servizi.

Da qualche anno a questa dimensione va sempre associata quella, come abbiamo più volte visto, della personalizzazione, ovvero delle scelte lasciate al singolo dipendente nel costruire il proprio set di informazioni. Anche su questo punto, come abbiamo visto in molti esempi recenti, non esistono scelte nette, ma uno spettro di possibilità, che hanno riassunto bene gli animatori di Intranetizen in un loro post

http://intranetizen.com/wp-content/uploads/2011/04/personalisation.png

Molto saggiamente, gli autori individuano, per ogni tipo di scelta i pro e i contro. Anche in questo caso, come per il rapporto globale/locale, al crescere della dimensione dell’azienda i vantaggi di una differenziazione si fanno sentire.

Ma attenzione perché, come fanno notare gli autori, sono ancora pochi i dipendenti che personalizzano, e quelli che lo fanno spesso creano pagine simili. Il che ci porta alla domanda: ma non era meglio fare prima una ricerca seria sugli utenti e poi dare loro subito quello che gli serve?

In realtà credo che un buon bilanciamento tra aspetti profilati e personalizzazioni sia oggi indispensabile, purché le cose che si possono personalizzare siano realmente utili (vedi la My page della intranet comune di Venezia) e purché  le funzionalità siano siano accompagnate e comunicate in modo serio a tutti i dipendenti.

dic
24

L’adozione della intranet 2.0 e i suoi dilemmi

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

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

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

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

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

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

Spero che lo schema seguente mi aiuti a farmi capire:

Lo schema presenta:

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

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

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

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

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

Che ne dite? Intanto buon Natale a tutti.

giu
9

E’ la intranet o “la mia” intranet? Piccole questioni identitarie

Mi capita, a volte di avere a che fare con intranet che “non funzionano”. Una intranet che non funziona è una intranet che non viene usata, e una intranet che non viene usata è, in genere, una intranet in cui i dipendenti non si riconoscono. La domanda a cui oggi vorrei provare a rispondere è: perché non ci si riconoscono?

Questa domanda coinvolge il piano editoriale delle intranet, non meno che le questioni riguardanti l’identità professionale dei dipendenti. Mi spiego: se sei un grande gruppo industriale di decine di migliaia di persone e nella intranet ti limiti a pubblicare i videomessaggi del Grande Capo,  gli accordi commerciali col Giappone e la visita del Ministro alla sede di Stoccolma stai facendo una intranet in cui si riconosceranno pochi super manager (che peraltro non vanno sulla intranet, come si sa), mentre la maggior parte dei dipendenti proseguirà tranquilla il suo tran tran tra problemi quotidiani, piccoli successi senza importanza, innovazioni locali che sfuggono ai radar organizzativi, relazioni informali.

Le persone vogliono vedere se stesse nelle cose che usano, i dipendenti vogliono vedersi rappresentati dagli artefatti tecnologici che proponiamo loro. E questa auto rappresentazione, nelle organizzazioni, è assai più complicata di quanto immaginiamo: prima di tutto ci sono io, con le mie competenze, i miei interessi professionali e le mie attività; poi ci sono i miei colleghi, quelli con cui tutti i giorni affronto i problemi operativi; poi c’è il palazzo in cui lavoro, ovvero la sede fisica che abito dalla mattina alla sera; poi ci potrà essere il settore a ci appartengo, l’azienda di cui faccio parte e infine, se è il caso, il Gruppo industriale di cui sono una semplice rotellina.

L’identità insomma, si presenta in maniera stratificata e in genere per ciascuno strato vi sono in intranet contenuti e servizi tipici:

Schema di identità in intranet e relativi contenuti

Questo schema generale vale per ogni contento organizzativo, ed è il motivo per cui i piani editoriali tarati sul Vertice alla lunga producono intranet marziane che le persone percepiscono come corpi estranei alla loro vita professionale. Gli strati più interni sono quelli in cui le persone abitano, sono quelli che vedono tutti i giorni e sono quello che, in genere vorrebbero vedere sulla intranet.

Riusciamo a farlo, almeno un po’?

 

 

set
29

Tempi duri per le news in intranet

E’ evidente a tutti che la lenta metamorfosi degli spazi intranet, che li sta portando lentamente verso un modello collaborativo guidato dagli utenti, coinvolge e trasforma molti aspetti collaterali a questi progetti, fino a ridisegnare il ruolo stesso della comunicazione interna e dei suoi strumenti tradizionali.

Ho provato a rappresentare l’insieme dei cambiamenti che sta travolgendo questi spazi in questa tabella (forse un po’ grossolana)

Schema: le tre fasi storiche della intranet

In questo insieme di cambiamenti ne fa le spese uno degli oggetti tipici delle intranet, almeno fino a qualche tempo fa, ovvero le news che raccontano le novità dall’azienda. Naturalmente le news non sono scomparse ancora dalle intranet, ma stanno soffrendo una sorta di crisi di identità che le costringe a misurarsi in continuazione con domande circa la loro utilità, il loro statuto, il loro ruolo effettivo nella nuova comunicazione interna.

Un tempo architrave dell’impianto editoriale di questi progetti, stanno poco alla volta cedendo il passo per mettersi al servizio del nuovo panorama fatti di discussioni,  servizi, applicazioni, spazi di collaborazione e così via. Questo cambiamento è testimoniato ad esempio da questo articolo che spiega la ragione segreta per cui le news non vengono lette dai dipendenti.

Io sono abituato ad evitare in questo campo contrapposizioni molto nette: credo che le news sopravviveranno per molto tempo nel modo in cui le conosciamo ma che semplicemente saranno poco alla volta affiancate da altre modalità di comunicazione (una di queste sono le notifiche, ovvero gli avvisi all’utente, un’altra sono i blog interni di progetto o specialistici e così via). Tuttavia ci sarà sempre bisogno di una parte della intranet che racconti in modo più o meno ufficiale le novità dall’azienda: semplicemente questa parte non sarà più il baricentro delle attività.

Anzi, per venire incontro a coloro che ancora si affannano sulla scrittura di news vi segnalo questa check list per misurare l’efficacia delle vostre news in intranet.

Buona lettura.

feb
22

Alla ricerca del modello perfetto per intranet e l’enterprise 2.0

Devo dire che nell’intenso dibattito – permanente – su enterprise 2.0 e intranet innovative, un dibattito attraversato da momenti di euforia, ripensamenti, grandi intuizioni e prosaici casi di studio, ci scontriamo con un autentico diluvio di modelli interpretativi e tentativi di cogliere astrattamente in un tutto l’insieme di dinamiche che queste nuove tendenze e questo insieme di tecnologie abilità.

La cosa è piuttosto divertente e il risultato assomiglia ad un collage di visioni che nel momento in cui si legittimano (poiché ognuna di essere ha dalla sua un bel po’ di evidenza empirica) contribuiscono a dipingere un quadro ancora davvero acerbo del fenomeno. Siamo tutti alla ricerca del nostro modello definitivo e della nostra narrazione unificante, anche se questa non si lascia ancora cogliere pienamente.

Nel frattempo accontentiamoci di frammenti di sistema: il primo, certamente già molto famoso e con un grande potenziale davanti a sé, è quello di Andrew McCafe, che cerca di dividere il territorio delle relazioni aziendali (Ricordate? Rapporti forti, deboli, potenziali, assenti).

Enterprise 2.0 Rings

Recentemente Andrew ha sottolineato come, secondo lui, gli strumenti dell’enterpse 2.0 diano i loro più grandi benefici negli anelli esterni di questo “bersaglio”.

Un secondo modello interessante è quello proposto da Bryan Menell, di Thoughtfarmer; Bryan racconta come nella definizione dei processi di user centred design per la loro intranet abbia utilizzato un modello che richiama la prossemica di Edward T. Hall. Il risultato è una definizione dell’ambiente intranet che va dalla persona all’ecosistema aziendale.

thoughtfarmer_proxemics

L’articolo è interessante anche per un altro motivo, ovvero perché propone un approccio alla personalizzazione degli ambienti che bypassa l’alternativa tra la personalizzazione totale da parte dell’utente (strategia su cui più di uno specialista ha qualche dubbio) e controllo centralizzato della home page (Un tema che molti, naturalmente, affrontano a modo loro, dai saggi consigli di Jane McConnell all’approccio darwinista di Stephan Schillerwein).

Vorrei provare a dare, in questo senso un mio contributo a questa intensa battaglia combattuta a colpi di schemi, diagrammi, freccioni e bersagli: il mio schema parte dal fatto che ogni ambiente intranet di nuova generazione supporta il lavoro dei singoli, ma lo supporta e lo segue nelle diverse situazioni sociali in cui sono impegnati in azienda:

- Supporta me in quanto lavoratore
- Supporta me in quanto appartenente a un dipartimento
- Supporta me in quanto appartenente a un team di progetto
- Supporta me in quanto appartenente ad una community (di pratica o di interesse)
- Supporta me in quanto appartenente ad un ecosistema di informazioni aziendali

Nelle diverse situazioni, ovviamente, cambiano i contenuti, i servizi, le funzionalità; ma anche l’impegno che mediamente è richiesto (sulla questione dell’impegno diversificato vi consiglio questo post di B. Duperrin, molto illuminante) il tipo di contributo che le persone danno (lavorare è diverso da collaborare che è diverso da condividere che è diverso da contribuire). Anche l’uso della mail, da sempre cartina di tornasole delle attività svolte in azienda, tende a diminuire man mano che si passa dall’uso individuale a quello “sociale”.

Modelli dei diversi usi della intranet

E’ importante, a mio parere, che ragioniamo sempre in termini di usi prevalenti e che pensiamo in quale contesto d’uso (più individuale o più sociale) si inseriscono le nostre applicazioni. Perché dobbiamo pensare che cambiano gli scopi, i tempi di utilizzo ma soprattutto l’impegno che la situazione (la situazione, non la tecnologia) richiede.

Che ne pensate?

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.

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

I social network interni secondo Ross Dawson

Continua la pubblicazione a puntate del libro di Ross Dawson dedicato all’enterprise 2.0. Da qualche giorno è disponibile un assaggio del capitolo 11, dedicato ai social network dentro le organizzazioni. Come sempre gli schemi di Ross sono molto belli e chiari:

Intranet_social_network_schema

Il testo è pubblicato su Scribd

IE2 Sample Chapter 11

_______________

Purtroppo il volume intero costa 195 dollari ma sono molto tentato di acquistarlo (e in ogni caso se lo fate voi, o lo fate fare alle vostre aziende,  mi raccomando fatemelo sapere, mi raccomando…:-)

lug
25

Una rappresentazione del meta-ambiente

Cito questo articolo di Patrick Vettelapesca (il tipo non mi è molto simpatico a dire il vero, e oggi lavora come architetto dell’informazione in BBC), perché prova a fornire una rappresentazione della complessità dei sistemi, dei silos e del tipo di saperi e informazioni con cui le intranet di trovano a dover fare i conti:

La sua idea di “lean intranet” è quella di una sistema capace di dialogare, alla lunga, con tutti  questi sottosistemi

Il pregio dell’articolo non è tanto quello di dirci come dovrebbe fare la intranet a realizzare questo obiettivo, quanto quello di aver provato a buttare giù una lista di quali siano questi sottosistemi, ovvero:

  • Email
  • Transazioni
  • siti internet
  • Applicazioni gestionali
  • Sistemi ERP
  • Applicazioni collaborative)
  • Progetti di comunicazione interna
  • Informazioni esterne
  • Sistemi basati su carta
  • Applicazioni e sistemi informali
  • Conoscenza tacita

Ovviamente sono sempre possibili vari livelli di integrazione: unire le basi dati delle varie applicazioni non è la stessa cosa di unificare l’interfaccia e la navigazione principale, che a sua volta è cosa diversa dal mettere semplicemente dei link a disposizione sulla intranet.

Diciamo che è un percorso, che andrà valutato progressivamente importando di volta in volta i “pezzi” più strategici. Per proseguire nel tempo con il resto.

giu
26

RSS in l’azienda: uno schema

Molto carino questo schema di Ross Dawson: credo solo che manchi un pezzo, ovvero la documentazione. Ce ne dimentichiamo sempre eppure è un pezzo davvero importante.

Se metti gli RSS, beh, li devi mettere anche per i documenti (cartelle, categorie, tag sui documenti) se no manca una componente.  Dallo schema inoltre non si capisce dove vanno a finire questi RSS. In home, in un pezzo della home o in una “my page”? Propenderei per la terza ipotesi.

RSS_diagram.jpg

apr
23

Oltre l’organigramma. Appunti per l’architettura informativa delle intranet

Sto partecipando ad una gara per la riprogettazione di una grande intranet pubblica, e questa occasione mi ha dato modo di riflettere in modo più approfondito sull’architettura informativa di intranet di grandi dimensioni, in special modo legate alle pubbliche amministrazioni ma non solo.

Mi riferisco in particolare alla costruzione dell’architettura di primo livello, la quale è naturalmente solo una parte dell’architettura informativa più generale. Tuttavia,  come ovvio, rappresenta una scelta fondamentale, che orienterà l’andamento di tutto lo spazio nel tempo e che richiede particolare una cura progettuale.

Spesso però in questo campo si commettono molte leggerezze, che si trasformano rapidamente in errori decisivi. I motivi di questi errori sono legati a molti fattori:

  1. fretta realizzativa (intanto andiamo online, poi magari modifichiamo in corso d’opera)
  2. presunzione organizzativa (conosco bene l’azienda, i contenuti vanno organizzati attorno ai processi di marketing)
  3. abitudini consolidate (noi in genere negli archivi cartacei le cose le organizziamo per codice matricola)
  4. sottovalutazione strategica (architettura informativa? E che cosa c’entra con il web? Piuttosto, ti hanno mandato la bozza grafica?)
  5. Approssimazione metodologica (ne ho parlato al bar con il Dirigente e ha detto che la mia ipotesi va bene)
  6. Scarsa attenzione agli utenti (non la trovano? Ma se sta proprio lì, sotto la sotto-sezione “Funzioni Operative!)
  7. Pulsioni megalomane (fate come volete, ma la mission aziendale deve apparire prima di tutto)

E molti, molti altri non facilmente classificabili. Il risultato di questa leggerezza progettuale è in genere un guazzabuglio in rapida crescita che provoca frustrazione, mal di testa, depressione cosmica; effetti soggettivi che si trasformano, nel migliore dei casi, nella dolorosa consapevolezza che bisognerà, prima o poi, “rimettere mano” a qualcosa che a prima vista sembrava funzionale, e che ora è diventato un mostro inavvicinabile.

Eppure l’architettura di primo livello di una intranet, per quanto complessa, non è un oggetto così enigmatico. Anzi, è possibile con facilità individuare alcune tipicità nella costruzione, ciascuna delle quali presenta una serie di vantaggi e di svantaggi.

Vorrei provare ad elencarle, identificandone le caratteristiche distintive. Come vedrete alcune sono assai ingenue, e inadatte a quasi tutte le situazioni tipiche che possono presentarsi.  Ma vale la pena passarle comunque in rassegna.

Modello 1: Architettura per settori aziendali

Metafora: organigramma

Architettura informativa per settori

Vantaggi

- Facilità nell’individuare gli owner di sezione. In alcuni casi possono coincidere con i rappresentanti del gruppo di lavoro.
- Relativa velocità nella costruzione dell’architettura. E’ sufficiente basarsi sull’organigramma aziendale già definito, proseguendo in profondità con le sotto-strutture e associandole alle sottosezioni.

Svantaggi

Sono tantissimi. Ne elenco qualcuno, ma ce ne sono sicuramente altri

- Difficile gestione delle trasversalità. Molto contenuti non appartengono in specifico a un settore aziendale, e diventa difficile collocarli in questa architettura.
- Cambiamento continuo. I settori, così come l’azienda, cambiano continuamente, e l’architettura rischia di invecchiare molto velocemente.
- Scarsa trovabilità. Molti argomenti, servizi e contenuti della intranet sono percepiti dai dipendenti in modo dissociato rispetto ai settori, e rischiano quindi di non essere trovati con facilità.
- Scarsa scalabilità. E’ molto facile che le sezioni di primo livello diventino troppe, e ingestibili
- Appiattimento contenutistico. Mettere sullo stesso piano H.R. e, poniamo, Legale, significa, in genere, non tenere conto delle esigenze degli utenti, mediamente più interessati al primo che al secondo
- Scarsa visibilità dei servizi. Tutti gli elementi di servizio e operativi, legati a precisi task degli utenti vengono mesi in secondo piano

Quando usarla

L’unica maniera sensata di usare un’architettura del genere è quando siamo in presenza di tante intranet separate, una per ogni settore e abbiamo la necessità di fornire comunque un unico punto di accesso alle diverse sezioni., In questo caso il “portale” non altro, appunto, che una porta introduttiva ad altre intranet di settore, con architetture proprie.

…………………………………………………………………………………………

Modello 2: Architettura per aree tematiche

Metafora: biblioteca

Architettura informativa per aree tematiche

Vantaggi

- Identificazione precisa dei temi. E’ abbastanza facile identificare i diversi temi e i contenuti e raggrupparli secondo uno schema razionale.
- Content owner. Anche in questo caso è abbastanza facile identificare i content owner e i gestori delle sezioni.

Svantaggi

- Overflow. Questa architettura rischia molto rapidamente di deragliare verso un affollamento di temi che la rende a lungo andare inservibile.
- Labeling. In lacuni casi il labeling diventa difficile e richia di asssbassare l’intelegibilità dell’architettura dal lato degli utenti. In alcuni casi l’informazione diventa difficile da trovare fin dal primo clic.
- Appiattimento dei contenuti. In questa architettura i vari temi rischiano di oscurare i concreti task utenti: in alcuni casi diventa difficile evidenziare che in alcune aree sono presenti servizi interattivi o contenuti generati dagli utenti.

Quando usarla

E’ un’architettura ottima per ambienti molto legati alle informazioni e con un tasso di crescita contenuto. In ambienti con molti servizi interattivi e con un forte tasso di crescita delle informazioni rischia di trasformarsi in un boomerang.

…………………………………………………………………………………………

Modello 3: Architettura per formati

Metafora: FNAC (?)

Architettura informativa per formati

Vantaggi

- Lerneability. E’ un’architettura con una curva di apprendimento piuttosto bassa, che facilita mediamente la vita degli utenti nell’ambiente.
- Stabilità. E’ un’architettura che resiste ai cambiamenti organizzativi.

Svantaggi

- Profondità. E’ un’architettura che rischia di essere molto profonda, a causa dei sottolivelli che spesso è necessario creare.
- Invisibilità dei settori. Al contrario della prima, è un’architettura che rende invisibili i settori aziendali e non prevede spazi specifici per loro dal primo livello. In alcuni casi questo può essere un problema.

Quando usarla

Personalmente è una delle architetture che prediligo, per il buon compromesso che offre tra scalabilità, intelleggibilità, completezza. Va molto bene per intranet ricche di contenuto, con contenuti diversificati in termini di formato, ed è in grado di ospitare le espansioni di contenuti e servizi abbastanza facilmente conservando un’eleganza di fondo. Anche se in alcuni casi è necessario associare navigazioni parallele per aspetti legati ai progetti o ai settori.

…………………………………………………………………………………………

Modello 4: Architettura per eventi

Metafora: sportelli pubblici

Architettura informativa per eventi

Vantaggi

- Architettura stretta. E’ un’architettura che non rischia di esplodere, almeno al primo livello
- Focus sull’attività. Il richiamo a una qualche attività che gli utenti possono compiere è certamente attrattivo.

Svantaggi

- Contenuti multiappartenenza. Alcuni contenuti non appartengono in specifico a evento della vita aziendale e diventa difficile collocarli in questa architettura. Servizi come un forum di help desk tecnico appartengono a “informarsi”, “lavorare”, o “collaborare”?
- Scarsa trovabilità. Molti argomenti, servizi e contenuti della intranet sono percepiti dai dipendenti in modo dissociato rispetto agli eventi e rischiano quindi di non essere trovati con facilità.
- Inserimento di formati diversi. In uno stesso contenitore possono finire contenuti molto diversi per formato (notizie, documenti, servizi interattivi, applicazioni ) e per tipo di attività richiesta (lettura, scrittura, collaborazione ecc).

Quando usarla

Certamente è un passo in avanti rispetto ad un’architettura per organigramma o per semplici aree tematiche, ma l’uso di questa architettura è un rischio qualora non sia associata ricerche sugli utenti e sulla loro “mappa mentale” rispetto informazioni aziendali. Dopo un serio lavoro di ricerca può essere una valida alternativa ai modelli precedenti.

…………………………………………………………………………………………

Modello 5: Architettura per appartenenze

Metafora: notiziario locale – Buffet

Architettura informativa per appartenenza

Vantaggi

- Focus sui singoli. Le informazioni sono molti più focalizzate sulle esigenze del singolo.
- Personalizzazione. E’ molto più facile costruire un proprio palinsesto.

Svantaggi

- Difficile gestione dei contenuti extraprofilo. Diventa difficile gestire contenuti e servizi che non si associano direttamente al profilo della persona.
- Rischio di overflow nella parte generale. La parte generale rischia di essere sovraccaricata di contenuti e servizi eterogenei

Quando usarla

Quasi tutte le intranet di grandi dimensioni si possono giovare di un’architettura di questo tipo, perché permette con facilità di abbinare contenuti generali e contenuti specifici o personali. Richiede una certa curva di apprendimento e l’abbinamento ad una architettura di secondo livello più “convenzionale” (poer aree tematiche o formati).

…………………………………………………………………………………………

Modello 6: Architettura per servizi

Metafora: Cassetta degli attrezzi

Architettura informativa per servizi

Vantaggi

- Distinguibilità dei servizi. Ogni servizio è facilmente distinguibili e immediatamente disponibile.
- Relativa velocità nella costruzione dell’architettura. E’ sufficiente basarsi sull’insieme di servizi disponibili
- Relativa facilità di coordinamento. Non è necessario individuare persone specifiche per la gestione delle singole sezioni, ma lavorare con il bacino esteso dei contributori

Svantaggi

- Perdita di controllo redazionale. Questo tipo di architettura lascia molto autonomia agli utenti nell’occupazione dello spazio spazio, perdendo la possibilità di fare “pushing” su determinati temi/servizi
- Dissociazione dai contenuti. Essendo legata ai servizi sezione può contenere contenuti più disparati (il blog di progetto assieme a quello dell’A.D., la modulistica assieme alle presentazioni, il forum di cazzeggio assieme a quello dell’help desk)

Quando usarla

Questo tipo di architettura è abbastanza flessibile da contenre praticametne tutto e permette con facilità l’individuazione dei servizi disponibili.  E’ ottima quasi esclusivamente per intranet che si pongono come “gateway” di servizio, ovvero come piattaforme “neutre” che gli utenti possono poi utilizzare a loro piacimento in tanti modi diversi. E’ insomma un’architettura da Intranet As A Service (IaaS), nelle quali la redazione, o il gruppo di lavoro, si incarica unicamente di animare lo spazio e di fornire dei servizi, che vengono poi fatti propri da gruppi di utilizzatori.

…………………………………………………………………………………………

Modello 7: Architettura per task

Metafora: Consolle di comando – Stanze di casa

Architettura informativa per task

Vantaggi

- Eleganza. Questo tipo di architettura ha il pregio dell’eleganza e di una certa armonia di fondo.
- Brevità. In genere questo tipo di architettura di primo livello tende ad essere breve, con pochi task ben identificati, a vantaggio della facilità d’uso.
- Focus sulle azioni delle persone. Per definizione questa architettura è ben focalizzata sulle azioni che gli utenti possono compiere, evitando ambiguità e orientando l’ambiente ferso uno scenario attivo e partecipativo.

Svantaggi

- Poco “profumo dell’informazione“. Questa architettura, ottima per semplici task utente, perde  valore man mano che i contenuti crescono,PErdendo “profumo informativo”.
- Contenuti “intrattabili”. Con questo tipo di metafora alcuni contenuti saranno difficili da trattare, non riuscendo ad esprimerli con un verbo adeguato
- Mescolamento. Alcuni contenuti rischiano di finire tutti in un unico contenitore, che a poco a poco si snatura.

Quando usarla

Come tutte le architetture tipiche dei servizi “2.0″, questo tipo di impostazione riflette fortemente una logica di “azione” che l’utente deve compiere su di una applicazione. Pertanto è controindicata in intranet di grandi dimensioni, che offrono una molteplicità di servizi e altrettante “situazioni” nelle quali è necessario presentare informazioni. E’ un ottimo tipo di architettura per singole applicazioni, per intranet piccole e molto centrate su task specifici o per sotto-sezioni specifiche, ma rischia di non riuscire a cogliere tutti gli effettivi “task utente” per intranet di grandi dimensioni.

…………………………………………………………………………………………

Osservazioni conclusive

Scordatevi la purezza. La maggior parte delle architetture concrete che si incontrano nella realtà non possono, né devono essere costruite secondo un modello P”uro”, scelto tra i 7 che ho elencato. Piuttosto, quello che funziona veramente è un sapiente dosaggio che ad un’architettura prevalente è capace di aggiungere elementi presi da altre architetture capaci di integrarsi con gli usi prevalenti e le mappe mentali degli utilizzatori. A volte è necessario inserire in un’architettura per Aree tematiche la funzione “H.R., altre volte è opportuno inserire la voce “Blog” in un’architettura per appartenenze. non sarà elegante, ma funziona.

Associate più architetture. Nelle intranet di grandi dimensioni è sempre una buona regola associare più architetture, in modo da offrire una visione alternativa dello stesso tipo di informazioni.  In alcuni casi possono essere due architetture parallele, in altri delle architetture secondarie che si aprono sotto l’architettura principale. Quasi mail, nel caso di grandi progetti, un’unica metafora è in grado di cogliere tutti i contenuti. Nella maggior parte dei casi le architetture si alternano a seconda del livello di profondità. Per esempio:

- in superficie architetture per formati o appartenenze
- in profondità architetture per task o aree tematiche

Sono solo degli esempi: in realtà le cose vanno valutate caso per caso.

Ascoltate gli utenti. Nessuna architettura può funzionare senza un ascolto costante e attento degli utenti, ovvero dei colleghi. Se avete dei dubbi potete stare certi che loro ve li toglieranno. Usate gli strumenti a disposizione (card sorting, interviete ecc) e fatene tesoro prima di costruire l’architettura.

lug
28

Le community di clienti secondo Dion

Gli schemi di Dion Hinchcliffe sono sempre così carini…

tipi di community online

In questo caso si parla di community di clienti, e il post è molto ricco di consigli. Da mettere a confronto con il recente e, devo dire a malincuore, pionieristico e coraggioso Vodafonelab (che comunque resta un’azienda che mi sta immensamente sulle palle. Ecco mo l’ho detto).

lug
28

Come cambiano gli oggetti nella intranet 2.0

Ok, sempre da Toby vi riporto un bello schema che elenca alcune delle differenze tra intranet 1.0 e 2.0.

schema differenze intranet 1.0 e 2.0

Io modificherei alcuni elementi (ad esempio, il contrario di RSS direi che sono piuttosto le newsletter interne) e ci aggiungerei qualcosa:

Cercapersone/social network
Sistemi documentali/Slideshare
Sezioni di dipartimento/gruppi di discussione

E così via.

lug
16

L’albero ondeggiante

Sono molto contento, perché continuo a imbattermi in post che affrontano questioni legate a intranet sulle quali rifletto da tempo. Chi segue questo blog sa infatti che sono un grande sostenitore del cercapersone (o ”Directory aziendale“) come killer application delle intranet e sa anche che questo tema rappresenta, a mio modo di vedere, la vera frontiera e il ponte cognitivo che permette a una intranet di passare dall’1.0 al 2.0 affrontando di petto la questione criuciale: mettere al centro le persone.

In particolare, come ho più volte scritto, il cercapersone dovrebbe evolvere al più presto in un sitema di social network che sappia unire, attraverso il sistema dei profili, dati organizzativi, dati personali, spazi documentali condivisi, filtri e personalizzazioni, competenze, servizi personali e accessi profilati.

Solo in questo modo è possibile sviluppare intranet che mettano insieme contenuti, relazioni e identità e sviluppino dinamiche di rete realmente alternative alle logiche gerachico-fordiste (io dirigente vedo solo i miei, i quali vedono solo i loro e così via piamidaleggiando).

Io devo poter vedere, contattare, entrare in relazione, scambiare contenuti anche in modo orizzontale e il profilo personale all’interno di un social netwok e il mattone principale di questa nuova costruzione.

E a quanto pare questa è anche l’idea di Elizabeth Marsh, dell’International Benchmarking Forum, la quale ha scritto un bel post parlando proprio di questa nuova generazione di Direcotry aziendali capaci di diventare il vero centro vivente delle intranet 2.0 (Elizabeth li definisce “Wave three“).

Ecco il post, ed ecco l’immagine che rappresenta in sintesi le diverse funzioni che dovrebbe assolvere questo oggetto all’interno della intranet.

funzioni_profilo_personale-intranet