ヘッダーをスキップ
Oracle® Communications Data Modelリファレンス
リリース11.3.1
B70210-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

B Oracle Communications Data Modelビジネス・ユース・ケース

この付録では、Oracle Communications Data Modelビジネス・ユース・ケース・シナリオの概要および例を示します。

この付録は次の項で構成されています:

サンプル・ユース・ケース: 概要

Oracle Communications Data Modelのサンプル・ビジネス・ユース・ケースの内容は次のとおりです。

SuperTelco通信組織は、2つの事業単位で構成されています。

特徴的な商品は次のとおりです。

見込み客(後の顧客)は、Tom Danielsとその家族(Mary Danielsと子供たち)および何人かの友人です。

サンプル・ユース・ケース1: 事業単位組織の設定

このビジネス・ユース・ケースでは、データ・モデルに組織SuperTelcoをPARTYとして作成する方法について説明します。特に、図B-2に示すように、2つの主な事業単位(SuperTelcoのモバイルとSuperDataのブロードバンド)がOracle Communications Data Modelの対応するサブジェクト・エリアにモデル化されます。

図B-1 サンプル・ユース・ケースの組織事業単位

図B-1の説明が続きます
「図B-1 サンプル・ユース・ケースの組織事業単位」の説明

Oracle Communications Data Modelでは、モバイルおよびブロードバンド事業単位について次の管理機能を取得する必要があります。

サンプル・ユース・ケースを使用して作業するには、Oracle Communications Data Modelで組織SuperTelcoをPARTYとして構築します。

  1. ORGANIZATION BUSINESS UNITの情報を保存するには、次の2通りの方法があります。

    • 標準の事前定義済の階層の使用

    • 柔軟性のある階層の使用

  2. 図B-2に示すように、事業単位は、対応する表に格納される単純な階層に従います。

    • ORGANIZATION BUSINESS UNIT: 組織の最も小さな独立した部門で、CALL CENTERに格納されるコール・センター、Service Web Siteに格納されるWebサイト、RETAIL STOREの小売店など、複数の販売チャネルまたは顧客(あるいはその両方)との接点が含まれます。ORGANIZATION BUSINESS UNIT TYPEで詳述したように、事業単位は特定のタイプに属します。事業所の住所や会社の登記番号など、事業単位に関するすべての情報がORGANIZATION BUSINESS UNITに格納されます。これは、PARTYのサブタイプです。

    • この事業単位は地理的に(およびなんらかの形で管理的に)、地区、地域およびエリア内に位置します。地理エンティティは、ORGANIZATION DISTRICT、ORGANIZATION REGIONおよびORGANIZATION AREAの各エンティティで指定され、保存されます。

    • 組織領域の上位にある組織チェーンの概念を理解するには、たとえば、SuperTelcoの小売店がスーパーマーケット・チェーンの内部に存在することを考えます。SuperTelcoは、ORGANIZATION CHAIN表に格納されるこのスーパーマーケット・チェーンに関連する組織の一部になることができます。

    • ORGANIZATION CHAINは会社に所属します。この例では、会社SuperTelcoは、ORGANIZATION COMPANY表に格納され、それ自体はORGANIZATION CORPORATEにその情報が格納されるグループのメンバーです。

    • 特定の販売チャネルでバナーを使用する場合は、ORGANIZATION BANNER表にバナーを保存し、事業単位を企業レベルにリンクします。

  3. 図B-1に示すように、事業単位は、いわゆる柔軟性のある組織階層の対応する表に格納される適切で変更可能な1つ以上の階層の一部になることもできます。

単純な階層と柔軟な階層の2つの選択肢のうち、SuperTelcoサンプル・ユース・ケースでは柔軟な階層を使用します。これは、SuperTelcoの成長履歴が階層の経時変化を示しているため、この例の優先される階層です。ただし、地方に配置されたSuperTelco小売店の地理的な組織に対処するには、標準階層を使用できます。この階層は、全国的なマーケティング・キャンペーンの影響についてローカルおよび地理的な相違の詳細分析をサポートします。

サンプル・ユース・ケース2: 新規顧客の獲得(ファミリ・プラン)

サンプル・ユース・ケースとして、父親(Tom Daniels)がSuperTelcoディーラーに行き、次の機能を備えたファミリ・プラン商品を注文するとします。

父親は競合他社からサービスを移転し、現在の携帯電話の番号を維持します(ナンバー・ポータビリティが必要)。この例では、契約、アカウント、顧客およびパーティの様々なエンティティに格納される情報の詳細を提供します。図B-2に示すように、この領域には次のアクションが含まれます。

図B-2 顧客の獲得: ファミリ・プラン・モデル

図B-2の説明が続きます
「図B-2 顧客の獲得: ファミリ・プラン・モデル」の説明

