Davide: Che cosa dovrebbe avere una buona intranet?
Jane: Una buona intranet deve avere 3 cose:

1. essere incentrata sull’utente,
2. avere una strategia allineata al business
3. Avere una governance e politiche di gestione integrate al modo con cui viene gestita l’impresa

Davide: Quali sono le best practices per adottare l’enterprise 2.0? Esiste una roadmap comune?
Jane: Ma dispiace ma non esistono roadmap comuni e collaudate. Alcune aziende definiscono prima la strategia, poi la implementano. Altre iniziano con sperimentazioni dal basso, poi ufficializzano ciò che funziona. Altri mettono in campo un minimo di strategia e un po’ di sperimentazione dal basso, per poi farne una sintesi!

La chiave del successo è iniziare da ciò che è necessario al business, non dalla tecnologia. Fate progetti pilota dove c’è allo stesso tempo un bisogno e una sfida.

Davide: Wiki e blog dovrebbero essere utilizzati in una intranet? Se si, esiste un approccio da consigliare per spiegare agli utenti qual è il tool migliore da utilizzare , in base ai contenuti da pubblicare e al feedback che si desidera ricevere?
Jane: I Wiki servono per la co-creazione: fare cose assieme, fornendo uno strumenti per  “la voce del popolo”. Sono di proprietà del popolo o del singolo gruppo. Sono multi-dimensionali: i contenuti si creano spontaneamente. Potrebbero emergere talvolta anche cose inattese.
I blog servono per fare esprimere una voce individuale, il punto di vista di un team, per condividere l’esperienza. Si fanno portatori del punto di vista di un singolo o di un gruppo di persone. Sono bi-dimensionali: viene riportato un certo punto di vista o una notizia, mentre tutte le altre persone possono commentare o fare domande.
E’ interessante notare che le mie ricerche degli ultimi anni, condotte per la Global Intranet Strategies survey, evidenziano che solo nell’ultimo anno i blog hanno assunto rilevanza al pari dei wiki nelle aziende. Entrambi hanno raggiunto il 45 % dell’utilizzo nell’inchiesta del 2009, su un campione di circa 300 organizzazioni in tutto il mondo.
Fino all’anno scorso, i wiki la facevano da padrone. Credo che le società stiano famigliarizzando coi blog. I blog ottengono spesso più visibilità: persone che esprimono punti di vista. Richiedono probabilmente maggior tempo per la gestione rispetto ai wiki, basati sulla collaborazione, cosa che le imprese fanno da diverso tempo.

Davide: Connessioni col sistema ERP: è utile averle all’interno della intranet?
Jane: Assolutamente. Più che utile, è essenziale. E’ la chiave di volta per far sì che la intranet diventi il luogo di lavoro all’interno dell’impresa.

Davide: Credi che esista una killing application? Si parla spesso di Sharepoint.. Lavoro su Sharepoint da quasi due anni, credo che sia una buona piattaforma per realizzare applicazioni web, molto malleabile per poter mappare i processi di business
Jane: Sharepoint è solo una delle tante soluzioni. Non penso che una soluzione da sola si possa considerare una killer app.

Davide: Accesso dall’esterno e tramite dispositivi mobili: credi che sia un obiettivo primario?
Jane: Non è primario ma è molto importante. E’ uno dei 5 key trends che ho individuato per il 2010.

Davide: Qual è il miglior progetto che hai realizzato? Perchè?
Jane: Ce ne sono parecchi! I migliori sono quelli in cui la intranet ha cambiato il modo di lavorare dell’azienda, e il modo di fare business. La intranet esiste, in estrema sintesi, per servire i clienti. Per clienti, intendo i clienti esterni.
Le intranet aiutano le organizzazioni a lavorare meglio: le aziende lavorano per servire i loro clienti.

Davide: Grazie mille per questa intervista Jane, spero di sentire qualche utile consiglio all’E2.0 Forum!

