Quando si progetta un sistema 2.0 all’interno delle organizzazioni sono possibili, ovviamente, vari approcci generali. Uno di questi recita, più o meno così: “costruiamo una piattaforma di servizi innovativi e lasciamo che le persone se ne approprino poco alla volta lasciando emergere degli utilizzi e dei pattern“. In poche parole, si crea una piattaforma che si pone come geenral pourpose technology e si guarda che succede. Un po’ come portare l’energia elettrica e lasciare che gli utenti la usino come vogliono.

Questo tipo di progettazione ha, naturalmente, il pregio di permettere la nascita di soluzioni nuove e divergenti, ma sconta il difetto di concentrasi sulle soluzioni invece che sui problemi (e basta leggere i bandi di gara per rendersene conto): vogliamo i forum, poi i blog, poi qualcosa per gestire progetti, un motore interno con un pizzico di semantica e una spolverata di wiki. Innaffiamo con un po’ di groupware e abbiamo quello che ci serve.

Ma, dato che queste applicazioni hanno successo nella misura in cui i dipendenti le utilizzano, il rischio di fallimento è ovviamente dietro l’angolo.

Ora, il mondo che è emerso dall’International forum on enterprise 2.0 di Milano mostra, diversamente dall’approccio che ho sommariamente descritto, lo stretto rapporto che lega i progetti enterprise 2.0 con specifici problemi organizzativi e locali.

Sono in genere problemi e questioni pratiche molto concreti: accorciare la filiera dell’informazione, migliorare alcune dinamiche organizzative, rendere più intelligenti alcuni processi decisionali, velocizzare le risposte verso i clienti, coordinare meglio certi flussi di lavoro, gestire in modo efficace la documentazione di progetto e così via. Sono questioni a volte prosaiche, poco cool e in certi casi decisamente noiose.

Questi problemi organizzativi hanno in genere un rapporto vago e per lo più implicito con il mondo delle applicazioni web 2.0 o enterprise 2.0. La novità non sta certo nei problemi, ma nelle soluzioni nuove che queste applicazioni riescono a portare.

E riescono a farlo perché definiscono una specifica promessa e un patto chiaro con i partecipanti, qualcosa che tutti in azienda possono capire: UN singolo problema, UNA singola esigenza alla quale si cerca di rispondere in modo specifico utilizzando in modo creativo (ovvero, in molti casi, ricombinando) soluzioni nuove.

Potremmo chiamare questo approccio PCD, ovvero Problem centred design: identifico esattamente il problema e progetto una soluzione 2.0 che risponda solo a quello. Niente megapiattaforme, niente megaprogetti: soluzioni locali guidate da un pensiero globale.

Credo che questo sia il messaggio più importante che emerge dal Forum e con il quale bisognerà fare i conti: il futuro è, a mio parere, in una collezione di specifiche applicazioni che permettono di risolvere specifiche questioni.

Il primo corollario di questo approccio è evidente: nessuna applicazione sarà identica all’altra e ogni soluzione sarà quella soluzione a quello specifico problema in quella specifica azienda.

Il secondo corollario è che qualunque iniziativa costruita sulla moda del momento è destinata al fallimento perché non si concentra su un problema, ma cerca unicamente di adottare qualcosa senza una promessa esplicita e condivisibile. Lo stesso errore delle piattaforme di KM degli anni ‘90.

Ma naturalmente questa è solo una parte della storia, perché comportamenti emergenti, pattern non previsti e dinamiche divergenti sono comunque parte integrante della vita di questi progetti. È per questo che ogni iniziativa che funziona tende nel tempo a riconfigurasi, ad aggiungere dei pezzi e a modificare alcune clausole del patto stabilito con gli utenti. Ma questa è solo un’estensione dinamica di qualcosa di locale che ha funzionato prima.

E soprattutto è l’applicazione di metodi e strumenti nuovi a problemi di volta in volta diversi.