新しい顧客とファミリ・プラン・データ:

  1. ORGANIZATION BUSINESS UNITの情報は、「サンプル・ユース・ケース1: 事業単位組織の設定」で説明しているように、以前に設定されたとおりです。

  2. 新しく取得された顧客情報は、CRMまたは課金システム(あるいはその両方)に格納されます。この情報は、カスタムETLを使用するOracle Communications Data Modelに入力されます。CUSTOMERの1つのレコードが、個人のタイプの名前(この場合はTom Daniels)付きで挿入されます。通常、顧客は、複数の番号を購入する際に追加のユーザー情報を提供する必要はありません。この情報が提供された場合、PARTYエンティティに情報を保存できます(この情報をデータソースで使用できるようにする場合、PARTY ASSIGNMENT表を使用してTom Danielとのリレーションシップを記述する必要があります)。

  3. 職業、年齢、教育などの顧客に関する情報は、関連するCUSTOMER表、SOC JOB (個人顧客の職業に関する標準職業分類システム)などの参照検索表に保存します。誕生日などの機密情報は、データベースで個別に隠蔽および暗号化できるCUSTOMER RESTRICTED INFOという特別な表に保存します。

  4. Tom DanielsとSuperTelcoの契約は、CONTRACT表で設定されます。顧客には、アカウントを(通常は一意のログインまたは一意の識別子により)定義するサービス・プロバイダとの契約があります。たとえば、このサンプル契約は、特殊パッケージPKG_Mobile_300に基づきます。個人(B2C)または企業(B2B)の任意のタイプの消費者が利用できる製品パッケージは、PRODUCT MARKET PLANエンティティに保存されます。

  5. 1つの顧客アカウントがACCOUNTエンティティに挿入され、その顧客キーは新規顧客インスタンスを指しています。アカウントは、顧客の財務状態です。通常、1人の顧客に1つのアカウントのみが存在しますが(購入するサブスクリプションの数とは無関係)、1人の顧客が複数のアカウントを持つことも許可されます(請求状態を再現する場合や特定の事例の場合に一般的)。

  6. 顧客のTom Danielsは、4つの異なるハンドセットを選択しています(EQUIPMENT表に保存されていますが、図B-2の図には表示されていません)。

  7. 4つの携帯電話番号がACCESS METHOD表および関連するハンドセットに保存されます。各電話番号では、現在の日付が発効日として使用され、アカウントIDがアカウントを指しています(アカウントIDは設定済)。

  8. 顧客が注文した携帯電話番号、製品パッケージおよびその他のすべてのアイテム(ナンバー・ポータビリティ要求を含む)を伴った顧客注文が生成され、CUSTOMER ORDERエンティティに保存されます。

  9. 注文により、ナンバー・ポータビリティ要求がトリガーされ、ナンバー・ポータビリティ・イベントがNP REQUEST HEADER表に保存されます。ナンバー・ポータビリティ要求のため、顧客注文の処理がいくらか遅延する可能性があります。旧ネットワーク・プロバイダは、SuperTelcoのナンバー・ポータビリティ要求に積極的に対応する必要があります。この場合、Tom DanielsのIMSIのみ、またはTom Danielsに関連するすべてのIMSIが契約日(今日)以降にアクティブ化されます。この場合、仲介またはプロビジョニング・システムへの追加のカスタムETLが1つ以上必要になる場合があることに注意してください。

  10. SUBSCRIPTION表に4つのサブスクリプションが挿入されます。ネットワーク・イベントであるコールとは対照的に、サブスクリプションは非ネットワーク・イベントとしてみなされます。各サブスクリプションでは、製品、顧客、アカウントおよびACCESS METHOD (携帯電話番号)がそれぞれ1つずつ関連付けられます。

  11. 顧客の注文は、ステータスの変更ごとに、またはBSS/OSSシステムで完了および満足されたときに1回のみ、抽出、変換およびロード・スクリプト(ETL)を通じてOracle Communications Data Modelにロードされます。

  12. 満足された(クローズされた)顧客の注文は、顧客セグメンテーション、市場シェアおよび収益OLAPキューブに関連するデータ・マイニング表に自動的に影響します(たとえば、ナンバー・ポータビリティ要求により、競合他社は1人の顧客を失い、SuperTelcoは特定セグメントで1人の顧客を獲得します)。

  13. 純粋なプリペイド・ケースでは、請求書は作成されません。ただし、いずれかのプリペイド・サービス・タイプのバウチャーの購入は、Oracle Communications Data Modelのアカウントに取得されます(有料TV、音楽ダウンロード、ハンドセットのプリペイド・カードなど)。元のプリペイド割引またはチャージは記録され、後払いの場合と同様にアカウントが作成されます。

サンプル・ユース・ケース3: サービス実装

Tomがファミリ・プランを購入し、支払いを行い、顧客の注文が生成された後、プロビジョニング・エンジンが引き継ぎます。

サービス実装は、図B-3に示すように、Oracle Communications Data Modelに格納されます。

図B-3 サービス実装

図B-3の説明が続きます
「図B-3 サービス実装」の説明

サービス実装では、プロビジョニング・エンジンが次の処理を行います。

  1. それぞれの「顧客の注文」が複数の「サービスの注文」に分解され、全体のシステムを編成するためにプロビジョニング・エンジンによって使用されます。通常、それぞれの「サービスの注文」は、特定の「ネットワーク要素」または「ネットワーク要素」のグループに対応します。たとえば、プリペイドGSM電話の顧客の注文は、請求およびCRMシステム、Intelligent Networkシステムなどでのアカウント設定を含む複数の「サービスの注文」で実行できます。

  2. 「サービスの注文」が実行されると、新しいサービスが生成される場合があります。サービスは、サブスクリプションの内部表現である顧客対応サービスの可能性があります。ビジネス・ユーザーは、ビジネスの使用状況を追跡するために「サブスクリプション」として各顧客の各製品を認識し、テクニカル・ユーザーは、(ネットワークから)「リソース対応サービス」として「ネットワーク要素」(電話番号などの論理的な「ネットワーク要素」を含む)の顧客のアクティベーション(および使用状況)を認識します。これらの概念は、TeleManagement Forumで定義されています。

  3. 「ネットワーク要素」で障害が発生した場合、テクニカル・サポートは、「ネットワーク要素」と「サービス」および「サブスクリプション」の関係に従って影響を受ける可能性がある顧客またはアカウントを簡単に追跡できます。

  4. ビジネス対話のサブタイプとして、CUSTOMER FIELD SERVICE ACTIVITY表(図には非表示)には、この注文の顧客サイトまたはネットワーク・サイトでの直接対話がすべて格納されます。

サンプル・ユース・ケース4: 顧客のコール・データの格納

Tom Danielsが電話を取得し、妻と子供の電話がアクティブ化された後、Tom Danielsは家族および友人に定期的に電話をかけます。Tom Danielsは主に、音声電話およびSMSメッセージの送信に電話を使用します。彼は、データまたはMMSサービスをほとんど使用しません。

顧客のコール情報は、図B-4に示すように、Oracle Communications Data Modelに格納されます。

図B-4 顧客のコール・モデル

図B-4の説明が続きます
「図B-4 顧客のコール・モデル」の説明

コール・データは、Oracle Communications Data Modelに保存できます。

  1. 「サンプル・ユース・ケース2: 新規顧客の獲得(ファミリ・プラン)」で説明したように、CUSTOMER、PRODUCTおよびACCESS METHODが設定されています。

  2. 顧客が通話するたびに、ネットワークのスイッチ・レベルでコール詳細レコード(CDR)が生成され(RAW CDR)、次にそれは調整によって収集され(調整済CDR)、評価エンジンや請求エンジンに転送されます(評価済CDR)。この最後のCDRは(ワイヤレスの事例の場合)、Oracle Communications Data ModelのWIRELESS CALL EVENT表に保存されます(これはNETWORK EVENT表のサブエンティティです)。NETWORK EVENTは、あらゆるネットワーク・イベント(コールおよびすべてのタイプのサービス使用)の最小限の共通事項を定義する抽象エンティティです。

  3. CALL CATEGORYは、データまたは音声電話など、コール・タイプを追跡します。

  4. ROAMING TYPEは、別の事業者からのローミング・コールか、別の事業者へのローミング・コールかどうかを追跡します。

  5. MEDIATED CALL EVENT表には、(請求エンジンに入力する前の)調整システムからのCDRが保存されます。

  6. NETWORK EVENT表には、コールの日時および持続時間などの詳細が保存されます。

注意: コール詳細レコード(CDR)ソースの取得場所に応じて、CDRには次の料金が含まれる場合があります。

分析のタイプに応じて、収益の確認では、通常、少なくとも調整済CDR (課金システムの前)と評価済または(請求からの)請求済CDRの両方をチェックすることをお薦めします。RAW CDR (ネットワークからの直接入力)は、通常、処理するには複雑ですが(バイナリ・タイプのデータ、CDRの数における潜在的要因100個、および追加のシグナリング情報)、ネットワーク運用や収益の確認の観点からすると非常に有用です。

