知識管理、知識ベースの作成。 そして実際には何ですか？

ナレッジマネジメントのトピックに関する研究が行われ、主な結果が説明された2つの以前の投稿（ 1番目と2番目 ）のテーマを続けて、この問題の実際的な要素を掘り下げたいと思います。 議論するための質問はたくさんありますが、主なもの-知識管理の観点からビジネスのすべてのニーズを満たすツールはありますか？ 「鐘楼」からこの質問に答えようとします。

知識管理システムの分類

ナレッジマネジメントソフトウェア市場は非常に複雑です。 これは、方向が比較的若いという事実によるものであり、このトピックの最初のトピックで既に説明したように、「知識管理」の概念の定義そのものは、著者によって異なる解釈がされています。 最も有名な分類を以下の図に示します（資料に基づいて-www.bigc.ru/publications/bigspb/km/itkm ）。 このような幅広いソフトウェアのナレッジマネジメントシステム（CPS）への割り当ては、CPSが非構造化コンテンツ（文字、スケッチ、写真）、データ（データベースおよびデータウェアハウス内）、および知識（パターンとして）を含むすべてのタイプの情報を指すという事実によって説明されます専門家が問題を解決できるようにします）。







もちろん、この小さな木の各枝を分析することは意味がないので、生活の現実と研究の結果を考慮して、詳細化の方向は大幅に狭められました。 完全を期すために、IT分野で知識ベース（KB）を作成する2つの例を挙げざるを得ません。 1つ目は、大手コンサルティング会社であるIBSのBZです。 情報はかなり古いもので、それ以降何かが変更された可能性があります。 いくつかの重要なポイントのみを述べたいと思います。残りはプレゼンテーションで見ることができます。



IBSの基本概念はドキュメントです。 すべては、補充から使用までの知識ベースと連携し、ドキュメントを中心に展開します。 このような一見シンプルなアプローチのPPとして、3つの異種で高価なソリューションが一度に使用されます。 これらは、Documentim、SAP R / 3、Lotusです。 同意して、三位一体は印象的です。 当時は特別な代替手段はなく、すでに何かが変わっていたと信じたい。 ハブに会社の代表者はいますか？



2番目の例は、石油とガス産業で産業用制御システムを占有する会社Elisiです。 そこでは、メタデータ、メタ記述、オントロジーを企業CPSの基盤として使用して、知識保管所を導入することが提案されています。 このように、必要な知識の体系化とこのプロセスの高コストの間で妥協点を見つけることができます。 つまり 会社のCPSは、企業の情報システムのセマンティックな上位構造になります。 セマンティクスがあるため、このアプローチはより現代的で意味のあるものになります。これは、知識に近い、内部を見る試みを意味します。 このプロジェクトのイニシエーターが会社のゼネラルディレクターであり、同時にこのトピックに関する論文を擁護したことは注目に値します。

何が必要ですか

前の段落で、ロシアの実例が示されました。 以下は、CPSの概要を説明したときに注目した方向と基準を選択する試みです。

1. セマンティック技術の使用。 知識を扱う場合、セマンティクスを無視しないでください。 基本的なポイントの1つ。
2. 中小企業に焦点を当てます。 Documentumの助けを借りて、ITインフラストラクチャに関連する多くの問題を解決でき、SharePointがすべてを実行できることは明らかですが、もっと平凡なことが必要です。
3. コラボレーションと高度な相互運用性のサポート。 ほとんどの企業情報システムのコラボレーションが多かれ少なかれ、相互信頼性（借用用語が嫌いです）はどこでも異なります。 明らかに、知識ベースを閉じてISを分離すべきではありません。
4. 調査から明らかになったトリビアユーティリティ：知識ベースとワークフローおよび視覚化の使用（特に、マインドマッピング）のリンク。

これらすべての要因を考えると、方向はwikiシステムに狭まりました。 多くの理由で、そのうちの1つは、Wikiがすでに積極的に使用されていることを示す調査の結果です。つまり、Wikiは潜在的なユーザーになじみのあるものです。 そしてもちろん、それらのシンプルさ、展開の容易さ、そしてしばしばオープン性。



