JP2006501569A

JP2006501569A - アプリケーションサーバのクラスタへの多重企業プランニングモデルの展開

Info

Publication number: JP2006501569A
Application number: JP2004541552A
Authority: JP
Inventors: エス．ヒュムナンスキー，ブライアン; エス．ボーウェン，デイビッド; ダンカンピアーソン，ジョージ; エム．サンドレス，ジョン; エー．アシェンブレナー，クラレンス; アントロバス，マーク
Original assignee: コグノスインコーポレイティド
Priority date: 2002-09-30
Filing date: 2003-09-19
Publication date: 2006-01-12
Anticipated expiration: 2023-09-19
Also published as: AU2003274987A1; CA2498431A1; CN1689006A; US7072822B2; US20040064349A1; JP4375562B2; WO2004031891A3; AU2003274987B2; EP1573615A4; WO2004031891A2; EP1573615A2

Abstract

企業ビジネスプランニングシステムは、複数のアプリケーションサーバと、このアプリケーションサーバのそれぞれの組に１組の企業プランニングモデルの各々を結合する配備マップを生成するアドミニストレーションコンソールを含む。このアドミニストレーションコンソールは、自動的にかあるいはシステム管理者からの入力に応答して、企業プランニングへのコンピュータリソースの配備を精密に制御できる。アドミニストレーションコンソールは企業プランニング活動に対する近づいてくる期限に基づいて配備マップを調整することができる。企業プランニング活動と結合されたタスクを管理するときに、アドミニストレーションコンソールはこのタスクを多数のジョブに分割し、各ジョブをモデルによって規定される組織階層に従ってモデルの異なったスライスと結合する。この結果、企業活動へのコンピュータリソースの割り当てを精密に制御することができ、組織階層内の現在のニーズに合うように調整することができる。

Description

本発明は、企業コンピュータ環境、特に、企業ビジネスプランニングのためのコンピュータ環境に関する。

これまで以上に、企業は、企業経営について正確な予測を立てる責任を負っている。立てた予想がはずれた場合には、中でもキャシュフロー、株価、流動性、および投資家の信頼の領域において企業は重大なマイナスの打撃を受ける可能性がある。正確さが重大である企業プランニング活動の例には、収益予測、在庫管理、リソースプランニングなどが含まれる。企業ビジネスプランニング（enterprise business planning）は、しかしながら、往々にして不正確な結果を生む困難で費用のかかる仕事である。

従来、ビジネスは、企業プランニングへのアプローチに“トップダウン”か“ボトムアップ”かどちらかを取っていた。“トップダウン”プランニングでは、平均製品価格、従業員当たりのコストなど基本的なビジネス目標を特定し、会社の階層的構造を通じて目標を押し下げていく。これと対照的に、“ボトムアップ”プランニングでは、組織の最も下のコストセンタからの低レベルの予測を集合することが必要になる。例えば予算計画に対しては、支出を定期的に予測し、その支出を広告費、旅費、給与など多数のカテゴリーに割り当てることが経理職員に要求されよう。しかしながら、ボトムアップ予測は、トップダウンのビジネス目標と調和することは、あったとしても、稀である。

こうした情報は、一般的には紙を使って収集されていたが、もっと最近では、スプレッドシート・ソフトウェアプログラムで作られた電子テンプレートなど電子的な形態を用いて収集されてきている。これは、これまで相反する仮定や変化するビジネスロジックを用いて作り上げられてきたまとまりのないプランを統合する困難な仕事を、企業の財務部門に残す場合が多い。

最近になって、企業ネットワークを介してデータを収集するのに大型コンピュータシステムが使用されてきた。このコンピュータシステムは、典型的には、“オフ”時間中に時間のかかるオフラインバッチ処理を使って様々な企業ユーザから収集されたデータを統合する。このオフライン統合は、ユーザからデータを収集してから、収集されたデータを企業から収集された他のデータと統合するまでの間の相当の時間的遅れにつながりかねない。結果として、このようなシステムは、往々にして、予測された企業活動について実際の集合データの不正確な見解をユーザに示す。これは、ユーザが、不正データを提供される、または、その入力を誤って改変する方向に導きかねない。その上、ユーザは、どの数字が企業に対して“正しい”数字なのか確信がなくなり、また、結果の完全性を一般的に疑うことになるかもしれない。このデータ収集とオフライン統合の処理の遅さは、企業プランニングのような、期限が重視の活動にとって特に問題が多いと言える。

本願発明は大組織内の予算計画の正確さと予測性を改善する企業プランニング技術に関するものである。この技術は組織が会社財務モデルおよび組織目標を詳細な予測でリアルタイムに調和させることを可能にする。

この技術により、企業プランニングシステムは、企業に対するトップダウン目標を詳細なボトムアップ予測と調和させることを可能にし、自動化する。一般に、この企業プランニングシステムは３段階、すなわち、（１）モデル化段階、（２）コントリビューション段階（contribution stage）、そして（３）調和段階（reconciliation stage）の企業プランニングを備える。モデル化段階の間に、アナリストと呼ばれる上位の企業管理者または役員が、組織目標を規定し、企業のプランニングモデルを構築する。次のコントリビューション段階の間に、規定された1組のコントリビュータ（contributor）が企業プランニングシステムと対話し、詳細な予測をコントリビューションデータの形で提供する。調和段階の間に、企業プランニングシステムは、予測データと組織目標との調和を自動化する。

このプロセスの間に、上記の企業プランニングシステムは、規定されたモデルに従って動作し、多重調和レベル（multiple reconciliation level）を有する階層的プランニングプロセスを提供する。この各レベルにおいて、企業プランニングシステムは、階層的モデルにより規定された通り企業レビューア（enterprise reviewer）に上記のコントリビューションデータを提供し、レビューアが目標データを予測データと調和させることを要求する。各レビューアは、例えば、アナリストにより提供された会社目標を考慮して上記のコントリビューションデータを拒絶したりあるいは受け入れたりすることができる。

コントリビュータがコントリビューションデータを提供するにつれて、企業プランニングシステムは、自動的にコントリビューションデータを企業全体からリアルタイムで集合させ、この集合したデータをレビューアに提供し、受け入れまたは棄却される。このプロセスは、コントリビューションデータが組織階層（organizational hierarchy）の最上位レベルに属するレビューアにより最終的に承認されるまで続き、それにより、コントリビュータからのコントリビューションデータは会社目標と確実に調和させられる。

一実施例においては、システムは、複数のアプリケーションサーバ及びアドミニストレーションコンソールを含み、１組の企業プランニングモデルの各々を上記のアプリケーションサーバのそれぞれの組と結合する配備マップ（deployment map）を生成する。

他の実施例においては、１つの方法は１組の企業プランニングモデルの各々をアプリケーションサーバのそれぞれの組と結合する配備マップを生成することと、上記のそれぞれの組のアプリケーションサーバを有する上記の企業プランニングモデルでジョブを処理することを含む。

本発明は１つ以上の利点をもたらすことができる。例えば、ここで述べる技術は、自動的に、あるいはシステム管理者からの入力に応答して、企業プランニングへのコンピュータリソースの配分全体について細密な制御を提供することができる。上記の配備マップを、上記の企業プランニング活動に対する期限の接近に基づいてアプリケーションサーバ全体にわたってモデルの配置をシフトするように調整することができる。企業プランニング活動と結合されたタスクを管理するとき、上記の企業プランニングシステムはこのタスクを多数のジョブに分割し、そのモデルによって規定された組織階層に従って、各ジョブをそのモデルの異なったスライスと結合する。この結果、コンピュータリソースの企業プランニングへの配分は細密に制御され、上記の組織階層内の現在のニーズに合うように調整することができる。

この技術は、組織が会社モデルと組織目標とを詳細な予測でリアルタイムに調和させることを可能にすることによって企業プランニングの正確さと予測性を改善することができる。この技術は、予測のオフライン統合および集合を必要とすること無しに、協働的なリアルタイムプランニング能力を与えるプラットホームを提供する。この企業プランニングシステムは、コントリビューションデータをリアルタイムで集合させることができるので、全てのユーザにデータの正確な最新の一覧を提供することができる。このシステムは、プランニングに含まれた企業ユーザの数に関係なく、高速応答を提供し、従って正確なプランニング情報を提供することができる。

加えて、この技術は、企業全体にわたって高度なユーザ参加を促進し、それで、プランニングサイクルを例えば数ヵ月から数週間に短縮できるようにし、また、ローリング予測のような最良の方式を迅速に実践できるようにする。

以下、本発明の1つ以上の実施例を添付図面に則して詳細に説明する。本発明の更なる特徴、目的および利点は、以下の説明、図面および特許請求の範囲から明らかとなろう。

図１は、企業プランニングシステム（enterprise planning system）３が企業４に対するトップダウン目標と詳細なボトムアップ予測との調和を可能にし、自動化する環境２を図示するブロック図である。一般に、企業プランニングシステム３は３段階、すなわち、（１）モデル化段階、（２）コントリビューション（contribution）段階、そして（３）調和（reconciliation）段階の企業プランニングを備える。モデル化段階では、最高財務責任者、上級財務アナリスト、あるいは製品及び販売アナリストなどのアナリスト８が、要件を規定し、企業４に対するプランニングモデルを構築する。詳記するならば、アナリスト８は、ビジネス単位またはビジネス部門など、企業４内部の様々なコストセンタを表す階層的に配置された多数のノードを有するモデルを開発する。

