JP4652418B2 - 企業全体にわたるポリシー管理のシステムおよび方法 - Google Patents

Description

本発明は、複雑な組織の資産を管理するためのシステムおよび方法に関する。より具体的には、本発明は、企業全体にわたるポリシーを管理および施行するためのシステムおよび方法に関する。

小さな組織は、すべての情報を組織内のあらゆる人と直接共有することができ、それによって、それぞれの人は他の人が何をしているかが分かるという点で、情報効率がよい。組織の規模が大きくなるにつれて、たとえばイントラネットなどの内部の通信ネットワークが、1つの建物内のオフィスどうしの間における通信から、別々の大陸に配置されているオフィスどうしの間における通信に至るまで、地理的に異なる場所どうしの間における通信を容易にする。イントラネットの使用、ならびにそれをサポートするハードウェアおよびソフトウェアは、よく知られており、さらに説明する必要はない。たとえば、参照によって本明細書に組み込まれるC.Zacker、「Networking:The Complete Reference」、McGraw-Hill Companies、Berkeley、California (2001)は、イントラネット内で使用できるネットワークハードウェアおよびプロトコルについて記載している。別の例においては、参照によって本明細書に組み込まれるR.Orfali、D.Harkey、「Client/Server Programming with Java and COBRA,2nd ed.」、John Wiley & Sons,Inc.、New York (1998)は、クライアント/サーバミドルウェアを開発するために使用できるソフトウェアの方法について記載している。クライアント/サーバミドルウェアを開発するために、たとえばRPC (remote procedure calls)、MOM (Message-Oriented-Middleware)、あるいはデータベースストアドプロシージャーなど、他の従来の方法を使用することができる。

組織は、大きくなるにつれて、構造的にも複雑になり、また組織内のそれぞれの部門が、自分の業務に必要な情報を作成して保持するために、情報の流れが分断される。多くの状況においては、それぞれの部門に必要な情報を保存するために、その部門によって、別々のカスタマイズされたデータベースが保持される。別の部門からの情報が必要とされる場合には、通常は、他の部門のデータベースにアクセスするための許可を付与されなければならず、また検索されるデータは、古くなっているおそれがある。それぞれの別々の部門に対して許可を得る必要があるため、組織全体にわたるレポートを作成することが困難になり、多大な時間を要する。
米国特許第6,754,674号 C.Zacker、「Networking:The Complete Reference」、McGraw-Hill Companies、Berkeley、California (2001) R.Orfali、D.Harkey、「Client/Server Programming with Java and COBRA,2nd ed.」、John Wiley & Sons,Inc.、New York (1998)

大企業はまた、企業全体にわたるコンプライアンスを必要とする州法、連邦法、および国際法の制約を受ける。そのような要件に従うためには、企業内のあらゆる部門にわたってタイムリーなやり方で情報を収集しなければならない。したがって、企業全体にわたるポリシーをタイムリーなやり方で組織全体にわたって実施およびモニタできるシステムおよび方法が、依然として必要とされている。データの信頼性と、コスト効率のよいデータ収集活動とを確かなものにする手順を用いて、組織の資産に透明性を伴ってアクセスできるようにするシステムおよび方法も、依然として必要とされている。

完全な最新のセキュアな、かつ容易にアクセス可能な、組織の資産の一覧を含む組織資産データベース(ADb)について記載する。それぞれの資産を、組織の組織階層を表す構造にマップする。これにより、それぞれの資産に対する責任の複数のレベルを構成する。それぞれの資産は、ADb内の他の資産との関係において、1つまたは複数の役割を有し、かつADb内の他の資産との関係において、1つまたは複数の資格を有する。資産どうしの間の関係は、ADbが必ず完全かつ最新であるようにし、かつADb内に含まれる情報の容易なフィルタリングと回収とを可能とする。

本発明の一実施形態は、資産を表す少なくとも1つの資産レコードを含む資産テーブルであって、その少なくとも1つの資産レコードは資産タイプによって特徴付けられる資産テーブルと、第1資産タイプと第2資産タイプとの間の関係を表す少なくとも1つのレコードを含む関係タイプテーブルであって、1つまたは複数のレコードを、それぞれその関係タイプテーブル内で定義される関係を介して管理単位の資産にマップし、その管理単位資産は階層構造組織内の管理単位を表す、関係タイプテーブルとを含む、資産データベースシステムを対象とする。

本発明の別の実施形態は、資産データベースのデータインテグリティーを保持するコンピュータで実装される方法であって、資産を表す少なくとも1つの資産レコードを含む資産テーブル、および第1資産タイプと第2資産タイプの間の関係を表す少なくとも1つのレコードを含む関係タイプテーブルとを構成するステップであって、その少なくとも1つの資産レコードは、資産タイプで特徴付け、1つまたは複数の資産レコードを、それぞれその関係タイプテーブル内で定義される関係を介して管理単位の資産にマップし、その管理単位の資産は、階層構造組織内の管理単位を表すステップと、信頼できるデータソースからのデータ供給によって資産データベースを更新するステップと、その資産データベースの一覧内の変更を特定するステップと、その一覧内の変更によってさらなる情報が必要かどうかを判定するステップと、さらなる情報を提供する責任者を、その責任者と変更された一覧との関係に基づいて特定するステップと、その責任者からそのさらなる情報を受信するステップと、そのさらなる情報でその資産データベースを更新するステップとを含む方法を対象とする。

本発明について、その好ましい実施形態および代替実施形態を図面と共に参照することによって説明する。

会社全体にわたる、あるいは企業全体にわたるポリシーを資産データベース(asset database (ADb))内へコード化することによって、それらのポリシーを実施し、文書化し、そのコンプライアンスを測定することができる。ADbは、企業の資産と、それらの資産がどのように相互に関係しているかとを反映するリレーショナルデータベースである。資産は、従業員、ハードウェア、ソフトウェア、コンテンツなどを含む。資産はまた、たとえば部門、部署、およびP&Lグループなど、企業の下位組織を含む。ADbは、それぞれの資産を企業の組織階層に関係付け、それによって、その資産をコントロールしている人々の階層が容易に識別される。

ADbシステムは、組織を部門、部署、およびビジネスエリアへとマップして、企業の実際の組織を映し出す構造を組み込んでいる。さらに、管理機能(たとえばCAO)、地理的位置(たとえば地域、国、都市、建物、デスク)、適法性(たとえば給与、コンプライアンス)、企業内での肩書き(たとえば常務、上級アナリスト、VP)、企業内での役割/企業との関係(たとえば委員会のメンバー、ベンダー、クライアント)、あるいはP&Lグループに資産を関係付ける資産関係タイプがADb内に組み込まれている。

この構造は、企業のセグメントを比較的容易に分類したり、フィルタにかけたり、あるいはグループ化したりする柔軟性と共に、資産の割り当ておよび保守を容易にするための共通のセマンティックベースを用いてユーザに力を与える。これのみの利点は多いが、それらの中でも最たるものは、企業のアーキテクチャーの明確な青写真、および資格によって推進され規定される整然としたシステムである。

ADbは、物理的な資産および仮想資産の一覧としての役割を果たすことに加えて、資産に対する所有権およびアクセスが資格に基づく程度にまで組織的な基準を規定する。この責任によって、企業レベルでのさらに高い透明性およびデータコントロールが可能となり、アプリケーションの統合がさらに容易になり、データがさらに同期化され、ドキュメントを保存するコストがさらに低減され、ナビゲーションおよび検索が向上し、業務上のリスクに対するコントロールが改善され、データの管理に対する責任が高まり、タスク/データの冗長性が低減される。

ADbは、組織のイントラネットを通じて組織内のすべての従業員にとってアクセス可能とすることができ、あらゆる部署によって活用することができる。ユーザは、ADb内のデータの完全性および正確さを信頼することができ、共通のボキャブラリーを通じてデータにアクセスすることができる。ADbは、組織全体にわたってさまざまな信頼できるデータソースからデータ供給を受けることによって、自分のデータを最新の状態に維持する。それぞれの信頼できるデータソースは、自分のデータ供給の正確さに責任を持つ。信頼できるデータソースは通常、自分自身の目的から情報を収集し、したがって、自分のデータ供給の正確さを保持するための内在するインセンティブを有する。たとえば人事部(human resources (HR))は、組織内のすべての従業員の正確な最新のリストを保持するためのインセンティブを有する。これは、自分の機能を果たす上で、そのようなリストが必要なためである。同時にHRは、組織内の他の部署に対してそのリストにアクセスすることを許可することに消極的である可能性があり、あるいは、リストを保持するためのカスタムアプリケーションを使用している可能性もあり、これには、カスタムインターフェースが必要となる。従業員リストをHRからADbへとロードすることによって、HRアプリケーションへのカスタムインターフェースを構築することなく、HRデータのインテグリティーを保持しながら、組織内のあらゆる人が、従業員の最新の正確なリストにアクセスできるようになる。この例においては、HRが、ADb内の人の一覧に関する信頼できるデータソースである。

ADbは、信頼できるデータソースから新たなデータ供給を受けた場合は常に、現在の一覧を新たな一覧と比較し、その一覧に対する変更にフラグを立てる例外を作成する。これらの変更は、そのような変更を知る必要がある個人やグループに自動的に配信することができる。ADbは、役割、ならびにデータ供給と、通知を受ける人々の役割との間における関係に基づいて、変更通知用のEメールリストを自動的に作成する。

変更によって、資産の所属先が不明になる状況が生じることもあり、ADbは、そのような状況を識別し、改善することができる。説明に役立つ例として、あるアプリケーションを管理している人が組織を去った場合に、ADbは、HRからの次のデータ供給において例外を作成する。ADbはまた、所属先が不明になったアプリケーションを識別し、そのアプリケーションのための新たなマネージャーを指名しなければならない旨をそのアプリケーションの責任者に通知する。ADbは、そのアプリケーションおよび関係タイプAccounts_Forにフィルタをかけることによって、そのアプリケーションの責任者が誰であるかを検索することができる。ADbは、そのアプリケーションのためのマネージャーを指名するためのリマインダをその人のウェブページに追加することができる。その人が所定の期間内にマネージャーを指名しない場合には、ADbは、その人のネットワーク権限の使用を制限し、タスクが完了していない旨をその人のマネージャーに通知することができる。このようにして、指揮系統内の次なるより上位の権限者に適切に上申することによって、ADb内の不整合が迅速に改善される。資産を組織の階層に結び付ける役割および関係によって、それぞれの資産に関する適切な責任系統が確かなものとなる。

