IT構造の開発の特定の段階で、IT従業員とビジネスユーザーの両方のナレッジベース（以下KB）の組織について疑問が生じる場合があります。 このベンチャーの実装は、すべてのプロジェクト参加者にとって、プラスの効果をもたらし、深刻な頭痛の種となる可能性があります。つまり、資金を提供するビジネスと実装を調整するプロジェクトマネージャーからです。 この記事では、遭遇したいくつかのポイントを明らかにするとともに、いくつかの推奨事項を示します。
知識ベースを作成するプロセスは、組織内の根本的に異なる構造の観点から考えることができます：ITユーザー、ビジネス、両方同時に。
ITおよびビジネスのKB。
KBが組織全体に関連していると判断した場合、ビジネス担当者およびテクニカルディレクターからの道徳的および財政的なサポートを確保する価値があります。 これは、プロジェクトが適切な保証を取得するのに役立ち、将来的には、目標の誤解に関連する不快なインシデントを回避するのに役立ちます。または、下位レベルでは、提出された記事の品質に対する不満を防ぎます。
• インターフェイスの要素と開発環境の選択に対応するようにしてください 。 検索ツールは重要です。 この要素がうまく機能しない場合、そのようなベースにはほとんど意味がありません：あなたがその中に何かを見つけることができるベース！ この点を過小評価しないでください。 組織に何千もの記事がある場合、問題はますます感じられます。
• 明確な分類を使用します 。 ITワーカーが理解できるカテゴリは、ビジネスユーザーにはまったく何も言えません。 私たちが理解しているビジネスプロセスとサブカテゴリの名前を反映するカテゴリを組み合わせてみてください。
• システムの選択 。 ユーザーが質問をする環境からKBを操作する方がより便利になるため、この項目も重要です。 おそらく、良い解決策はユーザーのリクエストを管理するシステムでしょう。 インシデント管理とナレッジ管理の組み合わせを考えてください。
• 急いでデータベースをユーザーに開かないでください 。 最良かつ最も興味深いソリューションであっても、それが10の記事で構成されている場合、ユーザーを長い間自分自身から遠ざけることができます。 事前に準備してください。 開始するには、最も関連性が高いと思われる問題に関する記事を書いてください。
• IT KBとユーザーのKBを区別します 。 そして、彼らが見るべきでないものを彼らから隠すためではありません。 ユーザーの記事にはもっと注意を払う必要があります。 このスタイルのプレゼンテーション、およびITスラングと略語の使用の拒否。 公開するものはすべて、ユーザーが技術的に使用できることを確認してください。
• システムを使用して、公開前に記事を監視および管理します。 1つの頭が良く、2つが良いです。 これにより、無能な知識や煩わしいしみからあなたを救います。
• 記事のアプリケーション 。 特定のコンテンツの記事にアプリケーションを追加する機能を実現します。 ユーザーは、必要なものとそうでないものをよりよく理解します。
•ツールの使用方法に関するドキュメントを作成し、最初は集中的なサポートを提供してください。
実践では、ユーザーは一般にITナレッジベースを作成するという考えに対して前向きな姿勢を持っていることが示されていますが、それから技術サポートを交換する価値はありません。少なくとも最初は考えてはいけません。 問題を解決するための追加チャネルとしてツールを提示し、宣伝します。 たとえば、問題を口頭または紙で解決した後、KBで文書化し、ユーザーにリンクを送信することは理にかなっています。
ITのKB。
IT構造内でKBを使用すると、多くの場合に役立ちます。
•新入社員のトレーニング。
•当該分野の深い専門家ではない人への関連知識の移転。
•関連するIT部門との知識の交換。
この段階では、ビジネスで発生する可能性のある問題とはまったく異なる種類の問題が発生する可能性があります。
•「 すべてのことをすでに知っていて、ユーザーに簡単に説明できるのに、なぜKBが必要なのですか 。」 これは、KBのユーザーと著者から寄せられた非常に一般的な質問です。 記事の執筆には時間がかかりますが、従業員はそれを他の何かに費やしたいと考えていますが、それでも彼の意見では有用です。 人に何かをすることを義務付けることは可能ですが、これが質の高い記事の形で良い効果をもたらすことはまずありません。 ツールが誰かを助けるほどではないが、個人的には役立つと人々に伝えるようにしてください。これにより、まず第一に、時間を節約できます：有能な同僚ではなく、ユーザーと通信することです。 たとえば、5分の時間を空けて、記事の執筆に費やした場合、問題や機能を説明するのにこれらの5分の時間がなければ、それを保存します。
• 技術的実装の失敗 。 簡単にアイデアを台無しにすることができる重要なポイント。 ツールを便利にするようにしてください。 テキストエディタが組み込まれている場合は、問題なく動作するようにします。 記事を書くのが不便な場合、彼らは書くことはありません。
• モニタリング 。 記事がいくつ書かれているか、誰が個人的にそれを行っているかだけでなく、それらの関連性もチェックしてください。 ビューカウンターとフィードバックの機能を追加します。 ユーザーが記事にコメントを投稿できるようにします。 いくつかのレポートを作成します。 重複を監視してみてください。 基地の成長とともに発生する可能性も大きくなります。
一般に、KBに関連するすべてを急いで実装すべきではありません。 技術的な実装に多くの時間とお金を費やすことができ、小さな欠陥や迷惑なバグによる効果を達成することはできません。 そして、そのようなシステムの目的は、支持構造との接触の数を減らすことです。 もちろん、落とし穴の数は、この記事で示したものよりもはるかに多いですが、説明したものが最も重要です。
私はあなたのコメントを聞く準備ができており、私の経験を共有できればうれしいです。
会社のITナレッジベース
All Articles