主な疑問が生じましたが、セマンティックテクノロジーの使用はどこにありますか？ セマンティックwikiは長い間wikiの間で区別されてきたことが判明し、この記事の残りの部分はこのコンテキストに専念します。 Habréについての参考文献が非常に少ないことに非常に驚いた。 要するに、従来のウィキと比較した主な特徴は、記事間のリンクの種類、記事内のデータ型、およびページに関する情報を指定する機能です。 これは、同じ名前のウィキペディアの記事からの提案です。



つまり、セマンティックWikiを使用すると、情報をより効率的に整理および構成できます。 多くのセマンティックwikiはrdfとowlをサポートします。これにより、より厳密な形式化が可能になり、推論システムと推論サポートが追加されます。 一見すると、これはすべて余分な合併症であり、エンドユーザーにとって別の障害になると思われます。 ただし、実際には、型付けされたデータの処理はセマンティックフォームを使用して整理できます。ユーザーにとっては、別のアンケートのように見え、操作が簡単です。

セマンティックWiki。 悲しいかな、たくさんあります

セマンティックwikiの最も顕著な例は、MediaWikiエンジンへのアドオンです。これは、簡潔かつ明確にSemantic MediaWikiと呼ばれています。 優れたGNU GPL v.2ライセンスの下で配布：すでにメディアWikiを使用しており、そのようなライセンスポリシーのオープン性、シンプルさ、およびその他の機能を希望するユーザーに最適です。 彼女には多くの拡張機能がありますが、有用ではありません。 一般に、一見の価値があります。



他のすべてのセマンティックwikiの中で、私は2つだけに焦点を当てます。この2つを使用して、少なくとも少し作業する機会がありました。 どちらも商用ライセンスで配布されますが、機能が多少制限されたコミュニティバージョンもあります。 なぜ彼らに？ なぜなら彼らはより大きな企業焦点を持っているからです。



最初はセマンティックメディアwikiプラスです。 同じセマンティックメディアWiki拡張に基づいており、セマンティックWikiの機能を簡素化すると同時に拡張する、非常に重要で豊富な機能によって補完されます。 さらに、必要なものはすべて1つのパッケージにすぐに収集されます。これは、よく調べて特定のシステムを選択したときに重要でした。 私はもう宣伝しません、 製品サイトは私のためにはるかに効率的にそれをします。 何が好きでしたか：



を含む優れた統合機会 すでに開発されたものを含む。 たとえば、Microsoft Office製品（Word、Project）、電子メール、同じSharePoint。 ここに、アプリケーション用のコネクタを作成する機能があります。

使用例として、作成済みのプロジェクトおよびリスク管理オントロジーをインストールできます。 明らかに、明らかに、他の誰かが実際に試みます。 何かが起こった場合、あなたはいつでも自分自身のために構造を変更することができます、それは実際には難しくありません。 また、システム自体を説明するウィキでは、このクラスのシステムを示す典型的な役割が強調されていることも気に入っています：オントロジスト、庭師、エンドユーザー、開発者、管理者。 おそらく2つの段落で十分です。詳細については、Webサイトを参照してください。



2番目の製品は、たまたま少し知りましたが、何らかの理由でJavaテクノロジーを好む人に適しています。 情報ワークベンチ（IWB）と呼ばれます。 この製品は、開発した会社とまったく同じです。 可能性やその他の有用性については説明しません。 アーキテクチャを確認し、すべての情報については開発者のサイトにアクセスしてください。 私は実装がまだ湿っているだけであることに注意しますが、すべてが有能で専門的に行われます。 そして科学的に;）会社の代表者が私に言ったように：「私達のディレクターの両方は博士号です。」

視覚化-マインドマップ、ワークフロー、コンフルエンス

このパートでは、これら3つの異質な単語について簡単に説明します。



最初から視覚化に多くの注意を払ったことを溶かしていません。 アンケートでは別の質問でさえ始まりました。 その理由は、視覚形式で情報をよりよく認識できるためです（テキストを読み直し、もう一度これを確信します）。 知識を扱うための最良の視覚化は、マインドマップを使用することです（ところで、この方法については記事は悪くありませんでした）。

だからここに。 これはすべてのウィキに当てはまります。 Freemind には embed オプションのみがあり 、これはすでに有効です。 もちろん、どこかで彼が何かを省略したのかもしれません。



