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

サイロで運営することには実際のビジネスリスクがあります。 効率的であるために、あなたの会社が真の中央集権的知識ベースを持つ必要がある理由を見てみましょう。
Table of Contents

「彼らが何かをしているのは知っていますが、それが一体何のことなのか正確には分かりません。」

あなたの同僚が別のチームや部署についてこれらの言葉をどう言ったか(または正直に言って、あなたが言ったか)を何回聞いたことがありますか? 私たちは日々の仕事の中で自社の隅々に埋もれてしまうことが簡単です。それが時には、他の部署の仲間が私たちのビジネスにどのように貢献しているのかを理解できなくなる原因となります。 それには正当な理由があります:自分の専門分野や責任に集中することで、誰もが自分の機能において成長できます。 しかし、その視点が狭くなりすぎると、チームが自分たちの仕事が他の会社にどのように影響を与えるかを見るのに苦労することになります。

会社の知識は横断的になることを望んでいます

チームがそれぞれの機能を空白の中で見ると、彼らのチームの知識も同様に空白の中で見られがちです。 マーケティングチームにとって、これは購入者ペルソナや機能のポジショニング説明を意味するかもしれません。 エンジニアリングチームにとって、これは技術文書や環境設定手順を意味するかもしれません。 サポートチームにとって、これはFAQへの回答や機能バグのトラブルシューティングガイドを意味するかもしれません。 これらのリソースは、Google Drive、GitHub、Intercomなど、各チームが依存するツールのいずれかに存在する可能性があり、共同で使用されるか、文書化に特化したリーダーや専門家が所有している可能性があります。

表面的には、異なるチームがそれぞれのワークフローに最適な異なる文書ツールを必要とすることは理解できますが、さらに掘り下げると、運営のサイロに関連する本当のビジネスリスクが明らかになります。

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

サイロ化した知識が業務に与える影響

ほとんどの文書作成は横断的なコラボレーションを含みます。 サポートエージェントが機能に関するヘルプセンター記事を更新する例を見てみましょう。 エージェントは、自分のチームが集めたFAQから始め、その後、回答を得るためにエンジニアリングチームと連携する必要があります。 その回答のいくつかはGitHubに文書化されていますが、ほとんどはある主題の専門家の頭の中に存在します。

サポートエージェントがその回答を持っているとき、機能の利点に正しい用語を使用しているか確認するために、製品マーケティングチームと確認する必要があるかもしれません。 製品マーケティングチームは、その後、昨年の機能の立ち上げ時のメッセージが含まれている可能性があるGoogle Driveからのワンシートを送信するかもしれません。 最終的に、サポートエージェントは、彼らが追加の質問を追加したいかどうかを営業チームに確認し、もしそうであれば、再びエンジニアリングチームに確認しなければならないでしょう。

サポートエージェントが新しいヘルプセンター記事を作成するまでに、彼らは会社全体のチームメンバーとの会話を重ね、それぞれが自分の知識のチャンネルに入って情報を見つけなければなりませんでした。 そして、それはすべてがスムーズに進むと仮定した場合です。 もし、機能の主題の専門家であるエンジニアがその週に休暇に行っていたら、どうなるでしょうか? または、営業チームが追加の質問を追加したいと気づいた場合、それがさまざまなSlackチャンネルに散らばっている場合は? あらゆる問題が発生するたびに、タイムラインは引き延ばされ、知識漏洩や誤解の機会が増えていきます。

会社の情報を整理する。 どこでもアクセスできる。

プランを選択する

相互接続された知識の利点

さあ、すべてのチームが重要な最新の製品知識を文書化し、アクセスする場所を共有するという別のシナリオを考えてみましょう。 サポートエージェントが最初にエンジニアリングチームに問い合わせる際、SMEがその週に休暇に行っているかどうかを心配する必要はありません。事前に、彼らは共通の知識ベースを通じて他のチームとその専門知識を共有しているからです。

製品マーケティングチームが、昨年書かれた情報が古くなっているかもしれない情報を送信する代わりに、彼らは四半期ごとに正確性を検証する最新のメッセージとポジショニング情報にアクセスします。 営業チームがSlackチャンネルを通じて、以前に求めた答えを見つけるために走り回るのではなく、彼らはすべての質問を共有プラットフォームに文書化しています。

このプロセス全体の良い点は、サポートエージェントが他の人をワークフローから外すことなく、自分で多くのこの情報を見つけることができるということです。

すべての情報がチーム固有のサイロ化されたツールに保持されている場合、セルフサービスの知識取得は単に不可能です。

同僚間のリアルタイムのコラボレーションの役割は決して排除されることはありません。結局のところ、それらの相互作用が私たちが互いに関係を形成し、共感を持つのを助けるのです。 しかし、製品の提供と実現サイクルの多くのフェーズにおいて、知識がすべてのチームに普及しているときに、はるかに効率的に完了できるタスクが存在します。 知識を求める人と主題の専門家の両方が、作業の流れを中断することなく続行でき、リアルタイムのコラボレーションの帯域幅をより意義のある創造的な作業に節約できます。