Enterprise 2.0 per chi è sul pezzo, nuovi strumenti lavorativi per chi semplicemente li usa. Fatto sta che sono sempre più diffusi, all’interno delle organizzazioni, strumenti come i blog e i wiki; utilissimi ai team di lavoro per la gestione quotidiana delle attività, altrettanto utili all’azienda per conservare traccia del lavoro svolto e rendere questa conoscenza riutilizzabile in futuro. Sono arrivati già da tempo anche i software di instant messaging, un altro noioso compagno d’ufficio dopo il telefono. In fondo si tratta di tools per comunicare, ma non solo.

E’ sempre difficile la scelta su quale strumento utilizzare, soprattutto per chi ne è a digiuno; vi sono strumenti più o meno adatti in base alle informazioni da condividere e ai feedback necessari. La tipologia della relazione spesso fa la differenza sul raggiungimento dei risultati.
Per scrivere le riflessioni seguenti ho preso spunto da una discussione sul tema che ho letto via LinkedIn, dove veniva citato questo interessante contributo.

Veniamo al dunque, quando è meglio usare uno strumento piuttosto che un altro?

• Blog: è uno strumento informativo più che collaborativo. E’ particolarmente indicato per team di lavoro distribuiti, dove il project manager deve tenere informati i vari attori, talvolta pure il cliente. Dagli articoli possono scaturire discussioni, ma generalmente si tratta di discussioni operative, destinate a perdersi col tempo poichè non sono strutturate. La discussione è asincrona. Le informazioni possono essere catalogate con tag e categorie, ma la componente cronologica è sempre prevalente e prima o poi le notizie finiscono nel dimenticatoio.
• Wiki: è un contenitore di conoscenza. Un repository all’interno del quale memorizzare la conoscenza, sia quella esplicita che tacita. L’informazione può essere strutturata attraverso menù di navigazione, link tra pagine ed eventualmente con una tassonomia. Il contenuto è vivo, viene continuamente modificato dagli utenti ma si conserva la traccia dell’evoluzione. Non è certamente adatto per sviluppare discussioni sulle faccende più operative e non si presta nemmeno come luogo di scambio col cliente, a meno di particolari situazioni. E’ un luogo dove archiviare cose che possono tornare necessarie in futuro, come le best practices per lo sviluppo di un prodotto o per l’archiviazione di istruzioni operative.
• Instant Messaging: è perfetto per chiedere informazioni al volo senza disturbare troppo i colleghi o chi per loro. E’ certamente meno invadente del telefono pur svolgendo la medesima funzione. La comunicazione è rallentata ma efficace: sincrona. Va usato con moderazione, ma è forse uno degli strumenti più rivoluzionari. Con i software di IM è inoltre possibile condividere file o la propria sessione del desktop, si tratta di funzionalità spesso poco utilizzate.
• Email: la rogna più grossa dei nostri tempi. Serve solo ed esclusivamente per comunicazioni ufficiali, come ad esempio la notifica di un appuntamento o l’assegnazione di un task. Sviluppare discussioni dove si chiede il parere di più persone così come collaborare su un file tramite mail è la cosa più sbagliata che si possa fare. Quando serve un feedback “evoluto”, mai usare la mail.
• Telefono: serve per chiedere “Dove sei?” ed eventualmente comunicare al volo alcune cose, come il classico “Arrivo più tardi!”. A volte, se servono molte informazioni immediatamente è meglio parlarsi, perchè l’instant messaging potrebbe rubare tempo ad entrambi. Si tratta di comunicazione sincrona; in fondo a volte è anche piacevole scambiarsi informazioni in modo naturale.

A questi strumenti, inoltre, dobbiamo aggiungere i cosidetti workspace. Tipicamente siti web che raccolgono una o più funzionalità citate sopra e ne estendono le potenzialità con calendari o cartelle condivisi, dove archiviare file sui quali è richiesto l’intervento di più persone.

L’ultima frontiera della collaborazione è sicuramente il buon Google Wave, che ancora in pochi utilizzano (me compreso) ma che alla lunga credo andrà a sostituire la mail, o perlomeno quel modo errato di usarla, che tutti prima o poi sperimentano. In sostanza unifica l’IM, l’editing collaborativo e la mail, aprendosi verso quel mondo infinito di applicazioni web: mappe, video, ecc..