ただし、代替アプローチがあります。 たとえば、IWBには、ウィキの基礎となるオントロジーがグラフとして表示されます。 とても快適です。 効果的に使用できます。 セマンティックWikiがSPARQLエンドポイントをサポートしている場合、サードパーティのデータベースビジュアライザーとなるRelFinderを固定することができます。 アクションのメカニズムを理解するために、アインシュタインとゲーデルの既製の例を見ることができます。 または、たとえばモスクワやプーシキンで一般的なことを個別に調べます 。



ワークフロー。 実際の活動から分離した知識は必要ありません。 それらが使用されない場合、それらのポイントは何ですか。 毎日のアクティビティをワークフローに反映できます。 ここは何ですか？



そして、ここでも、そうではありません。 一方、同じSMW +は、smw +「異種および非公式のワークフローを扱う組織またはチームに適したツール」と述べています。 しかし、ワークフローと知識ベースをリンクするための通常の実用的なソリューションはありません。 これに関する良いコメントがあります：



最初のアイデア（ここでは、ワークフローとBPを実際に区別しません）

-wikiを使用してワークフロー/プロセスを作成/改善する=>理想は、（最終）wiki情報からプロセスを生成できる場合

-wikiを使用して、ワークフロー/プロセスを文書化する

-Wikiを使用して、ワークフロー/プロセスの実行をサポートします（バックグラウンド、方法、エクスペリエンスの共有、Q＆Aに関する情報...）

-ワークフロー/ BPMを使用してKMプロセスを操作する=>情報をプッシュし、ユーザー/アプリをトリガーし、情報を収集し、

-ワークフロー/ BPMを使用してWikiの公開を操作する=>承認など



ただし、BizagiプロセスモデラーパッケージのBPMには、Media Wikiのカテゴリおよび記事で作成されたモデルのレンダリングされたすべてのブロックがアンロードされます。 非常に便利にバンドルで使用できるため、作業が簡単になります。



英語のコメントの著者は、Wikiとワークフローがより密接に連携するリンクを提供してくれました-www.adhocworkflows.comこれはConfluenceのサードパーティプラグインです。 私は設定しませんでした、試しませんでした、私はテストしませんでした。 どうしてもコメントできませんが、共有する必要があると思います。 さらに、ConfulenceとJiraは非常に近く、後者は多くの人によって使用されています。 Confluenceのセマンティックアドオンもあります-www.zagile.com/products/wikidsmart.htmlウィキをゼロから構築するのではなく、既存のウィキを再設計する人のための優れた代替手段です。 私もそれをテストしませんでした。自分からは何も追加できません。

他に何

ご存じのように、一般的な知識の管理および特に知識ベースの作成における主な問題は、知識ベースを満たすための時間と不本意の欠如です。 自由時間は、多くの場合、インターネットをサーフィンして同僚と通信します。 大声で考えて：「次回同様のタスクを実行させてください。何かを必死に思い出して、もう一度検索する必要があります。それでも遠い将来のより好ましい仕事に貢献するでしょうが、今は知識ベースを取り上げません。」 しかし、これから逃れることはできず、何らかの形で従業員をさらに刺激するだけです。



上記のウィキの代替として、コミュニケーションプロセスに焦点を当てたアプローチがあります。 一部には、知識がここに表示されます。これは、有名な日本の専門家である野中によると、 知識変換のプロセスの1つ、社会化、左上象限の存在によって確認されます。



ここで私は主にrizzomaプロジェクトを意味します。 提起された問題に対処し始めたばかりのとき、私は彼らの最初の記事の 1つが本当に好きでした。 その後、プロジェクトはまだ古い名前でした。 要するに、rizzomaはGoogle Waveの概念の続きであり、ディスカッション全体がwaveまたはblip-sで構築されています。 「Rizzomaは、Wikiシステム、メッセンジャー、および近い将来、タスクトラッカーを含むコラボレーションサービスです。」サービスにはまだやることが多く、同じタスクは現在ありません。Wikiは通常の意味では推測されませんが、開発があります。 私は特に、マインドマップでの波の構造の表示が気に入りました。 有能な組織では、その構造は部外者にとってよく認識されていることがわかります。 私見-リゾマでコミュニケーションの文化を植え付け、ウィキに構造化を置く場合、このアプローチはセマンティックウィキと組み合わせて最もよく機能します。



あなたのコメントを待っています。 誰かが言及された製品を使用した可能性があります。 サードパーティの意見を知ることは興味深いでしょう。



シートをごめんなさい。 次の投稿を再び遅らせないために、トピックをいくつかに分割したくありませんでした。