ADbは、資格付与システムを含み、この資格付与システムによって、アドミニストレータおよびマネージャーは、組織内における従業員の役割に基づいてアクセス権限を割り当てることができる。資格付与システムは、コンプライアンスおよびセキュリティーの指標を組み込むことができ、それらの指標は、たとえば管理機能、地理的位置、適法性、肩書き、P&L、あるいは企業内での役割/企業との関係など、特定の割り当てられた基準に基づいて自動的にインスタンス化される。ADbの透明性によって、部署レベル、部門レベル、および全体レベルでの監査が容易になる。

ADb内へ組み込まれる資格付与システムの説明に役立つ例として、VPの肩書きを有し、ある部署のCAOとしての役割を果たし、サンフランシスコオフィスに勤務し、全社経営幹部運営委員会の委員を務めている従業員は、その役割に従ってさまざまなリストおよび資格に関連付けられる。たとえばVPとして、この従業員は、特定の特別に許可された会社情報にアクセスするための権限を有することができる。CAOの役割は、その部署に関する予算データを見ること/変更することなど、さまざまな資格をこの従業員に与えることができる。この従業員は、サンフランシスコオフィスに影響を及ぼす問題に関するEメールの警告を受信することができ、委員会のオンラインフォーラムに対するメンバー資格を有することができる。資格は、雇用、昇進、あるいは地位および/または役割の変更に際して割り当てることができる。資格はまた、資産の資格の割り当てや変更を行うことができる従業員を識別する。

資格を使用して、組織のドキュメントをより効率よく管理することもできる。電子ドキュメントは、従業員の個人のネットワークドライブ上に保存されている場合が多く、通常は、それらを見ることに関心のある資格を持った当事者にEメールで送信される。いくつかのドキュメントは、共有されているエリアにコピーされ、そこでは、同じチームまたは部署の人々がそれらのドキュメントにアクセスすることができる。あるいは、ディスカッションスレッドおよびドキュメントライブラリを格納するために、仮想ルームを作成することもできる。しかし仮想ルームは、アドミニストレータが保持しなければならない。

ADbは、それぞれの資産に割り当てられる関係の種類を拡大することによって、これらのドキュメント管理機能を拡張することができる。ADbは、さまざまな関係を反映するドキュメントのための名前付きのストアを提供し、企業内での役割に基づいてそれらのストアのための資格を設定することができる。説明に役立つ例として、ある部門の監査役は、その部門内での監査ポリシーに関連するすべてのドキュメントにアクセスできるかもしれない。同様に、ある部署のマネージャーは、その部署内のすべての勤務評定にアクセスすることができ、あるいはコストイニシアチブチームのメンバーは、そのイニシアチブに関連するドキュメントを開くことができる。

ある従業員が新たな役割を引き受けた場合には、すべてのドキュメントストアに関する資格が、その役割を用いて識別される他のすべてのツールと共にADbによって自動的に更新されて、その従業員の新たな役割が反映される。自動的に資格が更新される結果、Eメールで送信されて余分に共有されるドキュメントが少なくなり、その一方で余分な保存コストが節減される。自動的に更新されることによって、フォルダへのアクセスに対する絶え間ない承認および不承認に苛まれているサーバアドミニストレータの作業負荷が軽減される。必要とされているドキュメントを見つけ出そうとする際の効率の悪さが低減され、また同様に、未許可の個人にドキュメントをさらすことに関連するリスクも低減される。

組織は通常、ポリシーを義務付け、それらのポリシーは、従業員にそのさまざまな役割において影響を与える。ポリシー当局は、ポリシーを実施し、コンプライアンス、監査、および人事から、ビジネスコンティニュイティーおよびセキュリティーエンジニアリングなどのあまり目立たないものまで多岐にわたり、アプリケーションおよび開発者のための要件を決定づける。すべての従業員が、データベース内に列挙されているマネージャーを有するように、およびすべてのアプリケーションが、テクニカルマネージャーを有するように要求するデータポリシーも実施される。

それぞれのポリシーは、ケースバイケースで施行することができる。いくつかのポリシーは、ドキュメントが配布され、すべての項目に記入され、回収されることを必要とするかもしれない。他のポリシーは、明確であり、十分に伝わるものの、コンプライアンスを確かなものにするためのメカニズムが欠けている。これまでは、所与のポリシーに従う責任がある従業員にとって、自分がその要件を満たしているかどうかを判断することは困難であった。

ADbは、集中化されたポリシー管理フレームワークを提供し、これによってポリシー当局は、所与のポリシーに従っていない人々や資産を識別するための定義を設定する。このシステムは、問題を解決する責任がある人を識別することができ、そして組織内のその人、おそらくはマネージャーやアドミニストレータには、概要のレポートが提供される。

ポリシーを施行するための配信メカニズムは、通常は組織のイントラネットである。ある従業員がブラウザを起動すると、タイムフレームおよび従わなかった場合の結末など、その従業員が解決しなければならないポリシーの要件を列挙したナゲットを含むページが表示される。結末は、権限の取り消しや、管理階層内におけるより上位の人物への上申を含むことができる。

説明に役立つ例として、ビジネスコンティニュイティーが、すべての従業員に自分の連絡先情報を3カ月ごとに更新または確認するよう求めるポリシーを設定すると仮定する。ある従業員の最後の更新が6カ月を超えた場合には、ADbは、例外条件を作成する。これによって、その従業員のマネージャーに通知が送信され、その一方で、その部門のマネージャーおよびBCPの責任者には、概要のレポートが提供される。ADbは、このような問題が解決するまで、その従業員がオンラインコンテンツにアクセスするのを拒否するように構成することもできる。

ポリシーと、例外と、ポリシー当局との間における相互接続がADbによって保持されるため、ADbは、部署、建物、あるいはデータベース内で利用可能な他の任意のパラメータによってグループ分けされた例外条件の最新の報告を提供することができる。

所与のポリシーの有効性を測定するために指標を作成することができる。いくつかのポリシーは、その指標が、組織の一覧内の資産を単純に追跡把握して、経時的な変化を報告するよう要求することができる。他のポリシーは、ポリシーの例外を数えて、経時的な変化を報告するよう要求することができる。

指標は、範囲の点で、透明性があり、最新のものであり、完全なものであるべきである。ADbによって提供されるデータパラメータの全体にわたる分類および標準化によって、ADb内に含まれる資産の透明性を伴ったデータマイニングが可能となり、これらの指標の計算が容易になる。計算された指標は、ADbと同様に最新で完全なものである。

図1は、本発明のいくつかの実施形態におけるデータモデルを示す図である。図1においては、4つのデータタイプが、組織や企業内のそれぞれの資産を特徴付けるテーブルとして示されている。

資産タイプテーブル110は、ADb内のそれぞれの資産タイプを定義する。資産タイプテーブル110内のそれぞれのレコードは、1次キー115と、それぞれの資産タイプを定義する複数のフィールド117とを含む。図1に示されている例においては、1次キー115は、Asset_Type_IDとラベル付けされ、それぞれの資産タイプごとに一意である。Asset_Type_Nameは、それぞれの資産タイプに割り当てられる名前である。Asset_Groupは、管理を容易にするための資産タイプの集合を指す名前である。Allow_Createは、その資産タイプの一覧が手動で作成されるか、または自動的に作成されるかを示すフラグである。Descriptionは、資産タイプの簡単な説明である。Code_Numonicは、その資産タイプの短いアルファコードプレフィックスである。たとえば「div」は、部門資産タイプを表すコードニーモニックとすることができる。Data_Sourceは、一覧や資産のソースを示す。Tech_Contactは、一覧の供給の所有者を示す。Load_Frequencyは、ADbに対するその供給の更新の頻度を示す。他のフィールドを資産タイプテーブル内に含めることもでき、それらのフィールドも本発明の範囲内に収まることを意図しているという点を理解されたい。たとえば資産タイプテーブル110は、その資産タイプを有する資産情報を表示するために使用されるHTMLドキュメントを指すデフォルトのURLを含むフィールドを含むことができる。

役割タイプテーブル130は、ADb内の資産に割り当てることができるそれぞれの役割タイプを定義する。図1でRole_IDとラベル付けされている1次キー135は、それぞれの役割タイプの一意のIDを提供する。複数のフィールド137は、それぞれの役割タイプを定義し、その役割を短く記述したものであるRole_Nameを含むことができる。反対の役割を示すために、Contra_Roleを役割タイプテーブル130内に含めることもできる。たとえば「Manages」という名前の役割タイプは、「Managed by」という名前の反対の役割を有し、その逆もまた同様である。役割は、資産関係タイプを介して2つの資産タイプをリンクする。

資産関係タイプテーブル150は、ADb内の資産タイプどうしの間において認められる関係を規定するそれぞれの関係タイプを定義する。資産関係タイプテーブル150は、関係タイプに関する一意の識別子を提供する1次キー155を含む。資産関係タイプテーブル150はまた、関係タイプを定義する複数のフィールド157を含む。資産関係タイプテーブル150は、Asset_Type_IDと、Role_IDと、2つの資産タイプの間における関係を定義するRelated_Asset_Typeとを含む。Asset_Type_IDおよびRelated_Asset_Typeの双方は、資産タイプテーブル110内で定義される資産タイプを記述する。Role_IDは、役割タイプテーブル130内で定義される役割タイプを記述する。資産関係タイプテーブル150は、所有者、または関係タイプの作成を要求した人を記述するOwnerフィールドを含むこともできる。Mandatoryフィールドは、ヌル値が認められるかどうかを示すフラグを含む。Descriptionフィールドは、資産関係タイプの簡単な説明を含むことができる。

資産タイププロパティテーブル170は、資産タイプのプロパティを定義し、プロパティタイプに関する一意の識別子を提供する1次キー175を含む。図1に示されている例においては、1次キー175は、資産タイプを記述するAsset_Type_IDと、資産プロパティを記述するProperty_Nameとを含む。1次キーフィールド175内でAsset_Type_IDとProperty_Nameとがペアになることによって、プロパティタイプに関する一意の識別子が提供される。資産タイププロパティテーブル170はまた、資産プロパティを記述する複数のフィールド177を含む。ヌル値が認められるかどうかを示すMandatoryフィールドを含むことができる。Descriptionフィールドは、資産プロパティの簡単な説明を含むことができる。ownerフィールドは、資産タイププロパティの所有者を示すことができる。

図1に示されているテーブル110、130、150、および170のそれぞれは、パフォーマンスを高めるための、監査の追跡把握を提供するための、あるいはADbの全体的な堅牢性を提供するためのさらなるフィールドを含むことができ、これらも、本発明の範囲内に収まるものと理解されたい。図1に示されている4つのテーブルは、ADb内のそれぞれの資産を特徴付ける典型的なデータモデルを形成している。それぞれの資産を記述することに加えて、それぞれの資産は、階層構造、好ましくは組織の内部構造を反映する階層構造へとマップすることができる。