モデル化段階の間で、アナリスト８はまた、組織階層の各ノードに対する会社目標をも確立する。アナリスト８は次に、各ノードに1つ以上の企業ユーザ、例えばマネージャ、スーパーバイザ、販売代理者、労務管理者など、対応するコストセンタのための企業プランニングに対する責任を負う企業ユーザ（enterprise user）を割り当てる。各企業ユーザを、プランニングデータを企業システム３に提供するコントリビュータ（contributor）８として、コントリビュータ８からのコントリビューションを受け入れ、または拒絶するレビューア（reviewer）として、または、その両方として指定され得る。コントリビュータ８およびレビューア９は、企業４内部の、あるいはネットワーク９に結合された他の企業体、例えば納入業者（supplier）１４や顧客１６の内部の公認ユーザ（authorized user）であってもよい。

最後に、アナリスト８は、コントリビュータから支出予測データ（spending forecast data）を収集するための多数のテンプレートを規定する。アナリスト８は、会社目標データを予測データとの調和を容易にするようにテンプレートの中に入れる。

次に、企業プランニングシステム３はコントリビューション段階に入り、この間に、コントリビュータ６が企業プランニングシステム３と対話し、詳細な予測をコントリビューションデータの形で入力する。例えば、コントリビュータ６は、詳細な財務予測、収益予測、注文予測、在庫品目予測、推定リソース要求量（estimated resource requirement）などを、企業４が実行している特定の企業プランニング活動に応じて提供することができる。

調和段階の間に、企業プランニングシステム３は、予測データの、アナリシス８により提供された会社目標との調和を自動化する。特に、企業プランニングシステム３は、多重調和レベル（multiple reconciliation levels）を有する階層的なプランニングプロセスを備えるように規定されたモデルに従って動作する。コントリビュータ６の各々が自分自身のコントリビューションデータを提供するにつれて、企業プランニングシステム３は、企業４全体にわたってコントリビューションデータをリアルタイムで自動的に集合させ、企業４のより上位のレベルと結合したレビューア９に対して上記の集合データ（aggregated data）へのアクセスを提供する。特に、コントリビュータ６からのコントリビューションデータを受け取ると、企業プランニングシステム３は、新たに受け取ったコントリビューションデータによって影響される組織モデルのすべての上位レベルを識別し、各レベルにおける新たな集合合計（aggregate total）をリアルタイムで計算する。

結果として、レビューア９は、企業プランニングセッションの間に企業４全体にわたってリアルタイムで集合データを見る。各レベルにおいて、企業プランニングシステム３は、レビューア９が、企業モデルのノードにより規定されたように、目標データを予測データと確実に調和させるようにする。各レビューア９は、例えば、アナリスト８により提供された会社目標に照らしてコントリビューションデータを拒絶したり受け入れたりすることができる。このプロセスは、コントリビューションデータが組織階層の最上位レベルにより最終的に承認されるまで続き、それにより、コントリビュータ６からのコントリビューションデータは、アナリスト８により提供された会社目標と確実に調和するようになる。

このようにして、企業プランニングシステム３は、従来技術よりもっと正確な企業プランニングを提供することができる。例えば、企業プランニングシステム３は、組織が会社モデルおよび組織目標を詳細な予測と調和させるのを可能にすることにより、企業プランニングの正確さと予測性を改善することができる。この技術は、協働的なリアルタイム・プランニング能力を実現させるプラットフォームを、予測のオフライン統合および集合を必要としないで提供することができる。企業プランニングシステムはコントリビューションデータをリアルタイムで集合させることができるので、すべてのユーザに数値の正確な最新の一覧を提供することができる。更に、企業プランニングシステム３のアーキテクチャは、数千のユーザに容易に拡大することができ、また最良に近いプランニングが実践されるように設計することができる。加えて、この技術は、企業ユーザ、すなわち、コントリビュータ６およびレビューア９による高度な参加を可能にし、正確なプランニングサイクルを短縮できるようにする。

企業ユーザは、ネットワーク９を介して企業プランニングシステム３と対話するために多様なコンピュータ装置を使用することができる。企業ユーザは、企業プランニングシステム３との対話を、例えばワシントン州レドモンドのマイクロソフト社のインターネットエクスプローラ（登録商標）などのウェブブラウザを動かすラップトップコンピュータ、デスクトップコンピュータなどを使用して行うことができる。あるいは代わりに、企業ユーザは、カリフォルニア州サンタクララのPalm Inc.のパーム・オーガナイザ（Palm（登録商標）organizer）などのパーソナル・ディジタル・アシスタント（ＰＤＡ：personal digital assistant）、ウェブで可能なセルラーフォン（web-enabled cellular phone）、または類似の装置を使用してもよい。ネットワーク９は、インターネットのようなパケットベースのディジタルネットワークなど、どんな通信網をも表す。このようにして、システム２は大企業に適合するように容易に拡大することができる。企業ユーザは、ローカルエリアネットワーク経由で企業プランニングシステム３に直接アクセスすることができ、あるいは、仮想プライベートネットワーク、リモートダイアルアップ、または類似のリモートアクセス通信機構を介して企業プランニングシステム３に遠隔的にアクセスしてもよい。

図２は、企業プランニングシステム３の一実施例を図示するブロック図である。図示した実施例では、企業プランニングシステム３はウェブサーバ２０、アプリケーションサーバ２６、およびデータベースサーバ４０を含む。

ウェブサーバ２０は、ネットワーク９を介して企業ユーザ１８と通信するためのインタフェースを備える。ウェブサーバ２０は、ワシントン州レドモンドのマイクロソフト社のインターネットインフォメーションサーバ（Internet Information Server（登録商標））などのウェブサーバソフトウェアを実行する。このように、ウェブサーバ２０は、解析モジュール３０、コントリビューションモジュール３２、アドミニストレーション（ADMIN：administration）コンソール３６、および拡張マネージャ（extension manager）３８を含むソフトウェアモジュール２１に従ってコントリビュータ６、アナリスト８およびレビューア９と対話するための環境を備える。

ソフトウェアモジュール２１は、Lotusスクリプト（Lotus script）、Java（登録商標）スクリプト、Java（登録商標）アプレット、アクティブサーバページ（Active Server Page）、ハイパーテキストマークアップ言語（HTML）またはダイナミックＨＴＭＬで書かれたウェブページ、アクティブＸオブジェクト（Active X object）、およびその他の適当なモジュールを含むことができる。ウェブサーバ２０は、ソフトウェアモジュール２１により規定されたウェブページを出し、そのウェブページを企業ユーザ１８のコンピュータ装置に通信する。このウェブページは、企業ユーザ１８からの情報を受け取るために、テキストやグラフィックイメージ（graphic imagery）などの静的媒体、ならびに、テキストエントリボックス（text entry box）、ラジオボタン、ドロップダウンメニューなどの従来型の入力媒体を含むことができる。

ソフトウェアモジュール２１はデータベースサーバ４０と対話して、ユーザデータ４２Ａ、モデルデータ４２Ｂ、ジョブデータ（job data）４２Ｃ、および構成データ（configuration data）４２Ｄを含む企業データ４２にアクセスする。企業データは、1つ以上のデータベースサーバ上で動作を実行する、1つ以上のデータベース管理システム（DBMS：database management system）、あるいは1つ以上のデータ記憶ファイルを含む多数の異った形で記憶することができる。このデータベース管理システムは、関係型（RDBMS）、階層型（HDBMS）、多次元型（MDBMS）、オブジェクト指向型（ODBMSまたはOODBMS）、あるいはオブジェクト関係型（ORDBMS）のデータベース管理システムでよい。その上、図では別個に描かれているが、企業データ４２は、組み合わせて単一のデータベースに、あるいは他のデータ記憶構造に組み入れることもできよう。企業データ４２は、例えば、マイクロソフト社のSQLサーバなどの単一の関係型データベース（relational database）として実現させることもできよう。

ユーザデータ４２Ａは、名前、ｅメールアドレスおよび他のユーザ連絡先（contact information）を含むユーザ１８の各々に対する情報を記憶する。モデルデータ４２Ｂは、アナリスト８により規定された企業プランニングモデルを記憶する。モデルデータ４２Ｂは、例えば、調和レベルの数、階層における様々な“ノード”、および各ノードと結合したコントリビュータ６を含む、アナリスト８により展開される調和プロセス（reconciliation process）を規定する情報を記憶する。加えて、モデルデータ４２Ｂは、ユーザ１８からのコントリビューションおよびレビューデータを捕えるためのモデルのそれぞれのデータエントリテンプレート（data entry template）を記憶する。ジョブデータ４２Ｃは、アプリケーションサーバ２６の実行のためのアドミニストレーションジョブを規定し、構成（CONFIG）データ４２Dは、企業プランニングシステム３のための基礎構成データを記憶する。

