JP2014116016A - 所定のアラートを備える経営管理システム - Google Patents

Abstract

【課題】アラートを識別し、このアラートに関連するレポートと合わせてアラートを事前に規定する能力を有する経営管理システムを提供する。
【解決手段】消費者金融サービス事業に関するデータを含むように構造化された次元テーブルおよびファクトテーブルを有するデータベースモジュールを備えている。アラートモジュールが、消費者金融サービス事業に重要な条件をユーザに警告するように事前に規定され、レポートモジュールが、データベースモジュールに関連付けられる。事業のアラート条件を事前に規定して、消費者金融サービス事業内の情報の特定ユーザが求める情報に関するアラート条件を識別する。
【選択図】図１

Description

本出願は、全般的に経営管理システムの分野に係り、さらに詳細には、ビジネスインテリジェンス、自動レポートを含む分析、および早期の警告アラート機能を提供する経営管理システムに係る。

経営管理システムは、全般的にユビキタスになってきている。このようなシステムは、製造工場に特別に焦点を当てたソリューションや、精製所などの操業に焦点を当てたプロセス指向システムなど、特定の産業に特化させることができるものの、一般的な管理システムは、実際には、消費者金融、金融サービス、保険、および電気通信企業を含む各種の会社にみられるものである。

多くの管理システムは、企業全体にわたって生じる問題に対処しようとするものである。このようなシステム、例えばドイツ・ヴァルドルフのＳＡＰ社が生産販売しているシステムなどは、カスタマイズしたモジュールを使用できる中核機能を提供している。このようなシステムは、特定産業である遙かに少ない会社に合わせるために、広範にわたりかつ高コストのカスタマイズ作業を必要とする。カスタマイズプロセスの最後に、会社は数々の機能を提供するシステムを得ることができるが、そのプロセスで柔軟性が失われる可能性がある。その上、システムの基本機能は「標準的な」会社向けの仕様になっていることから、そのようなシステムの特定産業への適合性は必然的に制限されてしまう。

先行技術では、特化した小さめのシステムを寄り合わせることによってこれらの問題に対処して、全体のソリューションに到達しようとしてきた。しかし、このようなシステム間のインターフェースからは、実際には理論が示唆するものよりも多くの問題をはらんでいることが実証されることが多い。現代のビジネス企業は非常に複雑化しているため、幅広い基盤を持つ管理システムの強さに、業界特有のソリューションの柔軟性を組み合わせたソリューションを提供する試みに挫折することが多い。

このように、特定産業分野に適応させるための経営管理システムに対する幅広いニーズがある。

本開示の態様は、消費者金融サービス事業を管理するための経営管理システムである。この管理システムは、データベースモジュール、アラートモジュール、およびレポートモジュールを備えている。データベースモジュールは、次元テーブル、ファクトテーブルという２種類のテーブルを備えている。次元テーブルは、消費者金融サービス事業に関連するデータを含むように構造化され、商品明細次元テーブル、次元テーブル、スノーフレーク次元テーブル、および静的次元テーブルなどがある。ファクトテーブルも、消費者金融サービス事業に関連するデータを含むように構造化され、アプリケーションステータステーブル、アプリケーションテーブル、日々のアカウントのトランザクションスナップショットテーブル、およびアカウントのトランザクションスナップショットの集約テーブルなどがある。本開示はさらに、消費者金融サービス事業に重要な条件をユーザに警告するよう事前に規定したアラートモジュール、および消費者金融サービス事業に重要な条件をレポートするよう事前に規定したレポートモジュールを備えている。

本開示のさらに別の態様は、消費者金融サービス事業を管理するための経営管理システムの操作においてアラートを生成する方法である。この方法は、ユーザの役割を識別し、このような役割の中でユーザが求める重要情報も合わせて識別すること；その重要情報に伴う商品カテゴリを識別すること；その重要情報に伴う題目を識別すること；およびその重要情報に関わるアラート条件を識別することを含む、事業のアラート条件を事前に規定することを含む。システムが動作している間、このアラート生成方法は、何らかのアラート条件を満たしているかどうかを判定するようにシステムを監視する。１つのアラート条件を満たしていることを発見すると、システムは、それに対応する事前規定したものを作動させて、ユーザに知らせる。ユーザからの要求があると、システムは、そのアラートに関連するレポートを生成する。

以下に説明する図面は、本開示についての多数の例示的な実施形態を記載し、説明するものである。全図面を通して、同じ符号は同じ要素または機能的に同様の要素を指す。図面は、説明的なものであり、原寸通りに描かれてはいない。

本開示のシステムの全体構造を示すブロック図である。 本開示のシステムの一実施形態のデータフローを示すフローチャートである。 本開示のいくつかの実施形態で使用した次元テーブルのデータ構造を示す図である。 本開示のいくつかの実施形態で使用したファクトテーブルのデータ構造を示す図である。 本開示のいくつかの実施形態で使用した、アラートを規定し作動させるプロセスを示すフローチャートである。 本開示のアラートサブシステムの特徴を描いているスクリーンショットである。 本開示のアラートサブシステムの特徴を描いているスクリーンショットである。 本開示のアラートサブシステムの特徴を描いているスクリーンショットである。 本開示のアラートサブシステムの特徴を描いているスクリーンショットである。 本開示のレポートサブシステムの特徴を描いているスクリーンショットである。 本開示のレポートサブシステムの特徴を描いているスクリーンショットである。 本開示のレポートサブシステムの特徴を描いているスクリーンショットである。 本開示のレポートサブシステムの特徴を描いているスクリーンショットである。 本開示のレポートサブシステムの特徴を描いているスクリーンショットである。 本開示のレポートサブシステムの特徴を描いているスクリーンショットである。