E voi, cosa ne pensate? Avete mai provato a spiegare a qualcuno che sia a digiuno di tutti quando è il momento di usare una cosa piuttosto che un’altra?
Nell’ottica della gestione delle informazioni, credo che sia importante istruire gli utenti circa gli strumenti che hanno a disposizione. Ma come farlo? Attraverso lunghe pagine descrittive del servizio? Può essere utile moderare i contributi e spostarli da un blog a un wiki e viceversa? Io sono ancora in fase di studio dei comportamenti..

Avete mai definito una strategia per diffondere le logiche di web 2.0 in azienda? Ovvero, per arrivare alla tanto decantata enterprise 2.0.. Se si, sono il primo a volerlo sapere.! E dopo un commento a questo articolo, potreste andare a pubblicare la vostra roadmap sul sito di AIIM entro il 2 aprile 2009: è in corso un contest che potrebbe farvi vincere 2000 dollari.

Diffondere la cultura 2.0 in una azienda è una sfida notevole, sia dal punto di vista tecnico che dal punto di vista organizzativo. Se da un lato vi sono sempre più strumenti “all-in-one”, che permettono un veloce deploy delle applicazioni sociali e collaborative web based, dall’altra è sempre vivo il timore della perdita del controllo sui dati, ma anche e soprattutto sui processi o sulle prassi aziendali. Ecco perchè il coinvolgimento del top management divenda un punto fermo, senza questa sponsorship non riusciremo a raggiungere gli obiettivi. Così come è fondamentale definire i passi assieme al dipartimento HR, per tutti quegli aspetti legali dovuti alla privacy; infine sarà indispensabile individuare i key users, persone che possono dare grande valore aggiunto.

Vi sono, a mio avviso, due tipologie di key user da scovare:

• Gli Esperti: coloro che sanno come funziona l’azienda, il knowledge, come girano le informazioni, come le persone ottengono le cose. Sono tipicamente i “nonni”, lavorano in azienda da tempo e magari non hanno molta confidenza con gli strumenti informatici.
• I Visionari: coloro che sanno (nella loro testa) come dovrebbero apparire le informazioni, come dovrebbero essere taggate, come dovrebbero essere archiviate e presentate. Sono persone che sentono l’esigenza di comunicare e lavorare meglio, hanno la casella di posta elettronica intasata da discussioni con maree di allegati ma si sentono impotenti davanti a tutto ciò.

Il fattore critico è sempre il tempo che questi utenti possono mettere a disposizione, dal top management ai key users, tipicamente nessuno ha mai tempo da dedicare all’IT per migliorare la propria condizione lavorativa. E’ difficile far comprendere che si sta cercando di dare risposte a loro e forse proprio in questo senso la definizione della roadmap dovrebbe essere un punto di partenza ineluttabile.

Per chi volesse approfondire ecco l’articolo di presentazione del contest dal blog di AIIM. Ovviamente, finito il contest sarà interessante vedere i contributi pervenuti! I risultati sono attesi per l’11 Maggio 2010.

In realtà la laurea è avvenuta a Marzo, i festeggiamenti pure.. in un poetico irish pub addobbato a festa per San Patrizio.

Durante lo stage e nei mesi a seguire mi sono occupato di PDM (Product Data Management) e di intranet (sorprendendomi di un versatilissimo Sharepoint) in un gran bel gruppo industriale. Avevo già pubblicato qualche idea, ora è il momento del pdf. Pubblico solo in parte, per ovvi motivi di riservatezza, il capitolo 7 relativo alla intranet sviluppata in azienda.

L’intero lavoro è rilasciato con licenza Creative Commons.
Scarica il PDF: Tecnologie ICT per l’Enterprise 2.0: tra Project Management e Collaborazione

Tecnologie ICT per l’enterprise 2.0: tra project management e collaborazione by Davide Del Monte is licensed under a Creative Commons Attribuzione-Non commerciale-Non opere derivate 2.5 Italia License.
Permissions beyond the scope of this license may be available at www.diplod.it.

