私＋４名で社内に広報チームを結成しました。

ゴールは、仕事の引き合い確保を、誰か１人の営業力などではなく、

会社の仕掛けとして確立すること。

まずは、メンバーを人選して、声をかけて回ります。

　私）広報チームを立ち上げるからメンバーになってね。
　Ａ）いやぁー。私忙しいんです。
　私）大丈夫！Ａさんには時間がかからなくて、大事なところだけ割り振るから。

　　　例えば○○○とか、○○○とか。　・・・・・・（a）
　Ａ）わかりました。

　*** 快く引き受けてくれました。 ***

　　　(a)・・ ちなみに、ここで仕事のおもしろさを伝えることはとても大切にしています。

　　　　　　　どの程度伝わったかは未知数ですけど・・・。

こんな調子で、一部メンバーには未経験分野で戸惑いがあったようですが、
結局４人とも快く引き受けてくれました。（←本当）

みんな通常業務と兼務なので、大変なのですが、

スピード感にあふれる気分の良い仕事になると思います。

ホームページのリニューアルを前に、

今、リスティング広告を少々試しています。
登録したキーワード数は800ほど。

試した価値はありました。
実は１つ意外な事実を発見したのです。

リスティング広告に"ITコンサルティング"の単語を入れると、

広告表示時のクリック率が落ちるのです。

ITコンサルティングのサービスは、前面に出すと会社の能力を

アピールできるだろうと思っていたのですが、そうでもないようです。

もしかすると、ITコンサルティングには、価格が高いなどの
マイナスイメージがあるのでしょうか。

データ取りはほんの数日なので、
偶然この結果になった可能性もあります。

けれども、あれこれ考えるより、一旦結果を信じてしまうことにしました。

そうです、現在準備を進めているホームページリニューアルでは、
ITコンサルティングの単語を使わないことに・・・。

で、かわりにどう表現するか。

悩んでいるとメンバーがグッドアイディアを出してくれました。

「その他サービス」がいいでしょう。
「ITコンサルティング」よりわかりやすいですよ。

えっ？

一瞬理由がわからなかったのですが、なるほど、
一般的にITコンサルティングは何をするサービスか
理解されているわけではないのですよね。

そんな訳で、HP上の表記は「ITコンサルティング」はやめて
「その他サービス」に変更。

サービスの詳細説明のページで、具体的なサービス内容
（IT戦略立案やRFP(提案依頼書)作成)を並べることにしました。

これが書きなおした原稿です。
実はかなり気合いが入っています。

** 用語解説です。ご参考まで **

※リスティング広告とは
　yahooやgoogleの右側に出てくるテキスト広告のことです。
　企業がキーワードに対してクリック時の価格を入札し、
　検索エンジンが、検索語に合わせて広告を表示する
　仕掛けになっています。
　クリック単価はキーワードによって全く異なっていて、
　安いと10円未満ですが、みんなが検索するbigワードで
　高いものは1クリックあたり1,000円以上するそうです。

※RFP(Request For Proposal) / 提案依頼書とは
　ユーザーがベンダーに示すシステム開発の要求事項を取りまとめた資料です。
　提案や見積・調達の条件などもあわせて示されることが一般的です。

ホームページをリニューアルすることにしました。

会社のホームページは、今までは会社案内的な位置づけでしたが、

今回のリニューアルで営業戦略的な位置づけに変更します。

原稿は作成しましたが、デザインはこれからです。

私たちの業種はITコンサルティングとシステム開発、

つまり法人相手なので、あまり奇をてらう必要はないかも知れません。

お客様がSIerに求めるのは信頼感ですよね。

当たり前ですが、ホームページもそれを踏まえようと思います。

大事にしているのは、具体的なサービス内容を前面に出すことです。

作成した原稿でも、トップページに得意なサービスが並んだ形になっています。

営業ツールとして使うなら、訴求力は大事ですよね。

せっかくなので、トップページはFLASHも使って今時風に。

このFLASHの部分は今はノーアイディア。

何か考えないといけないですね。。。（と言ってもごく普通にすると思います。）

まずご報告

　タバコをやめてからもうすぐ１ヶ月。

　そして今は・・・

　ちゃんと続いてます。１本も吸ってません!!

ニコチンの禁断症状はまだ続いていますが、だいぶ楽になりました。

完全に落ち着くのも時間の問題になりつつあります。

一段落ついたら、途中経過をまとめてブログで公開しますね。

実は、それなりに大変だったのです。

BI（ビジネスインテリジェンス）や、DWH（データウェアハウス）のシステム構築は、

6割が失敗すると言われます。

※BIとDWHについては、この記事の一番下に用語解説を用意しました。

かけるコストを考えると、あんまりな比率です。

今日はBIシステム構築の失敗パターンと対策例を紹介します。

紹介する失敗例は次の３点です。

　失敗パターン１：何を分析したいのかをよく分かっていなかった。
　失敗パターン２：運用上無理があった。
　失敗パターン３：データベースの設計が実ビジネスモデルに適合しない。

失敗パターン１：何を分析したいのかをよく分かっていなかった。

　びっくりする方もいるかと思いますが、
　実は、もっとも多い失敗はこのパターンです。

　これは一時期、DWHの用語が先行して流行ったために起きた現象かとも思えます。

　もちろんこれはシステム化の目的を明らかにしていないことが原因です。
　具体化された経営方針や対策に対して実行するのなら良いのですが、
　目的があいまいな場合や、とにかくBIシステムを構築するなどの用語先行の場合は

　注意が必要です。

　DWHは、「さまざまな分析ができるようにデータを蓄積」の目標もあるのですが、

　具体的な目標を欠いたDWH構築は、コストばかりがかかりお勧めできません。

