Use One Knowledge Base for End-to-End Product Delivery

孤立運作會帶來實際的商業風險。 看看為什麼你的公司值得擁有一個真正的集中知識庫以提高效率。
Table of Contents

“我知道他們有做事情,我只是確切不知道那個事情是什麼。”

你聽過(或者老實說,說過)這些話的次數有多少次,從你的同事對另一個團隊或部門提及? 在我們日常工作中,很容易讓我們迷失在公司自己的角落,這有時會導致對我們的同行在公司的另一邊的工作方式缺乏了解,以幫助我們的業務運作。 這並非沒有道理:專注於自己的專業領域和責任會幫助每個人在自己的職能中成長。 但當視野變得如此狹隘,以至於團隊難以看到他們的工作對公司其他部分的影響,會發生什麼情況?

公司知識希望是跨職能的

當團隊將自己的職能放在真空中時,他們也往往會在真空中看到團隊的知識。 對於市場營銷團隊而言,這可能意味著買家角色或功能定位描述。 對於工程團隊,這可能意味著技術文檔或環境設置說明。 對於支持團隊,這可能意味著對常見問題的回答或功能故障的故障排除指南。 這些資源可能存在於各種工具中,這些工具個別團隊依賴,例如Google Drive、GitHub、Intercom等,可以由團隊內部的領導者/專家或集體擁有,專注於文檔編寫。

從表面上看,不同的團隊需要不同的文檔工具以最好地適應其工作流程是有道理的,但隨著我們深入挖掘,我們揭示了與在孤島中運作相關的真正商業風險。

knowledge-wants-to-be-cross-functional-internal.png

孤立知識如何影響運營

大多數文檔涉及< a href="https://www.getguru.com/blog/collaboration-and-communication-go-hand-in-hand/" id="">跨職能合作以某種方式進行。 讓我們通過一個示例來了解支持代理更新有關功能的幫助中心文章。 代理可能會從其團隊收集的常見問題開始,然後需要與工程團隊合作以獲得答案。 這些答案中的一些記錄在GitHub中,但大部分都存在於一位主題專家的腦海中。

一旦支持代理有了這些答案,他們可能還需要向其產品市場團隊確認,以確保他們使用的是正確的功能優勢術語。 產品市場團隊可能然後從他們的Google Drive發送一個資料表,其中包含去年度功能的啟動信息,可能已經過時。 最後,支持代理與銷售團隊進行檢查,以查看他們是否有任何額外問題要添加,如果有,他們則必須再次與工程團隊進行檢查。

當支持代理建立新的幫助中心文章時,他們與跨公司隊友進行了對話,所有人必須進入自己分開的知識通道尋找支持信息。 而這假設一路上所有事情都順利進行。 如果擁有該功能的主題專家工程師在那一周休假會發生什麼情況? 或者如果銷售團隊意識到他們有其他問題要添加,但這些問題分散在各個Slack頻道中呢? 隨著每一個路障,時間表被延長,知識洩漏和誤傳的機會越來越多。

整理公司信息。 隨時隨地訪問它。

選擇一個計劃

互聯知識的好處

現在,讓我們考慮一個替代場景——所有團隊共享一個地方來記錄和獲取重要的最新產品知識。 當支持代理最初聯繫工程團隊詢問問題時,工程團隊不需要擔心如果主題專家那周休假——他們之前已經通過共享知識庫分享了自己的專業知識。

而不是產品市場團隊發送可能過時的資料,自一年前寫的內容,他們訪問其更新的消息和定位信息,並每季度確認其準確性。 而不需要銷售團隊在Slack頻道中忙於找到之前已尋求解答的問題,他們將所有問題都記錄在一個共享平台上,這樣就可以輕鬆地發送過去。

這整個過程的好處在於,支持代理甚至可以獨立找到許多這些信息,而不必打斷他人的工作流,只需進行搜索。

當所有這些信息都保存在特定團隊的隔離工具中時,自助知識檢索根本不可能。

同事之間的實時協作角色將永遠不會被取消;畢竟,這些互動是幫助我們與彼此形成聯繫和共鳴的原因。 但在產品交付和啟用周期的許多階段中,存在可以在知識在所有團隊之間民主化時更高效地完成的任務。 知識尋求者和主題專家都可以在不受干擾地繼續其工作流,並且可以將其實時協作頻寬保留給更有意義和創造性的工作。

