文書化 8.5 ポータル 小項目

現行
ポータル画面
ポータルは、コミュニケーション、メッセージ、情報収集、ライブラリの4つの機能で構成される。
コミュニケーションの基本は操作画面です。個人認証で的確な表示を行い、関連システムをシングルサインオンする。
メッセージ
システム毎にメッセージが存在している。ポータルに集約させる。その上で、メッセージから始まる循環をイメージする。
お知らせ以外に、掲示板・iFlameなどで伝えている。それらの効果が不明。基幹系と同時表示ができない。
ライブラリ
本部の情報をストックする場として、Sa-ライブラリを開発して、メッセージと連携させた。
ライブラリを必要としない販売店も多い。ライブラリの存在理由を明確化する。
情報表示
実績表の表示を一目で状況が分かるために、情報提供している。自社での加工レベルを上げる必要がある。
アピール・アンケートは表形式のアンケートが主になっている。結果をアピールできるものが必要になる。
8.5.2 拡張
ポータル改善
ポータルの情報共有機能を前面に出していく。４つの機能を進化させる。ポイントは販売店での加工になる。
最新のパッケージを用いて、操作の容易性を図る。並列的な表示とポップで即時性を持つことで、ポータルの独立を目指す。
メッセージ
システムを通さずに、権限で表示させる。お客様・メーカー・本社とのメッセージのスルー性を確保する。
社内SNSの具体化をはかる。一つのテーマについて、スタッフがお客様を代表して発言する。その要望を吸い上げる仕組み。
ライブラリ
Sa-ライブラリについては、スタッフのコラボ結果を集約できるようにする。検索異能を含めて、知識と意識の集約をはかる。
販売店からバラバラでアクセスしているメーカー情報、大容量データ、自社映像コンテンツなどをポータルからアクセス。
情報収集
ポータルのコンテンツ編集の機能を使って、基幹系・情報系の販売店でデータ外付けして、自社用の表示を可能にする。
アピール・アンケートの結果なども、グラフなどで表示して、アピールする。自社サーバなしでの活用を可能にする。
8.5.3 企画
スタッフ環境
ポータルをスタッフ自身の武器にしていく。情報共有を徹底させて、店舗の活性化をめざす。販売店での加工を可能にする。
ソーシャル・ウェブを活用して、社会システムとの親和性を図る。クルマを使うことへの認識をカタチにする。
テータの外付け
EAI機能を使って、基幹系データの差分を反映させる。自社で収集した、フロー情報と合わせて、プロファイルを作成。
簡単な操作で、スタッフ単位での活用を可能にする。お客様接点で得られた情報を集約する。
メーカーと直結
メーカー情報を毎回、取りに行くから、関係する情報をプッシュさせる。サーバー情報とポータルの個人情報を関係づける。
ライブラリの見える化として、利用状況・ランキングなどを提供。ソーシャルウェブで微分的から積分的なものに変わる。
お客様と接続
お客様ポータルは、おきゃ様任せです。お客様の声を吸い上げ、的確に対応するスタッフ側の意識は必要になる。
最終的には、お客様のコミュニティとの接続して、メーカー企画との関係とつなげていく。メーカーの存在理由になる。
8.5.4 開発
要件
現行機能の確保が前提になっている。現行はポータルの最終形ではない。足りない部分をできなかった部分は補完する。
ポータルでの拡張性としては、４つの機能で展開していく。販売店システム全体と先行きのイメージも提示していく。
選択
開発方式は３つが提案されている。Salesforce、SharePont、Liferayです。私はソーシャルウェブを選びます。
SFDCのポイントは、アジャイル型開発手法、生産性、情報共有基盤の認識、全体への展開、機能改善の抑え込みです。
構築
現行機能を作り上げるのは、仕様書を元に、稼働状態を見ながらの開発。なるべく似たものを作るが、許容範囲は判定する。
追加機能は、SNSはコラボ、モバイルはメッセージ表示、検索はライブラリで対応。アイデアボックス、データ抜出は既存に含む。
展開
10万人に対する展開ではなく、先行する販売店を優先する。事務局を構えて、販売店事例の横展開を行っていく。
スタッフでの評価を優先して、自分たちのツールにしてもらい、意見を発してもらう。それを経営者に訴える。