サンプル・ユース・ケース5: 顧客請求

各請求サイクル期間の終了時(通常は特定の請求サイクルの月の特定日)に、SuperTelcoは、顧客の通話レコードに対して請求処理を実行し、請求書を生成します。この例では、Tom Danielsはすべての電話番号について$100の請求書を受け取ります(通常は後払いのみですが、子供たちのプリペイド電話に毎月デフォルトでチャージ金額を支払うことに合意していることも考えられます)。Tom Danielsは1か月以内にSuperTelcoに支払いを行う必要があり、そうしない場合、サービスが一時停止される可能性があります。

図B-5に示すように、Oracle Communications Data Modelに顧客の課金、請求書および支払いに関する情報が格納されます。

図B-5 請求および支払いデータ・モデル

図B-5の説明が続きます
「図B-5 請求および支払いデータ・モデル」の説明

Oracle Communications Data Modelの課金データ:

  1. 「サンプル・ユース・ケース4: 顧客のコール・データの格納」の項で、コール・データ・レコードのデータ収集について説明しています。

  2. Oracle Communications Data Modelでは、PRODUCT RATING PLAN、PRODUCT RATING PLAN DETAILおよびPRODUCT CHARGE TYPEなどのPRODUCTサブエンティティを使用して、製品の課金情報の詳細を格納します。

  3. 各ACCOUNTは、単独で請求されます。顧客が複数の契約を所有する場合は、同じ月に複数のINVOICEが生成されます。

  4. 契約は、同じアカウントに関連付けられた他の契約とは異なる請求期間を持つことができます。請求期間は、毎月、隔週などのように指定できます。

  5. 課金および請求書の処理が課金システムで発生した後、特定の請求期間(通常は1か月)の請求書に関するすべての情報がINVOICE、INVOICE ITEMおよびINVOICE ITEM DETAIL表に保存されます。顧客の請求書の支払い期間は、各請求書に関連付けられたINVOICE PAYMENT TERM TYPEに保存されます(たとえば、1か月または90日)。期間は、契約を締結する際に確定します。

  6. 請求書に割引または調整が適用される場合、その情報は対応する表(INVOICE DISCOUNTまたはINVOICE ADJUSTMENT)に格納されます。EMPLOYEEは、INVOICE ADJUSTMENT QUOTAによって制限される金額まで請求書に調整を加えることができます。

  7. Tom Danielsに対する請求書配送自体は、非ネットワーク・イベントとしてEVENT INVOICE DELIVERYに格納されます。

  8. 契約の締結時に選択された支払い方法はACCOUNT PREFERRED PAYMENT METHODに格納され、この支払い方法は、支払いトランザクションのデフォルトになります。

  9. Tom Danielsが、たとえば銀行振込みなどを使用して請求書を支払うと、その支払いはACCOUNT PAYMENTに保存され、対応する未決済請求書に割り当てられます。ACCOUNT PAYMENTは、INVOICE PAYMENT ASSIGNMENTに格納されます。

  10. INVOICEの金額と支払額の差額は、負債に加算されます(負債は図B-5に示されていません)。

注意: 収益保証サブエリアおよびそれに対応するレポートでは、請求明細をOracle Communications Data Modelに格納することが重要です。これにより、使用アイテム(詳細コール・リスト)を1つずつ評価済CDRと比較し、この方法を使用して、評価済CDRと請求済CDRの違いを確認できます。

「サンプル・ユース・ケース8: ビデオ・オン・デマンド・サービスのターゲットを絞ったプロモーション」の項では、見込み客の選択を伴ったキャンペーン設定を示しています。このキャンペーンでは、プロモーションの送信から顧客のコール・バックまでの時間(時間数または日数)を要素として、プロモーションに基づいてコール・センターに連絡し、商品の変更を要求したサブスクライバ数を分析することでキャンペーンの成功を測定できます。

サンプル・ユース・ケース6: プランおよび請求先住所の変更

SuperTelcoは、ブロードバンド・サービスとモバイル・サービスを一本化したパッケージのプロモーション・キャンペーンを立ち上げます。Tom Danielsは、SMSキャンペーンを通じて配信されたプロモーション・メッセージを読み、プロモーションを利用しようと決断しました。彼はコール・センターに電話をかけ、ブロードバンド・サービスと一本化された新しいファミリ・プランへの商品パッケージの変更を依頼します。その後、SuperTelco Webセルフサービス・インタフェースを使用して、請求先住所を変更しました。

SuperTelcoでは、Oracle Communications Data Modelを使用して、図B-6および対応する手順に示すように、顧客の対話を保存します。

図B-6 プランおよび請求先住所の変更データ・モデル

図B-6の説明が続きます
「図B-6 プランおよび請求先住所の変更データ・モデル」の説明

  1. 「サンプル・ユース・ケース1: 事業単位組織の設定」の項で、コール・センターについて説明しています。

    コール・センター・エージェント(CALL CENTER AGENTに格納)と、チームおよび部門(CALL CENTER表に格納)は、Oracle Communications Data Modelで一意に識別されます。コール・センター・エージェントは、SuperTelcoの従業員(EMPLOYEEに格納)またはSuperTelcoのコール・センターを経営するパートナ会社の従業員です。この例では、CALL CENTER AGENTは、EMPLOYEEのサブタイプです。すべてのINTERACTION CHANNEL (CALL CENTER、Webまたはオンライン・ビジネス・システム、店舗内のカウンターなど)を構成して、いつでも顧客との対話をトレースできるようにしておく必要があります。

  2. コール・センターの対話情報の詳細は、非ネットワーク・イベントとして保存されます。Tom Danielsがコール・センターへの連絡に使用する方法に応じて、INTERACTION TYPEの対応するコードがイベントとともに保存されます。

  3. 顧客が契約の変更を確定すると、CRMおよび課金システムで商品変更処理が発生します。この処理ではACCOUNTの2つのSUBSCRIPTIONイベントがトリガーされます(一本化された商品が分割できない完全なパッケージである場合)。Oracle Communications Data Modelに保存されるイベントは次のとおりです。

    サービス・プロバイダが定義したこの商品の取引処理の一部としてCONTRACTの変更が必要な場合は、次を実行します。

    • 取消し理由を指定して古い契約をクローズします(CONTRACT STATUS REASON検索表で取消し理由を検索)。

    • 対応するCONTRACT TERM VALUEを指定して新しい契約を作成します。

    • CONTRACTを置換する必要がなく、新商品で同じ契約を使用する場合は、特定の割当てコードを使用してCONTRACT PRODUCT ASSIGNMENT表の既存契約の商品割当てを変更します。

    商品の変更は、次の自動でのデータ移動(およびそれに対応するレポート)で、他の複数の表に影響を与えます。

    • 料金およびパッケージの変更に関連する個別のレコードを取得するCANNIBALIZATION DETAIL MONTH AGGR表。この表は、クロスセルおよびアップセル・マイニング・モデルに挿入されます。

    • CHURN PREDICT SOURCE DERIVEDのチャーン予測ソース。契約または商品が変更され、この変更はチャーンの可能性に影響を与えます。

    • 顧客生涯価値に関連する表も更新されます。契約または商品が変更され、この変更はチャーンの可能性に影響を与えます。

    • この顧客の収益予測OLAPキューブも変更されます。