Di cosa parla questo lavoro? Il sommario vale più di mille parole:

1.Introduzione……………………………………………………………………………….. 11

2.Lo scenario…………………………………………………………………………………. 13
(a)Project Management in R&D………………………………………………. 14
(b)La struttura organizzativa…………………………………………………… 18
(c)Importanza della gestione progetti e Open Innovation………….. 21
(d)Intranet: condivisione e architetture Service Oriented…………… 25
(e)Gestione documentale abbinata ai progetti…………………………. 27

3.Gli strumenti per l’innovazione…………………………………………………….. 31
(a)Ai confini del Knowledge Management……………………………….. 32
(b)Crowdsourcing…………………………………………………………………. 35
i.caso Goldcorp………………………………………………………… 37
ii.caso Colgate-Palmolive…………………………………………… 38
(c)Triz Innovation…………………………………………………………………. 38

4.Social Network e analisi delle reti di persone…………………………………. 45
(a)Enterprise 2.0 e reti sociali………………………………………………….. 44
(b)I bisogni emergenti: Social Network e Appartenenza aperta……. 47
(c)Social Network Analysis e Value Network Analysis…………………. 53
(d)Gli strumenti per l’analisi delle reti sociali…………………………….. 59
Approfondimento tecnico: il software Ucinet……………… 64
(e)Small world network e i 6 Degrees su Facebook…………………….. 68
(f)Le reti a invarianza di scala e la dinamica dei sistemi complessi.. 70
(g)Elementi teorici per la costruzione di un Social Network…………. 74

5.Governance ICT: integrazione e architetture service oriented…………… 83
(a)complessità crescente e bisogno di integrazione……………………. 84
(b)Service Oriented Architecture (SOA) e Software as a Service
(SaaS), Business Process Management (BPM) e Rich Internet Applications (RIA) nei modelli organizzativi rizomatici…………… 85
(c)Dalle prime forme di scambio informazioni alla Enterprise
Application Integration (EAI)………………………………………………. 93
(d)Accoppiamento del software: bene o male?…………………………. 97
(e)Il ruolo dell’ICT: Perché i progetti falliscono………………………….. 99

6.Gli strumenti della Social Era…………………………………………………………. 103
(a)Virtual workspaces: tra wiki, blog e team di lavoro…………………. 104
i.caso Lago………………………………………………………………… 109
ii.caso Serena……………………………………………………………. 111
(b)Sharepoint e Project Web Access: la collaborazione sui progetti
secondo Microsoft…………………………………………………………….. 112
(c)Qualche cenno sui vendor internazionali e i player italiani……… 119
(d)Qualche cenno sul mondo Open Source………………………………. 124

7.Il caso LandiRenzo SpA: intranet per il reparto R&D……………………….. 129
(a)L’azienda e l’unità R&D………………………………………………………. 130
(b)L’analisi di partenza…………………………………………………………… 133
i.Persone e progetti………………………………………………….. 133
ii.Metodologie e prassi lavorative……………………………….. 134
iii.La collaborazione e gli strumenti……………………………… 136
iv.I network relazionali………………………………………………. 138
v.I rapporti con le sedi estere…………………………………….. 141
(c)Il re-design della intranet R&D: metodologie e problematiche.. 142
(d)Sharepoint e PWA: personalizzazioni della piattaforma e Web Parts……………………………………………………………………………….. 145
i.Utenti, sincronizzazione Active Directory e
ristrutturazione RBS……………………………………………….. 149
ii.Calendari condivisi per i banchi e la strumentazione
tecnica………………………………………………………………….. 152
iii.Template Landi………………………………………………………. 155
Approfondimento tecnico: Creazione tema Sharepoint…………………………………………………… 156
iv.Realizzazione prototipo di project workspace: uno spazio collaborativo con wiki e blog……………………………………. 159
(e)Product Data Management con il software CoCreate Model
Manager: workflow e integrazione SAP……………………………….. 166
i.Creazione di una nuova classe documentale………………. 174
ii.Creazione di nuovi materiali…………………………………….. 176
iii.Definizione workflow di approvazione disegni……………. 178
(f)Punti di forza e debolezza dei sistemi e ipotesi di sviluppo……… 180
i.PWA: i Key Users…………………………………………………….. 181
ii.PDM: integrazione SAP…………………………………………….. 183
iii.Scarso utilizzo e mancanza di incentivi………………………. 184
iv.Web Services con PDM……………………………………………. 185
v.Integrazione tra Sharepoint e SAP Portal……………………. 186