図2は、本発明のいくつかの実施形態において使用できる階層構造を示す図である。図2に示されている典型的な組織構造においては、部門(Division)210は、組織階層のトップレベルの管理単位に相当する。この組織は、1つまたは複数の部門を有している可能性がある。部署(Department)220は、組織構造の第2レベルの管理単位に相当する。部署は、地域や事業単位を表すことができ、組織の構造を反映することが好ましい。部門210を部署220へつないで点で終わるライン215は、部門210と部署220との間における多対一の関係を示している。図2においては、部署220の終端の点は、部門210が、少なくとも1つの部署220を含むということを示している。部門210と部署220との間における関係を記述する別の方法は、a Division Consists Of Departmentsである。その逆が、a Department Belongs To a Divisionである。図2に示されている構造においては、「Consists Of」は、部門を部署に関係付ける役割である。同様に「Belongs To」は、部署を部門に関係付ける役割である。「Belongs To」という役割は、「Consists Of」の反対の役割であり、その逆もまた同様である。

図2に示されている組織階層内で部署の下にあるのが、P&Lグループ230という管理単位である。好ましい一実施形態においては、P&Lグループは、組織の財務構造内の予算編成単位に相当する。P&Lグループ230は、多対一の関係で部署にBelongs Toする。逆に部署は、P&LグループからConsists Ofされる。役割の推移的な性質のために、P&Lグループはまた、部門にBelongs Toし、部門は、P&LグループからConsists Ofされる。

組織階層の基礎をなすのが、人240である。人は、P&LグループにBelongs Toし、したがって部署220および部門210に所属しなければならない。好ましい一実施形態においては、人240は、1つのP&Lグループ230だけに直接所属する。

たとえばビジネスエリアなど、組織階層内の別の組織レベルを可能にするために、任意選択の特別グループ250をその階層内に含めることができる。

リーガルエンティティー270は、P&Lグループ230からConsists Ofされる。リーガルエンティティーとは、何らかの方法で組織にリンクされている法的に登録された企業である。好ましい一実施形態においては、リーガルエンティティー270は、組織の総勘定元帳から取られる。

組織階層は、地理的な階層を含むこともできる。たとえば図2は、それぞれのP&Lグループが地域260にBelongs Toしていることを示している。いくつかの実施形態においては、地理的な階層を使用して、場所を資産に添付することができる。図3は、本発明のいくつかの実施形態において使用される地理的な階層を示す図である。図3においては、トップレベルの地理的なエンティティーは地域310であり、これは、少なくとも1つの国320から構成される。それぞれの国320は、少なくとも1つの都市330から構成され、それぞれの都市330は、少なくとも1つの建物340から構成される。それぞれの建物340は、少なくとも1つの場所350から構成され、それぞれの場所は、少なくとも1人の人360から構成される。

メタデータおよびマッピング構造が定義されると、資産および組織構造を記述する資産タイプ、プロパティタイプ、役割、および関係タイプを作成することによって、ADbを実装することができる。下記のテーブル1は、図2および図3に示されている組織構造を記述する資産タイプを示している。

テーブル1に示されている資産タイプは、Allow_Createフラグが、テーブル1に示されている資産タイプを有する資産の手動による作成を認めないように設定されている。これは、これらの資産タイプが場当たり的に作成されるのを防止するために行われている。というのも、これらの資産タイプは、組織の構造を表すためである。

Data Source列内の項目は、テーブル1に示されている資産タイプの資産を作成するための信頼できるソースを識別する。テーブル1においては、HR(Human Resources)が、人やP&Lグループの資産を作成するための信頼できるソースである。HRは、すべての人の資産に関する信頼できるソースであると想定される。というのも、HRは、自分の割り当てられた機能を果たすために、組織の全従業員の正確な、最新の、包括的なリストを保持しなければならないためである。HRは、すべての従業員の完全な最新のリストを保持するために自分のリソースを費やす動機およびインセンティブを有する。というのは、自分のその他の割り当てられたタスクを完了するために、その情報が必要だからである。HRはまた、そのリストに対する改ざんのリスクを減らすために、そのリストへのアクセスを防止するインセンティブを有する。組織内の従業員の完全なリストへのアクセスを求める他のグループは、そのリストにアクセスするための許可をHRから与えられなければならず、また従業員リストにアクセスするためにHRによって使用されている特定のデータベース管理システムについて学ばなければならず、そのデータベース管理システムは、要求側の部署によって使用されているDBMSとは異なる可能性がある。

本発明の利点のうちの1つは、組織内のすべてのグループがADbを通じて情報にアクセスするために使用する全体にわたる分類である。さらに、たとえばHRなどの信頼できるソースからの一覧の供給を更新することによって、ADbのユーザは、たとえば自前の従業員リストを作成するために自分自身のリソースを費やすことなく、情報の正確さ、適時性、および完全性を信頼することができる。ADbへの一覧の供給を更新することによって、信頼できるソースのリストのデータが改ざんされるリスクも少なくなる。というのは、情報が、信頼できるソースのリストから直接ではなく、ADbを通じて、組織の残りの部分に供給されるためである。

財務部も、従業員の完全な最新のリストを保持することができ、また人の資産に関する信頼できるデータソースとして機能することもできる。たとえば、HRが財務部よりも先に変更を通知されると予想される場合など、更新の容易さや反応のよさなどの要因に応じて、信頼できるデータソースを選択することができる。いずれにしても、HRおよび財務部は双方とも、人の一覧に関する信頼できるデータソースである。これは、双方の部署が、従業員の正確な最新のリストを保持するインセンティブを有するためである。

信頼できるデータソースのロード頻度が、テーブル1の最後の列に示されている。テーブル1によれば、人およびP&Lグループの一覧は、HRのデータソースから毎日更新される。これとは対照的に、都市、国、および建物の一覧は、定期的な頻度では更新されない。というのも、これらの資産は、人やP&Lグループの一覧ほど頻繁には変更されないと予想されるためである。

テーブル2は、人という資産タイプに関する資産プロパティタイプの部分的なリストである。テーブル2のリストは、すべてを網羅したものではなく、人の資産を記述するために使用できるプロパティのタイプを示している。テーブル2が示しているように、それぞれの人の資産は、人の名前、肩書き、Eメールアドレス、Eメールホスト、電話番号、従業員のステータス、その人のコンピュータのサブネットワーク、およびその人の事業単位を記述するプロパティを含むことができる。それぞれのプロパティタイプはまた、そのプロパティが必須かどうか、およびそのプロパティのデータタイプ(文字列、数字、フラグなど)を示す。

テーブル3は、本発明のいくつかの実施形態において使用できる役割およびその反対の役割の部分的なリストである。テーブル3のリストは、すべてを網羅したものではなく、関係タイプを定義するために使用できる役割のタイプを示している。

テーブル4は、1つの資産タイプを別の資産タイプと結び付けるために使用できる関係タイプの部分的なリストである。テーブル4のはじめの3つの項目は、資産を、図2に示されている組織構造へとマップする関係タイプを定義し、ここでは、部門は、少なくとも1つの部署から構成され、部署は、P&Lグループから構成され、P&Lグループは、人から構成される。テーブル4の4番目の項目は、反対の関係を定義するための反対の役割の使用を示しており、この場合、人がP&Lグループに所属することを(必須フラグによって示されているように)必要とする関係を定義している。テーブル4の5番目から7番目の項目は、資産タイプが別の資産タイプに対して並行して有することができるさまざまな役割を示している。テーブル4に示されている例においては、人は、P&Lグループを管理したり、責任を負ったり、あるいは所有したりすることができる。管理する役割においては、人は、P&Lグループの資産タイプに関する特定のプロパティや関係に対して承認や変更を行うことによって、その資産タイプを保護することを担当することができる。いくつかの実施形態においては、いくつかのプロパティおよび関係を制限することができ、それによって、指定された人のみがそれらの変更を行うことができ、資産の所有者やマネージャーがその資産タイプのその他のプロパティおよび関係を変更できるようにすることができる。「責任を負う」役割においては、人は、P&Lグループの資産に責任を負う予備の人とすることができる。「所有する」役割においては、人は、P&Lグループの財務上の所有者とすることができる。テーブル4の最後の項目は、アプリケーションにおける変更が行われた場合に人に通知できるようにする関係タイプを示している。

テーブル1〜4の項目は、すべてを網羅したものではなく、項目を適切なテーブル内に追加することによって、他の資産タイプ、役割、プロパティ、および関係タイプを作成することができるという点を理解されたい。資産タイプ、役割、プロパティ、および関係タイプは、組織内のあらゆる資産を記述するための組織全体にわたる共通の言語を定義し、組織の資産に関する正確な最新の情報に対する透明性を伴ったアクセスを提供する。

資産タイプ、役割、プロパティ、および関係タイプを作成したり、削除したり、あるいは修正したりする資格のある個人や個人のグループを定義することによって、資格付与の階層的なシステムをADb内に実装することができる。いくつかの実施形態においては、資格付与システムは、図4に示されているような資格関係テーブルによって定義することができる。図4においては、資格関係テーブル400は、1次キー415と、資格を記述する少なくとも1つのフィールド417とを含む。図4においては、Group_Nameは、資格を有する個人のグループを識別する。Group_Nameは、たとえば特定の部署内のすべてのCAO(Chief Administrative Officer)やすべてのアプリケーションマネージャーを含むことができる。Web_User_IDは、資格を有する特定の個人を識別する。資格は、個人や個人のグループが、具体的に識別された資産や資産のグループを修正することを可能にすることができる。Source_Asset_TypeはAsset_Typeを識別し、Source_Asset_Codeは特定の資産を識別する。Rel__Typeは、元の資産と目的の資産との間における関係を識別する。Dest_Asset_TypeはAsset_Typeを識別し、Dest_Asset_Codeは特定の目的の資産を識別する。

データモデルおよび組織の構造が定義されると、ADbは、組織の資産の一覧を受け取ることができる。それぞれの資産は、資産テーブル内の項目を介してADbへと入力される。図5は、本発明のいくつかの実施形態における資産テーブルを示す図である。図5においては、資産テーブル500は、1次キー515と、資産を記述する少なくとも1つのフィールド517とを含む。Asset_IDは、ADB内の資産に関する一意の識別子を提供する1次キー515である。Asset_Type_IDは、資産の資産タイプを記述し、資産タイプテーブル内の資産タイプのうちの1つから選択される。Asset_Nameは、資産に割り当てられている名前であり、Descriptionは、資産の簡単な説明である。Short_Nameは、その資産タイプの全領域にわたって一意の名前である。Asset_Codeは、他のアプリケーションに公開されている資産に関する一意の識別子である。それぞれの資産は、特定の資産に関連付けられていてプロパティ値のペアとして保存されているゼロ以上のプロパティを有することができる。同様に、それぞれの資産は、他の資産に対するゼロ以上の関係を有することができる。