“我知道他們有做事情,我只是確切不知道那個事情是什麼。”

你聽過(或者老實說,說過)這些話的次數有多少次,從你的同事對另一個團隊或部門提及? 在我們日常工作中,很容易讓我們迷失在公司自己的角落,這有時會導致對我們的同行在公司的另一邊的工作方式缺乏了解,以幫助我們的業務運作。 這並非沒有道理:專注於自己的專業領域和責任會幫助每個人在自己的職能中成長。 但當視野變得如此狹隘,以至於團隊難以看到他們的工作對公司其他部分的影響,會發生什麼情況?

公司知識希望是跨職能的

當團隊將自己的職能放在真空中時,他們也往往會在真空中看到團隊的知識。 對於市場營銷團隊而言,這可能意味著買家角色或功能定位描述。 對於工程團隊,這可能意味著技術文檔或環境設置說明。 對於支持團隊,這可能意味著對常見問題的回答或功能故障的故障排除指南。 這些資源可能存在於各種工具中,這些工具個別團隊依賴,例如Google Drive、GitHub、Intercom等,可以由團隊內部的領導者/專家或集體擁有,專注於文檔編寫。

從表面上看,不同的團隊需要不同的文檔工具以最好地適應其工作流程是有道理的,但隨著我們深入挖掘,我們揭示了與在孤島中運作相關的真正商業風險。

knowledge-wants-to-be-cross-functional-internal.png

孤立知識如何影響運營

大多數文檔涉及< a href="https://www.getguru.com/blog/collaboration-and-communication-go-hand-in-hand/" id="">跨職能合作以某種方式進行。 讓我們通過一個示例來了解支持代理更新有關功能的幫助中心文章。 代理可能會從其團隊收集的常見問題開始,然後需要與工程團隊合作以獲得答案。 這些答案中的一些記錄在GitHub中,但大部分都存在於一位主題專家的腦海中。

一旦支持代理有了這些答案,他們可能還需要向其產品市場團隊確認,以確保他們使用的是正確的功能優勢術語。 產品市場團隊可能然後從他們的Google Drive發送一個資料表,其中包含去年度功能的啟動信息,可能已經過時。 最後,支持代理與銷售團隊進行檢查,以查看他們是否有任何額外問題要添加,如果有,他們則必須再次與工程團隊進行檢查。

當支持代理建立新的幫助中心文章時,他們與跨公司隊友進行了對話,所有人必須進入自己分開的知識通道尋找支持信息。 而這假設一路上所有事情都順利進行。 如果擁有該功能的主題專家工程師在那一周休假會發生什麼情況? 或者如果銷售團隊意識到他們有其他問題要添加,但這些問題分散在各個Slack頻道中呢? 隨著每一個路障,時間表被延長,知識洩漏和誤傳的機會越來越多。

整理公司信息。 隨時隨地訪問它。

選擇一個計劃

互聯知識的好處

現在,讓我們考慮一個替代場景——所有團隊共享一個地方來記錄和獲取重要的最新產品知識。 當支持代理最初聯繫工程團隊詢問問題時,工程團隊不需要擔心如果主題專家那周休假——他們之前已經通過共享知識庫分享了自己的專業知識。

而不是產品市場團隊發送可能過時的資料,自一年前寫的內容,他們訪問其更新的消息和定位信息,並每季度確認其準確性。 而不需要銷售團隊在Slack頻道中忙於找到之前已尋求解答的問題,他們將所有問題都記錄在一個共享平台上,這樣就可以輕鬆地發送過去。

這整個過程的好處在於,支持代理甚至可以獨立找到許多這些信息,而不必打斷他人的工作流,只需進行搜索。

當所有這些信息都保存在特定團隊的隔離工具中時,自助知識檢索根本不可能。

同事之間的實時協作角色將永遠不會被取消;畢竟,這些互動是幫助我們與彼此形成聯繫和共鳴的原因。 但在產品交付和啟用周期的許多階段中,存在可以在知識在所有團隊之間民主化時更高效地完成的任務。 知識尋求者和主題專家都可以在不受干擾地繼續其工作流,並且可以將其實時協作頻寬保留給更有意義和創造性的工作。

體驗 Guru 平台強大功能 - 進行我們的互動式產品導覽
進行導覽