8.Conclusioni: una nuova intranet di Gruppo…………………………………….. 191

Riferimenti Bibliografici………………………………………………………………… 199
Appendice A: Una Web Part con le news da Google, XML e XSL all’opera 202
Appendice B: procedura per il deploy di un Application Template Sharepoint…………………………………………………………………………………… 206
Ringraziamenti…………………………………………………………………………….. 209

Mi piacerebbe se da questo lavoro nascessero spunti di riflessione, se qualcuno si facesse avanti per indicarmi esperienze simili, per scambiare pareri e conoscenze. Buona lettura ;)

Questa dei libri in azienda l’ho sentita per la prima volta ad una conferenza su Sharepoint organizzata da Amicucci Formazione. A detta di molti, Sharepoint sembra essere il non plus ultra per creare una intranet 2.0 come si deve: ormai è pubblicizzato in ogni dove come miglior piattaforma, io ancora devo convircermi fino in fondo: il basso supporto di browser diversi da IE e la non validità del codice secondo i canoni di accessibilità W3C mi fa pensare.. Vuoi per il buon marketing che sanno fare dalle parti di Microsoft, vuoi perchè effettivamente si tratta di una piattaforma duttile, questo cosino inizia a piacermi sul serio.

Così, tra le verie idee, ve n’era una che mi ha catturato più di altre: Libri in Azienda. Alla base di tutto c’è la volontà di diffondere proposte di lettura ai dipendenti; la novità è che il tutto viene realizzato secondo le logiche 2.0. Ai dipendenti è lasciata facoltà di commentare e recensire i libri proposti, loro stessi possono proporli. L’azienda può limitarsi a dare consigli di lettura oppure istituire una biblioteca vera e propria, in qualche stanzino vicino alla sala caffè: dove le persone possono recarsi per prendere in prestito i libri.

Ho pensato di mettere in pratica la faccenda (solo a livello virtuale), con ciò che avevo a disposizione: WSS e Sharepoint Designer. Ecco allora che che i titoli sono presentati attraverso la intranet, che l’azienda apre un profilo su Anobii e tramite i feed RSS la libreria viene presentata su una xml web part.

Le strade possibili erano due:

• Utilizzare due liste Sharepoint, dove vengono catalogati libri e recensioni.
• Utilizzare un social network esterno come Anobii, presentandone l’attività tramite i feed RSS

Cosa è meglio? Beh.. non si tratta di business, semmai di formazione collaterale del personale. Non ci sono dati sensibili, non ci sono dati da salvare; la scelta è presto fatta: servizio esterno!

Tramite un tenplate XSL si può processare il feed di Anobii e il codice è piuttosto snello:

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foo="http://purl.org/rss/1.0/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:admin="http://webns.net/mvcb/"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
version="1.0" xmlns:ddwrt2="urn:frontpage:internal">
<xsl:template match="/rss" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foo="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime">
<html>
<head>
<style type="text/css">
img {border: none;}
</style>
</head>
<body>
<div>
<ul style="list-style: none; margin: 0; padding:0">
<xsl:for-each select="channel/item">
<li style="border: 1px dotted #ccc; margin: 5px; padding: 5px; background: #f9f9f9;">
<xsl:element name="a">
<xsl:attribute name="href">
<xsl:value-of select="link"/>
</xsl:attribute>
<xsl:value-of select="title"/>
</xsl:element>
<br/>
<small style="color: #666; text-align: right"><xsl:value-of select="pubDate" /></small>
<xsl:value-of select="content:encoded" disable-output-escaping="yes" />
</li>
</xsl:for-each>
</ul>
</div>
<div id="footer" style="display: none;">
<xsl:value-of select="channel/copyright" />
</div>
</body>
</html>
</xsl:template>
</xsl:stylesheet>