図6は、Adb内における部門一覧の作成を示す流れ図である。ステップ610においては、新たな部門を求める要求が、財務部によって受信されて処理され、そのデータベースへと入力される。その要求のコピーが、ステップ620においてポータルエンジニアリングへ転送され、このコピーは、要求者の名前、ユーザーフレンドリーな名前、およびそれぞれの地域ごとの重要な役割を含むことが好ましい。重要な役割は、マネージャー、CAO、財務代表、およびアドミニストレータとすることができる。新たな部門を財務部のデータベースへと追加すると、ステップ625においてポータルエンジニアリングへの例外の報告が生じる。図6に示されている例においては、部門の資産に関する信頼できるデータソースは財務部である。部門の資産に関する財務部など、信頼できるデータソースからADbが更新されると、財務部のデータベース内の新たな部門によって例外が生じる。というのは、その新たな部門がADb内にないためである。通知の後に、ポータルエンジニアリングは、その部門の資産タイプの所有者として、その部門の資産をADb内に作成するが、その資産を、組織のイントラネット上に表れないように非アクティブなステータスに設定する。ステップ620および625が完了すると、ポータルエンジニアリングは、ステップ630において、すべての地域に関して財務部によって提供された重要な役割を割り当てる。ポータルエンジニアリングはまた、すべての地域のCAOおよびアドミニストレータへ、彼らの地域のページコンテンツおよび役割を更新するための要求を送信する。地域のCAOの役割は、その地域のページコンテンツを更新する資格を人に与え、その地域のCAOが、その地域の1人または複数のアドミニストレータに同じ資格を与えることを可能にすることができる。これに応じて、対象の地域内における地域のCAOやアドミニストレータは、ステップ640において地域の部門ページを更新し、ステップ645においてその部門内の残りの役割を更新する。ステップ640および645が双方とも完了すると、地域のCAOは、ステップ650において、地域の部門のイントラネットページをアクティブ化するための要求をポータルエンジニアリングへ送信する。ステップ660においては、ポータルエンジニアリングは、部門ページをアクティブ化して、組織のイントラネット内からそれらのページへアクセスできるようにする。

図7は、本発明の一実施形態における地域の部門ページを示す図である。地域の部門ページ700は、HTMLページとして保存することができる。地域の部門ページ700は、管理ナゲット710の表示を含み、この管理ナゲット710は、その部門の重要な役割のメンバーの地域のビューを表示する。表示される地域のビューは、人をワークステーションへ、人をP&Lグループへ、およびP&Lグループを地域へリンクする関係の連鎖を通じてフィルタリングを行うことによって決定することができる。重要な役割のメンバーは、管理の役割をフィルタリングして対象の地域のマネージャーのみを表示することによって決定される。部署ナゲット720は、その部門に関連する部署の地域のビューを表示する。部署リストの地域のビューは、対象の地域に関係付けられている関連したP&Lグループに対してフィルタリングを行うことによって決定することができる。中央のナゲット730および右側のナゲット740は、その組織に関して部門/地域に固有のコンテンツを表示する。部門の所有者は、中央のナゲットおよび右側のナゲット内に表示されるコンテンツを作成し、所有する。

資産は、手動で、あるいは信頼できるデータソースからのデータ供給から作成することができる。信頼できるデータソースは、資産のグループを保持して責任を負う任意のグループとすることができる。たとえば不動産グループは、その組織によって占有されている不動産のリストを保持することに責任を負うことができ、あるいはネットワークインフラストラクチャーグループは、ネットワーク上のハードウェアに責任を負うことができる。それぞれのグループは、自分の資産を保持するために専門のアプリケーションを使用することができる。それぞれのグループの資産情報を含むデータ供給が、そのデータの動的な性質に応じて定期的に、あるいは要求に応じてADbへ送信される。たとえば、すべての従業員については、HRからの自動化されたデータ供給から日常的に入力することができる。というのも、従業員は、任意の所与の日に雇用されたり、退職したりするためである。その一方で、不動産グループは、要求に応じてのみ、データ供給を提供することができる。というのも、建物のリースにおける変更は、頻繁には生じないためである。データ供給は、たとえばCSV(comma separated variable)など、ADbにとって公知のフォーマットでグループのアプリケーション上で作成されたシンプルなレポートとすることができる。

ADbは、容易に拡張することができ、新たなグループに対応するように新たなデータ供給を作成することができる。たとえばビジネスコンティニュイティープランニング(BCP)グループは、既にADb内にある情報を活用することができ、BCPの資産を含むデータ供給を作成することによって、その情報を組織にとって利用可能にする。BCPの資産は、そのBCPの資産をサポートするために作成できる資産タイプ、役割、および関係によって特徴付けられる。

ADb内に保存されている役割および関係を使用して、ADb内の情報を強化し、活用することができる。たとえば図8は、ADb内の既存のデータを活用する名簿アプリケーションに対する有用な機能強化を示すウェブページ、あるいはダッシュボードである。図8は、組織の人物検索アプリケーション内における検索結果ページとして従業員のプロファイルを提示している。このダッシュボードは、従業員の名前810、任意選択の写真812、連絡先情報814、および場所816を表示しており、これらは、シンプルな名簿アプリケーションにおいて通常求められるものである。従業員プロファイル800はまた、組織階層820を含み、この組織階層820は、その従業員のP&Lグループ、部署、および部門を表示する。組織階層820は、その従業員、ならびにその従業員とP&Lグループとの関係に関してADbにフィルタリングを行うことによって投入することができる。報告関係ナゲット830は、その従業員のスーパーバイザと、その従業員に直接報告を行う従業員とを表示し、その従業員、ならびに関係タイプ、Manages、およびManaged Byに関してADbにフィルタリングを行うことによって投入することができる。役割ナゲット840は、組織内におけるその従業員の役割を表示する。共有ドキュメントナゲット850は、その従業員がアクセスしたり修正したりする資格を有するドキュメントを表示し、その従業員の資格に関してフィルタリングを行うことによって投入することができる。メンバーシップナゲット860は、グループおよび委員会におけるその従業員のメンバー資格を表示し、組織内におけるその従業員の複数の役割に基づいている。従業員プロファイル800は、さまざまな信頼できるデータソースからの正確な最新のデータをありのままに活用し、透明性を伴ってそれらのデータを組み合わせて有用な情報を作成するというADbの有用性および威力を示している。

図9は、ユーザが管理タスクを完了しなければならない場合に常に表示できるリマインダ通知900のスクリーンショットである。リマインダ900は、信頼できるデータソースからのデータ供給によって作成された例外レポートからADbによって自動的に作成することができ、ユーザの役割および関係に関してフィルタリングを行うことによってユーザに宛てることができる。図9に示されている説明に役立つ例においては、リマインダ通知900は、さらなる詳細、および完了していないタスクを完了させるためのリンクのために、ユーザのホームページ上のリマインダナゲットへとユーザを導く。タスクが所定の時間内に完了しない場合には、リマインダ通知は、さらなる警告を伴って変わることができる。

図10aは、管理ナゲット1010を表示するホームページ1000の典型的な図である。図10bは、図10aに示されている管理ナゲットの詳細を示している。図10bにおいては、管理ナゲット1010は、従業員が完了しなければならないタスクリマインダを列挙している。それぞれのタスクリマインダは、期日すなわち締め切り1012と、リマインダの簡単な説明1014と、ユーザがその管理タスクを完了することができるページへのリンク1016とを含む。それぞれのリマインダは、このユーザの役割に基づいて、このユーザに宛てられている。説明に役立つ例として、パフォーマンスゴールリマインダ1020が、所定の期間内に自分のパフォーマンスゴールを達成していない従業員のマネージャーとしての役割に基づいて、このユーザに宛てられている。このユーザは、その従業員のManaged Byの関係に関してADbにフィルタリングを行うことによって、その従業員のマネージャーとして識別されている。その従業員が所定の期間内に対応しなかったため、パフォーマンスゴールリマインダ1020は、その従業員の指揮系統に沿ってリマインダを上申している。スーパーバイザへのこのリマインダは、そのスーパーバイザ、この場合はこのユーザに対して、その従業員に自分のパフォーマンスゴールタスクを迅速に完了するよう促すことを推奨することができる。このようにして、従業員の管理者を巻き込むことによって、ADb内におけるいかなる不足データや不整合も迅速に解消される。さらに、従業員のスーパーバイザを見つけ出すタスクは、ADbによって処理される。というのも、組織の管理構造は、ADbの構造内に既に組み込まれているためである。

ビジネスコンティニュイティーリマインダ1030は、ユーザの緊急連絡先情報を更新または確認するようユーザに要求する。ビジネスコンティニュイティーリマインダ1030は、組織のためのビジネスコンティニュイティーのプランニングに責任を負うビジネスコンティニュイティープラン(BCP)グループによって作成することができる。BCPグループは、BCPを最新の状態に保つためにあらゆる従業員が自分の緊急連絡先情報を定期的に確認または更新すべきであるとするポリシーを有することができ、このユーザは、組織の従業員としての自分の役割を通じてこのリマインダを受信している。このポリシーは、連絡先情報を常に最新の状態にしておくために、必要に応じて従業員のスーパーバイザを巻き込こんで、そのポリシーの「施行」にADbを利用することによって、実施することができる。BCPグループは、それぞれの従業員に関するスーパーバイザのリストを自前で保持する必要はない。というのも、その情報をADbから利用することができ、その情報が正確で完全であると信頼することができるためである。

新従業員リマインダ1040が、新たな従業員に関するさらなる情報を提供するために、P&Lグループのマネージャーとしての役割を通じて、このユーザに宛てられている。新従業員リマインダは、HRからの人の一覧のデータ供給の日常的な例外レポートから自動的に作成することができる。新たな従業員は、雇用されてP&Lグループを割り当てられた際に、HRアプリケーションに追加される。日常的なデータ供給の最中に、ADbは、そのデータ供給を、自分の既存の人の一覧と比較し、その新たな従業員がADbの既存の人の一覧内にないため、例外を作成する。その新たな従業員のP&Lグループの割り当てを使用して、ADbは、その新たな従業員のP&Lグループのマネージャーへのリマインダを自動的に作成することができる。