アプリケーションサーバ２６は、ビジネスロジックモジュール（business logic module）４６、企業プランニング拡張部（enterprise planning extension）４７、およびアプリケーションプログラミングインタフェース（API）４８の実行のための動作環境を提供する。加えて、アプリケーションサーバ３６は、ジョブデータ４２Ｃにより規定されたようなアドミニストレーションタスク（administration task）を実行する。換言すれば、ジョブデータ４２は、アプリケーションサーバ２６による実行のためのペンディングのアドミニストレーションジョブに関するジョブ明細（job description）を待ち行列に入れる（queuing）ためのメカニズムを備える。

ソフトウェアアプリケーション２１について説明すると、解析モジュール３０は、プランニングプロセス全体を制御するために、企業４向けの財務モジュールのような、企業プランニングモデル作成用の1つ以上のソフトウェアモジュールを含む。例えば、解析モジュール３０により、アナリスト８は、企業プランニングプロセスにおける様々なコストセンタ、それに対応するオーナ（owner）、および調和段階の数を規定することができる。一構成において、解析モジュール３０は、企業リソースプランニング（ERP：enterprise resource planning）データベース（図示されていない）からコストセンタ構造およびオーナシップを読み取る。加えて、解析モジュール３０により、アナリスト８は、コントリビューションデータを収集するための“テンプレート”を規定できる。テンプレートは、コントリビューションデータの入力と計算のためのインタフェースを備える1つ以上の多次元構造を含むことができる。例えば、このテンプレートを、コストセンタを列に沿ってアカウント、欄に期間を取ったチャートを有する、データ選択のためのデータキューブ（data cube）内部の一次元として規定することができる。解析モジュール３０は、企業プランニングモデルならびに対応するテンプレートをモデルデータ４２Ｂ内部に記憶する。

解析モジュール３０により、組織は、予算計上プロセス（budgeting process）を自動化し、コントリビュータ６がそれらのそれぞれのコントリビューションデータを適時に提出すること、及びテンプレートが、規定された調和段階を通って迅速に移動することを確実にするための多数の機構を規定することができる。例えば、解析モジュール３０を用いて、アナリスト８は、コントリビュータ６が企業プランニングシステム３にアクセスして特定のテンプレートを完成させるように思い出させるために電子メールメッセージ（ｅメール）をトリガするためのタイマを規定することができる。

コントリビューションモジュール３２は、コントリビュータ６として指定された企業ユーザ１８にテンプレートを提供し、コントリビュータ５からのコントリビューションデータを捕えるためのソフトウェアモジュールを含む。コントリビューションモジュール３２は、企業４全体にわたってリアルタイムでコントリビューションデータを捕えて集合させ、企業４のより上位のレベルと結合したレビューア９にこの集合したデータへのアクセスを提供する。

レポート生成器（report generator）３４は、コントリビュータ６から受け取ってモデルデータ４２Ｂの中に記憶したコントリビューションデータに基づいて企業プランニングレポートを生成する解析ソフトウェアモジュールを含む。特に、この解析ソフトウェアモジュールにより、アナリスト８やレビューア９などのユーザ１８は、企業モデルの現データに基づいてレポートを生成し、他のデータ解析機能を実行するための複雑なクエリ（query）を定式化することができるようになる。これらのソフトウェアモジュールは、ブラウザインタフェースを有するウェブベース型モジュールであっても、スタンドアロンで実行可能なプログラムであってもよい。

ビジネスロジックモジュール４６は、アプリケーションサーバ２６により提供された動作環境の中で動作を実行し、ソフトウェアモジュール２１に応答してデータベース４２の中に記憶されたデータにアクセスし、これを処理するための機能性を備える。特に、ビジネスロジックモジュール４６は、企業プランニング機能を実行するためのソフトウェアルーチン（software routine）を含み、ソフトウェアモジュール２１により呼び出される。

アドミニストレーションコンソール３６は、ウェブサーバ２０、アプリケーションサーバ２６およびデータベースサーバ４０のクラスタリング（clustering）を制御するためのインタフェースを提供する。アドミニストレーションコンソール３６により、システム管理者は、各クラスタ内部で使用されるサーバの数を制御することができる。上記のシステム管理者は、例えば、ネットワーク９内部で使用可能なサーバを1つ以上選択することができ、アドミニストレーションコンソール３６に、そのサーバを例えばアプリケーションサーバ３６として利用するように命令することができる。このようにして、企業プランニングシステム３は、数千のユーザ１８を有する大企業をサポートするように容易に拡大することができる。

企業プランニング活動と結合したタスクを管理するとき、アドミニストレーションコンソール３６は、そのタスクを、各々、特定のモデルにより規定された多レベルの組織階層に従ってモデルの異なるスライス（slice）と結合した多数のジョブに分割することができる。例えば、アドミニストレーションコンソール３６は、１つの特定のタスクを1組のＮ個のジョブに分離することができ、ここで、Ｎは階層内部で規定されたノードの数に等しい。アドミニストレーションコンソール３６は、次に、上記のモデルが配備されたアプリケーションサーバ２６のセット全体にわたって上記のジョブを分配することができる。

アドミニストレーションコンソール３６は、アプリケーションサーバ２６による処理のために待ち行列に入れられた（queued）ジョブを見るための、また、クラスタ化したアプリケーションサーバ２６全体にわたってロードバランスを見るためのジョブインタフェースを備える。アドミニストレーションコンソール３６は、アプリケーションサーバ２６のためのタスクを規定するためにジョブデータ４２Ｃを生成する。ジョブデータ４２Ｃ内部でジョブが待ち行列に入れられるにつれて、アプリケーションサーバ２６は、データベースサーバ４０からジョブデータ４２Ｃを読み取り、そのジョブを処理して完成させる。例えば、あるタイプのジョブは、企業データ４２Ｂ内部で規定された企業モデルを各ユーザに対して“スライス”する“カットダウン”プロセスを含む。このプロセスの間に、アプリケーションサーバ２６は、規定されたモデルの領域が、ユーザ１８がコントリビュータとして割り当てられた領域かレビューアとして割り当てられた領域かを識別する。企業プランニングシステム３は、コントリビューションデータを捕え、そのコントリビューションデータを組織目標と調和させるために、各ユーザ１８に上記のそれぞれのスライスを提供する。この方式では、企業プランニングシステム３はモデル全体をユーザ１８の各々に通信する必要はなく、それにより、通信時間ならびにリソース要求量（resource requirement）が低減される。代わりに、各ユーザ１８は関連情報のみを受け取る。

加えて、アドミニストレーションコンソール３６により、システム管理者は、アプリケーションサーバ２６全体にわたって企業プランニングモデルの配備を制御することができる。特に、アナリスト８は、企業４のために複数のプランニングモデルを規定することができる。例えば、アナリスト８は、収益予測、在庫管理、リソースプランニング、支払勘定管理（managing accounts payable）などのために別々のモデルを規定することができる。アドミニストレーションコンソール３６により、システム管理者は、各モデルを1組のアプリケーションサーバ２６に割り当てる配備マップ（deployment map）を作成できる。換言すれば、異なる企業モデルを別個のアプリケーションサーバ２６に配備することも、1つ以上のアプリケーションサーバで共有することもできる。

結果として、システム管理者は、企業プランニングへのコンピュータリソースの割り当てを細かく制御することができ、企業の現在のニーズに合うようにそのリソースを調整することができる。システム管理者は、企業プランニング活動に対する接近しつつある期限（deadline）に基づいてアプリケーションサーバ２６全体にわたってモデルの配備をシフトするために上記の配備マップを調整することができる。特に、システム管理者は、期限の接近につれて増大しそうなユーザ１８による活動に照らして、最も早い期限を有する企業モデルにより多くのコンピュータリソースを割り当てることができる。別の例として、システム管理者は、企業プランニングモデルに参加するユーザ１８に対する現在の使用レベルに基づいて上記の配備マップを調整することができる。

アドミニストレーションコンソール３６により、アナリスト８は企業プランニングモデルを修正できる。例えば、アナリスト８は、企業プランニング活動を開始した後に追加のコントリビューションデータを獲得したい場合がある。モデルに対する変更の受け入れを容易にするために、アドミニストレーションコンソール３６は、企業プランニングモデルのノードレベル修正（node-level modification）とメンテナンスをサポートする。特に、アドミニストレーションコンソールにより、アナリスト８は、モデルのノードのチェックイン、チェックアウトを行う、即ち、そのノードにマークを付けるか、さもなければそのノードの状態を「オンライン」から「オフライン」に変更することができるようになる。結果として、アナリスト８は、企業規模のプランニング活動を中断するよりはむしろ、特定のオフラインと結合したモデル「スライス」を更新することができる。他のユーザはこのオフラインノードを編集することはできない、即ち、コントリビューションデータあるいはレビュー入力を取引データ領域６２内のノードに対するそれぞれのスロットにセーブすることはできない。

しかしながら、上記のオフラインでないノードと結合された企業コントリビュータは企業プランニングセッションのためにコントリビューションデータを提供し、レビューし続けることができる。この特徴により、１ノードベース（per-node basis）の修正とメンテナンスが可能となり、またモデルはいつでも使用できる状態に留まることができる。従って、アナリスト８は、モデル全体をオフラインにすることなく、特定のノードと結合したビジネスロジックを修正することができる。