商品の料金の詳細は、PRODUCT RATING PLANおよびPRODUCT RATING PLAN DETAILなど、様々なPRODUCTサブエンティティに保存されます。

注意: Oracle Communications Data Modelでは、どのイベントも金銭的な観点では評価されません("shadow billing"などはありません)。ただし、この目的でOracle Communications Data Modelをカスタマイズすることは可能です。

CUSTOMERエンティティおよびBilling Address Location Code属性を使用して、顧客表に顧客の請求先住所が保存されます。この属性は、実際の住所エンティティADDRESS LOCATIONにリンクします。請求先住所のタイプは、新しい住所のADDRESS TYPEのいずれかの値です。たとえば、Tom DanielsがSuperTelco Webセルフサービス・インタフェースを使用して請求先住所を変更すると、ETLにより(CRMまたはWebインタフェースから)変更内容が取得され、非ネットワーク・イベントとしてOracle Communications Data Modelに保存されます(ソースWebインタフェースは、Webベースのカスタマ・セルフケア・システムで、通常はサービスを得るためのログイン先です)。

Tom Danielsが新しい住所を提供した場合、2つの住所はADDRESS RELATEDエンティティによりリンクされます。複数の住所がある場合、ADDRESS RELATEDエンティティおよびCUSTOMERエンティティでの変更が必要です。

さらに、PARTY STATUS HISTORYが更新される可能性があります(サービス・プロバイダで必要な情報により異なります)。

サンプル・ユース・ケース7: ビデオ・オン・デマンド・サービスのターゲットを絞ったプロモーション

SuperTelcoでは、ビデオ・オン・デマンド・サービスを購入する可能性が最も高い顧客を特定するために現在の顧客ベースを分析します。また、マーケティング部門では、ロイヤルティ・プログラムの顧客数を増加しようと考えています(これにより、チャーンを抑制できます)。SuperTelcoマーケティングのビジネス・アナリストは、ターゲット・プロモーション用のデータ・マイニング・ツールを使用して、このサービスに関心を持つ可能性のある顧客のうち、現在ロイヤルティ・プログラムのメンバーでない顧客のリストを作成します(スーパーバイズド・マイニング)。

プロモーションのテストのため、対象となる顧客リストのサンプルが選択されます。顧客のTom Danielsは、対象となる顧客リストに含まれています。SuperTelcoは、対象の顧客に電子メールを送信します。SuperTelcoでは、顧客からフィードバックを得るために、ビデオ・オン・デマンド・サービスと1本の無料DVDの取得に際してテスト・プロモーションの顧客にコール・センターに連絡させることに決定しました。

Tom Danielsはサービスの購入を決定し、新プロモーションを得るためにCALL CENTERに電話をかけます。内容は次のとおりです。

「サンプル・ユース・ケース6: プランおよび請求先住所の変更」の項で、商品の変更による影響について説明します。

ビジネス・アナリストは、キャンペーンの準備、潜在顧客の選択およびキャンペーンの成功の測定のために次のことを行います。

  1. マーケティング・マネージャは、ロイヤルティ・プログラムのメンバーである顧客数を調べます。ロイヤルティ・プログラムのメンバーシップは、チャーンを削減し、顧客の優先傾向に関するSuperTelcoの知識を向上させる要因になります。ロイヤルティ・プログラムの顧客数を増加するため、マーケティング・マネージャは、既存顧客と連絡を取って新しいビデオ・オン・デマンド商品を提案し、ロイヤルティ・プログラム・メンバーシップに商品をバインドする決定をします。顧客がビデオ・オン・デマンド・プロモーションを利用するかどうかを問わず、ロイヤルティ・プログラムのメンバーシップを顧客に提案します。したがって、このプロモーションには、次の2つのプロモーションが含まれます。

    1. サービスの提案: ビデオ・オン・デマンド

    2. ロイヤルティ・プログラム・メンバーシップ

  2. ビデオ・オン・デマンド製品の設定は、PRODUCT表およびPRODUCT MARKET PLAN表に指定します。各プロモーションの目的およびサマリー情報は、PROMOTION表に指定します。一部のPROMOTIONは、単一の戦略目的となります(CAMPAIGNがプロモーションの目的を追跡します)。

  3. このキャンペーンのビジネス・アナリストの要件は次のとおりです。

    1. ビデオ・オン・デマンドの見込み客にはアクティブなブロードバンド・サービスが必要です。

    2. ロイヤルティ・プログラムの見込み客は、現在ロイヤルティ・プログラムに加入していない顧客でなければなりません。

    3. 見込み客は個人に限定されます。

    4. 見込み客はキャンペーンに参加していないこと、および最近(この3か月以内)、プロモーション商品のための連絡を受けていないことが必要です。

    5. 見込み客の収益は、中間層以上でなければなりません。

    6. 見込み客の支払いは、分割払いで、負債エイジングが0またはほとんど0である必要があり、支払い不良により過去にサービスが中断されたことのない顧客でなければなりません。

    7. 大規模なプロモーションの提案を行う前に、ビジネス・アナリストは、サンプルとして200人の顧客リストを選択してキャンペーンのテストを実施する必要があります。

  4. 情報を受け取るため、ビジネス・アナリストは、指定された基準を使用して見込み客リストを検索し、ターゲットを絞ったプロモーションのデータ・マイニングにスーパーバイズド方式を使用します。

  5. ビジネス・アナリストは、見込み客リストの連絡先を生成するには、次の2つの可能性があると判断します。

サンプル・ユース・ケースで、顧客Tom Danielsは、テスト用の顧客サンプル200人に含まれています。彼は、このキャンペーンの見込み客としてタグ付けされ、PROSPECT表に示されます。Tom Danielsは、一度に1つのキャンペーンでのみ見込み客になることができます。これはキャンペーンの反響を正しく測定するために厳密に必要です。Tom Danielsは個人であるため、PROSPECT INDIVIDUAL表に入力され、また、プロモーションの顧客との対話の際に一部のデータが収集される場合もあります。

CALL CENTERでのTom Danielsとの対話の後、PARTY INTERACTION THREADに指定されたように、INITIATIVE RESULT TYPE表、PARTY PROMOTION RESPONSE表、PROSPECT表およびProspect Result Codeフィールドが更新されます。

  1. Tom Danielsはプロモーションで指定されたサービスを購入し、Tom Danielsが選択したビデオは詳細分析のために記録されます(課金のため、およびTom Danielsの関心事に関する情報、最も成功したビデオのタイプおよび名前に関する情報を保存するため)。

  2. Tom Danielsは、LOYALTY PROGRAMエンティティに格納されたロイヤルティ・プログラムのメンバーシップを承諾し、これにより、ロイヤルティ・プログラムのメンバーが増加し、Tom Danielsの関心事に関する知識が高くなります。