好ましい一実施形態においては、データ供給がADbによって受信された場合は常に、ADb内のモジュールが実行される。このモジュールは、そのデータ供給をADb内の既存の一覧と比較し、変更された資産を識別する例外レポートを作成する。このモジュールは、それらの変更された資産に対するすべての関係が依然として有効であることを確認することもできる。あるP&Lグループに新たな従業員が加わったこの例においては、そのP&Lグループのマネージャーは、その新たな従業員の最初の処理を完了するよう督促される。その新たな従業員の最初の処理は、たとえば、そのP&Lグループによって所有されるアプリケーションに対する責任、そのP&Lグループによって参加を求められる特別グループのメンバー資格、あるいはそのP&Lグループ内の他の従業員の監督など、その従業員を組織内の他の資産に結び付けるその新たな従業員とADbとの関係を追加することを含むことができる。このモジュールは、そのP&Lグループおよび適切な関係タイプに関してADbにフィルタリングを行うことによって、そのP&Lグループのマネージャーを識別する。このモジュールは、そのP&Lグループのマネージャーにリマインダを送信することができ、このリマインダは、必要とされる情報をそのマネージャーがADbに提供することができるウェブページへのリンクを含む。

T&Eアプルーバリマインダ1050が、P&Lグループのアドミニストレータとしての役割を通じて、このユーザのホームページスクリーン上に表示されている。リマインダ1050は、提供されているリンクへ進んで、このユーザが管理しているP&Lグループにマネージャーを割り当てるよう、このユーザに要求する。リマインダ1050は、自動的に作成することができ、そのP&Lグループを管理していた従業員がそのグループを去ったこと、あるいはそのP&Lグループが新たなグループであることを理由に現れることができる。従業員がグループを去った場合には、HRからの日常的な供給が例外を作成し、新たなP&Lグループが作成された場合には、たとえば財務部など、P&Lグループに責任を負うグループからのデータ供給が例外を作成する。いずれにしても、ADbは、信頼できるデータソースからのデータ供給に基づいて例外を作成する。例外レポートを作成することによって、ADbは、信頼できるデータソースプロバイダを、変更によって影響を受ける可能性のある組織内のグループに通知を行う義務から解放する。

部署リマインダ1060が、ある部門のCAO(Chief Administrative Officer)としての役割を通じて、このユーザのホームページスクリーン上に表示されている。リマインダ1060は、提供されたリンクへ進んで、マネージャーをその部署に割り当てるよう、このユーザに要求する。リマインダ1060は、自分のそれぞれの信頼できるデータソースからの人や部署の一覧のデータ供給からの例外から、ADbによって自動的に作成することができる。

この例においては、信頼できるデータソースからのデータ供給がADbによって受信された場合は常に、ADbモジュールを実行することができる。このモジュールは、そのデータ供給を、ADb内に存在する一覧と比較し、その一覧内のすべての変更を識別し、そのデータ供給を用いて一覧を更新する。たとえば、新たな部署がそのデータ供給内に含まれている場合には、このモジュールは、その新たな部署がデータ供給の更新の前にはADbの一覧内にないため、その新たな部署を変更として識別する。

このモジュールは、ADbをチェックして、その新たな部署に対して必要とされる関係がADb内に存在することを確認することができる。たとえば、ADb内のビジネスルールまたはポリシーは、それぞれの部署の資産が、「Managed By」の役割を伴った人の資産タイプに対する関係を含むよう要求することができる。このモジュールは、その部署の資産および「Managed By」の関係タイプに関してADbにフィルタをかけ、なぜなら「Managed By」、その関係が作成されていない場合には、ヌルの結果を得る。このモジュールは、次なるより上位の管理単位のマネージャーに、この場合は部門のマネージャーにリマインダを送信する。このモジュールは、その新たな部署の「Belongs To」の関係タイプに関してADbにフィルタリングを行うことによって、その新たな部署を含む部門がどこかを割り出すことができる。同様に、その新たな部署を含む部門および「Managed By」の関係タイプに関してADbにフィルタリングを行うことによって、その部門のマネージャーを識別することができる。あるいは、このモジュールは、その新たな部署と、部署に関する「Managed By」の関係において変更を認める資格とに関してADbをフィルタにかけて、その新たな部署のための新たなマネージャーを割り当てる権限を有する人を識別することができる。このモジュールは、そのマネージャーがその新たな部署に新たなマネージャーを割り当てることができるようにするウェブページまたはHTMLドキュメントへのリンクと共にリマインダをそのマネージャーのホームページ内に含めることができる。このモジュールは、そのウェブページからのデータを受信し、入力されたデータを用いてADbを自動的に更新することができる。このモジュールは、部門のマネージャーへ確認通知を送信することもできる。このモジュールは、シングルプロセッサ上で実行することもでき、あるいは、1つまたは複数のプロセッサ上で実行される1つまたは複数のサブモジュールから構成することもできる。

図11は、本発明のいくつかの実施形態において使用されるコンプライアンスレポートの図である。図11においては、コンプライアンスレポートダッシュボード1100が、ある部門全体のコンプライアンスステータスを表示している。このダッシュボード1100は、特定のプロジェクトのためのコンプライアンスレポートを作成するためのレポートフィルタ1110を含む。プロジェクトは、ユーザの資格に基づいて投入できるドロップダウンメニュー1115から選択されることが好ましい。オーバービューナゲット1120は、特定のプロジェクトに関する統計の概要を表示し、ユーザが部署レベルでコンプライアンスを見たり、あるいはP&Lグループレベルへと掘り下げたりできるようにする。好ましい一実施形態においては、コンプライアンスにおけるそれぞれのグループのパーセントを示すコンプライアンスパーセンテージが表示され、「問題の」グループや部署にユーザの注意を向けるために色分けされる。従っていないそれぞれの従業員のアドレスのリスト1140と、従っていない従業員のそれぞれのマネージャーのアドレスのリスト1160とを含むメーリングリストナゲットを表示することができる。ユーザは、そのリストを簡単なEメールメッセージへとカットアンドペーストすることができ、そのEメールメッセージをそれぞれの従っていない従業員、およびその従業員のマネージャーへ送信する。タスクを迅速に完了するよう従業員を動機付けるのに、その従業員の部門のマネージャーからのEメールメッセージに勝るものはなく、とりわけ、そうするように促すその従業員の直属のスーパーバイザからのメッセージによって補足されている場合は、なおさらである。それは、千金に値するかもしれない。

ADbは、ネットワーク効果を活用し、ADbの有用性は、より多くのグループが自分のデータをADbに提供するにつれて高まる。ADb内に含まれるデータの透明性によって、アプリケーションを低コストで迅速に作成することが可能になる。たとえば、組織全体にわたる活動のためのアプリケーションは、1万〜2万ドル程度で開発することができる。新たなアプリケーションは、共通のボキャブラリーを通じて既にADb内にあるデータを活用することができるため、低コストで開発することができる。ADbアプリケーションの開発者は、必要とされるデータソースを識別し、それらのデータソースにアクセスするための許可を得て、カスタムインターフェースをそれぞれのデータソースに書き込むのではなく、ADbを通じてデータに直接アクセスし、そのデータの質、正確さ、および適時性に高い信頼を置くことができる。さらに、組織全体にわたって情報を収集する活動は、それぞれの資産を組織内の1つの管理単位にマップすることを介してADb内に責任が組み込まれるために、通常は高い成功率を有する。このマッピングによって、資産に責任を負う人と、組織内での上方向および下方向の双方におけるその人の指揮系統とを迅速に識別することが可能になる。

ADb内で使用されるデータモデルは、それぞれのアプリケーションが自分自身のデータを管理できるようにし、その一方で、組織がそのデータにアクセスできるようにする。アプリケーションは、そのアプリケーションにとって一意である新たな資産タイプ、関係タイプ、プロパティタイプ、および役割を作成することができる。そのアプリケーションによって作成されるデータのコントロールは、ADbの資格を通じて管理される。次いで、ADbを活用するビジネスコンティニュイティープラン(BCP)アプリケーションの一例について説明する。

あらゆる組織は、不測の状況や災害に対処するためにBCPを有するべきである。9/11の同時多発テロによって、BCPの必要性がさらに浮き彫りになった。従業員の情報など、BCP内で必要とされる情報の多くは、既にADb内にあり、ADb内の情報を活用することによって、組織のためのBCPを作成および保持するコストを低減することができる。

Meyersらに対して2004年6月22日に発行された米国特許第6,754,674号は、危機用プランを作成するために使用されるユーザからの情報を受信するためにコンピュータネットワークを使用する対応プラン作成用のシステムおよび方法について記載している。このシステムはまた、データをシステム内へインポートすることを可能にし、危機用プランをネットワーク上に保存することができる。しかし、記載されているシステムは、危機用プランに影響を与える可能性のある組織内での変更を反映するために危機用プランをいつ更新しなければならないかを判断することや、タイムリーなやり方でプランを更新するようユーザに促すためのメカニズムを提供することができない。

Meyersは、コンティニュイティープランニングの脆弱性のうちの1つ、すなわち、それぞれのプランを最新の状態に保つことの脆弱性について説明している。最新のコンティニュイティープランニングの多くは、シナリオおよびタスクに基づくものであり、この場合のシナリオは、仮定されたものであり、プランは、その仮定されたシナリオに応答して実行されるタスクのセットとして定形化されている。BCPは、それぞれのシナリオごとに作成され、それぞれのBCPを更新しなければならない。いくつかのBCPの保守は、すぐに負担となるおそれがある。というのは、決して発生しないかもしれない事態に備えて絶え間なくプランを保守するためにリソースを費やさなければならないためである。

9/11の同時多発テロによって、タスクに基づくプランの別の脆弱性が浮き彫りになった。これらのプランは、9/11からの復旧の後半の段階中には有益であったが、復旧チームは、9/11の後の最初の数時間あるいは数日間を、状況に対応することに費やした。9/11の同時多発テロから学んだ教訓として、BCPは、復旧チームが危機に対応している復旧の最初の期間に適応できるだけの十分な柔軟性を有するべきであり、この最初の期間中に復旧チームが意思決定を行う上で必要とする正確な最新の情報を提供すべきである。