以下の詳細な説明は、図面を参照して記載するものである。例示的な実施形態を記載して、添付の特許請求の範囲で規定する本開示の主題を説明するが、この実施形態は本開示の範囲を限定するものではない。

概要
本開示は、特定の環境に適応させやすい経営管理システムであって、アラートを識別し、このアラートに関連するレポートと合わせてアラートを事前に規定する能力を有する経営管理システムについて記載するものである。第１のレベルでは、その事業内での特定の役割に対するアラートおよびレポートを構成する。次に、所与の役割の範囲内で、アラート／レポートをさらに詳細に、事業全体の特定の商品またはサブセットに結びつけることができる。その後、所与のアラートの特定のサブジェクトを、そのアラートの生成を引き起こす特定条件と一緒に設定することができる。アラートは、特定の条件が生じたという通知を出すだけである。アラートをレポートと関連付けることで、ユーザは、アラートを所望の粒度で正確に解釈するのに必要な詳細レベルまで容易にドリルダウンすることができる。

本開示のシステムをサポートしているデータ構造は、次元テーブルおよびファクトテーブルを含むデータウェアハウスの方式で構成されている。次元テーブルは、所与の事業活動を測定する手段となる属性を含んでいるのに対し、ファクトテーブルは、そのような次元に関する特定情報を含んでいる。

本開示は、金融機関に対する本開示の例示的な実施形態を示すものである。そのため、本明細書で考察するシステムを使用する一組織の全体的な会社構造には、多くの銀行支店が含まれてよい。このような組織の他の局面は、地域本部または集約施設のほか、中央本部にまで広がってよく、そこに会社の全データが集められる。この銀行システムの使用法は、完全に例示的な性質のものであることは理解されるであろう。本明細書に記載の原理は、多くの産業に適応可能であり、当業者は、本明細書に記載の一般原理を他の産業分野に適用しやすいことがわかるであろう。

例示的な実施形態
システムオペレーション
図１は、本開示のいくつかの実施形態によるビジネスプラットフォーム２００を含む経営管理システム１００を描いている。一般に、経営管理システム１００は、ソースデータベース１０２の周りに構築される。データベースは、大企業規模のデータベースまたはデータウェアハウスシステムとすることができ、例を挙げると、ＳＱＬサーバＤＢ、ＤＢ２、Ｏｒａｃｌｅ ＤＢ、Ｄａｔａｓｔａｇｅ、ＯＤＩ、Ｉｎｆｏｒｍａｔｉｃａ、Ｃｏｇｎｏｓ、Ｏｒａｃｌｅ ＢＩなどのシステムである。このようなシステムは、データ要素からなるインターフェースファイルを受け入れるような構造になっているのが一般的であり、このデータ要素は、消費者金融および金融サービスの顧客によって、元のソースから直接得たデータを介して提供される。そのため、売上データは、銀行支店などのソースから流れることができ、銀行支店は、個人向けの銀行業務、法人向けの銀行業務、ローンなど、銀行内の特定事業分野からデータを受け取ることができる。さらに、地域本部または地域よりも上の本部は、完全に異種の事業部からデータを受け取ることができる。そのため、地域センターに報告する実体には、銀行支店、ローン仲介業者、ローン会社、およびクレジットカード発行会社などが含まれてよい。

ソースデータベース１０２とビジネスプラットフォーム２００との間に、インターフェース層１０４を立てることができる。このモジュールは、ユーザに対してより直接的に機能するフォーマットにソースデータをロードし、数種類のレポートの生成を容易にする。ここで注意すべきは、インターフェース層１０４は、多くの形態を取ることができ、以下でさらに詳細に考察していくように、複数の場所に設置されてよいということである。

ビジネスプラットフォーム２００を用いて本開示の教示を具体的に説明する。主要コンポーネントは、商品データベース１１０およびレポート／アラートモジュール１２２を含んでいる。先行技術において一般に理解されているように、データは、データを抽出し、変換し、ロードするプロセスを通して、データウェアハウスシステムの中にロードされる。このプロセスは、一般にＥＴＬモジュールと呼ばれるモジュール内で動作する。ここで、入力データの一般フォーマットも、ロードされるデータの所望の形態も、いずれも公知のものであり、ＥＴＬモジュールは、いかなる必要な変換も実行する。このようなモジュールは、先行技術で公知であり、ここではこれ以上考察しない。