アプリケーションサーバ２６は、典型的には、アナリスト８によって為されたモデル変更を処理する。特に、アナリスト８がプランニング活動の間に企業モデルを修正する場合は、アプリケーションサーバ２６を、ユーザ１８から受け取ったコントリビューションおよびレビューデータを更新されたモデルと調和させるために使用することができる。あるいは代わりに、アドミニストレーションコンソール３６がアプリケーションサーバ２６に、ユーザ１８のコンピュータ装置上での遠隔調和を容易にするようにさせることができる。モデル変更に続くユーザ１８によるアクセスを認証すると、認証サーバ４４は、調和ジョブをローカルコンピュータ装置へ“プッシュ”することができる。リモートコンピュータ装置は、ユーザ１８のコントリビューションデータおよびレビューデータを更新されたモデルと調和させ、この調和させたデータを企業プランニングシステム４にセーブする。これは、企業モデルを更新するのに企業プランニングシステム３をオフラインにする必要がないという点で有利であり、また、その更新を処理するためのコンピュータリソース（computing resource）をユーザ１８のリモートコンピュータ装置全体に分配できるという点で有利であり得る。

拡張マネージャ（extension manager）３８は、システム管理者が、システム１０に追加の企業プランニング機能を容易に提供するように拡張部（extension）４７をインストールし、選択的に配備することができるインタフェースを備える。一般に、３つのクラスの機能拡張、即ち、（１）アドミニストレーションの拡張、（２）サーバ側の拡張、および（３）クライアント側の拡張が追加可能である。アドミニストレーションの拡張は、アドミニストレーションコンソール３６内部で動作を実行し、またはそれによって呼び出されるソフトウェアモジュールを含む。結果として、アドミニストレーションの拡張は典型的には、追加の管理機能性を提供するために使用され、アプリケーションサーバ２６による実行のためのアドミニストレーションジョブを生成することができる。

サーバ側の拡張は、典型的には、アプリケーションサーバにより提供された動作環境の中で動作を実行する。これらの拡張は、プランニング活動の間の、ワークフローインテグレーション（workflow integration）、カスタム初期化、または、集合したコントリビューションデータのカスタムパブリッシング（custom publishing）を容易にするのに使用することができる。

対照的に、クライアント側の拡張は、ユーザ１８のリモートコンピュータ装置の動作環境、典型的にはウェブブラウザ環境の中で動作を実行するソフトウェアモジュールを含む。コントリビューションモジュール３２は、新たにインストールされた拡張について拡張部４７を自動的に探索し、それらのその次のアクセス時に、上記の拡張をユーザ１８にダウンロードする。特に、コントリビューションモジュール３２は、ユーザアクセスがあり次第、または要求があり次第、直ちにリモートコンピュータ装置上において上記の拡張をロードし、呼び出すことができる。クライアント側の拡張は典型的にはリモートコンピュータ装置の動作環境の中で動作するが、この拡張は、サーバ側コンポーネントと対話することができる。

拡張の組み込みを容易にするため、企業プランニングシステム３は、拡張部４７がモデルデータ４２Ｂ内部のモデル、ならびに、企業プランニングシステム３の他のコンポーネントに直接アクセスし、操作することができるようにするアプリケーションプログラミングインタフェース（API：application programming interface）４８を備える。拡張マネージャ３８を介して、システム管理者は、新たな拡張部４８をシステム１０で登録し、この拡張を開始させるための入力、例えばボタンまたは他のグラフィックアイコンを規定することができる。

拡張マネージャ３８により、システム管理者は、特定ユーザ１８に割り当てられた役割に基づいて拡張を選択的に配備することができる。特に、拡張マネージャ３８により、システム管理者は、拡張をすべてのコントリビュータ６に、また、すべてのレビューア９に割り当てることができる。加えて、拡張マネージャ３８により、システム管理者は、拡張を、モデルデータ４２Ｂの中に記憶された企業プランニングモデルの異なるスライスに割り当てることができる。このようにして、拡張を異なるコストセンタ、異なるビジネス部門等に割り当てることができる。その上、拡張を、特定モデルにより規定された階層内部でレビューア９のレベルに基づいて割り当てることができる。例えば、階層のあるレベルのレビューア９、例えばコストセンタのためのコントローラに、集合したすべてのコントリビューションデータ上に詳細な最良のプラクティス有効化（practice validation）を提供する最良プラクティスの拡張（best-practices extension）を完成させるよう要求することができる。拡張マネージャ３８は、どの機能拡張がユーザ１８の各々に割り当てられるかを指示し、あるいは、拡張についてユーザ固有のプロパティを設定し得るユーザデータ４２Ａ内部のユーザ固有の拡張情報を記憶することができる。このフレキシビリティにより、企業プランニングセッションがより深く企業１０の中まで広がるにつれて、有利に企業プランニングモデルを適合させ、カスタマイズすることができる。

拡張の１つの例が、マイクロソフト社のネットミーティング（NetMeeting）のような、既製の（off-the-shelf）協業ネットワークベース型（collaborative network-based）プランニングツールに帯封（wrapper around）を提供する拡張である。コントリビューションデータを拒絶する代わりに、レビューア９は、次位の会議に上記の拡張を呼び出し、モデルデータ４２Ｂに直接アクセスして、コントリビューションデータを共にレビューすることができる。別の例は、他のソースに対してコントリビューションデータのリアルタイムの有効化を可能にする拡張である。拡張の他の例には次のものが含まれる。即ち、（１）階層内部で特定ユーザ１８により要求されたカスタマイズされたレポート機能のための拡張、（２）プランニングデータを他のアプリケーション、例えば表計算（spreadsheet）アプリケーションにエクスポートするための拡張、（３）新たに開発された印刷エンジンを駆動するための拡張、（４）企業データをインポートするための拡張、および（５）ドキュメント管理システムとのインタフェースのための拡張。

拡張マネージャ３８により、システム管理者は、拡張部４７をシステム３内部のイベントまたはメッセージにマッピングすることができる。例えば、システム管理者は、新しい拡張をインストールし、また、その拡張が、コントリビューションモジュール３２経由でコントリビュータ６の１つからコントリビューションデータを受け取るときに呼び出されるよう要求することができる。この特徴は、コントリビューションデータの最良のプラクティスの有効化を展開するために、または、他の企業要件を強化するために特に有用であり得る。別の例として、トップダウンの会社目標とボトムアップ予測との調和を所定の規定されたパーセンテージ、例えば１０％の範囲内で強化するのに拡張を使用することができる。別の例として、予測をあるレベルに、または特定のパーセンテージだけ低減するのに拡張を使用することができる。こうして、予測の均一な減少を容易に要求して、企業４全体にわたってそれを強化することも可能である。

一実施例では、拡張部４７は、コンポーネントオブジェクトモデル（COM：component object model）に準拠するソフトウェアモジュールを含むことができる。結果として、アクティブＸクライアント（Active X client）を使って拡張部４７を容易に呼び出すことができる。各拡張部４７は、例えばコントリビューションモジュール３２またはアドミニストレーションコンソール３６による呼び出しおよび制御のために1つ以上の共通インタフェースを備えることができる。

図３は、コントリビュータ６またはレビューア９などのユーザ１８により操作されるとき、その上で動作を実行する様々なソフトウェアモジュールを含むコンピュータ装置５０の一実施例を図示するブロック図である。この実施例において、コンピュータ装置５０は、ウェブブラウザ５２、計算エンジン５４、テンプレート５６およびデータキューブ（data cube）５８を含む。ユーザ１８がコンピュータ装置５０に、企業プランニングシステム３にアクセスするよう命令するとき、計算エンジン５４およびテンプレート５６がウェブブラウザ５２内部にダウンロードされ、インストールされる。

一実施例では、計算エンジン５４は、アレイベース言語（array-based language）で構築されたアクティブXオブジェクトに包み込まれたフォワード計算エンジン（forward calculation engine）５４を含む。テンプレート５６は、予算予測データを入力、操作するために必要な何らかのドライバを含むアクティブXコントロール（Active X control）を含む。テンプレート５６は、トップダウン目標データおよびボトムアップコントリビューションデータを含むスタンドアロンのデータキューブ５８を含み、全ての計算を局部的に実行できるようにする。それゆえ、そのダウンロードが完了した後、各コントリビュータ６は、自分自身のそれぞれのコントリビューションデータをテンプレート５６内部で修正し、企業プランニングシステム３にアクセスすることなく計算を実行することができる。アクティブXコンポーネントとして、計算エンジン５４、テンプレート５６およびデータキューブ５８は、コンピュータ装置５０経由でローカルに維持される。こうして、コントリビュータ６がネットワーク遅延（network delay）に直面するのは、テンプレート５６および計算エンジン５４が最初にダウンロードされるときだけ、ならびに、テンプレート５６がセッションの終わりにセーブされるときだけということになる。