本発明のいくつかの実施形態においては、BCポータルは、組織のイントラネットを介して従業員のウェブブラウザへ、BCP情報を含むウェブページを提供することができる。BCポータルは、復旧チームに対して、アクシデントの最初の数時間中に彼らの意思決定をサポートする最新の正確な情報を提供する。BCポータルは、復旧しなければならないミッションクリティカルな資産、それらの資産を復旧すべき順序、それらの資産の場所、およびそれらの資産に責任を負う人々を識別することによって、復旧チームをサポートすることができる。BCポータルは、組織のビジネスコンティニュイティーポリシーに対するコンプライアンスを迅速に表示するトップレベルのマネージャー用の自動化されたステータスレポートを提供することもできる。トップレベルのマネージャーは、組織の最も下のレベルでのコンプライアンスを表示するために、組織の中を迅速に掘り下げることができる。

BCポータルは、それぞれの従業員に対して彼らのウェブブラウザ上に個別のウェブページを表示して、その従業員に固有のBCP情報と、BCプランまたはポリシーにおける変更に関してその従業員に教えるための新たな情報とを提供することができる。BCポータルは、人の指揮系統を検索するADbの機能を利用して、従業員へ押し出された情報が必ず確認応答されるように、およびその従業員から要求されたいかなる情報も必ず迅速に受信されるようにすることができる。BCポータルは、ADbへの信頼できるデータ供給を利用して、BCPに固有の情報を必要とする組織内のあらゆる変更を関知し、その情報を非常に低いコストで得ることもできる。

BCP内の前提が無効であると判明する最初の復旧期間中には、あらゆる従業員へ情報を押し出すことができることが望ましい。たとえばBCPは、従業員Aを、アプリケーションAの復旧を担当する復旧チームに任命することができる。アクシデントが発生したが、従業員Aが休暇中である場合や、その他の理由で対応できない場合には、ADbは、そのアプリケーションを復旧することできる従業員Aの予備要員を迅速に識別することができる。BCポータルは、アプリケーションAを復旧するために復旧場所へ出頭するよう従業員Bに命じる情報を従業員Bへ押し出すことができる。

図12は、本発明のいくつかの実施形態において使用されるBCプラン内の資産を示すブロック図である。好ましい一実施形態においては、BCプランは、部門および部署のそれぞれの地域ごとに作成される。それぞれのBCプラン1200は、そのプラン1200によって対象とされる人々1210のリストと、組織内の場所1230のリストと、組織内で使用されるアプリケーション1220のリストとを含む。それぞれのアプリケーションは、場所および人にリンクされ、それによって、そのアプリケーションを実行するサーバまたはホストの場所、およびそのアプリケーションに責任を負う人を迅速に識別することができる。同様に、それぞれの人は、場所にリンクされ、そしてアプリケーションにリンクすることができる。所定のメッセージ1240のリストもBCプラン1200内に含まれ、それらのメッセージは、プランのメンバーに対して表示または送信して、集合場所などの最初の指示を提供することもでき、あるいは、そのメッセージを受信する人の役割に従ってさらに具体的な情報を提供することもできる。緊急会議呼び出し番号1250のリストは、電話番号と、暗証番号と、アクシデントの場合に使用できるすべてのエマージェンシーコールブリッジの説明とを含むことができる。リソースの一覧1260は、復旧場所において復旧スタッフにとって利用可能なすべての資産のリストを提供する。資産は、パーソナルコンピュータ、プリンタ、ファクシミリ、補給品などのハードウェアを含むことができる。リソースの一覧1260は、復旧チームのメンバーにとってアクセス可能なウェブページ上にポストすることができ、それによって彼らは、復旧場所において自分たちにとって何が利用可能となるかが分かる。ドキュメント1270のリストは、BCコーディネータによってポストされて、復旧の取り組み中に必要とされる可能性のある部門レベルまたはビジネスに固有のドキュメントへのアクセスを復旧チームに提供することができる。

好ましい一実施形態においては、BCPアプリケーションは、適切なレコードを上述のデータモデルに追加することによって、ADbと統合することができる。たとえば、BCPLANおよびBCP_GROUPの資産タイプを資産タイプテーブルに追加することができる。それぞれのBCプランは、BCPLANの資産タイプに割り当てることができる。

BCP_GROUPの資産タイプを使用して、特定のBCプランによって関連付けられているまたは対象とされている組織の従業員をグループ化することができる。好ましい一実施形態においては、組織内のあらゆる人がBCPグループに所属するよう要求するために、ポリシーをインスタンス化することができる。従業員は、1つまたは複数のP&LグループをBCPグループに割り当てることによって、その従業員のP&Lグループを通じてBCPグループに追加することができる。それぞれのBCPグループのメンバーシップリストは、BCプラン用の呼び出しリストとしての役割を果たすことができる。いくつかの実施形態においては、あらゆる人をBCグループ内の復旧チームまたは予備チームのいずれかに割り当てることができる。ある人が予備チームに属している場合、その人は、復旧の最中は在宅で勤務する一方で、必要が生じた場合には復旧を手助けできるように待機することができる。復旧チームの人は、作業現場で復旧に加わることができ、復旧チームの人には、主要な場所および副次的な場所を割り当てることができる。復旧または予備のいずれかへの割り当ては、BCP_GROUPの資産タイプに関連付けられているフラグプロパティタイプによって示すことができる。その他のBCPグループは、通知の目的で、そのグループ内のメンバーの役割に基づいて作成することができる。たとえば、あるBCPグループは、ある部署内のすべてのマネージャーから構成されるように作成することができる。

適切な項目をADbの役割タイプテーブル内に追加することによって、いくつかのBCP固有の役割を作成することができる。たとえば、それぞれのプランには、そのプランに対する最終的な責任を有し担うBCPコーディネータを割り当てることができる。BCPコーディネータは、プランの一部またはすべてを保守する日々の責任を割り当てられる1人または複数のBCPアドミニストレータを指名することができる。プランの一部またはすべてを保守する責任を割り当てられたそれぞれのBCPアドミニストレータには、BCPコーディネータと同じプランの読み取り資格および更新資格が与えられる。BCPコーディネータは、BCPグループに割り当てられて、そのグループのための1つまたは複数のコールツリーを管理することに責任を負う1人または複数のBCPアドミニストレータを指名することができる。コールツリーを管理するだけのアドミニストレータについては、プランの他の部分にアクセスすることをBCPコーディネータによって制限することができる。部門のBCプラン用の窓口として機能するためのBCM窓口を、ビジネスコンタクトマネージメント(BCM)チームに所属する人に割り当てことができる。この窓口は、その部門内のBCプランの作成および管理における支援およびサポートを提供する。人を主要な場所および副次的な場所に関係付けるために、それぞれBCP_Primary_LocおよびBCP_Sec_Locの役割を作成することができる。この場所は、建物、階、あるいは部屋とすることができる。

それぞれのBCプランは、ユーザの役割に従ってプランのさまざまな部分を提示することができる。たとえば、あるBCPコーディネータは、プランを作成して保守するために完全なアクセスを必要とするかもしれない。このBCPコーディネータは、プランの詳細を提示するウェブページを見ることができ、このウェブページによって、そのコーディネータは、プランを修正することができる。これとは対照的に、ある従業員には、その従業員に関連する情報のみを表示するウェブページを提示することができる。トップレベルのマネージャーには、自分の管理単位の全体にわたるコンプライアンスのステータスの概要情報を表示するページを提示することができる。

図13は、BCプランによって対象とされているある従業員に関連するそのBCプランの部分を示す図である。図13に示されている表示は、従業員の役割に従ってプランからの情報を表示するウェブページ1300とすることができる。ウェブページ1300は、従業員のブラウザからの要求に応答して、BCPポータルサーバから組織のイントラネットを介して従業員のウェブブラウザへ配信することができる。好ましい一実施形態においては、ウェブページ1300は、定期的な間隔で自動的に表示することができ、提示された情報を読んで理解したことを確認するよう、およびそれらの情報を更新するよう従業員に促すことができる。図13においては、ウェブページ1300は、コンタクトナゲット1310を表示することができ、このコンタクトナゲット1310は、従業員のBCPコーディネータおよびBCM窓口をそれらの連絡先情報と共に識別する。メッセージナゲット1330は、その従業員のグループ用の避難集合場所など、その従業員に関する情報を表示することができる。メッセージナゲット1330内に表示される情報は、所定のメッセージ、あるいは従業員の役割に基づく1つまたは複数の具体的なメッセージとすることができる。それらのメッセージは、サードパーティーのワイヤレスデバイスを通じて従業員へ押し出すことができる。復旧場所ナゲット1340は、従業員のための復旧場所を表示する。コンフェレンスラインナゲット1350は、アクシデント中に従業員が通報したり最新の情報を受信したりするために使用できる緊急電話番号を表示する。ドキュメントライブラリナゲット1360は、その従業員のグループを対象とする復旧ドキュメントへのリンクを表示する。BCPグループナゲット1370は、その従業員を含むBCPグループを表示する。リファレンスナゲット1380は、従業員が検討できるBCプラン用のその他の補助資料へのリンクを表示する。

重要アプリケーションナゲット1320は、組織のオペレーションにとって重要とみなされるアプリケーションを表示する。好ましい一実施形態においては、組織内のそれぞれのサーバ上のそれぞれのアプリケーションは、組織のオペレーションに対するそのアプリケーションの必要性に従って段階レベルが割り当てられる。復旧チームは、他のアプリケーションが復旧される前に、ミッションクリティカルであると識別されたアプリケーションを上の段階レベルに上げることができる。それぞれのアプリケーションに割り当てられる段階レベルによって、復旧チームにとっての復旧の取り組みの優先順位が決定される。

図14は、ハイレベルのマネージャーが必要とする可能性のある概要情報を示す図である。図14においては、スコアカード1400が、ベストプラクティス1410のリストを表示しており、そのスコアカード上に表示されているベストプラクティスのそれぞれに関するステータス1420を示している。それぞれのベストプラクティスは、いかなるBCPにも組み込むべきであるとコンティニュイティーの立案者たちが一般に同意するポリシーとすることもでき、あるいは組織にとって重要なポリシーとすることもできる。たとえばベストプラクティスは、あらゆる従業員が少なくとも1つのコールツリーに所属するよう要求するポリシーとすることができる。他のポリシーは、特定のアプリケーションの日常的なバックアップや、重要なアプリケーションをホストできる準備された代替サイトでさえ要求することができる。他のポリシーは、危機に際して復旧現場で利用できるように法律文書や保険文書を保持するよう要求することや、複数のベンダーとの間で短期および中期の流動性を融通する関係を確立することなど、技術的な領域以外にも対処することができる。