商品データベース１１０は、準備領域１１２およびデータマート１１４にデータを格納する。データマッピングドキュメントに明記されている通りにソースデータが整うと、データは、ソースシステムによってインターフェース層１０４へ送られる。データがソースファイルとして提供された場合、データはビジネスプラットフォーム２００によって読み出され、インターフェース層１０４内のインターフェーステーブルにロードされ、その後、データ処理およびデータの計算が準備領域１１２で行われる。次にデータは、データマート１１４にロードされ、このデータマートから、アプリケーションは、アラートを報告し生成するためのデータをフェッチする。商品データベース１１０は、準備領域１１２でデータを処理し、データマート１１４にデータを格納する。これらのモジュールを実装する機器は、先行技術で公知のものであり、データベースの組み合わせ（例えばＤＢ２、ＳＱＬサーバＤＢまたはＯｒａｃｌｅデータベース）、ＥＴＬツール（例えばＤａｔａｓｔａｇｅ、ＯＤＩ、またはＩｎｆｏｒｍａｔｉｃａ）およびＢＩツール（ＯＢＩＥＥまたはＣｏｇｎｏｓ）などがある。商品データベース１１０内に運ばれるデータの構造を、以下で詳細に考察する。

レポート／アラートモジュール１２２は、レポートツール１２０およびレポート／アラートモジュール１２２を備える。本明細書では、可能性のある多くの構造を用いるが、図面に示した好適な構造では、レポートのフォーマットおよび内容を生成するモジュールであって、事前に生成したレポートを格納して迅速に配信するための装置に接続されたモジュールを用いる。レポートおよびアラートを作成するには、ビジネス企業を慎重に分析する必要があることが容易に理解されるであろう。ここで重要なタスクは、管理者およびそのチームが、経営管理過程でどのような情報を必要とするかを判断することである。事業の状況はそれぞれ異なるため、ここでは先験的な規則はあり得ない。同一事業内であっても、異なる部署または事業部が様々な情報を必要とするのは当然である。しかしながら、注意すべきことは、経験豊富な熟練の管理者は、自らの情報要件を理解しており、その要件をレポートツール１２０に入力できるという点である。この点で、レポートツール１２０は、商品データベース１１０から要求されたデータの場所を決定することができる。チームの知識および技能を用いて特定形態でデータを表示するように構成されたレポートは、レポート／アラートモジュール１２２にスケルトン形式で維持されることができる。これらのレポートは、レポートの規定・作成ステップを通らないため、極めて高速でレンダリングされることができる。

レポートおよびアラートは、極めて接近した関係にある。レポートは、管理者が事業の状況を把握するのを補助するために選択され、フォーマットされたデータの集まりである。アラートも、管理者が必要とする事業情報に関連しているが、アラートは、所定基準に基づいた問題が存在するという通知を伝達するだけである。アラートは、管理者に対して早期に警告するトリガーとして作用する。逆に言えば、システムが指定した領域にアラートがないということは、その局面に対する早期警告がないほどに、その領域でビジネスが前向きに成長または改善しているということである。そのため、イベントが自然と進行すれば、管理者にアラートを発するようシステムに要求され、管理者は、レポートの内容通りに、さらなる詳細を要求する。生成およびアクセスを容易にするため、本開示では、レポートとアラートの機能を１つのモジュール内に統合して、レポート／アラートモジュール１２２にする。

図２は、上記の考察を拡大し、ビジネスプラットフォーム２００へ入るデータフローに焦点を当てたものである。前述したように、データは、ソースデータベース１０２からＥＴＬモジュール１０４へ流れ、同モジュールでデータは抽出、変換、ロードされる。ここに示したように、ＥＴＬプロセスは、照合モジュール１０１、事前検証モジュール１０３、および検証モジュール１０５を含んでいる。データは、提供される可変的なリストに基づいて一時的な準備領域に送られる必要があり、このデータはその後、照合エンジンによって引き出される。最初に、データは、管理者のニーズに基づいてデータをカテゴリに統合することによって、ソースデータベース１０２にみられるソース指向の構造ではなく、ビジネスプラットフォーム２００の構造に反映されたように、照合される。重要な点は、ソースデータが、ソースＳ１、Ｓ２、Ｓ３、およびＳ４で示したように、複数の場所から来ていることが多いという点である。ソースは、例えば、様々な銀行支店の所在地、または多様な事業地内にある様々な事業部とすることができる。ソースデータベース１０２に含まれるデータは、フォーマット、組織、および題目が様々に異なっていてよく、データ照合エンジン１０１は、ビジネスプラットフォーム２００にロードするために論理的に関連する部でデータを組織する。
さらに、照合エンジン１０１は、いくつかの計算を実行できる。異種のソースから来ているデータは、ＡＰＩ（アプリケーションプログラミングインターフェース）を介して収集される。ＡＰＩが実行する機能は、ビジネスプラットフォーム２００の要件、特にそのシステムのデータディクショナリ（図示せず）に結びついている。これには、初期の措置として、データソースからのデータをデータディクショナリにマッピングさせることが必要である。直接利用可能なデータは、準備領域（図１）に直接ロードできるが、複数のシステムから来るデータは、適切な計算アルゴリズムで処理してデータディクショナリに合わせる必要があることがある。ソースデータとビジネスプラットフォーム２００の両方の詳細が公知である以上、このような計算が先行技術の範囲内であることは理解されるであろう。