対象となる顧客のすべての反応がPARTY PROMOTION RESPONSEに記録されます。肯定的な反応はキャンペーンのマイニング結果の一部として保存され、Tom Danielsと類似のセグメントにある個人顧客のスコア向上をもたらします。スコア表は、テストの域を超えて他の顧客にキャンペーンを拡大する際に、キャンペーンへの肯定応答の可能性を計算するために再利用されます。

注意: このイニシアチブは顧客電子メールによりトリガーされ、コール・センターでイニシアチブが完了しています。Tom DanielsのCALL CENTERへの電話は電子メールによりトリガーされたため、このターゲットを絞ったプロモーションの媒体は電子メールで、販売チャネルはCALL CENTERです。

新規のロイヤルティ・プログラム・メンバーシップおよび関連するボーナス・ポイント500点の結果、ロイヤルティ・タイプの非ネットワーク・イベントが作成されEVENT LOYALTY PROGRAM表に格納されます。Tom Danielsは、LOYALTY PROGRAM CHANNELエンティティで事前定義済のCALL CENTERからのLOYALTY PROGRAM表(LOYALTY PROGRAM MO AGGR)にも表示されます。PARTY STATUS HISTORYが変更され、CUSTOMERの一部のフィールドが更新されます(Initiative NumberおよびCustomer Balanceなど)。

サンプル・ユース・ケース9: 契約解除のリテンション

顧客としての期間が経過すると、Tom Danielsの契約およびプランは終了します。契約の終了前に、SuperTelcoは、社会人口学的データ、現在のサブスクリプション、(顧客セグメントとの比較に基づく)使用および収益パターンから、彼がチャーンする可能性が高いと判断します。

コール・センターは、新しい商品によるこの顧客の継続を提案します。

SuperTelcoでは、Oracle Communications Data Modelを使用して、図B-7および対応する手順に示すように、顧客の対話を保存します。

図B-7 契約解除のリテンション・モデル

図B-7の説明が続きます
「図B-7 契約解除のリテンション・モデル」の説明

契約の解除およびコール・センターのリテンションには、次のステップが含まれます。

  1. 契約の終わりに近づくと、Tom Danielsのチャーンの可能性は高くなります。彼はロイヤルティ・プログラムに所属する重要な顧客であるため、他のセグメントよりもチャーンの可能性は低くなります(PARTY LOYALTY PROGRAM PARTICIPATIONにより、Tom Danielsがロイヤルティ・プログラムに参加した際のAWARD LEVELに基づく)。

  2. 事業者は、Oracle Communications Data Modelマイニング・モデルを実行して最も可能性の高いチャーン顧客を特定できます。マイニング・モデルの結果は、CUSTOMER MINING表に保存されます。詳細は、「モデル1: チャーン予測」および「モデル3: 顧客のチャーン要因」を参照してください。

  3. 通常、契約の終了時期になると、次の2通りのアクションが可能です。

    • 何もしない: この場合、積極的に取消しをしないと、契約は自動更新されます(顧客チャーンがないと想定した場合)。これは、最新のより安価な商品を利用しない休眠中の顧客の一般的なケースです。

    • 顧客に積極的に連絡する: この場合、契約終了の通知を顧客に送る前に、顧客と連絡を取ります(これは顧客チャーンの可能性が高く、その顧客に投資する価値がある場合に実行します)。このアクションは、特に短期のチャーン条件に該当します。たとえば、顧客が競合他社から申込みを受ける可能性がある、契約終了の1か月前までに連絡を取るように指示されている場合です。契約が自動的に終了した場合、更新のためのサービス・プロバイダのアクションが必要です。

  4. Tom Danielsに連絡を取ると仮定した場合、SuperTelcoは、提案する内容について知る必要があります。このコンタクトには、次のような選択肢があります。

    • 変更せずに契約を更新: これは可能ですが、通常、数年後に競争によってこのオプションは魅力がないものになります。

    • 新しい商品の提供。

    • 顧客の契約が12か月を超える場合、新しいハードウェアと割引を付加して契約を更新。

      Tom Danielsのサンプル・ユース・ケースでは、HANDSET INSTANCE (EQUIPMENT INSTANCEのサブタイプ)の情報に指定された家族全員のハンドセットが古く、2年以上を経過しているので、新しいハンドセットを付加した契約更新は適切な商品提供となります。契約更新に新しいハードウェアを付加する場合、顧客が獲得したロイヤルティ・ポイントの一部の使用を許可します(異なる機器の選択)。また、ARPUバンドに従って、顧客をさらに12か月間バインドする場合は12%の割引を適用する価値があります。

      新しいハンドセットの提供によって、新しい機能が提供される場合があります。たとえば、アプリケーションのダウンロードによって、SuperTelcoに追加の収益が生じる可能性があります。子供の年齢から判断しても、この予測が正しいことがわかります。

  5. 処理の観点から、このユース・ケースは、「サンプル・ユース・ケース7: ビデオ・オン・デマンド・サービスのターゲットを絞ったプロモーション」に記載されたターゲットを絞ったプロモーションとエンティティおよび変更点が類似しています。顧客が新しい商品を承諾すると、新しいCONTRACTが設定されます。新しいCONTRACTに加えて、Tom Danielsはギフトを付与されます。この例では、新しい契約に、最新のハンドセットまたは1か月のデータ・サービス無料パスが含まれます。顧客によるギフトの選択は、EVENT GIFT REDEMPTIONで追跡されます。

  6. パーティの対話に加えて、無料のハンドセット情報を含む非ネットワーク・イベントがEVENT LOYALTY PROGRAM REDEMPTION表に保存されます。無料のハンドセットは、対応するマーケット・プラン(PRODUCT MARKET PLAN ASSIGNMENT表)から割り当てられるGIVE AWAY TYPE表で関連付けられます。ハンドセット自体はITEM表にあります。

  7. さらに、Tom Danielsが利用できるハンドセットの種類に関する情報を得るには、REDEMPTION MO AGGR表を使用します。

  8. Tom Danielsがロイヤルティ・プログラムのメンバーでない場合にも、類似した商品の提供が可能です。この場合、ハンドセットの提供のための対話はEVENT GIFT REDEMPTION表に保存されます。

サンプル・ユース・ケース10: ディーラーおよび従業員の販売手数料

このユース・ケースは、「サンプル・ユース・ケース2: 新規顧客の獲得(ファミリ・プラン)」の項に記載された顧客情報の詳細を拡張します。このユース・ケースでは、ディーラーの販売情報の保存方法について詳しく説明します。ユース・ケース2で、顧客のTom Danielsは次の内容のファミリ・プラン商品を注文していました。

