---
sourceDocument: オーストラリアのカスタマーサービス管理 (CSM)
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/customer-service-management

 Release :

    - australia

ft:locale :

    - ja-JP

ft:publication_title :

    - オーストラリアのカスタマーサービス管理 (CSM)

ft:clusterId :

    - csm

bundleId :

    - csm

workflow :

    - Customer and Industry


---

# 業種別のユースケース

# 業界固有のデータモデルシナリオ {#ariaid-title1}

* リリースバージョン: Australia
* 
* 更新日 2026年08月07日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：12分

サービスモデル基盤データモデルは、ビジネス組織構造をモデル化するために不可欠です。さまざまな業界にわたって構成して適用できます。各例は、実際の運用モデルをサポートするために、内部および外部の事業所、サービス組織、および顧客リレーションシップがどのように構成されているかを示しています。

## 業界横断的な サービスモデル基盤 を探る {#smf-data-model-example__section_tjg_bbx_1hc}

次の例は、 公共機関デジタルサービス、 ファイナンシャルサービスオペレーション、 ヘルスケアとライフサイエンス、 製造業営業オペレーション、 リテールオペレーション などのさまざまな業界の組織が、サービス組織を構成し、内部ユーザー、外部エンティティ、および顧客間の関係を定義する方法を示しています。これらのシナリオは、複雑な階層のモデル化、サービスデリバリーの管理、および実際のユースケースへの役割の調整における SMF の柔軟性を強調しています。

## ユースケース:で複数の支店にまたがる顧客とアカウントの管理 ファイナンシャルサービスオペレーション {#smf-data-model-example__section_ad3_3bx_1hc}

概要:このユースケースでは、多国籍金融機関が本社 (HQ)、地域本社、支店、独立系アドバイザーの場所などの事業所のネットワークを通じてどのように運営されているかを示します。

各拠点は特定の目的を果たし、顧客やアカウントを管理するマネージャー、従業員、アドバイザーなどのスタッフを雇用しています。

データの正確性、可視化、およびアクセス制御を維持するために、組織は サービスモデル基盤 を使用して階層をモデル化し、ロールを定義し、従業員、顧客、および場所間の関係を管理します。

問題シナリオ:大手金融サービス組織であるFinServe Ltdは、内部および外部の支店のネットワーク全体で、アクセスの不整合や顧客の所有権の競合という繰り返しの問題に直面していました。  
観察された課題:

* アカウントの重複所有:異なる支店の複数の従業員が同じ顧客レコードを表示または変更できます。
* アクセス違反:外部アドバイザーが意図せず内部のビジネスアカウントを可視化していました。
* あいまいな顧客関係:特定の顧客またはアカウントに対してどの従業員または支店が責任を負っていたかが明確に示されていません。
* 複雑なメンテナンスオーバーヘッド:場所階層を更新したり、従業員を再アサインしたりすると、関係が壊れ、権限の不一致が発生しました。
{#smf-data-model-example__ul_sht_qfx_1hc}これらの課題は、データガバナンスのリスク、顧客の信頼の低下、アクセスに関する異議申し立てを解決するための手作業の増加につながりました。  
関連ペルソナ:

* 本社の従業員:トップレベルの業務と主要なビジネスアカウントを管理します。
* 地域本社マネージャー -- 支店の活動を監督し、現地のビジネスアカウントを監督します。
* 支店の従業員 -- 日々の顧客トランザクションとビジネス関係を処理します。
* 独立アドバイザー (外部ユーザー) -- コンシューマーと世帯の顧客を管理します。
* 顧客:ビジネスエンティティまたは個々のコンシューマーのいずれかを表します。
{#smf-data-model-example__ul_yz1_kdx_1hc}  
前提条件:

* SMF では、組織のビジネス階層 (本社、地域本社、支店、独立アドバイザー) が事業所として定義されます。
* 内部ユーザーと外部ユーザーは、適切なペルソナ (マネージャー、従業員、関係マネージャーなど) とともにそれぞれの場所にアサインされます。
* 顧客とアカウントはシステムに登録され、担当従業員にリンクされます。
{#smf-data-model-example__ul_ehr_2gx_1hc}  
図 : 1. 金融機関における事業所とアクセス階層 解決ワークフロー/ソリューション実装:

1. 事業所階層の定義
   * 組織は、事業所の構造化された階層を確立します。
     * 本社:親会社
     * 地域本社:複数の内部支店を監督する
     * 会社の支店:事業顧客の管理
     * 独立アドバイザーの場所:コンシューマーアカウントと世帯アカウントを管理する外部エンティティ
     {#smf-data-model-example__ul_kzh_5gx_1hc}
   * 各場所タイプは、所有権とアクセスレベルに基づいて内部または外部のいずれかとして定義されます。
   {#smf-data-model-example__ul_sgw_mhx_1hc}
2. 場所にスタッフをアサイン
   * 本社および支店のスタッフは内部ユーザーです。
   * 独立アドバイザーの場所には、パートナーシップ契約に基づいて活動する外部ユーザーが含まれます。
   * 各スタッフメンバーは事業所にマッピングされ、ロール (マネージャー、従業員、アドバイザーなど) がアサインされます。
   {#smf-data-model-example__ul_dd4_vhx_1hc}
3. 顧客とアカウントの関係を確立する
   * 顧客 (企業、コンシューマー、または世帯) は、特定の従業員にリンクされます。
   * 各従業員には定義された責任があります。
     * 本社の従業員は、事業顧客のアカウントマネージャーです。
     * 支店の従業員は、地域の事業顧客のアカウントマネージャーです。
     * 独立アドバイザーは、コンシューマーまたは世帯の関係マネージャーです。
     {#smf-data-model-example__ul_h4k_f3x_1hc}
   {#smf-data-model-example__ul_mq1_d3x_1hc}各従業員はそれぞれの顧客またはアカウントにリンクされていました。このマッピングにより、所有権の競合が解消され、説明責任が明確になりました。
4. アクセス制御とデータの可視化を決定するSMF は、ペルソナと事業所に基づいてアクセスルールを自動的に適用しました。

   * アカウントや顧客プロファイルなどのレコードへのアクセスは、次の基準に基づいています。
     * 従業員にアサインされた事業所。
     * リレーションシップロール (アカウントマネージャー、リレーションシップマネージャーなど)。
     * SMF で定義された階層。
     {#smf-data-model-example__ul_tqp_43x_1hc}
   * たとえば、次のようになります：
     * 本社の従業員 2 は、事業顧客 1 にアクセスできます。
     * 支店 1 の従業員 2 は、事業顧客 2 にアクセスできます。
     * アドバイザーの従業員 1 は、コンシューマー 1 を表示および管理できます。
     {#smf-data-model-example__ul_rws_53x_1hc}
   {#smf-data-model-example__ul_rtv_n3x_1hc}
5. 場所の関係性の管理
   * 従業員 2 などの本社スタッフは、場所の関係マネージャーとして、外部アドバイザーの場所の監督を維持することができます。
   * 類似点として、本社の従業員 2 はアドバイザーの場所 1 と 2 のアクティビティをレビューできます。
   {#smf-data-model-example__ul_vy1_cjx_1hc}これにより、外部パートナーの活動が会社の標準およびコンプライアンスポリシーに準拠していることが確認されます。
{#smf-data-model-example__ol_urm_ngx_1hc}

結果:

FinServe Ltd は、 サービスモデル基盤 データ モデルを適用することで、複数の事業所にわたるアクセスの不整合と所有権の競合を解決しました。このフレームワークは、大規模な財務環境で顧客関係を管理するための、統一された安全かつ透過的なアプローチを提供しました。

## ユースケース:での患者、医療提供者、アカウントの管理 ヘルスケアとライフサイエンス {#smf-data-model-example__section_w2k_ytx_1hc}

概要:このユースケースでは、多国籍医療機関が、本社 (HQ)、地域の臨床本社、病院または診療所、独立したプロバイダーまたは研究拠点などの事業所のネットワークを通じてどのように運営されているかを示します。

各拠点には特定の目的があり、アドミニストレーター、臨床医、患者アカウント、臨床研究、医療サービスを管理する外部パートナーなどのスタッフが雇用されています。

データの正確性、可視化、およびアクセス制御を維持するために、組織では サービスモデル基盤 を使用して階層をモデル化し、ロールを定義し、従業員、患者、および場所間の関係を管理しています。

問題のシナリオ:大手医療機関である HealthCorp Ltd は、内部と外部の拠点間でアクセスの不整合や患者/アカウント管理の競合など、繰り返し発生する問題に直面していました。  
観察された課題:

* 患者レコードの重複:異なる場所の複数の従業員が同じ患者データを表示または変更できます。
* アクセス違反:外部の研究パートナーまたはプロバイダーパートナーが意図せず内部の臨床記録を可視化していました。
* あいまいなアカウント所有権:特定の患者または臨床研究にどの従業員、臨床医、または場所が責任を負っていたかが明確に示されていません。
* 複雑なメンテナンスオーバーヘッド:場所階層の更新やスタッフの再アサインにより、関係性が壊れ、権限の不一致が発生しました。
{#smf-data-model-example__ul_x2k_ytx_1hc}これらの課題は、コンプライアンスのリスク、患者の信頼の低下、アクセスに関する異議申し立てを解決するための手作業の増加につながりました。  
関連ペルソナ:

* 本社アドミニストレーター:トップレベルの運用、承認、および主要アカウントを管理します。
* 地域本社マネージャー:病院または臨床支店を監督し、地元の患者または臨床アカウントを監督します。
* 病院または診療所のスタッフ:日々の患者ケア、予約、医療サービスの提供を処理します。
* 独立したプロバイダーまたは研究パートナー (外部ユーザー):患者とのやり取り、臨床研究、または研究プログラムを管理します。
* 患者または臨床参加者:個々の患者、世帯、または医療アカウントのいずれかを表します。
{#smf-data-model-example__ul_y2k_ytx_1hc}  
前提条件:

* 組織のビジネス階層 (本社、地域本社、病院または診療所、独立したプロバイダー) は、SMF で事業所として定義されます。
* 内部ユーザーと外部ユーザーは、適切なペルソナ (アドミニストレーター、臨床医、研究者、関係マネージャーなど) とともにそれぞれの場所にアサインされます。
* 患者と医療アカウントはシステムに登録され、担当従業員にリンクされます。
{#smf-data-model-example__ul_z2k_ytx_1hc}  
図 : 2. ヘルスケアとライフサイエンスでの事業所とアクセス階層 解決ワークフロー/ソリューション実装:

1. 事業所階層の定義
   * 組織は、事業所の構造化された階層を確立します。
     * 本社:親組織
     * 地域本社:複数の病院または診療所を監督します
     * 病院または診療所:患者および臨床アカウントの管理
     * 独立したプロバイダーまたは研究場所:患者または研究アカウントを管理する外部エンティティ
     {#smf-data-model-example__ul_efk_ytx_1hc}
   * 各場所タイプは、所有権とアクセスレベルに基づいて内部または外部のいずれかとして定義されます。
   {#smf-data-model-example__ul_dfk_ytx_1hc}
2. 場所にスタッフをアサイン
   * 本社と病院または診療所には、内部ユーザーが配置されています。
   * 独立したプロバイダーまたは研究拠点には、パートナーシップ契約に基づいて運営されている外部ユーザーが含まれます。
   * 各スタッフメンバーは事業所にマッピングされ、ロール (アドミニストレーター、臨床医、研究者、関係マネージャーなど) がアサインされます。
   {#smf-data-model-example__ul_ffk_ytx_1hc}
3. 患者とアカウントの関係性の確立
   * 患者またはアカウント (個人、世帯、臨床研究) は、特定の従業員にリンクされます。
   * 各従業員には定義された責任があります。
     * 本社の従業員は、大規模なヘルスケアアカウントのアカウントマネージャーです。
     * 病院の臨床医は患者アカウントを担当します。
     * 独立したプロバイダーまたは研究者が、臨床参加者または研究参加者を管理します。
     {#smf-data-model-example__ul_hfk_ytx_1hc}
   {#smf-data-model-example__ul_gfk_ytx_1hc}各従業員はそれぞれの患者またはアカウントにリンクされるため、所有権の競合がなくなり、説明責任が明確になります。
4. アクセス制御とデータの可視化を決定するSMF は、ペルソナと事業所に基づいてアクセスルールを自動的に適用します。

   * 患者データ、臨床研究、アカウントなどのレコードへのアクセスは、以下に基づいています。
     * 従業員にアサインされた事業所。
     * リレーションシップロール (臨床医、研究者、アカウントマネージャーなど)。
     * SMF で定義された階層。
     {#smf-data-model-example__ul_jfk_ytx_1hc}
   * たとえば、次のようになります：
     * 本社の従業員 2 は、企業患者アカウント 1 にアクセスできます。
     * クリニック支店 1 の臨床医従業員 1 は、クリニック患者アカウント 2 にアクセスできます。
     * 研究パートナーの従業員 1 は、臨床試験の参加者を表示および管理できます。
     {#smf-data-model-example__ul_kfk_ytx_1hc}
   {#smf-data-model-example__ul_ifk_ytx_1hc}
5. 場所の関係性の管理
   * 本社のスタッフは、独立したプロバイダーまたは研究場所の監督を維持する場所関係マネージャーとして機能する場合があります。
   * 類似性、本社の従業員 2 は、複数の外部研究場所の活動をレビューできます。
   {#smf-data-model-example__ul_lfk_ytx_1hc}これにより、外部パートナーの活動が会社の標準およびコンプライアンスポリシーに準拠していることが確認されます。
{#smf-data-model-example__ol_cfk_ytx_1hc}

結果:

サービスモデル基盤データモデルを適用することで、HealthCorp Ltd は複数の医療機関にまたがるアクセスの不整合とアカウント所有権の競合を解決しました。このフレームワークは、大規模な HCLS 環境で患者と臨床アカウントを管理するための、統一された、安全かつ透過的なアプローチを提供しました。

## ユースケース:での市民世帯、行政サービス、およびスタッフの管理 公共機関デジタルサービス {#smf-data-model-example__section_nhk_vby_1hc}

このユースケースでは、公共部門の組織が、州本部、地域センター、地方事務所など複数の内部事業所にわたって養育費やその他の福祉プログラムなどのデジタルサービスの提供を管理する方法を示します。

各センターには、割り当てられた市民世帯を担当するスタッフがおり、 サービスモデル基盤 データモデルを通じて正確なデータ、ロールベースのアクセス、効率的なサービス提供を確認します。

問題のシナリオ: 社会福祉省 (DSS) は、センターと世帯のネットワーク全体の関係とアクセス制御を管理するという課題に直面しました。  
観察された課題:

* センター間でレコードを複製します。
* 他のセンターのケースへの不正アクセス。
* 世帯の所有権が不明瞭。
* スタッフまたは場所を再アサインする際のメンテナンスの問題。
{#smf-data-model-example__ul_bfm_chy_1hc}これらの課題は、データの不整合、コンプライアンスリスク、サービスの非効率性につながりました。  
関連ペルソナ:

* 州本部のスタッフ: 州全体のプログラムとコンプライアンスを監督します。
* センターの従業員:地域の世帯ケースを管理します。
* 関係マネージャー:アサインされた世帯の主要連絡先。
* 市民:世帯主や認可済み担当者を含む世帯員。
{#smf-data-model-example__ul_wdm_chy_1hc}  
図 : 3. ヘルスケアとライフサイエンスでの事業所とアクセス階層 解決ワークフロー/ソリューション実装:

1. 事業所階層の定義
   * 組織は、州本社、→センター、世帯などの事業所の構造化された階層→確立します。
   * 各場所は内部として定義され、定義されたサービスデリバリーの責任に関連付けられています。
   {#smf-data-model-example__ul_r1m_chy_1hc}
2. 場所にスタッフをアサイン
   * 本社の従業員 (HQE1 および HQE2):州全体のアカウントを管理し、地域の活動を監視します。
   * センタースタッフ(C1E1、C1E2など):特定の世帯とそのサービスを管理します。
   {#smf-data-model-example__ul_t1m_chy_1hc}
3. 世帯とケースの関係の確立
   * 世帯 (Parker Household や Collins Household など) は、ケースを管理する従業員にリンクされます。
   * 各世帯には、世帯主や認可済み担当者など、定義されたロールを持つメンバーが含まれます。
   * 従業員は、割り当てられた世帯の関係マネージャーとして機能します。
   {#smf-data-model-example__ul_u1m_chy_1hc}
4. アクセス制御の決定SMF は、場所、ロール、および関係に基づいてアクセスルールを自動的に適用します。

   * センターの従業員には、自分に割り当てられた世帯のみが表示されます。
   * 本社の従業員は、ローカルレコードを変更することなく監督を維持します。
   * 許可された世帯メンバーは、世帯内の他のメンバーを代表することができます。
   {#smf-data-model-example__ul_w1m_chy_1hc}
5. 場所間の関係性の管理
   * 本社のスタッフは、コンプライアンスについてセンター全体の世帯データを確認できます。
   * 世帯が複数のサービスエリアにまたがる場合 (共有メンバーや里親のシナリオなど) は、センターのスタッフが連携します。
   {#smf-data-model-example__ul_z1m_chy_1hc}
{#smf-data-model-example__ol_q1m_chy_1hc}

結果:  
サービスモデル基盤データモデルを実装することで、DSSは次のことを達成しました。

* センター間で世帯の所有権と説明責任を明確にします。
* スタッフのロールとビジネス階層に合わせた一貫したアクセス制御。
* データの精度が向上し、レコードの重複が減少しました。
* 運用の簡素化とデータガバナンスポリシーへのコンプライアンス。

{#smf-data-model-example__ul_h34_mky_1hc} このフレームワークにより、 公共機関デジタルサービス デリバリーのための統一された透明性のある安全な管理アプローチが可能になりました。