例えば、多くの状況では、ソースデータベース１０２に含まれるデータは、多くの異なるフォーマットで表現されることができる。照合エンジン１０１は、アカウントレベルの月々のデータに変換される必要のある様々な日々のトランザクションデータへのアクセスを持つことができる。例えば、単純な例として、ツールは、その月にアカウントで成された支払いをすべて調査し、それを合計してそのアカウントのその月の支払とすることができる。データは、エクセルファイルもしくはテキストファイル、またはその他の任意のフォーマットの形態で照合エンジン１０１に届くことができる。照合エンジンが実行できる１つのタスクは、そのようなファイルを選択したフォーマットに変換してさらに処理することである。

ソースデータベース１０２から来るデータは、そのデータがソースデータベース１０２に受信されると直ちに照合エンジン１０１へ送られるか、あるいは引き出されることができ、これはつまり、周期単位で処理するため、または特定量のデータが蓄積された際に処理するために、引き出されることができる。データは、さらに処理するために、事前検証ファイル内で統合される。これらの変形例およびその他の変形例を、当業者は理解し、実施することができる。

事前検証モジュール１０３は、データディクショナリを介して照合データを運用する。公知のように、このプロセスで、データを所与の一連の制約に合わせる。必要に応じてエラーメッセージを識別できる。

検証エンジン１０５は、データを検査して、内容およびフォーマットがビジネスプラットフォーム２００にロードするために正しいことを確認する。ここで、問題に遭遇した場合、エンジンは、ファイル全体を拒絶し、問題のある個々の記録を、ユーザがアクセスするための特別なファイルにロードし、拒絶の原因となる要素をハイライトする。全記録が修正されると、ユーザは、ファイル全体を再び送ることができる。修正を必要とするデータ項目を識別するために、拒絶レポートを生成することができる。

インターフェース層１０４は、照合エンジン１０１、事前検証モジュール１０３、および検証エンジン１０５からデータを受信し、ビジネスプラットフォーム２００にロードするためにそのデータを保持する。このロード動作は、日、週、または月など、計画した単位で起こすか、あるいは、選択した量のデータがインターフェース層１０４に蓄積された時点で起こすができる。

データの準備が整うと、そのデータはビジネスプラットフォーム２００にロードされ、特に商品データベース１１０にロードされる。そこで、データは、まず準備領域１１２で処理されてから、データマート１１４で処理される（図１）。準備領域のテーブルを読み込むためにセッションが起動するたびに、テーブル内の前段のデータがまず削除されるか切り捨てられ、その後、新たな一連の記録が挿入される。データは、最初にそれぞれのデータソースから読み出され、続いてすべての計算および変換が、ファクトテーブルおよび次元テーブルにそれぞれロードされる。データマートの次元テーブルにロードされている間、それぞれの固有の記録に対してキーが生成され、その後、利用できる次元でファクトテーブルが調査され、キーは、それぞれのファクトテーブルにロードされる。ローディングは、常にインサートとして行われる。そのため、集約テーブルは、ファクトテーブルから作成される。データウェアハウスのこのような両要素の動作は、先行技術で十分公知であるため、ここではこれ以上説明する必要はない。

データ構造
商品データベース１１０は、データを２種類のテーブル−次元テーブル３００およびファクトテーブル４００に格納する。次元は、属性であり、この属性によって事業が測定され（この測定は、計算された可変的なデータで、その値はユーザが分析する）、次元は、データセットを非重複領域に分離するようになっている。次元は、測定値を分割できる手段となるようなパラメータである。例えば、銀行支店が受けた収益からなるデータセットにおいて、有益な次元は、支店の所在地、日付、収益額、および事業部門とすることができる。このような次元の各々は、データセットを、別々の非重複要素に「スライスアンドダイス」するように動作する。しかし、ファクトテーブル４００は、事業プロセスの測定法、または測定基準を含んでいる。例えば、「＄１２，０００」はファクトであり、このファクトは、「収益」と名付けた次元のカテゴリに収めることができる。通常は、複数のファクトおよび次元を集約し、その結果、１つのファクトテーブルに「２０１２年１１月２０日の１６番通り支店の収益＄１２，０００」などのエントリを入れることができる。

図３に詳細に示した次元３００は、全体的に次の４つのカテゴリ：商品明細次元３０２、共通次元３０４、スノーフレーク次元３０６、および静的次元３０８に分類される。商品明細次元３０２は、特に、自動車ローン商品次元３０２ａ、クレジットカード商品次元３０２ｂ、ローン次元３０２ｃ、個人金融次元３０２ｄなどの商品部門を指す。これらの次元の各々は、特に特定種類の商品に関係している。例えば、クレジットカード次元３０２ｂのカテゴリ以下にある次元は、例えば、「カードタイプ」「与信限度額」などとすることができる。事業構造に応じて、商品ベースの次元をいくつ追加してもよい。ただし、管理ＩＰに基づくレポートとアラートからなる基本セットが、技術を即座に有益かつ生産的にする。

共通次元３０４は、商品カテゴリが多岐にわたる。例えば、「支店」３０４ａは、ある支店で販売された全商品に対する次元であり、その支店自体は個々のどの商品にも結びついていない。

スノーフレーク次元３０６は、他の次元テーブルからのキー情報のみを保持する次元である。１つのこのような次元が、例えば、商品明細テーブルの「自動車＿ディーラー」「自動車＿モデル」および「自動車＿ローンタイプ」から、キー情報を保持できる。共通のスノーフレーク次元３０６ａは、全商品に当てはまり、商品のスノーフレーク次元３０６ｂは、特定商品のみに対して使用される。