対応期間中に、顧客は電話、ブロードバンド商品およびビデオ・オン・デマンド・サービスを得るためにコール・センターに電話をかけました。SuperTelcoが顧客収益、サービス数および顧客ロイヤルティに応じてディーラーに報酬を与えると仮定して、ディーラーおよび特定のキャンペーンの手数料および経費の支出について考えます。

ディーラーおよび従業員の売上げ手数料ユース・ケースには、次のアクションが含まれます。

SuperTelcoでは、Oracle Communications Data Modelを使用して、図B-8および対応する手順に示すように、ディーラーおよび顧客の対話を保存します。

図B-8 ディーラーおよび従業員の売上げ手数料モデル

図B-8の説明が続きます
「図B-8 ディーラーおよび従業員の売上げ手数料モデル」の説明

  1. 顧客およびアカウント設定の情報は、「サンプル・ユース・ケース2: 新規顧客の獲得(ファミリ・プラン)」に記載されています。

  2. 実装の際またはディーラーの初出時に、ディーラーはたとえば、John DealerというDEALER (PARTY表のサブタイプ)として入力されます。DEALERには、次の関連エンティティがあります。

    1. ADDRESS LOCATIONに格納され、DEALERに関連付けられた住所。

    2. SALES CHANNELおよびディーラーを識別するチャネル。SALES CHANNELは、社外のDEALERおよび社内の販売員をEMPLOYEEとして統合する抽象的な包括組織です。各従業員のJOB ROLEはEMPLOYEE JOB ROLE ASSIGNMENTにあります。たとえば、販売従業員の職種は「販売員」です。

    3. 組織構造または個人との関係(ORGANIZATION BUSINESS UNIT)。

    4. DEALER DISCOUNT GROUP ASSIGNMENT表内のDISCOUNT GROUPエンティティの割引グループ。プロバイダがディーラーに許可するすべての割引は、DEALER DISCOUNT GROUP ASSIGNMENTに定義されます(グループとして)。このエンティティはディーラー・コストおよび顧客コスト表への挿入を行います。

  3. 販売の従業員として、John Dealerは、SALES COMMISSION PLAN表の売上げ手数料プラン・コードに関連付けられます(JOB ROLEを使用)。プランの詳細SALES COMMISSION PLAN DETAILまたは手数料のタイプCOMMISSION TYPEは関連するエンティティに格納され、販売されたアイテム、機器、サービスおよび製品市場計画のすべての手数料および報酬が設定されます。EMPLOYEE JOB ROLE ASSIGNMENT。

  4. John DealerとTom Daniels間のパーティの対話により、新しいCUSTOMER ORDERが生成されます。顧客注文はBOSS/OSSシステムに生成され、Oracle Communications Data Modelにロードされます。顧客注文ごとにSALES COMMISSION DETAILがロードされ、その販売取引においてDEALERに与える手数料の金額が追跡されます。プロビジョニング・システムでCUSTOMER ORDERが満たされると、4件のアクティベーション、4個のハンドセット(ITEM)および(契約が1件のみであっても)5個の製品を伴った契約が設定されます(各モバイルにつき1個およびFriends and Familyの共有)。これにより、Oracle Communications Data Modelでは、次のような結果になります。

    1. John Dealerは、収益、顧客数およびサブスクリプション数の増加をもたらしました。収益は、これらのアイテム、収益、顧客数およびサブスクリプション数に対する月初での割当てと比較され、ディーラーの手数料および(可能な場合は)ボーナスが計算され、ディーラーの最終的なレポートの生成に使用されます。

    2. John Dealerが収益の一部を獲得すると、それに応じて彼の経費が増加します。

    3. Johnの店舗にあるハンドセット数が4個減少します(後払い2個、プリペイド2個)。在庫切れ予測マイニング・モデルに自動的に入力され、相応に更新されます。

    4. 手数料インジケータ属性(Commission Ind)を通じてハンドセットに関連付けられた手数料により、売上げアイテムに対する付加手数料の計算がトリガーされ、月次ベースで集計されます(COMMISSION DAY DRVDおよびSALES MONTH AGGRを使用)。

  5. SuperTelcoが顧客から生じた有効な収益について報酬を支払うと仮定した場合、顧客に関連付けられたアカウントのARPUバンドに応じて、Tom DanielのプロファイルでJohn Dealerの特別ボーナスが計算され、ディーラーおよび顧客の追加費用として加算されます。多くの場合、この段階で、ディーラーまたは顧客の詐欺を制限するために詐欺検出メカニズムが適用されます。

  6. Tom Danielsは、キャンペーンにより、パッケージを一本化された商品に変更したため、SuperTelcoはJohn Dealerに報酬を与えません。通常、キャンペーン・コストの増加は、SMSの作成費と送信費、およびコール・センター・エージェントの対話のコストにより生じます。顧客コストの増加は、コール・センター・エージェントの対話のコストのみです(Tom Danielsに送信されたSMSを考慮しない場合)。Tom Danielsがパッケージを変更したという事実は、ARPUバンドに影響を与える可能性があり、これによって、John Dealerのボーナスも変更される可能性があります。

  7. Tom Danielsの契約が終了すると、SuperTelcoでは、コール・センターのみに回収アクションの成功報酬を与え、顧客ロイヤルティに対するJohn Dealerへのボーナスは与えない可能性があります(顧客ロイヤルティは対策には含まれていないため)。それにもかかわらず、顧客Tom Danielsのコストは増加します。また、従業員およびコール・センターのコストも同様に増加します(ここでは、コール・センターのコストは労働、従業員、コストおよびその他のコストの合計として考慮する必要があるため、従業員コストのみが増加するものと考えます)。たとえば、建物の賃料またはコール・センター・サービスの料金は、通常、コール・センターの場所にのみ関連付けられます。当月の相対マージンが減少した場合でも、契約の更新から生じた収益により、総マージンは増加します。

  8. 月末に、営業員の手数料が給与で支払われると、SALES COMMISSION PAYROLLに情報が移入されます。

  9. 新規の顧客を獲得する際にディーラーが不正を行う場合もあります。たとえば、友人に契約を締結させてギフトを獲得した後、契約を解除する場合があります。不正なディーラーによる新規顧客の獲得は、SUBSCRIPTION STATISTIC DRVDにより特定できます。この導出表で統計的なファンクションが適用され、他のすべてのディーラーと比較して、高いチャーン率により不正を働いた可能性があるDEALERが見つかります。

サンプル・ユース・ケース11: ネットワーク障害の処理

ネットワーク監視システムは、スイッチで障害を検出します。SuperTelcoでは、障害の影響を受ける顧客数を知る必要があります。ネットワーク監視システムでは、ネットワーク・インベントリへの問合せによって、障害が発生した要素のリソースIDを取得します。その後、ネットワーク監視システムでネットワーク障害イベントが生成され、Oracle Communications Data Modelでこのイベントを取得します。

