営業データを蓄積するDWH（データウェアハウス）とは｜複数ソースのデータを統合・蓄積する仕組みとデータレイクとの違い

商談メモはSFA、リードはMA、月次の集計はExcelという具合に、営業に関わる情報やデータが複数の場所に散らばっているケースは珍しくありません。数字を作るたびに手作業でファイルをつなぎ直し、表記のズレを直しているうちに、分析にたどり着く前に力尽きてしまう。この「散らばりを1箇所に集めて蓄積する」役割を担うのがDWH（データウェアハウス）です。この記事では、DWHとは何か、データレイクやデータベースといった類似の仕組みとどう違うのか、そして営業データで何をどう蓄積すればよいのかまでを、導入判断の手前として整理します。

データの生成から活用までを含む体系的な全体像は、営業データ活用基盤の全体像で整理しています。本記事はそのうち「統合・蓄積層＝DWH」だけを深く掘り下げます。

営業データを蓄積するDWHとは

DWH（データウェアハウス：分析のために複数システムのデータを整理・統合して長期蓄積する情報の倉庫）とは、営業文脈でいえば、SFA・MA・Excelなどに散らばった営業情報やデータを1箇所に集め、共通のルールに整えたうえで時系列に溜めておく仕組みです。単に集めるだけの保管庫ではなく、「受注率がなぜ先月から落ちたのか」「単価が下がった時期に何があったのか」を後から遡って分析できる状態を作る点に価値があります。

ここで押さえておきたいのは、DWHはそれ単体では営業の数字を動かさないということです。データを溜めても、入力する仕組み（生成層）と、溜めたデータを見て判断する仕組み（活用層）がそろって初めて意味を持ちます。以下では、DWHの特徴と、営業データ活用基盤のなかでの位置づけを具体的に見ていきます。

DWHの4つの特徴を営業データで理解する

DWHは、データウェアハウスの提唱者であるビル・インモンが示した4つの特徴で説明されることが一般的です。営業データに当てはめると、それぞれ次のような意味になります。

• サブジェクト指向 業務システム単位ではなく「受注」「顧客」「案件」といった分析テーマ単位でデータを整理する。SFAの画面構造そのままではなく、分析したい切り口でまとめ直す
• 統合 SFAでは「株式会社○○」、MAでは「○○株式会社」と表記が割れている企業名や、単位・コード体系のばらつきを共通のルールに統一してから格納する
• 時系列 ある時点のスナップショットではなく、月次・週次といった時間軸で履歴を保持する。過去の受注率の推移や単価の変化を後から追える
• 不揮発 一度蓄積したデータは原則として上書き・削除せず残す。SFA上で案件が更新・削除されても、DWH側には過去の状態が記録として残る

営業データは日々更新されます。SFA上の案件フェーズは商談が進むたびに書き換わりますが、DWHに時系列で不揮発に溜めておけば「先月時点でヨミA（受注確度の高い案件）だった案件が、今どうなったか」といった変化そのものを分析できます。これが日々の処理を目的とした業務システムとの決定的な違いです。

営業データ活用基盤の3層のうち「統合・蓄積層」にあたる

営業データ活用基盤は、大きく3つの層で捉えると整理しやすくなります。データを生み出す生成層（MAやSFA/CRM、メール・議事録など）、データを集めて整える統合・蓄積層（DWH）、そしてデータを見て判断する活用層（BIツールやレポート）です。DWHはこのうち中央の統合・蓄積層にあたります。

生成層でデータが入力されていなければDWHに集まるものはありません。逆に、DWHに整ったデータがあっても、活用層で見て意思決定に使わなければ倉庫に眠らせているだけになります。DWHを「基盤の真ん中を支える層」として理解しておくと、後述する導入判断でつまずきにくくなります。

DWHとデータレイク・データベース・データマートの違い

似た言葉が多く混乱しやすいところですが、役割で分けると整理できます。データベース（DB）は日々の業務処理のための仕組み、DWHは分析のために整理して蓄積する仕組み、データレイクは加工前の生データも含めてそのまま溜める仕組み、データマートはDWHから特定部門向けに切り出した小規模版です。営業データは議事録や商談の温度感など整った形になっていない情報が多いため、DWHとデータレイクの使い分けが特に判断の分かれ目になります。

この4つは対立するものではなく、目的に応じて併用されることも多い仕組みです。以下でそれぞれの違いを、営業データの実態に照らして見ていきます。

DWHとデータベース（DB）の違い｜処理用か分析用か