静的次元３０８は、ＣＳＶタイプの静的ファイルを介してロードされ、コンマ、タブ、段落記号などの符号によって区切られることが特徴である。例えば次元「年代幅（Ａｇｅ Ｂａｎｄ）」は、静的次元である。

図４は、ファクトテーブル４００の詳細構造を描いている。ファクトテーブルは、様々な用途において多くの形態を取ることができるため、ここに描いたものとは異なる構造を用いてもよいことは当業者に理解されるであろう。前述したように、本開示の例は、銀行への適用に焦点を当てたものであり、その指向は、ファクトテーブル４００の詳細構造に反映されている。

ここに構造化したように、ファクトテーブル４００は、商品ごとに組織されており、その結果、各商品に対して４つのファクトテーブルがある。それは、アプリケーションテーブル、アプリケーションステータステーブル、日々のアカウントのトランザクションスナップショットテーブル、月々のアカウントのトランザクションスナップショットテーブルである。日々のアカウントのトランザクションスナップショットテーブルは、各サブジェクト領域における全アカウントを含む、対象となる各サブジェクト領域における一日の終わりのトランザクションデータのスナップショットを含む。月々のアカウントのトランザクションスナップショットテーブルは、各サブジェクト領域における全アカウントを含む、対象となる各サブジェクト領域における月末のトランザクションデータのスナップショットを含む。最後のテーブルは、実際には集約テーブルであり、これは、より高い粒度で要約した一種のファクトテーブルである。そのため、商品４０２と名付けた第１の商品には、４つのファクトテーブルがあり、それは、アプリケーションテーブル４０２ａ、アプリケーションステータステーブル４０２ｂ、日々の収支テーブル４０２ｃ、およびアカウントスナップショットテーブル４０２ｄである。商品２から商品ｎまでの各商品は、同じ４つのファクトテーブルに関連している。

アラートおよびレポート
前述したように、管理者は、いつ、どの程度の問題が存在するのかを正確に判断し、早期に警告するアラートを関係者に出し（目標のソリューションに基づいた役割）、ドリルダウンする必要のあるレポートを特定して、取り組む必要のある特定の問題を識別するという主な課題に直面している。さらに、どの特定の問題が管理者にとって最も重要であるかという問いは、その事業における管理者の立場に非常に強く関連しているため、この課題は困難なものである。部門長が直面する問題は、ＣＥＯにとって重要な問題とは大いに異なっている。

図５は、役割ベースのアラートプロセスを事前規定し、作動させるためのプロセス５００のフローチャートである。上記に状況を記載したように、本開示は、特に、銀行業向けの管理ソリューションを対象しているため、本明細書に記載する特定の例は、その事業に適合している。当業者は、プロセス５００の基礎となる原理を他の産業にも適用できることを理解するであろうし、先行技術レベルは、そのタスクを達成するのに十分である。

プロセス５００は、２つの異なる部分で発生するものと考えることができる。第１の部分は、ステップ５０２〜５０８を占める事前規定段階である。これらのステップは、ユーザ、商品または商品カテゴリ、アラートサブジェクト、およびアラート条件の面で、プロセスを完全に規定するものである。アラートパラメータを作成した後、プロセスは、作動段階のステップ５１０〜５１８に入り、このステップでシステムは、動作を監視してアラート基準を満たす条件を識別し、そのような条件が満たされると、アラートが発行される。

規定段階における第１のステップであるステップ５０２では、ユーザの役割を識別する。前述したように、ユーザの役割が、ユーザが自分の任務を実行するのに求めている特定の情報に広く影響を与える。例えばＣＥＯが、組織全体の業績を必要としている場合、多くのソースからデータを統合する必要がある。多国籍組織では、広範囲にわたるタイムゾーンの様々な国で操業している多様な組織から結果を要約することがある。一方、部門長が同量の重要情報を必要としていても、その情報は、焦点を遙かに絞ったものになるだろう。例えば、部門長は、１週間または１ヵ月間のレポートを見るよりも、最終シフトおよび最終日の情報を検索するであろう。部門長は、事業部全体の収益を閲覧するよりも、発生した成果の合計または収益を、個々のレベルまたはセルレベルまで下げて検索するだろう。

特定の役割およびその情報のニーズを規定するためには、相当量のリサーチを達成し、思考しなければならない。この問題は、通信量および器械使用量が膨大な現代において、特に重大になっている。現代の管理者の問題は、より多くの情報をどのようにして入手するかではなく、データの洪水の中から重要情報をどのように指先で識別するかということである。プロセス５００のような任意のシステムの実装をサポートするためには、このレベルの事業分析を達成しなければなならい。プロセス５００の実装細部に焦点を当てるため、経営アナリストは、組織内の情報の流れおよび情報の要求に関する調査を完了していると思われる。

プロセス５００の例示的な実施形態を、図６〜９に描いたシステムに示している。これらの図は、経営管理プラットフォーム２００（図１）のアラート規定部分のスクリーンショットを示している。最初のこのようなスクリーンショットである図６は、会社のＣＥＯ／ＣＦＯ／ＣＲＯなどがアラートシステムにサインインした際に見る画面を示している。この図に見られるように、アラート画面６００には、３つのドロップダウンリスト：役割選択用ドロップダウンリスト６０２、商品選択用ドロップダウンリスト６０４、およびアラートカテゴリドロップダウンリスト６０６が含まれている。このほか、ユーザは、その時点のアラート条件すべてを示しているアラート表示６０８を見る。以下の考察は、そのような画面部分の各々について述べたものである。