Dal punto di vista tecnico è tutto ok, adesso si tratta solo di seguire gli sviluppi e i risultati dell’esperimento! Qualcuno ha provato cose del genere?

Ho cercato PBwiki e Google mi propone PBWorks. A volte le cose si scoprono anche così, cercandole. Magari sono pure arrivato lungo, perchè il cambio del marchio è avvenuto ad Aprile 2009. In ogni caso ciò che ho visto oggi è un tool di tutto rispetto, che ha messo da parte il suo taglio prettamente wiki e si propone come strumento di collaborazione per piccoli team di lavoro.

Una delle maggiori esigenze nelle aziende di oggi è la possibilità di avere uno spazio di condivisione facilmente estendibile verso l’esterno, per comunicare con clienti o fornitori, per fare co-design, per scambiare files e conoscenza. Cosa serve quindi? Un’area FTP (magari Tortoise per tracciare le versioni dei files), un wiki, e tanta (troppa) amministrazione. Cosa potrebbe sostituire queste cose? PBWorks: un wiki con un’area di gestione file dotata del versioning. Ma soprattutto uno strumento facile da utilizzare, che può benissimo essere aperto in autonomia da qualsiasi utente senza il supporto IT e che è in grado di gestire diversi profili di accesso: amministratore, editore, lettore, ecc..

Non mancano RSS, backup, personalizzazione dei colori e del logo. Sono tutte funzionalità che devono esserci e sono considerate commodity. Tipicamente ciò che fa la differenza in questi strumenti è la facilità di gestione.

Nell’ottica di intranet management, dare la possibilità ai propri utenti di aprirsi e configurarsi uno spazio di lavoro in autonomia è cosa buona e giusta. Può però diventare problematico quando vi è la necessità di aprire l’accesso verso l’esterno: clienti e fornitori non avranno mai un utente di dominio. Ecco allora che si passa nel campo della extranet.

Perchè non utilizzare servizi esterni? Gli utenti prima o poi lo farebbero da soli, a mio avviso meglio prevedere certi comportamenti e convogliare la domanda verso un unico strumento. PBWorks mi ha colpito per la sua estrema facilità di utilizzo e per la sua velocità di configurazione.
In PBWorks ho notato tante di quelle funzionalità che il buon Giacomo Mason ha elencato per il corporate wiki ideale. Ciò che non va sono le politiche di prezzo, se è vero che comunque viene data la possibilità di creare workspaces gratuitamente con utenti infiniti, è altrettanto vero che le licenze annuali per i servizi professionali sono piuttosto alte (nell’ordine dei 20 dollari per utente, Google ne chiede 40 per offrire la posta elettronica più tutta la suite di Google Apps).

Cosa mi servirebbe? Un servizio simile, se poi qualcuno conoscesse qualcosa di utilizzabile pure in locale e non come servizio, sarebbe il top. Wikispaces è la concorrenza, ma pecca nella gestione dei files: manca infatti un ambiente di gestione dei documenti e relative revisioni.

Entrambi hanno però una cosa fondamentale: le API. Purtroppo ancora non ho avuto tempo per studiarmele a fondo, ma è proprio attraverso le API che si potrebbero gestire all’interno della propria intranet i workspaces aperti verso l’esterno dagli utenti, per tenere sempre la situazione sotto controllo. Questo, a mio avviso, è uno degli elementi fondamentali per scegliere il prodotto. Mi riserbo quindi la decisione finale dopo aver giochicchiato con le API. Semmai qualcuno lo avesse già fatto, è obbligato a commentare!

Se prendiamo in considerazione una società con la tipica organizzazione gerarchica, la diffusione di un software ERP è per antonomasia completa, perchè imposta. Generalmente questo viene implementato in azienda per volontà del top management in collaborazione con l’unità ICT e viene per forza utilizzato da tutti, perchè quello è il luogo dove l’azienda rendiconta il proprio operato.