データベース（DB）は、SFAやMAといった業務システムの裏側で、日々発生するデータの登録・更新・参照を高速に処理するための仕組みです。案件を新規登録する、フェーズを更新する、といった一件ずつの処理に最適化されています。

一方DWHは、そうした業務システムのDBに溜まったデータを分析用に取り出し、整理・統合して蓄積します。DBが「今この案件をどう扱うか」を支えるのに対し、DWHは「この半年で受注率がどう動いたか」を支えます。業務システムのDBで重い集計クエリを直接回すと本来の業務処理に負荷がかかるため、分析は別の場所（DWH）で行う、という役割分担が生まれます。

DWHとデータレイクの違い｜構造化して溜めるか生のまま溜めるか

DWHとデータレイクの最大の違いは、データを「整えてから溜める」か「生のまま溜める」かです。DWHは事前に構造を決め、表記や単位を統一した構造化データを蓄積します。分析の型があらかじめ決まっているぶん、集計や比較がすぐに行えます。

データレイクは、CSVやExcelのような表形式のデータだけでなく、議事録のテキスト、商談の音声・動画、メール本文といった非構造化データ（あらかじめ決まった列に収まらない、そのままでは集計しにくい情報）も、加工せずそのまま溜められます。営業現場は「担当者が感じた顧客の温度感」「議事録に書かれた失注理由の一言」といった、数値化されていない情報が判断に効く場面が多くあります。こうした生の情報も残しておきたい場合はデータレイクが向きます。

営業データでの使い分けの目安は、次のように考えると整理できます。受注率や単価の推移を数値で分析するのが中心ならDWHが軸になります。議事録や音声など、後からテキスト分析やAI活用の余地を残しておきたいならデータレイクを併用します。実務では「まずDWHで構造化データの分析を回し、非構造化情報はデータレイクに溜めておく」という併用も珍しくありません。

営業現場でどの情報が構造化されており、どこから非構造化なのかを整理したい場合は、構造化データと非構造化データの違いもあわせて確認すると、DWHとデータレイクのどちらに何を溜めるかの判断がしやすくなります。

DWHとデータマートの違い｜全社か部門特化か

データマートは、DWHに蓄積された全社のデータから、特定の部門や用途に必要な部分だけを切り出した小規模なデータの集まりです。DWHが営業・マーケ・経営など複数部門のデータを横断的に持つのに対し、データマートは「営業部門の受注分析専用」のように用途を絞ります。

用途を絞るぶん扱うデータ量が少なく、必要な人が必要な切り口で素早く分析できる利点があります。実務では、まず全社のDWHを整えてから部門ごとにデータマートを切り出す流れもあれば、後述するように「1つのKPIを解く最小のデータマート」から小さく始める流れもあります。

DWHとBIの違い｜溜める仕組みと見る仕組み

DWHとBIツールは、しばしばセットで語られますが役割は明確に分かれます。DWHはデータを整えて溜める仕組み、BI（ビジネスインテリジェンス：蓄積したデータをグラフやダッシュボードで可視化・分析するツール）はそのデータを見て判断するための仕組みです。DWHが倉庫、BIがその倉庫の在庫を一覧できるダッシュボード、と考えると関係を捉えやすくなります。

BIは前述の3層でいう活用層にあたります。DWHに整ったデータがあってこそBIの可視化が生きるため、両者は補完関係にあります。営業BIの具体的な使い方は営業BIの基礎で扱っています。

DWHが複数ソースのデータを統合・蓄積する仕組み

DWHは、ETL/ELT（複数システムからデータを抽出・整形・格納する一連の処理）と呼ばれる仕組みで、SFA・MA・Excelなど形式の異なるデータを共通のルールに整えてから蓄積します。ここで重要なのは、DWHが「集めるだけ」の仕組みではないという点です。表記や単位を統一してから溜める整形の工程があるからこそ、後で正しく集計・比較できます。

営業データはシステムごとに項目名も入力の仕方もばらばらです。この不揃いを吸収する工程を理解しておくと、DWH導入時に「なぜデータをそのまま入れられないのか」でつまずかずに済みます。以下で流れと勘所を見ていきます。

抽出・整形・格納（ETL/ELT）の流れ

ETLは、Extract（抽出）・Transform（整形）・Load（格納）の頭文字です。SFAやMAからデータを抜き出し（抽出）、表記や形式を共通ルールに整え（整形）、DWHに格納する（格納）という流れになります。先に生データを格納してからDWH内で整形するELT（抽出・格納・整形の順）も広く使われます。どちらも「複数ソースのデータを整えて溜める」という目的は同じです。

