Noi fondatori nel mondo B2B siamo spesso inammirati dai fondatori B2C, quando consideriamo le belle app che hanno creato e l'incredibile scala che hanno raggiunto con esse. Si sente parlare molto della “consumerizzazione dell'IT”, e molte aziende B2B traggono analogie con storie di successo dei consumatori. Quando fatto bene funziona molto bene. Salesforce è noto per fare riferimento ad analogie di consumatori come ispirazione dietro la loro strategia di prodotto per il loro CRM. Sembra che funzioni bene ;).

Ma nella maggior parte dei casi non funziona, semplicemente perché i lavori e le preoccupazioni degli esseri umani nelle loro vite personali sono fondamentalmente diversi dai loro lavori e preoccupazioni nelle loro vite lavorative. Un grande esempio è l'ondata di aziende che volevano essere “Facebook per le imprese” pensando che le persone posterebbero cose al lavoro solo perché è divertente. Ma al lavoro abbiamo dei compiti da svolgere, quindi il software che scegliamo di usare è scelto perché ci aiuta a svolgere i nostri doveri.

Un altro grande motivo per cui l'analogia fallisce è la scala. Ora ci sono miliardi di persone su Internet. Le più grandi imprese del mondo sono solo di 100.000 in dimensione. Diversi ordini di grandezza più piccoli. Quello che funziona nel mondo dei miliardi non si trasferirà senza soluzione di continuità nel mondo delle migliaia. Abbiamo già scritto su strumenti di Q&A aziendali e sul perché quel trasferimento non funziona. I wiki sono un altro grande esempio…

I wiki non sono dove lavori

Dopo che Google ha rilasciato il proprio Knowledge graph nel 2012, Wikipedia ha visto un declino del 21% delle visualizzazioni di pagina l'anno successivo.

Come puoi vedere nell'immagine sopra, Google ora inserisce informazioni pertinenti riguardo le ricerche direttamente nel flusso di lavoro della ricerca, quindi gli utenti non devono neanche fare clic su Wikipedia. Con un 1 su 4 ricerche che utilizza il knowledge graph, Google sta lentamente fornendo informazioni agli utenti nel contesto, il che contribuisce al declino della lettura di Wikipedia. Super utile perché questa preziosa conoscenza viene ora portata a noi senza dover lasciare la ricerca di Google.

Nell'impresa, questa nozione di conoscenza contestuale è altrettanto importante. Come dimostra il successo del knowledge graph, mentre un wiki aziendale può sembrare il modo più semplice per creare conoscenza, non è sicuramente il modo più semplice per trovare e consumare conoscenza. Al lavoro utilizziamo così tante app durante la giornata che a meno che un'app ci aiuti a svolgere il nostro lavoro, semplicemente non la utilizzeremo. È fuori vista, fuori mente. Così tanti progetti wiki vengono implementati al lavoro e poi vengono rapidamente dimenticati per questo motivo; un wiki o una base di conoscenza non dovrebbero essere visti come una meta, un'app, un portale. È un mezzo per un fine. Il fine è un lavoro che dobbiamo completare, la nostra base di conoscenza ci aiuta a portare a termine quel lavoro. Leggi di più su come Guru fa gestione della conoscenza a livello aziendale.

I wiki non sono costruiti per cambiamenti continui

Wikipedia funziona perché letteralmente ci sono centinaia di migliaia di contributori (980.176 in lingua inglese contributori solo a febbraio 2015). C'è una nozione chiamata “regola dell'1%” che dice che per ogni 1000 lettori in una comunità internet, avrai 1 contributore. Sebbene quel rapporto funzioni su scala per Wikipedia, sicuramente non funziona per le aziende.

Ha anche senso perché la maggior parte dei contenuti su Wikipedia non ha bisogno di cambiare una volta scritto. Molti contenuti riguardano cose discrete e eventi che sono accaduti nel passato — sono già accaduti.

Ma nelle aziende è totalmente diverso. La maggior parte dei contenuti nelle aziende cambierà. Dovrebbe cambiare. Pensa a questo; hai gli stessi concorrenti oggi che avevi un anno fa? 6 mesi fa? Alcuni di loro hanno rilasciato nuove funzionalità negli ultimi 3 mesi? Il tuo team di vendite dovrebbe essere a conoscenza di quelle nuove funzionalità? I wiki non sono costruiti per il cambiamento. Sono costruiti per grandi quantità di contenuti di lunga durata. Fantastici per fonti di conoscenza globali come Wikipedia, non sono il miglior adattamento per aziende in evoluzione.

I wiki non sono necessariamente accurati

In un enorme forum pubblico come Internet, il modo in cui si deriva l'accuratezza è un problema enorme e complesso. Wikipedia ha un processo di gestione delle modifiche per garantire che ciò che si vede sia accurato per quanto possibile, e anche quel sistema non è perfetto.

Al lavoro tuttavia è molto diverso. Anche nelle aziende più grandi del mondo, è molto più ragionevole sapere chi sono gli esperti su un dato soggetto, e quali gruppi o individui possono garantire l'accuratezza delle informazioni su prodotti, persone, processi, ecc. Nonostante ciò, i repository di conoscenza aziendale sono silenziosi su questo concetto di accuratezza e verifica. Sì, molto probabilmente sai quando il contenuto è stato aggiornato l'ultima volta. Potresti sapere chi ha aggiornato l'ultimo. Ma nella tua organizzazione che si affida a pochi creatori di conoscenza, i tuoi consumatori di conoscenza hanno bisogno di un chiaro timbro di approvazione per fidarsi di questo contenuto accurato.

