EDA の取引先モデルの理解
学習の目的
この単元を完了すると、次のことができるようになります。
- Salesforce の取引先モデルと EDA の取引先モデルの違いを説明する。
- 管理取引先モデルと世帯取引先モデルの違いを説明する。
- EDA に含まれるデフォルト取引先レコードタイプについて理解する。
Salesforce と取引先モデル
Salesforce の歴史を簡単に説明すると、Salesforce は元来、企業のセールスプロセスを向上させ、ひいては売上を最大限に伸ばすことを目的とするビジネス対ビジネス (B2B) アプリケーションとして設計されたものです。従来の B2B のシナリオでは、各企業がその取引先 (販売相手となる企業や事業) とのやりとりを記録してその経過を把握します。取引先ごとに、その取引先に関連付けられた人々 (取引先責任者) とその他の事物 (商談、ケース、ToDo など) が存在します。Salesforce において、このすべてが相互に連携し合うしくみを取引先モデルといいます。
幼稚園から大学院に至る教育業界では、物事を追跡する方法が多少なりとも異なります。Salesforce ではもちろん、入学希望者の勧誘目的で提携している企業や事業、学生を募集する高校、転校生を受け入れる他の教育機関などとのビジネス活動が管理されます。けれどもそれだけではありません。学生が何をしているのか、どの授業を受けているのか、どの部活に所属しているのかなど、学生について把握することも大切です。Salesforce では、学部、部活動、同窓会組織なども追跡できるようにしたいと考えました。とすると、ビジネス向けに設計されたアプリケーションで、このすべての事項を管理するにはどうすればよいかと言う疑問が浮上します。そして、Salesforce.org が EDA と EDA の取引先モデルを採用した優れたソリューションを設計しました!
EDA の取引先モデル
EDA の取引先モデルは Salesforce の標準の取引先モデルと密接に連携しています。Salesforce のあらゆる機能を活用できるため、各自のニーズに合わせて標準モデルをカスタマイズする必要がありません。商談やケースのような Salesforce の標準オブジェクトがそのまま搭載され、必要に応じて EDA でビジネスを追跡できます。その一方で Salesforce.org は、EDA を基盤に、教育業界の利用者の業務に応じたカスタム機能を備えたアプリケーションを作成しました。
EDA の取引先モデルでは、Salesforce の標準の取引先オブジェクトがコンテナ取引先として機能します。EDA には 2 種類のコンテナ取引先があります。管理取引先と世帯取引先です。
管理取引先には、1 人の取引先責任者が関連付けられます。この取引先責任者は通常学生ですが、教職員や卒業生、教育機関に関連のある他の個人である場合もあります。この取引先と取引先責任者には 1 対 1 の関係があります。つまり、EDA で作成する取引先責任者ごとに、固有の管理取引先を設定します。管理取引先は、取引先責任者を取引先レベルで表すものと考えることができます。
世帯取引先はその名のとおり、学生である取引先責任者が属する世帯を表します。管理取引先が 1 対 1 の関係であるのに対し、世帯取引先には通常、親や保護者、兄弟姉妹、同居人など、学生のほかに複数の取引先責任者が存在します。
どちらの取引先モデルを選んだとしても、独立した取引先責任者 (つまり、どの取引先にも属していない取引先責任者) を作成するたびに、Salesforce がコンテナ取引先 (管理または世帯) を作成します。デフォルトでは、新しい取引先責任者の姓が新しい取引先の名前になります。(EDA では、コンテナ取引先の命名規則もカスタマイズできます。それについては後のモジュールで詳しく説明します。)
たとえば、Pete Peterson という取引先責任者は Peterson 管理取引先に属します。取引先責任者レコードには、次のように表示されます。
世帯取引先モデルを使用している場合は、「Peterson 世帯取引先」という名前になります。ご覧のとおり、管理取引先と世帯取引先のどちらを選択するかは、取引先の命名に影響します。また、EDA での取引先責任者と取引先の住所データの管理にも影響します。世帯取引先では、より複雑な住所管理が可能です。
ここでこの概念を力説するのも、EDA では取引先責任者がその中核をなすためです。取引先責任者を中心に据えることで、校内におけるその一員の全体像をとらえることが可能になり、その取引先責任者について「関心事は何か」「誰と知り合いなのか」といった極めて重要な質問に答えることが可能になります。Salesforce では、どの取引先責任者も取引先に関連付けられている必要があります。取引先のない取引先責任者は、作成したユーザーにしか表示されません。
取引先モデルの選択
では、どちらの取引先モデルが自分に適しているでしょうか? 教育機関はそれぞれ異なることから、各学校が最も適したアプローチを選択できます。実装パートナーと提携する場合は、コンサルタントがこの意思決定プロセスをサポートしてくれます。
Nina が Cloudy College でシステム管理者の役割に就いたときに最初に行った意思決定の 1 つが取引先モデルの選択でした。彼女は、どちらの取引先モデル (または両方) を使用するかは、いくつかの要素によって決まるということを理解していました。そこで、検討すべき要素について考えを整理するために次の表を作成しました。
|
管理
|
世帯
|
|
|---|---|---|
|
デフォルトのモデル
|
X |
|
|
取引先レベルのメンテナンスが簡単
|
X |
|
|
取引先あたりに複数の取引先責任者をサポート
|
|
X |
|
世帯住所レコードの追跡をサポート
|
|
X |
ただし、両方のユースケースがある場合にはどうすればよいでしょうか? その場合、学生のライフサイクルの異なる時点で異なるモデルを使用することが可能です。また、同じ組織内で両方の種別のコンテナ取引先を使用している学校もあります。柔軟性が成功への鍵です。
たとえば、Nina は学生募集、入学事務、現役学生に関するプロセスには管理取引先を使用し、その後、同窓生になったときには学生取引先責任者を世帯取引先モデルに変換するのが理にかなっていると判断しました。
学校に何が最適かにかかわらず、管理取引先または世帯取引先のどちらかの種別を組織レベルの [EDA Settings (EDA 設定)] のデフォルトとして設定する必要があります。独立した取引先責任者 (別の取引先に属していない取引先責任者) を新規作成するたびに、デフォルトとして指定した種別を使用して自動的にコンテナ取引先が作成されます。
取引先責任者、リレーション、所属
これで取引先責任者と管理 (または世帯) 取引先が設定されましたが、取引先責任者レコードは何かに活用できなければ意味がありません。作成した時点の取引先責任者は真っ白なキャンバスです。ある個人の基本情報を表しているに過ぎません。その後、「取引先責任者は学生、教職員、卒業生のどれに該当するか、あるいはその複数に該当するのか?」「取引先責任者はスポーツ選手か、特定の部活に属しているか?」「取引先責任者は教育機関の他の取引先責任者とつながっているか?」「取引先責任者は卒業生の子女か?」「取引先責任者が他の取引先責任者と婚姻関係にあるか?」など、その個人が教育機関とどのように関連しているかを定義していく必要があります。この定義に使用するのがリレーションと所属です。
EDA の取引先モデルの一環として、EDA には取引先責任者と併用する重要なカスタムオブジェクトが 2 つ用意されています。
- リレーションカスタムオブジェクトは、取引先責任者間のリレーション (誰と知り合いか?) を追跡します。
- 所属カスタムオブジェクトは、取引先責任者と他の取引先間の所属 (関心事は何か?) を追跡します。
この場合、他の取引先とは何を意味するのでしょうか? EDA で取引先となる可能性があるのが学部です。スポーツチームも取引先の 1 つです。内定先の企業が取引先になることもあります。このアーキテクチャは柔軟です! ここで留意すべき重要な点は、所属取引先が他の人々ではないことです。取引先は学部、アカデミックプログラム、大学、その他の企業や組織などのものやグループです。そして、所属の一環として、取引先責任者のロール (学生、教員、スポーツ選手など) を指定して、取引先責任者の取引先とのつながりを決定します。
他方、人々 (つまり、Salesforce の他の取引先責任者レコード) とのつながりは、リレーションオブジェクトを使用して作成します。
例を見てみましょう。Pete Peterson (取引先責任者) はリレーションを介して人々 (他の取引先責任者) とつながっています。他方、教育課程や関心事 (取引先) とは所属を介してつながっています。
この例の Peterson 管理取引先は、所属取引先ではありません。取引先責任者に必須の親取引先です。学部やスポーツチームといった他の取引先への所属を作成すると、EDA がこれらの取引先を直接取引先責任者 (この場合は Pete Peterson) に関連付けます。
これは、リレーションと所属が取引先モデルにどのように関連し、EDA での賛助者の全体像の把握にどのように役立っているかを簡単に示したものです。リレーションと所属については、後のモジュールで詳しく説明します。
これで、EDA のアーキテクチャ、設定、取引先モデルを学習し、EDA の概要を習得できました。これは、教育機関のシステム管理者ジャーニーの重要なマイルストーンですが、やる気がある皆さんのために、さらに多くのものが用意されています。次に取り組むのに適したモジュールのリンクが下にあります。Nina もまた登場します。トレイルでお会いしましょう。
リソース
- Salesforce ヘルプ: EDA データモデルオリエンテーションへようこそ
- Salesforce ヘルプ: Configure Account Model Settings (取引先モデル設定の構成)
- Salesforce ヘルプ: 教職員、スタッフ、学生の取引先責任者のモデル化
- Trailhead: EDA の設定とデータのインポート