ステータスリスト1420は、それぞれのベストプラクティスのステータスを、対応するベストプラクティスリスト1410内に表示する。このステータスリストは、ベストプラクティスのステータスを示すために色分けすることができる。好ましい一実施形態においては、それぞれのベストプラクティスには、それぞれのベストプラクティスのコンプライアンスに応じて3つのステータスレベルのうちの1つを割り当てることができる。たとえば緑色のステータスインジケータは、100%のコンプライアンスを示すことができ、赤色のステータスインジケータは、所定のコンプライアンスレベルに満たないことを示すことができ、黄色のステータスインジケータは、完全なコンプライアンスには満たないが所定のコンプライアンスレベルを上回っていることを示すことができる。所定のコンプライアンスレベルは、ベストプラクティスに応じて別々の値に設定することができる。たとえば、コールツリーのベストプラクティスには、90%という所定のコンプライアンスレベルを割り当てることができるが、研修および啓蒙のベストプラクティスには、75%という所定のコンプライアンスレベルを割り当てることができる。

それぞれのベストプラクティスのステータスは、BCMチームのメンバーによって手動で設定することもでき、あるいはADb内の情報から自動的に決定することもできる。説明に役立つ一例においては、ポリシーは、段階1のそれぞれのアプリケーションに対して6カ月ごとに障害回復のテストを行うよう要求することができる。段階1のそれぞれのアプリケーションの最後のテスト日をADb内に保存し、現在の日付と比較して、そのアプリケーションがコンプライアンスの状態にあるかどうかを判定することができる。

図15は、ハイレベルのマネージャーへの報告を行う管理グループによってセグメント化されたハイレベルのマネージャー用の概要情報を示す図である。図15においては、ステータスインジケータ1520が、それぞれのベストプラクティスごとに、およびハイレベルのマネージャーへの報告を行うそれぞれの管理グループごとに表示されている。インジケータのそれぞれの列1510は、ベストプラクティスを表す。インジケータのそれぞれの行1530は、それぞれの管理単位ごとのコンプライアンスを表す。図15に示されている表示によって、ハイレベルのマネージャーは、自分の部署や部門の全体的なコンプライアンスを迅速に評価し、BCPのコンプライアンスを高めるために注意を必要とする可能性のあるグループやベストプラクティスを識別することができる。

図16は、BCPコーディネータのためのBCPエディタを示す図である。BCPエディタ1600は、BCプランを作成し、修正し、保守するために使用することができる。好ましい一実施形態においては、BCPエディタ内に入力された情報は、ADb内に保存することができる。図16においては、地域ナゲット1610が、プランによって対象とされている選択された地域を示している。部署ナゲット1615は、選択された部署を示している。ユーザによって編集することができるプランのさまざまな部分を表す1つまたは複数のタブ1625を表示することができる。図16においては、homeタブ1620が選択されて、ホームビュー1630を表示している。ホームビュー1630は、そのプランのためのBCM窓口、BCPコーディネータ、および1人または複数のBCPアドミニストレータを識別する。編集アイコン1635は、プランを編集する権限を与えられている人々を示している。

BCPグループは、BCPエディタ内のPeopleタブを選択することによって、作成および保守することができる。図17は、Peopleタブ1710が選択されている状態のBCPエディタ1700の別のビューを示す図である。図17においては、情報ナゲット1720は、表示されているページ1700に関する情報をユーザに表示し、ユーザに指示を提供することができる。ユーザは、チームリストウィンドウ1730内のBCPグループのリストを見ることができる。ユーザは、リンク1740をクリックすることによって、新たなグループやチームを作成することができる。BCPコーディネータは、BCPページのpeopleタブ内の呼び出しアクションを選択することによって、BCPグループ用のコールツリーを始動することができる。呼び出しアクションが選択されると、このシステムは、自動通知システムを呼び出し、コーディネータの電話をその自動通知システムにつなぎ、この自動通知システムにおいて、コーディネータは、メッセージを録音し、コールツリーを始動することができる。コーディネータが、あらかじめ録音されたメッセージを自分のコンピュータ上に保存してある場合には、このシステムは、そのあらかじめ録音されたメッセージを使用し、コーディネータのさらなる介入を伴わずにコールツリーを始動することができる。

図18は、ユーザがcreate new groupリンク1740をクリックした際に表示することができるBCPグループエディタのビューを示す図である。グループエディタページ1800は、ユーザがBCPグループの名前を入力することができる編集可能なフィールドを含むことができる。グループエディタページ1800は、そのグループに関するBCPコーディネータおよびBCPアドミニストレータを表示することができる。アイコン1820をクリックすることによって、新たなBCPアドミニストレータを追加したり、修正したり、あるいは削除したりすることができる。説明フィールドを表示することができ、そこでユーザは、BCPグループの説明を入力することができる。ユーザは、saveボタン1840をクリックして、ページ1800上で行われた変更を保存し、利用可能なP&Lビューを表示することができる。通知グループに関連付けられているシナリオコード1850を表示して、その通知グループ用の自動化されたコールツリーをアクティブ化するアクシデントシナリオを表示することができる。

図19は、Available P&Lsタブ1910が選択された際の利用可能なP&Lビュー1900を示す図である。ビュー1900は、そのBCPグループに割り当てられているP&Lグループのリスト1920と、そのBCPグループに追加することができるまだ割り当てられていないP&Lグループのリスト1930とを含む。割り当てられているP&Lグループおよびまだ割り当てられていないP&Lグループのリストは、資産タイプ、およびそのBCプランに関連付けられている部門や部署との「Belongs To」の関係に関してADbにフィルタリングを行うことによって投入することができる。ユーザは、deleteボタン1925をクリックして、割り当てられているP&LグループをそのBCPグループから削除することもでき、あるいは、addボタン1935をクリックして、まだ割り当てられていないP&LグループをそのBCPグループに追加することもできる。あるP&LグループがBCPグループに追加される際には、そのP&Lグループ内のそれぞれの人ごとに「Belongs To」の関係が作成されて、その人がそのBCPグループにリンクされる。あるP&LグループがBCPグループから削除される際には、そのP&Lグループ内のそれぞれの人ごとにそのBCPグループに対する「Belongs To」の関係が削除される。P&Lグループを使用してBCPグループに対するメンバー資格を割り当てることは、それぞれの人をBCPグループへ個々に追加するのではなく、人々のグループを一度に割り当てることができるため、より効率的である。P&Lグループを介してBCPグループへの割り当てを行えば、あらゆる人が既にP&Lグループに割り当てられているため、あらゆる人がもれなくBCPグループに割り当てられることにもなる。

図20は、BCP Group Membershipsタブ2010が選択された際のグループメンバーシップビュー2000を示す図である。図20においては、そのBCPグループのメンバーを含むリスト2020が表示されている。それぞれのBCPグループメンバーごとに、個人のページャー番号2022、職場の電話番号2024、およびメンバーのタイプ2026が表示されている。個人のページャー番号および職場の電話番号は、メンバーリスト2020が投入された際に人のプロパティタイプとして保存し、検索することができる。BCPコーディネータまたはアドミニストレータは、Member Typeの下に表示されている適切なコントロールをクリックすることによって、それぞれのメンバーを復旧チームまたはオンコールチームに割り当てることができる。ある人が、組織が直接には管理していないコンサルタントであり、組織の場所の中に主要な場所を有していない場合には、BCPコーディネータは、その人にベンダーのタイプを割り当てることができる。アクシデントの場合には、ベンダーとして分類されたメンバーには連絡しないでおくことができる。あるメンバーが復旧チームの一員である場合には、プロンプト2040が表示されて、そのユーザに主要な復旧場所を入力するよう要求する。第2のプロンプト2045が表示されて、そのユーザに副次的な復旧場所を入力するよう要求する。ユーザがプロンプトを選択したことに応答して、ウィンドウ2050が表示され、そこでユーザは、復旧場所を入力することができる。

BCPコーディネータは、BCPエディタ内のOther Notification Groupsタブを選択することによって、任意選択の通知グループをすることができる。図21は、Other Notification Groupsタブ2110が選択された際のその他の通知グループのビュー2100を示す図である。ビュー2100は、そのBCプランに関連付けられている通知グループのリストを含む。その他の通知グループは、純粋に通知の目的で使用することができ、オンコールグループまたは復旧グループの一員ではないメンバーや、組織の別の部門に所属するメンバーを含むことができる。通知グループに関連付けられているシナリオコード2130を表示して、その通知グループ用の自動化されたコールツリーをアクティブ化するアクシデントシナリオを表示することができる。ユーザは、deleteコントロール2140をクリックすることによって通知グループを削除することもでき、あるいは、Create Newコントロール2150を選択することによって新たな通知グループを追加することもできる。

図22は、通知グループエディタのその他の通知グループのビュー内でCreate Newコントロール2150が選択された際に表示することができる通知チーム属性ビューを示す図である。図22においては、属性ビュー2200は、その通知グループに関連付けられているBCプランのためのBCPコーディネータ2210の表示を含む。その通知グループのためのアドミニストレータが割り当てられていない場合には、そのユーザがアドミニストレータの役割を用いて人と通知グループとの間における関係を作成することを選択できる旨のプロンプト2220が表示される。情報アイコン2225を表示することができ、これは、選択されると、さらなる情報をユーザに提供する。ビュー2200は、名前フィールド2230を含み、そこでユーザは、その通知グループ用の名前を入力することができる。説明フィールド2240を表示することができ、そこでユーザは、その通知グループの説明を入力することができる。Saveボタン2250は、ビュー2200内に入力した情報を保存するためにユーザによって選択することができる。

通知グループエディタ内のMembersタブを選択することによって、通知グループにメンバーを追加することができる。図23は、Membersタブ2310が選択された際の通知グループエディタ内のメンバービュー2300を示す図である。図23においては、通知グループメンバーリスト2320が表示され、これは、それぞれの個人の電話番号およびページャー番号を含むことができる。Add Team Membersコントロール2320を選択することによって、新たなメンバーを追加することができる。コントロール2320を選択すると、ポップアップウィンドウ2330が表示され、そこでユーザは、その通知グループのための新たなメンバーを選択することができる。ユーザは、肩書きによって、名前によって、あるいはBCPグループによって、新たなメンバーを選択することができる。ポップアップウィンドウ2330は、1つまたは複数のチェックボックス2332を含み、ユーザは、それらのチェックボックス2332をチェックして、肩書きによって新たなメンバーを選択することができる。ユーザは、アイコン2334をクリックして、名前によって新たなメンバーを選択することができる。ポップアップウィンドウ2330は、BCPグループのリストを表示するリストボックス2336を含み、ユーザは、このリストを選択して、BCPグループよってメンバーを追加することができる。選択されたメンバーは、メンバーリストボックス2338内に表示される。選択されたそれぞれのメンバーの隣にチェックボックスを表示することができ、それによってユーザは、人を選択解除して、その人を通知グループから除外することができる。saveボタン2340をクリックすることによって、選択されたメンバーを通知グループに追加することができる。

