既存のビジネスを強化するにしても、新しいビジネスを起こすにしても、まずはやらなければいけないことは、自社を見つめ直すことです。
「データ・マネジメント」というと、見渡しきれないほど大きな組織の、あらゆるデータのマネジメントを意味するように聞こえるかもしれません。
実際、大企業のデータをまとめるのは大変ですし、そのための方法論でもあります。
しかし、ビジネスの規模に関わらず、データ・マネジメントは経営にとって重要です。
理由は、データ・マネジメントを通じて、「自社を見つめ直」して、新しい「目指すべき姿」を描いていくことも、可能になるからです。
本稿では
- データ・マネジメント、について紹介しつつ
- 中小企業を例にとって、自社の事業を見つめ直して新規事業を起こすために必要な「あるべき姿」を思い描く
といったことをご紹介したいと思います。
データ・マネジメントとは
データ・マネジメントについての説明は、様々なところでされています。
専門書による説明も、役立ちます。本稿でも触れる２冊を、ご紹介しておきます。
『DMBOK データマネジメント知識体系ガイド 第二版』
『DMBOK データマネジメント知識体系ガイド 第二版』ではデータ・マネジメントを体系的に説明しています。
しかし６００ページ以上のボリュームがあるので、全てじっくり読もうと思うとまとまった時間と、理解のための時間が必要になります。
ここでは少しずつ内容を紹介しつつ、中小企業で、新規事業を起こそうとするときに、データ・マネジメントを応用する方法を考えていきたいと思います。
（ただ、筆者は英語版を入手してあったので、日本語訳とは違う表現になってしまっていると思います。ご了承ねがいます。）
『DXを成功に導くデータマネジメント』
もう１冊は、 『DXを成功に導くデータマネジメント』（翔泳社） という本です。
Webサイトでもデータ・マネジメントについての様々な記事や資料を提供されています。
多数の図表を通じて、実践的なデータ・マネジメントの方法や事例を、具体的に示されています。
きちんとデータ・マネジメントを行いたいときや、システム構築をする際に、とても参考になると思います。
サブジェクト・エリア・モデル（主要領域モデル）と概念データ・モデル
『DMBOK』では 「4章 データアーキテクチャ」 の章でで説明されています。
自社のビジネスの主要領域を明確にして描くのが、主要領域モデル（サブジェクト・エリア・モデル）です。
領域毎に、利用されるデータの概念を図示するのが、概念データ・モデルです。
ビジネス全体を、領域に分けて、その領域内でどのようなデータが扱われるかを、もれなく、全て、整理するということになります。
サブジェクト・エリア・モデル（主要領域モデル）と概念データ・モデル
「サブジェクト・エリア・モデル（主要領域モデル）」は、「企業の鍵となる、主要な領域で、名刺で表現されるべき」と書いてあります。何十個も出てくるものではなく、多くても２０個程度、と、説明されているものが多いです。
では、
サブジェクトエリアとは、基本業務機能（購買、営業、経理、精算など）と事業領域と市場の組み合わせで決まる業務領域
であり、
エンティティ（データのこと：筆者）を主管している組織を決めるということ
(p.247)
と表現しています。簡単に言えば、部門毎に扱うデータを並べて、部門間やプロセス間でのデータの関係を明確にしていくことと言えます。
「概念データ・モデル」は、一言でいえばデータのことですが、ITシステムで扱う、データベースの中のデータのようなものというよりも、もっと業務や部門の立場から見たデータのことと言えると思います。同じ本から引用すると：
データモデルは意味に着目して構造化していることから、概念データモデルと呼ばれています。（…）データモデルは知識を整理する際に役に立つといわれていますが、それはデータモデリングをすることで（…）構造化するトレーニングを行っていることになるため、知識の整理スキルが身についているものと考えます。
『DXを成功に導くデータマネジメント』（翔泳社） (p.234)
と書いてあります。
簡単に言えば、仕事をする上で必要な手続き、書類、役割、を、書きだしていくこと、になりますが、「概念データ」というくらいですから、事細かに書き出さなくても、とりあえずは良いでしょう。
当社の場合の「サブジェクト・エリア」と「概念データ」の例
サブジェクト・エリアとして部門をおき、それぞれの下に主なデータを書きだしていきます。
実態とは若干異なりますが、技術部がエンジニアを擁し、営業部が契約を受注し、人事と事務を担当する部門がそれぞれある、と言った形になります。
実際には、もう少し多くの部門があるかもしれません。
とりあえず部門毎、または業務毎、に、それぞれが扱うデータやモノの名前を書きだしていきます。
サブジェクト・エリアから考え直してみる
さて、ITシステムを構築するのであれば、このプロセスをさらに細かく、厳密にしていく必要があります。
しかし、今回はシステム構築ではなく、「ビジネスを見つめ直す」ことに力点を置いて考えてみます。
「ビジネスを見つめ直す」とは、どういうことか。ここでは、当社が新しい事業を企画して、育てたいと考えている、としましょう。
現在のサブジェクト・エリアには存在しない、新しいサブジェクトを考えたいということです。こんな感じで追加してみます。
サブジェクト・エリアに必要な「概念データ」を考えてみる
サブジェクト・エリア・モデルには、概念データが必要です。
新しく追加したサブジェクト・エリアに、どのようなデータが必要になるのかを考えます。
今は無いものを考えるので、何が必要か、答えはありません。
ここでは、当社があるプロジェクトで構築した「AIチャットボット」を、自社のサービスとして、様々な顧客に販売していきたい、と考えたとします。
AIチャットボットを自社サービスとする
新しい商品なので、新しい営業が必要になると考えられます。
通常、私たちの仕事は、プロジェクトを毎に「契約」を交わして、お客様にシステムを構築したり、構築のお手伝いをしたりしています。
しかし、「AIチャットボット」は、システムではなく、サービスです。
1回の契約で終わるものでもなく、サブスクリプション型が望ましいので、「営業」の概念データに追記していきます。
今までの営業では、
- プロジェクトを推進したい顧客へ当社のエンジニアや得意分野を営業して契約を得る（SI営業）
- 社員だけでは足りないエンジニアリングの力を、ビジネス・パートナーである同業他社から調達（BP営業）
- 直接エンドユーザへシステムを構築、異業種交流会やセミナーなどを通じて知り合った顧客へのシステム開発提案の営業（エンドユーザ営業）
３つのスタイルでした。
しかし、サービスを販売するために営業し、「サブスクリプション契約」より売り上げをあげるには、営業方法も変えないといけないと思われます。
何故なら、まず、今までの顧客とは異なる顧客との出会いを作らなければなりません。
「マーケティング」で広く顧客との接点を探していくために、今までの営業とは異なる「顧客管理」も必要になると仮定します。
この「AIチャットボット」は、当社で開発をしたものですので、「仕入」は発生しませんが、継続的に開発をする必要があるでしょう。
今までは顧客のためのシステムを開発してきましたが、自社のサービスのための開発を、継続して行う必要があります。
開発に関する概念データは、「技術」の欄に追加していきます。
既存の概念データである、「プロジェクト」、「プロジェクト・マネジメント」、「エンジニア」に対応する概念データとして、
- サービス開発
- サービス開発マネジメント
- AIエンジニア
- データエンジニア
- サービスエンジニア
が必要ではないかと考えました。
『DMBOK』では、「サブジェクト・エリア」について、正規化を通じて企業のデータ・モデル全体で統一的に使われる必要がある、と書いてあります。
要するに、ビジネスのビジョンを表すべきであるということです。ビジョンが部署ごとに異なっていては困るのです。
また、ここでは、ビジネスの「現在」ではなく、「未来」を描こうとしているので、「正規化」は後で考えます。
サンプルで考えてみた、当社の新サービスに関わる「サブジェクト・エリア」を追加した、モデル全体を見てみます。
「未来のサブジェクト・エリア・モデル」から、未来のデータ・フローを考えることで、ビジネスを見つめ直していきたいと思います。
未来の概念データ・モデルから、未来のデータ・フローをさらに考える
新しいサービスのための営業は、今までの営業とは異なるのではないかと、考えましたが、具体的にどのようなビジネスが、新しい営業活動として必要になるでしょう。
データ・マネジメントでは、サブジェクト・エリアと概念データを明確にした後で、データ・フローを整理することになりますが『DMBOK』によれば：
- データとビジネスで利用するシステムの関係
- データが保存されるデータベース（または、ファイルの保存先でも良いと思います：筆者注）との関係
- データが通るネットワーク
- データを参照・操作するユーザやシステムの、権限・役割
などを、データ・フローで表せる、と書いてあります。データのフローかどうか、難しいことは考えず、とりあえず、サービス事業を起こすにあたり、必要になりそうな営業フローを図に描いていってみます。「概念データ」かどうかも気にせず、考えられるものを図示していきたいので、色を変えて表現しておきます。
まず、「サブスクリプション」という契約形態を取り入れようと考えましたが、どうやってサブスクリプションしてもらいましょうか。ごく一般的に考えて、下図のように考えてみます。
こちらから営業をして、契約を取るというよりも、お客様が自分でWebフォームを通して申し込んで頂けるようなイメージを考えてみました。勿論、営業担当が直接契約を登録することもあるでしょうから、営業担当からの流れも記載してみました。
次に、申し込みフォームへお客様が入ってくるのはどういう流れでしょうか？かんがえてみます。
DMや、LP（ランディング・ページ、広告ページ）、ブログやメルマガを使った宣伝、また、デモサイトを用意するなどして、興味を持った顧客が申し込みフォームまで行けるように考えてみました。また、従来のお問合せフォームなどから直接くるケースも、そのまま残してあります。
デモサイトやLP、ブログやメルマガ、へアクセスしてもらえれば、そこから問合せ、もしくは申し込みフォームへのアクセスが初めて生まれてきます。まずは未来の顧客に、コンテンツを見てもらう必要があります。
まだまだ議論しないといけないことはいっぱいありますが、とりあえず、サブスクリプションまでつながるように、未来の営業について考えてみました。下図のようになりましたが、一言でいえば、当たり前ですが、今までの営業以上に、「マーケティング」に力を入れる必要があることが、図からも感じられます。
緑の枠で示したものの多くは、現在まだないものです。右に挙げた現在の営業の姿よりも細かく書いてあるとはいえ、それでもやらなければいけないことがたくさんあるのは確実です。
こんなにいっぱい、今すぐなんてできないよ！しかもまだ完成すらしていないのですから。。！
それに、肝心のサービスを作る方の整理も出来ていません！
今出来ること、やらなければいけないこと
このままでは何も出来ずじまいになってしまいます。ですから、まずは「出来ること」からやっていくことが肝心です。次の図では、ぐっとスコープを小さくして、出来るだけ「今から出来る」形に絞ってみます。
まず、問合せフォームや電話起点の営業を、白い四角に変えました。
これらは現在でも、行っています。ただ、対象となる顧客が、今までとは異なります。本格的に行うには、今までとは違う営業になるのでしょうが、営業マンを急に増やすことも出来ませんから、今までの営業の枠で考えることにしました。
次に、サブスクリプションを、トライアルだけにしてみました。
勿論、お金を払って使いたい顧客が要れば、きちんと商売すれば良いのですが、最初からどんどん売れると考えるのは、難しいと判断しました。
サービスを売ること以上に、やらなければいけないこと
ビジネスである限り、利益を作らなければいけませんが、その利益を作るには、顧客を作る必要があります。
当社の場合、顧客は常に存在して、そこにいかに技術力を提供するか、が「営業」でした。
しかし、サービスを売るためには、そのサービスを知ってもらい、欲しいと思ってもらう必要があります。今まで経験のない、マーケティング主体の営業活動だと言えます。
まずはそれを開始しないことには、サービスを売ることも出来ないだろうと判断しました。
顧客管理の見直し
それと、顧客管理も見直すことにしました。今まではセグメントも３つ、中でも重要なセグメントは２つ。システム・インテグレータである大企業（SI営業）と、同業他社（BP営業）だけでした。
重点顧客と新規顧客の重みづけをして、EXCELの一覧で管理し、営業日報・週報を添えていれば、事足りてしまっていました。
しかし、これからは、もっと幅広い顧客に対して、当社のサービスを売り込む必要があります。どのような顧客で、何を欲していて、どのようなことに価値を見出してもらえるのか、分析していく必要が出てくるでしょうし、何よりもそれを、開発部門にフィードバックし、より良いサービスを作っていくサイクルを作る必要があります。
そのためには顧客のプロファイリングに力を入れないといけないと考えました。
そこで、今までも何度も検討はしてきたものの、結局導入に至ってい居なかった、顧客管理システム（CRM）の導入を本格的に検討することとしました。
データ・マネジメントから始まった、見つめ直しの、行方
さて、そもそもデータ・マネジメントから始めた話ですが、データの話ではなく、営業活動の見直しの話になってしまいました。
サブジェクト・エリア・モデルも、概念データ・モデルも、データ・フロー図も、完成には程遠い状態です。
しかし、サービスを売るビジネスを開始するために、マーケティング主導の営業に切り替え、CRM導入を本格的に考えるべきである、という、行動指針を得ることが出来ました。
データ・マネジメントの重要性が強調されるのは、ビッグデータ、AI、IoT、ブロックチェーン、などなどの必要性が高まっているからではありますが、何よりも重要なのは、今のビジネスを変えていくための行動指針をどうやって打ち立てるか、だと私は思います。
見つめ直しはまだ、始まったばかりです。今回は「営業」についてかんがえましたが、次は「開発」のほうに目を向けて考えたいと思います。
データ・マネジメントに相応しい作図ツールを使いましょう
話題を変えて、ご提案です。
今回、サブジェクト・エリア・モデルや概念データ・モデルを作るにあたり、daiagrams.net （旧 Draw.IO） の作図ツールを使いました。
無料でオンラインで使えますが、弊社ネクストクラウドのデモサイトでも試用出来ます。
下図のように様々なダイアグラムに対応していて、使いやすいですし、オンラインツールなのでブラウザさへあればどこでも使えます。
使いやすい作図ツールですので、是非お試しください。
ネクストクラウドで利用すると、社内での共有やコラボレーションがやり易くなります。
ネクストクラウドの便利なコメント機能を利用して意見や修正すべき点を書き留めたり出来ます。
ネクストクラウドでは、バージョン管理も自動的にしてくれます。
ファイルの共有も、社内での共有、社外との共有、簡単に出来ます。
また、共有相手がファイルを参照したかどうかも、アクティビティですぐに確認出来ます。
デモユーザで、簡単、安全、便利なネクストクラウドと、多様な作図ツールを体験してみてください。
※デモユーザは共有ユーザなので、情報漏洩には気を付けて下さい！