営業の実務では、この処理を毎日・毎週など決めたタイミングで自動実行し、最新の営業データが常にDWHに反映される状態を作ります。手作業でのファイル結合を繰り返している場合、この自動化だけでも数字を作る工数が大きく減ります。

なぜ整形が必要か｜表記ゆれ・単位のばらつきを揃える

整形が必要になる典型が、企業名や担当者名の表記ゆれです。SFAでは「株式会社○○」、名刺管理ツールでは「○○（株）」、Excelでは「○○様」と入力されていると、同じ顧客が別々にカウントされ、受注件数も売上も正しく集計できません。DWHではこうした表記を統一し、同一の顧客として名寄せしてから蓄積します。

単位のばらつきも同様です。ある部門は金額を「千円」で、別部門は「円」で入力しているといった食い違いを、格納前に共通の単位へそろえます。この整形工程を省くと、DWHに溜めても数字が合わず、結局手作業での突き合わせに逆戻りしてしまいます。整形こそがDWHの肝です。

集めたデータを時系列で溜めることの意味

DWHが分析に強い理由は、時系列でデータを溜めることにあります。業務システムは「今の状態」を持つのが基本で、フェーズが進めば過去の状態は上書きされていきます。DWHに月次・週次でスナップショットを残しておけば、「先月末時点の案件パイプラインが、今月末にはどう変化したか」を後から比較できます。

これにより、受注率の低下がどのフェーズで起きたのか、単価の変動がどの時期の施策と連動しているのか、といったトレンド分析ができます。営業活動の変化を「点」ではなく「線」で捉えられることが、時系列蓄積の実務的な価値です。

営業データ活用基盤の統合・蓄積層としてのDWH｜何を蓄積するか

営業DWHに集めるべきデータは、営業生産性の4つの変数に紐づけて考えると迷いません。営業生産性は「（商談数 × 受注率 × 単価）÷ 工数」で表せます（出所：株式会社マツリカの営業生産性フレーム）。この式のどの数字を動かしたいかが、蓄積すべきデータを決めます。

逆に、何のために溜めるかを決めずに「とりあえず全部集める」と、溜めたが使わないデータの山になりがちです。以下では、蓄積対象の代表例と、その決め方を示します。

リード・商談・案件・活動履歴

営業DWHに集める代表的なデータは、生成層から来る次のような情報です。

• リード情報 MAで獲得した見込み客の属性・行動履歴・流入経路
• 案件・商談情報 SFAに入力された案件のフェーズ・金額・受注確度（ヨミ）・進捗
• 活動履歴 訪問・架電・メールなど、案件を前に進めるための一つひとつのアクション
• 受注・売上実績 受注日・受注金額・商材・クロスセルやアップセルの有無

これらを1箇所に統合して初めて、「どの流入経路のリードが受注につながりやすいか」「どのフェーズで案件が停滞しているか」を横断して分析できます。

KPIツリーに紐づけて蓄積対象を決める

蓄積対象を決めるときは、営業生産性のKPIツリーから逆算します。商談数を分解すると新規問合せ数・商談化率・有効商談創出数、受注率を分解すると初回突破率・キーマン接触件数、単価を分解すると初回受注単価・クロスセル率・アップセル率、工数を分解すると顧客対応時間・社内業務時間といった指標が並びます（出所：株式会社マツリカの営業生産性フレーム）。

このツリーのなかで「今いちばん詰まっている数字」を1つ選び、その数字を分解・分析するのに必要なデータだけを蓄積対象にします。受注率が詰まっているなら、フェーズごとの通過率・担当別の受注率・キーマン接触の有無が必要なデータになります。この絞り込みが、後述する「小さく始める」の起点になります。

営業データの生成やデータ分析で使う基本用語を先に押さえておきたい場合は、営業データの分析基本用語が参考になります。

蓄積の前提：生成層で入力が回っているか

ここが営業DWHで最も見落とされやすい前提です。DWHはあくまで生成層から流れてきたデータを集める層なので、そもそもSFAやMAへの入力が習慣化していなければ、集まるデータは乏しく空箱になります。

たとえば、案件フェーズが更新されず、活動履歴も入力されていないSFAをつないでも、DWHには断片的なデータしか流れてきません。「議事録は個人のメモに、商談の温度感は担当者の頭の中にある」状態では、DWHに集める前に生成層を整える必要があります。DWHの構築を検討する前に、生成層で入力が回っているかを点検することが、遠回りに見えて確実な近道です。