企業プランニングシステム３との対話のために、コントリビュータ６は各々、ウェブブラウザ５２を使ってテンプレート５６と対話して、例えば表示グリッド（displayed grid）のセルを完成させ、そのグリッド内部の計算された項目に生じる動的変化を見ることにより、それぞれのコントリビューションデータを提供する。計算エンジン５４はウェブブラウザ５２内部に常駐しているので、セルエントリ（cell entry）をネットワーク９経由で企業プランニングシステム３に再提示し（resubmit）、再計算し、ウェブブラウザ５２に再掲示する（re-post）には及ばない。コントリビュータ６がプランニングセッションを終了させたいと望んでいながら、プロセスを終了させなかった場合、コントリビュータ６は、テンプレート５６およびデータキューブ５８を企業プランニングシステム３にセーブすることができる。コントリビュータ６がプランニングセッションを続行したいと望むときは、自ら企業プランニングシステム３にアクセスでき、その時点で、適当なテンプレート５６およびデータキューブ５８が更なる編集のためにウェブブラウザ５２にロードされることになる。コントリビュータ６がテンプレート５６内部に入力された予算データに満足するときは、コントリビュータ６は、そのデータを企業プランニングシステム３に提示することができる。各コントリビュータ６が自分のコントリビューションデータを提供するかあるいはそのコントリビューションデータを受け入れるかするにつれて、企業プランニングシステム３は、そのコントリビューションデータを企業４全体にわたってリアルタイムで自動的に集合させ、そしてその集合させたデータへのアクセスを、企業４のより上位のレベルと結合したレビューア９に提供する。

同様の仕方で、レビューア９は各々、自分のリモートコンピュータ装置５０上で実行するウェブブラウザ５２経由で企業プランニングシステム３と対話する。各レビューア９は、アナリスト８により提供された会社目標に照らしてコントリビューションデータを拒絶し、または受け入れることができる。このプロセスは、コントリビューションデータが組織階層の最上位レベルと結合したレビューアにより最終的に承認されるまで続き、それにより、コントリビュータからのコントリビューションデータは会社目標と確実に調和させられる。

一実施例では、ウェブブラウザ５２は、企業プランニングシステム４への通信を自動的に圧縮し、このシステムから受け取った通信を復元（decompressing）するためのインライン圧縮モジュール（inline compression module）５３を含む。特に、インライン圧縮モジュール５３は、ウェブブラウザ５２からハイパーテキストトランスポートプロトコル（HTTP）経由でシステム１０に伝送される出力バッファ（outgoing buffer）を自動的にインターセプトし、このバッファを伝送に先立って自動的に圧縮する。同様に、インライン圧縮モジュール５３は、入力HTTPバッファ（incoming HTTP buffer）をインターセプトし、このバッファが圧縮されたか否か決定する。バッファが圧縮されている場合、インライン圧縮モジュール５３は、このバッファを自動的に復元し、この復元したバッファをウェブブラウザ５２に転送する。このようにして、インライン圧縮モジュール５３は、コンピュータ装置５０と企業プランニングシステム３との間の通信の圧縮と復元をシームレスに実行し、その結果、システム２内部の効率の増進（efficiency gain）が可能となる。

一実施例では、企業プランニングシステム３は、圧縮されたHTTPバッファを受け取るために単一のアクティブサーバページ（ASP：active server page）を使用し、その圧縮されたバッファを復元と処理のために適当なビジネスロジックモジュール４６に導く。各HTTPバッファを有するヘッダは、バイトカウント、またはバッファが圧縮されているか否かを示す他の情報、および適当なビジネスロジックモジュール４６のための識別子を含むことができる。

図４は、企業データ４２が取引データ領域（transactional data area）６２と関係データ領域（relational data area）６３を含むように組織されたデータベースサーバの一実施例を図示するブロック図である。一般に、取引データ領域６２は、ユーザ１８からのリアルタイムのデータ収集とデータ集合をサポートし、一方関係データ領域６３の方は、レポート生成と複雑なデータ解析に使用される。

詳記するならば、データベースサーバ４０は、コントリビュータ６から受け取ったコントリビューションデータを取引データ領域６２に記憶し、そのコントリビューションデータを取引データ領域６２から関係データ領域６３に、例えば周期的ベースで発行（publish）する。取引データ領域６２は、企業モデルに従って階層的に関連付けられた多数のスロット（slot）６６を含む。取引データ領域６２は、コントリビュータ６から受け取ったコントリビューションデータを記憶する1組のコントリビューションスロット（contribution slot）６６、および、このコントリビューションデータから算出された集合データを、上記のモデルにより規定された階層に従ってリアルタイムで記憶する1組の集合スロット（aggregation slot）６７を含む。結果として、取引データ領域６２は、企業コントリビュータ６の各々に対して、それぞれの企業コントリビュータから受け取ったコントリビューションデータを記憶する取引スロット（transaction slot）６７を含む。加えて、取引データ領域６２Aは、各レビューア９をレビューア９に対して少なくとも１つの集合スロット６７と結合させる。例えば、１つの企業モデルが、階層的に配置されたN個のノードを有することができ、各ノードが１つのネットワークユーザを規定し、そのユーザをコントリビュータおよびレビューアの１つとして指定することができる。この構成では、取引データ領域は、各レビューアに対する集合スロットと、モデルにより規定された各コントリビュータに対する取引スロットを含むN個のスロットを含む。

図５および６は、企業プランニングモデルにより規定された階層に従った取引データ領域６６の組織を更に図示するブロック図である。図５は、架空のピザチェーン“Pizza Palace, Inc.”の例に対する企業プランニングモデルにより規定された階層の一例を描いたものである。階層７０は、水平方向において、フランチャイズにより占められた様々な地域（geographic region）、すなわち地域１から５を中心として組織され、垂直方向において３つの調和レベル（reconciliation level）に組織されている。企業の目的と目標はアナリスト８により設定され、階層の様々なノードを通じて下へ分配される。フランチャイズの個別の店（アウトレット（outlet）と呼ぶ）が最下位レベル（bottom level）、すなわち、レベルIIIを占め、コントリビューションデータを提供する。

レベルＩの各ノードは、コントリビューションデータの入力に対して責任を負う対応するコントリビュータ６を有する。同様に、レベルＩ、IIの各ノードは、アナリスト８により規定された会社目標に照らしてコントリビューションデータを調和させるためのレビューア９と結合している。簡単のために、図５は、コントリビュータの１人、アウトレットＡと結合したANDYと、地域１と結合したPETERおよびそのノードと結合したGUYの２人のレビューアを示す。本例において、GUYはPizza Palace, Inc.の最高財務責任者で、全地域を監督する責任を負う。それ故、GUYは、ルートノード（root node）２９の“オーナ”として、全地域１〜５に対する“レビューア”として挙げられる。PETERは、地域１を監督する役割を担う中間レベルのマネージャである。そこで、PETERは、地域１のオーナとして、またアウトレット（outlet）Ａのレビューアとして挙げられる。ANDYは、ローカルピザ店のマネージャで、アウトレットＡのオーナとして挙げられる。

階層７０の各ノードは、その階層内部のノードのレベルに応じて、モデルデータ４２Ｂ内部の1つ以上の対応するテンプレートと結合している。例えば、レベルIII内部の各アウトレットは、予測情報を獲得するための単一のテンプレートと結合している。レベルIIでは、各地域がその対応する子供ノード（child node）のテンプレート、すなわち、その地域内のアウトレットと結合している。それ故、階層７０のルートノード７２は、会社に対するテンプレートの全てと結合している。

図６は、Pizza Palaceに対する企業プランニングモデルにより規定された階層７０に従ってリアルタイムでのコントリビューションデータの集合をサポートするための取引データ領域６２の組織の一例を示す。本例において、取引データ領域６２は、レベルIIIの各ノードのための、すなわち、アウトレットＡ〜Ｈの各々のためのコントリビューションスロット６６を含む。各コントリビューションスロット６６は、階層７０のレベルIIIのそれぞれのノードと結合したコントリビュータ６に対するコントリビューションデータを記憶する。

同様に、取引データ領域６２は、レベルＩ、IIの各ノード、すなわちルートノード７２および地域１〜５に対応するノードのための集合スロット６７を含む。各集合スロット６７は、階層７０により規定され、また、図６に矢印で表されたように、その子供ノードに対する集合したコントリビューションデータを記憶する。例えば、集合スロット７４がルートノード７２に対応し、地域１〜５から受け取った全てのデータを合計することによって算出された集合データを記憶する。別の例として、地域２に対応する集合スロット７６は、アウトレットB〜Dに対するコントリビューションデータから算出された集合データを記憶する。こうして、取引データ領域６２は、モデルの全レベルに対するデータの正確な最新の一覧を提供し、それで、全社規模の企業プランニングを容易にする。

図７は、企業プランニングシステム３の動作を更に詳細に図示するフローチャートである。先ず、アナリスト８が企業プランニングシステム３と対話して、多次元を有する1つ以上のデータキューブを含むプランニングモデルを展開する（８０）。例えば、Pizza Palace, Inc.の場合、上記のモデルは下記の３つの次元を有する単一データキューブを規定することができる。即ち、（１）特製ピザ、例えば肉好き向き、菜食主義者向き、バーベキュー、シーフード、ハム、及びマッシュルームのピザなどをリストアップする第１の次元、（２）週間売上予測に関する第２の次元、そして、（３）会社目標に関する第３の次元である。