「彼らが何かをしているのは知っていますが、それが一体何のことなのか正確には分かりません。」

あなたの同僚が別のチームや部署についてこれらの言葉をどう言ったか(または正直に言って、あなたが言ったか)を何回聞いたことがありますか? 私たちは日々の仕事の中で自社の隅々に埋もれてしまうことが簡単です。それが時には、他の部署の仲間が私たちのビジネスにどのように貢献しているのかを理解できなくなる原因となります。 それには正当な理由があります:自分の専門分野や責任に集中することで、誰もが自分の機能において成長できます。 しかし、その視点が狭くなりすぎると、チームが自分たちの仕事が他の会社にどのように影響を与えるかを見るのに苦労することになります。

会社の知識は横断的になることを望んでいます

チームがそれぞれの機能を空白の中で見ると、彼らのチームの知識も同様に空白の中で見られがちです。 マーケティングチームにとって、これは購入者ペルソナや機能のポジショニング説明を意味するかもしれません。 エンジニアリングチームにとって、これは技術文書や環境設定手順を意味するかもしれません。 サポートチームにとって、これはFAQへの回答や機能バグのトラブルシューティングガイドを意味するかもしれません。 これらのリソースは、Google Drive、GitHub、Intercomなど、各チームが依存するツールのいずれかに存在する可能性があり、共同で使用されるか、文書化に特化したリーダーや専門家が所有している可能性があります。

表面的には、異なるチームがそれぞれのワークフローに最適な異なる文書ツールを必要とすることは理解できますが、さらに掘り下げると、運営のサイロに関連する本当のビジネスリスクが明らかになります。

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

サイロ化した知識が業務に与える影響

ほとんどの文書作成は横断的なコラボレーションを含みます。 サポートエージェントが機能に関するヘルプセンター記事を更新する例を見てみましょう。 エージェントは、自分のチームが集めたFAQから始め、その後、回答を得るためにエンジニアリングチームと連携する必要があります。 その回答のいくつかはGitHubに文書化されていますが、ほとんどはある主題の専門家の頭の中に存在します。

サポートエージェントがその回答を持っているとき、機能の利点に正しい用語を使用しているか確認するために、製品マーケティングチームと確認する必要があるかもしれません。 製品マーケティングチームは、その後、昨年の機能の立ち上げ時のメッセージが含まれている可能性があるGoogle Driveからのワンシートを送信するかもしれません。 最終的に、サポートエージェントは、彼らが追加の質問を追加したいかどうかを営業チームに確認し、もしそうであれば、再びエンジニアリングチームに確認しなければならないでしょう。

サポートエージェントが新しいヘルプセンター記事を作成するまでに、彼らは会社全体のチームメンバーとの会話を重ね、それぞれが自分の知識のチャンネルに入って情報を見つけなければなりませんでした。 そして、それはすべてがスムーズに進むと仮定した場合です。 もし、機能の主題の専門家であるエンジニアがその週に休暇に行っていたら、どうなるでしょうか? または、営業チームが追加の質問を追加したいと気づいた場合、それがさまざまなSlackチャンネルに散らばっている場合は? あらゆる問題が発生するたびに、タイムラインは引き延ばされ、知識漏洩や誤解の機会が増えていきます。

会社の情報を整理する。 どこでもアクセスできる。

プランを選択する

相互接続された知識の利点

さあ、すべてのチームが重要な最新の製品知識を文書化し、アクセスする場所を共有するという別のシナリオを考えてみましょう。 サポートエージェントが最初にエンジニアリングチームに問い合わせる際、SMEがその週に休暇に行っているかどうかを心配する必要はありません。事前に、彼らは共通の知識ベースを通じて他のチームとその専門知識を共有しているからです。

製品マーケティングチームが、昨年書かれた情報が古くなっているかもしれない情報を送信する代わりに、彼らは四半期ごとに正確性を検証する最新のメッセージとポジショニング情報にアクセスします。 営業チームがSlackチャンネルを通じて、以前に求めた答えを見つけるために走り回るのではなく、彼らはすべての質問を共有プラットフォームに文書化しています。

このプロセス全体の良い点は、サポートエージェントが他の人をワークフローから外すことなく、自分で多くのこの情報を見つけることができるということです。

すべての情報がチーム固有のサイロ化されたツールに保持されている場合、セルフサービスの知識取得は単に不可能です。

同僚間のリアルタイムのコラボレーションの役割は決して排除されることはありません。結局のところ、それらの相互作用が私たちが互いに関係を形成し、共感を持つのを助けるのです。 しかし、製品の提供と実現サイクルの多くのフェーズにおいて、知識がすべてのチームに普及しているときに、はるかに効率的に完了できるタスクが存在します。 知識を求める人と主題の専門家の両方が、作業の流れを中断することなく続行でき、リアルタイムのコラボレーションの帯域幅をより意義のある創造的な作業に節約できます。

Experience the power of the Guru platform firsthand – take our interactive product tour
見学する