Concept |
Enterprise Web2.0 |
Enterprise オープンソース |
「JIRO」と従来のシステムとの違い |
Function |
3分でWeb2.0で情報共有が可能に |
メーラー形式UIによるROI向上 |
ESP(全文検索機能) |
URI/RSS/XMLによる情報一元管理 |
Demo |
3分で作るWeb2.0情報共有アプリ |
開発フレームワークの技術解説 |
Application |
お客様情報管理 |
社内メール情報の共有化 |
クレーム管理 |
商品情報統合情報 |
マニュアルのデジタル化 |
プロジェクト内の情報共有 |
基幹データの参照 |
Framework |
開発フレームワークとして |
「タグ付きデータモデル」について |
開発フレームワーク適用例 |
Document |
ドキュメント |
Service |
弊社のサービス内容 |
動作・利用環境 |
FAQ |
お問い合わせ |
Company |
開発blog |
会社概要 |
商品知識はもちろん、ビジネスをする上では競合情報も必要になりますし、顧客がその商品に望んでいるニーズや市場全体の情報など、実に様々な情報が商品情報に絡んできます。
企業内の情報は、究極的には、顧客に集約されるか、商品に集約されるかの二つに分類できます。また、情報は入力した時点で古くなるため、現場では常に情報を更新していかなければなりません。商品関連情報であればなおさらです。それを商品情報なら商品情報のフォーマットに、競合情報なら競合情報フォーマットに、顧客ニーズ情報ならニーズ情報フォーマットに登録する、という旧来のやり方では、現場の負担が増える一方で数字にしわ寄せが現われたり、入力される情報の質が期待通りのものにならなかったり、といったことが起こります。
商品情報ほど、フォーマットを決めて蓄積しようとすると失敗するものはありません。それは、商品情報と言っても、セールス情報、競合情報、成功事例、顧客の生の声と様々な情報があるからです。
しかし一方で、情報の性質ごとに定型のフォーマットを決めて、それぞれのシステムに分散して集めるのでは高い効率は期待できません。「JIRO」なら「タイトルと本文」程度のフォーマットをひとつ作り、そこに情報を登録していくことで、これらの情報を時系列で表示したり、「商品名 or 競合名」等の方法で全文検索を活用し、その商品や競合に関連する情報を漏れなく引き出すことができます。