Roberdan.com è passato quasi un anno da quando mi son messo in testa di fare un esperimento: fare una business-community e vedere fin dove ci si poteva spingere. È tempo di conclusioni, analisi, feedback e, se possibile, qualche best-practice, o Knowledge Object.

Executive Summary

Sicuramente una buona gestione di business community conviene: ha cioè un ritorno positivo. Nel mio caso parliamo di svariati milioni di euro tra revenues dirette e indirette (metodologia del Total Value R=Td+Ti*x%). Per i costi è un pò più un problema: in una community è difficilissimo capire quanto si sta spendendo, visto che la maggior parte delle prestazioni professionali vengono fatte sul limite tra lavoro e piacere/favore personale. Di certo si sanno solo i fondi inizialmente a disposizione. Quasi sempre è difficile farsi dare soldi (ma semplicemente perchè non è definito un processo decisionale). Spesso è ancora più difficile spenderli.

Lesson learned:

1. I goal devono essere chiari e soprattutto misurabili, tramite scorecard
2. Metriche condivise e facilmente applicabili
3. Validazione delle metriche tramite strumenti standard (siebel, excel, sharepoint, access, groove)
4. Comunicazione strutturata e profilata per stakeholder/business unit cliente. Report mensili con stato avanzamento lavori.
5. Comunicazione chiara e standard.
6. Standardizzare modalità di lavoro, strumenti, ritmo, meetings etc. Creare un’identità di gruppo
7. Il modello del core team è vincente e funziona. Modello cordone ombelicale. Ruoli e responsabilità vanno chiarite subito e condivise
8. Metodologia del NoDecisione->NoMeeting e Meeting=Decisione. Non si fa una riunione se non ci sono decisioni da prendere. Non si esce da una riunione senza aver preso tutte le decisioni del caso.
1. Gestite agenda degli incontri in maniera chiara e dettagliata: chi fa cosa, chi deve fare cosa
2. Fate sempre dei report del meeting con i follow-up e le ownership
9. Battete il ritmo: siate consapevoli che siete voi che date il ritmo alla community. Non aspettatevi che qualcun altro lo faccia per voi! E, essendo un modello a rete, nulla vi è dovuto: tutto va “comprato”. Questa è la lezione più importante: in un modello a rete, a differenza del modello gerarchico/funzionale tayloriano (stica....dimostratemi che quello che sto per dire non è vero, se potete ;-), non ci sono regali. Tutto va guadagnato. Il modello a rete è meritocratico: da quì la difficoltà enorme della sua implementazione nel contesto internazionale.
10. Le aziende, gli enti, le organizzazioni, i cittadini, gli utenti piuttosto che (!) i clienti, hanno bisogno di qualcuno che gli dica cosa fare. Da qui la grande accettazione del modello gerarchico/funzionale. Il modello a rete vale per le realtà (le persone) con approccio imprenditoriale, e questo costringe il modello a rete a dei forti limiti di scalabilità a parità di livello di governo (nel caso delle reti il governo si realizza soltanto tramite un mercato).
11. L’unico modo per rendere profittevole una rete di communities è applicare il modello dei distretti industriali.
12. Esiste un limite pratico alla dimensione della community: 8 al primo livello, 30 al secondo livello, 100/120 al terzo livello. Oltre non è fisicamente possibile partecipare alla vita della community.
13. Come far evolvere una business community?
14. Usate le tecniche della Social Network Analisys per identificare le teste di ponte, ovvero i vs contatti di secondo livello. Quelli di primo livello tipicamente non potete sceglierli. Quelli di terzo livello arrivano da soli in maniera incontrollata direttamente dal secondo livellol.
15. Ragionate come foste un Urbanista: un urbanista col senso del ritmo, capace di guardare la città a 360 gradi. Di vederne la bellezza e i fenomeni che la percorrono. Da voi dipende il buonumore degli abitanti della città. Dalla vostra capacità di analizzare le esigenze, predire invece che studiare, dalla vostra sensibilità e dedizione dipende la qualità della vita nella città che state costruendo.
16. ...
17. È lunga, è lunga....spero che Romeo mi dia una mano a sintetizzare, chiaramente a pagamento ;-)...se riesco a rivenderlo come servizio. Riga 17: in questa riga c’è (o meglio, nella sua negazione c’è) lo sforzo che dovrebbero fare i vari dipartimenti IT, se vogliono riprendere in mano il loro processo decisionale.

Limiti del modello:

è come gestire un ministero senza portafogli: serve un meccanismo di sostentamento, tipo advertising o quote di iscrizione. In ambiti aziendali si può vendere questa quota di iscrizione tramite dei livelli di servizio per servizi base e servizi primium

Non scala. Ancora più difficile, senza leve istituzionali, è governare un insieme di business community.

La domanda è: qual’è il limite tra una business community ed una business unit? Il processo di budget.

E qual’è la differenza tra le due? Che la prima può cambiare in qualsiasi momento, in maniera democratica e auto-selezionante (è il cliente che sceglie, vota, paga), mentre la seconda è inamovibile (almeno in termini temporali). L’altra differenza è che una business community non investe (o semplicemente non ha) strutture e risorse dedicate alla comunicazione. Tutto avviene con il tam tam, o, in altri termini, con qualsiasi strumento possa essere condiviso (tipicamente internet o sms). Diverse sono le community per fasce d’età: ciò che vale per un pubblico di trentenni non è assolutamente applicabile ad una di quarantenni così come bisogna essere essenziali con un sessantenne, pur comunicando a 360°.

PALINSESTO: è lo strumento principale dell’urbanista. È come il metronono per un direttore d’orchestra. Batte il tempo.

Vabbè, mi son distratto....domani magari continuo, o tra qualche giorno ... è pur sempre un blog, no? ;-)

Rob