前述したように、プロセス５００の第１のステップであるステップ５０２では、ユーザの役割を識別する。図７に示したようなアラート画面６００では、役割選択用ドロップダウンリスト６０２上でクリックして役割選択を行う。このアクションは、適切なドロップダウンリストを開くよう要求するものであり、このドロップダウンリストが役割選択を示す。ここでは、ユーザは、ＣＥＯ、商品責任者、ＣＲＯ、ＣＦＯ、およびアナリストの中から選択できる。明らかに、これらの役割は、排他的なリストを提供するものではなく、排他的なリストであれば使用が面倒になることも明らかである。そのため、適切な役割群を提供するシステムのなかには、この場合有益なものがある。いくつかの実施形態では、システムは、現在のユーザにとって適切な役割を決定するために、他の情報を用いることができる。これらの方法および他の方法が、ユーザのジョブタイトルを規定し、これによって、ビジネスプラットフォーム２００に関するユーザの役割を規定する。

図５に戻ると、次のステップ５０４では、商品カテゴリの識別に移る。ここで注意すべきは、アラートを事前規定する際に必要となる特定の基準は、様々な用途によって異なるということである。銀行業では、商品カテゴリは、例えば、小売銀行業、商業銀行業などの間で区別されるため、事業データへの良いエントリポイントである。他の事業では、異なる基準が重要となることがある。例えば、いくつかの業務では、地理的位置が商品カテゴリよりも重要なことがある。ここで注意すべきは、特定のカテゴリの識別が重要なのではなく、今後の事業に特にふさわしいカテゴリの名称を識別しなければなないということである。

商品カテゴリ選択の実行を図８に示している。この図では、ユーザは、商品選択用ドロップダウンリスト６０４上でクリックして、商品カテゴリのリストを呼び出す。図示したリスト内の選択肢は、クレジットカード、自動車ローン、個人ローン、住宅ローン、および財産管理である。これらのカテゴリは、このビジネスプラットフォーム２００を用いる特定のシステムによって識別される通りに、銀行業における事業部門を分離している。銀行業界内であっても、特定の会社が商品カテゴリリストを自社特有の状況に合うように変更することを望むのは当然である。例えば、住宅ローン事業に専念している銀行が、クレジットカード、自動車ローン、個人ローン、および財産管理のカテゴリを削除して、例えば、住宅ローン、商業用不動産ローン、証券化住宅ローンなどを選ぶのは当然である。

再度図５に戻ると、システムは、ステップ５０６でアラートサブジェクトを識別し、続いてステップ５０８でアラート条件を識別する。アラートの基本サブジェクトを事前の事業分析によって識別しなければならないため、これらのステップのうちの第１のステップをまず完了しなければならない。この分析は、企業の各レベルで的確な決定を下すために正確にどの情報が必要なのかを識別する重要部分である。組織の上に行くほど、この決定はますます困難になるが、この原因は正に、利用できるデータがあまりにも多いからである。第２の要点は、管理知識およびスキルに基づいて、ステップ５０８でアラート条件を識別するには、ある程度高度なプランニングも必要な点である。なぜなら、正確に何が良好なパフォーマンスレベル、不確かなパフォーマンスレベル、および悪いパフォーマンスレベルを構成するのかを最初に判断しなければならないからである。さらに、パフォーマンスレベルは、条件の変化に追従するために連続的に綿密に調査しなければならないため、この分析要点は、継続したものでなければならない。設備は最新のものになっているため、例えば、予想されるパフォーマンスレベルはおそらく変化するであろう。同じく、コスト削減のためにメンテナンスが延期されている場合、パフォーマンスレベルはその条件に適応させなければならない。

図９に見られるように、ユーザは、所与のアラートをトリガーするためにパフォーマンスレベルを選ぶことができる。ここでは、ホスト会社は、カラー符号化スキームを用いて、パフォーマンスレベルを黄、緑、赤および白で示している。同様のカラースキームが広く使用されており、カラースキームには、これらの色に特定のパフォーマンスレベルが広く関連付けられている。ユーザの関心は、ある要因が不足しているかどうかを知るとともに、パフォーマンスが良好なとき、またはパフォーマンスが不良なときであって、パフォーマンスがその中間ではないときに、別の要因をアラートととして識別できることを知ることである可能性があるため、選択肢が必要である。好ましくは、ユーザは、２つ以上のアラートレベルを選択することができ、これによって複数のパフォーマンスレベルでの選択が可能になる。

ステップ５０８で、プロセス５００の識別段階を完了する。その後、システムは、ステップ５１０〜５１８からなる作動段階に入る。ステップ５１０は、システムを監視することからなり、続いてステップ５１２では、任意のアラート条件を満たしているかどうかを判定する。どの条件も満たしていない場合、システムは、単純にステップ５１０に戻る。ほとんどのシステムの動作は、この２つのステップからなることが容易にわかる。ただし、アラート条件を満たしていれば、アラートはステップ５１４で作動する。その結果を、図６〜９のアラート表示６０８に見ることができる。これらの図に見られるように、アラートの題目は、簡潔に記載され、そのアラート項目の状態を示すカラーの丸とともに表示されている。

