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:
- I goal devono essere chiari e soprattutto misurabili, tramite scorecard
- Metriche condivise e facilmente applicabili
- Validazione delle metriche tramite strumenti standard (siebel, excel, sharepoint, access, groove)
- Comunicazione strutturata e profilata per stakeholder/business unit cliente. Report mensili con stato avanzamento lavori.
- Comunicazione chiara e standard.
- Standardizzare modalità di lavoro, strumenti, ritmo, meetings etc. Creare un’identità di gruppo
- Il modello del core team è vincente e funziona. Modello cordone ombelicale. Ruoli e responsabilità vanno chiarite subito e condivise
- 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.
- Gestite agenda degli incontri in maniera chiara e dettagliata: chi fa cosa, chi deve fare cosa
- Fate sempre dei report del meeting con i follow-up e le ownership
- 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.
- 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).
- L’unico modo per rendere profittevole una rete di communities è applicare il modello dei distretti industriali.
- 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.
- Come far evolvere una business community?
- 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.
- 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.
- ...
- È 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
Commenti