アナリスト８はまた、全社規模のプランニングプロセスを制御するための組織階層も規定する（８２）。例えば、Pizza Palaceの場合、アナリスト８は、図５に示す通りの１４個のノードを有する組織階層を規定することができる。アナリスト８は、各ノードに1つ以上の企業ユーザを割り当て、各ユーザをコントリビュータ、レビューア、またはその両方として指定する。加えて、アナリスト８は、各ノードと結合したユーザの１つをそのそれぞれのノードのオーナと指定することができる。

上記の組織階層を受け取ると、企業プランニングシステム３のアプリケーションサーバ２６は、その階層に照らして上記のモデルを規定された各ユーザに対して“スライス”するように処理する。換言すれば、アプリケーションサーバ２６は、あたかも階層が追加の次元であるかのようにモデルにその階層を当てはめ、各ユーザがアクセスできるモデルのそれぞれの部分を識別する。アプリケーションサーバ２６は、階層内の各ノードをモデルの他の次元全体にわたって１つのスライスと結合させる。こうしてモデルをスライスすることにより、企業プランニングシステム３は、モデル全体をユーザのリモートコンピュータ装置に通信させる必要がなくなり、モデルの1つ以上のデータキューブの関連部分と通信する必要があるのみとなる。

加えて、アプリケーションサーバは、適当な数の取引データ領域６２の集合スロット６６とコントリビューションスロット６７を作成すること、関係データ領域６３の表と関係を作成することを含めて、企業データ４２を初期化する。

次に、アナリスト８は、企業に対する目標データを提供するために企業プランニングシステム３と対話し（８６）、コントリビュータ６は、詳細な予測をコントリビューションデータの形で提供するために上記のシステムと対話する（８８）。コントリビューションデータを受け取ると、アプリケーションサーバ２６は、取引データ領域６６のコントリビューションスロット６７を更新してそのコントリビューションデータを記憶し、また、企業階層の上位レベルのノードの各々に対する集合合計（aggregate total）を記憶するために集合スロット６６をリアルタイムで更新する。

こうして、上記の集合合計は、企業４全体にわたってレビューア９に直ちに利用可能となる。結果として、レビューア９は企業プランニングシステムにアクセスでき、アナリスト８により提供された目標データに照らしてコントリビューションデータおよび集合合計を拒絶するか受け入れるかのどちらかのレビュー入力を直ちに提供する（９２）。このプロセスの間、アプリケーションサーバ２６は、レポート生成器３４による解析レポートおよび他の統計解析の生成のために（９６）、コントリビューションデータおよび集合データを取引データ領域６２から関係データ領域６３に発行する（９４）。企業プランニングシステム３は、コントリビューションデータおよび集合合計が組織階層の上位レベルのレビューアによって受け入れられるまで、この調和プロセスを繰り返す（９８）。

図８は、企業プランニングシステム３のリアルタイム集合プロセスを更に詳細に図示するフローチャートである。コントリビュータ６の１つからアクセスのリクエストを受け取ると（９９）、アプリケーションサーバ２６は企業データ４２にアクセスして、コントリビュータのためのそれぞれのコントリビューションスロットを識別する（１００）。アプリケーションサーバ２６は、識別されたスロットから、先にコントリビュータにより記憶されたどのようなコントリビューションデータをも検索し、入力テンプレート５６およびコントリビューションエンジン５４をコントリビュータ６に通信させる（１０２）。

コントリビュータ６からの新規の、または更新されたコントリビューションデータを受け取ると（１０４）、アプリケーションサーバ２６は、それぞれのコントリビューションスロットを更新してそのコントリビューションデータを記憶する（１０６）。次に、アプリケーションサーバ２６は、更新されたコントリビューションスロットに関連付けられたどのような親集合スロットについても集合スロット６６の集合合計を選択的に更新する。特に、アプリケーションサーバ２６は、規定された階層モデルに基づいて更新されたコントリビューションスロットに対する直近の親集合スロットを識別し（１０８）、更新されたコントリビューションスロットに基づいて上記の親スロットに対する新たな集合合計を計算し（１１０）、その新たな集合合計を上記の親スロットに記憶する（１１２）。アプリケーションサーバ２６は、関連するすべての上位レベルの集合スロットが更新され終わるまで、このプロセスを繰り返す（１１４）。

一実施例では、アプリケーションサーバ２６は、取引データ領域６２を、1組の横列を有する単一の表として組織する。各横列が、規定された組織階層におけるそれぞれのノードに対応する。アプリケーションサーバ２６は、それぞれのコントリビューションデータまたは集合データを各横列の中に記憶し、また、これらのデータを、データの単一の“ブロブ（blob）”を含む１つの列として記憶することができる。特に、アプリケーションサーバ２６は、与えられた1列に対するデータを単一のストリングまたはテキストまたはバイナリデータとして書き込むことができる。一実施例では、各列が、エクステンシブルマークアップ言語（XML：extensible markup language）に準じるパックされたテキストとして記憶される。パックされたXMLは、列と結合したユーザに属するモデルのスライスに対する各セル、ならびに、そのセルの現在値を記述する。取引データ領域６２を初期化するとき、アプリケーションサーバ２６は、モデルの1つ以上のデータキューブからメタデータ（metadata）を抽出し、そのモデルの各“スライス”のXML表現をそれぞれのスロットの中に作成する。

コントリビューションデータを更新するとき、XMLはユーザのリモートコンピュータ装置によって生成され得る。リモートコンピュータ装置はこのXMLを生成し、このXMLを、圧縮された形か復元された形のどちらかの形でHTTPバッファの一部として通信させることができる。その代わりに、アプリケーションサーバ２６がXMLを作成してもよい。

集合合計をリアルタイムで更新するため、アプリケーションサーバ２６は、それぞれの親集合スロットに対するXMLを構文解析（parse）して各セルの現在値を迅速に検索し、パックされたXMLを、更新された集合合計を有する新しいエントリと取り替える。集合データは、集合合計を記憶する1組のセルを有する線形アレイとしてXMLの形で記憶され得る。結果として、アプリケーションサーバ２６は、この線形アレイを１つの集合スロットから検索し、そのアレイを親集合スロットのアレイでオーバーレイし、その親スロットに対する集合合計を迅速に再計算することができる。

図９は、データを取引データ領域６２から関係データ領域６３に発行することにおけるアプリケーションサーバ２６の一動作例を更に詳細に図示するフローチャートである。アプリケーションサーバ２６は、データを周期的に、例えば１５分ごと、３０分ごとなどに発行することができる。あるいはその代わりに、または、それに加えて、アプリケーションサーバ２６は、例えば、コントリビュータ６からのコントリビューションデータの提出、レビューア９からのレビュー入力といったイベントに応答してデータを発行することができる。

上記のデータを発行するために、アプリケーションサーバ２６は、各コントリビューションスロット６７のコントリビューションデータを通過させて、1組のデータエレメントとそのそれぞれの値を識別する（１１６）。上で述べた通り、各スロット６７は、企業プランニングモデルのスライスを記述するパックされたXMLを含むことができる。アプリケーションサーバ２６は、このパックされたXMLを復元し、モデルのデータキューブの含有セル、ならびに、そのセルの現在値を識別する。

次に、上記のモデルに基づいて、アプリケーションサーバ２６は、構文解析されたコントリビューションデータに対応する関係データ領域６３から1つ以上の表を選択する（１１８）。例えば、アプリケーションサーバ２６は、予測された製品売上を記憶する売上表（sales table）を識別することができる。

最後に、アプリケーションサーバ２６は、構文解析されたデータを関係データ領域６３の上記の識別された表に書き込む。結果として、レポート生成モジュール３４は、企業４全体にわたって捕えられたコントリビューションデータに基づいて洗練されたレポートを生成し、または、同様な解析を実行するために複雑なクエリ（query）をデータベースサーバ４０に発行することができる。

図１０は、アプリケーションサーバ２６全体にわたる多数の企業プランニングモデルの配備を制御することにおけるアドミニストレーションコンソール３６の動作モードの一例を図示するフローチャートである。先ず初めに、アドミニストレーションコンソールは、1つ以上のアプリケーションサーバ２６を識別する入力を受け取る（１２２）。例えば、システム管理者は、ローカルエリアネットワーク内部で利用できるサーバのリストからアプリケーションサーバ２６を選択することができる。あるいはその代わりに、システム管理者は、アプリケーションサーバとの通信のために特定のネーム、インターネットプロトコル（IP）アドレス、または同様の通信ハンドル（communication handle）を指定することができる。

これに応答して、アドミニストレーションコンソール３６は、識別されたアプリケーションサーバに、各サーバ上に存在するコンピュータリソースの記述、例えば、各アプリケーションサーバ２６内部に存在するプロセッサの数などについて照会する（１２４）。アドミニストレーションコンソール３６は、この情報を、企業４の様々なプランニングモデルを配備することに使用するためにシステム管理者に提供することができる。

次に、アドミニストレーションコンソール３６は、各モデルを1組のアプリケーションサーバ２６に割り当てる入力をシステム管理者から受け取る（１２６）。この入力に基づき、アドミニストレーションコンソール３６は、各モデルをアプリケーションサーバのそれぞれの組と結合させる配備マップを生成し、このマップを企業データ２１内部に記憶する（１２８）。