　特に「やること自体が大切です。まず始めましょう。」等の考え方には
　乗らないほうが賢明です。

　DWHは規模を大きく取ると湯水のようにコストが膨らみ、費用対効果が
　合わなくなります。

　よほど明確かつ具体的な目標があり予算が十分な場合はともかく、
　通常は、費用対効果が最大になるように設計を進めるとよい結果が
　生まれやすくなります。

　BI/DWHはスモールイン（小さく始める）が正解です。
　業務プロの方が、完成したシステムを使うことで
　次の素晴らしい案が見えるようになります。

失敗パターン２：運用上無理があった。

　手入力すべきデータを入力する手間が割けなかったり、
　夜間バッチの処理時間が足りないなどの問題です。

　この問題はDWHに限らず一定規模以上のシステムでたまに聞く話です。

　DWHは大量のデータを扱うことが多いため、比較的この問題が
　発生しやすいと言えます。

　運用作業に関わる部分は作業量に無理がないかを
　初期段階からよく考えておくことが必要です。

失敗パターン３：データベースの設計が実ビジネスモデルに適合しない。

　これはビジネスにおけるものごとの構造がベンダーに伝わっていないことが原因です。

　発生させないようにするには、ベンダーの成果物の良し悪しを把握する必要があります。

　そこで、
　BIのDB設計は、データの実モデルを反映する点が特徴的なので、

　このDB構造は業務プロの方も理解されることをお勧めします。

　そうすることで初めて設計の良し悪しが評価できるようになります。

　プロジェクトの初期段階からベンダーが用意する設計書の見方や設計技法について
　よく説明を受けるようにしてください。

　このDB設計を理解できるまで説明するのはベンダーの責務だと思います。

-- 以下、用語解説です。 --

※１　BIとは

　　　ビジネスインテリジェンスの略で、

　　　データ分析をビジネスのために活用するソリューション（問題解決手段）のことです。
　　　さまざまな技術を組み合わせて実現します。

　　　用語としては、DWHを包含する単語です。

※２　DWHとは

　　　データウェアハウスの略で、直訳では「データの倉庫」です。

　　　企業をはじめとする組織活動から発生するデータを集めて、
　　　分析するためにそのデータを蓄積するデーターベースを指します。

　　　DWHシステムと呼ぶシステムを考える場合、蓄積部分だけではなく、
　　　分析部分も含めて考えることがほとんどです。

もともと私は床屋派なのですが、
引っ越してからというもの、
近くにお気に入りの床屋がありません。
そこで、今回は久し振りに美容室に行ってきました。

　　　※私が10代のときは、美容室のことをパーマ屋と
　　　　 呼んでいたのですが、今は違いますよね。

なるべく場違いにならなそうなお店を探していると
男性客２人が入口に立っているお店を見つけたので、
そのお店に決めました。（笑）

内装はとてもおしゃれ。でも、女性好みとは少し違うような・・・。
後で聞いたところ、その美容室はやはり男性客が多いのだそうです。
狙ってやっているのですね。

動きのある髪型（無造作ヘア？）を勧められましたが、
仕事柄、髪型で遊ぶわけにもいかず、結局いつもどおりです。

でも、休日にちょっとカジュアルにみせる方法も教わってきました。
いつもみたいに髪を全部後ろ方向に流すのではなく、
自然に・・・ってやり方です。

で、ワックスを買って、自分でやってみたら・・・

んんん。

自分でやると、単なる寝癖にしか見えません。

（あんまりだったので写真は勘弁してください。）

来月に、もう一度教わろうと思います。

３プレ１とは、「３回プレゼンテーションを行って１回受注すればプロフェッショナル」を意味する言葉です。

ちょっと変かも知れませんが、私は、「さんぷれわん」と読んでいます。

若手のプレゼンテーターにはまず、この３プレ１を目標にしてほしいと思います。

大事なのはテクニックより、以下の３点です。
　1) 明示・暗黙に関わらず、要求事項と提案内容が一致しているか。
　2) 注文するだけの中身があるか。
　3) この人は信用できるのか。

では、１つ１つ。。。

1) 要求事項と提案内容が一致しているか。

　あたりまえの話ですが、要求事項との一致は絶対条件です。

　前提と言ったほうが正しいかもしれません。

　要求事項は明示・暗黙に関わらず把握して、しっかり一致させる必要があります。

　ポイントは以下のとおりです。

　　・お客様の話をよく聞くこと。

　　・きちんと資料化（いまどきの表現だと見える化）して、お客様に確認頂くこと。

　　・打ち合わせ毎に何か気になることはありませんか？とお客様の不安事項の払拭に努めること。

　　・お客様の都合で、提案を繰り返すのは当然であると考えること。

　　（当たりまえの内容ばかりですね。。。）

2) 注文するだけの中身があるか。

　要は"お得なのか"です。

　普段買い物をするのと同様に、賢い買い物をしたいのは、システム開発の発注でも同じです。

　これは普段の努力がものをいうところです。
　努力なくしては、付加価値も生産性も品質もそう簡単にはあがりません。

　SIerがプロフェッショナルだからこそ、
　お客様からご相談して頂けることを意識して、
　努力を重ねる必要があります。

3) この人は信用できるのか。

　意外かも知れませんが、一般に会社より人を見るほうが
　ウェイトが高いとされます。

　システム開発の発注とは、なかなか勇気のいる仕事なのです。
　後で機能の不足がみつかったり、発注内容に齟齬が発生したときに、
　こちらのことを考えて動いてくれるだろうか。そんな不安が付きまといます。

　SIerには、その不安をなくすだけの、一貫した姿勢が必要です。

　決してテクニックなどではなく、
　いつも真摯にお客様の視点で仕事に取り組むこと。

　その一貫した姿勢が最も大切なのだと思います。