Un software collaborativo invece ha solitamente una genesi diversa: esso viene acquistato da un dirigente con potere di acquisto, per essere poi diffuso o imposto ai propri diretti impiegati. Questo modo di procedere non garantisce però una completa e compatta adozione, poichè altri dipendenti, che fanno riferimento a diversi dirigenti, potrebbero non essere motivati ne incentivati all’utilizzo.

In questa immagine vengono riassunti i concetti presentati nell’articolo citato in precedenza. Piuttosto significative sono le due schematizzazioni in basso: a sinistra la genesi di un sistema collaborativo imposto secondo la logica top-down, a destra quella di un sistema emergente, nato per volontà di gruppi di utenti con bisogni emergenti, secondo una logica bottom-up.

Tipicamente questi sistemi tendono ad espandersi seguendo le esigenze che di volta in volta si manifestano, la governance è molto più caotica ma la diffusione e l’utilizzo dello strumento sarà sicuramente più uniforme. Il risultato è che alcune funzionalità nascono e muoiono nel giro di pochi mesi, altre si espandono nel tempo grazie alla partecipazione degli utenti. E’ il caso tipico di una intranet aziendale nata secondo una logica 2.0.

Insomma, nel 2009 l’enterprise 2.0 non è più un tabù, invito a leggere una attenta analisi dello status quo presentata sul blog Social Enterprise da Emanuele Quintarelli, di cui riporto solo un passaggio a mio avviso molto interessante che a completamento dei discorsi sopra. Tra le cose che emergono dallo studio sull’andamento del mercato Enterprise 2.0 proveniente da Forrester vi sono queste due sopra tutte:

• Più use cases contemporaneamente: quest’aria un pò carbonara è rafforzata dal numero di aziende che fanno contemporaneamente esperienza con più scenari di utilizzo del social software, guardando in primis al catturare e far circolare la conoscenza (51%), alle comunicazioni corporate (49%), al project management (48%), stimolare la collaborazione (39%). Data la flessibibilità, plasmabilità ed usabilità dei tool, è d’altronde immediato assecondare in corsa le richieste degli utenti e del business
• Pochi dipendenti di fatto usano gli strumenti: in media oggi solamente 1 dipendente su 10 accede sistematicamente ai blog o wiki messi a disposizione dalla società, contro i 4 su 10 che usano il portale corporate ed i 2 su 10 che sfruttano i workspace di progetto. Anche questo dato purtroppo dovrebbe stupirci poco dato lo scarso impegno delle aziende nel coltivare le comunità interne, nel gestire il change management ed ancora prima nel co-progettare questi spazi di scambio coinvolgendo in modo centrale gli utilizzatori finali. Come mostrano altri studi, è ormai chiaro che senza questa attenzione all’adozione, introdurre strumenti sociali non è altro che una perdita di tempo e denaro.

Il dato confortante è che comunque l’Italia non è rimasta indietro, una volta tanto.

Ecco allora un po’ di documentazione per chi volesse cimentarsi in queste affascinanti integrazioni. Io ci sono in mezzo, attualmente non ho La Soluzione, ma una vaga idea me la sono fatta. Credo che l’integrazione perfetta, quella dove l’utente non percepisce differenze, sia difficile ma realizzabile. Già il semplice fatto che entrambi i sistemi supportano il Single Sign On e pescano le credenziali di accesso dall’active directory migliora sensibilmente l’esperienza di navigazione. Non credo però sia un bene, lato amministratore, costruire un forte accoppiamento. Si tratta comunque di sistemi in evoluzione (stiamo parlando di portali e non di software gestionali), ritengo quindi più conveniente mantenere una certa separazione, evitando di caricare viste di Sharepoint su SAP Portal o viceversa pescare dati da SAP per pubblicarli in sharepoint.

SAP è il mondo della documentazione definitiva, dei dati da archivio; sharepoint è il mondo della documentazione viva, delle discussioni, della community.
Qualcuno ci ha lavorato? Qualcuno l’ha vissuta diversamente?

