Wiki aziendale
Come avviare un wiki aziendale che non sia vuoto il primo giorno
Un wiki nuovo raramente muore per lo strumento sbagliato. Nasce con una struttura e nessuna risposta; le persone ci guardano una volta, e tornano a chiedere a un collega. SecondBrain 365, un agente AI dentro il tuo Microsoft 365, riempie le prime pagine con le risposte che stanno già nelle email, nelle riunioni e nelle chat.
La risposta breve
Un wiki aziendale, detto anche wiki interno, è un insieme di pagine collegate in cui i dipendenti mettono per iscritto come funziona l'azienda: processi, decisioni, a chi chiedere, le risposte alle domande che tornano sempre. Chiunque abbia accesso può contribuire, ed è questo che lo rende un wiki e non una cartella di documenti.
Per avviarne uno che le persone usino davvero, non partire da tutta l'azienda e non cominciare dalla scrittura. Parti da un team e da un responsabile, usa come struttura le domande che vengono fatte a quel team, e riempi le prime pagine con risposte che esistono già nelle email, nelle riunioni e nelle chat. Aprilo solo quando sa rispondere a quelle domande, e da lì in poi rispondi con un link invece che con una spiegazione.
Perché quasi tutti i wiki aziendali muoiono vuoti
Non per mancanza di buona volontà. Un wiki nuovo chiede alle persone di spiegare, una seconda volta e in un altro posto, qualcosa che hanno già spiegato una volta.
Le cose si spiegano dove arriva la domanda: in una risposta, in una riunione, in una chat. Metterle su un wiki vuol dire fermarsi, riscriverle per lettori che non si conoscono e pubblicarle in un posto dove nessuno le ha chieste. È un favore a un collega futuro, e perde sempre contro il lavoro che ha una scadenza.
Quando i ricercatori di MITRE hanno studiato come i dipendenti usavano i wiki interni, si sono sentiti dire proprio questo. Mandare un'email a un piccolo gruppo fa parte del lavoro; scrivere una voce del wiki è un lavoro in più. Le persone non pubblicavano una pagina finché non la sentivano «finita», e continuavano a usare gli strumenti che avevano già davanti. Nel wiki più grande, con 1.502 utenti registrati, in un mese qualsiasi circa 220 persone modificavano qualcosa, più o meno il 3% del personale.
Un wiki lanciato vuoto peggiora le cose. I primi visitatori cercano, non trovano niente e concludono che la risposta non c'è — una conclusione su cui non tornano quando, settimane dopo, la risposta c'è. Per la conoscenza che resta chiusa in un team per altri motivi, vedi far uscire la conoscenza dai silos dei team.
3%
del personale ha modificato il wiki interno più grande dell'organizzazione in un mese qualsiasi.
«Mandavo per email le istruzioni della demo e le mettevo nel codice, ma non mi [ricordavo mai di] metterle sul wiki.»
Un piano di lancio che parte da ciò che esiste già
Cinque passi in circa un mese. Nessuno richiede software nuovo, e scrivere è soprattutto copiare.
Prima di aprirlo
Scegli un team e un responsabile
Parti da dove le domande si ripetono ogni settimana (IT, HR, un reparto, un progetto lungo), non da tutta l'azienda. Scegli una persona che decide dove va una pagina e quale versione è giusta quando due non coincidono. Non deve scrivere tutto: deve decidere.
Prima settimana
Usa come struttura le domande che le persone fanno
Elenca le domande a cui quel team ha risposto più spesso il mese scorso, con le parole usate da chi le ha fatte. Ognuna diventa il titolo di una pagina. Raggruppale in tre, al massimo cinque, sezioni. Un albero di pagine progettato per contenuti che non esistono ancora è la pagina bianca in un'altra forma.
Dalla prima alla terza settimana
Riempilo con ciò che è già scritto
Quasi tutte quelle risposte esistono già: nelle email inviate, nei verbali delle riunioni, nei thread di chat, nel documento che tutti inoltrano. Copiale dentro, con qualche ritocco, con la data e un link al punto da cui vengono. Apri il wiki solo quando ogni domanda della tua lista ha una pagina.
Il giorno del lancio
Aprilo con una risposta, non con un annuncio
Un'email che dice «ora abbiamo un wiki» si legge una volta. La prossima volta che qualcuno fa una di quelle domande, rispondi con il link alla pagina. È così che le persone imparano che il wiki ha la risposta, e dove si trova.
Da lì in poi
Decidi dove vanno le nuove risposte
Basta una regola per farlo crescere: una risposta data due volte va su una pagina. Senza una regola, le nuove spiegazioni tornano nelle email e nelle chat, e il wiki si ferma al giorno del lancio.
Dopo il primo mese il problema cambia: le pagine ci sono, e la domanda diventa se sono ancora giuste. È un altro lavoro: tenere corretta nel tempo una knowledge base aziendale.
Dove le prime pagine sono già scritte
Se la tua azienda lavora su Microsoft 365, le risposte per la prima settimana stanno in quattro posti. Nessuno dei quattro è un wiki.
Posta inviatain Outlook
La risposta che hai scritto a tre persone diverse. Se l'hai spiegato tre volte, è una pagina, e la spiegazione è già stata collaudata su lettori veri.
Riunioni e canaliin Teams
Il riepilogo che qualcuno ha fatto girare, il thread in cui si è chiusa un'eccezione, il messaggio fissato in alto perché tutti continuavano a chiedere. Spesso è lì che la decisione è stata presa davvero.
Siti di team e cartelle condivisein SharePoint
La procedura scritta per un audit, la checklist in una cartella che nessuno apre. Esiste, ma non è nel posto dove qualcuno andrebbe a cercarla.
Il documento che tutti inoltranoin Word
Gli appunti di onboarding che un collega ha scritto per l'ultimo assunto e che manda a ogni nuovo arrivato. Quell'inoltro è il segnale che manca una pagina.
Se la tua azienda usava Viva Topics, aggiungi un quinto posto: le pagine degli argomenti che ha generato potrebbero essere ancora nel tuo tenant Microsoft 365, e alcune vale la pena tenerle. Vedi riusare le pagine lasciate da Viva Topics.
Dove entra in gioco SecondBrain 365
Le prime pagine arrivano dal lavoro che stai già facendo
Il piano qui sopra ha un passaggio costoso: copiare le risposte da email e riunioni. È il passaggio che fa SecondBrain 365: l'agente ha una propria identità e una propria email aziendale nel tuo Microsoft 365, e scrive il wiki come pagine sul tuo SharePoint.
Descrivi la struttura in un file di contesto, in linguaggio naturale — le stesse domande, raggruppate in sezioni, che prepareresti nella prima settimana. Poi lo coinvolgi nel lavoro di tutti i giorni: lo metti in copia in un thread, gli inoltri una risposta che hai già scritto, lo inviti a una riunione Teams, lo aggiungi a un gruppo Teams o condividi con lui un documento. Quello che si dice lì diventa pagine, collegate tra loro.
Scrive solo a partire da ciò che gli viene mostrato, quindi il wiki cresce con le domande reali del team invece che secondo un piano di cosa dovrebbe contenere. Puoi richiedere un'approvazione prima che venga pubblicata qualsiasi cosa, e ogni pagina resta modificabile a mano. Approfondisci cosa succede a un'email quando l'agente è in copia e cosa può leggere un nuovo collega nella prima settimana.
—One page per question people ask, titled the way they ask it.
—Keep how-to pages apart from policies.
—When a reply is forwarded, add it to the page it answers, with the date.
Plain language. Rewrite it whenever the work changes.
How do I…
- How do I get a new laptop?
- How do I connect to the VPN from home?
Policies
- Software you can install yourself
Known issues
- Meeting room screens — the workaround
—One page per supplier, with the contact and the contract dates.
—Keep who approves what in one page, linked to where it was decided.
—Record each change to the buying process as a dated decision.
Plain language. Rewrite it whenever the work changes.
Suppliers
- Office supplies — framework contract
- Cleaning services
Approvals
- Who approves what, by amount
Decisions
- New purchase request form — September
Three lines of rules instead of a page tree drawn in advance. The pages under each section are written from the replies, meetings and threads the agent was brought into.
FAQ
Domande sull'avvio di un wiki aziendale
Le risposte alle domande che vengono fatte più spesso a un team, con le parole che le persone usano per farle. Mission, organigrammi e pagine di benvenuto sono facili da scrivere e poco cercati. Una prima versione che risponde a venti domande vere vale più di una con la struttura completa e niente dentro.
Con pochi livelli, e con i nomi nel linguaggio di chi legge. Da tre a cinque sezioni per cominciare, titoli delle pagine scritti come la domanda a cui rispondono, e link tra le pagine invece dello stesso fatto copiato in due posti. Aggiungi una sezione quando ci sono abbastanza pagine che la richiedono, non prima.
Per ogni area, il team che fa il lavoro descritto dalle pagine, con una persona indicata per nome che decide dove vanno le cose e quale versione è giusta. Non chi ha installato lo strumento, e non un comitato: una responsabilità condivisa da tutti non la esercita nessuno.
Chiedendo loro di scrivere meno. Le persone spiegano già le cose nelle email, nelle riunioni e nelle chat; il wiki fallisce quando chiede la stessa spiegazione una seconda volta. Prendi le prime pagine da quello che hanno già scritto, dai loro il merito, e rispondi alle domande con un link: così chi contribuisce vede subito che la volta dopo non dovrà rispiegare.
Sì. Su SharePoint, dentro Microsoft 365, un wiki è un sito fatto di pagine moderne, salvate nella raccolta Pagine del sito e collegabili tra loro; i membri del sito con permesso di modifica possono aggiungere pagine. Se la tua azienda lavora su Microsoft 365, ce l'hai già. Quello che SharePoint non fornisce è il contenuto.
No. Scrive pagine a partire dalle email, dalle riunioni, dalle conversazioni Teams e dai documenti in cui lo coinvolgi, seguendo le regole del tuo file di contesto. Ciò che non è mai stato detto o scritto in un posto che può leggere resta nella testa delle persone finché qualcuno non lo mette per iscritto. Puoi richiedere un'approvazione prima che venga pubblicata qualsiasi cosa, e tutto resta modificabile.