レポート
先に言及したように、管理者が、短い１行で記載できる情報よりも遙かに多くのアラート条件に関する情報を知りたがるのは当然であることは、認識できる。そのニーズを満たすため、アラートシステムには、レポートモジュール１２２（図１）が組み込まれている。その結果、ユーザがステップ５１６でレポートを希望すれば、ユーザは、アラート表示６０８の各項目の右端にあるカラーの丸をクリックすることができ、このアクションにより、ステップ５１８でレポートが生成される。生じたレポート内に適切なハイパーリンクを含めることで、管理者は、リンクの連鎖をたどって、希望する情報をできるだけ多く、または少なく得ることができる。

本開示により生成したレポートの一例を図１０〜１５に示している。図１０に見られるように、システムは、基準のデフォルト設定を確立するためのユーザプロフィールを用いることができ、この基準は、ユーザが最初にシステムにログオンしたときに表示される情報を支配する。ここで、レポート画面９００は、「ＣＥＯ」の役割を持つ人物がレポートモジュール１２２（図ｌ）にログオンしたときに、システムによって自動的に生成されるものである。そこに、選んだ事前設定された商品領域、および１つ以上の特定のレポートが表示される。図示した例では、ユーザは、商品領域を「クレジットカード」に事前に設定しており、６つの事前に規定したレポートを表示用に選択している。個人プロフィールの生成および使用は、先行技術で公知であり、ここではこれ以上考察しない。

選択したレポートを生成するためにユーザが取る詳細なステップは、以下のセクションに及ぶ。レポート生成における第１のステップは、図１１に示した役割の識別であり、ユーザは、アラートに関して上記で考察したように、ドロップダウンリスト９０２から１つの役割を選択する。ここで、ユーザは、ＣＥＯ、商品責任者、ＣＲＯ、ＣＦＯ、およびアナリストという選択肢を提供される。同じく、図ｌ２に見られるように、ユーザは、ドロップダウンリスト９０４から１つの商品カテゴリを選択する。ここに表示されている選択肢は、クレジットカード、自動車ローン、個人ローン、住宅ローン、および財産管理である。役割選択も商品選択も両方とも相互に修正してよいことは理解されるであろう。例えば、ユーザの役割で、ドロップダウンリスト９０４によって提供される商品の範囲を限定してもよい。例えばローン会社は、住宅ローン以外の商品を見られなくてもよい。

各商品領域内では、ユーザは多くの事前規定レポートを入手できる。これらのレポートを多くのレベルで統合することができ、システムによってユーザは、レポートのカテゴリおよびサブジェクトを階層的に処理することができる。例えば、図１３に示したように、システムは、カテゴリ９０６を複数のレベルで提供できる。図示した例は、クレジットカードを商品領域として選択していると仮定したものであり、システムは、上位３つのカテゴリ：先行インジケータ（ＬＥＡＤＩＮＧ ＩＮＤＩＣＡＴＯＲＳ）、同時インジケータ（ＣＯＩＮＣＩＤＥＮＴＡＬ ＩＮＤＩＣＡＴＯＲＳ）、遅延インジケータ（ＬＡＧＧＥＤ ＩＮＤＩＣＡＴＯＲＳ）を提供して、カテゴリを、過去、現在および未来に時系列に分割している。商品カテゴリの選択は、特定事業の周到な知識に依存している。また、レポートカテゴリは、役割によって様々であってよい。ＣＥＯは、広く企業全体のカテゴリに主に関心があるかもしれないが、国内の営業部長は、地理的区分を見たいと思う可能性があり、その場合は、上位のカテゴリは、東地区、南地区などであってよい。

上位のカテゴリ９０６には、階層的に入れ子になったサブカテゴリ９０７が続き、入れ子のレベルは、単に事業のニーズによって決定される。図示した例では、先行インジケータのカテゴリには、取得メトリック（Ａｃｑｕｉｓｉｔｉｏｎ Ｍｅｔｒｉｃ）、活動分析（Ａｃｔｉｖｉｔｙ Ａｎａｌｙｓｉｓ）、アトリッション（Ａｔｔｒｉｔｉｏｎ）などのサブカテゴリが含まれている。サブカテゴリは、左側に「拡張」ボタンを含んでおり、追加のサブカテゴリを選択できることをユーザに知らせていることに注意されたい。ある事業の構造を基に、複数レベルのサブカテゴリを用意することができる。

図１４は、ユーザがサブカテゴリの取得メトリックを選んだ状況を示しており、このサブカテゴリは、ユーザに、取得インジケータ（Ａｃｑｕｉｓｉｔｉｏｎ Ｉｎｄｉｃａｔｏｒｓ）、取得傾向（Ａｃｑｕｉｓｉｔｉｏｎ Ｔｒｅｎｄｓ）、承認分析（Ａｐｐｒｏｖａｌ Ａｎａｌｙｓｉｓ）、および例外分析（Ｅｘｃｅｐｔｉｏｎ Ａｎａｌｙｓｉｓ）と名付けた４つのレポート９０８の選択肢を提供している。前述したように、特定のレポートサブジェクトの選択も、レポート内容の選択も、事業の詳細な調査および特定のユーザのニーズに基づく結果である。