Come promesso, ecco un buon elenco di materiale dal quale partire:

• Interoperability between SAP NetWeaver Portal and Microsoft SharePoint Technologies
  http://download.microsoft.com/download/b/c/1/bc1939d9-638f-4053-b602-4258f18bb683/CB_045_Interoperability%20between%20SAP%20NetWeaver%20Portal%20and%20Microsoft%20SharePoint%20Server%202007.pdf
• Interoperability between SAP NetWeaver Portal and Microsoft SharePoint Portal Server
  https://www.sdn.sap.com/irj/sdn/dotnet?rid=/webcontent/uuid/f735eb47-0a01-0010-6286-fd089bc952e3
• Integration of SAP Business Server Pages (SAP BSP) in Share Point 2007
  http://download.microsoft.com/download/4/3/d/43de0f43-df6a-4cf2-8c91-2c9001df5945/cb_027_integration_of_sap_bsp_into_sharepoint_server_2007.pdf
• Integrating Microsoft® Office SharePoint® Server 2007 and SAP
  http://download.microsoft.com/download/9/9/5/99583191-9cd2-4701-9ef1-47715b73cffe/CB_028_Integrating_Microsoft_Office_SharePoint_Server_and_SAP.pdf
• Consuming SAP Enterprise Services in a Microsoft Office InfoPath Form
  https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e0421f9a-4c9e-2910-1085-a45f8e813324
• Interoperability between Microsoft Office SharePoint Server and SAP Enterprise Portal [il caso Siemens]
  http://www.sharepointusergroup.at/info/Dokumente/Sharepoint_and_SAP_Real_World_final.pdf

Ebbene, non avendo ancora installato SharePoint Designer volevo farmi un’idea del software per capirne le potenzialità. Le strade sono due: scaricare la demo utilizzabile per 60 giorni oppure effettuare una prova direttamente on-line. Piacevolmente sorpreso: grazie a Runaware viene data la possibilità di collegarsi in remoto a una macchina che ospita una serie di applicazioni Microsoft, il tutto dopo aver scaricato un plugin per il browser sviluppato da Citrix. E’ possibile provare tutto il pacchetto Office: Access, Excel, InfoPath, OneNote, Outlook, Project, Publisher, Visio, Word. Oltre a questi, anche tutta la serie delle applicazioni web based come SharePoint o Project Server.

Giusto per darvi un’idea, a lato trovate la schermata di un sito sharepoint dove all’interno ho preparato un wiki (click per ingrandire). Tutto fatto via browser.
L’esperienza nell’utilizzo è davvero considerevole. Una pratica finestrella indica qualche semplice esercizio per prendere confidenza col software che stiamo valutando. Soprattutto nel caso di SharePoint Designer si è rivelata estremamente utile per capire la logica che sta sotto al programma e fare qualche esperimento.

Per chi non lo conoscesse, SharePoint Designer serve per costruire siti web basati su SharePoint, impostare le master page (template dinamici con spazi dove caricare il contenuto) e creare applicazioni personalizzate. Ad una prima osservazione mi è parso un software completo. Tenete presente che l’ultimo prodotto Microsoft in materia, toccato con mano, fu FrontPage 2000.. Era praticamente impossibile non notare passi in avanti: uno fra tutti il supporto a css. Ma al di là del programma specifico, che avrò modo di installare e provare con la dovuta calma, ciò che mi ha stupito maggiormente è stata la modalità con cui viene offerta la demo.

Provare un programma via browser ha il difetto della lentezza (senza una connessione veloce è impensabile), a volte si percepisce un po’ di ritardo nelle azioni, ma l’immenso vantaggio di non dover installare la versione demo, quella che dopo 60 giorni ti chiede la licenza. Vi immaginate doversi installare tutta la suite Office, Sharepoint e Project Server? Una lavorata immensa se commisurata allo scopo: la prova di un programma, magari anche solo per vedere come è fatta l’interfaccia.
Dalle parti di Runaware sono specializzati in questo: test via web del software, che sia Microsoft o chi per loro. Piacevole scoperta.