このように少なくとも本発明の例示的な実施形態について説明したが、当業者なら、さまざまな修正および改良を容易に想起するであろう。そうした修正および改良も、本発明の範囲内に収まることを意図している。したがって前述の説明は、例示にすぎず、限定することを意図するものではない。本発明は、添付の特許請求の範囲およびその均等物において定義されるようにのみ限定される。

本発明の一実施形態におけるデータモデルを示す図である。 本発明のいくつかの実施形態において使用できる階層構造を示す図である。 本発明のいくつかの実施形態において使用される地理的な階層を示す図である。 本発明のいくつかの実施形態において使用される資格関係テーブルを示す図である。 本発明のいくつかの実施形態において使用される資産テーブルを示す図である。 本発明の一実施形態における部門一覧の作成を示す流れ図である。 本発明の一実施形態における地域の部門ページを示す図である。 本発明のいくつかの実施形態における強化された名簿情報を表示するダッシュボードを示す図である。 本発明のいくつかの実施形態において表示されるリマインダ通知を示す図である。 本発明のいくつかの実施形態における管理ナゲットを表示するホームページを示す図である。 図10aに示されている管理ナゲットの詳細を示す図である。 本発明のいくつかの実施形態において使用されるコンプライアンスレポートを示す図である。 本発明のいくつかの実施形態において使用されるBCプラン内の資産を示すブロック図である。 本発明のいくつかの実施形態におけるある従業員に関連するBCプランの部分を示す図である。 本発明のいくつかの実施形態におけるBCP概要情報を示す図である。 本発明のいくつかの実施形態におけるBCP概要情報の別のビューを示す図である。 本発明のいくつかの実施形態におけるBCPエディタを示す図である。 本発明のいくつかの実施形態におけるBCPエディタの別のビューを示す図である。 本発明のいくつかの実施形態におけるBCPグループエディタのビューを示す図である。 本発明のいくつかの実施形態におけるBCPエディタの利用可能なP&Lビューを示す図である。 本発明のいくつかの実施形態におけるBCPエディタのグループメンバーシップビューを示す図である。 本発明のいくつかの実施形態におけるBCPエディタのその他の通知グループのビューを示す図である。 本発明のいくつかの実施形態における通知グループエディタの通知チーム属性ビューを示す図である。 本発明のいくつかの実施形態における通知グループエディタ内のメンバービューを示す図である。

符号の説明

110 資産タイプテーブル
115 1次キー
117 フィールド
130 役割タイプテーブル
135 1次キー
137 フィールド
150 資産関係タイプテーブル
155 1次キー
157 フィールド
170 資産タイププロパティテーブル
175 1次キー
177 フィールド
210 部門
220 部署
230 P&Lグループ
240 人
250 特別グループ
260 地域
270 リーガルエンティティー
310 地域
320 国
330 都市
340 建物
350 場所
360 人
400 資格関係テーブル
415 1次キー
417 フィールド
500 資産テーブル
515 1次キー
517 フィールド
700 地域の部門ページ
710 管理ナゲット
720 部署ナゲット
730 中央のナゲット
740 右側のナゲット
800 従業員プロファイル
810 従業員の名前
812 写真
814 連絡先情報
816 場所
820 組織階層
830 報告関係ナゲット
840 役割ナゲット
850 共有ドキュメントナゲット
860 メンバーシップナゲット
900 リマインダ通知
1000 ホームページ
1010 管理ナゲット
1012 締め切り
1014 リマインダの簡単な説明
1016 リンク
1020 パフォーマンスゴールリマインダ
1030 ビジネスコンティニュイティーリマインダ
1040 新従業員リマインダ
1050 T&Eアプルーバリマインダ
1060 部署リマインダ
1100 コンプライアンスレポートダッシュボード
1110 レポートフィルタ
1115 ドロップダウンメニュー
1120 オーバービューナゲット
1140 従っていないそれぞれの従業員のアドレスのリスト
1160 従っていない従業員のそれぞれのマネージャーのアドレスのリスト
1200 BCプラン
1210 人々
1220 アプリケーション
1230 場所
1240 メッセージ
1250 緊急会議呼び出し番号
1260 リソースの一覧
1270 ドキュメント
1300 ウェブページ
1310 コンタクトナゲット
1320 重要アプリケーションナゲット
1330 メッセージナゲット
1340 復旧場所ナゲット
1350 コンフェレンスラインナゲット
1360 ドキュメントライブラリナゲット
1370 BCPグループナゲット
1380 リファレンスナゲット
1400 スコアカード
1410 ベストプラクティス
1420 ステータス
1510 列
1520 ステータスインジケータ
1530 行
1600 BCPエディタ
1610 地域ナゲット
1615 部署ナゲット
1620 homeタブ
1625 タブ
1630 ホームビュー
1700 BCPエディタ
1710 Peopleタブ
1720 情報ナゲット
1730 チームリストウィンドウ
1740 create new groupリンク
1800 グループエディタページ
1820 アイコン
1840 saveボタン
1850 シナリオコード
1900 P&Lビュー
1910 Available P&Lsタブ
1920 割り当てられているP&Lグループのリスト
1925 deleteボタン
1930 まだ割り当てられていないP&Lグループのリスト
1935 addボタン
2000 グループメンバーシップビュー
2010 BCP Group Membershipsタブ
2020 メンバーリスト
2022 個人のページャー番号
2024 職場の電話番号
2026 メンバーのタイプ
2040 プロンプト
2045 第2のプロンプト
2050 ウィンドウ
2100 その他の通知グループのビュー
2110 Other Notification Groupsタブ
2130 シナリオコード
2140 deleteコントロール
2150 Create Newコントロール
2200 属性ビュー
2210 BCPコーディネータ
2220 プロンプト
2225 情報アイコン
2230 名前フィールド
2240 説明フィールド
2250 Saveボタン
2300 メンバービュー
2310 Membersタブ
2320 Add Team Membersコントロール
2330 ポップアップウィンドウ
2332 チェックボックス
2334 アイコン
2336 リストボックス
2338 メンバーリストボックス
2340 saveボタン

Claims (8)

1. 資産を表す少なくとも1つの資産レコードを含む資産テーブルを含み、
   前記少なくとも1つの資産レコードは資産タイプによって特徴付けられ、
   第1資産タイプと第2資産タイプとの間の関係を表す少なくとも1つのレコードを含む関係タイプテーブルと、
   前記資産テーブルおよび前記関係タイプテーブルを使用して作成された、第1資産と、第2資産と、前記第1資産の前記第2資産に対する役割と、前記第2資産の前記第1資産に対する役割とを表す少なくとも1つのレコードを含むテーブルと、をさらに含み、
   前記資産は企業の組織および前記組織内の人を含み、
   同じ資産タイプの資産の一覧が、信頼できるデータソースによって資産データベースに供給され、
   資産の一覧内の変更を特定する例外レポートを生成する手段と、
   前記資産の一覧内の変更に基づいてさらなる情報が必要であるかどうかを判定する手段と、
   前記さらなる情報を提供する責任者を特定する手段と、
   前記さらなる情報を提供する責任者へのリマインダ手段とをさらに含み、
   前記さらなる情報は変更された資産に対して所定の役割を有する資産の情報である資産データベースシステム。
2. 前記さらなる情報を提供する責任者のスーパーバイザを特定する手段と、
   前記責任者が所定の時間内に前記さらなる情報を提供しない場合に、前記スーパーバイザにリマインダを送信する手段とをさらに含む請求項１に記載の資産データベースシステム。
3. 資産データベースのデータインテグリティーを保持するコンピュータで実装される方法であって、
   資産を表す少なくとも1つの資産レコードを含む資産テーブルと、第1資産タイプと第2資産タイプとの間の関係を表す少なくとも1つのレコードを含む関係タイプテーブルと、前記資産テーブルおよび前記関係タイプテーブルを使用して作成された、第1資産と、第2資産と、前記第1資産の前記第2資産に対する役割と、前記第2資産の前記第1資産に対する役割とを表す少なくとも1つのレコードを含むテーブルと、を含む資産データベースを構成するステップを含み、
   前記少なくとも1つの資産レコードは資産タイプによって特徴付けられ、前記資産は企業の組織および前記組織内の人を含み、
   信頼できるデータソースからのデータ供給によって前記資産データベースを更新するステップと、
   前記資産データベースの一覧内の変更を特定するステップと、
   前記一覧内の変更によってさらなる情報が必要かどうかを判定するステップと、
   さらなる情報を提供する責任者を、前記責任者と変更された一覧との関係に基づいて特定するステップと、
   前記責任者から前記さらなる情報を受信するステップと、
   前記さらなる情報で前記資産データベースを更新するステップとをさらに含み、
   前記さらなる情報は変更された資産に対して所定の役割を有する資産の情報である方法。
4. 前記一覧内の変更を特定するステップは、
   前記データ供給と前記資産データベースの既存の一覧とを比較するステップと、
   前記データ供給と前記資産データベースの既存の一覧との間の差分を特定するステップとをさらに含む請求項３に記載の方法。
5. 前記さらなる情報が必要かどうかを判定するステップは、
   変更された資産および前記変更された資産に関連付けられる関係に関して前記資産データベースをフィルタリングするステップと、
   前記関係によって前記変更された資産と関連付けられる対象資産が前記資産データベース内に存在するかどうかを判定するステップと、
   前記対象資産が存在しない場合に、さらなる情報が必要であると判定するステップとをさらに含む請求項３に記載の方法。
6. 前記さらなる情報が必要かどうかを判定するステップは、
   変更された資産および前記変更された資産に関連付けられる必要な関係に関して前記資産データベースをフィルタリングするステップと、
   前記必要な関係が存在しない場合に、さらなる情報が必要であると判定するステップとをさらに含む請求項３に記載の方法。
7. 前記責任者から前記さらなる情報を受信するステップは、
   前記責任者に前記さらなる情報を提供するようにリマインダ通知するステップと、
   前記責任者を、前記責任者が前記さらなる情報を入力できるウェブページに導くステップと、
   前記ウェブページから前記さらなる情報を受信するステップとをさらに含む請求項３に記載の方法。
8. 前記責任者から前記さらなる情報を受信するステップは、
   前記責任者のスーパーバイザを特定するステップと、
   所定の時間後に、前記責任者の前記さらなる情報の提供不履行を、前記責任者のスーパーバイザに通知するステップとをさらに含む請求項３に記載の方法。

Images