その結果生成されたレポート９１０を図１５に見ることができる。このレポートは、図１４に示した画面で取得インジケータを選択した結果である。このレポートは、ヒストグラム表示とデータ表示の両方の構造になっている。事業分析によって、データに対するユーザのニーズのほか、レポートに対する適切な次元決定手段も明らかになってくる。例えば、図示したグラフのユーザのニーズは、日ごとに別々のデータポイントに対して、＄１００，０００ずつ増額して表示された金額で記載されている。事業背景が異なれば、ここに示したグラフよりも規模の大きいまたは小さい量の尺度（ｙ軸）が必要になることもある。同じく、時間単位（ｘ軸）は、これよりも短くてもよいし（１日など）長くてもよい（数週間または数ヶ月にわたる）。

おそらくユーザは、これらのレポートの各々を構造化できるとともに、どのカテゴリ、どのサブカテゴリ、どの個々のレポートが必要になるのかを判断することもできると考えられるが、そのタスクに必要な時間は膨大になるであろう。しかし、そのタスクにかかる時間は、データを分析し、経営判断を下すことが求められるものの、レポートの構造化はしないというユーザの主なミッションとは別にかかる時間である。そのため、幅広い事業活動をカバーしている、事前に規定した一連のレポートをユーザに提供することで、ユーザは、データを表示するプロセスではなく、データに集中することができる。その結果は、事業全体を改善する判断となるものでなければならない。

このほか、システムは、ユーザに、ｘ軸およびｙ軸の値を修正することによってレポートを洗練させる能力をもたらすとともに、データをより高い粒度までドリルダウンする能力ももたらす。このような可能性は、公知のものであり、詳細には考察しない。

本システムによって、ユーザは、アラート条件を迅速に識別することができ、アラートを直接レポートに結びつけることができる。アラートの生成は、十分直接的で容易なため、ユーザは、状況の変化により必要に応じて、アラートの識別を瞬時に変更することができる。

結論
以上に述べたシステムは、多様な状況に応用できることがわかるであろう。本開示において識別した実施形態の詳細は、特に銀行業に関連するものであるが、当業者は、同じ原理を多様な他の産業に適用できることがわかるであろう。基本的な事業分析で、管理者にとって重要な情報のカテゴリを識別できる。例えば、情報を地理的領域ごとに分割したいと思う企業もあれば、商品部門に集中させる企業もあるであろう。本明細書に記載したシステムは、多岐にわたるビジネスニーズに適用させるのに十分に柔軟であり、いずれも本開示の範囲内であるとともに、添付の特許請求の範囲内である。

Claims (5)

1. 消費者金融サービス事業を管理するための経営管理システムであって、
   データベースモジュールであって、
   各次元テーブルが、
   １つ以上の商品明細次元テーブル；
   １つ以上の共通次元テーブル；
   １つ以上のスノーフレーク次元テーブル；および
   １つ以上の静的次元テーブル；
   を含む、消費者金融サービス事業に関連するデータを含むように構造化された、１つ以上の次元テーブル、ならびに
   各ファクトテーブルが、
   １つ以上のアプリケーションステータステーブル；
   １つ以上のアプリケーションテーブル；
   １つ以上の日々のアカウントのトランザクションスナップショットテーブル；および
   １つ以上のアカウントのトランザクションスナップショットの集約テーブル；
   を含む、消費者金融サービス事業に関連するデータを含むように構造化された、１つ以上のファクトテーブル
   を含む、データベースモジュール、
   消費者金融サービス事業に重要な条件をユーザに警告するよう事前に規定された、アラートモジュール；ならびに
   消費者金融サービス事業に重要な条件をレポートするように事前に規定された、レポートモジュール
   を備える、経営管理システム。
2. 消費者金融サービス事業を管理するための経営管理システムの動作においてアラートを生成する方法であって、
   ユーザの役割を識別し、前記役割の中でユーザが求める重要情報も合わせて識別すること；
   前記重要情報に伴う商品カテゴリを識別すること；
   前記重要情報に伴う題目を識別すること；
   前記重要情報に関わるアラート条件を識別すること；
   を含む、事業のアラート条件を事前に規定すること、
   何らかのアラート条件を満たしているかどうかを判定するように前記経営管理システムを監視すること；
   １つのアラート条件を満たしていることを発見すると、アラートを作動させてユーザに知らせること；
   ユーザからの要求があると、前記アラートに関連するレポートを生成すること
   を含む、方法。
3. 商品カテゴリの識別は、クレジットカード、住宅ローン、消費者ローン、自動車ローン、または財産管理のうちの１つである商品を識別することを含む、請求項２に記載の方法。
4. 消費者金融サービス事業に重要な条件をレポートするようにレポートを事前規定すること；および
   ユーザの要求によりユーザに対してレポートを準備し、配信すること
   を含む、請求項２に記載の方法。
5. 消費者金融サービス事業を管理するための経営管理システムであって、
   消費者金融サービス事業に重要な条件をユーザに警告するよう事前に規定したアラートモジュール；および
   消費者金融サービス事業に重要な条件をレポートするよう事前に規定したレポートモジュール
   を備える、経営管理システム。