Rethinking Your Knowledge Base Architecture: Why Bite-Size is Best
Om du förlitar dig på Control-F för att söka igenom fler sidor dokument i ditt företags kunskapsförvar, är det dags att tänka om kring din kunskapsarkitektur helt och hållet – och gå mot kortformade, lättillgängliga, distinkta kunskapsbitar.
När Google introducerade sin Knowledge Graph på sökmotorresultatsidor (SERPs) 2012, blev dess utvalda utdrag (de korta, relevanta datapunkterna som finns högst upp på sidan) det självklara valet för dem som behövde ett snabbt svar. Google var starkt beroende av att hämta data från sajter som Wikipedia, och kunde utnyttja data som sammanställts av andra för att hålla dig i sitt ekosystem - en tillgång för en reklambaserad intäktsström. Men något annat hände också: trafiken till Wikipedia minskade. Även om vilken statistiker som helst har rätt att påminna oss om att korrelation inte är likvärdig eller implicerar kausalitet, kan vi också se på vårt eget beteende för att få en känsla av vad som hände. Om allt du behöver veta är, säg, vem som vann Nobelpriset i fysik i år och svaret finns högst upp på sidan, finns det ingen anledning att fortsätta söka igenom de andra 105 miljoner resultaten.
Vi vet det här instinktivt, men när det gäller våra kunskapsportaler sätter vi dem ofta upp för att fungera som förvar, inte som ett sätt att enkelt få fram den information vi behöver. Det är därför - och det kan vara svårt att höra - vi behöver tänka om helt och hållet kring vårt tillvägagångssätt.
Om din företags kunskapsportal är som de flesta, när du har en fråga, måste du veta a) exakt vad du letar efter eller b) du måste söka igenom hundratals (eller tusentals!) ord i fler sidor FAQ:er eller PDF:er för att hitta ett svar som är begravt någonstans i dem.
Control-F har varit avgörande för att få detta upplägg att fungera, men varför ska du behöva använda vad som i praktiken är en omväg bara för att få ett enkelt svar? Det skapar inte bara en belastning för anställda att gräva fram kunskap (vilket kan ta en ganska betydande mängd tid), det betyder också att varje gång någon av den kunskapen ändras, måste företaget ladda upp en helt ny PDF, video eller FAQ. Det slösar tid - och budgetar.
Den bättre lösningen är att tänka om helt och hållet kring din kunskapsarkitektur och gå mot kortformade, lättillgängliga (och uppdateringsbara), distinkta kunskapsbitar.
Sök och rädda
“Titta, det är inte så illa,” säger du förmodligen just nu, “det fungerar!” Så låt oss prata om det. Detta är inte ens första gången vi har pratat om detta på Guru-bloggen. För nästan tre år sedan, vi påpekade att:
Säljare spenderar upp till en tredjedel av sina dagar på att leta efter information som behövs för att göra sina jobb. Information behövs på begäran, och de nuvarande lösningarna är inte byggda för en efterfrågad värld. Dokument och wikis tvingar dig att använda Control+F för att hitta ord och sedan lämna dig att pussla ihop svaren.
Om du chattar med en kund och behöver svara på en fråga, har du inte tid att gå igenom den aktuella långa och ineffektiva processen för att hitta svaret. Att söka efter dokumentet som har rätt svar, öppna det dokumentet, söka efter ett nyckelord, och efter allt detta ser du inte svaret utan istället ser du att ordet du skrev visas femton gånger. För att få den korrekta informationen måste du klicka dig igenom alla alternativ, under tiden väntar din kund på sitt svar.
Men det går längre än att bara slösa värdefulla sekunder. Längre innehåll är helt enkelt svårare att söka i än kortare innehåll. Låt oss ta detta ur området kunskapsförvaltning och in i ett vi alla kan relatera till: hur vi engagerar oss med innehåll för nöjes skull.
Här är en fråga du kanske eller kanske inte känner till svaret på: Vilket år hade The Simpsons premiär? Du slår upp Wikipedia, skriver in “The Simpsons” och får denna sida med över 17 000 ord. Du förlitar dig på din gamla räddare Control-F och söker efter “premiär” och så här blir det:
Vänta, vad? Visar sig att du behövde söka efter “utgivning”:
Inte bara behövde du veta exakt hur denna (mycket organiserade, ska vi påpeka) sidan är uppbyggd, du måste veta exakt terminologin som skribenterna har använt för att indikera ett startdatum. Samtidigt, om du går till Google och helt enkelt skriver in “Simpsons premiär” får du detta:
Sök efter “Simpsons utgivning” och du får samma information, om än presenterad lite annorlunda:
I båda fallen är resultatet hjälpsamt, snabbt och, viktigast av allt, lätt att hitta oavsett exakt formulering du har använt. Du behövde inte ens använda Control-F.
Jag har fortfarande inte hittat vad jag letar efter
Nu, låt oss flytta denna diskussion tillbaka mot kunskapsförvaltning. Dina tätt sittande, 10pt typsnitt, tre-sidiga PDF:er och 48-punkters FAQ:er är bra - för att spara på tryckkostnader. De är inte bra för att enkelt fokus på exakt vad dina anställda behöver veta, oavsett om vi pratar om förmånsinformation vid onboarding, produktinformation vid lansering, eller till och med försöker hitta rätt informationsblad att distribuera.
Det är roligt nog, ju mer av vår kunskap vi har digitaliserat, desto mer har vi fått förlita oss på omvägar för att faktiskt fokusera på vad vi har behövt hitta. De mycket avskydda läroböckerna från din ungdom? Indexet var den del med vilken du spenderade mest kvalitetstid. Det sa dig helt enkelt exakt var du skulle hitta vad du behövde - och att ignorera vad du inte behövde - och innehöll vanligtvis också kontextuella uppdelningar (ex: Månlandningen, Sovjetunionens reaktion på).
Nu? Vi gör oss själva att utföra arbete som datorer och AI kan göra mer effektivt, om vi bara låter dem. Att lagra din kunskap i bitstora delar innebär att all kontextuell sökning kan ske mycket, mycket snabbare. Många företag pratar om sina maskininlärnings- och AI-funktioner i företags sökning - men alla dessa lösningar är värdelösa om allt de kan göra är att ta upp ett 30-sidigt dokument som dina anställda fortfarande måste söka igenom.
Om dokument inte är avsedda att skrivas ut, finns det ingen anledning att inte dela upp dem i individuella komponenter för att skapa en bättre kunskapsreferenserfarenhet. Annars, som företag, kan du betala dina anställda för att göra det manuella arbetet med att söka igenom 50 markerade förekomster av ordet "säkerhet" i ett produkt dokument - och de kanske fortfarande inte hittar vad de letar efter, eftersom de inte kan sätta mer kontext i en Control-F-sökning.
Denna metod gynnar inte bara de som lägger till och underhåller kunskap; det är en stor hjälp för ditt intäkts team också. När en försäljare försöker stänga en affär, skulle du hellre att hon har omedelbar tillgång till specifik information eller ... köra ett Sök-kommando på ett 45-punkts dokument för försäljningsberedskap? Om din kundsupportrepresentant är på den mottagande sidan av ett argt telefonsamtal, vill du att han febrilt ska leta igenom en FAQ efter ett svar, eller ge honom möjlighet att plocka fram just den relevanta sektionen?
Bygga en hållbar kunskapsgrund
Vi har sett att bitstora kunskapskort fungerar för oss, vilket är varför vi vet att de kan fungera för dig också. Inte bara gör det att hitta den information du verkligen behöver snabbare och enklare, det innebär också att underhåll av kunskap är mycket enklare. Lär dig mer om fördelarna med att anta en företagsomfattande kunskapsförvaltningssystem.
Genom att implementera en kortform metod för kunskapsbas arkitektur, slipper du ständigt behöva ladda upp helt ny dokumentation. En enmeninguppdatering i ett 20-sidigt dokument innebär att du måste ladda upp hela dokumentet igen och se till att alla är medvetna om ändringen, då den är begravd i den nionde punkten på sidan 12.
Alternativt kan en enmeninguppdatering i en fyrmeningstext av kunskap ske på några sekunder. Denna metod gör också att det är mycket enklare att verifiera bitstort innehåll för att säkerställa dess noggrannhet än vad det är att verifiera längre dokument, då varje kunskapsdel kan verifieras individuellt som korrekt - och verifiering är i slutändan kärnan i att skapa ett kunskapsnätverk som alla kan lita på.
Visst, vi vet att, ironiskt nog, detta är mycket ord för att förklara varför kort innehåll är en bättre metod för kunskapsarkitektur, så här är tl;dr: bitstort innehåll är enklare att lägga till, enklare att uppdatera, enklare att verifiera och enklare att söka. Tänk på det som ordfärdiga flashkort vs. ordboken: en har allt men kommer inte att hjälpa dig förbereda dig för nästa veckas prov, medan den andra är just vad du behöver för att ta dig igenom provet, kan kompletteras för att få dig igenom mittermin och slutprov, och är tillräckligt flexibel för att omorganiseras på en miljon olika sätt. Vilken skulle du välja?
När Google introducerade sin Knowledge Graph på sökmotorresultatsidor (SERPs) 2012, blev dess utvalda utdrag (de korta, relevanta datapunkterna som finns högst upp på sidan) det självklara valet för dem som behövde ett snabbt svar. Google var starkt beroende av att hämta data från sajter som Wikipedia, och kunde utnyttja data som sammanställts av andra för att hålla dig i sitt ekosystem - en tillgång för en reklambaserad intäktsström. Men något annat hände också: trafiken till Wikipedia minskade. Även om vilken statistiker som helst har rätt att påminna oss om att korrelation inte är likvärdig eller implicerar kausalitet, kan vi också se på vårt eget beteende för att få en känsla av vad som hände. Om allt du behöver veta är, säg, vem som vann Nobelpriset i fysik i år och svaret finns högst upp på sidan, finns det ingen anledning att fortsätta söka igenom de andra 105 miljoner resultaten.
Vi vet det här instinktivt, men när det gäller våra kunskapsportaler sätter vi dem ofta upp för att fungera som förvar, inte som ett sätt att enkelt få fram den information vi behöver. Det är därför - och det kan vara svårt att höra - vi behöver tänka om helt och hållet kring vårt tillvägagångssätt.
Om din företags kunskapsportal är som de flesta, när du har en fråga, måste du veta a) exakt vad du letar efter eller b) du måste söka igenom hundratals (eller tusentals!) ord i fler sidor FAQ:er eller PDF:er för att hitta ett svar som är begravt någonstans i dem.
Control-F har varit avgörande för att få detta upplägg att fungera, men varför ska du behöva använda vad som i praktiken är en omväg bara för att få ett enkelt svar? Det skapar inte bara en belastning för anställda att gräva fram kunskap (vilket kan ta en ganska betydande mängd tid), det betyder också att varje gång någon av den kunskapen ändras, måste företaget ladda upp en helt ny PDF, video eller FAQ. Det slösar tid - och budgetar.
Den bättre lösningen är att tänka om helt och hållet kring din kunskapsarkitektur och gå mot kortformade, lättillgängliga (och uppdateringsbara), distinkta kunskapsbitar.
Sök och rädda
“Titta, det är inte så illa,” säger du förmodligen just nu, “det fungerar!” Så låt oss prata om det. Detta är inte ens första gången vi har pratat om detta på Guru-bloggen. För nästan tre år sedan, vi påpekade att:
Säljare spenderar upp till en tredjedel av sina dagar på att leta efter information som behövs för att göra sina jobb. Information behövs på begäran, och de nuvarande lösningarna är inte byggda för en efterfrågad värld. Dokument och wikis tvingar dig att använda Control+F för att hitta ord och sedan lämna dig att pussla ihop svaren.
Om du chattar med en kund och behöver svara på en fråga, har du inte tid att gå igenom den aktuella långa och ineffektiva processen för att hitta svaret. Att söka efter dokumentet som har rätt svar, öppna det dokumentet, söka efter ett nyckelord, och efter allt detta ser du inte svaret utan istället ser du att ordet du skrev visas femton gånger. För att få den korrekta informationen måste du klicka dig igenom alla alternativ, under tiden väntar din kund på sitt svar.
Men det går längre än att bara slösa värdefulla sekunder. Längre innehåll är helt enkelt svårare att söka i än kortare innehåll. Låt oss ta detta ur området kunskapsförvaltning och in i ett vi alla kan relatera till: hur vi engagerar oss med innehåll för nöjes skull.
Här är en fråga du kanske eller kanske inte känner till svaret på: Vilket år hade The Simpsons premiär? Du slår upp Wikipedia, skriver in “The Simpsons” och får denna sida med över 17 000 ord. Du förlitar dig på din gamla räddare Control-F och söker efter “premiär” och så här blir det:
Vänta, vad? Visar sig att du behövde söka efter “utgivning”:
Inte bara behövde du veta exakt hur denna (mycket organiserade, ska vi påpeka) sidan är uppbyggd, du måste veta exakt terminologin som skribenterna har använt för att indikera ett startdatum. Samtidigt, om du går till Google och helt enkelt skriver in “Simpsons premiär” får du detta:
Sök efter “Simpsons utgivning” och du får samma information, om än presenterad lite annorlunda:
I båda fallen är resultatet hjälpsamt, snabbt och, viktigast av allt, lätt att hitta oavsett exakt formulering du har använt. Du behövde inte ens använda Control-F.
Jag har fortfarande inte hittat vad jag letar efter
Nu, låt oss flytta denna diskussion tillbaka mot kunskapsförvaltning. Dina tätt sittande, 10pt typsnitt, tre-sidiga PDF:er och 48-punkters FAQ:er är bra - för att spara på tryckkostnader. De är inte bra för att enkelt fokus på exakt vad dina anställda behöver veta, oavsett om vi pratar om förmånsinformation vid onboarding, produktinformation vid lansering, eller till och med försöker hitta rätt informationsblad att distribuera.
Det är roligt nog, ju mer av vår kunskap vi har digitaliserat, desto mer har vi fått förlita oss på omvägar för att faktiskt fokusera på vad vi har behövt hitta. De mycket avskydda läroböckerna från din ungdom? Indexet var den del med vilken du spenderade mest kvalitetstid. Det sa dig helt enkelt exakt var du skulle hitta vad du behövde - och att ignorera vad du inte behövde - och innehöll vanligtvis också kontextuella uppdelningar (ex: Månlandningen, Sovjetunionens reaktion på).
Nu? Vi gör oss själva att utföra arbete som datorer och AI kan göra mer effektivt, om vi bara låter dem. Att lagra din kunskap i bitstora delar innebär att all kontextuell sökning kan ske mycket, mycket snabbare. Många företag pratar om sina maskininlärnings- och AI-funktioner i företags sökning - men alla dessa lösningar är värdelösa om allt de kan göra är att ta upp ett 30-sidigt dokument som dina anställda fortfarande måste söka igenom.
Om dokument inte är avsedda att skrivas ut, finns det ingen anledning att inte dela upp dem i individuella komponenter för att skapa en bättre kunskapsreferenserfarenhet. Annars, som företag, kan du betala dina anställda för att göra det manuella arbetet med att söka igenom 50 markerade förekomster av ordet "säkerhet" i ett produkt dokument - och de kanske fortfarande inte hittar vad de letar efter, eftersom de inte kan sätta mer kontext i en Control-F-sökning.
Denna metod gynnar inte bara de som lägger till och underhåller kunskap; det är en stor hjälp för ditt intäkts team också. När en försäljare försöker stänga en affär, skulle du hellre att hon har omedelbar tillgång till specifik information eller ... köra ett Sök-kommando på ett 45-punkts dokument för försäljningsberedskap? Om din kundsupportrepresentant är på den mottagande sidan av ett argt telefonsamtal, vill du att han febrilt ska leta igenom en FAQ efter ett svar, eller ge honom möjlighet att plocka fram just den relevanta sektionen?
Bygga en hållbar kunskapsgrund
Vi har sett att bitstora kunskapskort fungerar för oss, vilket är varför vi vet att de kan fungera för dig också. Inte bara gör det att hitta den information du verkligen behöver snabbare och enklare, det innebär också att underhåll av kunskap är mycket enklare. Lär dig mer om fördelarna med att anta en företagsomfattande kunskapsförvaltningssystem.
Genom att implementera en kortform metod för kunskapsbas arkitektur, slipper du ständigt behöva ladda upp helt ny dokumentation. En enmeninguppdatering i ett 20-sidigt dokument innebär att du måste ladda upp hela dokumentet igen och se till att alla är medvetna om ändringen, då den är begravd i den nionde punkten på sidan 12.
Alternativt kan en enmeninguppdatering i en fyrmeningstext av kunskap ske på några sekunder. Denna metod gör också att det är mycket enklare att verifiera bitstort innehåll för att säkerställa dess noggrannhet än vad det är att verifiera längre dokument, då varje kunskapsdel kan verifieras individuellt som korrekt - och verifiering är i slutändan kärnan i att skapa ett kunskapsnätverk som alla kan lita på.
Visst, vi vet att, ironiskt nog, detta är mycket ord för att förklara varför kort innehåll är en bättre metod för kunskapsarkitektur, så här är tl;dr: bitstort innehåll är enklare att lägga till, enklare att uppdatera, enklare att verifiera och enklare att söka. Tänk på det som ordfärdiga flashkort vs. ordboken: en har allt men kommer inte att hjälpa dig förbereda dig för nästa veckas prov, medan den andra är just vad du behöver för att ta dig igenom provet, kan kompletteras för att få dig igenom mittermin och slutprov, och är tillräckligt flexibel för att omorganiseras på en miljon olika sätt. Vilken skulle du välja?
Upplev kraften i Guru-plattformen förstahands - ta vår interaktiva produktturné