このマッピングに基づき、ビジネスロジックモジュール４６が、企業プランニングセッションを管理するジョブを生成し、ジョブ記述をジョブデータ４２Ｃ内部に記憶する。アプリケーションサーバ２６は、上で述べたように上記のジョブ記述を読み取り、配備マップに従って処理する（１３０）。このようにして、異なる企業モデルを別個のアプリケーションサーバ２６上に配備するか、あるいは1つ以上のアプリケーションサーバを共有することができる。

上記の配備マップは、システム管理者からの入力に応答するか、または、アプリケーションサーバ２６の現在のロードレベル（current loading level）に基づいてダイナミックに調整することができる（１２６）。特に、アドミニストレーションコンソールは配備マップの再生成を命令し、これにより、アプリケーションサーバ２６のクラスタ全体にわたって企業プランニングモデルの配備の再バランスを取る。

図１１〜１９は、上で述べた架空のPizza Palace, Inc.の例示的な企業プランニングセッションの間のウェブブラウザ５２の多数の画面（view）を図示するものである。例えば図１１は、最高財務責任者（CFO）のGUYが、ピザフランチャイズに対する種々の予算の進行をチェックするために企業プランニングシステム３にアクセスするときに、ウェブブラウザ５２により表示されるウィンドウ１６０の一実施例を示す。本例においては、GUYは、マイクロソフト社のインターネットエクスプローラを使ってマクロメディア社（Machromedia Inc）の「ショックウェーブ（Shock Wave）（登録商標）」を動かして、企業プランニングシステム３にアクセスしたものである。

ウィンドウ１６０は次のものを表示する。即ち、１）所与の予算テンプレートのすべてのコントリビュータおよびレビューアにカスタマイズ可能な見出し（headline）１６２、２）命令（instructions）を表示するためのリンク１６４、３）コントリビュータの名前、および、４）現在日。企業プランニングシステム３は、新たなパスワードが作成されて別個に管理されることがないようにするセキュリティのために、リモートコンピュータ装置のオペレーティングシステムに組み込まれた認証（authentication）を使用することができる。

ウィンドウ１６０は、ピザチェーンについてアナリスト８により規定された階層モデル１３８を表示する左のフレーム１６５を含む。上で述べたように、この階層は５つの販売地域を有し、ここでは、地域２が３つのピザストア（アウトレットB〜アウトレットD）を有する。この階層は、会社の仕事の流れ（workflow）を表し、それ故、コントリビュータに直観的に認識することができる。その上、各コントリビュータは、階層モデル１３８の、この特定のコントリビュータがアクセスした部分だけを左のフレーム１６５が表示するように制限された画面を有する。GUYは、５地域すべてに対するレビューアとして規定された上位レベルの管理職であるので、階層全体を見ることができる。

右のフレーム１６６と左のフレーム１６５は、ユーザが左のフレーム１６５内部の階層内のノードを選択するとき、右のフレームが選択されたノードとその子供のノードの詳細を表示するように協働する。詳記するならば、右のフレーム１６６は、選択されたノードとその子供の各々を詳細に示す表を表示する。各表は下記のものを示す。即ち、ａ）ノード名、ｂ）そのノードの動作状態、ｃ）テンプレートの最終修正時間、ｄ）予算テンプレートがそのノードのオーナにより開かれたか否か、ｅ）オーナ／レビューアの名前、ｆ）予算テンプレートがレビューされたか否か、および、ｇ）ユーザがそのノード上で取ることができるアクション。

階層の最下位レベル（bottom level）では、各ノードが３つの仕事の流れの状態を有する。すなわち、ａ）NS：予算はスタートしていない（Not Started）、ｂ）WIP：予算は、オーナが幾らかデータを入力したが、未だ終了していないような“作業進行中（work in progress）”である、そして、ｃ）LOCKED：オーナは予算をレビューのために提出した、という状態である。一度予算が提出されると、そのオーナは、次位のレベルのレビューアがその提出を拒絶する、これは下位のラインのノードの状態を変更してWIPに戻すことで、そのようにしない限り、変更をすることができない。

ローカルピザ店のマネージャであるAndyに対する画面は、Guyの場合とまったく異なる。図１２は、Andyが企業プランニングシステム３にアクセスするときに、ウェブブラウザ５２により表示されるウィンドウ１７０の一例を示す。図１２に示す通り、Andyが見ることのできるのは、アウトレットA、すなわち、彼が責任を負うアウトレットだけである。Andyは予算計上プロセスをスタートさせていなかったので、右のフレームの表１７６はそのノードに対してNSの状態を表示している。

図１３は、AndyがアウトレットA上をクリックし、企業プランニングプロセスを開始するときに表示されるウィンドウ１８０を示す。この時点で、ウェブブラウザ５２はテンプレート５６およびデータキューブ５８をダウンロードする。これは、ネットワーク９を横断するトラフィックが存在する何回かのうちの１回である。計算エンジン５４はクライアント側にあるので、ユーザが予算計上情報を入力するにつれてウェブトラフィック（web traffic）が起こることはない。Andyは、支出予測データ１８２を入力するためにウィンドウ１８０と対話するが、アナリスト８によりセットされた目標データ１８４を更新できず、テンプレート内に埋め込まれた数式（formula）を上書きすることはできない。このように、ウィンドウ１８０により、Andyは、詳細な予測情報を入力することができる一方で、アナリスト８により設定された財務目標を見ることができる。計算エンジン５４により、ウィンドウ１８０は算術演算、条件付き論理演算、加重平均や時間平均の演算、および他の多数の演算をサポートするインテリジェントな集計表として働くことができる。加えて、アナリストは、列、欄およびページ項目のためのコンテキストに応じたヘルプ画面（context sensitive help）を提供するようにウィンドウ１８０を構成することができる。支出予測データ１８２を入力すると、Andyは情報をセーブし、その後プロセスを続行し、または、上記の予測情報をレビューのためにPeterに提出することができる。

図１４に示す通り、Andyがテンプレートをセーブすると、ウェブブラウザ５２は、そのノードの状態を“作業進行中（work in progress）”（WIP）として反映するウィンドウ１９０を表示する。この状態において、Andyは、図１５のウィンドウ２００で描かれているように、リターンして予測データを編集し続け、その予測データをPeterによるレビューのために提出することができる。一度予測データが提出されると、図１６のウィンドウ２１０によって示されるように、ノードの状態はLOCKEDに変えられる。この状態では、Peterがテンプレートをレビューし、その情報を拒絶しない限り、Andyは予測情報を修正することはできない。

図１７は、Peterが、自分が責任を負う予算情報をレビューするために企業プランニングシステム３にアクセスするときに、ウェブブラウザ５２により表示されるウィンドウ２２０の一例を示す。図1７に示す通り、Peterは、地域１のオーナで、アウトレットAに対するレビューアとして規定される。ログイン（logging in）すると、Peterは直ちに、Andyが予算情報を提出したことを通知でき、これは、ウィンドウ右手の表２２２により表示されるLOCKED状態によって反映される。加えて、地域１、すなわち、アウトレットAへの子供のノードの全てが予測情報を提出したので、表２２４は地域１の状態をREADYと表示し、Peterが予算情報のすべてをレビューできることを示す。

図１８は、レビューのためにPeterにより選択されたときのテンプレートを表示するウィンドウ２３０の一例を示す。注目すべきことは、オーナ（Andy）によりセットされた予測データ２３２および財務アナリストによりセットされた目標データ２３４を含むすべての情報が、読み取り専用で、修正できないことである。こうして、Andyはレビューアとして２つの選択肢を持つ。すなわち、（１）予測情報を拒絶し、そのグリッドを修正のためにPeterに送り戻すか、あるいは（２）テンプレートが地域１の指名レビューアであるGuyによりレビューできるように予測情報を承認するか、どちらかである。このレベルにおいて、ノードは５つの可能な状態を有する。その最初の３つはレベルIのノードと同様である。すなわち、NS（not started：スタートしなかった）、WIP（work in progress：作業進行中）、そして、LOCKEDである。加えて、より上位のレベルのノードは、INCOMPLETEおよびREADYでもあり得る。このINCOMPLETEの状態が生じるのは、少なくとも１つの子供のノードがNS状態にあるとき、すなわち、レビューアに報告をする者が予算計上プロセスをスタートさせていなかったときである。

これで、レビューア９は、テンプレートが見られていなかった場合、オーナが幾らか追加のプロンプト（prompting）を必要としていることを速やかに知らせることができる。READY状態が生じるのは、すべての子供のノードが予算計上プロセスを完了したときである。この時点では、レビューアは予算計上プロセスのクリティカルパスにあり、下位（subordinate）からのデータを拒絶するか受け入れるかどちらかをしなければならない。他のデータ収集方法にまさるこのアプローチの利点の１つは、中位レベルのマネージャが、予算計上の予測を容認して委ねられた上位レベルの管理を示す簡単かつ効果的な方法を有することである。

図１９は、PeterがアウトレットＡからの情報を拒絶するときの情報の画面の一例を示す。アウトレットＡはWIP状態に移行して戻ってしまい、従って地域１もWIP状態へ移動する。オーナのAndyは、彼のレビューアであるPeterからのｅ−メールを自動的に受け取り、何故提出が拒絶されたかの理由を知らされる。この調和プロセスは、受け入れ可能な予算情報が最終的に階層の全レベルを通じて上に伝搬されるまで続く。