営業データをDWHに蓄積するメリットと注意点

営業データをDWHに蓄積するメリットは、散在の解消・分析の高度化・時系列の正確な保持の3つに集約できます。一方で、構築・運用にコストがかかること、そして生成層が回っていないと空箱になることが注意点です。DWHを入れるだけで営業の数字が自動的に動くことはありません。効くのは、生成層と活用層がそろったときです。

以下でメリットと注意点を具体的に見たうえで、どちらのケースでDWHに進むべきかを条件付きで示します。

メリット｜散在の解消・高度な分析・正確な時系列

第一のメリットは、複数ソースに散らばったデータの一元化です。手作業でのファイル結合や表記ゆれの修正から解放され、数字を作る工数が減ります。第二は分析の高度化です。リード・案件・受注実績を横断できるため、流入経路別の受注率や、フェーズ別の停滞状況といった、単一システムでは見えなかった切り口が分析できます。第三は時系列の正確な保持です。過去の状態を不揮発に残すことで、変化そのものを分析対象にできます。

これらは、属人化の解消にも直結します。属人化はデータの一元化とプロセスの標準化の両輪で解消されますが、DWHはこのうちデータの一元化を担う仕組みです。誰かの頭の中やExcelにしかなかった数字が、組織の共有資産になります。

デメリット・注意点｜構築/運用コスト・目的なき蓄積のリスク

一方で、DWHには構築と運用のコストがかかります。データソースの接続設計、整形ルールの定義、定期実行の運用など、作って終わりではなく継続的なメンテナンスが必要です。データソースが増えたり項目が変わったりすれば、整形ルールも見直します。

もう1つの注意点が、目的なき蓄積のリスクです。何を分析したいかを決めずに「将来使うかもしれない」とデータを溜め込むと、運用コストだけがかかり、誰も見ないデータの倉庫になります。前述のとおり、生成層で入力が回っていなければ、そもそも溜まるデータが乏しく空箱になる点も繰り返し確認しておきたいところです。

導入を優先すべきケースと、先に生成層を整えるべきケース

ここは条件で言い切れます。SFAやMAへの入力がすでに習慣化しており、複数ソースにデータが散らばって手作業でのつなぎ直しが発生しているなら、統合・蓄積（DWH）に進むべきタイミングです。散在の解消と分析の高度化の効果がすぐに出ます。

一方、まだSFAやMAへの入力が定着しておらず、案件情報や活動履歴が十分に溜まっていないなら、DWHより先にSFA/CRM運用の定着を優先すべきです。生成層でデータが生まれる仕組みを作ることが、DWHを活かす前提になります。

営業データをDWHに集める進め方

営業DWHは、いきなり全社規模で作ろうとすると、要件定義だけで頓挫しがちです。1つのKPI（たとえば受注率）を解くための最小のデータセットから小さく始めるのが、失敗しにくい進め方です。壮大な基盤を目指すより、解きたい問いを1つに絞ることが成功の分かれ目になります。

以下の5ステップで、各段階の営業側のアクションと成果物を示します。

ステップ1：解きたい問いを1つに絞る

まず、営業生産性のKPIツリーのなかで、今いちばん詰まっている数字を1つだけ選びます。「受注率が下がっている理由を知りたい」のように、問いを具体的な1文にします。ここで欲張って複数のKPIを同時に扱おうとすると、必要なデータが膨らみ、最小構成の利点が失われます。成果物は「解きたい問いを書いた1文」です。

ステップ2：必要なデータソースだけを特定する

選んだ問いを分析するのに必要なデータだけを洗い出します。受注率を解くなら、SFAの案件フェーズ・担当・受注実績が中心になり、リードの流入経路など直接関係しないデータは後回しにします。この段階で「あれも使うかもしれない」と対象を広げないことが、小さく始める要点です。成果物は「接続するデータソースと項目のリスト」です。

ステップ3：連携・整形のルールを決める

特定したデータソースをつなぐにあたり、表記統一のルールとキー設計を決めます。企業名や担当者名をどう名寄せするか、どの項目を突き合わせのキー（顧客IDなど）にするかを事前に定義します。ここを曖昧にすると、集めたデータが正しく結合できず分析に使えません。成果物は「整形ルールとキー設計の定義書」です。

ステップ4：小さく蓄積し、活用層で検証する