SuperTelcoでは、Oracle Communications Data Modelを使用して、図B-9および対応する手順に示すように、ネットワーク障害を処理します。

SuperTelcoでは、Oracle Communications Data Modelで指定された全ネットワーク構造を含め、ネットワーク・オペレーティング・アプリケーションおよびネットワーク・インベントリ・アプリケーションが1日に1回、Oracle Communications Data Modelに情報を提供します。

図B-9 ネットワーク障害の処理モデル

図B-9の説明が続きます
「図B-9 ネットワーク障害の処理モデル」の説明

状況を検討し、ネットワーク障害の処理に必要なステップについて考えます。

問題を特定した後のマネージャの最初の質問は次のとおりです。

  1. ある晩、午後8時にネットワーク・セルが落雷に打たれて停電に見舞われ、ネットワーク・セルの機能が停止して再開しません。リアルタイム・ネットワーク監視システムがSuperTelcoの集中メンテナンスに警告します。これにより、SuperTelcoでは、障害の場所をすぐに特定し(サイト、場所、故障前のデフォルト構成)、問題の調査のためにチームを派遣します。人口密集地であるにもかかわらず、停電は到達の困難なセルで発生し、メンテナンス・チームがネットワーク・セルを修理して再始動するのに4時間かかりました。

  2. ネットワークが停止している間、SuperTelcoの顧客は固定回線を通じてコール・センターに苦情の電話をかけます。一部の顧客は、問題が持続する場合はサービスを解約すると脅します。

  3. 現段階では、Oracle Communications Data Modelが果たす役割はありません。Oracle Communications Data Modelでは、このイベント、ステータスなどのサマリー情報を1日に1回取得すると仮定します(翌朝の午前2時)。Oracle Communications Data Modelをほぼリアルタイムで(たとえば毎時)更新するようにネットワーク制御アプリケーションのETLを構成した場合、Oracle Communications Data Modelは早期にイベントを認識できます。

  4. SuperTelcoのマネージャは、ネットワーク・アプリケーション・チームからリアルタイムでネットワーク障害の情報を取得します。

    • セルの場所はどこか。

    • 現在担当している権限を与えられたチームはどれか。

    • 影響を受けるサービスはどれか。

    • 影響を受ける顧客は誰か。

    • 対策を何も講じなかった場合、平均的な収益への影響はどれだけか。

  5. ネットワーク・アプリケーションは、セルの場所および担当チームを直接に回答できる必要があります。また、故障したセルのIDを入力すれば、(Oracle Communications Data Modelがセルの故障についてまだ認識していない場合でも)Oracle Communications Data Modelでこの情報を特定できます。NETWORK ELEMENT表とその副表への簡単なアドホック・クエリーにより、質問の回答を得ることができます。

    ネットワーク要素ID xxxは、どこにあるのか。

    質問に答えるには:

    メンテナンス・プランによると、担当者は誰か。

    Oracle Communications Data Modelでは、モデルのカスタマイズにより、この情報を提供できます(この情報は、追加設定なしでは取得できません)。ネットワーク障害が複数のNETWORK ELEMENTで発生した場合、障害のあるすべてのネットワーク要素がNETWORK ELEMENT FAULT ASSIGNMENTで追跡されます。

  6. 各ネットワーク障害の発生は、NETWORK FAULTに記録されます。顧客サイトでネットワーク障害が発生した場合、問題解決のためのテクニカル・サポート・アクティビティは、Oracle Communications Data Modelにロードされると、CUSTOMER FIELD SUPPORTに保存されます。CUSTOMER FIELD SUPPORTエンティティは、CUSTOMER FIELD SERVICE ACTIVITYのサブタイプです。

  7. ネットワーク障害が解決されると、FAULT RESOLUTION TYPEに従ってネットワーク障害の解決タイプがロードされます。

  8. 影響を受けるサービスのリストは、野外に設置された要素のリストに関連があります。サンプル・ユース・ケースでは、落雷により、アンテナ付近の地域内のすべてのワイヤレス・トラフィックが機能していないと考えます。この地域は密集地であるため、他のアンテナが地理的領域の一部をカバーしていることも予想できます。GSMネットワークでは、地理的領域は、対応するBASE STATION CONTROLLERによって処理される異なるCELLに分割されています。BASE STATION CONTROLLERは、NETWORK ELEMENTのサブタイプです。影響を受ける地域およびサービスを示す簡単なレポートに、セルに関連付けられたサービスのリストも表示されます。

  9. 影響を受ける顧客のリストは、ネットワーク障害とSUBSCRIPTION表をリンクするNETWORK FAULT SUBSCRIPTION ASSIGNMENTにより取得できます。SUBSCRIPTION表に含まれるCircuit Component Code属性により、CIRCUIT COMPONENT表を使用して関連のあるNETWORK TOUCHPOINTを取得できます(CELL SITEはNETWORK TOUCHPOINTの副表です)。したがって、故障したセルIDに結び付けられたサーキット・コンポーネントを持つすべてのサブスクリプションに対する簡単なクエリーによって、特定のセルに関連するすべての顧客情報のリストが得られます。

  10. 同様に、顧客ごとに、影響を受ける製品の正確なリストを簡単に得ることができます(機能していないサービスおよび関連サブスクリプションに関して)。

  11. マネージャは、影響を受ける製品のリストにより、金曜日の夜8時から12時までの間に通常実行されるコール数をチェックし、その時間帯にそれらの顧客がもたらす収益の平均を取得できます。これは、4時間の休止時間内の平均的な収益の損失を提供します。マネージャは、可能性のある顧客のリストをコール・センターに電子メールで送信して、この3～4時間以内にサービスの損失について顧客から苦情を受ける可能性があることをコール・センターに警告できます。

  12. 顧客がコール・センターに電話をかけると、対話タイプがComplainの対話イベントがEVENT PARTY INTERACTIONに作成されます。

  13. 電子メールと顧客リストにより、コール・センター・マネージャはコール・センターの従業員に警告し、可能な場合は追加の人員を要求して増加する可能性がある苦情電話に対処できます。ネットワーク問題に関連のあるセル障害に関するすべての顧客からのコール・センターへの電話を識別することが重要です。この識別は、コール・センター・エージェントがリアルタイムに直接実行するか、Oracle Communications Data Modelの分析により後で実行することもできます。注意: これにより、コール・センター・マネージャは、次回の月例会で顧客満足度レポートを見せる際に説明をあらかじめ準備できます。

  14. 不満がありチャーンの恐れがある最も重要な顧客には、カスタマ・ケアー・マネージャが補償プログラムの実行を決定する場合があります。たとえば、個人客の場合は、無料SMSを10個または翌月に10分間の無料通話時間を提供し、チャーンの恐れがある企業顧客には10%割引を提供します。

  15. 後で、これらの手続きが実行されなかった場合、翌月のチャーンの増加がネットワーク問題に即座に関連付けられます。特定領域での飛びぬけたチャーンの増加によって、デフォルト・レポートで警告が示されます(Oracle Business Intelligence Suite Enterprise Editionのアラート機能に関連付けられたデータベースの外れ値機能を使用)。

  16. したがって、Oracle Communications Data Modelに用意された様々な方法を使用して、同じ結果をもたらすことが可能です。このケースでは、次のとおりです。

    • ネットワーク・セルID (ほぼリアルタイム)。

    • 異常に限定的な苦情発生地の地理的分布(ほとんどは最初の2日以内)。

    • 限定的な地区での異常なチャーンの増加(1か月後)。