Immagina un team di vendita che utilizza un wiki come base della propria conoscenza. I rappresentanti sanno anche quanto rapidamente cambia la conoscenza, e mentre potrebbero dare un'occhiata al wiki (o meno), non è chiaro chi ha verificato l'accuratezza del contenuto che trovano, o quando è stato verificato l'ultima volta. Quindi, per essere sicuri, contattano un ingegnere di vendita o si avvicinano a un manager di prodotto e gli danno un colpetto sulla spalla. Mentre il rappresentante pensa di arrivare alla soluzione più velocemente, gli esperti del soggetto sbuffano sottovoce, rispondendo alla stessa domanda 3 volte in un giorno da persone diverse. E distrarre gli esperti costa denaro; uno studio recente mostra che ci vogliono in media 23 minuti e 15 secondi per recuperare da un'interruzione! Messaggi one-off e colpetti sulla spalla non scalano, specialmente quando alcuni esperti vengono coinvolti da decine e infine centinaia o migliaia di colleghi che necessitano tutti del loro aiuto. Quindi, anche se la conoscenza potrebbe essere nel wiki, non importa. I tuoi dipendenti non si fidano di essa. Senza quella fiducia, il tuo wiki fallisce.

Quindi qual è la soluzione?

La consapevolezza del contesto è il futuro dei repository di conoscenza aziendale

Come accennato, il Knowledge Graph di Google porta contenuti chiave da fonti come Wikipedia e li incorpora direttamente accanto ai risultati della tua ricerca, quindi non devi nemmeno aprire una nuova finestra. Al lavoro, pensa ai vari aspetti della conoscenza di cui abbiamo bisogno per svolgere il nostro lavoro, e poi pensa a quando ne abbiamo bisogno.

• Voglio le ultime informazioni competitive quando mi sto preparando per vendere a un cliente che so essere interessato anche a quella azienda.
• Voglio sapere come usare questa app quando sto cercando di usarla.
• Voglio sapere fatti rapidi su questo partner quando mi viene chiesto di loro dal mio cliente
• Voglio il nostro ultimo messaggio di prodotto quando sto aggiornando i nostri vari canali social media.

Nota che in tutti questi esempi c'è un lavoro da svolgere e la conoscenza referenziale è necessaria per completare il compito. Questa consapevolezza del contesto permette alla giusta conoscenza di emergere al momento del bisogno, direttamente nel flusso di lavoro della persona che svolge il compito. I consumatori di conoscenza cercano di meno, mentre gli esperti di conoscenza ricevono meno messaggi one-off e colpetti sulla spalla, così possono concentrarsi sull'esecuzione dei loro compiti specifici.

Il contenuto verificato costruisce fiducia

Tutti i contenuti di cui i membri del team si affidano per svolgere i loro compiti devono essere verificati da esperti del team a intervalli regolari. Per chiunque cerca e naviga in questo contenuto, dovrebbe essere molto chiaro chi ha verificato l'accuratezza del contenuto, quando è stato verificato l'ultima volta e con quale frequenza viene revisionato.

Altrettanto importante, gli esperti dovrebbero essere automaticamente ricordati di verificare i contenuti man mano che invecchiano, in modo che non debbano pensare di farlo. La frequenza di verifica dovrebbe essere determinata dalla natura della conoscenza catturata. Se un'azienda rilascia nuove versioni dei propri prodotti trimestralmente, allora la conoscenza su quel prodotto dovrebbe essere revisionata trimestralmente.

Quando un membro del team trova contenuti di cui ha bisogno e può chiaramente vedere che è stato recentemente verificato da un esperto, è molto meno probabile che si contatti un altro membro del team. Questa è vera scalabilità.

Sfrutta le analisi per vedere come questa conoscenza influisce sulla tua attività

L'ultimo, e probabilmente più importante aspetto, è misurare come queste basi di conoscenza influenzano le metriche chiave per la tua azienda. A un alto livello, le metriche di utilizzo dovrebbero essere tracciate per ciascun contenuto di conoscenza archiviato; quante volte sono state visualizzate, copiate o aggiunte ai preferiti, in modo da poter vedere il contenuto più prezioso che il tuo team utilizza.

I membri del team dovrebbero anche essere notificati proattivamente riguardo le lacune nella conoscenza del tuo team mostrando i termini di ricerca che il tuo team sta utilizzando che non restituiscono risultati. In questo modo puoi aggiungere questa conoscenza mancante e far sapere al tuo team non appena è disponibile.

Infine, pensa a come puoi collegare queste metriche di utilizzo alle tue applicazioni aziendali chiave. Possiamo collegare l'uso del contenuto a chiusure più complete? Cicli di vendita abbreviati? I nuovi membri del team vengono inseriti più rapidamente?

Quindi sia che si tratti di approfondimenti tattici, "i miei membri del team stanno usando la nostra base di conoscenza?", oppure strategici, "il mio team sta eseguendo meglio grazie alla mia base di conoscenza?" è una parte spesso trascurata ma critica della tua strategia di implementazione.