決めたルールで最小のデータセットを蓄積し、活用層（BIツール）で実際に分析してみます。受注率をフェーズ別・担当別に可視化し、当初の問いに答えられるかを検証します。ここで初めてDWHの価値が数字として見えます。成果物は「問いに答えるダッシュボード」です。

ステップ5：効果を確認してから対象を広げる

最小構成で効果が確認できたら、次のKPIや別のデータソースへと蓄積対象を段階的に広げます。1つ成功事例を作ってから広げることで、社内の理解も得やすく、運用の型も再利用できます。いきなり全社に広げるのではなく、成果を確認しながら育てる姿勢が、DWHを空箱にしない鍵です。

営業データをDWHに蓄積する活用イメージ

DWHに営業データを溜めると、これまで感覚で語られていた判断を、数字と時系列の根拠で下せるようになります。活用の効き方は、営業生産性の変数ごとに具体化すると分かりやすくなります。以下では、受注率・単価まわり・活用層との連携という切り口で、どんな判断ができるようになるかを示します。

DWHはあくまで溜める仕組みなので、活用層（BIツール）で見て初めて判断につながります。両者はセットで機能する点を念頭に読み進めてください。

受注率の低下要因をフェーズ別・担当別に分析する

DWHに案件のフェーズ・担当・受注実績を時系列で溜めておくと、受注率がどのフェーズで落ちているかを分解できます。初回商談から提案までの通過率が下がっているのか、提案からクロージングで失注が増えているのかが分かれば、打ち手が変わります。担当別に見れば、特定のフェーズで成績にばらつきがある場合に、上位者のプロセスを標準化する材料にもなります。

売上推移・単価・クロスセル状況を時系列で把握する

受注金額や商材のデータを時系列で持っておくと、単価の推移やクロスセル・アップセルの発生状況を追えます。単価が下がった時期に何が起きていたか、どの顧客層でクロスセルが伸びているかを、過去との比較で把握できます。時系列で溜めているからこそ、単発の集計では見えない変化のパターンをつかめます。

活用層とセットで初めて生きる

繰り返しになりますが、DWHは溜める仕組み、BIは見る仕組みです。DWHに整ったデータがあっても、活用層で可視化して意思決定に使わなければ、その価値は眠ったままになります。逆に、活用層が見たい切り口を先に決めておくと、DWHに何を溜めるべきかも明確になります。溜める側と見る側を行き来しながら設計することが、実務では効きます。

営業データ向けDWHを選ぶときの観点

DWHやその周辺の基盤を選ぶときは、製品名から入るのではなく、観点を先に固めるのが失敗しない順序です。営業データの実態に照らすと、重視したい観点は操作性、既存のSFA/CRMや他SaaSとの連携の柔軟性、個人情報を扱うためのセキュリティ、導入後のサポートの4つです。以下で観点を整理したうえで、最後に「つなぐ」役割を担う製品カテゴリの例を1つだけ挙げます。

オンプレミスかクラウドか

DWHには、自社の設備に構築するオンプレミス型と、クラウドサービスとして利用するクラウド型があります。クラウド型は初期投資を抑えて小さく始めやすく、利用量に応じて拡張できるため、前述の「1つのKPIから小さく始める」進め方と相性がよい傾向があります。厳格なデータ管理要件がある場合はオンプレミス型が検討されますが、営業データの分析用途では、まずクラウド型で始めるケースが増えています。

既存のSFA/CRM・他SaaSとの連携の柔軟性

営業DWHは、SFA・MA・名刺管理・会計など複数のSaaSからデータを集めます。そのため、すでに使っているツールとどれだけ柔軟につながるかが実務上の分かれ目になります。連携できるサービスの範囲、連携の設定にかかる手間（ノーコードで設定できるか、開発が必要か）を、選定時に必ず確認します。ここが弱いと、結局手作業でのデータ取り込みが残り、DWHの利点が薄れます。

拡張性・操作性・セキュリティ・サポート

小さく始めて段階的に広げる前提なら、後からデータソースや利用者を増やせる拡張性が重要です。日々分析するのは営業やマーケの現場担当なので、専門知識がなくても扱える操作性も見ておきます。加えて、営業データには顧客の個人情報が含まれるため、アクセス権限の管理や暗号化といったセキュリティ要件を満たすかは必須の確認事項です。導入後に運用でつまずかないための、サポート体制の手厚さもあわせて評価します。

生成から活用までをつなぐ製品カテゴリの一例

