Rethinking Your Knowledge Base Architecture: Why Bite-Size is Best
當Google在2012年於搜尋引擎結果頁 (SERPs) 中推出其知識圖譜時,它的特色摘要 (那些短小且相關的數據點,位於頁面頂部) 成為需要快速答案的人的首選。 依賴於從維基百科等網站刮取數據的Google,可以利用他人編譯的數據來保持你在其生態系統中—這對以廣告為驅動的收入流來說是一種助益。 但還發生了其他事情:維基百科的流量下降了。 雖然任何統計學家都有權提醒我們相關不等於或暗示因果關係,但我們也可以從自己的行為中尋找發生了什麼的線索。 如果你需要知道的只是,比如說,今年誰獲得了諾貝爾物理獎,而答案就在頁面頂部,那麼就沒有必要繼續搜尋其他1.05億個結果。

我們直觀上知道這一點,但在我們的知識入口網站時,我們經常將它們設置為存儲庫,而不是作為一種方式,輕鬆揭示我們所需的信息。 這就是為什麼—而這可能很難接受—我們需要徹底重新思考我們整個的方式。
如果你的企業知識入口網站與大多數相似,當你有問題時,你必須知道a) 你正在尋找的確切內容或b) 你必須在多頁常見問題或PDF中搜尋數百(或數千!)個字以找到埋藏在其中的答案。
Control-F在使這種設置能夠運作中起到了重要作用,但為什麼你需要使用有效上是一種變通方法,只是為了得到一個簡單的答案? 這不僅使員工承擔了挖掘知識的負擔(這可能需要花費不少時間),而且這意味著每當那些知識有任何變化時,公司必須上傳一個全新的PDF、視頻或常見問題。 這浪費了時間—和預算。
更好的解決方案是徹底重新思考你的知識架構,並轉向簡潔、便於消耗(且便於更新)的知識片段。
搜尋與救助
“看,這並不好,”你現在可能會說,“它能完成工作!” 那麼讓我們談談這個。 這還不是我們第一次在Guru博客上談論這個。 將近三年前,我們指出:
銷售人員花費多達三分之一的時間來尋找做事所需的信息。 隨需應變的信息是必要的,而當前的解決方案並不是為隨需應變的世界而設計的。 文件和維基強迫你使用Control+F來尋找單詞,然後讓你自己拼湊答案。
如果你正在與客戶聊天,需要回答一個問題,你就沒有時間通過當前繁瑣且低效的過程來找到答案。 搜尋將含有正確答案的文檔,打開該文檔,搜尋一個關鍵字,而在經過這一切後,出現的並不是你的答案,而是你輸入的單詞出現了十五次。 為了獲得正確的信息,你必須點擊所有選項,而此時你的客戶正在等待回答。

但這不僅僅是浪費了寶貴的幾秒鐘。 較長的內容比起較短的內容更難搜尋。 讓我們將此從知識管理領域轉移到一個所有人都能夠感同身受的領域:我們如何參與消遣內容。
這裡有一個問題,你可能知道或不知道答案:《辛普森家庭》是哪一年首播的? 你打開維基百科,輸入“辛普森家庭”並獲得這一頁,裡面有超過17000個字。 你依賴於你舊有的控制-F搜尋“首播”,結果是這樣:

等一下,什麼? 結果你需要搜尋“發行”:

不僅需要你確切知道該頁面(我們應該指出這是高度組織的)如何設置,還需要你確切知道作家用來表示開始日期的術語。 同時,如果你去Google,隨便輸入“辛普森首播”,你會得到:

搜尋“辛普森發布”,你會得到相同的信息,儘管以稍微不同的方式呈現:

無論哪種方式,結果都是有用的、快速的,最重要的是,無論你使用的確切措辭如何,都很容易找到。 你甚至不必使用Control-F。
我仍然沒有找到我正在尋找的東西
現在,讓我們將這一討論重新導向到知識管理。 你的緊湊、10pt字體、三頁的PDF和48項常見問題非常好—但對於節省列印成本是有利的。 它們對於讓你的員工專注於他們需要知道的內容並不好,無論是關於入職時的福利信息、產品文檔的推出,還是試圖找到合適的單頁分發。
有趣的是,隨著我們數字化知識越多,我們不得不依賴於變通方法來實際精確找到我們必須尋找的東西。 那些你年輕時十分厭惡的教科書? 索引是你花最多時間的部分。 畢竟,它告訴你正確位置在哪裡以查找所需的內容—並忽略不需要的內容—通常還包括上下文細分(例如:登陸月球、蘇聯的反應)。
現在呢? 如果我們讓計算機和人工智能更有效率地工作,那麼我們自己卻讓自己去做工作。 將你的知識存儲成便於搜尋的碎片意味著,任何上下文搜尋都能更快發生。 許多公司談論他們在企業搜尋中的機器學習和人工智能的能力—但如果它們只能返回一篇員工仍需搜索的30頁文檔,那麼所有這些解決方案都是無用的。
如果文檔不是為了打印而設計的,那麼就沒有理由不將其拆分成個別組件,以改善知識參考經驗。 否則,作為公司,你可能正在支付你的員工進行“安全”一詞的50個高亮例子的手動搜索工作—而且他們仍可能無法找到他們所尋找的內容,因為他們不能在Control-F搜尋中添加更多上下文。
這種方法不僅有利於那些添加和維護知識的人;這對你的收入團隊也是一個巨大的幫助。 當一名銷售人員試圖促成交易時,你希望她可以立即訪問具體信息,還是...在45個要點的銷售準備文檔上執行搜尋? 如果你的客戶支持代表接到一通憤怒的電話,你希望他拼命地在常見問題中翻找答案,還是授權他只調出相關部分?

建立可持續的知識基礎
我們已經看到便於消耗的知識卡對我們有效,這就是為什麼我們知道它們也能對你有效。 這不僅使快速且輕鬆地找到你真正需要的信息,還意味著知識維護變得更加簡單。 了解更多有關實施公司級知識管理系統的好處。
通過實施短格式知識庫架構方法,你可以擺脫不斷需要上傳全新文件的麻煩。 在20頁文檔中的一句話更新意味著你必須重新上傳整個文檔,並確保每個人都知道這一變更,因為它隱藏在第12頁的第九條要點中。
相對而言,四句話中的一句話更新可以在幾秒鐘內完成。 這種方法使驗證便於消耗的信息,以確保其準確性變得比驗證較長文件要容易得多,因為每一條知識都可以單獨驗證為正確—而驗證最終是創建信賴的知識網絡的核心。
當然,我們知道這樣有點諷刺的是,這麼多字來解釋為什麼短內容對於知識架構是更好的方法,因此這就是tl;dr:便於消耗的內容更易於增加、更易於更新、更易於驗證和更易於搜索。 把它想成詞彙卡片和字典:一個擁有所有東西卻不會幫助你為下周的測驗做準備,而另一個正是你需要的,並且可以靈活到可以在千百種不同的方式下重新組織。 你會選擇哪一個?