サンプル・ユース・ケース12: ビジネス・エリアの実装

CFOは、Oracle Communications Data Modelのすべての請求関連レポートの実装をSuperTelcoのITマネージャ(Susan)に要求します。

簡易化のため、次のことが前提となっています。

顧客および製品に関するDWHが存在するにもかかわらず、Susanは「グリーンフィールド」実装の計画を進めます。ただし、以前に行った作業の一部を再利用するため、Oracle Communications Data Modelのソースとして使用されているDWH表を直接に使用するか、ETLを使用してOracle Communications Data Modelの表に直接に移入しようと考えています。

第2フェーズで、CFOは、外交官である顧客、つまりVAT(付加価値税)を支払わない顧客に関する特殊なレポートを要求します。CFOは、特殊な顧客コードを作成して、その特殊コードの顧客のみに関するレポートを要求します。このため、Susanは、顧客表にTax Rate Amount列を追加し、新しい顧客タイプDiplomatを導入する必要があります。これらの変更は、CRM、顧客DWHおよび課金システムで並行して進める必要があります。

ITマネージャであるSusanは、これらのステップを実装するために次のことを行います。

  1. このプロジェクトは、一般的なDWHプロジェクトですが、1つの重要な例外があります。それは、Oracle Communications Data Modelには、最適な設計、自動データ移動およびIntra-ETLが装備され、追加設定の不要なDWLであるため、Susanの主な課題は次のようになります。

    1. プロジェクトの範囲を制限してCFOに速く価値を提供する:

      選択した事業分野に関連するレポートの特定。

      事業に必要または要求されるOLAPキューブおよびマイニングの特定。

      要求を満たすために必要な入力表の特定。

      表に入力する必要があるデータのソース・システムでの特定。

    2. 分析:

      組織のニーズと初期状態のOracle Communications Data Modelとのギャップの特定。Susanの場合、これらは最小限になることが予想できます。「グリーンフィールド」実装でなかった場合、既存レポートとOracle Communications Data ModelによるDWHの基本構造とのギャップも分析する必要があります。

      様々な用語のセマンティクスの相違の特定およびメモ(これは通常、Oracle Communications Data Modelでのトレーニングの後に即座に実施します)。ターゲット・データ要素へのソース・システムのマッピング(このケースでは、請求、製品および顧客のDWHのみ)。

    3. 設計および開発:

      ETL (請求からOracle Communications Data Modelへ、および他のDWHからOracle Communications Data Modelへ)。

      論理データ・モデルおよびレポートの設計の拡張

    4. トレーニングおよびテスト:

      シナリオの作成および実行

      一部の(トレーニングされた)パワー・ユーザーによる受入れテスト

    5. デプロイメント:

      初期/履歴データのロード

      増分ロード

    6. メンテナンス:

  2. Susanは、特定の事業分野で、追加の設定なしで利用可能なレポートを探し(レポートを直接に表示または関連ドキュメントで表示)、CFOが確実に要求するであろうレポートを検討します。

  3. Susanは、使用するレポートのリストを作成した後、ドキュメントをチェックして、それらのレポートに入力するエンティティおよび使用するプログラムを探します。まず最初に、Oracle Metadataダッシュボードを使用します(Oracle Business Intelligence Suite Enterprise Edition): 各レポートについて、入力の必要なすべての表を見つけて(ダッシュボード・レポート、エンティティ)、これらの表にアクセスするIntra-ETLにもアクセスします(ダッシュボード・エンティティ、プログラム)。

  4. エンティティの説明では、表ごとに入力する属性(列)を決定し、それらを様々なソースから取得できるデータと比較します。Susanは、ExcelファイルOCDM_KPI_Aggr_spec.xlsの列に関連付けられているKPIを見つけることができます。

    1. 課金システムでの格付けイベントとしてのNETWORK EVENT。

    2. 課金システムでのINVOICEの詳細。

    3. 課金システム、CRMシステムまたは独自の顧客DWHからの顧客データ。

    4. 課金システムまたは製品のDWHからの製品および製品の格付けデータ。

  5. 最後に、Susanはソースを決定し、対応する情報をロードするETLを作成します。このケースでは、2つの選択肢、つまりアーキテクチャまたはプロセスのいずれかを選択できます。

    1. 彼女は顧客および製品に関する正確かつ最新の情報の基盤として、製品および顧客のDWHを使用します(製品および顧客「ハブ」の原則)。標準DWH原則を使用した場合、通常それらは3NFフォーマットであるため、顧客、製品およびサービスに関して、Oracle Communications Data Modelの実表へのマッピング処理が簡易化されます。

    2. 製品および顧客のDWHへの移入を行うためのETLを使用し、Oracle Communications Data Modelに直接に移入できるように調整します。

  6. Susanにとって重要なことは、Oracle Communications Data Modelで一部のデータが利用可能になると、OLAPキューブのレポーティング・レベルおよび様々なマイニング・モデルに自動的にデータがプッシュされることです(実装の際に合意された計画に基づく)。彼女はOracle Communications Data Modelの各レベル(参照、ベース、導出、集計など)でデータを照合し、彼女が所持している以前のレポートと比較できます。あらかじめ定義の相違点を特定することにより(サブスクライバ、顧客、提供、サービスなどの定義)、データの比較および相違点の明確化が可能になります。

  7. 第2フェーズでの新タイプの追加は、対応する検索表(CUSTOMER TYPE)に1行を追加するだけです。ETLは、新しい顧客タイプを正しく参照できる必要があります。

  8. 税のカスタマイズでは、Susanは、Oracle Metadataダッシュボードで顧客表のカスタマイズによる影響を受けるすべてのIIntra-ETLおよびプログラムのリストをチェックします。基本的に、多数が影響を受けます。ただし、新しい属性により、そのほとんどは変更の必要がありません。この新しい列に応じてファクトの結果を集計する必要がある場合のみ拡張が必要です。

  9. Susanはこの情報を使用して、必要に応じて各INTRA-ETLにアクセスし、コードを修正します。次に、新しいディメンションを表すようにOracle Business Intelligence Suite Enterprise Editionのリポジトリおよびサンプル・レポートを修正します。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引