複数のSaaSやデータを整えてつなぐ役割を担う製品カテゴリの一例として、Mazrica DataHubがあります。Mazrica DataHubは、700以上のSaaS・AIとノーコードで連携し、AI・API・RPA・OCRを使ってデータの連携・統合・整形を自動化する「つなぐ」製品群に位置づけられます。手作業で行っていたデータの取り込みや整形を自動化することで、営業・マーケが分析や顧客対応に向き合う時間を生み出せます。

なお、溜めたデータを可視化する活用層の製品もあります。営業・顧客データを役割ごとに可視化するMazrica BIはその一例ですが、こちらはMazrica Salesと組み合わせて使う製品である点に留意してください。どの製品を選ぶにせよ、前述の観点（連携の柔軟性・操作性・セキュリティ・サポート）を自社の要件に照らして比較することが先決です。

まとめ｜営業データを資産化する第一歩

営業DWHは、散らばった営業情報やデータを1箇所に集め、時系列で蓄積して分析できる状態を作る「統合・蓄積層」です。ただし、それ単体では営業の数字を動かしません。SFAやMAへの入力がすでに回っているなら統合・蓄積（DWH）へ進むべきタイミングであり、まだ入力が定着していないなら生成層の定着を先に進めるべきです。

そして、壮大な全社基盤を目指すより、解きたい問いを1つに絞ることが成功の分かれ目になります。受注率でも単価でも、いちばん詰まっている数字を1つ選び、その分析に必要な最小データから始めるのが現実的です。

最初の一歩は、いきなりKPIツリーを書き出すことではありません。まず、現在バラバラに管理している営業データのソースを棚卸しし、「どこに・何が・どんな形で溜まっているか」を一覧にするだけで十分です。この棚卸しが、生成層が回っているかの点検にもなり、DWHに進むべきか生成層を先に整えるべきかの判断材料になります。

生成から活用までを含む体系的な全体像は、営業データ活用基盤の全体像を参照してください。

よくある質問

Q. 営業データ活用基盤（DWH）の構築にはどのくらい費用・期間がかかりますか？

クラウド型のDWHは月額課金や利用量に応じた従量課金が主流で、小さく始められる料金体系が増えています。構築期間はスコープ次第で、1つのKPIを解く最小構成なら数週間、複数部門を横断する規模になると数か月かかることもあります。まず小さく始めて効果を確認し、段階的に広げるほうが、初期の費用と期間を抑えやすくなります。

Q. ExcelやスプレッドシートではDWHの代わりになりませんか？

データ量が少なく単発の集計なら、ExcelやスプレッドシートでもDWHの役割をある程度こなせます。ただし、複数ソースのデータを統合する、月次・週次で時系列に履歴を溜める、複数人が同時に安全に利用する、といった場面ではつまずきやすくなります。表記ゆれの手作業修正やファイルの結合が毎回発生するようになったら、DWHの検討時期といえます。

Q. データレイクとDWH、営業データにはどちらが向いていますか？

受注率や単価の推移を数値で分析するのが中心なら、構造化して溜めるDWHが向きます。議事録や商談の音声など、あらかじめ列に収まらない生データも残して後からテキスト分析やAI活用に使いたいなら、データレイクが向きます。実務では、DWHで構造化データの分析を回しつつ、非構造化情報はデータレイクに溜めておくという併用も選択肢になります。

Q. DWHとBIツールは何が違い、両方必要ですか？

DWHはデータを整えて溜める仕組み、BIツールは溜めたデータを可視化して分析する仕組みで、役割が分かれています。基本は両方をセットで使いますが、扱うデータ量が小さく単一のシステムで完結する場合は、蓄積と可視化を兼ねた製品でカバーできることもあります。データソースが複数に増えてきたら、溜める層としてDWHを分けて持つ意義が大きくなります。

Q. まだSFA/CRMを入れていなくてもDWHは作れますか？

技術的には可能です。ただし、DWHは生成層から流れてくるデータを集める層なので、入力の仕組みであるSFA/CRMがないと、集まるデータが乏しく空箱になりやすくなります。営業DWHの効果を出すには、まずSFA/CRMへの入力が習慣化し、案件情報や活動履歴が溜まる状態を先に作るほうが確実です。

Q. 中小企業でも営業DWHは必要ですか？

必要かどうかは、企業規模より「複数のソースにデータが散っていて、数字を作るたびに手作業でつなぎ直しているか」で判断します。散在と手作業が起きているなら、規模が小さくても効果があります。1つのKPIを解く最小構成から始められるため、いきなり大がかりな投資をする必要はありません。