SalesforceユーザーがETLを利用する5つのシナリオ

2022/06/27

copied!

はじめに

Salesforceが事実上、顧客や案件情報のマスターデータとなっている企業は多いかと思います。そのため、SalesforceのデータをSalesforce上で利用するだけでなく、Salesforceから抽出したデータを別のシステム上で利用することも多いのではないでしょうか。

当社はETL製品である「Reckoner」の開発元として、どのような場面でETLを用いてデータを抽出・変換・ロードすればよいかについて、豊富なノウハウを有しています。以下では、ETLを利用しSalesforceのデータを管理する、5つの具体的な利用シナリオをお伝えします。

シナリオ１ Salesforce から別のシステムへ

では、Salesforceにあるデータを変換した後に、別のシステムで利用する場合のETL利用シナリオを見てみましょう。ERPや会計製品といったパッケージ製品、または自社独自の基幹システムに対して、Salesforceのデータを変換・ロードする場合です。

1.Salesforceのデータを変形後、基幹システムにロード

リモートワークが当たり前になっている昨今において、社内でサイロ化されているデータが日に日々増えている会社も多いのではないでしょうか。このシナリオでは、以下のようなケースが想定されます。

Salesforce上の受注データを変形したのちにロードし、ERP・基幹システムが製品の生産開始を指示する
Salesforce上の未発注売上見込み情報を変形したのちにロードし、会計システム上の情報を随時更新する
Salesforce上の受注済情報を変換したのちにロードし、請求書発行を毎月自動で行う

SalesforceとAPI連携が可能な製品を除くと、「データの抽出」「データの変換」「データのロード」といった一連の処理を、自作のマクロなどを利用して半自動で行っている企業が多いのではないかと思います。こうした自作のマクロ処理は、システム側での変更があるたびに更新が必要であること、またマクロ作成のノウハウが属人的であることが多いため、安定的に継続稼働させるにはリスクがあります。

Reckonerを利用すると、あらかじめ定められた条件に従い、抽出・変換・ロードを全自動で実施できるほか、ノンプログラミングで利用できるため、エンジニアでないユーザーでも処理を作成できます。処理が属人的になることもありません。

2.SFDCの案件情報、個人情報などのデータを変形したのちに、DWHにロード

Salesforce自身はDWHではないため、Salesforce内にある顧客情報、商談情報、受注情報などをDWHに格納している例は多いかと思います。

Salesforce上にある個人情報を、データ変換した後にマーケティング分析用DWHにロードし、次のマーケティングキャンペーンの分析に利用する
Salesforce上にある商談情報を、データ変換した後に営業管理用DWHにロードし、全国の営業担当者の活動評価に利用する
Salesforce上にある受注情報を、データ変換した後にプロジェクト管理用DWHにロードし、各事業部のプロジェクト管理用マスターとして利用する

Salesforceは主要なDWHとAPI連携していますが、詳細な連携にはプログラミングが必要になるケースがあり、開発コストやメンテナンスコストがかかります。また、担当者が「こうしたデータが欲しい」「データ取得頻度を変えたい」と変更リクエストを出すたびに、新たな開発が必要となるため、営業やマーケティング活動のスピード感が損なわれるというデメリットがあります。

Reckonerは、AWS Redshift や BigQuery といった主要DWHに対応し、スムーズな連携と詳細なデータ変換をノンプログラミングで実現できます。

シナリオ2 別のシステムからSalesforceへ

別のシステム上にあるデータを、変換した後にSalesforceに登録・更新する場合のETL利用シナリオを見てみましょう。

3.新規で取得した個人情報を変換したのちに、Salesforceにロード

セミナー、イベント、展示会、商談時の名刺交換といった対面での営業マーケティング活動後に、取得した個人情報を、Salesforceの形式に合わせて変換したのちにロードし、今後の活動に用いる
オンラインセミナー、ホワイトペーパーのダウンロード、問い合わせといった非対面のマーケティング活動で取得した個人情報を、Salesforceの形式に合わせて変換したのちにロードし、今後の活動に用いる

一時的であっても、暗号化されていないExcelやCSVファイル、または担当者個人のGoogleスプレッドシートなどで、個人情報が管理されることは、個人情報漏えいのリスクが高いため非常に危険です。よって、Salesforceのように「権限がある人以外は個人情報を操作できない」「作業のログが全て保存される」といった安全な場所で管理する必要があります。

様々な方法で取得したデータを、都度フォーマットを変換してSalesforceにロードするのは大変面倒な作業であるだけでなく、ヒューマンエラー（データ漏れや変換ミス）が発生しがちです。

各所から取得してきた個人情報を、Reckonerを利用してどのように変換するかをあらかじめ定義しておけば、「指定されたタイミングで個人情報のフォーマットを変換したうえで、Salesforceにロード」する作業が全て自動で実施されます。

4.既存の会社情報・個人情報を変換した後に、Salesforceにロード

上記3.は、「新たに入手した情報の変換・ロード」ですが、4.は「既存情報メンテナンス目的での変換・ロード」です。

既存顧客の会社情報や個人情報（会社名、住所、部署名、電話番号など）が変更となった
マーケティング属性 (DM可/不可、メルマガ可/不可など）の変更希望があった

上記のような既存の情報は、誤って変更すると大きな影響を及ぼしかねません。そのため、「ユーザーは直接変更できない」「ユーザーは情報システム部に対して変更申請を行い、情報システム部で確認後一括変更」しているケースが多いかと存じます。

こうした処理を行う際、情報システム部のSalesforce管理者が、ユーザーが入力したExcelファイルやCSVファイルを都度アップロードするのは手間がかかります。

自動化しようとマクロを組んだ場合、Salesforceの仕様変更のタイミングがあるごとに修正が必要になり、またマクロは知識がある担当者が片手間で作成されることも多いため、「マクロ自体、またはマクロの運用がブラックボックス化しやすい」というデメリットがあります。

Reckonerを利用すれば、Salesforce上の既存情報のメンテナンスもノンプログラミングで、全ての関係者に処理が可視化される形で行うことができます。

5.様々なフォーマットの受注データを変換した後に、Salesforceにロード

販売窓口を自社ECサイトのみに絞っているようなケースを除き、ほとんどの企業では「電話」「メール」「フォーム」「チャットツール」「発注書（PDF）」「発注書（紙）」「FAX」など、様々なチャネルで注文を受けています。

これらのデータをまとめて同じフォーマットで「受注情報」としてSalesforceに登録する際、全てのチャネルを同じ方法で登録するのは非効率です。フォーム入力であれば、直接Salesforceに取り込む方が早いですが、「顧客企業テンプレートの紙の発注書」となると、直接Salesforceに取り込むことができず、いったん人手を介する必要があるためです。

「受注データを目視で確認し、手で転記する」場合や、「OCRやRPAで半自動処理する」場合など、それぞれのケースで作成された受注データ（Excel, CSVなど）をできるだけ早くSalesforceに反映しようとすると、この反映処理のために多くの工数が割かれる場合があります。

Reckonerを利用した場合、複数のチャネルから別々に出力された受注データであっても、定められた条件や頻度に従い、変換・ロード処理を完全自動で行えます。