図２０は、アナリスト８が、オーナを階層の様々なノードに割り当てることを含めて、企業モデルを作成し、維持するときに、ウェブブラウザ５２により提供される画面の一例を示す。図２１は、アナリストが各ノードに対するアクセスレベル（例えば、読み取り対書き込み（read vs. write））を規定するとき、ウェブブラウザ５２により提供される画面の一例を示す。

以上、本発明の様々な実施例について述べた。これらの実施例だけでなく、特許請求の範囲内の実施例は他にもある。

企業プランニングシステムがトップダウン目標と詳細なボトムアップ予測との調和を可能にし、自動化する環境を図示するブロック図である。企業プランニングシステムの一実施例を図示するブロック図である。システムと対話するためのリモートコンピュータ装置の一実施例を図示するブロック図である。企業データが取引データ領域と関係データ領域を含むように組織化されたデータベースサーバの一実施例を図示するブロック図である。企業プランニングモデルにより規定された階層に従って取引データ領域の組織の一例を図示するブロック図である。企業プランニングモデルにより規定された階層に従って取引データ領域の組織の一例を図示するブロック図である。企業プランニングシステムの動作を更に詳細に図示するフローチャートである。企業プランニングシステムにより遂行されるリアルタイム集合プロセスを更に詳細に図示するフローチャートである。データを取引データ領域から関係データ領域に掲載する1組のアプリケーションサーバの動作例を更に詳細に図示するフローチャートである。 1組のアプリケーションサーバ全体にわたって多重の企業プランニングモデルの展開を制御するアドミニストレーションコンソールの動作モードの例を図示するフローチャートである。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。例示的な企業プランニングセッション中にウェブブラウザにより提供された写真を図示する図である。

Claims

１組の企業プランニングモデルの各々をそれぞれの組のアプリケーションサーバと結合する配備マップを生成することと、
前記配備マップに従って前記のそれぞれの組のアプリケーションサーバを有する前記企業プランニングモデルでジョブを処理することと、
を含む方法。
前記配備マップを生成することは、
前記アプリケーションサーバの各々を１つ以上の前記モデルに割り当てるユーザからの入力を受け取るためのインターフェースを提供することと、
前記のユーザ入力に応答して前記配備マップを生成することと、
を含む請求項１に記載の方法。
前記ユーザ入力に応答してネットワーク内の新しいアプリケーションサーバを選択することと、
前記新しいアプリケーションサーバを１つ以上の前記モデルと結合するように前記マップを生成することと、
を更に含む請求項２に記載の方法。
前記企業プランニングモデルの各々と結合された期限に基づいて前記配備マップを調整することを更に含む請求項１に記載の方法。
前記企業プランニングモデルに参加するユーザに対する現在の使用レベルに基づいて前記配備マップを調整することを更に含む請求項１に記載の方法。
前記アプリケーションサーバの各々内のコンピュータリソースを記述するリソースデータについて前記アプリケーションサーバを紹介することと、
前記リソースデータに基づいて前記配備マップを生成することと、
を更に含む請求項１に記載の方法。
前記リソースデータは前記アプリケーションサーバの各々内の多数のプロセッサを含む請求項６に記載の方法。
前記のジョブは、前記のそれぞれのモデルによって規定された組織階層に従って前記のそれぞれの企業プランニングモデルの異なったスライスと結合される請求項１に記載の方法。
前記の各ジョブは前記企業プランニングモデルの少なくとも１つによって規定される組織階層内のノードと結合される請求項１に記載の方法。
１組の企業コントリビュータを規定する企業プランニングモデルを修正する入力を受け取ることであって、ここで、前記コントリビュータの各々は前記企業モデルの異なったスライスと結合されるものであることと、
前記コントリビュータによる企業プランニングシステムへのアクセス時に、前記入力と前記企業プランニングモデルの前記のそれぞれのスライスと結合されたデータとを前記コントリビュータのコンピュータ装置に通信することと、
前記コントリビュータの前記コンピュータ装置上で前記企業プランニングモデルのスライスを更新するための前記入力を処理することと、
を含む方法。
前記コントリビュータからコントリビューションデータを受け取ることを更に含み、ここで、前記入力を処理することは、前記コントリビューションデータを前記更新されたモデルと前記コントリビュータのコンピュータ装置上で調和させることを含む請求項１０に記載の方法。
複数のアプリケーションサーバと、
１組の企業プランニングモデルの各々を前記アプリケーションサーバのそれぞれの１組と結合させる配備マップを生成するアドミニストレーションコンソールと、
を含むシステム。
前記アプリケーションサーバは前記のそれぞれの企業プランニングモデルに対する管理ジョブを処理する請求項１２に記載の方法。
前記アドミニストレーションコンソールは、１つ以上の前記アプリケーションサーバの各々を前記企業プランニングモデルに割り当てるユーザからの入力を受け取り、かつ前記配備マップをユーザ入力に応答して生成するためのインターフェースを提供する請求項１３に記載のシステム。
前記インターフェースは、ネットワーク内の新しいアプリケーションサーバを選択する前記ユーザから入力を受け取るための入力領域を含み、前記アドミニストレーションコンソールは、前記新しいアプリケーションサーバを１つ以上の前記企業プランニングモデルと結合するための前記配備マップを生成する請求項１４に記載のシステム。
前記アドミニストレーションコンソールは、前記ジョブを、前記それぞれの企業プランニングモデルによって規定された組織階層に従って前記それぞれの企業プランニングモデルの異なったスライスと結合する請求項１３に記載のシステム。
前記アドミニストレーションコンソールは、前記の各ジョブを前記企業プランニングモデルの前記特定の最初の１つによって規定された組織階層内のノードと結合する請求項１３に記載のシステム。
前記アドミニストレーションコンソールは、前記企業プランニングモデルの各々と結合された期限に基づいて前記配備マップを自動的に生成する請求項１２に記載の方法。
前記アドミニストレーションコンソールは、前記企業プランニングモデル内に参加するユーザに対する現在の使用レベルに基づいて前記配備マップを自動的に調整する請求項１２に記載のシステム。
前記アドミニストレーションコンソールは、前記アプリケーションサーバの各々内のコンピュータリソースを記述する前記アプリケーションサーバからのリソースデータを受け取り、該リソースデータに基づいて前記配備マップを生成する請求項１２に記載のシステム。
前記リソースデータは前記アプリケーションサーバの各々内に多数のプロセッサを含む請求項１８に記載の方法。
プロッセサに、
１組の企業プランニングモデルの各々をそれぞれの組のアプリケーションサーバと結合させる配備マップを生成させ、
前記配備マップに従って前記それぞれの組のアプリケーションサーバを有する前記企業プランニングモデルでジョブを処理させるための命令を含むコンピュータ読み取り可能な媒体。
前記プロセッサに前記配備マップを生成させる前記命令は、
１つ以上の前記モデルに前記アプリケーションサーバの各々を割り当てるユーザからの入力を受け取るためのインターフェースを提供させ、
前記ユーザ入力に応答して前記配備マップを生成させる命令を含む請求項２２に記載のコンピュータ読み取り可能な媒体。
前記プロセッサに、
前記ユーザ入力に応答してネットワーク内の新しいアプリケーションサーバを選択させ、
前記新しいアプリケーションサーバを１つ以上の前記モデルと結合するための前記マップを生成させる命令を更に含む請求項２３に記載のコンピュータ読み取り可能な媒体。
前記プロセッサに、前記企業プランニングモデルの各々と結合された期限に基づいて前記配備マップを調整させる命令を更に含む請求項２２に記載のコンピュータ読み取り可能な媒体。
前記プロセッサに、前記企業プランニングモデル内に参加するユーザに対する現在の使用レベルに基づいて前記配備マップを調整させる命令を更に含む請求項２２に記載のコンピュータ読み取り可能な媒体。
前記プロセッサに、前記アプリケーションサーバの各々内のコンピュータソースを記述するリソースデータについて前記アプリケーションサーバを紹介させ、
前記リソースデータに基づいて前記配備マップを生成させる命令を更に含む請求項２２に記載のコンピュータ読み取り可能な媒体。
プロセッサに、
１組の企業コントリビュータを規定する企業プラニングモデルを修正する入力を受け取らせ、ここで、前記コントリビュータの各々は前記企業プランニングモデルの異なったスライスと結合されるものであり、
前記コントリビュータによる企業プランニングシステムへのアクセス時に、前記入力と前記企業プランニングモデルのそれぞれのスライスと結合されたデータとを前記コントリビュータに通信させ、
前記企業プランニングモデルの前記スライスを前記コントリビュータのコンピュータ装置上で更新するための前記入力を処理させる命令を含むコンピュータ読み取り可能な媒体。
前記プロセッサに、
前記コントリビュータからコントリビューションデータを受け取らせ、かつここで、前記入力を処理することは、前記コントリビュータの前記コンピュータ装置上で前記コントリビューションデータを前記更新されたモデルと調和させることを含む命令を更に含む請求項２８に記載のコンピュータ読み取り可能な媒体。