JP2008530692A

JP2008530692A - プロジェクト作業の計画／範囲変更の運営情報およびビジネス情報シナジーシステムおよび方法

Info

Publication number: JP2008530692A
Application number: JP2007555265A
Authority: JP
Inventors: エー．カレン三世アンドリュー; エー．ショースティーブン; レオニドジルバーマン
Original assignee: Volt Information Sciences Inc
Current assignee: Volt Information Sciences Inc
Priority date: 2005-02-11
Filing date: 2006-02-10
Publication date: 2008-08-07
Anticipated expiration: 2026-02-10
Also published as: MX2007009333A; EP1913534A4; AU2006213709A1; WO2006086690A3; CN101283317A; US20060190391A1; EP1913534A2; JP5172354B2; WO2006086690A2; SG159530A1

Abstract

【課題】
【解決手段】プロジェクト作業運営管理方法は、バイヤーからプロジェクト運営構成を受け取るステップと、供給者がバイヤーのために行うプロジェクト作業に関するプロジェクト作業取引データを格納するステップと、バイヤーからプロジェクト作業範囲記述書（ＳＯＷ）記録の構成を受け取るステップと、バイヤーのプロジェクトの計画／範囲記録セットの変更を処理するステップと、供給者のプロジェクトの計画／範囲記録セットの変更を処理するステップと、バイヤーの記録セットと供給者の記録セットを使って統合プロジェクトの計画／範囲記録セットの変更を作成するステップとを含む。
【選択図】図１

Description

本発明は、プロジェクト作業に関係する計画または作業範囲の変更に応じて企業経営、データ処理、ワークフローの連係および管理を電子的に容易にするコンピュータシステムおよび方法に関係する。

プロジェクト作業の見積もりとその後の運営は、作業範囲記述書（ＳＯＷ）およびプロジェクト計画活動がすべて当初の計画通りに進む場合でも極めて複雑なプロセスになりうる。しかし、多くの場合、運営活動が不可欠な計画変更（ＣＩＰ）を意味する遅延および／またはスケジュールの乱れがある。加えて、プロジェクトの開始にあたって確定する大規模な作業範囲変更（ＣＩＳ）が必要な場合もある。これらＣＩＰおよびＣＩＳ活動はプロジェクト計画の分野だけでなく、調達、供給者管理、会計、出荷および受取りにも甚大な影響を与える可能性があり、また企業全体に影響することもある。

これらＣＩＰおよびＣＩＳ活動は、プロジェクトの経費／予算、プロジェクトの時機／スケジューリング、プロジェクトの成果物／アウトプット、プロジェクト作業範囲記述書、プロジェクトの供給者の確保、プロジェクトの人的資源の確保、プロジェクト機器の受け渡し、契約条件、供給者への支払精算など（これだけには限定されない）プロジェクトに広範な影響をもちうる。そのため、これらＣＩＰおよびＣＩＳ活動を単一のアプリケーション処理環境の中で定義して、運営、管理し、それによって入札管理、発注処理、人的資源管理、資産管理、ＳＯＷプロビジョニング、伝票処理、品質保証、供給者管理、出荷／受取り、予算編成、会計、監査、および企業が協調的な作業環境の中で配置する必要のある他の特別な機能的役割といったプロジェクト作業のライフサイクルの要素を扱うプロジェクト作業の全関係者に透明性、決定サポート、運営データ処理能力、およびシナジーを提供するシステムおよび方法が必要である。

プロジェクト作業運営管理方法は、バイヤーからプロジェクト運営構成を受け取るステップと、供給者がバイヤーのために行うプロジェクト作業に関するプロジェクト作業取引データを格納するステップと、バイヤーからプロジェクト作業範囲記述書（ＳＯＷ）記録の構成を受け取るステップと、バイヤーのプロジェクトの計画／範囲記録セットの変更を処理するステップと、供給者のプロジェクトの計画／範囲記録セットの変更を処理するステップと、バイヤーの記録セットと供給者の記録セットを使って統合プロジェクトの計画／範囲記録セットの変更を作成するステップとを含む。

プロジェクトポートフォリオ記録作成方法は、プロジェクトグループの属性、バイヤー組織、および業務所有責任データを格納するようになされたプロジェクトグループ記録を作成するステップと、バイヤーのプロジェクトデータを格納するようになされた少なくとも１つのプロジェクトマスター記録を作成するステップと、プロジェクトグループ記録と少なくとも１つのプロジェクトマスター記録との対応関係を格納するステップと、少なくとも１つのプロジェクトマスター記録内に適用される従属関係を格納するステップと、プロジェクトグループに適用されるデフォルトのバイヤーの組織データおよび経営データを格納するステップとを含む。

プロジェクトの成果物記録を構成する方法は、非納入品目のプロジェクト作業活動発注書行項目を発注書成果物記録の少なくとも１つの発注書成果物行項目とを対応付けるステップと、発注書成果物記録に応じた属性データを指定するステップと、少なくとも１つのプロジェクト作業フェーズ区分記録を作成するステップと、少なくとも１つのプロジェクトフェーズ区分記録に応じた属性データを指定するステップと、発注書成果物記録の従属性を構成するステップと、マスターデータ記録への発注書成果物記録の所属を構成するステップを含む。

プロジェクトの計画／範囲変更を評価する方法は、供給者が提出するプロジェクト作業確認伝票のバイヤー決裁に対して、プロジェクト成果物の従属性とマスター記録の所属関係分析を行うステップと、予定された完了日に適合していない発注書成果物記録を特定するステップと、少なくとも１つの不適合成果物記録の選択を受け取るステップと、プロジェクトリスク通信セッションを生成するステップと、プロジェクトリスク通信パッケージを一斉配信するステップと、プロジェクトリスク通信パッケージ応答を受け取るステップと、プロジェクトリスク通信パッケージ応答を処理するステップとを含む。

プロジェクトの計画／範囲変更を処理する方法は、プロジェクトの計画／範囲変更承諾パッケージを作成するステップと、プロジェクトの計画／範囲変更承諾パッケージを一斉配信するステップと、一斉配信されたプロジェクトの計画／範囲変更承諾パッケージを完成まで処理するステップと、一斉配信されたプロジェクトの計画／範囲変更承諾パッケージを完成して提供するステップとを含む。

統合プロジェクト計画／範囲変更の記録セットを作成する方法は、少なくとも１つのプロジェクト計画／範囲変更の変更指示書を作成するステップと、少なくとも１つのプロジェクト計画／範囲変更の変更指示書を処理するステップと、少なくとも１つのプロジェクト計画／範囲変更の変更指示書の承認に対し少なくとも１つのマスターデータ記録を処理するステップと、少なくとも１つの処理したマスターデータ記録を更新するステップとを含む。

本出願の多数の進歩的な教唆を例示的な実施例を具体的に参照して説明する。しかし、これら実施例は本明細書の進歩的な教唆の数多くの有利な用途のごくわずかな例をあげているにすぎないことは理解されるべきである。全般的に、本出願の明細書でなされる記述は必ずしも請求される様々な発明の範囲を一切限定しない。また、一部の記述はいくつかの発明に関する特徴に適用されるが、他の発明に関する特徴には適用されないこともある。

本発明の実施例によると、ベンダーとは商品および／またはサービスのあらゆる提供者であり、バイヤーとは商品および／またはサービスのあらゆる購入者であり、請負人とはベンダーがプロジェクト作業のために採用するリソースであり、管理者とは第三者のシステム管理者またはバイヤーが採用するプロジェクト管理者である。バイヤーはベンダーからある特定の商品および／またはサービス（以下、プロジェクトという）について、プロジェクトの種類に関連する予め定めた入札項目のリストから生成する入札依頼書を使ってバイヤーが指定する形式で入札を要請できる。そのため、ベンダーから提出される応札書はすべて同じ形式として、応札の能率的かつ効率的な評価を可能にする。本発明の実施例はさらに入札プロセスをプロジェクト管理に結び付けて、バイヤー、ベンダー、請負人、および管理者が落札後のプロジェクトの遂行を追跡できるようにする。

本発明の原理によるコンピュータで使えるシステムおよび方法は、プロジェクト作業の活動を、企業組織がプロジェクト自体に参加しない場合でも、他の企業組織および要員と
結びつけるために提供される。企業が計画／範囲変更に適用されるリスクを制限し、作業範囲記述書（ＳＯＷ）従属性モデル化と協調的なワークフロー処理を通してデータ処理および経営努力を最適化するのを可能にするプロジェクトの計画／範囲変更（ＰＣＩＰ／Ｓ）運営管理機能を提供する。

典型的な実施例は、１）プロジェクト管理構成、２）プロジェクト作業取引データの取得と記憶、３）ＳＯＷ記録構成、４）ＰＣＩＰ／Ｓ影響モデル化、５）リスク通信セッション、６）ＰＣＩＰ／Ｓ承諾パッケージセッション、および７）ＰＣＩＰ／Ｓ記録修正管理のためのプロセスを含む。

典型的な実施例の様々なプロセスは、以下のアプリケーションコンポーネントおよび機能によってサポートできる。

ａ）バイヤー・エンティティが次の一または複数の機能を行うことを可能にするプロジェクト運営管理スキーマおよびアプリケーションツールコンポーネント。１）プロジェクトグループ記録の作成、２）プロジェクトマスター記録の作成、３）プロジェクトマスター記録とプロジェクトグループとの対応付け、４）プロジェクトグループ内のプロジェクト間の関係の定義（プロジェクト階層）、５）様々なビジネス属性とプロジェクトグループおよびプロジェクトとの対応付け、６）ＳＯＷ記録の作成、７）ＳＯＷ記録とプロジェクトとの対応付け、８）ＳＯＷ記録同士の対応付け、９）対応付けたＳＯＷ間の関係の定義、１０）バイヤー・エンティティ内のビジネスイベントに関する記録の作成、１１）ビジネスイベント記録とプロジェクトとの対応付け、１２）ビジネスイベント記録とＳＯＷとの対応付け、１３）予算グループ記録の作成、１４）予算マスター記録の作成、１５）予算マスター記録と予算グループ記録との対応付け、１６）予算マスター記録とプロジェクト記録との対応付け、１７）予算マスター記録とＳＯＷ記録との対応付け、１８）契約記録の作成、１９）、契約記録とプロジェクト記録との対応付け、２０）契約記録とＳＯＷ記録との対応付け、２１）資産グループ記録の作成、２２）資産マスター記録の作成、２３）資産マスター記録と資産グループ記録との対応付け、２４）資産マスター記録とＳＯＷ記録との対応付け。

ｂ）ＳＯＷサブモジュールを介してプロジェクト運営管理スキーマをプロジェクト作業ソリューションのライフサイクルプロセスにリンクするアプリケーション機能。ライフサイクルプロセスとは、１）ＲＦｘ入札、応札、落札、２）購入申請（ＳＯＷエレメント）、３）発注（ＳＯＷエレメント）４）伝票（供給者はバイヤーにＳＯＷエレメントが完了したことを承認／検証するよう要求する）、５）インボイス発行（バイヤー・エンティティ承認済み伝票に適用される体系的に抽出した伝票明細）、６）支払い、７）報告である。

ｃ）バイヤー・エンティティに次のことを可能にする運営管理スキーマおよびアプリケーションツール。１）プロジェクト運営管理モジュール内に記録を管理／構成すること、２）関連／従属プロジェクト、関連／従属ＳＯＷエレメント、および関連／従属ビジネス記録の従属性の識別／報告出力機能を表示すること、３）特定のＳＯＷ記録を選択し、例えば、状態または予想完了日などの記録の状況もしくは属性データを修正して、以前のユーザ構成に基づいて、関連ビジネス記録への影響を示すシステム診断リスクレポートを生成することで、診断リスクレポートの出力は典型的には、影響を受ける成果物、サービス単位、商品／出荷、プロジェクトフェーズ区分、人的資源の割り当て、発注／キャッシュフロー計画、予算編成／見越項目、関連ビジネスイベント、契約、資産管理、供給者、およびユーザを調査する、４）通信セッションを作成することによって、影響を受けるプロジェクト作業関係者に問題のあるＳＯＷエレメントおよびプロジェクトに適用される情報を提供でき、通信はユーザ構成と構成される一斉配信された具体的な記録によってマクロ
モードもしくはミクロモードで、問題のあるＳＯＷエレメントに適用できる双方向データ処理機能を可能にするような方法で一斉配信できること、５）相互に合意した通信セッションの記録をアプリケーションのＳＯＷエレメント、発注、その他に関連する記録を体系的に更新するように処理するとともに、通信記録および上書きされたＳＯＷエレメント、発注、その他に関連する記録の履歴を維持すること、６）仮定されるＳＯＷ記録の状況／状態の種類の変更を前提として記録セットのグローバル／マクロ状況／状態コードの変更を体系的に開始すること、７）仮定される状況／状態の種類の変更を前提として記録セットのグローバル／マクロ記録属性変更を体系的に開始すること、８）体系的な記録の更新修正に際し影響を受ける関係者に通知を送ること、９）問題のあるＳＯＷエレメントに適用できる、関係あるＲＦｘ応札記録からなるレポートを体系的に生成すること、１０）一斉配信できる新規ＲＦＸ入札の作成にＲＦｘ入札項目エレメントおよびＲＦｘ応札項目エレメントを体系的に利用するとともに、元のＳＯＷエレメントおよび関係にスレッドバックするデータベース記録を保持すること、１１）体系的に供給者の応札書を受領、レビュー、分析し、新規発注書を出すとともに、元のＳＯＷエレメントおよび関係にスレッドバックするデータベース記録を保持すること、１２）発注書ＳＯＷエレメントの統合にあたり、新規ＲＦｘを処理するためにＲＦｘ記録の詳細を利用した未達／元のＳＯＷエレメントに適用されるすべての過去の対応関係と従属性を、作業範囲記述書のサブモジュールを介して体系的に引き継ぐこと１３）ＰＣＩＰ／Ｓ運営ツールで従属性および関係を引き継いだＳＯＷ記録の編集／修正機能をバイヤーユーザに使用可能にすること。

ここで図面を参照すると、図１は本発明に関わる入札プロセスの高次機能図である。バイヤー５０からある特定の入札依頼書２００に対応する入札依頼データ２１０をプロジェクト入札管理システム３０に提供する。バイヤー５０は個人、事業体、またはプロジェクトの遂行を依頼するあらゆる他の形態のバイヤー５０でありうる。プロジェクト入札管理システム３０で受信された入札依頼データ２１０は、バイヤー５０が事前に指定するフォームである。例えば、フォームはそのプロジェクトの種類の所定の構成可能なあらかじめ決められた入札項目リストから選択した一または複数の入札項目を含むことができ、入札依頼データ２１０はこれら選択された入札項目のうち一または複数に関係付けることができる。

入札依頼データ２１０はプロジェクト入札管理システム３０でフォーマット化して、それぞれの応札書２２０の要請のために一または複数のベンダー１０ａ．．．１０ｎに入札依頼書２００として送信する。例えば、ベンダー１０は個人１０ａ、事業体１０ｂ、または依頼されるプロジェクトを遂行できるあらゆる他のベンダー１０ｎとなりうる。応札書２２０はベンダー１０からレビューのためにプロジェクト入札管理システム３０に提出された後、適格な応札書２２０１をバイヤー５０に転送する。例えば、プロジェクト入札管理システム３０は、ベンダーに依頼される応札項目を指定のデータフォーマットで記入させて、システム３０がベンダーの応札書２２０をある程度フィルタリングするように事前構成してもよい。このように、システム３０は、バイヤー５０が入札の評価に必要なデータを備える応札書２２０だけを確実に受領するようにできる。

本発明の実施例によると、プロジェクト入札管理システム３０は、図２Ａに図示するようにコンピュータシステム１００の内部に実装できる。ユーザ５はデータネットワーク４０のウエブブラウザ２０からコンピュータシステム１００に入る。ユーザ５はベンダー１０、バイヤー５０、管理者８０（例えば、第三者の管理者またはバイヤーが雇用する管理者）、またはプロジェクトに割り当てられた請負人１５とのあらゆる関係者を含む。制限ではなく例として、データネットワーク４０はインターネットまたはイントラネットでよく、ウエブブラウザ２０は利用可能なあらゆるウエブブラウザまたはデータネットワーク４０へのアクセスを提供するあらゆる種類のインターネットサービスプロバイダー（ＩＳＰ）接続でありうる。ベンダーであるユーザ５はベンダー・ブラウザ２０ｂからコンピュ
ータシステムにアクセスし、バイヤーであるユーザ５はバイヤー・ブラウザ２０ａからコンピュータシステムにアクセスし、請負人であるユーザ５は請負人ブラウザ２０ｃからコンピュータシステムにアクセスし、管理ユーザ５は管理ブラウザ２０ｄからコンピュータシステムにアクセスする。ユーザ５は、ウエブページをそれぞれベンダー・ブラウザ２０ａ、バイヤー・ブラウザ２０ｂ、請負人ブラウザ２０ｃ、管理ブラウザ２０ｄにプッシュできるウエブサーバ１２０または１２５からコンピュータシステム１００にアクセスする。

入札ウエブサーバ１２０は、ベンダー１０、バイヤー５０、請負人１５、および管理者８０がベンダー１０、バイヤー５０、請負人１５、および管理者８０に関係するデータを維持するデータベースシステム１５０にインターフェースすることを可能にする。ベンダー１０、バイヤー５０、請負人１５、および管理者８０の各々に関係するデータはデータベースサーバ１５０内の単一データベース１５５、複数の共有データベース１５５、または個別データベース１５５にセキュリティおよび便宜のために格納でき、便宜上説明されている。例えば、データベースシステム１５０は、バイヤー５０、ベンダー１０、管理者８０、および請負人１５の場所および選好によって、一または複数の場所に配信できる。

ベンダーユーザ５のユーザインターフェースは、ベンダー・モジュール１１５を経由して入札ウエブサーバ１２０が提供する。例えば、ベンダー・モジュール１１５はそのベンダーのデータベース１５５ｂに格納されるデータを使ってベンダー・ブラウザ２０ｂにプッシュされるウエブページを移すことができる。バイヤーユーザ５のユーザインターフェースは、バイヤー・モジュール１１０経由で入札ウエブサーバ１２０が提供する。例えば、バイヤー・モジュール１１０はそのバイヤーデータベース１５５ａに格納されるデータを使ってバイヤー・ブラウザ２０ａにプッシュされるウエブページを移植することができる。請負人ユーザ５のユーザインターフェースは、請負人モジュール１３０を経由してウエブサーバ１２０が提供する。例えば、請負人モジュール１３０は請負人データベース１５５ｃに格納されるデータを使って請負人ブラウザ２０ｃにプッシュされるウエブページを移植することができる。管理ユーザ５のユーザインターフェースは、管理モジュール１３５を経由して入札ウエブサーバ１２０が提供する。例えば、管理モジュール１３５は管理者データベース１５５ｄに格納されるデータを使って管理ブラウザ２０ｄにプッシュされるウエブページを移植することができる。ベンダー・モジュール１５５、バイヤー・モジュール１１０、請負人モジュール１３０、および管理モジュール１３５は各々がベンダー・モジュール１１５、バイヤー・モジュール１１０、請負人モジュール１３０、および管理モジュール１３５の機能を行うのに必要なあらゆるハードウェア、ソフトウェア、および／またはファームウェアを含むことができ、入札ウエブサーバ１２０の一部として、または追加サーバ（図示せず）内に実装できる。

コンピュータシステム１００はさらに管理ウエブサーバ１２５経由で管理ユーザ５との追加ユーザインターフェースを提供する。管理ウエブサーバ１２５は管理者８０がコンピュータシステム１００に登録されるベンダー１０、バイヤー５０、および請負人１５に関係するデータを維持するトップレベル・データベース１６０にインターフェースすることを可能にする。例えば、トップレベル・データベース１６０はベンダー資格審査データ１６２、バイヤー定義のベンダー基準データ１６４、請負人異動データ１６６を維持できる。

ベンダー１０に関係する情報にアクセスするには、管理ウエブサーバ１２５はベンダー・モジュール１４５を使って、ウエブページをベンダー１０に関係する管理ブラウザ２０ｄにプッシュする。例えば、ベンダー・モジュール１４５はある特定のバイヤー５０またはある特定の業界に適したベンダー１０の資格審査をするためにベンダー資格審査情報１６２にアクセスできる。同様に、管理ウエブサーバ１２５はある特定のバイヤー５０に適
したベンダー１０の資格審査をするために、バイヤー・モジュール１４０からバイヤー定義のベンダー基準情報１６４に関係する管理ブラウザ２０ｄにウエブページをプッシュできる。請負人モジュール１４８は管理者８０が入札サーバ１２０から請負人１５が入力し、請負人のデータベース１５５からトップレベル・データベース１６０に引き出した請負人異動データ１６６にアクセスできるようにする。異動データ１６６は、例えば、請負人の移動の可否、希望の地理的領域、請負人のスキル、希望の賃金、および管理者８０がバイヤー５０に適したベンダー１０の資格審査をするのに役立てられるその他請負人の情報を含むことができる。

図２Ｂに図示する別の実施例では、コンピュータシステム１００はバイヤーのネットワークだけに実装する。図２Ｂでは、ベンダーユーザ５は、図２Ａと同様、データネットワーク４０を経由してベンダー・ブラウザ２０ｂからコンピュータシステムに入る。しかし、図２Ｂのウエブサーバ１２０は単一のバイヤーが制御、操作するバイヤー・ウエブサーバである。データベースシステム１５０はその特定のバイヤーに関係するバイヤーのデータとその特定のバイヤーに直接関係あるベンダー、請負人、および管理者のデータのみを格納する。例えば、データベースシステム１５０には、バイヤーが適格ベンダーのみのベンダー資格審査データを格納する。

ここで図３Ａを参照すると、コンピュータシステム１００を実装するための例示的な物理的ネットワーク機器が図示される。ベンダーユーザ、バイヤーユーザ、請負人ユーザ、または管理ユーザは、それぞれコンピュータ６０ａ、６０ｂ、６０ｃまたは６０ｄをデータネットワーク４０に接続することによって、コンピュータシステム１００のウエブサーバ１２０にアクセスする。各コンピュータ６０ａ〜６０ｄは、例えば、パーソナルコンピュータ、ラップトップ型コンピュータ、データネットワークにリモートアクセスするために無線デバイスに接続したコンピュータ、データネットワークにアクセスできるウエブブラウザ装備の携帯無線デバイス、またはウエブブラウザを実装する他の種類のマシンでありうる。ウエブサーバ１２０は、例えば、マイクロソフト社のインターネット・インフォメーション・サービス（ＩＩＳ）サーバでありうる。ウエブサーバ１２０はユーザの種類によって適切なデータベースシステム１５０に接続する。データベースシステム１５０は、例えば、１つ以上のＳＱＬサーバに実装できる。

ここで図３Ｂに移ると、コンピュータシステム１００の物理的ネットワーク機器に実装する例示的な機能が図示されている。ユーザコンピュータ６０はコンピュータの記憶媒体６４内に内蔵するウエブブラウザ６６を使ってデータネットワーク４０にアクセスできる。例えば、記憶媒体はディスクドライブ、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、コンパクトディスク、フロッピーディスク、テープドライブ、またはあらゆる他の種類の記憶媒体でありうる。コンピュータ６０内のプロセッサ６２（例えば、マイクロプロセッサまたはマイクロコントローラ）がウエブブラウザ６６にロード、ランして、データネットワーク４０にアクセスする。

ウエブサーバ１２０のユニフォーム・リソース・ロケーター（ＵＲＬ）をコンピュータに入力すると、コンピュータ６０とウエブサーバ１２０との接続が確立する。ウエブサーバ１２０は、ユーザがユーザインターフェースデバイス６５上で見るためにウエブページ６１をコンピュータ６０にプッシュする。ある実施例では、ユーザインターフェースデバイス６５はコンピュータ６０に接続したコンピュータのスクリーン１５である。例えば、ユーザが認証されたら（例えば、ユーザ名とパスワードを入力することによって）、ユーザはコンピュータのスクリーン６５上の一または複数のウエブページ６１を見ることができ、各ウエブページにはユーザが様々な情報をコンピュータシステム１００に入力するためのプロンプトが含まれている。ユーザは、Ｉ／Ｏインターフェース６８と、例えば、マウス、キーボード、ライトペン、タッチスクリーン（図示せず）、または音声認識ソフト
ウェア（図示せず）などのあらゆる種類の入力デバイス７０を使って、データネットワーク４０経由でウエブサーバ１２０に送信するためにコンピュータ６０に情報を入力できる。

ウエブサーバ１２０では、プロセッサ（例えば、マイクロプロセッサまたはマイクロコントローラ）は、記憶媒体６４に関連して上記説明したあらゆる種類の記憶媒体でありうる記憶媒体１２４内に格納するソフトウェア・モジュール１２８に内蔵のコンピュータ命令にロードして、それを実行する。コンピュータ命令はオブジェクト指向型プログラミング技術を含めあらゆる種類のプログラミング技術を使って作成できる。例えば、ソフトウェア・モジュール１２８はベンダー・モジュール、バイヤー・モジュール、請負人モジュール、および管理モジュール（図２Ａおよび２Ｂに図示）のコンピュータ命令を内蔵して、それぞれベンダーユーザ、バイヤーユーザ、請負人ユーザ、および管理ユーザ用のウエブページ６１を移植する。コンピュータ・ユーザがウエブサーバ１２０にログインすることによって、プロセッサ１２２は適切なソフトウェア・モジュール１２８にアクセスしてコンピュータ・ユーザに対応するデータベースシステム１５０を判断し、コンピュータ６０のコンピュータ・スクリーン６５上に表示するウエブページ６１に移植するためにコンピュータ・ユーザに関係するデータを検索する。さらに、ソフトウェア・モジュール１２８はコンピュータ・ユーザから受け取ったデータをデータベースシステム１５０内に格納するように構成することもできる。

バイヤーユーザ、ベンダーユーザ、請負人ユーザ、管理ユーザに表示されるウエブページ６１の例を、それぞれ図４Ａ〜４Ｄに図示する。図４Ａは、バイヤーユーザがログインして認証されたら（例えば、チャレンジ・レスポンス認証）バイヤーユーザに表示されるサンプルのバイヤー用ホームページ６１ａを図示する。図４Ａから分かるように、バイヤー用ホームページ６１ａでバイヤーユーザに利用できる多数のシステム特徴がある。例えば、バイヤーユーザにはシステム内の自分の個人プロフィールを更新するリンク、ＲＦＰ／ＲＦＱ（本明細書では、入札依頼書という）を作成するリンク、現在の入札依頼書を管理するリンク、ベンダーの応札書を承認してある特定のベンダーに落札する（プロジェクトを与える）リンク、現在のプロジェクトを処理するリンク、過去の入札依頼書を見るリンク、または伝票処理システムにアクセスして請負人のタイムカードなど様々なプロジェクト関連のイベント追跡要求を見るリンクを提供できる。バイヤーユーザはさらにシステム修正に関して更新状態を維持し、システムから操作方法に関する説明を受け、バイヤー用ホームページ６１ａから支援を受けるためにシステム管理者（たとえば、第三者の管理者またはバイヤーが雇用する管理者）に連絡することができる。

図４Ａでは、バイヤーユーザにはさらに、ホームページ６１ａで未完了の入札およびプロジェクトの現在の状態が提示される。しかし、現在の活動はホームページ６１ａの代わりに、その後のウエブページで表示できることは理解されるべきである。例えば、バイヤーユーザには公開入札依頼書（提出済みの入札依頼書）の数、一時保存した入札依頼書（作成されたがまだ提出されていない入札依頼書）の数を提示できる。公開入札依頼書のボタンをクリックすると、バイヤーユーザは公開入札依頼書のリンクを表示する別のウエブページにリンクでき、公開入札依頼書のリストにはその後実際の公開入札依頼書を含むウエブページへのリンクがある。そのため、バイヤー用ホームページ６１ａから、バイヤーユーザはバイヤーユーザがアクセス権をもつ入札またはプロジェクトに関するあらゆる情報にリンクできる。

図４Ｂは、ベンダーユーザが利用できる多数のシステム特徴を含むサンプルのベンダー用ホームページ６１ｂを図示する。例えば、ベンダー用ホームページ６１ｂはベンダーの事業概要（例えば、ベンダーが提供する商品および／またはサービスの種類）を更新するリンク、受け取った入札依頼書に応答するリンク、現在のプロジェクトを処理するリンク
、または伝票処理システムにアクセスして現在のプロジェクトイベントの完成要求を見たり、もしくは新規プロジェクトイベントの完成要求を処理するリンクを提供できる。図４Ｂでは、ベンダーユーザには未完了の入札およびプロジェクトの現在の状態も提示する。例えば、ベンダーユーザはベンダーが応答する必要のある入札依頼書の数、およびベンダーがまだ記入し終わっていない一時保存した応札書の数を判断できる。ベンダー用ホームページ６１ｂから、ベンダーユーザはベンダー応札書を記入するための追加ウエブページ、または新たに受け取った入札依頼書にアクセスしてベンダーの応札を始めるための追加ウエブページにリンクできる。

図４Ｃは、請負人が利用できる多数のシステム特徴を含むサンプルの請負人用ホームページ６１ｃを図示する。例えば、初めて請負人ユーザが請負人用ホームページ６１ｃに入るとき、請負人ユーザにシステム内の他の情報にアクセスする前に様々な非雇用労働者合意書に同意するよう指示できる。非雇用労働者合意書をそれぞれ請負人ユーザに対して表示でき、続行する前に請負人ユーザに合意書の条件に同意もしくは他の形で受け入れるようプロンプト表示できる。請負人ユーザが合意書のすべてを記入したら、請負人ユーザは作業時間記録システムにアクセスして、請負人の作業時間を記入し、自身の経歴を更新し、または移動の可否を提出できる。さらに、要請される面接の数または追加プロジェクトに予定される面接の数など、請負人ユーザに関連する現在の活動も請負人用ホームページ６１ｃで請負人ユーザに対して表示できる。

図４Ｄは、管理ユーザに利用できる多数の特徴を含むサンプルの管理者用ホームページ６１ｄを図示する。例えば、管理ユーザはバイヤー、ベンダー、または請負人に関する情報にアクセスでき、承認の必要な入札依頼書を含むウエブページにリンクでき、応札書を承認してある特定のベンダーに落札することができ、現在のプロジェクトを処理でき、または伝票処理システムにアクセスして請負人のタイムカードなど、プロジェクト活動の承認を求める現在のベンダー／請負人からの要請を見ることができる。さらに、管理ユーザの現在の活動も管理者用ホームページ６１ｄに表示できる。例えば、承認待ちの入札依頼書の数、新規入札依頼書の数、およびベンダーの新規応答の数を管理ユーザに表示できる。管理者用ホームページ６１ｄから、管理ユーザは管理ユーザがアクセスできる入札プロセスまたはプロジェクト管理に関わるあらゆる情報にリンクできる。例えば、管理ユーザが第三者の管理者の場合、管理ユーザはシステムに登録される全バイヤーおよびベンダーの入札およびプロジェクトにアクセスできる。しかし、管理ユーザがバイヤーの雇用する管理者の場合、管理ユーザはその特定のバイヤーに関連する入札およびプロジェクトにしかアクセスできない。

本発明のプロジェクト入札管理システムが扱う入札／プロジェクトプロセス５００の例示的なステップを図５に示す。入札依頼書を提出する前に扱うべき入札／プロジェクトプロセスの側面がいくつかある（ステップ５０５）。例えば、図６および７に関連して以下詳細に説明するように、バイヤーは入札要請中の処理時間を短縮するために、特定の入札依頼の種類に適格なベンダーのリストを作成したいかもしれない。別の例として、図８〜１４に関連して以下詳細に説明するように、バイヤー、ベンダー、および管理者は入札／プロジェクトのプロセス中にメッセージおよび情報を効率的に送付するために、入札／プロジェクトプロセスの様々な構成要素を取りまとめる特定の要員を指名したいかもしれない。

入札前活動のすべてが完了したら（ステップ５１０）、図１５〜２９に関連して以下詳細に説明するように、バイヤーはプロジェクトの入札依頼書を作成して（ステップ５２０）、図２０に関連して以下詳細に説明するように、必要なら、承認を受けるために入札依頼書を管理者に提出できる（ステップ５２５）。ほとんどの会社では、予算上の目的で応札書の承認を必要とする。しかし、バイヤーが個人もしくは小企業の場合、入札依頼書を
作成するバイヤーユーザは入札依頼書の提出に対して他の関係者からの承認を必要としないかもしれない。

入札依頼書が承認されたら、図２３に関連して以下詳細に説明するように、入札依頼書を適格ベンダーに一斉配信し（例えば、電子メールでオプションの通知を添付してシステムからベンダーに利用できるようにする）（ステップ５３０）、ベンダーからの応札を要請する（ステップ５３５）。図３２および３３に関連して以下詳細に説明するように、応札書の各々をバイヤーが評価して、どのベンダーの応札書が最も参加要件を満たしているかを判断する（ステップ５４０）。バイヤーがプロジェクトにある特定のベンダーを選定した後、バイヤーとベンダーは契約の最終条件を交渉し（ステップ５４５）、図３７に関連して以下詳細に説明するように、プロジェクト追跡のためにこれら条件をシステムにロードできる（ステップ５５０）。その後、ベンダーはプロジェクトに合った具体的なリソース（請負人）を選定し、プロジェクトの条件によりリソースについてバイヤーの承認が要求されるなら、図３８に関連して以下詳細に説明するように、プロジェクトを進める前にバイヤーは割り当てられたリソースのすべてを承認する（ステップ５５５）。

入札活動のすべてが完了してしまえば（ステップ５１５）、さらにシステムはプロジェクトの進行中のプロジェクトの遂行および伝票の支払いを追跡する入札後活動（ステップ５６０）を扱える。例えば、図４３に関連して以下詳細に説明するように、ベンダーとプロジェクトに割り当てられた請負人は作業時間および経費をシステムに入力して（ステップ５６５）、システム経由でバイヤーに提出する支払伝票を生成できる。図４９に関連して以下詳細に説明するように、バイヤーおよび／または管理者は伝票を受け取ったら、伝票をレビューしてベンダーへの支払いを承認する（ステップ５７０および５７５）。図３９および４０に関連して以下詳細に説明するように、ベンダーの遂行をプロジェクト終結まで追跡するために他のプロジェクト追跡パラメータもシステムに入力できる（ステップ５８０）。ここで、入札／プロジェクトのプロセスの主な構成要素の各々（入札前活動、入札活動、入札後活動）を以下個別に論じる。加えて、入札／プロジェクトのプロセス中に収集したデータの分析および報告も以下個別に論じる。
入札前活動
前述したように、バイヤー５０は提出する各入札依頼書に要する処理の量を減らすために、特定のプロジェクトの種類に適したベンダー１０の参加資格を事前審査したいことがある。ここで図６を参照すると、バイヤーがベンダーの資格審査をしやすくするために、コンピュータシステム１００はバイヤー５０がベンダーに関してバイヤー定義のベンダー基準データ１６４を定めて、バイヤー定義のベンダー基準データ１６４をマスターバイヤーリスト１６１のトップレベル・データベース１６０内に格納できるようにする。コンピュータシステム１００はさらにベンダー１０から適切なベンダー資格審査データ１６２を取得して、ベンダー資格審査データ１６２をマスターベンダーリスト１６３のトップレベル・データベース１６０に格納できる。

例えば、ベンダー資格審査データ１６２はベンダー１０が提供する具体的な商品および／またはサービス、およびベンダー１０がこれら商品および／またはサービスを供給できる具体的な地理的領域を識別できると同時に、ベンダーの規模、ベンダーが保険に入っているかどうか、ベンダーがある業界内で認証されているかどうか等などの他のベンダー情報も識別できる。バイヤー定義のベンダー基準データ１６４はバイヤー５０が望む具体的な商品および／またはサービス、バイヤー５０が商品および／またはサービスが欲しい具体的な地理的領域、および望ましいベンダーの規模、不可欠なベンダーの保険の加入、不可欠なベンダーの証明書等などの他のバイヤーの制約条件を識別できる。

ベンダー資格審査データ１６２とバイヤー定義のベンダー基準データ１６４に基づいて、コンピュータシステム１００はどのベンダー１０がバイヤー５０に必要な適性を備えて
いるかを判断し、適格ベンダー情報１７０（例えば、名前、住所、およびバイヤーが必要なあらゆる他のベンダー情報）をレビューのためにバイヤー５０に提供する。バイヤー５０または任意で管理者８０がベンダー１０を承認する場合、バイヤー５０はベンダー情報１７０をベンダーリスト１５８に追加でき、バイヤーのデータベース１５５ａに格納される。さらに、バイヤー５０が以前に資格審査したベンダー１０のベンダー情報１７２もベンダーリスト１５８に格納できる。また、バックアップおよび更新のために、ベンダーリスト１５８のマスターコピー（すなわち、バイヤー用マスターベンダーリスト１６５）をトップレベル・データベース１６０に格納できる。

バイヤーリスト１５９に格納するために、バイヤー情報１７４（例えば、名前、住所、およびバイヤーが提供に同意する他の情報）もベンダーのデータベース１５５ｂにダウンロードできる。さらに、バックアップおよび更新のために、バイヤーリスト１５９のマスターコピー（すなわち、ベンダー用マスターバイヤーリスト１６７）をトップレベル・データベース１６０に格納できる。しかし、コンピュータシステム１００をバイヤーのネットワークにのみ実装している場合、トップレベル・データベース１６０はマスターコピー１６５および１６７に格納せず、バイヤー５０はバイヤー５０が知っているベンダー情報１７２またはベンダー１０がバイヤー５０に直接提供するベンダー情報１７２のみを使ってベンダーの資格審査を行うことになろう。ベンダー資格審査データ１６２およびバイヤー定義のベンダー基準データ１６４に基づくバイヤー５０に適したベンダー１０の資格審査の十分な説明については、同時係属出願で、本発明の譲受人に譲渡された米国特許出願番号第１０／１４１，８０１号を引用し、同特許出願はその全体を参照により本明細書に組み込む。

バイヤーに適したベンダーの資格審査をする例示的なステップを図７に示す。バイヤー定義のベンダー基準情報を定めて（ステップ７００）、ベンダーからベンダー資格審査情報を受け取ったら（ステップ７１０）、バイヤー定義のベンダー基準情報をベンダー資格審査情報と比較して（ステップ７２０）、ベンダー資格審査情報がバイヤー定義のベンダー基準情報と一致するかどうかを判断する（ステップ７３０）。一致すれば、ベンダーとバイヤーに一致したことを通知し（ステップ７４０）、バイヤーがベンダーを承認すれば、後で入札依頼書の作成で使うために、ベンダーに関連するベンダー情報をバイヤーのベンダーリストに格納する（ステップ７５０）。さらに、入札依頼書を受け取って、応札書を作成するときに参照するために、バイヤー情報をベンダーのバイヤーリストに格納できる（ステップ７６０）。

しかし、ベンダー資格審査情報がバイヤー定義のベンダー基準情報と一致しなければ（ステップ７３０）、システムはバイヤーに適したベンダーの資格審査をするのに追加のベンダー資格審査情報が必要かどうかを判断する（ステップ７７０）。必要なら、この追加ベンダー資格審査情報を提供するようにベンダーに要請して（ステップ７８０）、バイヤーに適したベンダーの資格審査をする（ステップ７１０）。そうでなければ、そのベンダーはバイヤーに適した参加資格を有しておらず（ステップ７９０）、そのベンダーはバイヤーリストに追加しない。

バイヤーに適したベンダーの資格審査をすることに加えて、ベンダー、バイヤー、および管理者は複数のユーザのプラットフォームにわたる通信、データ、取引の処理を同期させるために、入札／プロジェクトのプロセスの様々な側面をとりまとめる一定の要員を指名したいかもしれない。例えば、ここで図８を参照すると、典型的に入札／プロジェクトのプロセスには、入札／プロジェクトのプロセスの運営および管理を容易にする広範な範囲の情報処理および職務部署を含める必要がある。当該情報処理は、例えば、入札依頼書の一斉配信、ベンダーの応札書、入札の決裁（評価および落札）、リソース提出書類、タイムカードの提出、成果物の追跡、および支払伝票作成が含まれうる。これら情報処理の
構成要素の各々は、ＣＯＯ、人事部、プロジェクトユーザ、財務担当者など、一または複数の様々な個人または部署が扱ってもよい。これら職務ニーズを満たすために、本発明のコンピュータシステムは共有作業環境を可能にでき、バイヤー、ベンダー、および／または管理者は入札／プロジェクトに参加する必要のある多様なカスタムユーザ役割を指定でき、またすべての入札／プロジェクトまたは特定の入札／プロジェクトのユーザ役割の各々に要員（リソース）を指名できる。

ここで図９を参照すると、ユーザ役職を指定し、ベンダー、バイヤー、または管理者のユーザ役職に要員を割り当てる例示的なステップを図示している。最初に、ベンダー、バイヤー、または管理者は入札／プロジェクトのプロセスに必要な具体的なユーザ役職を判断する（ステップ９００）。例えば、図１１のサンプルのバイヤー用ウエブページに図示するように、バイヤーはプロジェクト／入札プロセス中に、財務承認者、非財務承認者、タイムカード検収者、管理代行者、プロジェクトマイルストーン管理者、財務コーディネーター、人的資源パートナーなど、いくつか異なるユーザ役割のカテゴリが必要であると判断するかもしれない。ベンダー、バイヤー、または管理者はさらに、入札／プロジェクトのプロセス中、一または複数のユーザ役割のカテゴリ内に複数のユーザ役職が必要だと判断することもある。例えば、図１１に図示するように、バイヤーは６名の財務承認者と２名の非財務承認者が必要と判断することもある。

もう一度図９を参照すると、ユーザ役職を決定したら、ベンダー、バイヤー、または管理者の所属要員のデータファイルを格納して（ステップ９０５）、ユーザ役職の各々に適切な要員を選定する際に使用する。ベンダー、バイヤー、または管理者の一または複数の幹部要員（例えば、ＣＯＯ、プロジェクトユーザ等）を選定して、要員を具体的にユーザ役職の各々に割り当てることができ（ステップ９１０）、または代わりにシステムが個人データファイルに記載される情報に基づいてユーザ役職に要員を割り当てることができる。ある会社では、ユーザ役職を予め指名しているが（ステップ９１５）、この場合、予め指名された要員をシステムにロードして（ステップ９２０）、ユーザ役割分担表に格納できる（ステップ９２５）。例えば、多くのベンダーの場合、全プロジェクトの様々なユーザ役職に要員を予め割り当てている。他の会社では、予め一または複数のユーザ役職を全く指名していないかもしれないし、またはある特定のプロジェクトについては予め指名していないかもしれないが（ステップ９１５）、この場合、選定した幹部要員またはシステムがユーザ役職に要員を具体的に割り当てることができる。

ユーザ役職に要員を具体的に割り当てるには、個別のユーザ役職を選択し（ステップ９３０）、ユーザ役割の制約条件によってそのユーザ役職に割り当てることのできる要員のリストを個人データファイルから決定する（ステップ９３５、９４０、９４５）。例えば、ユーザ役職がある特定のレベルのユーザでなければならない場合、そのユーザレベル以上の要員だけをリストに載せる。ユーザ役職の要員リストから、要員の中から１名をそのユーザ役職に選定し（ステップ９５０）、選定した要員をユーザ役割分担表に格納する（ステップ９２５）。例えば、図１１に図示するように、ある特定のユーザ役職を選択すると（例えば、ユーザ役職をクリックする）、システムはそのユーザ役職にふさわしい適任の要員を検索でき、選定をし終えたら、そのユーザ役職の選定した要員を表示できる。

バイヤーのユーザ役職の選択と割り当てのデータ構造の例を以下の表１〜９に示す。データ構造は分かりやすいように表形式でまとめて示しており、各表はバイヤーのユーザ役職を定義して割り当てるのに必要なフィールドのすべてを含んでいる。図１０の例示的なデータベース・テーブル構造３００に関連して以下説明するように、表を階層的および／またはリレーショナルに関係付けて、ユーザ役職に必要な情報のすべてを正確に格納およびアクセスできるようにしている。しかし、他のバイヤーの役割構成を含むことも可能なことは理解されるべきであり、システムは表１〜９または図１０にあげた特定的なバイヤ
ーのユーザ役割構成に限定されるものではない。

以下の表１および２は、それぞれ、サンプルのユーザ役割カテゴリと、各ユーザ役割カテゴリ内のユーザ役職を表し、図１０に図示するように、それぞれｔｂｌＨＭ役職カテゴリ３０５とｔｂｌＨＭ役職３０６の表のデータベースに格納できる。表１では、各ユーザ役割カテゴリに識別番号とウエブページ上に表示する表示順序を割り当てる。ユーザ役割カテゴリの識別番号はユーザ役職表（表２）でユーザ役職と特定のユーザ役割カテゴリを相関させるために使用する。ただし、バイヤーのニーズによっては、多数の追加カテゴリおよび役職がありうることは理解されるべきである。最初にユーザ役職を選択したときに、ユーザが選択するためのユーザ役割カテゴリと、各カテゴリ内の特定のユーザ役職へのリンクを表示できる。そのバイヤーのすべてのユーザ役職を選択した後、図１１のように選択したユーザ役職と割り当てた要員を表示できる。

以下の表３は、システムの各ユーザの個人データファイル内に格納されるサンプルデータを表し、図１０に図示するように、表ｔｂｌユーザ３０２のデータベースに格納できる。このユーザデータから、各ユーザ役職に適任の要員を判断でき、各ユーザ役職に割り当てられた各ユーザの必須情報を確認できる。表３内のフィールドの１つがそのユーザに割り当てられた職務等級である。職務等級はユーザの企業体系内の特定のレベルを示す。例えば、ユーザがレベル３のユーザであれば、この情報をユーザ表に格納することになる。以下の表４および５に示すように、利用できる職務等級をユーザ役職にマッピングして、各ユーザ役職に割り当てるユーザに求められる職務等級を示し、また図１０に示すように、これを表ｔｂｌＨＭ職務等級３０３およびｔｂｌＨＭＰ役職等級マップ３０４のデータベースに格納できる。
以下の表６〜９は、図１０に関連して以下詳細に説明する。

図１０から分かるように、バイヤーの構成可能な作業分担と具体的なワークフローの構成要素を使用可能するのに必要なすべてのフィールド間には簡潔な関係がある。データベース構造３００はスケーラブルかつ構成可能にして、高度ではないデータベース環境内で動作する場合でも、ユーザ役職が指定され個人データファイルが利用できる限り機能性が存在できるようにする。以下詳細に論じるように、ベンダーおよび管理者にも同様なデータベース表構造が利用できることは理解されるべきである。

バイヤーのデータベース表構造３００はバイヤーから入力された個人データ（ｔｂｌＨＲデータ３０１）を受け継ぎ、共有作業環境に関わりうる具体的な要員を含む個人データファイル（ｔｂｌユーザ３０２）を作成する。個人データは分かりやすくするために表ｔｂｌＨＲデータ３０１として示す。ただし、個人データはバイヤーのデータベースシステムによっていかなる形式であってもよいことは理解されるべきである。表ｔｂｌＨＲデータ３０１から表ｔｂｌユーザ３０２に定期的にダウンロードを行って、ユーザ役職が正しく割り当てられるように、バイヤーの現在の従業員に関してシステムを更新できる。表３および４に関連して前述したように、バイヤーが指定する様々な職務等級は表ｔｂｌＨＭ職務等級３０３に格納して、表ｔｂｌユーザ３０２にマッピングし、職務等級を個々に割り当てることもできる。さらに、表４および５に関連して前述したように、職務等級を表ｔｂｌＨＭ役職等級３０４で選択したユーザ役割にマッピングすることもできる。

ユーザ役割カテゴリ表（ｔｂｌＨＭ役職カテゴリ３０５）およびユーザ役職表（ｔｂｌＨＭ役職３０６）、それらの表と役職等級および割り当てた要員との相関も図１０に示す。例えば、表ｔｂｌＨＭ役職関係３０７は各ユーザ役職に割り当てた要員のユーザＩＤを含む。ユーザ役職を具体的な入札テンプレートの種類に対応付ける場合（図１５に関連して以下詳細に説明する）、各入札テンプレートの種類に対応するユーザ役職を表ｔｂｌＨＭ役職ＲＦＸマトリックス３０９に格納できる。また、ユーザ役職を各入札取引に具体的
に割り当てる場合、具体的な取引の各ユーザ役職に割り当てられた要員のユーザＩＤは表ｔｂｌ入札ＨＭ役職３０８に格納できる。

取引中にバイヤーがユーザ役職に要員を割り当てる例示的なステップを図１２に示す。取引の開始にあたり（ステップ１２００）（例えば、入札テンプレートまたは入札依頼書の作成、入札依頼書の一斉配信、応札書の受領、応札書の評価、落札、伝票の支払い等）、システムおよび／または幹部要員は取引に必要なユーザ役職がすべて定義されているかどうかを判断する（ステップ１２０５）。定義されていなければ、システムおよび／または幹部要員は取引に必要なユーザ役職を定義する（ステップ１２１０）。

ユーザ役職を確認したら、システムおよび／または幹部要員はユーザ役割に具体的な要員（本明細書ではユーザともいう）が予め指名されているかどうかを判断し（ステップ１２１５）、さらに予め指名されたユーザの誰かをその取引については変更する必要があるかどうかを判断する（ステップ１２２０）。一または複数のユーザ役職に予め指名されたユーザがいない場合、または一または複数の予め指名されたユーザを変更する場合、システムおよび／または幹部要員はすべてのユーザ役職に適切なユーザを指名し（ステップ１２２５）、ユーザ役職の指名されたユーザのアイデンティティをユーザ役割表に格納する（ステップ１２３０）（例えば、図１０のｔｂｌ入札ＨＭ役職）。すべてのユーザが予め指名されている場合、システムは予め指名されている要員を格納し（ステップ１２３０）、適当なら、適切な要員に取引を通知する（ステップ１２４０）。

もう一度図１０を参照すると、入札／プロジェクトのプロセス中に具体的なユーザ役職にユーザを割り当てることに加えて、データベース表構造３００はさらに多様な理由で承認を必要とする取引に指定の承認者を指名する能力を提供する。そのため、表ｔｂｌ承認レベル３１０内に、一定のユーザ役職を承認職に分類でき、各承認職について、承認の回付順を指定できる。例えば、ユーザ役職承認者（承認者Ａ）を、別のユーザ役職（ユーザＢ）が発生させる全取引を承認するよう指定して、システムが自動的にユーザＢから承認者Ａに全取引を送付できるようにする。

さらに、各ユーザにはシステム内のデータを閲覧および修正するためのアクセス権を与えることができる。例えば、あるユーザ役職は第１ウエブページからシステム内のデータを修正するまたはシステム内にデータを入力する権限をもつが、別のユーザ役職は第２ウエブページからデータを閲覧する権限しかないことがある。このように、ウエブページ上に表示される情報は両ユーザに対して同じであっても、ユーザ役職の承認レベルによって、実際のウエブページは異なる。ユーザがシステムにログインすると、システムはユーザの承認レベルを判別して、ユーザに適切なウエブページをプッシュする。ユーザ役割とウエブページのアクセスとのマッピングを実装したデータ構造の例を以下の表１０に示す。

ユーザ役職、社内要員、および具体的な取引の関係を継続的に維持するために、本発明のシステムはさらに組織の要員の異動、業務レベルおよび要員のユーザ権限の変更を考慮するように設計される。ここで図１４を参照すると、本発明の実施例によるユーザ役職割り当てを修正する例示的なステップを図示している。ユーザ役職はユーザ名または取引の種類に基づいて再割り当てできる（ステップ１４００）。ユーザ名に基づいて修正を行う場合（ステップ１４０５）ユーザが就くすべてのユーザ役職に全体的に変更を行うことができ、またはユーザが就く特定のユーザ役職だけに変更を行うことができる。全体的な変更の場合（ステップ１４１０）、新規ユーザを選定し（ステップ１４１５）、前ユーザが就いていたすべてのユーザ役職を前ユーザから新規ユーザに交代する（ステップ１４２０）。この種の全体的な変更は、例えば従業員が会社を退職する場合、および新従業員が社内の現従業員の職を引き継ぐ場合に必要である。

特定のユーザ役職の変更の場合（ステップ１４１０）、ユーザが就くユーザ役職のすべてを表示でき（ステップ１４２５）、ユーザ役職の１つを変更のために選択できる（ステップ１４３０）。そこで選択したユーザ役職に新規ユーザを選び（ステップ１４３５）、その選択したユーザ役職を前ユーザから新規ユーザに交代する（ステップ１４４０）。変更が必要な各ユーザ役職についてこのプロセスを繰り返すことができる（ステップ１４４５）。特定のユーザ役職の変更は、昇進、組織変更、従業員の地位の変化（例えば、常勤からパートタイムに）等など、多数の理由のために起こりうるであろう。

取引の種類に基づいて修正を行う場合（ステップ１４０５）、全取引の種類のリスト（例えば、入札依頼書の作成、入札依頼書の一斉配信、入札依頼書の受領、応札書の生成、応札書の受領、入札の評価、応札、作業時間の記録、支払伝票の作成等）を表示でき（ステップ１４５０）、ある特定の取引の種類を選択する（ステップ１４５５）。その取引の種類に関連するユーザ役職のすべてを表示でき（ステップ１４６０）、修正すべき特定のユーザ役職を選択する（ステップ１４６５）。そこで選択したユーザ役職に新規ユーザを選び（ステップ１４７０）、その選択したユーザ役職を前ユーザから新規ユーザに交代する（ステップ１４７５）。取引の種類の修正は、例えば、ユーザ役職にどのユーザが就いているかは不明であるが、顧客の苦情のために変更が必要な場合に便利であろう。

ユーザ役職の修正は、修正の理由および現在の取引の連続性の必要性によって、現在の取引または新規取引のみに適用できる（ステップ１４８０）。修正を現在の取引に適用することにした場合、ユーザ役割分担表を新規ユーザに更新し、前ユーザの記録を旧記録に修正する（ステップ１４８５）。ただし、修正を新規取引にのみ適用する場合、ユーザ役割分担表は新規ユーザに更新するが、前ユーザは削除せず、新規取引のみに新規ユーザをマークする（ステップ１４９０）。

ベンダーの場合、典型的には適任の要員にアクセスを制限するためにユーザ役職を予め指名する。ベンダーのユーザ役割を実装するデータ構造の例を以下の表１１〜１３に示す。分かるように、表１０に関連してバイヤーに関して前述したものと同様、ベンダーの要員にベンダーの連絡先の種類を割り当てることができ、それをシステム内のデータを閲覧および修正するアクセス権にマッピングできる。ただし、他のベンダーのユーザ役割構成も含められることは理解されるべきであり、システムは表１１〜１３にあげるそのままの構成に制限されるものではない。

管理者の場合、ユーザ役割は、具体的な入札形態と具体的な場所に関連する取引活動を管理するために処理チームとチームのメンバー全体を指定できるように定義できる。ここで図１３Ａ〜１３Ｂを参照すると、管理処理チームを実装する例示的なステップが図示されている。最初に、管理者ユーザのマスターデータを含む管理者の管理ユーザ表を設定する（ステップ１３００）。ユーザ表から、様々なユーザを一または複数のユーザグループに割り当てることができ、ユーザのユーザグループへのマッピングをユーザグループマッピング表に格納できる（ステップ１３０５）。ユーザグループは社内の事業単位または取引の種類もしくはその両方に対応付けできる。各ユーザグループについて、ユーザグループ内の各ユーザの職権と責任をユーザグループ権限表に定義できる（ステップ１３１０）。例えば、各ユーザにユーザグループのアクセス権（図１０に関連して前述したとおり）を割り当てることができる。管理者のユーザグループおよびユーザグループ権限を実装するデータ構造の例を以下の表１４〜１９に示す。ただし、他の管理者ユーザ役割構成を含められることは理解されるべきであり、システムは表１４〜１９にあげるそのままの管理者ユーザ役割構成に限定されるものではない。

図１３Ｂに示すように、ユーザグループを確認したら、ユーザグループ内に具体的な取引の種類を取り扱う処理チームを作成できる（ステップ１３１５）。ある特定のユーザグ
ループ内のユーザ全員を具体的な処理チームにマッピングして、その取引の種類の回付順を割り当てることができる（ステップ１３２０）。処理チームの作成、およびユーザと処理チームのマッピングの例示的なデータ構造を以下の表１８および１９に示す。

さらに、処理チームを具体的な地理的領域にマッピングして、異なる処理チームが異なる領域で同じ取引の種類を取り扱えるようにする（ステップ１３２５）。そのため、ある特定の取引の種類をある特定の場所で行う場合、システムは取引の種類と場所に基づいて適切なユーザにワークフローを管理できる（ステップ１３３０）。例えば、電子メールおよび／またはダッシュボードの更新により、適切なユーザに取引を通知できる。

このように、本発明のシステムがサポートするユーザ役割の管理は、入札の作成からプロジェクトの完了まで入札／プロジェクトのプロセス全体に柔軟でスケーラブルかつローバストな作業分担環境を提供する。さらに、システムはユーザ役割に基づいたセキュアな通信と取引処理を可能にし、そのためユーザは、データ閲覧およびアクセス権を職務上アクセスの必要性のあるユーザだけに確実に制限しながら、適時に適切な要員と連絡できる。
入札活動
入札前活動が完了したら、バイヤーはある特定のプロジェクトのために入札依頼書を作成して一または複数のベンダーに送信し、ベンダーから応札書を要請できる。入札／プロジェクトのプロセス全体の中で入札プロセスを助けるために、具体的なプロジェクト種類に合った入札テンプレートを使用して、具体的なプロジェクト種類に関してベンダーからの必須情報を統一的かつ包括的に要請し、応札書の効率的かつ効果的な評価を可能にできる。

入札テンプレートを利用した入札依頼書の作成の例示的な機能性を図１５に示す。本発明の実施例により、入札テンプレート２４０と入札テンプレート２４０から入札依頼書２００を作成するための、それぞれ、入札テンプレート作成ツール１８０と入札依頼書作成ツール１８５を図１５に図示している。入札テンプレート作成ツール１８０と入札依頼書作成ツール１８５はツールの機能を実行するのに必要なあらゆるハードウェア、ソフトウェア、および／またはファームウェアを含むことができ、ウエブサーバ１２０または追加サーバ（図示せず）内に実装できる。各バイヤーは、バイヤーが外注するプロジェクト作業の性質によって、一または複数の入札テンプレート２４０を作成できる。例えば、バイヤーが１部署でのみスタッフの補充が必要な場合、バイヤーはスタッフ補充の入札依頼書２００を処理する１つだけの入札テンプレート２４０を作成してもよい。

入札テンプレート２４０を作成するために、入札テンプレート作成ツール１８０はバイヤーのデータベース１５５ａにアクセスして、入札項目リスト１９４内の入札項目２３０を検索し、バイヤー・モジュール１１０、ウエブサーバ１２０、データネットワーク４０、そしてバイヤー・ブラウザ２０ａを介して、バイヤーが選ぶべき入札項目リスト２３０を提示する。入札項目２３０はバイヤー、ベンダー、またはその両者から要請する具体的な情報の種類に対応する。入札項目のリスト２３０から、バイヤーは一または複数の入札項目セレクション２３５を選択、提供して、入札テンプレート２４０に入れる。バイヤーの構成によって、バイヤーの名前、作業実施場所、依頼するプロジェクト作業の種類など、一または複数の入札項目２３０を入札テンプレート２４０の必須項目としてもよい。一または複数の必須入札項目２３０の場合、必須入札項目２３０を入札テンプレート２４０に入れることに加え、必須入札項目２３０の各々に対応する具体的な情報も、入札テンプレート２４０内の必須入札項目２３０に対応付けたフィールドに含めることもできる。例えば、バイヤーの名前とプロジェクト作業の種類をそのプロジェクト作業の種類用の入札テンプレート２４０に格納できる。バイヤーが作成する各入札テンプレート２４０は後で入札依頼書２００を作成するときに使うために、入札テンプレートリスト１９０内のバイ
ヤーのデータベース１５５ａに格納する。

入札依頼書２００を作成するために、入札依頼書作成ツール１８５はバイヤーのデータベース１５５ａにアクセスして、入札テンプレートリスト１９０内に格納された入札テンプレート２４０を検索し、バイヤー・モジュール１１０、ウエブサーバ１２０、データネットワーク４０、そしてバイヤー・ブラウザ２０ａを経由して、バイヤーが選ぶために入札テンプレート２４０のリストをバイヤーに提示する。適切な入札テンプレート２４０を選択したら、バイヤーは入札依頼データ２１０を入札依頼書作成ツール１８５に提供して、入札テンプレート２４０の種類の入札依頼書２００に含める。例えば、バイヤーは入札テンプレート２４０内のバイヤーからの情報が必要な各入札項目セレクション２３５に設けられたフィールドに、入札依頼データ２１０を入力できる。制限ではなく、例として、入札依頼データ２１０は作業実施場所、プロジェクトの時機、およびプロジェクトに必要な具体的なベンダー参加資格を含めることができよう。

入札依頼書作成ツール１８５はさらにバイヤーのデータベース１５５ａとインターフェースしてバイヤー用ベンダーリスト１５８にアクセスし、入札依頼書を受け取るのに適切なベンダーを判断する。適切なベンダーは入札テンプレート２４０の種類と入札依頼書２００自体に記載するあらゆる他のベンダー参加資格に基づいて選定できる。このように、ベンダーリスト１５８は入札テンプレート２４０の種類に合わせて事前審査したベンダーに分けて、入札依頼書２００を提出する処理時間を一層短縮できる。入札依頼書作成ツール１８５はさらに選定したベンダーに対応するベンダー連絡先情報２５０を使って、ベンダー・モジュール１１５、ウエブサーバ１２０、データネットワーク４０、そしてベンダー・ブラウザ２０ｂを介して適切なベンダーに入札依頼書２００を一斉配信（送信）し（図１および２に図示するとおり）、提出した入札依頼書２００をバイヤーの入札依頼書リスト１９６に格納する。

要請を受けたベンダーから受け取るベンダー応札書２２０（図１および２に図示するとおり）をさらに、ベンダー応札書２００を後で比較して等級格付けするときに使うために、応札書リスト１９８内のバイヤーのデータベース１５５ａに格納できる。ベンダー応札書２００は入札依頼書２００に記載される入札項目から生成する。具体的には、ベンダーはベンダーおよび応札書に関連するデータを、入札依頼書２００の有効な入札項目内のデータフィールドに移植する。ベンダーはベンダー・モジュール１１５を介して入札依頼書２００にアクセスして、入札依頼書を見て応札書を記入し、記入した応札書２２０をベンダー・モジュール１１５を介して提出すると、ベンダー・モジュール１１０を介してバイヤーのデータベース１５５ａに格納される（ステップは図示せず）。応札書２２０にはベンダーのデータベース１１５ｂ（図示せず）から検索したデータを含めることができ、応札書作成中および作成後にベンダーのデータベース１５５ｂに格納できる。

様々なシステム展開から、入札テンプレートを作成し、入札テンプレートから入札依頼書を作成し、入札依頼書から応札書を作成する例示的なステップを図１６Ａ〜１６Ｄに示す。入札テンプレートの作成のためにシステムで行われる主な処理ステップを図１６Ａに示す。システムはバイヤーユーザに所定の入札項目のリストを提示する（ステップ１６００）ことによって入札テンプレートを作成する。それに応答して、システムは入札項目リストから、システム内に格納され入札テンプレートに入れるための一または複数の入札項目セレクションを受け取る（ステップ１６１０）。入札テンプレートから入札依頼書を作成するために、システムは入札テンプレート内の入札項目セレクションをバイヤーユーザに通信して、入札項目セレクションを使って入札依頼書を生成する（ステップ１６２０）。

図１６Ｂでは、バイヤー側で、入札項目リストを受け取ったら、入札テンプレートを作
成するために、バイヤーユーザは入札テンプレートに入れる一または複数の入札項目を選択する（ステップ１６３０）。その後入札依頼書を生成するために、バイヤーユーザは入札項目セレクションの入った入札テンプレートを受け取り（ステップ１６３５）、入札依頼データを入札テンプレートの入札項目セレクションに対応するフィールドに入力して、入札依頼書を作成する（ステップ１６４０）。バイヤーユーザが該当の入札項目セレクションフィールドをすべて記入しえ終えたら、入札依頼書をシステムに送信して、適格ベンダーに一斉配信する（ステップ１６４５）。

入札依頼書の生成と一斉配信のためにシステムが行う主な処理ステップを図１６Ｃに示す。入札テンプレートを作成し、入札項目セレクションを入札テンプレートに格納した（ステップ１６５０）後、システムは、入札テンプレートの種類の入札依頼書に対してバイヤーユーザが入力した入札依頼データを使って入札依頼書を生成する（ステップ１６６０）。その後、入札テンプレートの種類の応札書を要請するために、システムは生成した入札依頼書を適格ベンダーに送信する（ステップ１６７０）。

図１６Ｄでは、ベンダー側で、ベンダーはバイヤーが選択した有効な入札項目セレクションを含む入札依頼書を受け取る（ステップ１６８０）。応札書を作成するために、ベンダーユーザは入札依頼書に記載される入札項目セレクションに対応するフィールドに応札データを入力して（ステップ１６８５）、応札書を作成する。ベンダーユーザが該当の入札項目セレクションフィールドをすべて記入し終えたら、応札書をシステムに送信して、バイヤーに転送する（ステップ１６９０）。

入札テンプレートを作成するために使うデータ構造の例を以下の表２０〜２５に示す。データ構造は分かりやすくするために表形式でまとめており、各表に選択すべき入札項目をバイヤーユーザに表示して、入札テンプレート用の入札項目セレクションを格納するために必要なフィールドがすべて含まれている。図１７に関連して以下説明するように、表は階層的かつリレーショナルに関係付ける。ただし、他の入札テンプレート構成を含められることは理解されるべきであり、システムは表２０〜２５および図１７に示すそのままの入札テンプレート構成に限定されるものではない。

ここで図１７を参照すると、上記の各表２０〜２５の相関関係を表すデータベース表構造４００を示す。入札項目２３０は便宜上、また入札テンプレート２４０を作成するときのビジネス情報処理の論理的な分割のために、入札セクションと入札カテゴリにまとめて示している。このように、バイヤーユーザには入札セクション２５０を提示して、そこからバイヤーユーザは入札カテゴリ２５５を選択してその入札カテゴリ２５５に対応する入札項目２３０を表示できる。入札項目２３０を入札カテゴリ２５５と入札セクション２５０に細分することで、バイヤーユーザが理解しやすい区画化したフォーマットを呈し、それによってより能率的かつ効率的な入札テンプレート作成プロセスが可能となる。

上記表２０の形式をもつ表ｔｂｌＲＦＸ入札セクション４０１は、入札項目２３０の各セクション２５０の入札セクション名と識別、並びにウエブページ上で各入札セクション２５０の表示順序の指示およびウエブページ上に入札セクション２５０と一緒に掲載するコメントを含む。各入札セクション２５０は個別の記録として表ｔｂｌＲＦＸ入札セクション４０１に格納でき、各記録は表２０の形式である。各入札セクション２５０内に一または複数の入札カテゴリ２５５がある。上記表２１の形式をもつ表ｔｂｌＲＦＸ入札カテゴリ４０２は、各入札カテゴリ２５５のカテゴリ名、識別番号、および各入札カテゴリ２５５に対応の入札セクション２５０を含む。さらに、表ｔｂｌＲＦＸ入札カテゴリ４０２はさらにウエブページ上での各入札カテゴリ２５５の表示順序、およびウエブページ上に入札カテゴリ２５５と一緒に掲載するコメントを含む。各入札カテゴリ２５５は個別の記録として表ｔｂｌＲＦＸ入札カテゴリ４０２に格納でき、各記録は表２１の形式である。

各入札カテゴリ２５５はさらに入札カテゴリ２５５に対応する一または複数の入札項目２３０を含む。そのため、上記表２２の形式をもつ表ｔｂｌＲＦＸ入札項目４０３は、入札項目名と識別番号、並びに入札項目２３０に対応する入札カテゴリ２５５を含む。各入札項目２３０の個別の記録を表ｔｂｌＲＦＸ入札項目４０３に格納でき、各記録は上記表２２の形式である。表ｔｂｌＲＦＸ入札項目４０３はさらに、入札項目２３０の無効を許可するかどうか、入札項目２３０をベンダーに表示するかどうか、入札項目２３０はベンダーの応答が必要かどうか、入札項目２３０に関しバイヤーが入力するデータタイプ、入札項目２３０に関しバイヤーが入力するデータのフィールド長、入札項目２３０に関しベンダーが入力するデータタイプ、入札項目２３０に関しベンダーが入力するデータのフィールド長など、入札項目２３０に付随する追加情報を含む。例えば、以下の表２６は、図１５に示す入札項目リスト１９４を成す表ｔｂｌＲＦＸ入札項目４０３内のサンプルの入札項目２３０を表す。

もう一度図１７を参照すると、各入札項目２３０は、入札テンプレート２４０を作成するプロジェクト作業の種類によって、ある特定の入札テンプレート２４０について無効または有効にできる。ただし、図１５に関連して前述したように、一または複数の入札テンプレート２４０の種類に入れる必要のある入札項目２３０がいくつかある場合がある。そのため、必須の入札項目２３０の場合、無効とするのは認められない。入札セクション２５０または入札カテゴリ２５５の全体がある特定の入札テンプレート２４０に適用されない場合、その入札セクション２５０または入札カテゴリ２５５内の入札項目２３０の全部を無効にできるなら、データベース表構造４００は入札セクション２５０または入札カテゴリ２５５中の全入札項目２３０を無効にするように構成できる。

ある特定の入札テンプレート２４０について、入札項目２３０をすべて無効または有効にしたら（入札項目セレクション２３５は有効な入札項目である）、入札テンプレート２４０と対応する入札項目セレクション２３５をデータベース表構造４００に格納できる。上記表２３の形式をもつ表ｔｂｌＲＦＸ入札テンプレート４０５は、入札テンプレート名と入札テンプレート識別番号を含み、これは入札項目セレクション２３５を上記表２４の形式をもつ表ｔｂｌＲＦＸテンプレート項目マトリックス４０４の入札テンプレート２４０に対応付けるときに使用する。各入札テンプレート２４０の個別の記録は表ｔｂｌＲＦＸ入札テンプレート４０５に格納でき、各記録が表２３の形式をもつ。さらに、ある特定の入札テンプレート２４０内に入れる各入札項目セレクション２３５の個別の記録は、表ｔｂｌＲＦＸテンプレート項目マトリックス４０４に格納でき、各記録が表２４の形式をもつ。

バイヤーの名前など、入札テンプレート２４０全部に適用できるデフォルト値をもつ特別な入札項目２３０がある場合、その入札項目２３０
のデフォルト値は表２５の形式をもつ表ｔｂｌＲＦＸ入札項目ＣＤＶ４０６に格納できる。各入札項目２３０に対応する各デフォルト値の個別の記録は表ｔｂｌＲＦＸ入札項目ＣＤＶ４０６に格納でき、各記録が表２５の形式をもつ。選択可能な入札項目を構造化した、構成可能かつスケーラブルなフォーマットで提供することにより、どの入札項目２３０も、バイヤーの具体的なニーズによっていつでも追加または削除できる。

階層的かつリレーショナルなデータベース表構造を使って入札テンプレートを作成する例示的なステップを表１８に示す。入札テンプレートを作成するためには、バイヤーユーザはテンプレートの名前を入力して、データベース表構造内のテンプレートの記録を作成する（ステップ１８００）。その後、バイヤーユーザは入札セクションのリストからある特定の入札セクションを選択し（ステップ１８０５および１８１０）、入札カテゴリのリストからある特定の入札カテゴリを選択して（ステップ１８１５および１８２０）、入札
テンプレートに入れる入札項目の選択プロセスを開始する（ステップ１８２５）。

選択した入札カテゴリ内の一または複数の入札項目が必須の場合（ステップ１８３０）、必須の入札セレクションを自動的に入札テンプレートに入れる（ステップ１８３５）。他の入札項目は特定の入札テンプレートの種類に関するバイヤーユーザのニーズに応じて選択する（ステップ１８４０）。このプロセスを選択した入札セクション内の各入札カテゴリ（ステップ１８４５）と入札セクションのリスト内の各入札セクションについて（ステップ１８５０）、すべての入札項目をレビューして、入札テンプレートで有効（選択）または無効にするまで繰り返す。前述したように、他の実施例では、入札セクションまたは入札カテゴリ内の入札項目全部の無効化が可能なら、個別に入札項目をレビューせずにその入札項目全部を無効にできる。入札テンプレートの入札項目の選択をしたら、後で入札依頼書を作成するときに使うために、入札テンプレートを入札テンプレートリストに格納する（ステップ１８５５）。

入札テンプレートを作成するための例示的なウエブページの画面を図１９に図示する。一または複数のウエブページを使って（そのうちの１つのみを図示）バイヤーユーザは入札テンプレート名２４０を入力し、入札セクション２５０を選択し、入札カテゴリ２５５を選択すると入札テンプレート２４０に含まれる入札カテゴリ２５５内の具体的な入札項目２３０を表示できる。表示される入札カテゴリ２５５内の各入札項目２３０について、バイヤーユーザはその入札項目２３０の有効または無効のいずれかを選択できる。ただし、ある特定の入札項目２３０を無効にできない場合、無効ボタンが薄く表示され、バイヤーユーザがその入札項目２３０を無効にできないようにする。さらに、オプションが利用できる場合、バイヤーユーザは現在表示されている入札セクション２５０または入札カテゴリ２５５の隣にある無効ボタンをクリックすることによって、ある特定の入札セクション２５０または入札カテゴリ２５５内の入札項目２３０全部を無効にすることもできる。入札テンプレート２４０について入札項目２３０の全部を有効または無効にしたら、バイヤーユーザは入札テンプレート２４０を保存できる。ある実施例では、すべての入札項目セレクション２３５を完了していない場合、バイヤーユーザは入札テンプレート２４０を一時的に保存することもできる。別の実施例では、入札項目２３０全部が有効または無効にされるまで、保存ボタンが薄く表示される。

図２０は、図１７に示すように階層的かつリレーショナルな形式でまとめられた入札項目を使って、図１５に示す入札テンプレートから入札依頼書を作成する例示的なステップを示す。初めに、バイヤーユーザは入札依頼書の入札テンプレートリストから入札テンプレートを選択する（ステップ２０００）。入札テンプレートは入札依頼書の生成直前に作成でき、または入札テンプレートを入札依頼書のかなり前に作成できることは理解されるべきである。入札依頼書に合った特定の入札テンプレートを選択したら、バイヤーユーザは、入札依頼書の名前または番号など、入札依頼書の入札依頼書識別子を入力する（ステップ２００５）。さらに、システム全体でベンダー、バイヤー、請負人、および管理者に適用するために、システムは入札を指す入札追跡番号を割り当てる。

入札テンプレートに入れた入札項目セレクションはすべて、バイヤーユーザのレビューのために入札セクションおよび入札カテゴリ別に表示される（ステップ２０１０）。入札テンプレートに入れた一または複数の入札項目セレクションがその入札依頼書に適用できず（ステップ２０１５）、不要な入札項目セレクションを無効にできる場合（ステップ２０２０）、バイヤーユーザはその入札依頼書に必要ない入札項目セレクションを無効にできる（ステップ２０２５）。その後、バイヤーユーザは必須の入札依頼データを適切なフィールドに入力して、入札項目セレクションを入札依頼書で有効にする（ステップ２０３０）。例えば、作業実施場所またはプロジェクト作業の種類など、一または複数の入札項目セレクションはバイヤーがデータを入力するフィールドを含むことがある。これらフィ
ールドは、テキスト入力フィールドまたは選択可能なオプションを含む他のウエブページへのリンクをもつ選択可能なオプションフィールドなど、可変型のデータフィールドでありうる。

選択可能なオプションフィールドが表示される例は、多数の所定のプロジェクト種類から入札依頼書のある特定のプロジェクト作業の選択に関わる。プロジェクト種類の選択プロセスを実装するために、バイヤー固有のプロジェクト作業の業務要求事項を非散文（非文章）形式で分類できるようにする構成可能かつスケーラブルなデータベース構造を提供できる。所定のプロジェクト作業の種類から選択することによって、バイヤーはベンダーの応札書をバイヤーのプロジェクト作業の要求事項に確実に同調させることができる。プロジェクト作業の種類は、入札依頼書を受け取るベンダーの選定のためのベンダー資格審査データ（図２に図示）を記入したときに、ベンダーも選択できる。プロジェクト作業の種類の選択で使用するデータ構造の例を以下の表２７〜２９に示す。データ構造は分かりやすくするために表形式にまとめて示しており、各表は、バイヤーユーザに選択するべきプロジェクト作業の種類を表示し、選択したプロジェクト作業の種類を入札依頼書の関連入札項目セレクションのフィールド内に格納するのに必要なフィールドのすべてを含む。表は階層的かつリレーショナルに関係付けて、プロジェクト作業の種類をバイヤーユーザに表示するある特定の順序で表にアクセスされるようにする。

以下の表２７は、コンサルティング、スタッフ補充、およびその他のプロジェクトサービスなど、サンプルのプロジェクトサービスの種類を示す。表２８に示すように、プロジェクトサービスの種類の各々の中に一または複数のプロジェクトセクターがあることがあり、また表２９に示すように、プロジェクトセクターの各々の中に一または複数のプロジェクトファミリーがあることがある。そのため、入札依頼書にある特定のプロジェクト作業の種類（プロジェクトファミリー）を選択するには、バイヤーユーザはプロジェクトサービスの種類とプロジェクトセクターの種類を選択して、選択すべきプロジェクトファミリーのリストを表示できる。他の構成およびプロジェクトの種類を含むことは理解されるべきであり、システムは表２７〜２９にあげるそのままの構成および情報に限定されるものではない。

もう一度図２０を参照すると、バイヤーユーザが必須の入札項目フィールド全部に入札依頼データを入力したら（ステップ２０３５）、入札依頼書は完成する。必ずしも入札項目フィールドのすべてがユーザに入札依頼データの入力を求めるわけではないことは理解されるべきである。例えば、一または複数の入札項目セレクションが、ベンダーのみが回答するベンダー用入札依頼書入札項目セレクションであることがある。ベンダー用入札依頼書入札項目セレクションの場合、バイヤーユーザはその入札項目セレクションを有効または無効にでき、ベンダーが応札書でその入札項目を記入する上で役立つかもしれないデータを除き、その入札項目セレクションのフィールドにはデータを入力しない。入札依頼書を完成させるために、バイヤーユーザが入札依頼データを入力できる有効な入札項目セレクションはそのすべてをバイヤーユーザが記入してから、入札依頼書を提出するのが好ましい。

多くの会社では、入札依頼書はベンダーに送信する前に承認を要する。そのため、入札依頼書に承認が必要なら（ステップ２０４０）、入札依頼書の作成者は入札依頼書を適切な承認者に提出する（ステップ２０４５）。図９〜１４に関連して前述したように、例示的な実施例では、全部の入札依頼書または特定の入札依頼書について承認ユーザ役職を予め指名して、入札依頼書を自動的に適切な承認者に送付するようにする。入札依頼書が承認されたら（ステップ２０５０）、作成者に入札依頼書が承認されたことを通知し（ステップ２０５５）、入札依頼書を適格ベンダーに送信する（ステップ２０６０）。しかし、入札依頼書が承認されなければ（ステップ２０５０）、作成者に入札依頼書が拒否された
ことを通知し（ステップ２０６５）可能なら、入札依頼書を編集する機会が与えられる（ステップ２０７０）。例えば、作成者は承認のために入札依頼書に記入する必要のある一または複数の入札項目セレクションを無効にしていた場合、または一または複数のバイヤーに必須のデータフィールドを空白のままにしておいた場合があろう。入札依頼書の承認が必要ない場合（ステップ２０４０）、入札依頼書は入札依頼のために適格ベンダーに送信される（ステップ２０６０）。

図２１および２２は、入札依頼書の作成のためにバイヤーユーザに提示できる例示的なウエブページの画面である。一または複数のウエブページを使って、バイヤーユーザは入札依頼書名２００を入力し、入札セクション２５０を選択し、入札カテゴリ２５５を選択してその入札カテゴリ２５５内で入札依頼書２００に含められる具体的な入札項目セレクション２３０を表示できる。図２１は入札依頼書２００の状態の概要を示し、各セクション２５０内の入札項目セレクション２３５の数、記入済みまたは無効にした各セクション２５０内の入札項目セレクション２３５の数を一覧表示する。入札項目セレクション２３５を記入または無効にするために、バイヤーユーザは入札セクション２５０をクリックして入札カテゴリ２５５と各入札カテゴリ２５５内の入札項目セレクション２３５を表示できる。入札項目セレクション２３５の全部を記入または無効にしてしまえば、バイヤーユーザは承認および／または適格ベンダーへの送信のために、記入済み入札依頼書提出ボタンをクリックできる。

図２２に図示するように、各入札セクション２５０内の各入札カテゴリ２５５にある各入札項目セレクション２３５をレビューして、入札項目セレクション２３５を無効にすべきかどうかを判断できる。一または複数のカテゴリ２５５の入札項目セレクション２３５のいくつかはバイヤーユーザからも入札依頼データ２１０を必要とすることがある。入札カテゴリ２５５内の各入札項目セレクション２３５について、バイヤーユーザはその入札項目セレクション２３５を有効または無効にできる。ただし、ある特定の入札項目セレクション２３５を無効にできない場合、無効ボタンを薄く表示して、バイヤーユーザが入札項目セレクション２３５を無効にできないようにする。さらに、オプションが利用できる場合、バイヤーユーザはある特定の入札セクション２５０または入札カテゴリ２５５内の入札項目セレクション２３５を全部無効にすることができる。入札項目セレクション２３５が有効で、入札依頼データ２１０を入力するフィールド２３８をもつ場合、バイヤーユーザは入力依頼データ２１０を対応のデータフィールド２３８に入力できる。さらに、入札テンプレートがある特定の入札項目セレクション２３５にデフォルトの入札依頼データ２１０を含む場合、デフォルトデータ２１０をデータフィールド２３８に表示でき、テンプレートの設定によって変更が許可される場合も許可されない場合もある。

図２３は、図１５に図示する入札依頼書をレビューしてから適格ベンダーに送信する例示的なステップを示す。入札依頼書の作成者はベンダーリストから入札テンプレートの種類と入力した入札依頼データに基づいて適切な適格ベンダーを選択でき、または入札依頼書をプロジェクト管理者に提出して、バイヤーの制約条件によって適格ベンダーを選ぶことができる。後者の場合、新規入札依頼書を管理ユーザに表示して（ステップ２３００）、レビューおよび送信したい入札依頼書を選択させる（ステップ２３０５）。レビュープロセス中、管理ユーザには品質管理のために入札依頼書の編集を認められ、または大幅な変更が必要な場合には、入札依頼書の作成者に入札依頼書を編集するように要求してもよい（ステップ２３１０）。

入札依頼書が完成したら、管理ユーザはベンダーリストにアクセスして（ステップ２３１５）、入札テンプレートの種類と入力した入札依頼データに基づいて（例えば、プロジェクトファミリーと予定される地理的作業場所の兼ね合いに基づいて）、入札依頼書に適格ベンダーを判断する（ステップ２３２０）。適格ベンダーリストが不十分な場合（ステ
ップ２３２５）、管理ユーザはトップレベルのデータベース（図６に図示）に問い合わせて、一致する追加ベンダーを適格ベンダーリストに追加してもよい（ステップ２３３０）。適格ベンダーリストにトップレベルのデータベースから一致するベンダーを補充することに加えて、またはその代わりに、管理ユーザには入札依頼データの全部に完全には一致していないベンダーを含める選択肢を与えてもよい（ステップ２３３５および２３４０）。

適格ベンダーリストに載せるために選ぶべき候補となるベンダーのすべてを表示する例示的なウエブページの画面を図２４に図示する。管理ユーザは、バイヤーが契約していて入札依頼データに一致するベンダー、バイヤーが契約していて入札依頼データとは完全には一致していないベンダー、契約していないがトップレベルのデータベースが提供する入札依頼データと一致するベンダーから選択できる。管理ユーザは、ベンダーとの過去の契約実績、ベンダーの評判、およびベンダーが応じられるかどうかを含め、任意の数の要因に基づいてベンダー資格審査リストに入れるベンダーを選択できる。

図２３に戻ると、適格ベンダーのリストが最終決定したら（ステップ２３４５）、管理ユーザは入札依頼書を適格ベンダーに送信し（ステップ２３５０）、入札依頼書の作成者に入札依頼書の状態を通知する（ステップ２３５５）。例えば、作成者にはあるベンダーが入札依頼書を受け取ったことや送信前に入札依頼書に何らかの修正を行ったことを通知できる。

図１および１５の２２０で概ね示した受け取った入札依頼書に対するベンダーの入札応答書の生成と送信の例示的なステップを図２５に示す。例示的な実施例では、図９〜１４に関連して前述したように、ベンダーユーザ役割構成に基づいて、入札依頼書をベンダーに送信し、適切なベンダーユーザに回付する。入札依頼書を受け取ると、ベンダーユーザはメニューまたはダッシュボードの制御通知から入札依頼書にアクセスできる（ステップ２５００）。別の例示的な実施例では、入札依頼書は、ベンダーユーザに入札依頼書の内容をベンダーユーザに表示する前に入札依頼書の内容を秘密に保持させる義務を課す入札秘密保持合意書を添付して提出する。ベンダーユーザが秘密保持合意書を肯定確認したら（例えば、同意ボタンをクリックする）、ベンダーユーザは入札依頼書の内容へのアクセス権を得る（ステップ２５１５）。同意しなければ、ベンダーユーザに入札内容にアクセスできないことを通知し、入札依頼書はベンダーユーザの画面から削除される（ステップ２５１０）。

ベンダーがベンダー応札書を提出しなければならない期間を設けるために、入札依頼書はベンダーが応答に同意しなければならない期限を記載してもよい。ベンダーユーザが期限内に応答するのに同意（例えば承諾ボタンをクリックする）（ステップ２５０５）できない場合（ステップ２５２０）、ベンダーユーザは入札依頼書の内容をそれ以上利用できないことをベンダーユーザに通知し、入札依頼書がベンダーユーザの画面から削除される（ステップ２５２５）。バイヤーまたはプロジェクト管理者にも秘密保持合意書もしくは期限の制約条件に肯定応答しなかったベンダーを通知し、否定応答したベンダーの数に基づいて、バイヤーまたはプロジェクト管理者は十分な数のベンダー応札書を受け取れるように、適格ベンダーリストにベンダーを追加し、追加ベンダーに入札依頼書を送信できる。

ベンダーユーザが期限内に応答することに同意した場合（ステップ２５２０）、ベンダーはベンダー応札書の記入に着手することが認められる（ステップ２５３０）。入札依頼書に応じるために、ベンダーユーザは、レビューのためにベンダー応札データを要求される入札セクションおよび入札カテゴリ別の入札項目セレクションにアクセスする（ステップ２５３５）。ベンダーユーザが入札依頼書に関し何か質問があれば（例えば、要求され
るベンダー応札データの種類または量）（ステップ２５４０）、ベンダーユーザはバイヤーが設定した期限以内に入札を明確化するための質問をバイヤーに提出できる（ステップ２５４５）。ベンダーが電子メールおよび／またはダッシュボードの更新によって提出した各質問を適切なバイヤーユーザ（例えば、入札依頼書作成者またはプロジェクト管理者）に通知し（ステップ２５５０）、そのバイヤーユーザは適用される時間制約の範囲内で提出された質問に対する回答を出す責任を負う（ステップ２５５５）。ベンダーには電子メールおよび／またはダッシュボードの更新によってバイヤーの回答を通知する（ステップ２５６０）。

例えば、システムはある特定の入札依頼書に関してベンダーとバイヤーの両者がアクセスできる入札メッセージボードを提供できる。例示的な入札メッセージボード６００の画面を図２７に図示する。バイヤーとある特定の入札依頼書に応じるベンダーだけが入札メッセージボード６００にアクセスできる。バイヤーの設定により、ベンダー全員に提出された質問とバイヤーの回答のすべてに対するアクセス権を与えてもよく、または質問を提出したベンダーだけにバイヤーの回答を見られるようにしてもよい。さらに、ベンダーの質問は、ベンダーおよび／またはバイヤーの選好によって、全ベンダーとバイヤーに匿名であっても、または全ベンダーにのみ匿名であってもよい。

図２５に戻ると、ベンダーユーザに何も質問がなければ（ステップ２５４０）またはベンダーの質問全部に回答されたら（ステップ２５６０）、ベンダーユーザは入札の所要入札項目セレクションの適切なフィールドに必須のベンダー応札データを入力する（ステップ２５６５）。ベンダー応札データは原価計算の要素（例えば、リソース要件、経費の種類等）およびそれに伴う価格情報（例えば、リソースの賃率、経費の金額等）を含めた原価計算情報、成果物の種類（例えば、完了する単位数、フェーズ区分情報等）を含む成果物情報、完了情報（例えば、プロジェクト終了日、フェーズ終了日等）を含めることができる。原価計算要素と成果物の種類は各々がそれぞれ異なる入札項目セレクションに対応し、ベンダー応札書の効果的な比較と等級格付けを可能にする。

入札項目フィールドは、テキスト／通貨／数値入力フィールドおよび／または選択可能なオプションフィールドなど、様々なデータタイプとなりうる。さらに、プロジェクトの種々の側面のために、フィールドは単一の応札書項目に関連して複数の詳細レベルをもつことができる。例えば、バイヤーおよび／またはベンダーが決定するように、プロジェクトにいくつかのフェーズがある場合、ベンダーの回答フィールドはプロジェクトの各フェーズごとに個別のセクションを含むことができる。ベンダー応札書を提出しようとすると、システムはベンダーがベンダー応札書の入札項目セレクションに必要なすべてのデータフィールドを記入しているかを検証する（ステップ２５７０）。必要なデータフィールドに記入漏れがある場合（ステップ２５７５）、ベンダーユーザに記入漏れのベンダー応札書の入札項目セレクションを示すシステム・メッセージを提示し、ベンダー応札書を提出する前に必要な入札項目セレクションを記入するよう指示する（ステップ２５８０）。入札項目セレクションの必要なすべてのデータフィールド応札書に記入したら（ステップ２５７５）、ベンダー（提出時）にベンダー応札書がバイヤーまたはレビューのためにプロジェクト管理者に提出されたことを示すメッセージが提示され（ステップ２５８５）、適切なバイヤーユーザに電子メールおよび／またはダッシュボードの更新により新規ベンダー応札書を通知する（ステップ２５９０）。

図２６Ａおよび２６Ｂは、応札書の生成のためにベンダーユーザに提示できる例示的なウエブページの画面である。ベンダーユーザには応札書の中でベンダー応札データが必要な入札項目セレクションを表示するウエブページが提示される。例えば、図２６Ａに図示するように、ベンダー応札書の状態がベンダーユーザに提示でき、各セクション２５０の入札項目セレクション２３５の数、各セクションの中でベンダーユーザが記入しなければ
ならない入札項目セレクション２３５の数、各セクション２５０の中で記入済みの入札項目セレクション２３５の数が一覧表示される。さらに、ベンダーユーザはベンダーが質問を投稿する入札メッセージボードにアクセスでき、読みやすいオンライン形式の応札書を見られ、またはベンダー応札書に添付する請負人候補の経歴書を提出できる。また、ベンダーがすべての入札項目セレクション２３５に対する回答を記入し終えたら、ベンダーユーザは記入済み応札書提出ボタンをクリックしてバイヤーまたはプロジェクト管理者の承認を受けるおよび／またはバイヤーまたはプロジェクト管理者に送信できる。

図２６Ｂに図示するように、入札項目セレクション２３５に対するベンダーの回答を記入するには、ベンダーユーザは入札セクション２５０をクリックして、入札カテゴリ２５５および各入札カテゴリ２５５内の入札項目セレクション２３５を表示できる。ある特定の入札項目セレクションに対するベンダーの回答が必要な場合、ベンダーユーザはベンダー応札データ２１５を入札項目セレクション２３５のデータフィールド２３８に入力できる。前述したように、データフィールド２３８は直接テキスト入力フィールドにでき、または所定のベンダー回答から適切なベンダー応札データを選択する他のウエブページへのリンクを含めることができる。さらに、データフィールド２３８は、各レベルにウエブページへのリンクを備える複数のレベルをもつことができる。また、データフィールド２３８は、ベンダー名およびベンダー住所などデフォルトのベンダー応札データ２１５をベンダーのデータベースから直接移植することができる。例えば、入札依頼書を受け取ったら、ベンダー・モジュールは特定の入札項目セレクション２３５を検索して、その入札項目セレクション２３５のデータフィールド２３８に適切なベンダー応札データ２１５を移植することができる。

所定のベンダー回答から選択したベンダー応札データの例を図２８に図示する。入札依頼書に、ベンダーがプロジェクトに関するリソース要件情報とともに、例えばリソース要件情報に対応するリソース賃率を提示する必要がある入札項目セレクションを含む場合、データフィールド２３８は所定のリソースプロファイルパラメータの選択をするための他のウエブページへのリンクを備えることができる。例えば、各リソースプロファイルはリソースプロファイルに必要なある特定のリソースの種類と関連スキルを表すことができる。バイヤーがリソースプロファイルと賃率を効率的に比較しやすくするために、ベンダーは所定の多数のリソースの種類と関連スキルを選択できる。リソースの種類とスキルの選択を行うには、ベンダーの具体的なリソース要件を非散文（非文章）形式で分類できる構成可能かつスケーラブルなデータベース構造を提供できる。

リソースの種類と関連スキルを選択するために使うデータ構造の例を以下の表３０〜３７に示す。データ構造は分かりやすくするために表形式でまとめており、各表は選択すべきリソースの種類と関連スキルをベンダーユーザに表示して、選択したリソースプロファイルを対応する入札項目セレクションのデータフィールドに格納するために必要なフィールドのすべてを含む。表は階層的かつリレーショナルに関係付けて、図２９に関連して以下説明するように、表をリソースの種類と関連スキルをベンダーに表示する特定の順序でアクセスできるようにし、図２９はベンダー応札書とバイヤー入札依頼書との相関関係で完全なベンダー応札書に対応付けた例示的なデータスキーマを表すデータベース表構造８００を図示している。

以下の表３０は、製造、経営／専門、事務、および技術など、サンプルの業務セクターのカテゴリを表す。各業務セクターのカテゴリ内には表３１に示す一または複数の業務分野があり、各業務分野内には表３２に示す一または複数の業務ファミリーがある。そのため、応札書のリソースの職種に関連するある特定の業務ファミリーを選択するには、ベンダーユーザは業務セクターのカテゴリおよび業務分野を選択して、選択すべき業務ファミリーのリストを表示できる。業務ファミリーを選択したら、リソースの職種に対応付ける
様々なスキル（一般的職務およびビジネススキル）を選択して、表３３〜３７に示す特定のリソースの職種にマッピングできる。例えば、一般的職務はリソースの職種に対応するスキルレベルを特定でき、スキルのカテゴリはリソースの職種が備えるスキルのタイプ、訓練および経験を特定でき、各スキルのカテゴリに対応付ける一または複数のスキルセットはリソースの職種に対応付ける具体的な経験を特定できる。さらに、リソースの職種の各スキルセットに優先レベルを設定することによって、あるスキルセットを他のスキルセットより強調表示できる。他のリソースの職種およびスキル選択を提供できることは理解されるべきであり、システムは表３０〜３７に示すそのままの構成および情報に限定されるものではない。リソースプロファイリングのより詳しい議論は、同時係属の本発明の譲受人に譲渡された米国特許出願番号第１０／１２８，７５１号を引用し、これにより同特許を参照により全体的に本明細書に組み込む。

ベンダー応札書の提出にあたり、入札項目セレクションフィールドのすべてに入札データ（入札依頼データまたはベンダー応札データのいずれか）を移植し、図２９のデータベース表構造８００に示すように、階層的かつリレーショナルに入札としてシステム（バイヤーのデータベースとベンダーのデータベース）に格納する。入札データを格納するための例示的なデータ構造を以下の表３８〜５５に示し、図２９に関連して述べる。

以下の表３８および３９は、図２９に示す表ｔｂｌＲＦＸ８０１とｔｂｌＲＦＣ選択入札項目８０２のデータベースに格納できるある特定の入札依頼書に対応するサンプルの入札依頼データを表す。例えば、表ｔｂｌＲＦＸ８０１では、入札依頼書に関する一般的な情報、例えば、システムが入札依頼書に割り当てる入札追跡番号、作成者が割り当てる入札依頼書名、入札依頼書作成者のアイデンティティ、入札テンプレートの種類、プロジェクト形態、プロジェクト作業場所、プロジェクトの予算支出額、入札依頼書の状態（例えば、新規、提出済み、評価済み、落札済み、等）、ベンダーが入札依頼書を受け取ったトップレベルのデータベースかどうか、何らかの承認が必要だったかどうかなどを格納できる。ただし、他の入札情報も含めることは理解されるべきであり、システムは表３８および３９に示すそのままの情報に限定されるものではない。

入札依頼書に入れる具体的な入札項目セレクションおよび各入札項目セレクションに作成者が入力した入札依頼データ（バイヤーのコメント）は、表ｔｂｌＲＦＸ選択入札項目８０２に格納できる。各入札項目セレクションはｔｂｌＲＦＸ選択入札項目８０２に個別の記録として格納でき、各記録が以下の表３９に示すフィールドのすべてを含む。表ｔｂｌＲＦＸ選択入札項目８０２は一般的な入札依頼情報の表ｔｂｌＲＦＸ８０１に結合する。図１０に関連して上記述べたように、表ｔｂｌＲＦＸ選択入札項目８０２に含まれる入札項目セレクションは表ＲＦＸ入札項目４０３から選択し、表ｔｂｌＲＦＸテンプレート項目マトリックス４０４から表ｔｂｌＲＦＸ入札テンプレート４０５内に格納される特定の入札テンプレートの種類に対応付ける。

入札依頼書の適格ベンダーへの投稿（送信）に付随するサンプルの情報を以下の表４０に示すが、これは図２９に示す表ｔｂｌＲＦＸ投稿８０３のデータベースに格納できる。例示的な実施例では、図３１〜３５に関連して以下説明するように、投稿情報を入札依頼書を受け取った各ベンダーに関係付け、例えば、入札依頼書を適格ベンダーに提出（投稿）した日時、入札依頼書を投稿した管理ユーザのアイデンティティ、入札依頼書を受け取った適格ベンダーのアイデンティティ、ベンダー応札書の識別子、ベンダーに割り当てたスコアを含むことができる。ただし、他の情報も含められることは理解されるべきであり、システムは表４０に示すそのままの情報に制限されるものではない。入札依頼書を受け取った各ベンダーにそれぞれ別の記録を表ｔｂｌＲＦＸ投稿８０３に格納でき、各記録は以下に示すフィールドのすべてを含む。

ベンダーが入札依頼書を受け取り、ベンダー応札書を提出することに付随するサンプルの情報を以下の表４１に示すが、これは図２９に示す表ｔｂｌＲＦＸ応札８０４のデータベースに格納できる。例えば、当該応札提出情報は、ベンダー応札書の識別子、ベンダー応札書の状態、ベンダーのアイデンティティ、ベンダー応札書の提出日、ベンダーが秘密保持を肯定確認し合意書に応じる意思表明をした日を含めることができる。表ｔｂｌＲＦＸ応札８０４に含められるステータス情報の種類の例を以下の表４２に示し、これは図２９に示す表ｔｂｌＲＦＸ応札状態８０５のデータベースに格納できる。表ｔｂｌＲＦＸ応札８０４およびｔｂｌＲＦＸ応札状態８０５は表ｔｂｌＲＦＸ投稿８０３に結合し、それがさらにｔｂｌＲＦＸ８０１に結合して、ベンダー応札提出情報と入札依頼書の入札投稿情報とを対応付ける。ただし、他の情報も含められることは理解されるべきであり、システムは表４１および４２に示すそのままの情報に限定されるものではない。各ベンダー応札書にそれぞれ別の記録をｔｂｌＲＦＸ応札８０４に格納でき、各記録は以下の表４１に示すフィールドを含む。

以下の表４３は、ベンダーからバイヤーにベンダー応札書で提出するサンプルのベンダー応札データを示すが、これは図２９に示す表ｔｂｌＲＦＸ応札メインのデータベースに格納できる。例えば、図３１〜３５に関連して以下詳細に説明するように、当該ベンダー応札データは、入札追跡番号、ベンダー応札書識別子、ベンダーのアイデンティティ、ベンダーが応じた特定の入札項目セレクション、その入札項目セレクションへのベンダー応答、その入札項目セレクションに対応するあらゆる入札依頼データ（バイヤーのコメント）、その入札項目セレクションへのベンダー応答の記録識別子、バイヤーがベンダー応答に与えた何らかの等級を含むことができる。ただし、他の情報も含められることは理解されるべきであり、システムは表４３に示すそのままの情報に限定されるものではない。バイヤーが応じた各入札項目セレクションにそれぞれ別の記録をｔｂｌＲＦＸ応札メイン８０６に格納し、各記録は以下の表４３に示すフィールドを含む。表ｔｂｌＲＦＸ応札メイン８０６はｔｂｌＲＦＸ８０１およびｔｂｌＲＦＸ投稿８０３に結合して、ベンダー応札書を入札依頼書に対応付ける。

入札項目セレクションに対する一または複数のベンダー応答に、ベンダーがプロジェクトの完了に必要だと特定した一または複数の特定のリソース（請負人）のリソースプロファイルを対応付けてもよい。リソースプロファイルは事前に、もしくはベンダー応札書の一部として作成できる。リソースプロファイルは、図２８に関連して上記述べ、上記の表３０〜３７に示す業務セクター、業務分野、業務ファミリー、一般的職務、およびスキルを使って生成する。

リソースプロファイルのリソースプロファイル情報（リソースの職種とスキル）の例を以下の表４４〜４６に示すが、これは図２９に示す表ｔｂｌリソースプロファイルマスター８０７、ｔｂｌリソースプロファイルマスタースキル８１６、およびｔｂｌリソースプロファイルマスターＧＦ８１７のデータベースに格納できる。表ｔｂｌリソースプロファイルマスター８０７はリソースプロファイルのリソースの職種（例えば、業務セクター、業務分野、業務ファミリー）を格納し、一方、表ｔｂｌリソースプロファイルマスタースキル８１６はリソースの職種に関連したビジネススキル（スキルセットおよびスキルセットの優先事項）を格納し、表ｔｂｌリソースプロファイルマスターＧＦ８１７はリソースの職種の一般的職務を格納する。ただし、他の情報も含められることは理解されるべきであり、システムは表４４〜４６に示すそのままの情報に限定されるものではない。各リソースプロファイルにそれぞれ別の記録を、表ｔｂｌリソースプロファイルマスター８０７、ｔｂｌリソースプロファイルマスタースキル８１６、およびｔｂｌリソースプロファイルマスターＧＦ８１７に格納し、各記録は以下の表４５〜４６に示すフィールドのすべてを含む。表ｔｂｌリソースプロファイルマスター８０７は表ｔｂｌリソースプロファイルマスタースキル８１６およびｔｂｌリソースプロファイルマスターＧＦ８１７に結合して
、一般的職務とスキルセットを各リソースプロファイルのリソースの職種に対応付ける。

ベンダー応札書と一緒に提出し、特定に選定したリソースプロファイルに関するサンプルの情報を以下の表４７に示すが、これは図２９の表ｔｂｌＲＦＸリソースプロファイル８１８に格納できる。例えば、当該選定したリソースプロファイル情報は、リソースプロファイルのアイデンティティと、プロジェクトの完了に必要な特定に選定したリソースプロファイルの見込み人数を含むことができる。ただし、他の情報も含められることは理解されるべきであり、システムは表４７に示すそのままの情報に限定されるものではない。プロジェクトのために選定した各リソースプロファイルにそれぞれ別の記録をｔｂｌＲＦＸリソースプロファイル８１８に格納し、各記録は以下の表４７に示すフィールドのすべてを含む。表ｔｂｌＲＦＸリソースプロファイル８１８は表ｔｂｌＲＦＸリソースプロファイルマスター８０７に結合して、特定のリソースの職種、スキル、および一般的職務を選定したリソースプロファイルに対応付ける。また、表ｔｂｌＲＦＸリソースプロファイル８１８は表ｔｂｌＲＦＸ選択入札項目８０２にも結合して、選定したリソースプロファイルをリソースプロファイルを必要とする特定の入札項目セレクションに対応付ける。

入札依頼書によっては、一または複数の入札項目セレクションに対するベンダー応札書の一部として、プロジェクトのために特定に選定したリソースプロファイルに対応する価格情報も提供できる。サンプルのリソース価格情報を以下の表４８に示すが、これは図２９に示す表ｔｂｌＲＦＸリソースプロファイルプライシング８１９のデータベースに格納できる。例えば、当該リソース価格情報は、リソースプロファイル識別子、リソースプロファイルおよび価格情報を必要とする入札項目セレクションに対するベンダー応札書記録のアイデンティティ、リソースプロファイルに対応するリソースの見込み作業時間数、リソースプロファイルに対応する賃率、およびリソースプロファイルに対応するリソースの見込み請求額を含めることができる。ただし、他の情報も含められることは理解されるべきであり、システムは表４８に示すそのままの情報に限定されるものではない。選定したリソースプロファイルの１つに対応する各リソースにそれぞれ別の記録を表ｔｂｌＲＦＸリソースプロファイルプライシング８１９に格納し、各記録が以下の表４８に示すフィールドを含む。表ｔｂｌＲＦＸリソースプロファイルプライシング８１９は表ｔｂｌＲＦＸリソースプロファイル８１８に結合して、ある特定のリソースのリソース価格情報を特定に選定したリソースプロファイルに対応付ける。さらに、表ｔｂｌＲＦＸリソースプロファイルプライシング８１９は表ｔｂｌＲＦＸ応札メイン８０６および表ｔｂｌＲＦＸ選択入札項目に結合して、リソース価格情報および選定したリソースプロファイルを特定の入札項目セレクションに対するベンダー応答書に対応付ける。

特定のリソースプロファイルと価格に加えて、ベンダー応札書はプロジェクトに必要な材料の種類に関係する情報も含めてもよい。サンプルの材料情報を以下の表４９に示すが、これは図２９に示す表ｔｂｌＲＦＸ応札材料８２２のデータベースに格納できる。例えば、当該材料情報は、材料情報を必要とする入札項目セレクションに対するベンダー応札書記録のアイデンティティ、材料の種類、および材料の原価を含めることができる。ただし、他の情報も含められることは理解されるべきであり、システムは表４９に示すそのままの情報に限定されるものではない。材料の各種類にそれぞれ別の記録を表ｔｂｌＲＦＸ応札材料８２２に格納し、各記録が以下の表４９に示すフィールドを含む。表ｔｂｌＲＦＸ応札材料８２２は表ｔｂｌＲＦＸ応札メイン８０６および表ｔｂｌＲＦＸ選択入札項目に結合して、材料情報を特定の入札項目セレクションに対するベンダー応札書に対応付ける。

ベンダー応札書はプロジェクトのフェーズ区分に関係する情報も含んでもよい。サンプルのフェーズ別情報を表５０に示すが、これは図２９に示す表ｔｂｌＲＦＸ応札フェーズ８２３のデータベースに格納できる。例えば、プロジェクトの各フェーズについて、フェ
ーズ別情報はフェーズ別情報を必要とする入札項目セレクションに対するベンダー応札書記録のアイデンティティ、具体的なフェーズの数、フェーズの明細、フェーズの予想期間、およびフェーズの終了時のプロジェクト成果物（例えば、完了した単位数、またはその他プロジェクトのマイルストーン）を含めることができる。ただし、他の情報も含められることは理解されるべきであり、システムは表５０に示すそのままの情報に限定されるものではない。各フェーズにそれぞれ別の記録を表ｔｂｌＲＦＸ応札フェーズ８２３に格納し、各記録は以下の表５０に示すフィールドを含む。表ｔｂｌＲＦＸ応札フェーズ８２３を表ｔｂｌＲＦＸ応札メイン８０６および表ｔｂｌＲＦＸ選択入札項目に結合して、フェーズ別情報を特定の入札項目セレクションに対するベンダー応札書に対応付ける。

入札メッセージボードでベンダーおよびバイヤーが投稿した質問と回答、およびベンダー応札書に関してバイヤーがベンダーに提出した質問もすべてシステムに格納して、そのベンダー応札書に対応付けることができる。サンプルの質問情報を以下の表５１および５２に示すが、これは図２９に示す表ｔｂｌＲＦＸベンダーからの質問８２０とｔｂｌＲＦＸバイヤーからの質問８２１のデータベースに格納できる。各ベンダーの質問／バイヤーの回答、およびバイヤーの質問／ベンダーの回答にそれぞれ別の記録を表ｔｂｌＲＦＸベンダーからの質問８２０とｔｂｌＲＦＸバイヤーからの質問８２１に格納し、各記録が以下の表５１および５２に示すフィールドを含む。さらに、表ｔｂｌＲＦＸベンダーからの質問８２０およびｔｂｌＲＦＸバイヤーからの質問８２１をｔｂｌＲＦＸ応答メイン８０６に結合して、質問をそのベンダー応札書に対応付ける。

ベンダー応札書はベンダーが遂行した過去のプロジェクト作業についての詳細にも対応付けて、応札プロセスに役立てることができる。サンプルの過去のプロジェクト作業の詳細を以下の表５３に示すが、これは図２９に示す表ｔｂｌＲＦＸ応札追跡記録８２４のデータベースに格納できる。例えば、当該過去のプロジェクト作業の詳細は、ベンダー応札書の識別子、プロジェクト名、バイヤーの名前、プロジェクト価格、プロジェクトの明細、プロジェクトに配置するリソース（請負人）の検討、ベンダーの実績の検討、プロジェクト開始日、およびプロジェクト終了日を含むことができる。追加の過去のプロジェクト作業の詳細を格納できることは理解されるべきであり、システムは表５３に示すそのままの過去のプロジェクト作業の詳細に限定されるものではない。

ここで図３０を参照すると、入札依頼書とベンダー応札書の管理のためにバイヤーにオプションが表示されるサンプルのウエブページの画面を図示している。入札依頼書管理ウエブページから、バイヤーユーザは記入済みの入札依頼書を管理者（または適格ベンダー）に提出し、入札依頼書に対するベンダー応札書を閲覧でき、ベンダー応札書を等級格付けし、ベンダー応札書についての質問をベンダーに提出し、ベンダーからの再見積もりを依頼し、ベンダーとのプロジェクト面接またはプロジェクトのリソース（請負人）候補とのリソース面接を要請し、ある特定のベンダーに入札（プロジェクト）を落札し、プロジェクトのリソースを割り当てるまたは入札依頼書を保留にすることができる。

バイヤーがある特定の入札依頼書に対して一または複数のベンダー応札書を受け取ったら、バイヤーはどのベンダーにプロジェクトを落札させるかを決定するためにベンダー応札書の等級格付けする、もしくはその他の形で比較できる。入札依頼書および応札書の所定の入札項目を使うと、ベンダー応札書はすべて同じフォーマットとなり、ベンダー応札書の効率的かつ効果的な等級格付けおよび比較が可能となる。そのため、ベンダー応札書の等級格付けを始める前に、バイヤーは等級格付けのために一または複数の入札項目を選択できる。

等級格付けする入札項目を選択し、選択した等級格付けする入札項目に対するベンダー応答を等級格付けする例示的な機能を図３１に示す。本発明の実施例による等級格付けす
る入札項目の選択およびベンダー応札書の等級格付けのための格付評価ツール１８８を図３１に図示する。格付評価ツール１８８は、ツールの機能を行うのに必要なあらゆるハードウェア、ソフトウェア、および／またはファームウェアを含めることができ、ウエブサーバ１２０または追加サーバ（図示せず）内に実装できる。

入札依頼書の作成後いつでも、ベンダー応札書の等級格付けの責任を負う格付評価人（例、バイヤーユーザまたはプロジェクト管理者ユーザ）は格付評価ツール１８８にアクセスして、入札依頼書から等級格付けする一または複数の入札項目セレクション２３５を選択できる。格付評価ツールはデータベース１５５に格納される入札項目リスト１９４にアクセスし、入札項目リスト１９４から格付評価人が識別する特定の入札依頼書内に含まれる入札項目セレクション２３５を検索して、入札項目セレクション２３５をバイヤー・モジュール１１０、ウエブサーバ１２０、データネットワーク４０、そしてバイヤー・ブラウザ２０ａを経由して、格付評価人に表示して選ばせる。入札項目セレクション２３５から、格付評価人は一または複数の評価対象の入札項目２３６を選択して、評価対象の入札項目２３６のリストを格付評価ツール１８８に提供する。

一または複数のベンダー応札書を受け取ると、格付評価ツール１８８はベンダー応札書リスト１９２にアクセスして、リスト１９２内のベンダー応札書のうちの１つの評価対象の入札項目２３６の１つに対応するベンダー応札データ２１５を検索できる。入札項目応札データ２１５が等級格付けのために格付評価人に表示される。表示される入札項目応札データ２１５に含まれる品質および情報に関する様々な要因（客観的および主観的）に基づいて、格付評価人は入札項目応答２１５に等級を割り当て、入札項目応答等級２６０を格付評価ツール１８８に送信できる。

格付評価ツール１８８はさらにデータベース１５５とインターフェースして、ベンダーの入札項目応答等級２６０を、ベンダー入札応札書リスト１９２にある各ベンダー応札書の等級格付けしたすべての入札項目２３６の入札項目応答等級２６０を含むベンダー等級リスト１９８に格納する。さらに、格付評価ツール１８８がある特定のベンダー応札書の評価対象の入札項目２３６のすべてについて受け取った入札項目応答等級２６０のすべてに基づいて、格付評価ツール１８８はそのベンダー応札書の総合ベンダースコア２６５を計算して、ベンダースコア２６５をベンダー等級リスト１９８に格納できる。

評価対象の入札項目を選択し、評価対象の入札項目を使ってベンダー応札書を等級格付けする例示的なステップを図３２および３３に示す。応札書の等級格付けについて行う主な処理ステップを図３２に示す。ベンダー応札書を受け取ると（ステップ３２００）、等級格付けに使用する入札項目セレクションを特定する（ステップ３２１０）。入札項目セレクションをベンダー応札書を要請する入札依頼書に対応付けて、ベンダー応札データを等級格付けのために選んだ入札項目セレクションに入れる。評価対象の入札項目内のベンダー応札データを使って、ベンダー応札書を等級格付けする（ステップ３２２０）。

より詳細な等級格付けプロセスを図３３に示す。入札依頼書を作成した後、バイヤーユーザに入札依頼書に対応する入札項目セレクションのリストを提示する（ステップ３３３０）。入札項目セレクションのリストから、一または複数の評価対象の入札項目を選び（ステップ３３０５）、各評価対象の入札項目に加重係数（例えば、加重率）を割り当てて（ステップ３３１０）、最終的なスコアである応札書を他の応札書より重みをつけて評価する。ある実施例では、加重係数を等しくでき、それによってバイヤーユーザは加重係数を入力するという要件を外せることに留意すべきである。評価対象の入札項目の加重係数はすべて、ベンダー応札書の等級を格付けする前に決めておかなければならない（ステップ３３１５）。

評価対象の入札項目のすべてを選んで、加重係数を割り当てたら、格付評価人にベンダー応札書のリストを提示し（ステップ３３２０）、等級格付けのためにベンダー応札書の１つを選択する（ステップ３３２５）。その後、格付評価人は評価対象の入札項目の１つを選択して（ステップ３３３０）、評価対象の入札項目に含まれるベンダー応札データを等級格付けする（ステップ３３３５）。格付評価人は格付評価人に利用できる何らかのメカニズムを使ってベンダー応札データを等級格付けることができる。ある実施例では、格付評価人はある特定の評価対象の入札項目に等級格付け基準を予め定めて、システムが自動的にベンダー応札データを等級格付けできるようにできる。例えば、価格情報を等級格付けするために、格付評価人は具体的な価格範囲に等級を予め割り当てることができるので、システムはベンダー応札書で提出された価格に基づき価格評価対象の入札項目に自動的に等級を付けることができる。他の実施例では、格付評価人は等級を割り当てる前にまず、ベンダー応札データ間の相対的な差異に基づいて、ある特定の評価対象の入札項目のベンダー応札データのすべてを比較できる。さらに別の実施例では、格付評価人は各等級をある特定の評価対象の入札項目に割り当てるチェックリストまたは閾値を予め定めることができる。

評価対象の入札項目のベンダー応札データに割り当てた等級はデータベースに格納し（ステップ３３４０）、ある特定のベンダー応札書の各評価対象の入札項目に含まれるベンダー応札データが等級格付けされるまで、各評価対象の入札項目についてこのプロセスを繰り返す（ステップ３３４５）。等級のすべてが完了したら、システムは各評価対象の入札項目に割り当てた個々の等級に基づいてベンダーの総合スコアを計算する（ステップ３３５０）。例えば、想定する等級がＡ、Ｂ、Ｃ、Ｄの場合、Ａに４点、Ｂに３点、Ｃに２点、Ｄに１点を割り当てて、ベンダーのスコアを計算できる。

各ベンダー応札書を同じように等級格付けすると（ステップ３３５５）、ベンダーのスコアを降順に並べ替えて（ステップ３３６０）、バイヤーユーザに表示できる（ステップ３３６５）。総合スコアに加えて、格付評価人には評価対象の入札項目の個々の等級も提示して、再見積もりが必要かどうかを判断できる。格付評価人に総合スコアと個々の等級を提示することによって、格付評価人は総合スコアが最も高かったベンダーはどこか、特定の評価対象の入札項目の等級が最も高かったベンダーはどこかを目視で判断でき、どのベンダーにプロジェクトを落札するかを決定できる。ただし、本明細書で説明する特定的な等級格付けおよび採点の代わりに、本発明のシステムと併用して他の応札書の比較技術も利用できることは理解されるべきである。

評価対象の入札項目の選択とベンダー応札書の等級格付けのために格付評価人に表示できる例示的なウエブページ６１の画面を図３４Ａ〜３４Ｅに示す。図３４Ａでは、ウエブページは格付評価人が選択するための入札項目セレクション２３５のリストを掲載する。選択した各評価対象の入札項目２３６について、格付評価人はその評価対象の入札項目２３６の加重率８５０も入力できる。格付評価人は所定の基準または個人的な選好に基づいて、加重率８５０の合計が１００パーセントに等しくなるまで加重率８５０を調整できる。前述したように、他の実施例では、評価対象の入札項目２３６のすべてに同じ重みを割り当てると、加重率８５０を格付評価人に表示する必要はない、または格付評価人が選択する必要はなくなるだろう。

図３４Ｂに示すように、ベンダー応札書を等級格付けするために、格付評価人には特定の評価対象の入札項目２３６を一覧表示し、ベンダー応札データ２１５を表示するまたはベンダー応札データ２１５へのリンクを提示するウエブページを提示できる。例えば、図３４Ｃに図示するように、ある特定の評価対象の入札項目を等級格付けするために、リソースプロファイルおよび関連のリスト価格情報へのリンクを提示できる。もう一度図３４Ｂを参照すると、格付評価人にはさらに、評価対象の入札項目２３６に対応するベンダー
応札データ２１５の等級８５５を入力するよう指示するプロンプトを提示できる。他の実施例では、所定の等級格付け基準に基づいて、等級８５５をシステムが自動的に割り当ててもよい。

ベンダー応札書を等級格付けしたら、図３４Ｄに示すように、格付評価人に、格付評価人入札項目２３６、評価対象の入札項目２３６に割り当てた加重率８５０、格付評価人が評価対象の入札項目２３６の各々に割り当てたベンダー等級８５５のすべてを表示するウエブページを提示できる。さらに、ベンダーの総合スコア８６０も表示して、格付評価人がベンダー応札書の総合的な品質を判断できるようにする。ここで図３４Ｅを参照すると、ベンダーの総合スコア８６０と評価対象の入札項目２３６の各々に割り当てた個々の等級８５５に基づいて、応札書を並べて比較できる。

評価対象の入札項目を選択しベンダーの等級を格納するために使用するデータ構造の例を以下の表５４〜５６に示す。データ構造は分かりやすいように表形式にまとめて示しており、各表は選択すべき入札項目セレクションをバイヤーユーザに表示して、ベンダー応札書の等級およびスコアを格納するのに必要なフィールドのすべてを含む。表は、図３５に関連して述べるように、階層的かつリレーショナルに関係付ける。

入札依頼書および対応するベンダー応札書に入れられるサンプルの入札項目セレクションを以下の表５４に示す。ただし、他の情報も含めることは理解されるべきであり、システムは表５４に示すそのままの情報に限定されるものではない。各入札項目セレクションについて、その入札項目セレクションが等級格付けできるかどうかが明示される。例えば、入札項目セレクションのすべてが等級格付けするベンダー応札データを含むわけではない。そのため、等級格付けのできる入札項目セレクションだけをバイヤーユーザに表示して選択させる。

以下の表５５に示す各評価対象の入札項目にそれぞれの個々の等級を格納するが、これは図３５に示す表ｔｂｌＲＦＸ等級項目８２５のデータベース表構造１１００に格納できる。ある特定の評価対象の入札項目２３６に割り当てた等級８５５とともに、表ｔｂｌＲＦＸ等級項目８２５はバイヤーユーザ格付評価人のアイデンティティ、評価対象の入札項目２３６に割り当てた加重率８５０、等級８５５に関連するベンダー応札書の識別子も含めてもよい。ただし、他の情報を含められることは理解されるべきであり、システムは表５５に示すそのままの情報に限定されるものではない。各ベンダーの各ベンダー等級８５５は表ｔｂｌＲＦＸ等級項目８２５にそれぞれ別の記録として格納し、各記録は以下の表５５に示すフィールドを含む。さらに、表ｔｂｌＲＦＸ等級項目８２５を、図２９に関連してそれぞれ上記述べた表ｔｂｌＲＦＸ８０１に結合する表ｔｂｌＲＦＸ応札メイン８０６に結合して、ベンダー等級８５５をベンダー応札書および入札依頼書に対応付ける。さらに、表ｔｂｌＲＦＸ等級項目８２５を表ｔｂｌＲＦＸ選択入札項目８０２に結合して、ベンダー等級８５５を特定の入札項目セレクション２３５に対応付ける。

各入札項目２３５のベンダー等級８５５の各々について計算したスコア８６５は以下の表５６に示すように格納でき、これは図３５に示す表ＲＦＸ項目スコアベンダー８２６のデータベースに格納できる。各ベンダー応札書の各評価対象の入札項目にそれぞれ別の記録を表ｔｂｌＲＦＸ項目スコアベンダー８２６に格納し、各記録が表５６に示すフィールドを含む。さらに、表ｔｂｌＲＦＸ項目スコアベンダー８２６に格納したベンダースコア８６５の全部に基づいて出す総合スコア８６０も以下の表５７に示すように格納でき、これは図３５に示すｔｂｌＲＦＸスコアベンダー８２７のデータベースに格納できる。各ベンダー応札書にそれぞれ別の記録を表ｔｂｌＲＦＸスコアベンダー８２７に格納し、各記録が表５７に示すフィールドを含む。

表ｔｂｌＲＦＸ項目スコアベンダー８２６を表ｔｂｌＲＦＸ等級項目８２５に結合して、各スコア８６５をある特定のベンダー応札書の評価対象の入札項目２３６すべてに対する関連のある等級８５５に対応付ける。さらに、表ｔｂｌＲＦＸスコアベンダー８２７を表ｔｂｌＲＦＸ項目スコアベンダー８２６に結合して、ある特定のベンダー応札書の評価対象の入札項目２３６すべてに対する全スコア８６５をそのベンダー応札書の総合スコア８６０に対応付ける。また、表ｔｂｌＲＦＸスコアベンダー８２７を図２９に関連して上記述べた表ｔｂｌＲＦＸ投稿８０３に結合して、表ｔｂｌＲＦＸ投稿をベンダースコア８６０で更新する。

ベンダー応札書を受け取り等級格付けした後、バイヤーユーザは、ベンダーのスコアを上げるために、一または複数の評価対象の入札項目についてベンダーが再見積もりを提出する機会を与えてもよい。例えば、バイヤーユーザが通例選ぶベンダー、または他の評価対象の入札項目については等級の高いベンダーが、他のベンダーよりもスコアが低いことがあり、バイヤーユーザは等級の低かった一または複数の評価対象の入札項目に関してベンダー応札データを改訂する機会をベンダーに与えたいと思うことがあろう。

再見積もりプロセスを容易にする例示的なステップを図３６に示す。格付評価人が一または複数の評価対象の入札項目についてある特定のベンダーの一または複数の等級が低いと気づいたら、格付評価人はベンダーに選択した一または複数の評価対象の入札項目について再見積もりを要請できる（ステップ３６００および３６１０）。再見積もりの要請（ステップ３６２０）は、ベンダーに再見積もりさせる特定の評価対象の入札項目だけを特定して、格付評価人が等級格付けをやり直したいとは思わない他の評価対象の入札項目についてベンダーに再見積もりさせないようにする。例えば、再見積書に当初のベンダー応札書のコピーを含めて、ベンダーユーザが再見積もりを要請される入札項目にしか新たなベンダー応札データを入力できないようにする。旧ベンダー応札データは削除でき、または参照のために新応札データとともにデータベースに格納することもできる。さらに、再見積もりの要請は、各再見積もり用入札項目に関してのベンダーの等級並びに各再見積もり用入札項目に関してのベンダーの順位、再見積もり用入札項目に関して高いおよび低いベンダー等級など、他の同様な情報を知らせることができる。

ベンダーがバイヤーの定める期限内に再見積もりしないことにする場合（ステップ３６３０）、当初のベンダー等級とスコアがそのベンダー応札書に適用される（ステップ３６４０）。しかし、ベンダーが再見積もり用入札項目の一または複数の項目について再見積もりする場合（ステップ３６３０）、ベンダーユーザは選択された再見積もり用入札項目の入札項目フィールドに新たなベンダー応札データを入力できる（ステップ３６５０）。再見積書を受け取ったら（ステップ３６６０）、格付評価人は再見積もり用入札項目を新規ベンダー応札データを使って等級格付けし、それに応じてベンダーのスコアを修正する（ステップ３６７０）。

落札およびプロジェクト追跡パラメータの入力の例示的なステップを図３７に示す。ベンダー応札書の等級格付けと採点のすべてが完了したら（ステップ３７００）、ベンダーのうちの１社に落札できる。バイヤーユーザがベンダーのスコアと他の要因（例えば、個人的な選好、ベンダーの評判に関する情報、ベンダーが応じられるかどうかの情報等）に基づいてベンダーを選定する権限をもつ場合（ステップ３７０５）、バイヤーユーザはプロジェクトのベンダーを選定できる（ステップ３７１０）。そうでなければ、スコアの最も高いベンダーに落札する（ステップ３７１５）。

プロジェクトのベンダーを選定したら、システムはプロジェクト管理者（ステップ３７２０）と落札ベンダーの両者に落札を通知する（ステップ３７２５）。その後、落札ベンダーとバイヤーは従来どおり交渉に入り、プロジェクトの条件を最終決定する（ステップ
３７３０）。落札ベンダーとバイヤーがプロジェクトの条件に関し合意に至らない場合（ステップ３７３５）、バイヤーは入札プロセスを再開して、既存のベンダースコア、新規ベンダー応札書、もしくはその両方に基づいて新規ベンダーを選定する（ステップ３７４０）。しかし、条件が合意に至れば（ステップ３７３５）、バイヤーと落札ベンダーは様々なプロジェクト追跡パラメータ、例えば、プロジェクト開始日、プロジェクト終了日、見込みプロジェクト支出（購入申請書の金額）、割り当てるリソース、プロジェクトフェーズ別スケジュール、プロジェクト支払精算スケジュール、プロジェクト成果物、プロジェクトの購入申請書を作成するためのプロジェクト材料およびプロジェクト経費などをシステムにロードできる（ステップ３７４５）。プロジェクトの遂行を追跡するために追加のプロジェクト追跡パラメータもシステムにロードできることは理解されるべきであり、システムは本明細書に述べるプロジェクト追跡パラメータに限定されるものではない。プロジェクトの購入申請書がプロジェクト管理者およびベンダーの適切な承認ユーザによって承認されたら（ステップ３７５０）、プロジェクトを開始できる。

プロジェクト管理者およびベンダーがプロジェクト追跡パラメータ８７０をシステムにロードするための例示的なウエブページ６１の画面を図３９Ａおよび３９Ｂに図示する。プロジェクト管理者の場合、図３９Ａに図示するように、購入申請書の作成日、購入申請書の状態（これはシステムが自動的に更新できる）、購入申請書の金額、購入申請書の通貨（例えば、米ドル）、プロジェクト開始日、プロジェクト終了日など、購入申請書の様々な情報を入力できる。さらに、プロジェクト管理者は、作業範囲記述書、プロジェクト商品およびサービスの成果物、プロジェクト契約、プロジェクト材料、割り当てたプロジェクトリソースおよび賃率、プロジェクト経費、プロジェクトフェーズ別スケジュール、プロジェクト支払精算スケジュールなど、様々なプロジェクトの条件もシステムに入力できる。また、プロジェクト管理者は、プロジェクトにまだ割り当てられていない様々な管理ユーザ役割に管理ユーザを割り当てることができる。さらに、勘定割り当て、元帳コード、原価中心点コード、プロジェクトコード、課税コード、アカウンティングプラントなど、プロジェクトに適用される他の財務関係のプロジェクト追跡パラメータもシステムに入力できる。

図３９Ｂに図示するように、ベンダーはプロジェクト管理者と同様バイヤーが入力したデータにアクセスして、以前にシステムに入力されたプロジェクト追跡パラメータ８７０を修正でき、および／または新規プロジェクト追跡パラメータ８７０をシステムに入力できる。例えば、ベンダーは前述のプロジェクト条件の一または複数の条件を入力できる。関係者は誰がプロジェクト追跡パラメータ８７０を入力するかについて合意でき、または関係者双方がプロジェクト追跡パラメータ８７０を入力および／または修正でき、システムは何らかの変更があれば両関係者に通知できる。他のプロジェクト追跡パラメータをシステムに入力できることは理解されるべきであり、システムは図３９Ａおよび３９Ｂに示すプロジェクト追跡パラメータに限定されるものではない。

例えば、図４０Ａおよび４０Ｂに図示するように、プロジェクト追跡パラメータ８７０の一部として課税情報８７５もシステムに入力できる。課税情報８７５はバイヤーとベンダーが使用して、財務管理および納税義務のために、プロジェクトですべての税務当局および適用される税額をもれなく考慮するようにできる。図４０Ａおよび４０Ｂに図示するように、例えばプロジェクトの進行中ベンダーが使用する材料など、活動に調達行項目番号を設定する場合、バイヤーとベンダーは適正な税額査定に必要なあらゆる関連取引情報をシステム内に指定できる。

例えば、図４０Ａに図示するように、材料購入申請書の入力行項目の一部として、バイヤーとベンダーは、バイヤーの所在地、発注場所、出荷先住所、物理的な引渡し住所、ベンダー所在地等の所在地情報を入力することによって課税情報８７５を発信または更新で
き、そのすべての行項目が管轄の税務当局を示すことになろう。さらに、バイヤーが免税者である場合、バイヤーは免税の理由を指定できる。バイヤーとベンダーの双方はさらに管轄の税務当局および税率を入力することによって課税情報８７５を発信または更新できる。図４０Ｂに図示するように、ある特定の活動の発注書を支払いのために提出したら、システムはバイヤーおよびベンダーがその活動について以前に入力した税率にアクセスして、その発注書の税額を計算できる。税務当局、税率、税額、およびその他課税関連の取引情報を含めた課税情報８７５はデータベースに格納して、許可されたユーザが利用できるようにする。

課税情報を入力して処理する例示的なプロセスを図４０Ｃに示す。バイヤー／管理者が、人件費、経費、材料、成果物、単位業務、その他雑費、商品／サービスを引き渡す場所または遂行場所を含めたプロジェクトの活動のあらゆる構成要素（プロジェクト追跡パラメータ）と課税情報を明記した購入申請書を作成する場合（ステップ４０００）、システムは課税情報を含めた購入申請書を該当のベンダーがレビューできるようにすることができる（ステップ４００５）。そのとき、ベンダーは関係ある課税情報をシステムに入力し、購入申請書を承認することもできる（ステップ４０１０および４０１５）。ベンダー承認のバイヤー課税情報およびベンダーの課税情報両方を含めた完全な購入申請書は、最終的な承認を受けるためにバイヤーに提出する（ステップ４０２０および４０２５）。

バイヤーが承認したら、ベンダー発注書を作成してベンダーに発行し（ステップ４０３０）、プロジェクトの作業を開始する（ステップ４０３５）。プロジェクトを着手している間、一または複数の発注書指定の商品またはサービスをベンダーが遂行する（ステップ４０４０）。商品／サービスは請負人の請求可能な作業時間経費に関係する場合、図４２〜４７に関連して以下詳しく説明するように、請負人は自分のタイムカードを記入する（ステップ４０４５）。他のすべての商品／サービスについては、図４８〜５０に関連して以下詳しく説明するように、ベンダーは他の伝票情報を記入する（ステップ４０５０）。その後、伝票はレビューのために指定のバイヤーユーザに送付する（ステップ４０５５）。バイヤーが伝票を承認したら、システム管理者は、適用される場合、以前に入力した税率を使って計算した適用される課税額をインポートする請求ファイルを作成でき、その支払いのためにバイヤーにインボイスを提出する（ステップ４０６０）。その後、バイヤーは管理者に支払い（ステップ４０６５）、管理者はベンダーに支払う（ステップ４０７０）。管理者は請求ファイルに伝票の支払いに関係する財務取引データを維持し、バイヤーまたはベンダーの許可要員に財務取引データのアクセス権を与え（ステップ４０７５）、図５９に関連して以下詳しく説明するように、その後の処理のために任意で財務取引データをトップレベル・データベースにアップロードする（ステップ４０８０）。

最終的な交渉中システムに入力できるプロジェクト追跡パラメータの別の例として、バイヤーはリソース候補（実際の請負人）の経歴書を提出するようベンダーに要請して、バイヤーがベンダー応札書に記載されたリソースプロファイルの職務にそのリソースプロファイルを備える実際の候補を充てていることを確認できるようにする。リソース候補の提出とリソース候補のレビューの例示的なデータ構造を以下の表５８および５９に示す。

以下の表５８は、ベンダーがプロジェクトのリソースプロファイルの職務に選任した各リソース候補について提出できるサンプルのリソース候補情報を示す。例えば、リソース候補情報は、リソース候補に関連する特定の入札（入札依頼書および応札書）の入札追跡番号、リソース候補リソースプロファイルのアイデンティティ、リソース候補の個人情報、ベンダー情報、リソース候補の経歴書、およびリソース候補提出書類の状態を含むことができる。表５９は表５８に含めることのできる様々なリソース提出書類の状態情報を示す。ただし、他の情報も含められることは理解されるべきであり、システムは表５８に示すそのままの情報に限定されるわけではない。

リソース候補者を承認するための例示的なステップを図３８に示す。ベンダー応札書に記載される各リソースプロファイルに関し、ベンダーはそのリソースプロファイルの職務に就かせる予定のリソース候補者の経歴書を提出する（ステップ３８００）。バイヤーは経歴書のすべてをレビューして、リソースプロファイルの職務に適格なリソース候補者を割り当てる（ステップ３８１０）。

一または複数のリソース候補者を承認できず（例えば、リソース候補者がリソースプロファイルに必須のスキルを備えていることが経歴書から確認されない）（ステップ３８２０）、そのリソースプロファイルの職務に承認できる候補者が他にいない場合（ステップ３８３０）、バイヤーは入札プロセスを再開して、プロジェクトに必要なリソースを提供できる別のベンダーを確保できる（ステップ３８４０）。ただし、すべてのリソースプロファイルの職務に適格なリソース候補者を充てることができる場合、バイヤーおよび／またはベンダーは割り当てられたリソース候補者（請負人）に関連するリソース情報を請負人のデータベースに入力する（ステップ３８５０）。例えば、請負人の氏名、住所、電話番号、従業員番号などの請負人に関する個人情報を請負人のデータベースに入力できる。さらに、認められた請求可能な時間、請求可能な賃率、認められた経費の総額および種類、作業開始前に請負人が作成する、または準備する必要のあるあらゆる合意書または書類など、具体的なプロジェクト関連の請負人情報を請負人のデータベースに入力できる。

請負人情報を入力したら、システムは作業時間記録およびシステムのアクセスのために請負人を認証できる（ステップ３８６０）。例えば、システムはシステムのログインおよび認証のために請負人にユーザ名とパスワードを与えることができる。さらに、システムは請負人に一または複数の合意書を作成するように要求できる（例えば、オンライン上で合意書の条件を肯定確認することによって）、および／または作業時間記録システムにアクセスさせる前に一または複数の書類を提出できる。

最初にログインし認証されたら請負人に表示される例示的なウエブページ６１の画面を図４２に図示する。ウエブページは、請負人がプロジェクトの作業を開始する前に作成しなければならないいくつかの書類を一覧表示する。例えば、請負人は知的財産合意書、秘密保持合意書、行動規範合意書、臨時労働契約の確認書に署名の必要があるかもしれない。一覧表示される書類のそれぞれをクリックすると、その合意書を掲載したウエブページが請負人に表示され、請負人は承諾ボタンをクリックすると合意書を作成したことになる。

請負人情報を格納し、関連書類を請負人から取得するまたは請負人から同意を得ることを確保するための例示的なデータベース構造を以下の表６０〜６３に示す。表６０は、請負人から取得する必要がある、またはプロジェクトのある時点で請負人が作成する必要のある様々なサンプルの書類を一覧表示する。表６０は当該書類を取得または作成する期限も一覧表示する。表６１は、請負人のアイデンティティ、認められた請求可能な時間数、認められた経費の額、様々な書類の作成日、および請負人タイプなど、請負人の情報を一覧表示する。表６２はある書類を一覧表示し、請負人がその書類を作成または提出したかどうか、また当該作成日または提出日を識別する。各書類の個別の記録は表６２のフォーマットで格納されることは理解されるべきである。表６３は、請負人がバイヤーのために勤務した日数および勤務しなかった日数など、請負人タイプを識別する様々な例示的な情報を表す。ただし、他の情報も含められることは理解されるべきであり、システムは表６０〜６３に示すそのままの情報に限定されるものではない。

プロジェクト追跡パラメータを格納するために使用するデータ構造の例を以下の表６４〜７９に示す。データ構造は分かりやすくするために表形式でまとめて示しており、各表
がプロジェクトの遂行を追跡するために必要なフィールドのすべてを含む。表は図４１に関連して述べたように、階層的かつリレーショナルに関係付ける。

以下の表６４は、図４１に示す表ｔｂｌ購入申請書１０００のデータベースに格納できるサンプルの購買申請書の一般情報を示す。例えば、当該購入の一般情報は、システム、バイヤーおよびベンダーが購入申請書に割り当てるアイデンティティ、申請書の作成日、申請金額、購入申請書に対応する入札（入札依頼書および応札書）の入札追跡番号、プロジェクトの開始日および終了日、並びにその他購入申請書のあらゆる関連情報を含むことができる。ただし、他の情報も含められることは理解されるべきであり、システムは表６４に示すそのままの情報に限定されるものではない。ここで図４１のデータベース表構造１１５０を参照すると、表ｔｂｌ購入申請書１０００は、それぞれ上記表６１および６３に対応するデータ構造形式で情報を含む表ｔｂｌ購入申請書請負人１０１２および表ｔｂｌｌｕ請負人タイプ１０１３に結合して示されて、割り当てられた請負人を購入申請書に対応付ける。

以下の表６５〜７０は、課税コードアカウントプラント、原価中心点、プロジェクトコード、勘定割り当て、その他同様なバイヤー指定の購入申請書情報に関連したサンプルの購入申請書の具体的な情報を示すが、そのすべてが図４１に示す表ｔｂｌ購入申請書課税コード１００１、ｔｂｌ購入申請書アカウントプラント１００２、ｔｂｌ購入申請書会計原価中心点１００３、ｔｂｌ購入申請書プロジェクトコード１００４、ｔｂｌ購入申請書会計総勘定元帳１００５、ｔｂｌ購入申請書勘定割り当て１００６に格納できる。ただし、購入申請書の要件によっては、購入申請書に関係する追加の表および情報も含められることは理解するべきである。表ｔｂｌ購入申請書課税コード１００１、ｔｂｌ購入申請書アカウントプラント１００２、ｔｂｌ購入申請書会計原価中心点１００３、ｔｂｌ購入申請書プロジェクトコード１００４、ｔｂｌ購入申請書会計総勘定元帳１００５、ｔｂｌ購入申請書勘定割り当て１００６は表ｔｂｌ購入申請書１０００に結合して、具体的な購入申請書の情報を購入申請書の一般情報に対応付ける。

以下の表７１〜７５は、購入申請書に関係するサンプルの申請書支払い情報を表す。例えば、当該申請書支払い情報には、プロジェクト成果物（プロジェクトの終了時点またはプロジェクトのフェーズ中に引き渡される商品およびサービス）に基づく支払い金額、期間に基づく支払い金額、完了した単位数に基づく支払い金額、プロジェクト材料に基づく支払い金額、プロジェクト経費に基づく支払い金額を含めることができる。図４１では、申請書支払い情報は、表ｔｂｌ購入申請書支払い成果物１００７、ｔｂｌ購入申請書支払い期間１００８、ｔｂｌ購入申請書支払い単位１００９、ｔｂｌ購入申請書支払い材料１０１０、およびｔｂｌ購入申請書支払いプロジェクト経費１０１１のデータベースに格納するように示されている。表ｔｂｌ購入申請書支払い成果物１００７、ｔｂｌ購入申請書支払い期間１００８、ｔｂｌ購入申請書支払い単位１００９、ｔｂｌ購入申請書支払い材料１０１０、およびｔｂｌ購入申請書プロジェクト経費１０１１はそれぞれ、表ｔｂｌ購入申請書に結合して、支払い情報を購入申請書の一般情報に対応付ける。

購入申請書の要件によっては、追加の表または情報を含めてもよいことは理解されるべきである。さらに、プロジェクトによっては、支払い表のうちの一または複数の表を含められることも理解されるべきである。また、各支払い金額にそれぞれ別の記録が以下の表７１〜７５のフォーマットで含まれることは理解されるべきである。

以下の表７７および７７は、購入申請書に割り当てられた請負人の賃率に関連するサンプルの情報を表す。例えば、請負人の賃率情報は、支払い形態（例えば、時間給、定額給、超過時間等）と賃率金額（例えば、請求可能な時間当たり単価、請求可能な超過時間当たり単価、請求可能金額）を示すことができる。賃率情報は、図４１に示す表ｔｂｌ購入
申請書支払い賃率１０１４およびｔｂｌｌｕ請負人支払い賃率タイプ１０１５のデータベースに格納でき、この表は表ｔｂｌ購入申請書１０００に結合して、賃率情報を購入申請書に対応づける。各請負人の各賃率タイプにそれぞれ別の賃率記録が表ｔｂｌ購入申請書支払い賃率１０１４に格納できることは理解されるべきである。さらに、購入申請書の要件によっては、追加の表または情報を含められることは理解されるべきである。

以下の表７８および７９は、購入申請書に割り当てた請負人の請負人経費に関連するサンプルの支払い情報を表す。例えば、請負人の経費情報は、経費の種類および経費に配賦する最高額を示すことができる。請負人の経費情報は図４１に示す表ｔｂｌ購入申請書支払い請負人経費１０１６およびｔｂｌｌｕ請負人支払い経費種類１０１７のデータベースに格納でき、この表は表ｔｂｌ購入申請書１０００に結合して、請負人の経費情報を購入申請書に対応付ける。各請負人の各請負人の経費の種類にそれぞれ別の請負人経費記録が表ｔｂｌ購入申請書支払い請負人経費１０１６に格納できることは理解されるべきである。また、購入申請書の要件によっては、追加の表または情報も含められることも理解されるべきである。
入札後活動
プロジェクトが始まってしまえば、プロジェクト管理者（またはバイヤー）は作業時間記録システムを使ってプログラムの進捗をモニタリングでき、作業時間記録システムに請負人は遂行したプロジェクト作業に関する時間をタイムカードに入力する。タイムカードは、購入申請書の支払い情報によって、購入申請書支払い情報に対してプロジェクトの遂行を評価する、および／または作業時間に基づいて支払伝票を生成するために格納できる。例えば、購入申請書の支払い金額が、少なくとも部分的に、ある特定の賃率のある特定の請負人の見込み請求可能時間数に基づいていて、請負人が見込み請求可能時間数に満たずにプロジェクトを完了した場合、プロジェクト管理者およびベンダーは当初支払いに設定した購入申請書の支払い金額を成果物、期間、または単位に基づいて再交渉できるであろう。

ここで図４３を参照すると、本発明のシステム内に作業時間記録システムを実装するための例示的なステップを示している。請負人が必要なすべての書類を記入し終わって、作業時間記録システムに入る許可が与えられたら、請負人は作業時間記録システムに入って（ステップ４３００）、請負人が作業した時間数に関連する作業時間記録情報をタイムカード（例えば、請負人の作業時間記録）に入力できる（ステップ４３１０）。作業時間記録情報は作業時間記録システムにアクセス可能なときにはいつでも入力できる。例えば、作業時間記録システムは、プログラム管理者が決める特別な時間帯（例えば、週末、週明け等）または作業時間記録システムがオフラインになっていない時間帯にしかアクセスできないようにできる。

請負人が作業時間記録情報をタイムカードに入力したら、タイムカードはプロジェクト管理者に提出して（ステップ４３２５）、レビューおよび承認を受ける（ステップ４３３０）。タイムカードが承認されなければ（ステップ４３４０）、請負人およびベンダーにタイムカードの拒絶を通知し（ステップ４３５０）、請負人は作業時間記録システムにアクセスしてタイムカードを修正するように指示を受ける（ステップ４３００）。例えば、請負人がタイムカードを漏れなく記入していなかった場合、タイムカードに入力された作業時間記録情報（たとえば、時間数）が正常な範囲内にないまたは不合理である場合、あるいは作業時間記録情報が不正確であることをプロジェクト管理者が知っている場合、タイムカードは拒絶されるであろう。タイムカードが承認されたら（ステップ４３４０）、システム内の該当するすべての記録を作業時間記録情報で更新し（ステップ４３６０）、作業時間記録情報に対応するあらゆる支払伝票をインボイス処理のために抽出する（ステップ４３７０）。例えば、購入申請書の支払いがある特定の期間内に作業した時間数に基づく場合、支払伝票は請負人が入力した作業時間記録情報に基づいて生成する必要があろ
う。

作業時間記録システムから請負人に提示される例示的なウエブページ６１の画面を図４４および４５に図示する。サンプルの作業時間記録システムのホームページを図４４に図示する。ホームウエブページから、請負人は新しいタイムカードを作成し、一時保存したタイムカードを記入のために呼び出し、または過去に提出したタイムカードを見ることができる。さらに、請負人に請負人経費の入力が認められている場合（購入申請書による）、請負人は新しい経費伝票を作成し、一時保存した経費伝票を記入のために呼び出し、または過去に提出した経費伝票を見ることができる。

図４５に示すように、新しいタイムカードを作成する（一時保存したタイムカードに記入する）ために、請負人は様々な作業時間記録情報１１５０をタイムカード１１００に入力できる。例えば、請負人は週末の作業日、プロジェクトのプロジェクトコード、および支払いの責任がある原価中心点を入力できる。さらに、請負人は各日に作業した規定時間数および（各超過時間賃率で）各日に作業した超過時間の時間数を入力できる。請負人は他の作業時間記録情報も入力できることは理解されるべきであり、システムは図４５に示すそのままの作業時間記録情報に限定されるものではない。

提出されたタイムカードのレビューのためにプロジェクト管理者に表示されるサンプルのウエブページ６１の画面を図４６に図示する。入力された作業時間記録情報に加えて、プログラム管理者にはそのタイムカードに関連する他の関連購入申請書の情報、例えば、現在のプロジェクトフェーズ、総勘定元帳コード、税使用コード、勘定割り当てコード、およびアカウントプラントコードなども提示してもよい。表示された作業時間記録情報に基づいて、プロジェクト管理者はタイムカードを拒絶するか、またはタイムカードを承認できる。プロジェクト管理者がタイムカードを拒絶する場合、プロジェクト管理者がタイムカードの拒絶理由を書くポップアップ・ウィンドウを表示できる。タイムカードの承認のために他の情報もプロジェクト管理者に表示できることは理解されるべきであり、システムは図４６に示すそのままの情報に限定されるものではない。

タイムカードおよび請負人経費伝票を格納するための例示的なデータベース構造を以下の表８０〜８３に示す。データ構造は分かりやすくするために表形式にまとめて表しており、各表はタイムカードおよび請負人経費伝票を格納するのに必要なフィールドのすべてを含む。図４７に関連して述べるように、表はデータベース内に格納される他の表に階層的かつリレーショナルに関係付ける。

以下の表８０はサンプルの作業時間記録の一般情報であり、これは図４７に示す表ｔｂｌタイムカード１０５０のデータベース表構造１１６０に格納できる。例えば、作業時間記録情報は、タイムカードの識別子、対応する購入申請書の識別子、請負人の識別子、ベンダーの識別子、入力された時間が請求記録の生成のために請求可能な時間かどうかの明示、タイムカードに対応する週末日、作成日、レビュー日、タイムカードが承認されているかどうかの明示を含むことができる。ただし、他の情報も含められることは理解されるべきであり、システムは表８０に示すそのままの情報に限定されるものではない。図４７に示す表ｔｂｌタイムカード１０５０は、図４１に関連して上記述べた表ｔｂｌ購入申請書１０００に結合する表ｔｂｌ購入申請書請負人１０１２に結合して、タイムカードを請負人および購入申請書に対応付ける。さらに、図４１に示す様々な他の表を図４７に表して、様々な購入申請書の表とタイムカードの表と請負人経費伝票の表の間の相関関係を示す。

表ｔｂｌタイムカード１０５０に格納するタイムカードの状態識別子は表ｔｂｌｌｕタイムカード状態１０５１から選択でき、この表はタイムカードの状態の種類（例えば、一
時保存、提出済み、承認済み、拒絶等）とそれに対応するタイムカードの状態の識別子を格納する。

表８１はサンプルの詳細な作業時間記録情報を表すが、これは図４７に示す表ｔｂｌタイムカード詳細１０５２のデータベースに格納できる。例えば、各詳細な作業時間記録情報は、ある特定の賃率のタイプについてある特定の日に作業した入力時間数、賃率のタイプに対応する賃率、および他の詳細な作業時間記録情報を含められる。表ｔｂｌタイムカード詳細１０５２は表ｔｂｌタイムカード１０５０に結合した状態で示して、詳細な作業時間記録情報を作業時間記録の一般情報に対応付ける。さらに、表ｔｂｌタイムカード詳細１０５２は表ｔｂｌｌｕ日付コード１０５３に結合して、表ｔｂｌタイムカード詳細１０５２に格納した日付コードをその特定の日に対応付ける。請負人が時間を入力する各日の各賃率のタイプについて、表８１のフォーマットの個別の記録が表ｔｂｌタイムカード詳細１０５２に格納されることは理解されるべきである。さらに、他の表および作業時間記録情報も含められることは理解されるべきであり、システムは図４７に示すそのままの表と作業時間記録情報に限定されるものではない。

以下の表８２はサンプルの請負人経費伝票の一般情報を表すが、これは図４７に示す表ｔｂｌ請負人経費伝票１０５４のデータベースに格納できる。例えば、当該請負人経費伝票の一般情報には、経費伝票の識別子、対応する購入申請書の識別子、請負人の識別子、ベンダー識別子、経費伝票に対応する週末日、作成日、検収日、および経費伝票が承認されたかどうかの明示を含められる。ただし、他の情報も含められることは理解されるべきであり、システムは表８２に示すそのままの情報に限定されるものではない。表ｔｂｌ請負人経費伝票１０５４は、図４１に関連して上記述べたように、表ｔｂｌ購入申請書１０００に結合する表ｔｂｌ購入申請書請負人１０１２に結合して示され、請負人の経費伝票と特定の請負人および購入申請書に対応付ける。

以下の表８３はサンプルの詳細な請負人経費伝票情報を表すが、これは図４７に示す表ｔｂｌ請負人経費伝票詳細１０５５のデータベースに格納できる。例えば、当該詳細な経費伝票情報は、ある特定の日のある特定の経費の種類の経費金額、および他の詳細な経費伝票情報を含められる。表ｔｂｌ請負人経費伝票詳細１０５５は表ｔｂｌ請負人経費伝票１０５４に結合して、詳細な経費伝票情報を経費伝票の一般情報に対応付けるように示される。さらに、表ｔｂｌ請負人経費伝票詳細１０５５は表ｔｂｌｌｕ日付コード１０５３に結合して、表ｔｂｌ請負人経費伝票詳細１０５５に格納される日付コードを特定の日に対応付ける。請負人が金額を入力する各日の各経費の種類について、表８３のフォーマットの個別記録が表ｔｂｌ請負人経費伝票詳細１０５５に格納されることは理解されるべきである。また、他の表および請負人経費伝票情報も含められることは理解されるべきであり、システムは図４７に示すそのままの表および請負人経費伝票情報に限定されるものではない。

ここで図４８を参照すると、バイヤーまたはプロジェクト管理者が落札ベンダーに支払う支払伝票１１８０の生成のために、システムに入力しデータベース１５５に格納できる多数の様々な種類の伝票情報１１６０である。例えば、伝票情報１１６０は作業時間記録伝票情報１１６０ａを含み、これは請負人が入力する作業時間記録情報１１５０（上記図４５に図示）、および作業時間記録情報に付随する入力済みプロジェクト作業追跡パラメータ８７０（上記図３９および４０に図示）が判別する購入申請書支払い情報を含む。伝票情報は、プロジェクト経費伝票情報１１６０ｂ、プロジェクト成果物伝票情報１１６０ｃ、プロジェクト材料伝票情報１１６０ｄ、請負人経費伝票情報１１６０ｅ、プロジェクト単位完了伝票情報１１６０ｆ、およびプロジェクト定期支払精算伝票情報１１６０ｇも含むことができる。システムは他の状況（例えば、プロジェクト追跡パラメータの入力、作業時間記録の入力、請負人経費の入力、および／またはプロジェクト経費の入力）で以
前に入力した伝票情報１１６０に基づいて自動的に支払伝票１１８０を生成でき、またはベンダーもしくはバイヤー／プロジェクト管理者が支払伝票１１８０を生成し、伝票情報１１６０の該当する様々な部分（例えば、単位完了の入力または成果物完了の入力）を支払伝票１１８０に入力できる。

ここで図４９を参照すると、伝票処理および支払いシステムに関わる例示的なステップが図示されている。最初に、様々なプロジェクト追跡パラメータ（例えば、購入申請書の情報）をシステムに入力し（ステップ４４００）、商品およびサービスに対するベンダーの全責任、請求対象および請求対象外の両方をデータベースに格納する（ステップ４４１０）。ベンダーが認められた商品またはサービスを提供する場合（入力したベンダーの責任によって判断する）（ステップ４４２０）、ベンダーはシステムにアクセスして、履行した商品またはサービスを記録し、その商品またはサービスに対する支払いを請求する（ステップ４４３０）。他の実施例では、一定の時間間隔でシステムが自動的に支払い請求してもよい。システムはプロジェクト追跡パラメータおよびその他の伝票情報（例えば、作業時間記録情報、経費、材料等）に基づいて伝票を生成し（ステップ４４４０）、伝票の承認を受けるために伝票を適切なバイヤーユーザまたは管理者ユーザに送付する（ステップ４４５０）。

伝票が承認されなければ（ステップ４４６０）、ベンダーに通知し、伝票を再提出する選択肢が与えられる（ステップ４４７０）。伝票が承認されたら（ステップ４４６０）、ベンダーに伝票が承認されたことを通知する（ステップ４４８０）。伝票が請求可能な伝票なら（ステップ４４９０）、規定のスケジュールに基づいて伝票に電子インボイス作成処理をする（システムまたはバイヤーの制約条件を用いる）（ステップ４４９５）。例えば、システムは指定の期間中に承認を受けた（一または複数のプロジェクトの）バイヤーに対する全支払伝票を回収するバッチ処理を採用できる。すべてのインボイスはバイヤーの仕様に基づくフォーマットまたはシステム定義のフォーマットで生成できる。バイヤーはインボイスを受け取り（ステップ４４９８）、予め設定した方法（例えばＥＦＩ、チェック等）でベンダーにインボイスの支払い精算をする（ステップ４４９９）。

伝票情報を支払伝票に格納し、支払い済みの伝票記録を生成する例示的なデータベース構造を以下の表８４〜９２に示す。データ構造は分かりやすくするために表形式にまとめており、各表は伝票情報を格納するのに必要なフィールドのすべてを含む。図５０に関連して述べたように、表はデータベース内の他の表と階層的かつリレーショナルに関係付ける。

以下の表８４はサンプルの一般的なプロジェクト単位完了伝票情報を表し、これは図５０に図示する表ｔｂｌ伝票単位１０６０のデータベース表構造１１７０に格納できる。例えば、一般的なプロジェクト単位完了伝票情報は、単位伝票の識別子、対応する購入申請書の識別子、単位完了に関連するすべてのタイムカードが承認されたかどうかの明示、ベンダーの識別子、伝票情報に対応する週末日、作成日、検収日、伝票情報が承認されたかどうかの明示を含めることができる。表ｔｂｌ伝票単位１０６０は図４１に関連して上記述べた表ｔｂｌ購入申請書１０００に結合して示しており、伝票情報を購入申請書に対応付ける。さらに、図４１に図示する他の表をここでは図５０に示して、様々な購入申請書の表と伝票の表との相関関係を示す。各未払単位伝票について、表８４のフォーマットの個別の記録を表ｔｂｌ伝票単位１０６０に格納することは理解されるべきである。

また、図示していないが、図４７に図示する表ｔｂｌ請負人経費伝票１０５４は未払伝票の生成用の伝票表も考慮される。他の表および伝票情報も含められることは理解されるべきであり、システムは図５０に示すそのままの表および伝票情報に限定されるものではない。

以下の表８５はサンプルの詳細なプロジェクト単位完了伝票情報を表すが、これは図５０に示す表ｔｂｌ伝票単位詳細１０６１のデータベースに格納できる。例えば、当該詳細なプロジェクト単位完了伝票情報は、単位完了の明細、認められた単位数、単価、完了した単位数、その他詳細なプロジェクト単位完了伝票情報を含めることができる。表ｔｂｌ伝票単位詳細１０６１は表ｔｂｌ伝票単位１０６０に結合して、詳細なプロジェクト単位完了伝票情報と一般的なプロジェクト単位完了伝票情報とを対応付ける。さらに、表ｔｂｌ伝票単位詳細１０６１は表ｔｂｌ購入申請書支払い単位１００９に結合して、購入申請書の単位支払い情報をプロジェクト単位完了伝票情報に対応付ける。

各未払単位伝票について、表８５のフォーマットの個別の記録が表ｔｂｌ伝票単位詳細１０６１に格納することは理解されるべきである。また、他の表およびプロジェクト単位完了伝票情報も含められることは理解されるべきであり、システムは図５０に示すそのままの表およびプロジェクト単位完了伝票情報に限定されるものではない。

以下の表８６はサンプルの一般的な作業時間完了伝票情報を表すが、これは図５０に図示する表ｔｂｌ伝票作業時間支払い１０６２のデータベースに格納できる。例えば、一般的な作業時間完了伝票情報は、作業時間伝票の識別子、対応する購入申請書の識別子、作業時間完了に関連するすべてのタイムカードが承認されているかどうかの明示、ベンダーの識別子、伝票情報に対応する週末日、作成日、検収日、および伝票情報が承認されたかどうかの明示を含むことができる。表ｔｂｌ伝票作業時間支払い１０６２は図４１に関連して上記述べた表ｔｂｌ購入申請書１０００に結合して示されており、伝票情報を購入申請書に対応付ける。各未払作業時間伝票について、表８６のフォーマットの個別の記録を表ｔｂｌ伝票作業時間支払い１０６２に格納することは理解されるべきである。

以下の表８７はサンプルの詳細な作業時間完了伝票情報を表すが、これは図５０に示す表ｔｂｌ伝票作業時間支払い詳細１０６３のデータベースに格納できる。例えば、当該詳細な作業時間完了伝票情報は、作業開始日、支払精算日、支払い金額、およびその他詳細な作業時間完了伝票情報を含むことができる。表ｔｂｌ伝票作業時間支払い詳細１０６３は表ｔｂｌ伝票作業時間支払い１０６２と結合して、詳細な作業時間完了伝票情報を一般的な作業時間完了伝票情報に対応付ける。さらに、表ｔｂｌ伝票作業時間支払い詳細１０６３は表ｔｂｌ購入申請書支払い期間１００８と結合して、申請書の作業時間支払い情報を作業時間完了伝票情報に対応付ける。

各未払単位伝票について、表８７のフォーマットの個々の記録を表ｔｂｌ伝票時間支払い詳細１０６３に格納することは理解されるべきである。さらに、他の表および時間完了伝票情報も含められることは理解されるべきであり、システムは図５０に示すそのままの表および時間完了伝票情報に限定されるものではない。

以下の表８８はサンプルのプロジェクト経費伝票の一般情報を表すが、これは図５０に示す表ｔｂｌ伝票プロジェクト経費１０６４のデータベースに格納できる。例えば、プロジェクト経費伝票の一般情報は、プロジェクト経費伝票の識別子、対応する購入申請書の識別子、プロジェクト経費に対応するすべてのタイムカード（あれば）が承認されているかどうかの明示、ベンダーの識別子、伝票情報に対応する週末日、作成日、検収日、および伝票情報が承認されているかどうかの明示を含むことができる。表ｔｂｌ伝票プロジェクト経費１０６４は図４１に関連して上記述べる表ｔｂｌ購入申請書１０００に結合して示されており、伝票情報を購入申請書に対応付ける。各未払プロジェクト経費伝票について、表８８のフォーマットの個別の記録を表ｔｂｌ伝票プロジェクト経費１０６４に格納することは理解されるべきである。

以下の表８９はサンプルのプロジェクト経費伝票の詳細情報を表し、これは図５０に示す表ｔｂｌ伝票プロジェクト経費詳細１０６５のデータベースに格納できる。例えば、当該プロジェクト経費伝票の詳細情報は、費用発生日、プロジェクト経費の明細、プロジェクト経費の金額、およびその他プロジェクト経費伝票の詳細情報を含むことができる。表ｔｂｌ伝票プロジェクト経費詳細１０６５は表ｔｂｌ伝票プロジェクト経費１０６４に結合して、プロジェクト経費伝票の詳細情報をプロジェクト経費伝票の一般情報に対応付ける。さらに、表ｔｂｌ伝票プロジェクト経費詳細１０６５は表ｔｂｌ購入申請書支払いプロジェクト経費１０１１に結合して、購入申請書のプロジェクト経費支払い情報をプロジェクト経費伝票情報に対応付ける。

各未払いプロジェクト経費伝票について、表８９のフォーマットの個別の記録を表ｔｂｌ伝票プロジェクト経費詳細１０６５に格納することは理解されるべきである。また、他の表およびプロジェクト経費伝票情報も含められることは理解されるべきであり、システムは図５０に示すそのままの表およびプロジェクト経費伝票情報に限定されるものではない。

以下の表９０はサンプルの材料伝票の一般情報を表すが、これは図５０に示す表ｔｂｌ伝票材料１０６６のデータベースに格納できる。例えば、材料伝票の一般情報は、材料伝票の識別子、対応する購入申請書の識別子、材料に対応するすべてのタイムカード（あれば）が承認されているかどうかの明示、ベンダーの識別子、伝票情報に対応する週末日、作成日、検収日、および伝票情報が承認されているかどうかの明示を含むことができる。表ｔｂｌ伝票材料１０６６は図４１に関連して上記述べる表ｔｂｌ購入申請書１０００に結合して示され、伝票情報を購入申請書に対応付ける。各未払い材料伝票について表９０のフォーマットの個別の記録を表ｔｂｌ伝票材料１０６６に格納することは理解されるべきである。

以下の表９１はサンプルの材料伝票の詳細情報を表すが、これは図５０に示す表ｔｂｌ伝票材料詳細１０６７のデータベースに格納できる。
例えば、当該材料伝票の詳細情報は、材料経費発生日、材料の名称、材料の明細、購入した材料の個数、材料の単価、およびその他プロジェクト経費伝票の詳細情報を含むことができる。表ｔｂｌ伝票材料詳細１０６７は表ｔｂｌ伝票材料１０６６に結合して示され、材料伝票の詳細情報を材料伝票の一般情報に対応付ける。さらに、表ｔｂｌ伝票材料詳細１０６７は表ｔｂｌ購入申請書支払い材料１０１０に結合し、申請書の材料支払い情報を材料伝票情報に対応付ける。

各未払い材料伝票について表９１のフォーマットの個別の記録を表ｔｂｌ伝票材料詳細１０６７に格納することは理解されるべきである。また他の表および材料伝票情報も含められることは理解されるべきであり、システムは図５０に示すそのままの表および材料伝票情報に限定されるものではない。

以下の表９２はサンプルの成果物伝票の一般情報を表すが、これは図５０に示す表ｔｂｌ伝票成果物１０６８のデータベースに格納できる。例えば、成果物伝票の一般情報は、成果物伝票の識別子、対応する購入申請書の識別子、成果物に対応するすべてのタイムカード（あれば）が承認を受けているかどうかの明示、ベンダーの識別子、伝票情報に対応する週末日、作成日、検収日、伝票情報が承認を受けているかどうかの明示を含むことができる。表ｔｂｌ伝票成果物１０６８は図４１に関連して上記述べる表ｔｂｌ購入申請書１０００に結合して示されており、伝票情報を購入申請書に対応付ける。各未払い成果物伝票について表９２のフォーマットの個別の記録を表ｔｂｌ伝票成果物１０６８に格納することは理解されるべきである。ただし、他の情報も含められることは理解されるべきであり、システムは表９２に示すそのままの情報に限定されるものではない。

以下の表９３はサンプルの成果物伝票の詳細情報を表すが、これは図５０に示す表ｔｂｌ伝票成果物詳細１０６９のデータベースに格納できる。例えば、当該成果物伝票の詳細情報は、成果物の明細、成果物の予想完了日、成果物の実際の完了日、請求される支払い金額、およびその他成果物伝票の詳細情報を含むことができる。表ｔｂｌ伝票成果物詳細１０６９は表ｔｂｌ伝票成果物１０６８に結合して示されており、成果物伝票の詳細情報を成果物伝票の一般情報に対応付ける。さらに、表ｔｂｌ伝票成果物詳細１０６９は表ｔｂｌ購入申請書支払い成果物１００７に結合して、申請書の成果物支払い情報を成果物伝票の情報に対応付ける。各未払成果物伝票について、表９３のフォーマットの個別の記録を表ｔｂｌ伝票成果物詳細１０６９に格納することは理解されるべきである。また他の表および成果物伝票情報も含められることは理解されるべきであり、システムは図５０に示すそのままの表および成果物伝票情報に限定されるものではない。

以下の表９４はサンプルの支払い済み伝票情報を表すが、これは図５０に示す表ｔｂｌ支払い済み伝票記録１０７０としてデータベースに格納できる。例えば、当該支払い済み伝票情報は、インボイス番号、バイヤーおよびベンダーが割り当てた購入申請書の識別子、伝票承認日、承認者の氏名、伝票の種類（例えば、タイムカード、請負人経費、プロジェクト経費、成果物、時間完了または単位完了）、関連伝票の識別子、インボイス金額、支払日、およびその他支払い済み伝票情報を含めることができる。

表ｔｂｌ支払い済み伝票記録１０７０は図４１に関連して上記述べる表ｔｂｌ購入申請書１０００に結合して示されており、支払い済み伝票情報を購入申請書に対応付ける。各支払い済み伝票について表９４のフォーマットの個別の記録を表ｔｂｌ支払い済み伝票記録１０７０に格納することは理解されるべきである。ただし、他の情報も含められることは理解されるべきであり、システムは表９４に示すそのままの情報に限定されるものではない。

ここで図５１を参照すると、プロジェクトの財務状態を示す例示的なウエブページ６１の画面が図示されている。このウエブページは、システムの制約条件によって、一または複数のフォーマットでバイヤー、ベンダー、および／または管理者がアクセスできる。図５１から分かるように、種々の支払伝票、および各支払伝票の見積額を表示できる。さらに、各支払伝票の種類の支払い実績、および各支払伝票の種類に支出する見積もり追加資金も追跡できる。このように、バイヤー、ベンダー、および／または管理者は財務的な観点からプロジェクト遂行の進捗状況を把握できる。ただし、図５１に示すそのままの財務情報の代わりに、またはそれに追加して、他の財務情報も表示できることは理解されるべきである。また、以下詳細に述べるように、バイヤー、ベンダー、管理者および／またはシステム構成によっては、他のプロジェクト関連情報（財務情報の代わりに、またはそれに追加して）も表示できることは理解されるべきである。
取引データの分析と報告
前述した入札前、入札、入札後の活動の間、入札／プロジェクトのプロセスに関係する様々な取引データを、プロセスに関わるバイヤー、ベンダー、および他の関係者（例えば、管理者）から取得する。図５８に図示するように、取引データ１１９５は、入札データ２１２、プロジェクト追跡パラメータ８７０、伝票情報１１６０、およびプロジェクト遂行データ１１９０の一または複数の構成要素を含むであろう。取引データ１１９５の各構成要素は入札／プロジェクトのプロセスの個々の段階中に取得する。ベンダー資格審査情報、バイヤー定義のベンダー基準情報、原材料情報、他の入札前およびプロジェクト関連データなど、他の構成要素も取引データ１１９５に含むこともできる。すなわち、取引データ１１９５はデータベースシステム１５０内に格納されるあらゆるデータを含むことができる。

例えば、ここで図５２を参照すると、バイヤー５０とベンダー１０とＰＢＭＳ（以下システムという）３０との間の情報交換を示す信号図が図示されている。前述したように、初めにバイヤー５０はシステム３０を介してベンダー１０に入札依頼書を送信する（ステップ４５００）。入札依頼書はバイヤー５０が入札依頼データを入力するデータフィールドと、ベンダー１０が応札データを入力するデータフィールドを含む。ベンダー１０が入札依頼データを適切なデータフィールドに入力すると、応札データを含む応札書がシステム３０を介してバイヤー５０に送り戻される（ステップ４５１０）。入札依頼データと応札データは合わせて、完全な入札の入札データ２１２を成す。入札データ２１２は前述したように入札に対応付けた記録としてシステムのデータベースに格納される。

バイヤー５０がある特定のベンダー１０に落札したら、バイヤー５０とベンダー１０の両者はプロジェクト追跡パラメータ８７０（例えば、購入申請書情報、課税情報等）を、入札データ２１２とともに、データベースに格納するためにシステム３０に入力できる（ステップ４５２０）。プロジェクト追跡パラメータ８７０は、商品およびサービスに対するベンダーの責任、請求対象および請求対象外など、契約条件の一部もしくは全部を含むことができる。ベンダー１０が認められた商品またはサービスを提供したら（記入したプロジェクト追跡パラメータ８７０によって判断する）、ベンダー１０はシステムにアクセスして、提供する商品または履行するサービスに関し、支払請求する伝票を提出し、またはその活動が請求対象外の場合は、バイヤーの完了確認を要求する伝票を提出する（ステップ４５３０）。伝票およびその後の伝票のインボイス作成の承認をしたら、バイヤーは予め設定した方法でベンダーに支払精算をする（ステップ４５４０）。バイヤー５０およびベンダー１０が伝票の提出および支払いプロセス中に入力した情報は、伝票情報１１６０としてデータベースに格納する。

プロジェクトの遂行中、図５３〜５７に関して以下詳細に説明するように、様々なプロジェクト遂行データ１１９０をシステム３０に入力する、またはベンダー１０およびバイヤー５０の両者が自動的に生成できる（ステップ４５５０）。例えば、プロジェクト遂行データ１１９０は、時機情報（例えば、ベンダーがプロジェクトの一または複数のフェーズまたは構成要素を完了できる時期を明示）、またはコスト情報（例えば、それぞれ予測（申請書の）コストと比較したプロジェクトの一または複数の構成要素の実績コスト）など、様々な状態情報を含むことができる。プロジェクト遂行データ１１９０も、プロジェクトの重要度もしくはプロジェクトの会社の他の側面に対する影響、または他の顧客固有の情報など、プロジェクト固有の情報も含むことができる。

入札データ２１２、プロジェクト追跡パラメータ８７０、伝票情報１１６０、およびプロジェクト遂行データ１１９０はすべて、入札およびプロジェクトに関係する取引データとしてシステムのデータベースに格納する。この取引データ全部にアクセスすることによって、システム３０は所要のほぼあらゆるタイプの分析を事実上行え、分析に基づいてレポートを生成できる。このように、システム３０はバイヤー、ベンダー、または分析データへのアクセス権をもつ別のユーザから一定のタイプの分析データの要求を受け取るように作動できる（ステップ４５６０）。要求に従い、システム３０は取引データの分析を行って、分析データを生成し（ステップ４５７０）、報告画面で分析データを要求者（例えば、バイヤー５０、ベンダー１０、または他のユーザ）に提示する（ステップ４５８０）。

例えば、バイヤー５０はある特定のプロジェクト、複数のプロジェクト、または複数のベンダー１０に関係する分析データを含むレポートを要求できる。分析データは財務情報（例えば、インボイスの詳細、支出（過去、現在、将来）、および他のタイプの財務分析）、プロジェクト情報（例えば、プロジェクト遂行、今後のプロジェクト活動、プロジェクト計画）、ベンダー情報（例えば、ベンダーの財務情報、ベンダーの経営情報、サプラ
イチェーン情報）、並びに所望のあらゆる他の種類の情報に向けられる。さらに、バイヤー５０は複数のバイヤー５０が依頼する複数のプロジェクトに関係する業界分析データを含むレポートを要求できる。業界分析データは、財務情報（例えば、プロジェクト種類の様々な側面の実績原価比率、またはプロジェクトの様々な形態の業界支出額比率）、ベンダー情報（例えば、業界内ベンダーの納期厳守率、または業界内ベンダーの原価の予算実績比）、および所要のあらゆる他の種類の業界情報に向けられる。同様な分析データをベンダー１０または許可された他のユーザに提示できる。例えば、ベンダー１０または管理者は、ベンダー１０が実施に関わるある特定のプロジェクトまたは複数のプロジェクトに関係する分析データを含むレポートを要求できる。

ここで図５３に移ると、プロジェクト遂行データ１１９０を入力する例示的な機能を図示する。本発明の実施例によるプロジェクト遂行データの入力のためのプロジェクト遂行ツール１２１および比較ツール１２３を図５３に図示する。プロジェクト遂行ツール１２１および比較ツール１２３はツールの機能を実行するのに必要なあらゆるハードウェア、ソフトウェア、および／またはファームウェアを含むことができ、サーバ１２０または追加サーバ（図示せず）内に実装できる。例えば、プロジェクト遂行ツール１２１および比較ツール１２３は図３Ｂに示すサーバ１２０内のソフトウェア・モジュール１２８に内蔵できる。

ある実施例では、プロジェクト遂行データ１１９０はバイヤー、ベンダー、または管理者がプロジェクト遂行ツール１８０から直接データベース１５５に入力できる。バイヤー、ベンダー、または管理者は、それぞれバイヤー・ブラウザ２０ａ、ベンダー・ブラウザ２０ｂ、または管理ブラウザ２０ｃ、およびデータネットワーク４０を介してコンピュータシステム１００のサーバ１２０にアクセスできる。バイヤー・モジュール１１０、ベンダー・モジュール１１５または管理モジュール１３５はプロジェクト遂行ツール１２１とインターフェースし、ウエブページをそれぞれバイヤー・ブラウザ２０ａ、ベンダー・ブラウザ２０ｂ、または管理ブラウザ２０ｃにプッシュして、プロジェクト遂行データを要請する。プロジェクト遂行ツール１２１はデータベース１５５にアクセスして、ある特定のプロジェクトに関連するプロジェクト遂行データフィールドに、バイヤー、ベンダーおよび／または管理者が入力したプロジェクト遂行データを移植する。例えば、プロジェクト遂行データは、それまでの状態または個人的なプロジェクト達成度に関するバイヤー、ベンダー、および／または管理者のコメントを含むことができる。

バイヤー、ベンダー、または管理者のいずれかからプロジェクト遂行データ１１９０を受け取ると、プロジェクト遂行ツール１２１はさらに他の関係者に新規プロジェクト遂行データ１１９０を通知するメッセージ（例えば、ｅメールのメッセージ）を自動的に生成し、それによって他の関係者は、以前に入力したプロジェクト遂行データ１１９０に関係のないデータを明確にする、応答する、または提供する追加のプロジェクト遂行データ１１９０を入力できる。

別の実施例では、比較ツール１２３はある特定のプロジェクトに関連するプロジェクト追跡パラメータ８７０と伝票情報１１６０との比較に基づいて、プロジェクト遂行データ１１９０を自動的にデータベース１５５に入力できる。比較ツールは必須のプロジェクト追跡パラメータ８７０と伝票情報１１６０をデータベース１５５から検索し、検索したプロジェクト追跡パラメータ８７０と伝票情報１６０の比較または分析を行い、比較または分析の結果に基づいて、あらゆる必要なプロジェクト遂行データ１１９０をデータベース１５５内のプロジェクトに対応するデータフィールドに入力する。

例として、比較ツール１２３はデータベース１５５に新規伝票情報１１６０の入力があるかをモニタリングするように構成でき、またはそうでなければ、新規伝票情報１１６０
の入力があると、入力された伝票情報１１６０とプロジェクトに関して以前に格納されたプロジェクト追跡パラメータ８７０を比較するように駆動できる。伝票情報１１６０は、原価、時機、またはプロジェクト追跡パラメータ８７０と比較する他の情報を含むことができる。比較の結果をプロジェクト遂行データ１１９０としてデータベース１５５に格納できる。例えば、伝票情報１１６０はプロジェクトに関してバイヤー５０が支払ったインボイスの金額を明示できるであろうし、比較ツール１２３はインボイスの金額と購入申請書の金額を比較して差異があるかどうかを判定できる。この場合、プロジェクト遂行データ１１９０は、予算未消化、予算超過、または予算どおりなどの原価の状態の明示、またあれば、予算超過額または予算未消化額を含むことができよう。

別の例として、比較ツール１２３は特定のプロジェクト追跡パラメータ８７０があるかデータベース１５５を探索して、プロジェクト追跡パラメータ８７０の状態をプロジェクト遂行データ１１９０として入力するように構成できる。例えば、比較ツール１２３はプロジェクトの期限切れの目標完了日があるかデータベース１５５を探索して、各プロジェクトの遅延日数をそれらプロジェクトに関係するプロジェクト遂行データ１１９０として入力できる。比較ツール１２３はまた、それら遅延プロジェクトに関係する伝票情報１１６０を探索して、伝票情報１１６０に基づいてプロジェクトの状態を入力できる。例えば、ベンダーが支払伝票をすでに提出しているが、バイヤーがまだ支払いを行っていない場合、伝票提出済み、支払い待ちの状態を明示できるであろう。

プロジェクト遂行データ１１９０を様々なシステムの展開から入力する例示的なプロセスを図５４〜５６に図示する。図５４は、バイヤー、ベンダー、または管理者などのユーザが、プロジェクト遂行データをシステムに入力する例示的なステップを示す。プロジェクトに関連するユーザからプロジェクト遂行データを受け取ると（ステップ４６００）、システムは後に使用および検索するためにプロジェクト遂行データをプロジェクトに対応するデータフィールドに格納する（ステップ４６１０）。プロジェクトに関わる関係者（バイヤー、ベンダー、および管理者）がプロジェクト遂行データの一部もしくは全部を関係者同士で開示させる条件を定めている場合、システムは関係者が定めた条件に従って、他の関係者にプロジェクト遂行データを受け取ったことを通知するメッセージを他の関係者に生成する（ステップ４６２０）。メッセージに応答して、他の関係者は以前に入力したプロジェクト遂行データに関係ないデータを明確にする、応答する、または提供する追加のプロジェクト遂行データを入力することにしてもよい。追加のプロジェクト遂行データを受け取ったら（ステップ４６３０）、システムは追加のプロジェクト遂行データを、データベース内に以前に入力したプロジェクト遂行データとともに、プロジェクトに対応するデータフィールドに格納する（ステップ４６４０）。

図５５は、以前に格納したプロジェクト追跡パラメータと伝票情報に基づいて、プロジェクト遂行データを自動的にシステムに入力する例示的なステップを図示する。システムがある特定のプロジェクトの、プロジェクト追跡パラメータ（ステップ４７００）と伝票情報（ステップ４７１０）の両方を受け取った後、システムはプロジェクト追跡パラメータと伝票情報を比較して（ステップ４７２０）、プロジェクトの状態を判断できる（ステップ４７３０）。プロジェクトの状態をシステムに入力して、プロジェクトに関係するプロジェクト遂行データとして格納できる（ステップ４７４０）。例えば、伝票情報はプロジェクトの実際のプロジェクト完了日を明示でき、システムは実際のプロジェクト完了日と目標プロジェクト完了日とを比較して、差異があるかを判定できる。この場合、プロジェクト遂行データは、納期どおりの完了、納期を過ぎた完了、または早期完了などの状態の明示とともに、遅延日数または繰上げ日数を含むことができよう。

図５６は、以前に格納したプロジェクト追跡パラメータの状態に基づいて、プロジェクト遂行データを自動的にシステムに入力する例示的なステップを図示している。システム
が目標完了日など、ある特定のプロジェクトのプロジェクト追跡パラメータを受け取った後（ステップ４７５０）、システムはプロジェクトの期限切れの目標完了日についてデータベースを探索できる（ステップ４７６０）。期限切れの完了日が見つかったら（ステップ４７７０）、システムは、すでに受け取っているあらゆる伝票情報に基づいて、プロジェクトの状態を判断し（ステップ４７８０）、プロジェクトの状態をプロジェクト遂行データとしてシステムに入力できる（ステップ４７９０）。

プロジェクト遂行データ１１９０を格納する例示的なデータベース構造を以下の表９５〜１１２に示す。データ構造は分かりやすいように表形式にまとめて表しており、各表はプロジェクト遂行データ１１９０を格納するのに必要なフィールドのすべてを含む。表は図５７に関連して述べるようにデータベース内に格納される他の表と階層的かつリレーショナルに関係付ける。

以下の表９５および９６はサンプルの成果物プロジェクト遂行データを表し、これは図５７に示すデータベース表構造１１８５の表ｔｂｌ成果物遂行追跡１０８０および表ｌｋｐ成果物状態１０８１に格納できる。成果物プロジェクト遂行データは、表ｌｋｐ成果物状態１０８１から判断する成果物の状態を含むことができる。例えば、成果物の状態とは、未完了―現在、未完了―遅延、一部完了―現在、一部完了―遅延、完了―納期通り、完了―遅延、または完了―早期となりうる。状態に対応する識別子を、表ｔｂｌ購入申請書支払い成果物１００７に格納される成果物プロジェクト追跡パラメータに対応する識別子、現在の状態（例えば、遅延日数または繰上げ日数）、およびあればユーザの備考とともに、表ｔｂｌ成果物遂行追跡に格納できる。

例えば、バイヤー、ベンダー、または他のユーザが成果物の状態に関係するなんらかのコメントを入力した場合、これらのコメントは表ｔｂｌ成果物遂行追跡１０８０に格納できる。コメントに加えて、コメントを入力したユーザのアイデンティティと、コメントを入力した日も格納できる。システムがバイヤーがコメントを入力したときにベンダーに通知するように構成される場合、ベンダーの応答の状態（現在未応答、応答なし、応答）も格納できる。

表ｔｂｌ成果物遂行追跡１０８０とｌｋｐ成果物状態１０８１を表ｔｂｌ購入申請書支払い成果物１００７に結合して示しており、これはさらに図４１に関連して上記述べる表ｔｂｌ購入申請書１０００に結合して、プロジェクト遂行データを伝票情報およびプロジェクト追跡パラメータ（例えば、購入申請書）に対応付ける。さらに、図４１に示す様々な他の表をこの図５７で図示し、様々なプロジェクト遂行表、伝票表、および購入申請書表の間の相関関係を示す。各成果物について表９５のフォーマットの個別の記録が表ｔｂｌ成果物遂行追跡に格納されることは理解されるべきである。他の表およびプロジェクト遂行データも含められることは理解されるべきであり、システムは図５７に示すそのままの表およびプロジェクト遂行データに限定されるものではない。

以下の表９７および９８はサンプルのフェーズ別プロジェクト遂行データを表し、これは図５７に示すデータベース表構造１１８５の表ｔｂｌフェーズ遂行追跡１０８２および表ｌｋｐフェーズ状態１０８３に格納できる。フェーズ別プロジェクト遂行データは、表ｌｋｐフェーズ状態１０８２から判断するフェーズの状態を含むことができる。例えば、フェーズの状態は、進行―現在、進行―遅延、進行―将来日、終結―納期通り、終結―遅延、または終結―早期となりうる。状態に対応する識別子は、図４１に示す表と同様な表でよい表ｔｂｌ購入申請書フェーズ別１０１８に格納されるフェーズ別プロジェクト追跡パラメータ、現在の状態（例えば、遅延日数または繰上げ日数）、およびあればユーザの備考とともに、表ｔｂｌフェーズ遂行追跡に格納できる。

例えば、バイヤー、ベンダー、または他のユーザがフェーズの状態に関係するなんらかのコメントを入力したら、これらコメントは表ｔｂｌフェーズ遂行追跡１０８３に格納できる。コメントに加えて、コメントを入力したユーザのアイデンティティ、およびコメントを入力した日も格納できる。バイヤーがコメントを入力したときにベンダーに通知するようシステムが構成されている場合、ベンダーの応答の状態（例えば、現在未応答、応答なし、応答）も格納できる。

以下の表９９および１００はサンプルの単位プロジェクト遂行データを表し、これは図５７に示すデータベース表構造１１８５の表ｔｂｌ単位遂行追跡１０８４および表ｌｋｐ単位状態１０８５に格納できる。単位プロジェクト遂行データは、表ｌｋｐ単位状態１０８５から判断する単位の状態を含むことができる。例えば、単位の状態は、未完了―現在、未完了―遅延、完了―納期通り、完了―遅延、または完了―早期となりうる。状態に対応する識別子は、表ｔｂｌ購入申請書支払い単位１００９に格納される単位プロジェクト追跡パラメータに対応する識別子、現在の状態（例えば、遅延日数または繰上げ日数）、およびあればユーザの備考とともに、表ｔｂｌ単位遂行追跡に格納できる。

例えば、バイヤー、ベンダー、または他のユーザが単位の状態に関係するなんらかのコメントを入力したら、これらコメントは表ｔｂｌ単位遂行追跡１０８４に格納できる。コメントに加えて、コメントを入力したユーザのアイデンティティとともに、コメントを入力した日も格納できる。バイヤーがコメントを入力したときにベンダーに通知するようシステムが構成されている場合、ベンダーの応答の状態（例えば、現在未応答、応答なし、応答）も格納できる。

以下の表１０１および１０２はサンプルのコストプロジェクト遂行データを表し、図５７に示すデータベース表構造１１８５の表ｔｂｌコスト遂行追跡１０８６および表ｌｋｐコスト状態１０８７に格納できる。コストプロジェクト遂行データは、材料伝票、経費伝票、成果物伝票、フェーズ別伝票、単位伝票、および賃金支払伝票を含め、あらゆる種類の伝票の支払い済み伝票に関係付けることができる。コストプロジェクト遂行データは、表ｌｋｐコスト状態１０８７から判断したコストの状態によって表される。例えば、コストの状態は、予算超過、予算未消化、または予算どおりとなりうる。状態に対応する識別子は、表ｔｂｌ支払い済み伝票記録１０７０に格納される伝票情報に対応する識別子、現在の状態（例えば、予算超過額または予算未消化額）、およびあればユーザの備考とともに、表ｔｂｌコスト遂行追跡に格納できる。

例えば、バイヤー、ベンダー、または他のユーザがコストの状態に関係する何らかのコメントを入力したら、これらコメントを表ｔｂｌコスト遂行追跡１０８６に格納できる。コメントに加えて、コメントを入力したユーザのアイデンティティとともに、コメントを入力した日も格納できる。バイヤーがコメントを入力したときにベンダーに通知するようにシステムを構成する場合、ベンダーの応答の状態（例えば、現在未応答、応答なし、応答）も格納できる。

プロジェクトおよび／またはベンダーもしくはバイヤーに関係し、プロジェクトの種類の一層の識別に役立つ追加データ、および今まで明示的に述べていない他のプロジェクト変数を含む他の表が図５７に示されている。分析および報告のために利用する取引データに追加データを含めることができる。例えば、以下の表１０３はバイヤーの他の側面に対するプロジェクトの影響を表すが、これは図５７に示すデータベース表構造１１８５の表ｌｋｐプロジェクト影響コード１０７２に格納でき、以下の表１０４は成果物の重要度を表すが、これはデータベース表構造１１８５の表ｌｋｐ成果物重要度に格納でき、以下の表１０５はプロジェクトの所有権の状態を表すが、これはデータベース表構造１１８５の表ｌｋｐＰＭ所有権状態１０７３に格納できる。

ベンダーおよびバイヤーに関係する他の情報は追加の表に格納できる。例えば、以下の表１０６はマスターベンダーデータを表すが、これは図５７に示すデータベース表構造１１８５の表ｌｋｐベンダーマスター１０９０に格納でき、以下の表１０７はマスターバイヤーデータを表すが、これはデータベース表構造１１８５の表ｌｋｐバイヤーマスター１０９５に格納できる。さらに、以下の表１０８および１０９は、バイヤーがベンダーに割り当てた階層グループを示すベンダー階層情報を表し（例えば、階層１のベンダーは典型的には優先的にまたは最も頻繁に利用されるベンダーである）、これは図５７に示すデータベース表構造１１８５の表ｌｋｐベンダー階層１０９１およびｔｂｌベンダー階層マップ１０９２に格納できる。また、以下の表１１０〜１１２はバイヤーの産業区分、支出および規模情報を表し、これは図５７に示すデータベース表構造１１８５の表ｌｋｐ産業区分１０９６、ｌｋｐバイヤー支出水準１０９７、ｌｋｐバイヤー規模水準１０９８に格納できる。産業区分はプロジェクト固有またはバイヤー全体に適用できる。

図５２に関連して上記述べたように、プロジェクト遂行データはデータベースに格納する取引データの一部を成す。もう一度図５８を参照すると、取引データ１１９５は入札データ２１２だけでなく、プロジェクト追跡パラメータ８７０、伝票情報１１６０、およびプロジェクト遂行データ１１９０も含めてもよい。取引データ１１９５はすべて、バイヤー、ベンダー、および管理者のデータベース（１５５、図示せず）を含む低レベルのデータベースシステム１５０に格納する。ある実施例では、取引データ１１９５は低レベルのデータベース１５０だけに維持し、そのため、分析データはその低レベルのデータベース内の取引データ１１９５にのみ制限される。例えば、バイヤー／管理者またはベンダーは自分たちの取引データへの外部（第三者）ソースからのアクセスを許可しないことがある。この場合、バイヤー／管理者またはベンダーの取引データを含む分析データを生成するには、バイヤー／管理者またはベンダーは自分だけの取引データに限られる。

図５９に示す別の実施例では、取引データ１１９５の全部もしくは一部をトップレベルのデータベース１６０（以下、中央データベース１６０という）まで転送して、分析のために後で使用または検索する。取引データは低レベルのデータベース１５５から中央データベース１６０にいつでもまたはいかなる理由でも転送できる。例として、複数のバイヤーのデータベース１５５ａ、１５５ｂ、および１１５ｃにそれぞれ格納される取引データ１１９５ａ、１１９５ｂ、および１１９５ｃ（集合的に１１９５という）を中央データベース１６０まで転送して、格納できる。転送は、記録作成日が指定期間内の取引データ１１９５を一括して中央データベース１６０まで転送するバッチモードプロセスで行うことができる。例えば、毎週、記録作成日がその週の間である取引データ１１９５すべてを一括して中央データベース１６０まで転送できる。

転送した取引データ１１９５は低レベルデータベース１６０内の取引データ１１９５の全部、またはシステムまたはバイヤー／管理者および／またはベンダーが指定する部分だけを含めることができる。例えば、取引データ１１９５の様々な部分は業界全体の分析には必要ないかもしれないため、中央データベース１６０に転送する取引データ１１９５は不必要なその部分を省いてもよい。別の例として、バイヤー／管理者および／またはベンダーはプライバシーまたは他の理由で、中央データベース１６０に利用させる取引データ１１９５の種類を制限したいと思うこともあろう。

ここで図６０を参照すると、分析データ２７０を生成するための例示的な機能が図示される。本発明の実施例により、分析データ２７０を生成するための報告モジュール１２６または１２７が図６０に示される。報告モジュール１２６または１２７はモジュールの機能を実行するのに必要なあらゆるハードウェア、ソフトウェア、および／またはファームウェアを含むことができ、それぞれサーバ１２０または１２５に、あるいは追加サーバ（
図示せず）に実装できる。例えば、報告モジュール１２６は図３Ｂに示すサーバ１２０内のソフトウェア・モジュール１２８に内蔵できる。

分析データ２７０は、所要の分析データ２７０の種類によって、低レベルデータベースシステム１５０内の低レベルデータベース（具体的には図示せず）からの取引データ１１９５、または中央データベース１６０からの取引データ１１９５を使って生成できる。例えば、バイヤーユーザがバイヤーに関連するプロジェクトのみに関係する分析データを必要とする場合、バイヤーユーザは低レベルデータベースシステム１５０内のバイヤーの低レベルデータベース内の取引データ１１９５にアクセスするであろう。ただし、バイヤーユーザが複数のバイヤーに関連するプロジェクトに関係する業界分析データを必要とする場合、バイヤーユーザは中央データベース１６０内の取引データ１１９５にアクセスするであろう。

低レベルデータベースシステム１５０または中央データベース１６０のいずれかから取引データ１１９５を使った分析データ２７０を受け取るには、バイヤーユーザ、ベンダーユーザ、または管理ユーザはそれぞれバイヤー・ブラウザ２０ａ、ベンダー・ブラウザ２０ｂ、または管理ブラウザ２０ｃとデータネットワーク４０を介して、データベース１５０または１６０に対応する各サーバ１２０または１２５にアクセスする。バイヤー・モジュール１１０または１４０、ベンダー・モジュール１１５または１４５、もしくは管理モジュール１３５または１４９は報告モジュール１２６または１２７にインターフェースして、ウエブページをそれぞれバイヤー・ブラウザ２０ａ、ベンダー・ブラウザ２０ｂ、または管理ブラウザ２０ｃにプッシュして、バイヤーユーザ、ベンダーユーザ、または管理ユーザがある特定の種類の分析データ２７０の要求２８５を生成するのを支援する。例えば、要求される分析データ２７０は取引データ１１９５の関数として様々な価格および遂行因子に関係付けることができる。分析データ２７０は単一のプロジェクト、複数のプロジェクト、複数のベンダーまたは複数のバイヤーに関係付けることができ、後者は中央データベースの取引データ１１９５だけを使えば可能である。生成できる多様な種類の分析データ２７０の多様な順列と可能性は、格納される取引データ１１９５の種類と量によってのみ制限される。さらに、図示していないが、別の実施例では、請負人ユーザには請負人ユーザが閲覧を許可されている様々な分析データ２７０、例えば、請負人が現在までにプロジェクトに要した作業時間数、一定の期間内に全プロジェクトに要した作業時間数、多様なプロジェクトの賃率、平均賃率等などにアクセスするのを認めてもよいことは理解されるべきである。

ある実施例では、ユーザが提出した要求２８５は分析データ２７０を特定の取引データ１１９５に的を絞るために一または複数のフィルタ２８０を含んでもよい。例えば、ユーザは特定の地理的地域で完了したプロジェクトのみに関係する分析データ２７０、もしくは特定のプロジェクトの種類または産業区分に関連する分析データ２７０を受け取りたいと思うこともあろう。報告モジュール１２６または１２７はフィルタ２８０を使ってデータベース１５０または１６０にアクセスして、フィルタ２８０の要件を満たす取引データのみを含むフィルタリングした取引データ１１９８を検索する。フィルタリングした取引データ１１９８から、報告モジュール１２６または１２７は分析データ２７０を生成する。

取引データ１１９５またはフィルタリングした取引データ１１９８を使って、報告モジュール１２６または１２７は要求２８５に基づく分析データ２７０を生成する。例えば、要求２８５が現在のプロジェクトに関し今後何ヶ月間の予測支出を示す財務報告に関するものの場合、報告モジュール１２６または１２７は取引データ１１９５にアクセスして、現在のプロジェクトの今後の購入申請書の金額に関係する様々なプロジェクト追跡パラメータを検索し、購入申請書の金額を月別に集計して分析データ２７０を生成する。別の例
では、要求２８５が階層１のベンダーのプロジェクトの様々な構成要素（例えば、材料、経費、成果物、労務等）の支出比率に関する統計レポートの場合、報告モジュール１２６または１２７は取引データ１１９５にアクセスして、様々な入札データ（階層１のベンダーに結合するプロジェクトを判断するため）、プロジェクト追跡パラメータ、伝票情報、およびプロジェクト遂行データを検索し、様々な算術および統計関数を利用して分析データ２７０を出す。報告モジュール１２６または１２７は分析データを掲載した報告画面を含むウエブページをバイヤー・ブラウザ２０ａ、ベンダー・ブラウザ２０ｂ、または管理ブラウザ２０ｃにプッシュする。

様々な種類の取引データを使って様々な種類の統計データ２７０を生成する例示的なプロセスを図６１〜６７に図示する。ただし、図示するプロセスは、本発明のシステムを使って行える数多くのプロセスのうちの単なる例であることは理解されるべきである。図６１は、システムのユーザが要求する分析データを生成するプロセスを表した例示的なフローチャートである。このプロセスでは、オンラインでの入札プロセス中に収集した少なくとも入札データを含む取引データの関数としての分析データの要求を受け取る（ステップ４８００）。要求は、入札で提出された入札データのうち特定の種類または不特定の種類を選択する探索および／または並べ替え要求として提出できる。さらに、要求は選択した種類の入札データの中で、分析データの生成に使用する入札データの量を絞るための一または複数のフィルタを含んでもよい。

必要な取引データを識別して検索したら、その取引データから分析データを生成する（ステップ４８１０）。分析データを生成するにあたり、様々な算術および統計関数を利用してユーザが要求する多様な情報を出すことができる。分析データは、単一のプロジェクト、複数のプロジェクト、複数のベンダー、または複数のバイヤーに関係する入札データから生成でき、多様な報告画面でユーザに提示できる。例えば、例示的な報告画面は、サマリー画面、集計画面、見積画面、統計画面、プロジェクト遂行画面、またはそのあらゆる組み合わせを含む。ユーザは個々の入札の評価、ベンダー遂行の評価、支出または収入の評価、業界内の価格上昇の評価、業界トレンド情報の生成等を含めた様々な目的で、統計データを利用できるであろう。

図６２は、システム内の現在、過去、および／または将来のプロジェクトにわたる集計プロジェクト遂行データを含む分析データを生成するプロセスを表す例示的なフローチャートである。図５３〜５６に関連して上記述べたように、プロジェクト遂行データはシステムに格納する（ステップ４８２０）。このプロセスでは、システムの許可ユーザから集計プロジェクト遂行データの要求を受け取る（ステップ４８３０）。要求は、システムが収集した特定の種類または不特定の種類のプロジェクト遂行データを選択する探索および／または並べ替え要求として提出できる。さらに、要求は、選択した種類のプロジェクト遂行データの中で、分析データの生成に使うプロジェクト遂行データの量を絞るための一または複数のフィルタを含んでもよい。要求とは、一または複数のベンダーが一または複数のバイヤーのために遂行する複数にわたるプロジェクトからプロジェクト遂行データを収集して、プロジェクト遂行データを集計することであることは理解されるべきである。

必要なプロジェクト遂行データを識別して検索したら、集計プロジェクト遂行データを生成する（ステップ４８４０）。集計プロジェクト遂行データの生成にあたり、算術および／または統計分析演算を利用できる。例えば、システムは、納期どおりまたは予算未消化等のプロジェクトの比率など、プロジェクトに関係する様々な情報を計算できる。集計プロジェクト遂行データは多様な報告画面でユーザに提示できる。例えば、例示的な報告画面は、サマリー画面、見積画面または統計画面を含む。ユーザは、あるベンダーの個々の遂行を他のベンダーと比較して評価、過去、現在または将来の支出もしくは収入の評価、業界内の価格上昇の評価、業界トレンド情報の生成等を含めた様々な目的で、集計プロ
ジェクト遂行データを利用できよう。

図６３は、個別プロジェクトに関係する集計統計プロジェクト遂行データを含む分析データを生成するプロセスを表す例示的なフローチャートである。図５３〜５６に関連して上記述べたように、プロジェクト遂行データはシステムによって格納する（ステップ４８５０）。このプロセスでは、システムの許可ユーザから集計統計プロジェクト遂行データの要求を受け取る（ステップ４８６０）。要求は、システムが収集した特定の種類または不特定の種類のプロジェクト遂行データを選択する探索および／または並べ替え要求として提出できる。さらに、要求は、選択した種類のプロジェクト遂行データの中で、分析データの生成に使うプロジェクト遂行データの量を絞るための一または複数のフィルタを含んでもよい。要求とは、一または複数のベンダーが一または複数のバイヤーのために遂行する複数にわたるプロジェクトからプロジェクト遂行データを収集して、個別プロジェクトに関係する統計データを計算し、統計データを集計することであることは理解されるべきである。

必要なプロジェクト遂行データを識別して検索したら、様々な算術および／または統計分析演算を使って個別プロジェクトに関して統計プロジェクト遂行データを計算する（ステップ４８７０）。統計分析は、平均月別コスト、平均支出、プロジェクトの様々な構成要素または側面の原価比率等など、プロジェクトに関する多様な情報を計算できる。その後、個々の統計データを集計して、統計プロジェクト遂行データを生成する（ステップ４８８０）。集計統計プロジェクト遂行データは多様な報告画面でユーザに提示できる。例えば、例示的な報告画面はサマリー画面、見積画面等を含む。ベンダーが遂行する複数のプロジェクトにわたる統計データを集計することによって、バイヤーは遂行されるプロジェクトの全体像を把握でき、プロジェクトを全体として評価するのに役立つ。

図６４は、取引データに基づく分析データの生成を表す例示的なフローチャートであり、取引データは少なくとも入札データ、プロジェクト追跡パラメータ、およびプロジェクト遂行データを含む。図５２に関連して上記述べたように、取引データはシステムに格納する（ステップ４９００）。このプロセスでは、分析データの要求をシステムの許可ユーザから受け取る（ステップ４９１０）。要求は、システムが収集した特定の種類または不特定の種類の取引データを選択する探索および／または並び替え要求として提出できる。さらに、要求は分析データの生成で使う選択した種類の取引データ内の取引データの量を狭めるための一または複数のフィルタを含んでもよい。

必要な取引データを識別して検索したら、取引データの一または複数の構成要素（例えば、入札データ、プロジェクト追跡パラメータ、および／またはプロジェクト遂行データ）から分析データを生成する（ステップ４９２０）。分析データを生成するにあたり、様々な算術および統計関数を利用して、ユーザが要求する多様な情報が得られる。分析データは、単一のプロジェクト、複数のプロジェクト、複数のベンダー、または複数のバイヤーに関係する取引データから生成でき、多様な報告画面でユーザに提示できる。例えば、例示的な報告画面は、サマリー画面、集計画面、見積画面、統計画面、プロジェクト遂行画面、またはそのあらゆる組み合わせを含む。分析データをグラフ表示して、ユーザのプロジェクトまたは業界トレンド分析に役立ててもよい。

図６５は、取引データを収集し、取引データから分析データを生成するより詳細なプロセスを表す例示的なフローチャートである。まず、バイヤーが入札を作成するが、入札はバイヤーおよびベンダーから入札データを受け取るデータフィールドを含む（ステップ４９５０）。例えば、データフィールドはバイヤーおよびベンダーが価格、数量、および調達時期の条件に関係する入札データを入力できるようにする。入札に含まれるデータフィールドは、入札活動の部分で上記述べたように、選択した入札項目に対応付けることは理
解されるべきである。システムがバイヤーおよびベンダーから入札データを受け取ると（ステップ４９５５）、入札データを取引データとしてシステムに格納する（ステップ４９６０）。

プロジェクトが落札されると、入札に関係するプロジェクトのプロジェクト追跡パラメータを受け取り（ステップ４９６５）、別の取引データとして格納する（ステップ４９７０）。プロジェクトの遂行中、プロジェクトに関係する様々なプロジェクト遂行データを受け取り（ステップ４９７５）、別の取引データとして格納する（ステップ４９８０）。取引データを受け取って格納してしまったら、取引データの関数として分析データを求める次の要求を受け取る（ステップ４９８５）。要求は、システムが収集した特定の種類または不特定の種類の取引データを選択するために、ユーザが探索および／または並び替え要求として提出してもよい。さらに、要求は選択した種類の取引データの中で、分析データの生成に使用する取引データの量を絞るために一または複数のフィルタを含んでもよい。

必要な取引データを識別して検索したら、取引データの一または複数の構成要素（例えば、入札データ、プロジェクト追跡パラメータ、および／またはプロジェクト遂行データ）から分析データを生成する（ステップ４９９０）。分析データを生成するにあたり、様々な算術および統計関数を利用して、ユーザが要求する多様な情報を得られる。分析データは、単一のプロジェクト、複数のプロジェクト、複数のベンダー、または複数のバイヤーに関係する取引データから生成でき、多様な報告画面でユーザに提示できる。例えば、例示的な報告画面は、サマリー画面、集計画面、見積画面、統計画面、プロジェクト遂行画面、またはそのあらゆる組み合わせを含む。分析データをグラフ表示して、ユーザのプロジェクトまたは業界トレンド分析に役立つ。

図６６は、一または複数のバイヤーのプロジェクトが生み出す取引データの関数としての業界分析データを生成するプロセスを表す例示的なフローチャートである。システムは複数のバイヤーのプロジェクトを管理できるため、業界全体にわたり遂行されるプロジェクトから業界分析データを評価できる。システムを使用する当然のこととして、システムを利用するバイヤーの様々なプロジェクトを取引情報から追跡できる。複数のバイヤーの取引データを分析することにより、業界トレンドを明らかにできる。例えば、電気通信業界では、中央スイッチの設置に関係する複数のプロジェクトがあるかもしれないが、本発明の原理を利用して中心スイッチの平均コスト、開発時間、設置時間、故障率を生成できよう。

まず、業界分析プロセスは、システム（例えば、図２Ａの管理サーバ１２５）が業界分析データの要求を受け取った時点で始まる（ステップ５０００）。要求はベンダー、バイヤー、またはシステムの管理者からのものでありうる。要求に基づいて、中央データベースの複数のバイヤーの複数のプロジェクトに関係する取引データにアクセスする（ステップ５０１０）。要求は、システムが収集する特定の種類または不特定の種類の取引データを選ぶために、ユーザが探索および／または並べ替え要求として提出してもよい。さらに、要求は選択した種類の取引データの中から、分析データの生成に使用する取引データの量を絞るために、一または複数のフィルタを含んでもよい。

必要な取引データを識別して検索したら、業界分析データを取引データの関数として生成できる（ステップ５０２０）。業界分析データの生成にあたり、算術および／または統計関数を利用して、ユーザが見たい多様な業界分析データを引き出せる。業界分析データは多様な報告画面でユーザに提示できる。例えば、例示的な報告画面は、サマリー画面、集計画面、見積画面、統計画面、プロジェクト遂行画面、またはそのあらゆる組み合わせを含む。分析データをグラフ表示して、ユーザのプロジェクトまたは業界トレンド分析に
役立てる。

図６７は、複数のバイヤーからバッチモードプロセスで取引データを収集し、取引データから業界分析データを生成するより詳細なプロセスを表す例示的なフローチャートである。個々のプロジェクトの取引データは、プロジェクトに関係するバイヤー、ベンダー、および管理者に対応する低レベルのデータベースに格納する（ステップ５０５０）。業界分析データの要求を処理するために、各低レベルのデータベースから必要かつ許可された取引データを、前述したように、また当分野で了解されるように、バッチモードプロセスとして中央データベースに引き出す（ステップ５０６０）。バッチ取引データを受け取って格納したら、バッチ取引データの関数としての業界分析データを求める次の要求を受け取る（ステップ５０７０）。要求は、システムが収集する特定の種類または不特定の種類の取引データを選択するために、ユーザが探索および／または並び替え要求として提出してもよい。さらに、要求は選択した種類の取引データの中から、分析データの生成に使用する取引データの量を絞るために、一または複数のフィルタを含んでもよい。

要求およびあればフィルタに基づいて、システムはバッチ取引データにアクセスして、要求される業界分析を行うのに必要な特定のバッチ取引データを識別して検索する（ステップ５０８０）。その後、識別したバッチ取引データから業界分析データを生成する（ステップ５０９０）。業界分析データを生成するにあたり、様々な算術および統計関数を利用して、ユーザが要求する多様な情報が得られる。業界分析データは多様な報告画面でユーザに提示できる（ステップ５０９５）。例えば、例示的な報告画面は、サマリー画面、集計画面、見積画面、統計画面、プロジェクト遂行画面、またはそのあらゆる組み合わせを含む。業界分析データをグラフ表示して、ユーザのプロジェクトまたは業界トレンド分析に役立ててもよい。

前述したように、ユーザが提出する分析データの要求は、分析プロセスに利用する取引データの種類を目的に合わせて絞り込む一または複数のフィルタを含むことができる。ここで図６８を参照すると、分析および報告目的でフィルタリングした取引データ１１９８を検索するために、データベース１５５または１６０にアクセスするのに使用できる例示的な種類のフィルタ２８０が図示されている。例えば、フィルタ２８０はベンダープロファイルプロパティ２８０ａ、バイヤープロファイルプロパティ２８０ｂ、プロジェクトプロファイルプロパティ２８０ｃ、および原材料プロファイルプロパティ２８０ｄを含むことができる。ベンダープロファイルプロパティ２８０ａは、ベンダーの階層グループ、ベンダーの事業体の種類、ベンダー資格審査データ、ベンダーの地理的場所等など、ベンダーに関係するあらゆる種類のデータを含む。同様に、バイヤープロファイルプロパティ２８０ｂは、バイヤーの産業区分、バイヤーの規模または支出能力、バイヤーの地理的場所等など、バイヤーに関係するあらゆる種類のデータを同様に含む。プロジェクトプロファイルプロパティ２８０ｃは、プロジェクトの種類、プロジェクト管理所有形態、ビジネス影響の種類、プロジェクトの地理的場所、プロジェクトセクター／ファミリー、その他プロジェクト追跡パラメータ等など、プロジェクトに関係するあらゆる種類のデータを含む。原材料プロファイルプロパティ２８０ｄは、原材料に関連するプロジェクトセクター／ファミリー、リソースプロファイリング、活動形態、地理的場所等など、原材料（例えば、人的資源または材料資源）に関係するあらゆる種類のデータを含む。

データベースからフィルタリングした取引データを検索する例示的なステップを図６９に示す。取引データをデータベースに格納した（ステップ５１００）後、取引データの関数としての分析データを求める次の要求を受け取ることができる（ステップ５１１０）。要求の種類に基づいて（例えば、要求される分析データの種類）、システムはデータベースにアクセスして、要求に応えるために必要な取引データの種類を検索する（ステップ５１２０）。要求が一または複数のフィルタを含んでいた場合（ステップ５１３０）、シス
テムは検索した取引データをフィルタリングして（ステップ５１４０）から、要求される分析データを生成する（５１５０）。フィルタは分析プロセスで使用する取引データの量を絞る機能を果たす。例えば、要求がバイヤーのプロジェクトの月別支出を集計する財務レポートに関するものの場合、バイヤーは、ある特定のベンダーのプロジェクトまたはある特定のプロジェクト種類のプロジェクトに関する月別支出のみを含むようにレポートをフィルタリングできる。

分析データを含む報告画面を提示する例示的なウエブページの画面を図７０〜８８に図示する。図７０は、バイヤーユーザのメイン報告メニューのウエブページ６１の例示的な描写である。同様なメイン報告メニューがベンダーユーザ、管理ユーザ、および請負人ユーザに提示できることは理解されるべきである。メイン報告メニューは、ユーザが様々な観点からプロジェクトを管理できるように設計される。そのため、メイン報告メニューから、ユーザは報告の種類３５０を選択でき、そこからユーザは特定の報告画面３６０を選択できる。例えば、図７０は、財務、プロジェクト、およびベンダー／人的資本という３つの報告の種類３５０を示す。これら報告の種類の各々の中に多数の報告画面３６０がある。

財務報告の種類３５０内の報告画面３６０の例は、インボイス詳細報告画面、原材料サマリー報告画面、将来支出モデル化／予算編成報告画面、および完成プロジェクト財務分析報告画面である。プロジェクト報告の種類３５０内の報告画面３６０の例は、プロジェクト遂行報告画面、今後の計画フェーズ・成果物活動報告画面、およびプロジェクト管理計画モジュール報告画面である。ベンダー／人的資本報告の種類３５０内の報告画面３６０の例は、財務報告画面、業務報告画面、およびサプライチェーン報告画面である。ただし、本発明は図７０に示すそのままの報告の種類３５０および報告画面３６０に限定されるものではなく、図７０に含まれる報告の種類３５０および報告画面３６０は単に分かりやすいように例示の目的であることは理解されるべきである。多種多様な報告の種類３５０および報告画面３６０の数は、システムが維持する取引データの種類と量、およびユーザの要件によってのみ制限される。

報告画面３６０の具体的な種類の例を図７１〜８８に図示する。例えば、図７１は、インボイス詳細報告画面３６０を提示するウエブページ６１の例示的な画面である。報告画面３６０内には、特定のインボイス（または伝票）に関係する分析データ２７０が含まれる。インボイス分析データ２７０は多数の変数によって並べ替えでき、多数の多様なフィルタ２８０を使ってフィルタリングでき、多数の多様な報告画面３６０に集計できる。例えば、インボイス詳細報告画面から、インボイス詳細報告画面で分析データを生成するために使う取引データをプロジェクト種類別に集計して、プロジェクト種類別インボイス分析データとしてプロジェクト種類別インボイスサマリー報告画面に表示できる。インボイス詳細報告画面３６０に可能なフィルタ２８０および追加の報告画面３６０は図７１に図示するものに限定されるものではなく、あらゆるカスタマ固有フィールド（ＣＳＦ）を含むように拡張できる。

図７２は、分析データ２７０を含む総合月別支出サマリー報告画面を提示するウエブページ６１の例示的な画面であり、当月および過月のプロジェクト支出の合計を一覧表示する。総合月別サマリー報告画面３６０から多数の追加のサマリー報告画面３６０にリンクできる。例えば、分析データ２７０を作成する取引データを地理別に集計して、地理別支出サマリー報告画面として表示すると、ユーザが多様な地理的地域におけるプロジェクトの支出額を判断するのに役立てることができる。

別の例として、図７３に図示するように、分析データ２７０を作成する取引データをプロジェクト種類別に集計して、プロジェクト納入種類別支出サマリー報告画面３６０とし
てウエブページ６１に表示でき、様々なプロジェクト納入種類の月別支出を一覧表示する分析データ２７０を含む。例えば、支出は固定価格の成果物、セット価格の成果物、作業時間に対する人件費と材料費（タイムアンドマテリアル）の成果物、作業時間に対する人件費と経費、作業時間に対する人件費のみ、サービス契約、またはその他のプロジェクト納入種類別に集計できる。さらに、各プロジェクト納入種類の支出取引データに関係する統計分析データ２７０を生成して、ユーザが月毎の総支出に対する各プロジェクト納入種類の支出比率を出すのに役立てることができる。ただし、同じ支出取引データを使って、他にも多数の分析／統計データを生成して、多数の他の報告画面に表示できることは理解されるべきである。

図７３に図示するウエブページの一番下に見えるように、支出取引データに関係する外部（例えば、トップレベルのデータベース）データを見るリンクを設けられる。そのため、ユーザはトップレベルの取引データにアクセスするのに違うサーバにログオンする必要はない。ただし、他の実施例では、別途ログオンの手順が必要な場合もあることは理解されるべきである。ユーザが外部データへのリンクをクリックすると、図７４に図示するタイプのサマリー報告画面３６０がユーザに提示される。

図７４は、外部データのプロジェクト納入種類別支出サマリー報告画面３６０に提示される業界分析データ２７０を含む例示的なウエブページ６１の画面である。図７４には２種類の業界分析データ２７０の例が図示されているが、ユーザが入力する要求とフィルタによって、そのうちの一方しか一度に表示されないこともある。ウエブページ６１の一番上に、自動車業界セグメントの月毎の総支出に対する各プロジェクト納入種類の支出比率を割り出す統計分析データ２７０を示す。ウエブページ６１の真中には、超大規模企業のバイヤーに関して月毎の総支出に対する各プロジェクト納入種類の支出比率を割り出す統計分析データ２７０を示す。

図７４に図示するウエブページ６１から分かるように、業界分析データとユーザの個々の会社の分析データとを比較する別の報告画面へのリンクを設けることができる。ユーザが外部データへのリンクをクリックすると、図７５に図示するタイプのサマリー報告画面３６０がユーザに提示される。図７５は比較プロジェクト納入種類別支出サマリーレポート３６０で提示される業界分析データ２７０と個々のバイヤーの分析データ２７０の比較を掲載する例示的なウエブページ６１の画面を図示する。図７５には２種類の比較分析データ２７０の例が示されているが、ユーザが入力した要求およびフィルタによっては、そのうちの一方のみしか一度に表示されないこともある。ウエブページ６１の上は、月毎の各プロジェクト納入種類の個々のバイヤーの支出を割り出す分析データ２７０を、月毎の各プロジェクト納入種類の業界平均支出と比較する。ウエブページ６１の下は、バイヤーの月毎の総支出に対する各プロジェクト納入種類の支出比率を割り出す分析データ２７０を、業界の月毎の総支出に対する各プロジェクト納入種類の支出比率と比較する。

図７６は、プロジェクト原価計算サマリー報告画面３６０に提示するある特定のプロジェクトに関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。分析データ２７０は、プロジェクトの状態、現在までのプロジェクト総コスト、購入申請書の金額（すなわち、プロジェクトに許可された金額）現在バイヤーが扱う全プロジェクトに対するこのプロジェクトの支出比率、プロジェクトの粗利、その他関連のプロジェクト原価計算分析データを含むことができる。ウエブページ６１の下は、ビジネス影響の種類、地理、ベンダー等など、種々の取引データ別に集計した多様なプロジェクト原価計算報告画面３６０へのリンクである。

図７７は、プロジェクト支出見積報告画面３６０で提示する一または複数のプロジェクトの見積将来支出に関係する分析データ２７０を掲載する例示的なウエブページ６１の画
面である。図７７には２種類の将来支出分析データ２７０を図示しているが、ユーザが入力する要求およびフィルタによっては、そのうちの一方しか一度に表示されないこともある。ウエブページ６１の一番上に、ある特定のプロジェクトの見積将来支出に関係する分析データ２７０を示しており、ウエブページの真中には、全プロジェクトの見積将来支出を示している。ウエブページ６１の一番下は、ビジネス影響の種類、地理、ベンダー等など、種々の取引データ別に集計した多様なプロジェクト支出見積報告画面３６０へのリンクである。

例として、ユーザがプロジェクトセクターおよびファミリー別のプロジェクト見積将来支出を集計するリンクをクリックすると、図７８に図示するものと類似の報告画面３６０が例示的なウエブページ６１上でユーザに提示される。図７８に図示する報告画面３６０はプロジェクトセクター／ファミリー別に集計した見積将来支出モデルであり、多様なプロジェクトセクター／ファミリー内のプロジェクトの見積将来支出に関係する分析データ２７０を掲載する。この種の報告画面３６０は、ユーザにとって事業計画に沿って組織的な投資を確実に行うのに便利であろう。

３事例のプロジェクトセクター／ファミリー別の見積将来支出を図７８に図示しているが、ユーザが入力する要求およびフィルタによっては、そのうちの１つだけしか一度に表示されないことがある。ウエブページ６１の一番上の分析データ２７０は、プロジェクトセクター／ファミリー別に集計した月毎の見積将来支出を含む。ウエブページの真中では、分析データ２７０は、月毎の総支出に対する特定のプロジェクトファミリーの支出比率の見積もりなど、ある特定のプロジェクトファミリーの見積将来支出に関係する統計データである。ウエブページの一番下の分析データ２７０は、月毎の総支出に対する特定のプロジェクトセクターの支出比率の見積もりなど、ある特定のプロジェクトセクターの見積将来支出に関係する統計データである。さらにウエブページ６１の一番下から分かるように、予測将来支出に関する外部の統計データを掲載するレポートを見るために、外部データへのリンクを設けることができる。当該外部データは、ユーザにとって、一般市場または特定市場のメンバーがその事業目的をかなえるための投資動向または計画内容を把握するのに便利であろう。

図７９は、プロジェクト遂行サマリー報告画面３６０に提示するある特定のプロジェクトのプロジェクト遂行データに関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。分析データ２７０は、プロジェクトの状態、プロジェクトフェーズ完了数、納期を過ぎたフェーズ数、成果物完了数、納期を過ぎた成果物完了数、納期どおりの成果物完了比率、その他プロジェクト遂行分析データを含むことができる。ウエブページ６１の一番下は、ビジネス影響の種類、地理、ベンダー等など、種々の取引データ別に集計した多様なプロジェクト遂行報告画面３６０へのリンクである。このように、このウエブページ６１から、取引データの種類別に集計した集計データおよびその他統計分析データを生成できる。

例として、ユーザがプロジェクト遂行分析データをプロジェクト管理所有形態別に集計するためのリンクをクリックしたら、図８０に図示するものと類似の報告画面３６０が例示的なウエブページ６１上でユーザに提示される。図８０に図示する報告画面３６０は、バイヤー所有、ベンダー所有、共同所有等など、様々な所有権のタイプで管理するプロジェクトの業務遂行サマリーであり、多様な所有権をもつプロジェクトの遂行に関係する分析データ２７０を掲載する。この種の報告画面３６０は、ユーザがプロジェクト管理所有権に応じた成功率／失敗率間の関係を理解するのに便利であろう。ウエブページ６１の一番下で分かるように、プロジェクト管理所有権に関係する場合、プロジェクト遂行に関する外部分析データを掲載するレポートを見るための外部データへのリンクを設けることができる。

別の例として、ユーザが図７９のウエブページ６１の一番下のリンクをクリックして、リスク／不履行レポートを見る場合、図８１に図示するものと同様な報告画面３６０が例示的なウエブページ６１上でユーザに提示される。図８１に図示する報告画面３６０はプロジェクトリスク／不履行例外レポートであり、納期が過ぎたまたは他の障害のある問題プロジェクトまたは不適合プロジェクトの遂行に関係する分析データ２７０を掲載する。

図８２は、計画マトリックス報告画面３６０に提示されるプロジェクト計画に関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。分析データ２７０は、例えば、当月および先行月の総プロジェクト数、および他のプロジェクト計画分析データ２７０を含むことができる。図８３は、プロジェクト計画ツール報告画面３６０に提示されるより具体的なプロジェクト計画に関係する分析データを掲載する例示的なウエブページ６１の画面である。例えば、ユーザはある特定のプロジェクトセクター／ファミリーを選択して、地理、ベンダーの階層等など、様々な影響変数（例えば、フィルタ２８０）、および様々なプロジェクト遂行報告画面３６０から選ぶと、特定の過去のプロジェクト遂行データに対応する一覧表示される影響変数のあらゆる組み合わせに関連した集計サマリー分析データ２７０を掲載する報告画面３６０を提示できる。この種の報告画面３６０は、ユーザにとって、どの事業構成（変数集合）が成功したか、またしなかったかを十分に把握するのに便利であろう。

図８４は、ベンダー階層コード支出報告画面３６０に提示されるベンダー階層の関数としての支出トレンドに関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。２事例のベンダー階層支出データが図８４に図示されているが、ユーザが入力する要求およびフィルタによっては、そのうちの一方しか一度に表示されないことがある。ウエブページ６１の上の分析データ２７０は、あるベンダー階層内の一または複数のベンダーの月毎の支出額を含む。ウエブページ６１の下の分析データ２７０は、ベンダー階層内のベンダー数、ベンダー階層内のベンダーの月毎の総支出額、およびその他集計または統計ベンダー階層支出分析データ２７０を含む。

図８５はベンダー資格審査報告画面３６０で提示されるベンダー資格審査情報に関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。分析データは、例えば、バイヤー定義のベンダー基準情報の一覧表示、各ベンダーの関連ベンダー資格審査情報、およびベンダーがバイヤー定義のベンダー参加資格条件の各々に適合するかどうかの明示を含むことができる。ウエブページ６１の下には、さらに様々なベンダー資格審査データに関する統計分析を集計および／または実行するための多様なサマリー報告画面３６０へのリンクがある。

図８６は、地理的リソース配置報告画面３６０に提示される地理の関数としての人的資源の配置に関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。分析データ２７０は、ある国、地域、または都市に配置されるリソースの比率、ある国、地域、または都市の作業時間の比率、ある国、地域、または都市で人的資源に支出した金額の比率を含むことができる。分析データ２７０はさらに、ある国、地域、または都市の総リソース数、時間、および支出金額など、様々な集計情報を含むことができる。この種の人的資源報告画面３６０は、キャパシティ管理、価格設定、共同雇用、異動等などの問題を処理するときにユーザに役立つであろう。

図８７は、ベンダー配置の人的資本リソース報告画面３６０に提示される人的資源に関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。３事例の人的資源データが図８４に図示されているが、ユーザが入力する要求およびフィルタによっては、そのうちの１つしか一度に表示されないことがある。ウエブページ６１の一番上の
分析データ２７０は、プロジェクト遂行の関数としての個々の請負人情報を含む。ウエブページ６１の真中の分析データ２７０は、ある特定のベンダーに関係する集計および統計請負人情報を含む。ウエブページ６１の一番下の分析データ２７０は、複数のベンダーに関係する集計および統計請負人情報を含む。ウエブページ６１の一番下にはさらに、様々な請負人データに関する統計分析を集計および／または実行するための様々なサマリー報告画面３６０へのリンクがある。

図８８は、ベンダースコアカード報告画面３６０に提示されるベンダーの業績に関係する分析データ２７０を掲載する例示的なウエブページ６１の画面である。この報告画面３６０は、画面３６０を特定の種類の取引データに絞るのに利用できるいくつかのフィルタ２８０を含む。前述の各報告画面３６０には図示されていないが、報告画面３６０の一部もしくは全部に様々なフィルタが利用できるであろうことは理解されるべきである。分析データ２７０は、様々なベンダーの入札、プロジェクト遂行、および支出活動に関係する集計および統計情報を含むことができる。ウエブページ６１の一番下にはさらに、様々なベンダー業績データに関する統計分析を集計および／または実行するための様々なサマリー報告画面３６０へのリンクがある。前述の報告画面３６０およびこれに提示する分析データ２７０の種類は、報告モジュールがローバストであることの単なる例を提供することを意味する。当業者には、本発明内で報告画面の数および変型が可能であることは容易に明らかであろう。以下の図面のいつくかでは、本発明の様々な特徴および実施例の説明を不必要に複雑にしないように、プロセスフロー決定ブロックから延びる否定の分岐を省略している。当業者には、本発明の原則を逸脱することなく、設計上の制約条件によってそうならざるを得ない否定の分岐を補充できることは認識されるであろう。

図８９は、システム３０に実装できる視覚的なプロジェクト作業環境のダイナミクス８９００の例を図示する。ダイナミクス８９００の最も内側のレイヤ１は、プロジェクトに対応するプロジェクト作業の取引データの基本的な有形の活動要素を示し、例えば、商品引渡し、サービス単位引渡し、固定価格成果物、人的資源割り当て（人件費およびコストを含む）、その他プロジェクト経費、およびプロジェクトフェーズ区分によって表される。要素８９０５〜８９３０は、実際に履行したプロジェクト作業を表す。要素８９０５〜８９３０で表される活動は必ずしも個人または集団の請求対象活動を表すものではないが、多くの場合はそうである。

要素８９０５〜８９３０は有形のプロジェクト作業活動の個別の視覚化および運営管理を容易にする。取引データは例えば図４０Ａおよび４１に図示する特殊なデータオブジェクトの形をとる。特殊なデータオブジェクトとは、例えば複数の可変データタイプ、コード、データベースクエリ、および階層的なリレーショナルデータセットを収容できる複雑なデータコンテナである。対する単純データオブジェクトとは、例えば、単一のテキストフィールド、コストフィールド、またはデータフィールドのオブジェクトである。これら特殊データオブジェクトは主に取引データを取得、格納、および処理するために使用する。

レイヤ１の中には、要素８９３５（ａ）〜（ｄ）で表されるプロジェクト作業範囲記述書（ＳＯＷ）の構成要素も示される。典型的な実施例では、成果物およびＳＯＷとは客観的なプロジェクトのアウトプットの具体的な記述をいい、同義である。ただし、ある実施例では、例えば、下請業者が購入申請書の成果物を作り出さない場合など、当てはまらない場合もある。当業者には、まさに４つのプロジェクトＳＯＷの構成要素が必要なわけではなく、その数はプロジェクトのマイルストーン構成の設計制約条件で決まることは認識されるであろう。ＳＯＷの構成要素８９３５（ａ）〜（ｄ）は客観的なプロジェクトのアウトプット（例えば、プロジェクトのマイルストーンまたはＳＯＷ／成果物）の具体的な記述を表す。プロジェクトのアウトプットはＳＯＷのアウトプットとして表すことがあり
、例えば、労働資源またはロジスティクスに関係する細目を規定しないのが一般的である。このため、１つのＳＯＷを一または複数の具体的なプロジェクト作業の要素にマッピングできるであろう。プロジェクト作業活動とは典型的にはＳＯＷのサブ構成要素であり、サブ構成要素の数はわずか１から極めて大きな数までの範囲になる可能性がある。レイヤ１の構成要素８９４０は従来のプロジェクト管理（ＰＭ）のＳＯＷ従属関係を表す。ＳＯＷのアウトプットは関係性でまとめる。サブ構成要素（すなわち、プロジェクト作業活動）は、まとまりのある作業環境が成立するように統合される。

レイヤ２は構成要素８９４５〜８９６０として表されるダイナミクス８９００の商取引上の面を示し、発注から支払いのサイクルともいう。ＲＦｘ入札テンプレート／項目システム８９４５は、レイヤ１のサポート構造として機能する。前述したように、項目はテンプレートに入り、テンプレートを使ってＲＦｘ入札を作成し、ＲＦｘ入札は供給者に一斉配信／投稿される。次に供給者はＲＦｘ応札書を処理する。バイヤーはＲＦｘ応札書を分析して、特定のＲＦｘ応札書エレメントに関連した落札書を発行する。これらＲＦｘ応札書エレメントは購入申請書／発注書環境に体系的に統合する。作業が完了すると、供給者がこれら特定の発注書（ＰＯ）記録にアクセスして、プロジェクト活動確認伝票を作成し、その時点でバイヤーは作業をレビューして品質評価し、最終的にバイヤーの承認となる。最後に、承認された伝票データを抽出して、インボイス作成データを生成するために使うことができ、供給者への支払いとなる。

特殊取引データオブジェクト（例えば、表２６のＲＦｘ入札データオブジェクト）は入札プロセス以外でも使用できる。例えば、ある場合には、バイヤーに時間がない、または競争入札プロセスを開始したいと思うことがある。このような場合、バイヤーは、例えば、プロセス５００の購入申請書の段階５６０から始めることができる。

レイヤ３はプロジェクト作業の商取引上の面に直接影響を受けるダイナミクス８９００の残りの部分を示す。図示される運営管理ポートフォリオグループは、予算編成／キャッシュフロー８９６５、契約８９７０、資産８９７５、および内部ビジネスイベント８９８０を含むが、例えば、製造または内部人的資源の機能エレメントなど数多くの他のものも考えられるだろう。レイヤ３のポートフォリオは、例えば、事業体がどの業界にいるか、またはその事業をどこで行うかによって、大幅に変わりうる。例示のために、典型的にプロジェクト作業を行うあらゆるバイヤー企業に影響を与えるポートフォリオを選択した。

多くの場合、プロジェクトに影響を与えるビジネスイベントは数多くあるが、実際にはプロジェクトの範囲内に属していない。例えば、あるプロジェクトがある特定の事業場所でのコンピュータ機器の設置およびソフトウェアのインストールを伴うことがあろう。この活動によって直接影響されるのにもかかわらず、プロジェクト作業自体の一部とはなっていないのが、事業体のヘルプデスク部であろう。このように、ヘルプデスク要員訓練と名づけた別のビジネスイベントは関係するビジネスイベントである。レイヤ３は事業体内でプロジェクト作業の舞台裏の面を表す。

次の、視覚的なダイナミクスの中で最も外側の環境がレイヤ４であり、構成要素８９８５〜８９９９を含む。ユーザ８９８５、通信８９９０、連携８９９５、決定サポート８９９９は、ダイナミクス８９００の中の人、またはソフト面を表す。

プロジェクト作業は複雑な活動であることが多い。プロジェクト作業活動は、例えば図８に図示する商業環境（すなわち、発注から支払いまでのデータ処理システム）に統合しなければならず、その環境は多くの場合、例えば、予算編成、キャッシュフロー、契約管理、資産／資本管理、およびその他多数の関連ビジネス活動／イベントなど、より高レベルの経営活動にも直接影響する。これら変数のすべてを網羅するには、ユーザと通信をセ
キュアかつ管理された連携環境で接続し合い、組織的にデータを処理し、所要のアウトプットを生み出し、総体的なビジネス活動をさらに活性化する堅実な決定サポートを提供できるようにする必要がある。そのため、ダイナミクス８９００は典型的な実装では極めて複雑となりうる。

図８９は、図示するダイナミックエレメント間に存在する入り組んだ網を表示する。例えば、商品引渡しを怠るようなことがあれば、そのＳＯＷは遅れるまたは取り消されるかもしれない。この不履行のために発注書を修正する必要がでてくるかもしれず、さらに予算およびキャッシュフローのポジションが変わってくるかもしれない。固定資産台帳を変更する可能性もあり、そうなればおそらくサービスおよび／または保守契約に影響を与えることになり、その結果物理的なプラント構成の改造に迫られるかもしれず、最終的には影響を受ける１０件余りの他の関連プロジェクトを見直しする必要がでてくることもあろう。

図９０は、ダイナミクス８９００を実装するのに使用できるビジネスデータ処理環境の高レベルの観点を示すブロック図である。データ処理環境９０００は４つの高レベルのコンポーネントを含み、コア情報データコンポーネント９００１、ワークフローエンティティコンポーネント９０２５、データ処理コンポーネント９０５０、データベースコンポーネント１５０として細分される。データベースコンポーネント１５０は、処理されたデータを格納し検索する場所である。コア情報データコンポーネント９００１は、データベースコンポーネント１５０に物理的に存在する構造および属性をもつ。ただし、管理用データと取引データとの違いを指摘するために、別々に表示している。

高レベルの観点から、ビジネスデータ処理環境９０００は、ユーザ、情報、処理コンテナ／フォーム、ワークフローパス、およびデータ格納の各コンポーネントから構成されると説明できる。コア情報データコンポーネント９００１は、企業のインフラストラクチャ（例えば、提供する産業、製品、またはサービス等）を定義するだけでなく、例えば図５に図示するようなものなど、商業マネジメントソリューションの範囲内での企業活動の境界（すなわち、プロジェクト作業の中で企業がどのようにソリューションと影響し合うか）を定義する情報を表す。このためこの情報は、取引データとは対照的に、管理用データ（すなわち、ある特定のプロジェクトに限定されるものではなく、ある特定のプロジェクトとは独立して企業およびそのプロセスの記述的なデータ）と考えられる。コア情報データコンポーネント９００１は環境９０００の境界も定義する。

コア情報データコンポーネント９００１は、以下の８つの例示的なシステムを含む。

１）ユーザ役割システム９００３で、これは要員／ユーザのアイデンティティと属性を格納および管理するアプリケーション・モジュールである。このモジュールの構成の側面は、基本的なログイン許可からワークフローデータ処理動作まで環境９０００内におけるユーザ対話性を容易にする。

２）ジオファシリティシステム９００５で、これはバイヤー・エンティティの地理的範囲と構成要素、および実際のプラント施設がその構成要素とどのように関係するかを定義するアプリケーション・モジュールである。構成は地理的範囲を例えば国内または国外のいずれかに定義し、あるいはバイヤー・エンティティが業務処理にカスタム地域分割スキーマを利用するか、郵便番号コードを利用するかを定義する。基本的な地理的構成要素に加えて、実際のプラントに適用する属性を定義することによって、実際のプラントサイトをジオファシリティシステム９００５に統合することもできるであろう。例えば、施設の活動、安全規則、施設利用の制約条件、出入りに関する属性情報もジオファシリティシステム９００５に維持できるであろう。

３）品質保証システム９００７で、これは業務プロセスおよび業務機能がバイヤー・エンティティにとってクリティカルと定義できるアプリケーション・モジュールである。加えて、業務プロセスおよび業務機能に適用される対応の測定属性を定義してもよい。

４）人的資本システム９００９で、これはバイヤー・エンティティの立場を明確にし、非従業員労働者に関係するデータを管理するアプリケーション・モジュールである。このモジュール内で、バイヤー・エンティティは、労働者の種類、労働者の採用条件、労働者の合意書、労働者の在職期間、労働者の入社要件、労働者の退社要件、労働者の職種、労働者の経費の種類、労働者の配置規則、労働者監査規則、および労働者の権利放棄のうちの一または複数の属性を定義し、構成できる。

５）財務管理システム９０１１で、これはバイヤー・エンティティが支出管理および財務データの処理活動の様々な面を管理できる財務アプリケーション・モジュールである。代表的な情報コンポーネントは、出金の種類の名称と属性定義、通貨の種類の名称と属性定義、支払条件の名称と属性定義、割引条件の名称と属性定義、割戻し条件の名称と属性定義、見越項目算定の名称と属性定義、税区分の名称と属性定義、免税の名称と属性定義、金融取引承認スキーマの名称と属性定義を含みうるが、必ずしもこれだけに限定されない。

６）調達管理システム９０１３で、これはバイヤー・エンティティが調達および商取引データ処理活動の様々な面を管理できる調達アプリケーション・モジュールである。例えば、図４０Ｃにあるように、このモジュール内には、原材料システム、ＲＦｘ入札システム、購入申請／発注システム、および伝票（すなわち、作業確認処理）システムのうちの一または複数の情報および構成が内蔵される。

７）供給者管理システム９０１５で、これはバイヤー・エンティティがその商業環境に関わる供給者管理の様々な面を管理できる供給者アプリケーション・モジュールである。特定の賠償責任保護から戦略的な供給者支出管理にいたるまで、供給者管理の様々なビジネス面を、そのために必要なビジネス情報が入手できれば、供給者管理システム９０１５の構成要素内で達成できる。代表的な構成要素は、供給者の種類の名称と属性定義、供給者の業務上の参加資格条件の名称と属性定義、供給者保険の参加資格条件の名称と属性定義、供給者階層の名称と属性定義、供給者合意書の名称と属性定義、供給者の業務監査の名称と属性定義、供給者の業務資格審査辞退の名称と属性定義、そして当然、バイヤーが利用する原材料に関係する供給者の提供能力を含みうるが、必ずしもこれだけに限定されない。

８）プロジェクト運営システム９０１７は、バイヤー・エンティティがプロジェクト運営の面を管理できるアプリケーション・モジュールである。

ワークフローエンティティコンポーネント９０２５は、環境９０００内で取引情報を処理するために利用する情報コンテナ（例えば、フォームまたはウエブページ）を表す。ワークフローエンティティとは本質的に、情報を表示または取得するために使うのに利用できるデータ環境（例えば、コア情報データコンポーネント９００１）の表現である。

データ処理コンポーネント９０５０は環境９０００の一次的なワークフローコンポーネントを表す一方、コンポーネント９００１および９０２５は実際には、ビジネスデータ処理環境９０００で使用するデータおよびデータ処理フォームを定義する。データプロセスコンポーネント９０５０は、データ処理フォームをそれぞれのデータ処理パスに沿って移動するように構成する場所である。

コア情報データコンポーネント９００１およびワークフローエンティティコンポーネント９０２５の場合と同様、データ処理コンポーネント９０５０は予め構成したワークフローパス９０５４の基本セットを含み、例えば、指定の条件または状態コードを前提として、ワークフローパスに沿って所定のユーザ役割に移動するワークフローフォームを移植するために使う。様々に構成されるワークフロー処理９０５８は、カスタマイズしたバイヤー・エンティティ計画のワークフロープロセスを表す。構成されたワークフロー処理９０５８は、特に、ユーザ役割システム９００３のバイヤーユーザ役職、バイヤーワークフローエンティティコンポーネント９０２５、およびバイヤービジネスルール（例えば、データ値および条件属性）を使って、ビジネスニーズを満たす精密なワークフローデータ処理を構成する。

データベースコンポーネント１５０は、データ処理コンポーネント９０５０の動作中に取得した取引データを格納、維持する環境９０００のデータベースの格納面である。取引データ取得および格納を強調するように、データベースコンポーネント１５０は環境９０００フローの端に示す。ただし、データベースコンポーネント１５０はコンポーネント９００１、９０２５、９０５０、および１５０の４つすべてを通して常時作動状態にある。

図９１は上記５の変形版で、本発明の原理に従うプロジェクトの計画／範囲変更プロセスの高レベルな概観を提供する。上記図５で示したように、プロセス５００は入札前活動５０５、入札活動５１５、入札後活動５６０に細分できる。図５では、入札前活動５０５はステップ５１０を含み、入札活動５１５はステップ５２０〜５５５を含み、入札後活動５６０はステップ５６５から５８０を含む。対するプロセス９１００は、入札前活動５０５、調達活動９１２５、調達後活動９１５０に細分する。図９１では、入札前活動５０５はステップ５２０の前に発生し、調達活動９１２５はステップ５６０の前に発生し、調達後活動９１５０はステップ５６０〜５８０の間に発生する。

入札前活動５０５は、ユーザ役割・ワークフロー構成９１１０、ＲＦｘ入札システム構成９１１５、プロジェクト運営構成９１２０を含む。調達活動９１２５はプロジェクト作業取引データセットアップ９１２７を含み、これはＳＯＷとプロジェクト活動のマッピング９１３０、ＳＯＷ従属構成９１３５、ＳＯＷとプロジェクト運営の対応構成９１４０を含む。調達後活動９１５０は伝票処理９１５５、ＰＣＩＰ／Ｓモデル化９１６０、ＰＣＩＰ／Ｓ連携９１６５、ＰＣＩＰ／Ｓ記録修正９１７０を含む。伝票処理９１５５はステップ５６０〜５７０の間に発生する。ＰＣＩＰ／Ｓモデル化９１６０、ＰＣＩＰ／Ｓ連携９１６５、ＰＣＩＰ／Ｓ記録修正９１７０はステップ５７５と同時にまたはステップ５７５の前に発生する。

図９２は図９１の変形版で、競争入札プロセスを利用しない。当業者には、本発明の様々な実施例が図９２に示すように競争入札を含む環境に制限されないことは認識されるであろう。図９２は図９１に示す調達／入札活動をなくす修正を含む。図９２に図示するプロセス９２００で、プロジェクト前活動９２１０はユーザ役割・ワークフロー構成９１１０とプロジェクト運営構成９１２０を含む。プロジェクトセットアップ活動９２１５はプロジェクト作業取引データセットアップ９２２７を含む。プロジェクト作業取引データセットアップ９２２７は、ＳＯＷとプロジェクト活動のマッピング９１３０、ＳＯＷ従属構成９１３５、ＳＯＷとプロジェクト運営の対応構成９１４０を含む。プロジェクト追跡活動９２２０は、伝票処理９１５５、ＰＣＩＰ／Ｓモデル化９１６０、ＰＣＩＰ／Ｓ連携９１６５、ＰＣＩＰ／Ｓ記録修正９１７０を含む。図５および９１と同様に、プロジェクト前活動９１２０はステップ９２０５で発生し、プロジェクトセットアップ活動９２１５はステップ５５０で発生し、プロジェクト追跡活動９２２０はステップ５６０〜５６５の間に発生する。

購入申請書／発注書データに移行してから、さらに伝票取引データに移行する入札項目として特別なデータオブジェクトを利用することは、図９１に図示するシーケンスに限られるわけではない。特別なデータオブジェクトを発注プロセスを全く省いた方法で利用するのを妨げるような技術的な制約は全くない。このような場合、同じ種類の記録を単にプロジェクト活動データに使用すればよいだろう。さらに当該データは、システム内の調達活動の結果取得した場合とまさに同じように、本発明の様々な実施例と合わせて使用できるであろう。さらに、同様に、例えば図９のようにユーザ役職の指定とユーザ役職への要員の割り当ては入札プロセスに限られるものではなく、代わりに、例えば見込みベンダーの資格審査とアップロード、または請負人合意データの取得など、他のワークフロープロセスに適用できよう。

図９３は、本発明の原理に従うプロジェクトの計画／範囲変更（ＰＣＩＰ／Ｓ）プロセスフローを図示する。図９３では、プロセスフロー９３００は調達前データ構成セグメントから始まり、ユーザ役割構成９３０５、プロジェクト管理モジュール構成９３１０、ＲＦｘ入札システム構成９３１５を含む。調達前データ構成活動９３０５〜９３１５の後、プロセス９３００の次の大きなセグメントは、ステップ９３２０〜９３３５として示すプロジェクト作業取引データの取得と格納を含む。

ステップ９３２０で、バイヤー・エンティティはＲＦｘ入札を作成して一斉配信する。ステップ９３２５で、供給者はＲＦｘ入札に応じる。ステップ９３３０で、バイヤーはＲＦｘ応札書を評価して、応札者を選定する。ステップ９３３５で、バイヤーは購入申請書／発注書を作成する。３番目の主なプロセスセグメントのＳＯＷ記録構成（ステップ９３４０〜９２５０）は、従来のプロジェクトＳＯＷ従属構成を行うとともに、プロジェクト管理モジュール構成９３１０でのデータ構成セットアップ９３１０とプロジェクト作業取引データの取得および格納を行う取引データセットアップセグメントと結合するプロセスセグメントである。

ＰＣＩＰ／Ｓ影響度モデルコンポーネントと呼ばれる４番目の主なプロセスセグメントは、ステップ９３５３〜９３６０で表される。ステップ９３５３〜９３６０はプロジェクト作業開始９３５３と同時に発生し、作業確認伝票の提出を含む。マイルストーン可変構成および伝票マイルストーンデータ管理から、様々な実施例はバイヤー・エンティティにとってマイルストーンに適合していない、そのためリスク活動になった（もしくはやがてなるであろう）具体的なプロジェクト作業活動またはＳＯＷ記録を特定できる。

問題特定９３５６は、システムの伝票作成の側面によって容易になる。この４番目のプロセスセグメントの中で最後の活動がＰＣＩＰ／Ｓ従属影響度レポート９３６０であり、これは以前に構成した情報を利用して、問題のある活動に影響を受ける可能性のある関連ビジネス記録セットを詳述するレポートをバイヤー・エンティティに表示する。この画面はある問題のある活動に基づいて危うくなっていることに関する情報をバイヤー・エンティティに与える。ステップ９３６０の間、バイヤー・エンティティの統括ユーザは重大なマイルストーン可変データ値を変更でき、情報の変更に基づいてシステムに影響出力レポートを生成させることができる。

５番目のプロセスセグメントのリスク通信セッションは、ステップ９３６３〜９３７０で表される。バイヤー・エンティティの統括ユーザは、問題のある活動が一または複数のプロジェクトの計画もしくは範囲の変更を招きかねない問題の存在を他の企業ユーザに警告を出すほどまで広範なまたは甚大な影響をもつかどうかを判断できる。例えば、ユーザはリスク管理通信セッション９３６３を開始できるであろう。具体的な問題のあるプロジェクト作業要素を参照してセッション９３６３が作成されたら、バイヤー・エンティティ
の統括ユーザはステップ９３６５で、影響を受ける可能性のあるどの企業ユーザに連絡するべきかを選択して、具体的な情報のニーズに合わせてユーザに対しそれぞれ別の通信パッケージを構成または操作できる。個々の通信パッケージが構成されたら、次にバイヤー・エンティティのユーザはステップ９３６８でその通信パッケージを関係するビジネス記録の統括オーナーである個人に一斉配信できる。

供給者応札２２０と同様に、リスク通信パッケージを受け取るバイヤー・エンティティのユーザは、ステップ９３７０で、備え付けのユーザインターフェースを介してそれぞれの応答を処理できる。ユーザは予想される影響に関するフィードバックをそれぞれの制御可能なビジネス記録／イベントに提供できる。受取人のリスク通信パッケージが全て完了すると、このプロセスセグメントは終了する。

手持ちのリスク通信パッケージのすべてを完了すると、ここで発行側のバイヤー・エンティティのユーザは６番目の主たるプロセスセグメント、ＰＣＩＰ／Ｓ承諾パッケージセッションに進むことができ、これはステップ９３７３〜９３８５で表される。このプロセス内で、バイヤー・エンティティの統括ユーザは前の通信セッション中（すなわち、ステップ９３６３〜９３７０）に収集した情報を集計して評価する。統括ユーザは最終的には問題のあるプロジェクト作業活動の可変項目の行方に関して最終処置をし、記録の変更を保存する。これら変更の際、ユーザはステップ９３７３で、新規可変データを前提に新規従属影響度レポートを生成できるので、これが関係するビジネス記録と記録の可変データ変更の全体像を提供することになる。

新規影響度モデルを計算した後、バイヤー・エンティティのユーザはステップ９３７５に進んで、ＰＣＩＰ／Ｓ承諾パッケージを所要の供給者ユーザに一斉配信できる。ＰＣＩＰ／Ｓ承諾パッケージセッションは、既存かつ公開されているリスク管理通信セッション（すなわち、ステップ９３６３〜９３７０）に関して作成し、それによって影響を受けるシステムの発注書を参照として掲載した一斉配信する対象供給者リストがすでに確定する。ステップ９２７２〜９３８５のプロセスは前の通信プロセス（すなわち、ステップ９３６３〜９３７０）と似ており、そのためそうしたいなら、個々の構成と表記法を各個々の受取人に関係付けることができる。

ステップ９３６３〜９３７０のセッションと同様、ＰＣＩＰ／Ｓ受諾パッケージを受け取る個々のユーザは、ステップ９３８０および９３８５でパッケージを処理して、発行したユーザに戻すことができる。典型的には、応答は修正された可変データを受け入れるか、または可変データ要素を実際に定義することに限られる。発信元の問題のあるプロジェクト作業活動記録に関し行われた処置を考慮してシステムが反映させる必要のある情報値を取得し、格納する。問題源の特定と連携は単一のプラットフォーム（例えば、システム３０）で引き受けながら、変数情報の修正は統括関係者が行い、活動は企業全体を見渡しながら追跡する。

記入済みのＰＣＩＰ／Ｓ承諾パッケージを受け取ると、７番目の大きなプロセスセグメントはＰＣＩＰ／Ｓ記録修正運営セグメント（すなわち、９３９０〜９３９５）である。統括ユーザは、例えばユーザインターフェースから備え付けのコントロールを起動して、可変データ修正の更新に承認を与える。ステップ９３９５が完了したら、影響を受けるバイヤー・エンティティのユーザに対してシステム内に予定された修正が行われたことを体系的に通知する。
調達前データ構成
典型的には、実際のプロジェクト作業取引データを取得する前に、様々な高レベルの構成およびデータ管理活動が起こる。これら調達前構成およびデータ管理活動は、将来のプロジェクト作業の取引データを接続する有形の情報スレッドを提供する。これら情報スレ
ッドは、他にも多くのものが考えられるが、典型的には、プロジェクトグループ／マスター、予算グループ／マスター、資産グループ／マスター、契約マスター、ビジネスイベント／マスターを含む。図９４Ａ〜１０１は図９３のステップ９３１０をより詳しく図示しており、このステップの間にバイヤー・エンティティは管理プロジェクトコア情報データコンポーネント９００１を構成する。

図９４Ａ〜Ｂは主に、プロジェクトグループとプロジェクトマスター記録の両方の作成および格納のプロセスフローに関係する。プロジェクトグループとは、例えば、技術分野、事業単位、または産業などのなにか所定の基準に従ってグループにまとめた一または複数のプロジェクトの集合体である。プロジェクトマスターはある特定のプロジェクトに対応付ける記録である。プロジェクトマスターとプロジェクトグループ記録は典型的にはプロジェクト運営システム９０１７内に存在する。プロセスフローは最終的に、情報を取得し、例えば表１１３〜１１４Ａなどのデータベース表に格納することになる。図９４Ａ〜Ｂに図示するプロジェクトグループ・プロジェクトマスタースキーマは、情報全体とプロジェクトポートフォリオ管理の基本的なサポート構造を表す。プロジェクトポートフォリオ管理は、プロジェクトまたはプロジェクトグループのデフォルトの所有権を、例えば、いずれかの適切な事業単位、原価中心点、または要員に指定することによって容易にできる。プロジェクトマスター記録同士の間でプロジェクト階層関係を確立でき、予想プロジェクト管理所有権を指定できる。プロジェクトと識別されるビジネス活動との関係を反映させるために、プロジェクト影響コードを指定してもよい（例えば、表１０３を参照）。２層のプロジェクト構造を図９４Ａ〜Ｂに図示しているが、本発明の原理を逸脱することなく、２より多くの層をもつ層状構造を作成することもできよう。

ここで図９４Ａを参照すると、プロジェクトグループ作成プロセスフロー９４００はステップ９４０３から始まる。ステップ９４０３で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９４０５で、ユーザは新規プロジェクトグループの作成に移動する。ステップ９４０８で、システムはユーザに入力ワークフローフォームを提示する。ステップ９４１０で、ユーザはプロジェクトグループの名前を入力する。ステップ９４１３で、ユーザはプロジェクトグループの明細を記入する。ステップ９４１７で、ユーザはプロジェクトグループのオーナー／バイヤーの許可要員を指定する。ステップ９４２０で、ユーザはオプションでデフォルトの事業単位を指定する。ステップ９４２３で、ユーザはオプションでデフォルトの原価中心点を指定する。ステップ９４２６で、ユーザはそれまでに行った入力を保存する。ステップ９４３０で、ユーザの設定をデータベースに格納する。

ここで図９４Ｂを参照すると、プロジェクトマスター作成プロセスフロー９４５０はステップ９４５３から始まる。ステップ９４５３で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９４５５で、ユーザは新規プロジェクトマスターの作成に移動する。ステップ９４５８で、システムはユーザに入力ワークフローフォームを提示する。ステップ９４６０で、ユーザはプロジェクトマスターの名前を入力する。ステップ９４６２で、ユーザはプロジェクトマスター内部コードを記入する。ステップ９４６５で、ユーザはプロジェクトのサマリー明細を記入する。ステップ９４６８で、ユーザはオプションで、例えば表１０３にあるようにプロジェクトに責任を負うプロジェクト管理者を定義するデフォルトのプロジェクトマスター（ＰＭ）所有権コードを指定する。ステップ９４７０で、ユーザはプロジェクト影響コード（例えば、表１０３を参照）を指定する。ステップ９４７３で、ユーザはプロジェクトグループ所属（すなわち、プロジェクトがメンバーとなるプロジェクトグループ）を指定する。ステップ９４７５で、ユーザはプロジェクトグループ内のプロジェクト階層所属を指定する。ステップ９４７７で、ユーザはそれまでに行った入力を保存する。ステップ９４８０で、ユーザの設定をデータベースに格納する。

図９５Ａ〜Ｂは、図９４Ａ〜Ｂでプロジェクトグループ／マスターのセットアップについて上記述べたのと同様のパターンに従う。ただし、図９５Ａ〜Ｂに示す特定のプロセスフローは、予算グループ／マスター記録の作成と格納を扱う。図９５Ａ〜Ｂに述べるデータ格納は、例えば表１１８および１１９などのデータベーステーブルで行う。予算データはコア情報データコンポーネント９００１の財務管理システム９０１１内の管理用データである。図９５Ａ〜Ｂには２層の予算構造が描かれているが、本発明の原理を逸脱することなく２層より多い層構造を作成することもできるであろう。

プロジェクトグループと同様に、予算グループは一または複数の予算の集合体である。当業者には認識されるように、予算は、例えば、部門、事業単位、および原価中心点別の階層状など、事業組織に従い分類されるのが通例である。ただし、予算グループおよび予算マスターの構築を含めた予算編成に対して本発明の原理を使用して、企業のニーズに応じて数多くの異なる方法で企業の予算編成機能を構築してもよい。予算マスターと予算グループの記録は典型的には財務管理システム９０１１内に存在する。

ここで図９５Ａを参照すると、予算グループ作成プロセスフロー９５００がステップ９５０２から始まる。ステップ９５０２で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９５０６で、ユーザは新規予算グループの作成に移動する。ステップ９５１０で、システムはユーザに入力ワークフローフォームを提示する。ステップ９５１４で、ユーザは予算グループの名前を入力する。ステップ９５１８で、ユーザは予算グループの明細を記入する。ステップ９５２２で、ユーザは予算グループのオーナー／バイヤーの許可要員を指定する。ステップ９５２６で、ユーザはオプションでデフォルトの事業単位を指定する。ステップ９５３０で、ユーザはオプションでデフォルトの原価中心点を指定する。ステップ９５３４で、ユーザは予算グループの金額を指定する。ステップ９５３８で、ユーザは予算を指定する。ステップ９５４２で、ユーザはそれまでに行ったユーザ入力を保存する。ステップ９５４６で、設定をデータベースに格納する。

ここで図９５Ｂを参照すると、予算マスター作成プロセスフロー９５５０はステップ９５５２から始まる。ステップ９５５２で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９５５６で、ユーザは新規予算マスターの作成に移動する。ステップ９５６０で、システムはユーザに入力ワークフローフォームを提示する。ステップ９５６４で、ユーザは予算マスターの名前を入力する。ステップ９５６８で、ユーザは予算マスターのサマリー明細を記入する。ステップ９５７２で、ユーザは予算グループ所属（すなわち、予算が所属する予算グループ）を選択する。ステップ９５７６で、ユーザはオプションでデフォルトの事業単位を指定する。ステップ９５８０で、ユーザは予算を指定する。ステップ９５８４で、ユーザは予算の金額を指定する。ステップ９５８８で、ユーザは予算マスターのオーナー／バイヤー要員を指定する。ステップ９５９２で、ユーザはそれまでに行った入力を保存する。ステップ９５９６で、設定をデータベースに格納する。

図９６Ａ〜Ｂは、上記図９４Ａ〜Ｂおよび９５Ａ〜Ｂでプロジェクトマスター／グループと予算マスター／グループのセットアップについて上記述べたのと同様なパターンに従う。ただし、図９６Ａ〜Ｂのプロセスフローは資産グループ／マスター記録の作成と格納に関係する。図９６Ａ〜Ｂはステップ９３１０に関係して大まかに述べた資産マスター／グループ記録の作成を図示する。図９６Ａ〜Ｂに描かれるデータ格納は、例えば表１２５〜１２６などのデータベーステーブルで行う。図９６Ａ〜Ｂに描くプロセスフローで作成される資産データは、コア情報データコンポーネント９００１の財務管理システム９０１１内の管理用データである。図９６Ａ〜Ｂに描かれる資産グループ／マスター記録の作成
は、例えば、企業内の様々な事業組織ごとの資産の減価償却など、様々な会計機能を容易にするのに役立てることができる。図９６Ａ〜Ｂには２層の資産構造が描かれているが、本発明の原理を逸脱することなく２層より多い層構造を作成することもできるであろう。

ここで図９６Ａを参照すると、資産グループ作成プロセスフロー９６００はステップ９６０２から始まる。ステップ９６０２で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９６０６で、ユーザは新規資産グループの作成に移動する。ステップ９６１０で、システムはユーザに入力ワークフローフォームを提示する。ステップ９６１４で、ユーザは資産グループの名前を入力する。ステップ９６１８で、ユーザは資産グループの明細を記入する。ステップ９６２２で、ユーザはプロジェクトグループのオーナー／バイヤーの許可要員を指定する。ステップ９６２６で、ユーザはオプションでデフォルトの事業単位を指定する。ステップ９６３０で、ユーザはオプションでデフォルトの原価中心点を指定する。ステップ９６３４で、ユーザはそれまでに行った入力を保存する。ステップ９６３８で、設定をデータベースに格納する。

ここで、図９６Ｂを参照すると、資産マスター作成プロセスフロー９６５０はステップ９６５２から始まる。ステップ９６５２で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９６５６で、ユーザは新規資産マスターの作成に移動する。ステップ９６６０で、システムはユーザに入力ワークフローフォームを提示する。ステップ９６６４で、ユーザは資産マスターの名前を入力する。ステップ９６６８で、ユーザは資産の明細を記入する。ステップ９６７２で、ユーザは資産グループ所属を選択する。ステップ９６７６で、ユーザは資産マスターのオーナー／バイヤー要員を指定する。ステップ９６８０で、ユーザはオプションでデフォルトの事業単位を指定する。ステップ９６８４で、ユーザはオプションでデフォルトの原価中心点を指定する。ステップ９６８８で、ユーザはオプションで資産金額を指定する。ステップ９６９２で、ユーザはオプションで資産取得日を指定する。ステップ９６９６で、ユーザはそれまでに行った入力を保存する。ステップ９６９９で、設定をデータベースに格納する。

図９４Ａ〜９６Ｂに関してこれまでに述べた例示的なプロセスで、これらが当然連続的な手順であると思われるかもしれない。しかし、当業者には、実際には、これらが述べた順序で行う必要のない独立したアプリケーションプロセスであることが認識されるであろう。

図９７は、契約情報をプロジェクトに、また最終的にはプロジェクト作業の取引データに統合するために、特定の契約情報要素を捕捉するための契約マスター記録の作成と格納のプロセスフローである。図９７に記述するプロセスフローを使って、企業または企業の代理がプロジェクト作業を行っている間属性を確実に一致させるために、企業が利用する契約の様々な属性を指定できる。契約マスター記録は、例えば表１２３などのデータベーステーブルに格納する。当業者には、契約情報は典型的には、電子的なテキスト文書、紙面、またはその両方に散文（文章）形式で記載されることは理解されるであろう。その場合、散文（文章）文書が従来のアプリケーション処理要素を表さない限り、典型的には契約情報にデータ処理能力または相互運用性は適用できない。図９７に具体的には図示していないが、当業者には、契約記録をプロジェクト、資産、および予算に関して上記述べたものと同様に階層構造にできるであろうことは認識されるであろう。契約記録は典型的には供給者管理システム９０１５内に存在する。

もう一度図９７を参照すると、契約記録作成プロセスフロー９７００はステップ９７０３から始まる。ステップ９７０３で、バイヤーの許可ユーザは、例えばホームページのナ
ビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９７０６で、ユーザは新規契約マスターの作成に移動する。ステップ９７０９で、システムはユーザに入力ワークフローフォームを提示する。ステップ９７１２で、ユーザは契約形態を指定する。ステップ９７１５で、ユーザは契約参照を記入する。ステップ９７１８で、ユーザは契約開始日および終了日を指定する。ステップ９７２１で、ユーザはオプションで最高契約支出額を指定する。システム９７２４で、ユーザはオプションでデフォルトの事業単位を指定する。ステップ９７２７で、ユーザはオプションでデフォルトの原価中心点を指定する。ステップ９７３０で、ユーザは契約した活動の範囲を指定する。ステップ９７３３で、ユーザはオプションで契約上の免責事項を指定する。ステップ９７３６で、ユーザは供給者を指定する。ステップ９７３９で、ユーザはオプションで顧客を指定する。ステップ９７４２で、ユーザは契約オーナーを指定する。ステップ９７４５で、ユーザはこれまで行った入力を保存する。ステップ９７４８で、設定をデータベースに格納する。

図９８は、ビジネスイベントマスター記録の作成および格納に関係するプロセスフローを表す。ビジネスイベントとは、プロジェクト作業に直接関係ないが、バイヤー・エンティティが引き受ける一または複数のプロジェクトに対して原因または結果の関係をもちうるバイヤーの活動である。ビジネスイベントの例は、新製品の作成に関わるプロジェクトであろう。製品を売り出すための販売促進キャンペーンは、販売促進キャンペーンが製品を作成するプロジェクトとは何の関係もないと言ってもよいため、ビジネスイベントと考えられるだろう。ただし、ビジネスイベントは製品を作成するプロジェクトの完了に左右される。例えば、製品がプロジェクト内の何らかの瑕疵のために作成しないと判断されたら、従属ビジネスイベント、すなわちそのプロジェクトに関係する販売促進キャンペーンに不必要なお金を使うのは賢明ではないであろう。ビジネスイベントマスター記録は、例えば表１２１などのデータベーステーブルに格納する。壊滅的な瑕疵でない場合、ビジネスイベントはプロジェクトリスクの通知を考慮して遅らせる、または並行して材料の修正を受けさせることができるであろう。上記述べたプロジェクト、予算、および資産と同様の層構造をもつことを明示的には示していないが、当業者には、ビジネスイベントが本発明の原理を逸脱することなく層状の構造にできるであろうことは認識されるであろう。

もう一度図９８を参照すると、ビジネスイベント記録作成プロセスフロー９８００はステップ９８０３から始まる。ステップ９８０３で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９８０６で、ユーザは新規ビジネスイベントの作成に移動する。ステップ９８１０で、システムはユーザに入力ワークフローフォームを提示する。ステップ９８１３で、ユーザはビジネスイベントマスターの名前を入力する。ステップ９８１６で、ユーザはビジネスイベントの明細を記入する。ステップ９８２０で、ユーザはビジネスイベントのオーナーを指定する。システム９８２３で、ユーザはオプションでデフォルトの事業単位を指定する。ステップ９８２６で、ユーザはオプションでデフォルトの原価中心点を指定する。ステップ９８３０で、ユーザはオプションで計画した開始日と終了日を指定する。ステップ９８３３で、ユーザはオプションで計画地を指定する。ステップ９８３６で、ユーザはビジネスイベントの顧客の所属を指定する。ステップ９８４０で、ユーザはビジネスイベントの影響コードを指定する。ステップ９８４３で、ユーザはこれまで行った入力を保存する。ステップ９８４６で、設定をデータベースに格納する。

予算、資産、契約、およびビジネスイベント記録などのコア情報データ要素をプロジェクトマスターまたはプロジェクトグループに所属させると、それが今度はマスターデータになる。そうではなく、プロジェクト作業または一般調達取引データにおいて未使用の場合、単に未使用のコア情報データである。プロジェクトのコアデータへの所属を行ったら、その結果の設定をプロジェクト運営システム９０１７に格納する。

図９９はプロジェクトマスターとコアデータの所属のプロセスフローを図示する。プロセスフロー９９００は、プロジェクトマスター記録の他のマスター記録（例えば、予算、資産、ビジネスイベント、または契約のマスター記録）へのマッピングを表す。プロセスフロー９９００のマッピングは典型的には、例えば表１１７、１２０、１２２、１２４、１２７などのデータベーステーブルに格納する。プロセスフロー９９００はバイヤー・エンティティのプロジェクトマスター記録のオーナーから起こす。ただし、当業者にはこれが例示的な態様であることは認識されるであろう。プロセスフロー９９００は、それが所属する他のマスターデータ情報コンポーネントから起こして、反対方向に流れることができるであろう。

プロセスフロー９９００が示すように、個々の情報入力は行う所属関係によって変わりうる。これら所属関係は、プロジェクトが入札されたら変化しうるデフォルトの初期マッピングを表す。プロジェクト運営システム９０１７のプロジェクトマスター記録の他のコア情報データへのマッピングは、プロジェクト作業の取引データが導入されたら、典型的にはより確定的になる。プロセスフロー９９００内では明示的に示していないが、当業者には、プロジェクト記録の取引データが導入された後、既存のプロジェクトマスター記録の所属の編集を行えることは認識されるであろう。

もう一度図９９を参照すると、プロセスフロー９９００はステップ９９０３から始まる。ステップ９９０３で、バイヤーの許可ユーザは、例えばホームページのナビゲーションバーからプロジェクト運営コントロールを起動する。ステップ９９０６で、バイヤーユーザはプロジェクトマスターの運営に移動する。ステップ９９１０で、システムはバイヤーユーザに利用できるプロジェクトマスター記録を表示する。ステップ９９１３で、バイヤーユーザは所要のプロジェクトマスター記録を選択する。ステップ９９１６で、システムはユーザに構成されたプロジェクトマスター関連データ要素を表示する。ステップ９９２０で、システムはユーザに「関係を表示」とラベルの貼られたコントロールまたは同様な他のものを提示する。ステップ９９２３で、ユーザは「関係を表示」コントロールを起動する。ステップ９９２６で、システムはプロジェクトマスター記録関係の出力画面を表示する。プロジェクトマスター記録関係の出力画面は、典型的にはプロジェクト、予算、資産、契約、およびビジネスイベントに細分される。

ステップ９９２６から、実行はステップ９９３０に進む。ステップ９９３０で、ユーザはユーザが設定を編集したいかどうかに関して指示される。ステップ９９３０での肯定応答に反応して、実行はステップ９９３３に進む。ステップ９９３３で、システムはユーザにコア情報データカテゴリを選択するよう指示する。ステップ９９３６で、ユーザはコア情報データカテゴリ（例えば、予算、契約、ビジネスイベント、または資産）を選択する。ステップ９９４０で、システムはユーザに「現在の記録を編集」または「新規関係を作成」を選択するよう指示する。ステップ９９４３で、ユーザが「新規関係を作成」を選択すると、ステップ９９４６でシステムは、利用できるコア情報データカテゴリマスター記録の表示をユーザに提示する。

ステップ９９５０で、ユーザは所要のマスター記録を選択する。ステップ９９５３で、システムは所属と構成済みデータ入力の要件を記入するようユーザに指示する。ステップ９９５６で、ユーザは要求される入力を記入する。ステップ９９６０で、ユーザは選択した記録の所属を記入したら設定を保存する。ステップ９９６３で、関係の所属をデータベースに格納し、「ペンディング」の状態をマークする。

ステップ９９６６で、システムは記録の所属を所属に影響を受ける構成済みビジネス記録のオーナーに一斉配信する。ステップ９９７０で、システムは影響を受けるビジネス記録のオーナーに記録の所属を承認または否認するよう指示する。ステップ９９７３で、影
響を受けるビジネス記録のオーナーは所属の承認または否認を許可される。所属の承認に応答して、実行はステップ９９７６に進み、そのステップで、所属はデータベースに格納されて、状態が「現在」となる。ただし、ステップ９９７３で、記録の所属の処置が否認されたら、実行はステップ９９８０に進み、そのステップで所属はデータベースに格納され、状態は「拒絶」となる。ステップ９９７６またはステップ９９８０のいずれかから、実行はステップ９９８３に進む。ステップ９９８３で、システムは処置要求者（すなわち、バイヤーユーザ）に記録オーナーの処置を通知する。

このように、プロセスフロー９９００の最後に、プロジェクトマスター記録は、例えば、予算マスター記録、資産マスター記録、契約マスター記録、ビジネスイベントマスター記録などの他のコア情報データ記録に所属する。本発明の様々な実施例では、バイヤーユーザがプロジェクトマスター記録を所属させようとする他の記録のオーナーが、プロジェクトマスター記録のバイヤーユーザが要求する所属を承認または否認する権限をもつ。

図１００は、バイヤーユーザの例示的なプロジェクト運営ホームページのユーザインターフェースを表す。

図１０１は、本明細書で述べる活動をサポートする例示的な使用可能データベーススキーマを表す。当業者には、ネットワークベースのシステム（例えば、インターネット）への本発明の様々な実施例の実装には、典型的にはコードおよび／またはデータベース情報処理基盤のいずれかを利用することが認識されるであろう。データベーススキーマおよび本明細書に記載する対応のデータベーステーブルは、このようなネットワークベースの実装をどのように行えるかの例として役立つ。

プロジェクト作業取引データの取得と格納
図１０２〜１０３は、図９３のステップ９３２０〜９３３５で大まかに図示したプロジェクト作業取引データの取得と格納をより詳細に図示する。図１０２に図示されるプロセスフローは、２つの異なるデータセットを互いに統合するのに役立つ。すなわち、プロジェクトマスター記録をＲＦｘ入札に所属させる。この所属の後に、図８９の前に上記述べたものと同様なＲＦｘ入札プロセスが行われる。

図１０２は、発注書起動プロセスフロー１０２００からＲＦｘ入札の要約図を図示する。プロセスフロー１０２００のステップ１０２１５〜１０２４０は、新規バイヤー入札依頼書を既存のプロジェクトマスター記録にマッピングするサブプロセスを表す。ステップ１０２１５〜１０２４０の結果生じる関係の設定は、例えば表１２８などのデータベーステーブルに格納し、応札の結果その次に出す購入申請書へのマッピングに役立ち、その場合関係の設定は、例えば表１２９などのデータベーステーブルに格納する。

これだけには限定されないが、ユーザがプロジェクトマスター記録を閲覧する権限がない場合、利用できるプロジェクトマスター記録が入札依頼活動に関係していない場合、またはプロジェクトオーナーがプロジェクトに関係する入札依頼書の通知もしくは承認許可を必要とする場合など、変型プロセスも可能である。図１０２に図示するプロジェクト作業の入札依頼書はビジネスニーズまたは確定したプロジェクトから出す。入札依頼書のプロジェクトマスター記録へのマッピングは、成立した入札プロセスから生じる取引データと以前に構成したマスターデータ記録とを後で統合するのを容易にする。

もう一度図１０２を参照すると、プロセスフロー１０２００はステップ１０２０５から始まる。ステップ１０２０５で、バイヤーの許可ユーザは、例えばバイヤー用ホームページのナビゲーションバー（例えば、図４Ａを参照）から、ＲＦＰ／ＲＦＱ作成コントロールを起動する。ステップ１０２０５から、実行はステップ１０２１０に進む。ステップ１
０２１０で、バイヤーユーザは「新規ＲＦＱを作成」を選択する。ステップ１０２１５で、システムはバイヤーユーザにＲＦＱを利用できるプロジェクトマスター記録に所属させるよう指示する。ステップ１０２２０で、バイヤーユーザは「プロジェクトマスター所属」コントロールを選択する。ステップ１０２２５で、システムはユーザにアクティブなプロジェクトマスター記録のリスト表示を提示する。ステップ１０２３０で、バイヤーユーザは利用できるプロジェクトマスター記録を選択する。ステップ１０２３５で、バイヤーユーザは所属を保存する。ステップ１０２４０で、ＲＦｘ入札とプロジェクトマスター所属関係をデータベースに格納する。

ステップ１０２４５で、バイヤーは、例えば図１６Ａ〜Ｄのように、ＲＦｘ入札を処理する。ステップ１０２５０で、供給者は、例えば図２５のように、ＲＦｘ応札書を処理する。ステップ１０２５５〜１０２６０で、バイヤーは、例えば図３１〜３７のように、供給者のＲＦｘ応札書を処理して落札する。ステップ１０２７０〜１０２７５で、バイヤーと供給者は、例えば図４０Ｃのように、購入申請書／発注書を処理する。ステップ１０２８０で、バイヤーは、例えば図４０Ｃのように、発注書を起動する。

図１０３は、マスターデータ、入札依頼書、および発注書データ間の連結性を含む変形調達データベーススキーマ１０３００を図示する。スキーマ１０３００は、プロジェクト運営システム９０１７と調達管理システム９０１３との高レベルの連結性を可能にする。作業範囲記述書（ＳＯＷ）記録の構成
図１０４〜１１５は作業範囲記述書（ＳＯＷ）記録の構成を図示する。ＳＯＷ記録構成プロセスは、図９３のステップ９３４０〜９３５０で大まかに述べる。

図１０４は、本発明の原理に従う作業範囲記述書のダイナミクス１０４００を図示する。プロジェクトＡ１０４０５を異なる４つのＲＦｘ入札１０４１０（ａ）〜（ｄ）に分割する。ＲＦｘ入札１０４１０（ａ）〜（ｄ）は、入札および応札書のレビュープロセスが完了したら、最終的には落札書の発行１０４２０（ａ）〜（ｄ）になるであろう。落札したプロジェクト作業活動１０４２５（ａ）〜（ｄ）を購入申請書／発注書モジュール１０４３０（ａ）〜（ｄ）に統合して、バイヤー・エンティティおよび供給者エンティティの両方がデータを処理する。

発注書に定義し、格納される個々のプロジェクト作業活動１０４２５（ａ）〜（ｄ）は、発注書成果物モジュール１０４３０（ａ）〜（ｄ）に記載される具体的な成果物にマッピングできる。基本的には、発注書行活動を集計して、発注書行活動が関係または所属する成果物記録に反映させることができる。このマッピングを要素１０４３２（ａ）〜（ｄ）で表す。その結果の成果物とそれに所属する活動を要素１０４３５（ａ）〜（ｄ）で表す。

プロジェクトレベルの概念は、供給者固有のプロジェクト作業コンポーネントからの成果物／ＳＯＷを全体的なプロジェクト成果物／ＳＯＷフレームワークにマッピングする付加レベルの関係の構築を表す。複数の供給者がそれぞれの入札および発注書に規定されるそれぞれ別のアウトプットに従事してアウトプットを生みながら、まとまったアウトプットに向かって独立してもしくは協力して作業するのが一般的である。プロジェクトをフェーズなどの進捗段階で戦術的に管理する場合がその例である。従来から、異なるＲＦｘ入札の結果契約した様々な供給者からの多くの成果物がうまく完了したら、まとまって成果物／ＳＯＷが達成されることになる。このように細分した成果物を大きなプロジェクトレベルのマイルストーンにまとめ上げることが、従来のフェーズ別プロジェクトモデルであることは当業者には認識されるであろう。

様々な供給者のＳＯＷのプロジェクトのマイルストーンまたはフェーズへのマッピング
／所属を要素１０４３８で表し、１つにまとめた供給者のＳＯＷを集合プロジェクトフェーズに統合することになる。ダイナミクス１０４００は様々なプロジェクト成果物をより大きなマイルストーン集合体にある程度区分する。この時点で、成果物間の関係が確立し、従属性の階層（すなわち、原因と結果）が所属記録セット内に構成される。要素１０４４０で表す構成は完結した１つのプロジェクト作業成果物階層１０４４５となり、それによってすべての有限のプロジェクト作業アウトプットがプロジェクトのマイルストーンの進捗に結合するだけでなく、原因と結果の管理を容易にするように定義される。このように、成果物をまとめて結合して、多様な成果物／ＳＯＷ記録間の従属性を定義する。

関係構築の次の側面は、プロジェクトとプロジェクトグループとの関係レイヤである。プロジェクトポートフォリオ内では、原因と結果の影響をもつ多数の独立した活動が複数のプロジェクト内で起こるであろう。そのため、この連結性が必要である。同族のプロジェクト（すなわち、同じプロジェクトグループ内のプロジェクト）を要素１０４５０で表し、プロジェクトＡとプロジェクトＸとの関係のマッピングを要素１０４５５で表す。同じデータ処理環境およびデータベース構造内で関係のマッピングを行うと、たとえ成果物アウトプットが異なるプロジェクトに属していても、同じ従属階層の構成を行うことができる。この連結性は多プロジェクトＳＯＷ／成果物統合であるプロジェクトＳＯＷ統合の３番目のレイヤを表す。

次に説明するのは、プロジェクト作業環境以外のＳＯＷ／成果物記録を企業の総合的なビジネスフレームワークに統合することである。この統合はそれぞれ要素１０４６２、１０４６８、１０４７２、１０４７８で表し、コア情報データ要素１０４６０、１０４６５、１０４７０、１０４７５を対象とする。

図１０５は、例えば、プロジェクト管理ホームページからユーザナビゲーションと記録の選択によってアクセスできる例示的なバイヤーユーザ用プロジェクトマスターウエブページである。図１０５は許可されたユーザのあるプロジェクトに関わる主な情報と処理インターフェースポータルを表す。ページ上の個々の機能的コントロールへのユーザアクセスは、ユーザ許可によって管理する。

図１０６は成果物／ＳＯＷ記録へのプロジェクト作業の所属を表す例示的なプロセスフローである。図１０６に図示するプロセスフローは図１０４の要素１０４３２および１０４３５で大まかに説明される。図１０６では、発注書活動と発注書成果物記録との所属プロセスフロー１０６００はステップ１０６０５から始まる。ステップ１０６０５で、バイヤーの許可ユーザは、例えばプロジェクトマスターホームページから、ナビゲーションで公開の発注書にアクセスする。ステップ１０６１０で、バイヤーユーザは該当する発注書を選択する。ステップ１０６１５で、システムはユーザに発注書のヘッダーと行項目の詳細の表示を提示する。ステップ１０６１５で、発注書を状態コードで管理する。このため、一部の発注書は承認がまだ済んでいない、またはまだ購入申請書の段階で処理中の状態であることがある。そのため、ステップ１０６１５はユーザに対する発注書の表示に関係し、表示は作成済み、承認済み、発注書非納入行項目と成果物／ＳＯＷのマッピング可である。

ステップ１０６２０で、活動の関係を構成するまたは活動の関係を編集するアクティブなコントロールオプションをユーザに提示する。ステップ１０６２０は実用的なニーズに応えて、行項目と成果物との関係を編集できるようにしている。ステップ１０６２０で活動の関係を構成オプションを選択すると、ステップ１０６２５でシステムは発注書成果物と発注書非納入行項目の細分化したリスト表示をユーザに提示する。ステップ１０６２５は非納入物の発注書行項目からの成果物／ＳＯＷ記録の分割を処理する。ステップ１０６３０で、ユーザは、例えばチェックボックスで所要の成果物記録を選択する。ステップ１
０６３５で、ユーザは、例えばラジオボタンで、所要の所属非納入行項目記録または複数の記録を選択する。ステップ１０６４０で、ユーザは「設定を保存」コントロールを起動する。プロセスフロー１０６００のこの時点で、バイヤーユーザは発注書成果物を一または複数の発注書非納入行項目に所属させたことになる。

ステップ１０６４５で、システムは妥当性検査ルーチンを実行する。ステップ１０６４５の妥当性検査ルーチンは典型的には日付比較演算を伴う。例えば、発注書非納入行項目が具体的な活動に関する情報を含んでいるため、発注書非納入行項目に対応する活動が論理的には、例えば対応付けた発注書成果物の納期を超えて延長しないように、単純な日付比較を行える。例えば、発注書成果物の納期が２００６年１０月１５日で、バイヤーユーザが４つの発注書非納入行項目を実施中で、２００７年１月まで延長する関連活動に所属させていた場合、ステップ１０６４５の妥当性検査ルーチンは不一致を示すであろう。ステップ１０６５０で妥当性検査に合格したら、ステップ１０６５５で発注書行活動と発注書成果物の所属をデータベースに格納する。ステップ１０６５０で妥当性検査に合格しなければ、実行はステップ１０６６０に進む。実行はステップ１０６５５からステップ１０６６０にも進む。

ステップ１０６６０で、ユーザに、所属成果物の納期以降まで続く発注書非納入行項目のリスト表示を提示する。ステップ１０６６５で、ユーザに妥当性が確認されなかった記録を廃棄する、非納入物の納期を修正する、成果物の納期を修正する、または妥当性が確認されなかった所属を保存する選択肢を提示する。バイヤーユーザが妥当性が確認されなかった所属を保存したいかもしれない状況の例は、労務の非納入行項目の場合であろう。例えば、始まりから終わりまでに多数のプロジェクトの労働者をある特定のプロジェクトに割り当てて、その作業がプログラム全体の複数の成果物の活動に当てはまるときに、発注書記録の観点から、その労働者全体に対して１つだけの割り当て記録を作成した場合、一または複数の労働者の雇用期間がある特定の所属発注書成果物以降まで続く状況となり、バイヤーユーザはこの明らかな不一致を安全に無視できるであろう。その場合、割り当ては典型的には複数の成果物／ＳＯＷ記録にマッピングされることになろう。

ステップ１０６７０で、ユーザはステップ１０６６５で提示する選択肢に対して様々な処置選択をする。ステップ１０６７５で、処置選択肢を選択した結果、様々なワークフローモデルとなる。ステップ１０６８０で、ユーザは所要の変更をする。ステップ１０６８５で、ユーザは「設定を保存」コントロールを起動する。ステップ１０６８５から、実行はステップ１０６４５に戻る。当業者には、ユーザは所属していない発注書記録についてもプロセスフロー１０６００を繰り返せることは認識されるであろう。図１０６に関して述べた構成を、例えば表１３４および１３５などのデータベーステーブルに格納する。プロセスフロー１０６００は最終的には、明確な供給者成果物ＳＯＷにプロジェクト作業活動の行項目を明確に所属させることになる。次の構成モードは発注書成果物／ＳＯＷ記録のプロジェクト全体のフレームワークへの統合である。

図１０７は、プロジェクトフェーズ記録とフェーズ区分スキーマの作成を描くプロジェクトフェーズ記録作成プロセスフロー１０７００を図示する。プロセスフロー１０７００は図１０４の要素１０４３８で大まかに示される。フロー１０７００はステップ１０７０５から始まる。ステップ１０７０５で、バイヤーの許可ユーザは、例えばプロジェクトマスターホームページから、ナビゲーションでプロジェクトフェーズ区分にアクセスする。ステップ１０７１０で、システムはユーザにプロジェクトフェーズ記録のリスト表示を提示する。ステップ１０７１５で、当該記録が存在するかどうかの評価を行う。ステップ１０７１５で否定の判断をされたら、実行はステップ１０７２０に進む。ステップ１０７２０で、ユーザは備え付けの「フェーズを作成」コントロールを選択する。ステップ１０７２５で、システムはユーザにフェーズ構造入力フェーズを提示する。ステップ１０７３０
で、システムはユーザにプロジェクトフェーズの数を指定するよう指示する。ステップ１０７３５で、システムはユーザに、ユーザがステップ１０７３０で行った入力に対するプロジェクトフェーズ記録のリスト表示を提示する。ステップ１０７４０で、ユーザは所要のフェーズを選択する。ステップ１０７４５で、システムはユーザにフェーズ入力ページを提示する。ステップ１０７５０で、ユーザは入力を完了する。ステップ１０７５５で、ユーザは設定を保存する。ステップ１０７６０で、プロジェクトフェーズをデータベースに格納する。ステップ１０７６５で、ユーザは該当するすべてのフェーズ別記録についてプロセスフロー１０７００のこれまでのステップを繰り返す。

プロセスフロー１０７００は、記録が作成されたらそうなるように、プロジェクトフェーズ別記録が存在しうることを強調するために、プロジェクトフェーズ別記録が存在しない状況を図示する。ただし、フェーズ区分スキーマ構成が必ずしも、前に述べたプロセスフローの後に線形で時系列になっていなくともよい。たとえば、バイヤーは入札プロセスの開始前に非常にタイトなプロジェクト計画を練っていて、入札に入る前に具体的な要求事項についてこれらのフェーズ別記録をすでにセットアップしている可能性もあるだろう。反対に、入札後にフェーズ別計画を立てる、またはプロジェクトマネージャーと連係して作業する供給者もしくは供給者のグループのフェーズ別計画を受け入れるのは珍しいことではない。このように、プロジェクトフェーズ別記録を以下の図１０８のプロセスフローの前に作成する限り、フェーズ別計画の構成は様々であり、直面するそのプロジェクト作業の状況に左右される。フェーズ別記録は、例えば表１３６などのデータベーステーブルに格納する。

図１０８は発注書成果物のプロジェクトフェーズ所属のプロセスフロー１０８００を図示し、これは成果物／ＳＯＷ記録とプロジェクトフェーズ別記録の間に存在する次の論理集約／マッピングである。これらマッピングは、例えば表１３７などのデータベーステーブルに格納する。プロセスフロー１０８００の完了時、適切な期間内に目標を達成するのを容易にするために、プロジェクト作業活動（すなわち、取引データ）を図１０７のプロジェクトフェーズ区分に所属させる。

図１０８に戻ると、プロセスフロー１０８００はステップ１０８０５から始まり、バイヤーの許可ユーザは、例えばプロジェクトマスターのホームページから、ナビゲーションでオープンなプロジェクトフェーズ区分にアクセスする。ステップ１０８１０で、システムはユーザにプロジェクトフェーズ記録のリスト表示を提示する。ステップ１０８１５で、ユーザは所要のフェーズ記録を選択する。ステップ１０８２０で、ユーザは備え付けの「成果物を所属させる」コントロールを選択する。ステップ１０８２５で、システムはユーザに所属のない発注書成果物のリスト表示を提示する。ステップ１０８３０で、ユーザは、例えばラジオボタンで、所要の発注書成果物記録を選択する。ステップ１０８３５で、ユーザはステップ１０８３０で選択した設定を保存する。

ステップ１０８４０で、システムはユーザに入力項目を記入するように指示する。ステップ１０８４５で、ユーザは入力項目を記入する。ステップ１０８５０で、ユーザは入力の設定を保存する。ステップ１０８４０〜１０８５０は、例えばフェーズ重要度設定など、典型的には予め定義するフェーズ設定に関係する。（例えば、表１３７を参照）。ステップ１０８５５で、プロジェクトフェーズ成果物をデータベースに格納する。ステップ１０８６０で、ユーザは該当するすべてのフェーズ区分と発注書成果物記録についてプロセスフロー１０８００を繰り返す。

図１０９は、プロジェクトＳＯＷ／成果物の従属構成のプロセスフロー１０９００を図示する。プロセスフロー１０９００はステップ１０９０５から始まり、バイヤーの許可ユーザは、例えばプロジェクトマスターのホームページから、ナビゲーションでＳＯＷ運営
情報にアクセスする。ステップ１０９０８で、システムはユーザにフェーズ別記録ごとに集計したプロジェクトＳＯＷ記録のリスト表示を提示する。ステップ１０９１０で、ユーザに関係スキーマを見る、関係スキーマを作成する、または関係スキーマを編集する選択肢が提示される。すなわち、ステップ１０９１０で、ユーザはＳＯＷと記録との従属性を作成するか、見るか、または編集するかを選択するよう指示される。

ユーザがステップ１０９１０で「関係スキーマを作成」オプションを選ぶと、実行はステップ１０９１５に進む。ステップ１０９１５で、システムはユーザにリストから発注書ＳＯＷを選択するよう指示する。ステップ１０９１８で、ユーザはＳＯＷ記録を選択する。ステップ１０９２０で、システムはユーザに所属させる記録を選択するよう指示する。ステップ１０９２５で、ユーザは所属させるＳＯＷ記録を選択する。ステップ１０９２５で、所属させる記録の選択が１つの所属させる記録の選択として示されている。ただし、処理のために記録のブロックの選択を容易にする機能を備えられるため、必ずしもこのような制限がある必要はない。

ステップ１０９３０で、システムはユーザにＳＯＷ関係構成ページを提示する。（例えば表１３９を参照。表１３９は構成ページの例示的なデータ要素を記載している）。ステップ１０９３３で、ユーザは、例えばプルダウンメニューから、ＳＯＷの関係を指定する。ステップ１０９３７で、ユーザは従属制約を強制するかどうかを指定するが、これは従属ＳＯＷ記録はそれが従属するＳＯＷ記録が完了するまで始められないことを意味する。強制または非強制にする制約の仕様は、連鎖的な成果物の従属性のために従属成果物が完了できなくなる可能性を含意するが、それでもすべての活動を禁止できるわけではない。このような場合、制約を強制したいとは思わないだろう。例えば、成果物アウトプットが技術保守ガイドで、コンピュータネットワークの物理的なインフラストラクチャの構築に従属している場合、従属成果物は親成果物が完了するまで開始できないことを規定する制約を強制するのが賢明であろう。

ステップ１０９４０で、ユーザは所要の任意のコメントを入力する。ステップ１０９４５で、ユーザは「関係を保存」コントロールを選択する。ステップ１０９５０で、システムは、例えば完了日の比較を使って、関係変数の妥当性検査をする。ステップ１０９５５で、妥当性検査の処置を行う。妥当性検査に合格すると、実行はステップ１０９６０に進む。ステップ１０９６０で、ＳＯＷ／成果物の所属をデータベースに格納する。ステップ１０９５５で妥当性検査が不合格になると、実行はステップ１０９６５に進む。ステップ１０９６５で、ユーザに妥当性検査が不合格となった変数のリスト表示を提示する。ステップ１０９７０で、ユーザにセッションを終了するか、または修正した変数に基づいて再び妥当性検査を試みるために妥当性検査の変数を修正するかの選択肢が提示される。ユーザが妥当性検査の変数の修正オプションを選択すると、実行はステップ１０９７５に進む。

ステップ１０９７５で、ユーザは変数処置の選択をする。ステップ１０９８０で、処置オプションの結果は様々なワークフローモデルになる。ステップ１０９８８で、ユーザは所要の変更をする。ステップ１０９９０で、ユーザは「設定を保存」コントロールを起動する。ステップ１０９９０から、実行はステップ１０９５０に戻る。当業者には認識されるように、ユーザは必要であればプロセスフロー１０９００を繰り返せる。従属構成ステップで、プロジェクトの物理的なアウトプットのマイルストーンを連結して従属性を確立できる。表１３９で例示的に開示する関係の種類はＳＯＷのクリティカルな従属性を確立する。プロセスフロー１０９００で示される記録の格納は、例えば表１３８などのデータベーステーブルに行う。プロジェクトグループ内の異なるプロジェクト間のＳＯＷのマッピングについては、機能的ユーザインターフェースが複数のプロジェクトの記録セットを含むＳＯＷ／成果物記録の拡張画面を提示する以外は同じである。

図１１０は、図９３のステップ９３４５で大まかに述べたＳＯＷ／成果物記録と予算マスターデータ記録のマッピングをする例示的なプロセスフロー１１０００を図示する。プロセスフロー１１０００はステップ１１００５から始まる。ステップ１１００５で、バイヤーの許可ユーザは、例えばプロジェクトマスターのホームページから、予算管理コントロールを起動する。ステップ１１０１０で、システムはユーザにデフォルト構成のプロジェクトに関係する予算マスター記録のリスト表示を提示する。ステップ１１０１５で、ユーザは該当する予算マスター記録を選択する。ステップ１１０２０で、システムはユーザにプロジェクトフェーズ別に集計したＳＯＷ／成果物記録のリスト表示を提示する。ステップ１１０２５で、システムは所属させるＳＯＷ／成果物記録またはプロジェクトフェーズを選択するようユーザに指示する。

ステップ１１０３０で、ユーザは選択をする。ユーザがステップ１１０３０でプロジェクトフェーズを選択すると、実行はステップ１１０３５に進む。ステップ１１０３５で、システムは入力ページをユーザに提示する。ステップ１１０４０で、ユーザは、例えばドロップダウンメニューから、事業単位を選択する。ステップ１１０４５で、ユーザは、例えばドロップダウンメニューから、原価中心点を選択する。ステップ１１０５０で、ユーザは、例えばドロップダウンメニューから、予算マスター記録のオーナーを選択する。ステップ１１０５５で、ユーザはこれまでに行った設定を保存する。ステップ１１０６０で、システムは日付および／または予算に基づいた予算マスターの妥当性検査ルーチンを実行する。ステップ１１０６５で、予算マスターの妥当性が確認されたかどうかの判断をする。ステップ１１０６５でそのように判断されたら、実行はステップ１１０７０に進み、承認された予算管理者に体系的な通知をする。ステップ１１０７５で、予算管理者の処置を行う。ステップ１１０８０で、予算管理者のステップ１１０７５での承認に応答して、所属をデータベースに格納する。ステップ１１０８５で、プロジェクトオーナーへの通知を体系的に行う。ステップ１１０３０で、ユーザが所属させるＳＯＷ／成果物記録を選択すると、実行はステップ１１０９０に進む。ステップ１１０９０で、ユーザによる個々のＳＯＷ／成果物記録の選択は、フェーズ予算の所属の場合と全く同じデータ処理フローが続くが、各ＳＯＷ記録について情報処理を完了する点が異なる。ステップ１１０９０から、実行はステップ１１０５５に戻る。

プロセスフロー１１０００のマッピングは、例えば表１４０などのデータベーステーブルに格納する。図１１０には具体的に表していないが、特定の成果物の予算配賦を複数の事業単位および／または原価中心点エンティティ間に分割する機能も利用できるであろう。当業者には、プロセスフロー１１０００が複数の方向から生じることができ、予算管理者またはプロジェクトマネージャーが記録の構成マッピングを開始できるであろうことは認識されるであろう。

図１１１は、ＳＯＷ／成果物記録を資産マスターデータ記録にマッピングする例示的なプロセスフロー１１１００を図示する。プロセスフロー１１１００はステップ１１１０５から始まり、バイヤーの許可ユーザは、例えばプロジェクトマスターのホームページから、資産管理コントロールを起動する。ステップ１１１１０で、システムはユーザにデフォルト構成のプロジェクトに関係する資産マスター記録のリスト表示を提示する。ステップ１１１１５で、ユーザは該当する資産マスター記録を選択する。ステップ１１１２０で、システムはユーザに、プロジェクトフェーズ別に集計した所属材料行項目を付けたＳＯＷ／成果物記録のリスト表示を提示する。ステップ１１１２５で、ユーザは該当するＳＯＷ／成果物記録を選択する。ステップ１１１３０で、システムはユーザに所属材料行項目のリスト表示を提示する。ステップ１１１３５で、ユーザは所要の行項目を選択する。ステップ１１１４０で、システムはユーザに入力ページを提示する。ステップ１１１４５で、ユーザは、例えばドロップダウンメニューから、事業単位を選択する。ステップ１１１５
０で、ユーザは、例えばドロップダウンメニューから、原価中心点を選択する。ステップ１１１５５で、ユーザは、例えばドロップダウンメニューから、資産マスター記録の管理オーナーを選択する。ステップ１１１６０で、ユーザはこれまでに行った設定を保存する。ステップ１１１６５で、システムは日付および／または資本予算に基づいた資産マスターの妥当性検査ルーチンを実行する。

ステップ１１１７０で、妥当性評価を行う。肯定の妥当性評価に応答して、実行はステップ１１１７５に進む。ステップ１１１７５で、承認済みの資産管理者への通知を体系的に行う。ステップ１１１８０で、予算管理者の処置が行われる。ステップ１１１８０で承認されると、実行はステップ１１１８５に進む。ステップ１１１８５で、所属をデータベースに格納する。ステップ１１１９０で、プロジェクトオーナーへの通知を体系的に行う。プロセスフロー１１１００のマッピングは、例えば表１４１などのデータベースｔａｋｅ（テーブル）に格納する。

すべてのマスターデータのマッピングと同様、プロセスフロー１１１００はプロジェクト管理記録のオーナーまたは資産管理記録のオーナーのどちらからも行える。当業者には、資産管理の透明性を確保しその後のその管理を確実にするために、プロジェクト作業内で定義するすべての材料活動の処理を委任する様々な実施例が構成できることは認識されるであろう。典型的な事業環境においては、資産は契約レベルで管理するより大きな作業範囲記述書（すなわち、成果物）の一部となることもあるだろう。特定の契約または資産管理システムの状況内では、物理的な資産さえも定義されないことが多い。

図１１２は、ＳＯＷ／成果物記録を契約記録にマッピングする例示的なプロセスフロー１１２００を図示する。プロセスフロー１１２００はステップ１１２０５から始まり、バイヤーの許可ユーザが、例えばプロジェクトマスターのホームページから、契約管理コントロールを起動する。ステップ１１２１０で、システムはユーザにデフォルト構成のプロジェクトに関係する契約記録のリスト表示を提示する。ステップ１１２１５で、ユーザは該当する契約記録を選択する。ステップ１１２２０で、システムはユーザにプロジェクトフェーズ別に集計したＳＯＷ／成果物記録のリスト表示を提示する。ステップ１１２２５で、ユーザは該当するＳＯＷ／成果物記録を選択する。ステップ１１２３０で、システムはユーザに入力ページを提示する。ステップ１１２３５で、ユーザは、例えばドロップダウンメニューから、事業単位を選択する。ステップ１１２４０で、ユーザは、例えばドロップダウンメニューから、原価中心点を選択する。ステップ１１２４５で、ユーザは、例えばドロップダウンメニューから、オプションで該当する顧客を選択する。ステップ１１２５０で、ユーザは、例えばドロップダウンメニューから、契約管理オーナーを選択する。ステップ１１２５５で、ユーザはそれまでに行った設定を保存する。

ステップ１１２６０で、システムは契約の妥当性検査ルーチンを実行する。妥当性検査は単に時間に敏感である必要があるだけでなく、範囲に敏感でもあろう。敏感な他の変数は、例えば、通貨またはサービス／商品の提供の種類が含まれるであろう。ステップ１１２６５で、契約の妥当性検査の判断を行う。ステップ１１２６５で妥当性検査の合格に応答して、実行はステップ１１２７０に進む。ステップ１１２７０で、承認済みの契約管理者（すなわち、構成した契約マスター記録のオーナー）への通知を体系的に行う。ステップ１１２７５で、契約管理者の処置を行う。ステップ１１２７５で承認されると、実行はステップ１１２８０に進む。ステップ１１２８０で、所属をデータベースに格納する。ステップ１１２８５で、プロジェクトオーナーへの通知を体系的に行う。プロセスフロー１１２００のマッピングは、例えば表１４２などのデータベースに格納する。プロセスフロー１１２００は、図１１２にはそのように明示的に表してはいないが、双方向でもよい。

下流のクライアントとその後の契約参照の指定を使用して、マルチレベルの契約を活動
に所属させてもよい。例えば、バイヤー・エンティティが契約の下で外部の供給者を利用していて、バイヤー・エンティティと商品／サービスの契約を結んでいる最終的なエンドユーザに外部の供給者がサービスを提供する場合がそれにあてはまるであろう。

図１１３は、ＳＯＷ／成果物記録をビジネスイベント記録にマッピングするプロセスフロー１１３００を図示する。プロセスフロー１１３００はステップ１１３０３から始まり、バイヤーの許可ユーザは、例えばプロジェクトマスターのホームページからビジネス管理コントロールを起動する。ステップ１１３０５で、システムはユーザにデフォルト構成のプロジェクトに関係するビジネスイベント記録のリスト表示を提示する。ステップ１１３１０で、ユーザは該当するビジネスイベント記録を選択する。ステップ１１３１５で、システムはユーザにプロジェクトフェーズ別に集計したＳＯＷ／成果物記録のリスト表示を提示する。ステップ１１３２０で、ユーザは該当するＳＯＷ／成果物記録を選択する。ステップ１１３２３で、システムはユーザに入力ページを提示する。ステップ１１３２５で、ユーザは、例えばドロップダウンメニューから事業単位を選択する。ステップ１１３３０で、ユーザは、例えばドロップダウンメニューから、原価中心点を選択する。ステップ１１３３５で、ユーザは、例えばドロップダウンメニューから、オプションで該当する顧客を選択する。ステップ１１３４０で、ユーザは関係の種類を指定する。ステップ１１３４５で、ユーザは従属制約を強制するかどうかを指定する。ステップ１１３５０で、ユーザは、例えばドロップダウンメニューから、イベント管理オーナーを選択する。ステップ１１３５５で、ユーザはそれまでに行った設定を保存する。

ステップ１１３６０で、システムはビジネスイベントの妥当性検査ルーチンを実行する。ステップ１１３６５で、妥当性検査が合格だったかどうかの判断を行う。ステップ１１３６５での妥当性検査の合格に応答して、実行はステップ１１３７０に進む。ステップ１１３７０で、承認済みのビジネスイベント管理者への通知を体系的に行う。ステップ１１３７５で、イベント管理者の処置を行う。ステップ１１３７５で承認されると、実行はステップ１１３８０に進み、所属をデータベースに格納する。ステップ１１３８５で、プロジェクトオーナーへの通知を体系的に行う。プロセスフロー１１３００のマッピングは、例えば表１４３などのデータベーステーブルに格納する。当業者には、プロセスフロー１１３００は、そのように明示的に図示していないが、双方向でもよいことは認識されるであろう。

他のマスターデータ記録（すなわち、予算、資産、および契約のマスター記録）と異なり、ビジネスイベントは因果関係の要素といえるであろう。そのため、妥当性検査と同時に、従属性のマッピングを採用する。従属性のマッピングは以前にＳＯＷとＳＯＷのマッピングのときに開示したものと同じである。ビジネスイベントは範囲が決まっていない性質であるため、ビジネスエンティティ内で実際に何かが起こると、マスターデータとＳＯＷの統合によってプロジェクトに結合できることになろう。

図１１４は、プロジェクトグループとプロジェクトマスター記録の高レベルの報告サマリーを表す例示的なユーザインターフェースのウエブページを図示する。記録の所属構成は画面を最適化し、プロジェクト作業のユーザに関係するすべての詳細とユーザへのアクセスを提供することを容易にする。当業者には、データ出力画面は簡潔に分かりやすくするために表しているが、関係と時機を表すのに他の画面も提示できるであろうことは認識されるであろう。

図１１５は、前述のプロセスフローに関連して使用できる例示的な支援データベーススキーマを図示する。

プロジェクト開始とＰＣＩＰ／Ｓリスクサマリー報告モデル
業務記録のプロジェクト作業成果物／ＳＯＷ記録への従属性とマッピングの構成の後、プロジェクトは最終的に着手されることになろう。前述した活動は下流の供給者活動の作業伝票の提出を容易にする。伝票プロセスとは、供給者が構成済みバイヤーユーザに作業履行確認要求を提出するプロセスである。この要求は請求可能なイベントと関連することもしないこともある。

図１１６は、図９３のステップ９３５３〜９３５６で大まかに示した問題のある業務記録が特定され、問題のある報告出力を出す伝票プロセスフロー１１６００を図示する。プロセスフロー１１６００はステップ１１６０５から始まる。ステップ１１６０５で、プロジェクト作業を開始する。ステップ１１６１０で、供給者はバイヤーが処理するための作業確認伝票を提出する。ステップ１１６１５で、伝票処理データが一または複数の活動が予想完了日を過ぎていることを明示する。ステップ１１６２０で、システムはＳＯＷオーナーに活動の日付が不適合であることを通知する。

ステップ１１６２５で、バイヤーユーザは、例えばプロジェクトのホームページから、活動／ＳＯＷ状態サマリーに入り、または例えば通知リンクを使って活動の記録に直接進む。ステップ１１６３０で、バイヤーユーザは不適合の活動記録にアクセスする。ステップ１１６３５で、システムはユーザに活動伝票取引のサマリー画面を提示する。ステップ１１６４０で、ユーザインターフェースはユーザに記録の従属性を見るアクティブなコントロールを提示する。ステップ１１６４５で、ユーザはアクティブなコントロールを起動する。ステップ１１６５０で、システムはユーザに、構成した活動と発注書ＳＯＷのマッピング、プロジェクトフェーズのマッピング、関係する発注書ＳＯＷとマスターデータ記録のマッピングのサマリー画面を提示する。ステップ１１６５０で、ユーザは全構成関係を表示できる大きな画像にアクセスする。この画面内には、典型的には問題の活動が所属するＳＯＷ記録に関連する関係の性質に関する情報がある。

ステップ１１６５５で、システムはユーザに発注書ＳＯＷの予想完了日を指定するよう指示する。プロジェクトＳＯＷの所有権レベルでのみ、プロジェクトの実際の実行に関わる個人がこれを行えるであろう。ステップ１１６６０で、ユーザは日付および／または条件の変更を指定する。影響が発注書ＳＯＷに及ぶと判断したら、ユーザは条件または日付のいずれかの修正を設定してもよい。極端な場合には、条件の変更は完全な機能停止または取り消しになるかもしれないし、それほど極端でない場合には、おそらく単なる納期の延長が適切であろう。

ステップ１１６６５で、システムはステップ１１６６０でのユーザ入力に基づいてＰＣＩＰ／Ｓ従属影響度画面を生成する。明示的には表していないが、発注書ＳＯＷの影響が生じない状況や、またはたとえ活動が実際には日付が適合していたとしても、供給者の伝票の提出が遅れてしまった単なる運営上の問題であることもありうるだろう。このような場合には、影響度画面には変の変化もなく、セッションは終了できるであろう。

ステップ１１６７０で、関係する問題のある記録を他のユーザが所有しているかどうかの判断をする。ステップ１１６７０での肯定判断に応答して、実行はステップ１１６７５に進み、バイヤーユーザはシステムに備え付けのリスク記録サマリーを起動する。ステップ１１６８０で、システムはリスク報告出力を出す。ステップ１１６８５で、ユーザはリスク通信セッションを開始するかどうかの選択ができる。

プロセス１１６００では明示的に示していないが、当業者には、関係する発注書ＳＯＷ（またはプロジェクトオーナーが所有する追加の発注書ＳＯＷ）だけに影響が及ぶ状況では、リスクのために行う変更は外部の記録の従属性または関係には影響しないだろうことは認識されるであろう。このような状況では、すべての記録がユーザ制御の入力で更新で
きる一方的な記録修正手順を採用できるであろう。
ＰＣＩＰ／Ｓリスク通信セッション
ステップ１１６８５で、バイヤー・エンティティはこれで、多数の関係するプロジェクトおよびマスター記録に対する潜在的な影響を把握する情報構造を装備したことになる。この情報を所有したからといって悪影響が起こらないというわけではないが、視認性を与えてくれ、正確に使えば、計画する機会を与えてくれる。当業者には、状況を把握した上で最新のビジネス決定を行い、リスク発生源に関する情報を維持するのに必要なデータへの視認性とアクセスをユーザに与えてくれるように、情報を使えることは認識されるであろう。

図１１７〜１１９は、ＰＣＩＰ／Ｓリスク通信セッションのプロセスフロー１１７００〜１１９００を図示し、リスクＳＯＷ記録オーナーパッケージを構成するステップと、そのパッケージを影響を受けるユーザに一斉配信するステップと、影響を受けるユーザの記録データの処理をして、記入した記録セットを発行側のユーザに送り返すステップとを含む。ここで図１１７を参照すると、プロセスフロー１１７００はステップ１１７０５から始まるが、このステップはプロセスフロー１１６００のステップ１１６８５から続いている。ステップ１１７０５で、システムはＰＣＩＰ／Ｓリスク通信セッションを開始する。ステップ１１７０８で、ユーザは初期ＰＣＩＰ／Ｓセッションフォームを完成して、フォームを保存する。ステップ１１７１０で、システムはユーザに影響を受ける全記録の表示を提示する。これらの記録は、例えば、ＳＯＷ、予算、資産、契約、およびビジネスイベントの記録別に集計してもよい。ステップ１１７１５で、システムはユーザに修正した条件および／またはＳＯＷの納期を確認するよう指示する。ステップ１１７２０で、ユーザはセッションの変数入力項目を編集または確認する。ステップ１１７２５で、システムはユーザに所属発注活動の行項目のリスト表示を提示する。ステップ１１７３０で、システムはユーザに修正の必要な行項目を選択するよう指示する。ステップ１１７３５で、ユーザは、例えばチェックボックスで、行項目を選択する。

ステップ１１７４０で、システムは行項目の変数の編集を可能にするユーザインターフェースを提供する。ステップ１１７４５で、ユーザは個別に選択した発注書の行項目活動記録に対して条件または許容変数を修正する。ステップ１１７５０で、ユーザはそれまでに行った設定を保存する。プロジェクト作業活動の編集が完了すると、ユーザはこれらの設定を保存できる。これらの活動記録に計画される修正は、例えば表１４９などのデータベーステーブルに格納する。

ステップ１１７５５で、影響を受ける従属プロジェクトＳＯＷをユーザが所有しているかどうかの判断を行う。ステップ１１７５５で否定の判断がされたら、システムは影響を受ける記録のサマリー画面をリフレッシュして、従属構成と可変データの比較を前提にどの記録が問題があるかを示す。ステップ１１７５５で肯定の判断がされたら、実行はステップ１１７６０に進む。ステップ１１７６０で、システムはユーザに従属ＳＯＷ記録を表示し、それを構成するよう指示する。ステップ１１７６５で、ユーザは影響を受ける従属ＳＯＷ記録を編集する。ステップ１１７７０で、システムはユーザに発注書活動の行項目の所属項目のリスト表示を提示する。ステップ１１７７５で、システムはユーザに修正の必要な行項目を選択するよう指示する。ステップ１１７７５から、実行はステップ１１７７０に戻る。

報告出力がＰＣＩＰ／Ｓセッションをサポートしたら、ユーザは出力レポートに備わるシステムプロンプト／コントロールに応えてＰＣＩＰ／Ｓセッションを開始する。ステップ１１７０８で基本情報入力フォームを完成した後、ステップ１１７１０でシステムは問題のあるまたは失敗したＳＯＷ記録に所属する完全な記録セットの出力画面を出す。初期フォームの記入とその保存は、例えば表１４４などのデータベーステーブルに格納する。

それからユーザはシステムからリスク従属レポートを生成するために当初利用したデータ修正を確認するよう指示される。ステップ１１７２０で、さらにユーザはオリジナルの入力を確認または修正できる。

プロジェクト作業活動はＳＯＷ記録とリンクしているため、システムはユーザにＳＯＷに入れられたすべての活動記録のリスト表示を提示できる。ＳＯＷの変更が見込まれるため、他のプロジェクト作業活動の記録、および因果関係を示す活動の記録を修正する必要があるかもしれない。ステップ１１７３５で、これら活動記録の選択を行う。

選択すると、システムはユーザにそれぞれ個別に選択した記録の編集インターフェースを提示する。編集インターフェースは活動自体によって変わりうる。例えば、人的資源作業割り当てに関する条件および／またはデータフィールドは、例えば材料引渡しなどの別の活動の処理に利用できるものとは異なるのが一般的である。これら記録の修正をステップ１１７４５として示す。

図１１８は、図９３のステップ９３６５で大まかに述べたＰＣＩＰ／Ｓリスク通信セッションのプロセスフロー１１８００を図示する。プロセスフロー１１８００はステップ１１８０５から始まるが、このステップはステップ１１７８０から続く。ステップ１１８０５で、外部所有の記録がサマリー画面に存在するかどうかを判断する。ステップ１１８０５での判断が否定なら、実行はステップ１１８０７に進み、フローはステップ１１８０７の更新に続く。しかし、ステップ１１８０５での判断が肯定なら、実行はステップ１１８１０に進む。ステップ１１８１０で、システムはユーザに、所要の個々のユーザ（オーナー）の記録セットに注釈を付けられるＰＣＩＰ／Ｓ通信パッケージを構成するよう指示する。

ステップ１１８１０から、実行はステップ１１８１５に進み、システムはユーザにビジネスオーナー別に集計した影響を受ける全記録のリスト表示を提示する。ステップ１１８２０で、ユーザは、例えばユーザインターフェースに備わるチェックボックスで、所要のビジネスオーナーを選択する。ステップ１１８２５で、ユーザは選択した記録に対して所要の注釈を記入する。ステップ１１８３０で、ユーザはそれまでに行った入力を保存する。ステップ１１８３５で、ＰＣＩＰ／Ｓの記録の集計を「保存済み」の状態でデータベースに格納する。ステップ１１８４０で、ユーザにＰＣＩＰ／Ｓ通信パッケージを一斉配信したいかどうか選ぶよう指示する。ユーザが通信パッケージを一斉配信する方を選んだら、実行はステップ１１８４５に進み、ユーザは「バイヤーＰＣＩＰ／Ｓパッケージを一斉配信」コントロールを起動する。ステップ１１８５０で、システムはパッケージを構成済みユーザに一斉配信するとともに、典型的にはｅメールおよびシステム転送更新により通知を発行する。

図１１９は、図９３のステップ９３７０に大まかに示した、影響を受けるユーザのＰＣＩＰ／Ｓ情報パッケージの取り扱いを図示する。影響を受けるユーザのＰＣＩＰ／Ｓ情報パッケージの取り扱いに関するプロセスフロー１１９００はステップ１１９０２から始まり、影響を受けるバイヤーユーザはＰＣＩＰ／Ｓ情報コレクションにアクセスする。ステップ１１９０５で、システムはユーザに発行者、配信日、および受信日を含めたＰＣＩＰ／Ｓセッションの詳細のサマリー概要を提示する。ステップ１１９０８で、システムはユーザに影響を受けるビジネス記録にアクセスするコントロールを提示する。明示的には表していないが、バイヤーの選好に従い、他のユーザに所属する影響を受ける他の記録の画面も同様に提示できる。ステップ１１９１０で、ユーザはコントロールを起動する。１１９１０でコントロールを起動すると、実行はステップ１１９１２に進み、システムはユーザに影響を受ける記録および記録の状態のリスト表示を提示する。

ステップ１１９１５で、記録が上流のＳＯＷの処理に従属するかどうかの判断をする。多重連鎖した従属記録セットの可能性があるため、関係ある上流の従属記録が処理されていなければ、離れた下流の記録の処置は非論理的である。ステップ１１９１５で肯定の判断がされたら、実行はステップ１１９１８に進む。ステップ１１９１８で、システムはユーザに従属処理の詳細と該当するビジネスオーナーを提示する。記録は「上流のＳＯＷ処置待ち」の状態をマークして、処理のために非活動状態にする。ステップ１１９１５で、判断が否定であれば、実行はステップ１１９２０に進む。ステップ１１９２０で、ユーザは記録の処理を可能にするコントロールを起動する。ステップ１１９２２で、記録がＳＯＷ記録であるかどうかの判断をする。ステップ１１９２２でそのように判断されたら、実行はステップ１１９２５に進み、ユーザはステップ１１７２５〜１１７７５と同様記録を処理する。

ステップ１１９２５から、実行はステップ１１９２８に進む。ステップ１１９２８で、ユーザはそれまでに行った設定を保存する。ステップ１１９３０で、データベースの記録を更新する。ステップ１１９３２で、下流のＳＯＷ記録のオーナーに必要な処理を通知する。ステップ１１９３５で、下流のＳＯＷ処理を完了するまで続ける。ステップ１１９３８で、ＳＯＷ記録と所属する発注書活動の記録がすべて処理されたかどうかの判断をする。ステップ１１９３８でそのように判断されたら、実行はステップ１１９４０に進む。ステップ１１９４０で、システムはマスターデータ記録のオーナーにＳＯＷの処理が完了したことを通知する。ステップ１１９４２で、マスター記録のオーナーのそれぞれの記録を処理する。構成された条件および／または可変データフィールドの編集もステップ１１９４２で行う。ステップ１１９４２はステップ１１９２２の否定の判断に対しても実行する。

ステップ１１９４２から、実行はステップ１１９４５に進み、ユーザはそれまでに行った設定を保存する。ステップ１１９４８で、データベースの記録を更新する。マスターデータ記録の処置設定は、例えば表１５２などのデータベーステーブルに格納する。表１４７の場合のように、これら記録の設定修正の両方の処理格納手段として、データタイプがＳＱＬバリアント型の複合データフィールド制御可能ＭＤデータ要素を使用する。このフィールドはメタデータの形で設定を格納するエンティティ型である。このデータモデルは、設定変更の保留テーブルを表す個別データベーステーブルを含んでもよい。ただし、当業者はこれが代替データベース処理モードだと分かるであろう。ステップ１１９５０で、マスターデータ記録の更新がすべて完了したかどうかの判断をする。ステップ１１９５０での肯定判断に応答して、実行はステップ１１９５２に進む。この提出はセッションのユーザに体系的な通知を出し、データベース内のＰＣＩＰ／Ｓセッションの状態をレビュー待ちに更新する。明示的には表していないが、システムは典型的にはデータ処理のすべてのフェーズの間妥当性検査を行う。ステップ１１９５２で、システムはセッションの発行者にＰＣＩＰ／Ｓバイヤー返信を生成する。ステップ１１９５５で、システムの通知をユーザに発行する。ステップ１１９６０で、セッションの状態は「レビュー待ち」に変わる。

必ずしもすべての記録を修正するわけではなく、バイヤーの選好の程度により、例えば、必須従属制約仕様を実施しない構成モードや、または例えば、ベストプラクティスの観点から非論理的と思える記録の条件の修正を容易にする構成モードなど、様々な実施例が様々な構成モードで操作できるであろう。典型的にはデータ処理に記録セット全体が利用できるようにされているが、影響を受ける可能性のある記録は、上流の処置順列が完了するまで処理のためにキャッシュしないのが一般的である。このように事前構成は従属性を設定するだけでなく、プロセス内のワークフローを開始および確立する。

明示的には表していないが、記録の修正は、当該記録が供給者のプロジェクト作業活動に直接関係する場合、連携的なプロセスであるのが一般的である。バイヤーとベンダーとの双方向の通信を容易にする入札メッセージボードを、ＰＣＩＰ／Ｓセッションのために構成および実装してもよい。メッセージボードは、バイヤーがプロジェクト作業の活動の条件の修正（例えば、価格、日付、数量、人的資源のアイデンティティ）に関して供給者と連絡をとるために使えるであろう。

図１２０は、ＰＣＩＰ／Ｓ通信セッションを容易にする例示的なデータベーススキーマである。
ＰＣＩＰ／Ｓ供給者承諾パッケージセッション
バイヤーのＰＣＩＰ／Ｓリスク通信セッションの入力を受け取ると、全体的な方法の次のフェーズはＰＣＩＰ／Ｓ修正に影響を受けるあらゆる供給者により取得した入力の発行と処理を扱う。

図１２１は、ＰＣＩＰ／Ｓ承諾パッケージセッションのプロセスフロー１２１００を図示する。プロセスフロー１２１００はステップ１２１０５から始まり、バイヤーユーザにＰＣＩＰ／Ｓが「レビュー待ち」の状態であることを通知する。ステップ１２１１０で、ユーザは、例えばメニューのナビゲーションまたはダッシュボードへのリンクから、ＰＣＩＰ／Ｓモジュールにアクセスする。ステップ１２１１５で、システムはユーザに、具体的な記録の条件と可変データの修正を示すサマリー報告出力を提示する。ステップ１２１２０で、プロジェクト作業の発注書の行項目に対する影響に関する体系的な判断をする。

発注書の行項目の修正が記録セット内に内在すると仮定すると、ステップ１２１２５でシステムは供給者の変更指示の承諾の発行を指示する。ステップ１２１３０で、バイヤーはこの処理の特徴の必要を無視しないと仮定する。備え付けのコントロールを起動すると、ステップ１２１３５でシステムはユーザに供給者別に集計した影響を受ける発注書の記録をまとめた記録の出力を提示する。

ユーザにはＰＣＩＰ／Ｓ供給者承諾パッケージを一斉配信／発行するよう体系的に指示される。ステップ１２１４０で肯定のユーザ動作を仮定すると、システムはユーザにＰＣＩＰ／Ｓ供給者承諾パッケージのメインウエブページを提示する。ステップ１２１５０でユーザは必要な基本入力を記入し、ステップ１２１５５でユーザが設定を保存すると、ステップ１２１６０でシステムはＰＣＩＰ／Ｓ供給者承諾パッケージを該当する供給者に一斉配信して、ステップ１２１６５で取引記録をデータベースに格納する。この処理フェーズ中に利用できるであろう例示的なデータベーステーブルを表１５７〜１６１に示す。

ＰＣＩＰ／Ｓ供給者承諾パッケージを一斉配信すると、ステップ１２１７０で、システムは構成済み供給者ユーザにペンディング中の活動に関する通知を発行する。この時、供給者の許可ユーザにはセッションの記録へのアクセス権が与えられ、備え付けのナビゲーションコントロールを利用して該当するセッションの記録にアクセスする。

図１２２は、図９３のステップ９３７５で大まかに述べたＰＣＩＰ／Ｓ承諾パッケージセッションのプロセスフロー１２２００を図示する。プロセスフロー１２２００はステップ１２２０２から始まる。ステップ１２２０２で、供給者の許可ユーザは、例えば標準的なナビゲーションまたは備え付けのダッシュボードコントロールの起動により、ＰＣＩＰ／Ｓ承諾パッケージにアクセスする。ステップ１２２０５で、ＰＣＩＰ／Ｓ承諾パッケージのメインページが表示される。ステップ１２２０８で、ユーザが備え付けの変更指示コントロールを起動すると、ステップ１２２１０で影響を受けるあらゆる発注書の体系的なサマリー出力が生成される。ステップ１２２１２で、ユーザは処理すべき個々の発注書を選択すると、ステップ１２２１５で影響を受ける発注書の行項目のサマリー出力が生成さ
れる。ステップ１２２１８で、ユーザは処理すべき特定の修正された行項目を選択する。ステップ１２２２０で、システムはユーザに発注書の行項目の詳細を提示して、データフィールドが影響を受けていることを示す。ユーザに活動記録のデータおよび／又は条件の変更を検証するよう指示する。

ステップ１２２２２で、供給者ユーザは記録の修正を検証して、ステップ１２２２５に進み、そこでシステムは、基本構成に基づいて、データの修正に供給者の課税査定が必要かどうかを判断する。肯定応答なら、供給者ユーザは、例えば税務当局、課税最低額、税率等の入力項目からなる必要な課税査定データを記入する。ステップ１２２３０で、ユーザはその入力を保存する。

この検証および課税査定処理は、ステップ１２２３５で発注書の行活動および発注書のすべてを処理して、未処理のまま残っている記録がなくなるまで続ける。ステップ１２２３８で、この時点でユーザにその入力をバイヤー・エンティティに送り返すよう指示する。論理的な選択をすると仮定すると、ステップ１２２４０で供給者ユーザはバイヤー・エンティティに送り返す。次にステップ１２２４２で、システムはバイヤー・エンティティの許可ユーザに通知を発行して、ＰＣＩＰ／Ｓ供給者承諾パッケージの応答を提出済みの状態に更新する。このプロセスフロー１２２００は、そのＰＣＩＰ／Ｓ供給者承諾パッケージに影響を受ける該当の供給者全部について繰り返す。ステップ１２２４８で影響を受ける全供給者の応答が提出されたら、ステップ１２２５０でＰＣＩＰ／Ｓ供給者承諾パッケージの状態は「完了」に更新されて、それによってステップ１２２５２でバイヤー・エンティティの許可ユーザにシステム通知を出す。

図１２３は、ＰＣＩＰ／Ｓシステムの支援データベーススキーマを図示する。当業者には、図１２３の右下の四角で囲んだ部分が、図１２１〜１２２に関して上記述べた表のスキーマの主要部分であることは認識されるであろう。
ＰＣＩＰ／Ｓ記録修正の統合
全供給者のＰＣＩＰ／Ｓ承諾パッケージの応答を受け取ると、残りのフェーズは最終的な記録セットの承認とＰＣＩＰ／Ｓ情報の統合である。

図１２４は、ステップ９３８０〜９３９５で大まかに示したＰＣＩＰ／Ｓ記録承認・統合セッションのプロセスフロー１２４００を図示する。プロセスフロー１２４００はステップ１２４０４から始まり、バイヤーの許可ユーザは、例えば標準的なナビゲーションまたはダッシュボードコントロールから、提出された供給者応答のＰＣＩＰ／Ｓ承諾パッケージにアクセスする。ステップ１２４０８で、ユーザはＰＣＩＰ／Ｓ承諾パッケージのメインページを表示する。ステップ１２４１２で、ユーザは備え付けの変更指示サマリーコントロールを起動する。ステップ１２４１６で、ユーザにプロジェクトに関係する全発注書のサマリーリスト表示が提示される。ステップ１２４２０で、最終的な変更指示の承認が要求される。ステップ１２４２０での要求された承認に応答して、実行はステップ１３４２４に進む。ステップ１２４２４で、ユーザに変更指示承認要求を一斉配信するよう指示する。ステップ１２４２８で、ユーザは備え付けの変更指示承認コントロールを起動する。ステップ１２４３２で、システムは発注書承認要求を一斉配信する。ステップ１２４３６で、影響を受ける発注書記録のオーナーに体系的な通知が発行される。ステップ１２４４０で、発注書の承認がされたかどうかの判断をする。ステップ１２４４０での肯定の判断に応答して、実行はステップ１２４４４に進む。

ステップ１２４４４で、システムは発注書承認通知を、作業範囲記述書に関係するマスターデータ記録のオーナーに一斉配信する。ステップ１２４４８で、マスターデータ記録の修正が行われたかどうかの判断をする。ステップ１２４４８での肯定の判断に応答して、実行はステップ１２４５２に進み、ユーザはマスターデータの記録を更新する。ステッ
プ１２４５６で、ユーザは新規入力設定を保存する。ステップ１２４６０で、ユーザは最終データの設定を承認する。ステップ１２４４８での否定の判断に応答して、実行はステップ１２４６０に進む。

ステップ１２４６０から、実行はステップ１２４６４に進む。ステップ１２４６４で、マスターデータの全記録の処置が行われたかどうかの判断をする。ステップ１２４６４での肯定判断に応答して、実行はステップ１２４６８に進む。ステップ１２４６８で、ＰＣＩＰ／Ｓセッションのオーナーにシステム通知を発行する。ステップ１２４７２で、ＰＣＩＰ／Ｓセッションのオーナーは、利用できるナビゲーションコントロールから承認済みのＰＣＩＰ／Ｓ記録にアクセスする。ステップ１２４７６で、ユーザにプロセス記録を更新するよう指示する。ステップ１２４８０で、記録が更新される。ステップ１２４８４で、システムは日付記録のルーティンを実行する。ステップ１２４８８で、記録の修正をデータベースに格納する。ステップ１２４９２で、影響を受けるＰＣＩＰ／Ｓ記録のオーナーにシステム通知を発行する。

発注書の承認をまず処理するのは、マスターデータ記録が最終承認を得ていない、または不完全なもしくは未承認の発注書のデータに基づいて編集される可能性に備えるためである。

マスターデータの処理は、プロジェクト作業取引データの副次的なものである。マスターデータの編集機能は、供給者承諾パッケージ応答データの設定に影響を受けるおそれのある記録を更新したい場合を想定してのものである。

プロジェクト入札管理システムに関係する分析データを作り出す包括的なウエブベースのコンピュータシステムおよび方法を提供する。入札およびプロジェクトに関係する取引データをオンライン入札、プロジェクト購入申請書、および支払いプロセスからコンピュータシステムに入力する。システム内に格納された取引データを使って、一または複数のバイヤーのために一または複数のベンダーが遂行する一または複数のプロジェクトに関係する実質的にあらゆる種類の分析データを生成できる。

一または複数のプロジェクトおよび一または複数の入札を管理し、取引データを格納するシステムで分析データを作り出す方法は、システム上でオンライン入札プロセスを実施するステップと、オンライン入札プロセス中に取引データの一部として入札データを入札のデータフィールドに入力するステップと、取引データの関数として分析データの要求を受け取るステップと、要求に応答して取引データに基づいて取引データを使った分析データを生成するステップとを含む。

入力するステップは、入札に関連するバイヤーが入札依頼データをデータフィールドに入力するステップと、入札に関連するベンダーが応札データをデータフィールドに入力するステップも含んでもよい。

分析データを作り出す方法は、取引データの一部としてプロジェクトのプロジェクト追跡データを入札に対応するデータフィールドに入力するステップと、取引データの一部として伝票情報をプロジェクトに対応するデータフィールドに入力するステップと、取引データの一部としてプロジェクト遂行データをプロジェクトに対応するデータフィールドに入力するステップも含んでもよい。この方法はまた、プロジェクトの遂行中、バイヤーおよびベンダーによるプロジェクト遂行データをシステムに入力するステップを含んでもよい。

方法は、少なくともプロジェクト追跡パラメータを使ってプロジェクト遂行データを自
動的に生成するステップも含んでもよい。この方法はさらに、プロジェクト追跡パラメータを伝票情報と比較して、プロジェクトの状態を判断するステップと、プロジェクトの状態をプロジェクトの遂行データとしてシステムに自動的に入力するステップを含んでもよい。

生成するステップは、プロジェクト追跡パラメータを探索して、プロジェクトの作業時間状態を判断するステップと、プロジェクトの作業時間状態をプロジェクト遂行データとしてシステムに自動的に入力するステップを含んでもよい。

プロジェクト追跡パラメータを入力するステップは、プロジェクトの課税要素と各課税要素に対応する税額を識別する課税情報を入力するステップを含んでもよい。

受け取るステップは、一または複数のフィルタを含む分析データの要求を受け取るステップと、一または複数のフィルタを使ってフィルタリングした取引データを得る取引データをフィルタリングするステップを含んでもよく、フィルタリングした取引データを使って分析データを生成する。

一または複数のフィルタを含む要求を受け取るステップは、一または複数の種類の取引データの関数として分析データの要求を受け取るステップを含んでもよく、一または複数のフィルタは一または複数の種類の取引データをフィルタリングする。

一または複数のフィルタは、ベンダープロファイルプロパティ、バイヤープロファイルプロパティ、プロジェクトプロファイルプロパティ、および原材料プロファイルプロパティのうちの少なくとも１つに関係付けることができる。

分析データを作り出す方法は、分析データをウエブページ上のプロジェクト報告画面に提示するステップも含んでもよい。プロジェクト報告画面はプロジェクト報告の種類のものでもよく、プロジェクト報告の種類は財務種類、プロジェクト種類、原材料の種類、またはベンダー／人的資源の種類のうちのどれかである。

生成するステップは、複数のプロジェクトに関連する取引データを集計して分析データを生成するステップを含んでもよい。集計するステップは、各プロジェクトに関係する取引データの関数として統計データを計算するステップと、複数のプロジェクトにわたる統計データを集計するステップを含んでもよい。集計するステップは、複数のベンダーが遂行する複数のプロジェクトに関連する取引データを集計して、分析データを生成するステップも含んでもよい。この集計するステップは、複数のバイヤーに関連する取引データを集計して、分析データを生成するステップも含んでもよい。

生成するステップは、複数のプロジェクトに関連する取引データを使って統計データを計算して、分析データを生成するステップを含んでもよい。計算するステップは、複数のバイヤーに関連する取引データを使って統計データを計算して、分析データを生成するステップを含んでもよい。

分析データを作り出す方法は、バイヤー、ベンダー、または管理者の入札およびプロジェクトに関係する個々の取引データを、それぞれバイヤー、ベンダー、または管理者のデータベースシステムに格納するステップと、データベースシステムに格納される取引データの少なくとも一部を、複数のデータベースシステムからの複数の取引データを格納する中央データベースに転送するステップとを含み、分析データは複数の取引データから生成する。

一または複数のプロジェクトと一または複数の入札を管理するシステムに関係する分析データを作り出すコンピュータシステムは、取引データの関数として分析データの要求を受け取るために接続されるウエブベースのインターフェースと、少なくとも入札データを含む取引データを維持するデータベースシステムであって、入札データをウエブベースのインターフェースを介して前記データベースシステムに格納される入札のデータフィールドに入力する、前記データベースシステムと、前記ウエブベースのインターフェースに接続して要求を受け取り、前記データベースシステムに接続して要求に基づいて取引データを検索するサーバで、前記サーバが要求に応答して検索した取引データに基づいて分析データを生成するよう作動できる、前記サーバとを含む。

データベースシステムは、前記ウエブベースのインターフェースを介して、入札に関連するバイヤーがデータフィールドに入力した入札依頼データを含む入札データと、入札に関連するベンダーがデータフィールドに入力した応札データを格納できる。データベースシステムは、少なくとも入札データ、前記ウエブベースのインターフェースを介して、プロジェクトに関連するバイヤーおよびベンダーが入札に関連するデータフィールドに入力したプロジェクトのプロジェクト追跡パラメータ、前記ウエブベースのインターフェースを介してバイヤーおよびベンダーが入札とプロジェクトに関連するデータフィールドに入力した伝票情報、入札およびプロジェクトに関連するデータフィールドに格納するプロジェクト遂行データを含む取引データも格納できる。データベースシステムは、プロジェクトの課税要素および各課税要素に関連する税額を識別する課税情報を含むプロジェクト追跡パラメータも格納できる。

サーバは一または複数のフィルタを含む要求を受け取り、一または複数のフィルタを使って取引データをフィルタリングしてフィルタリングした取引データを得るようにも作動でき、フィルタリングした取引データを使って分析データを生成する。一または複数のフィルタは、ベンダープロファイルプロパティ、バイヤープロファイルプロパティ、プロジェクトプロファイルプロパティ、および原材料プロファイルプロパティのうちの少なくとも１つに関係付けてもよい。

サーバはさらに、前記ウエブベースのインターフェースを介して、ウエブページ上のプロジェクト報告画面に分析データを提示するように作動できるようにしてもよい。プロジェクト報告画面はプロジェクト報告の種類のものでもよく、プロジェクト報告の種類は、財務種類、プロジェクト種類、またはベンダー／人的資本の種類のうちのどれかである。

サーバは複数のプロジェクトに関連する取引データを集計して、分析データを生成するように作動できるようにしてもよい。サーバは各プロジェクトに関係する取引データの関数として統計データを計算し、複数のプロジェクトにわたる統計データを集計するように作動できるようにしてもよい。サーバは、複数のベンダーが遂行する複数のプロジェクトに関連する取引データを集計して、分析データを生成するように作動できるようにしてもよい。サーバはまた、複数のバイヤーに関連する取引データを集計して、分析データを生成するように作動できるようにしてもよい。

サーバは、複数のプロジェクトに関連する取引データを使って統計データを計算して、分析データを生成するように作動できるようにしてもよい。サーバはまた、複数のバイヤーに関連する取引データを使って統計データを計算して、分析データを生成するように作動できるようにしてもよい。

データベースシステムは、バイヤー、ベンダー、または管理者の入札およびプロジェクトに関係する個別の取引データを格納するように構成してもよく、データベースシステムに格納した取引データの少なくとも一部を受け取るために、前記データベースシステムに
接続する中央データベースを含んでもよく、前記中央データベースは複数のデータベースシステムからの複数の取引データを格納し、分析データを複数の取引データから生成する。

コンピュータ実行可能な命令を格納し、一または複数のプロジェクトおよび一または複数の入札を管理するシステムに関係付けるコンピュータ読み取り可能媒体において、これらコンピュータ実行可能命令は、少なくとも入札データを含む取引データの関数として分析データの要求を受け取る手段で、入札データがオンライン入札プロセス中にデータベースシステムに格納される入札のデータフィールドに入力される、前記受け取る手段と、要求に基づいて取引データを検索するためにデータベースシステムにアクセスする手段と、要求に応答して検索した取引データに基づいて分析データを生成する手段とを含んでもよい。

プロジェクトを管理し、取引データを格納するシステムで分析データを作り出す方法が、取引データの一部としてプロジェクト遂行データを各プロジェクトに関連するデータフィールドに入力するステップと、取引データの関数として分析データの要求を受け取るステップと、要求に基づいて取引データを集計して、集計プロジェクト遂行データを生成するステップとを含んでもよい。

方法は、取引データの一部としてプロジェクトのプロジェクト追跡パラメータをプロジェクトに関連するデータフィールドに入力するステップと、取引データの一部として伝票情報を、少なくとも１つのバイヤーと少なくとも１つのベンダーのプロジェクトに関連するデータフィールドに入力するステップとを含んでもよい。

方法は、プロジェクトの遂行中、少なくとも１つのバイヤーと少なくとも１つのベンダーによるプロジェクト遂行データをプロジェクト入札管理システムに入力するステップを含んでもよい。方法はまた、少なくとも１つのプロジェクト追跡パラメータを使って、プロジェクト遂行データを自動的に生成するステップを含んでもよい。

生成するステップは、プロジェクトうちのある所定のもののプロジェクト追跡パラメータを所定のプロジェクトの伝票情報と比較して、所定のプロジェクトの状態を判断するステップと、所定のプロジェクトの状態をプロジェクト遂行データとしてシステムに自動的に入力するステップを含んでもよい。

生成するステップは、プロジェクト追跡パラメータを探索して、プロジェクトの作業時間状態情報を判断するステップと、作業時間状態情報をプロジェクト遂行データとしてシステムに自動的に入力するステップを含んでもよい。

受け取るステップは、一または複数のフィルタを含む分析データの要求を受け取るステップと、一または複数のフィルタを使って取引データをフィルタリングして、フィルタリングした取引データを得るステップを含んでもよく、フィルタリングした取引データを使って分析データを生成する。

一または複数のフィルタは、ベンダープロファイルプロパティ、バイヤープロファイルプロパティ、プロジェクトプロファイルプロパティ、および原材料プロファイルプロパティのうちの少なくとも１つに関係付けてもよい。

方法は、ウエブページ上のプロジェクト報告画面に分析データを提示するステップを含んでもよい。プロジェクト報告画面はプロジェクト報告の種類のものでもよく、プロジェクト報告の種類は、財務種類、プロジェクト種類、またはベンダー／人的資本の種類のうちのどれかである。

集計するステップは、各プロジェクトに関係する取引データの関数として統計データを計算するステップと、プロジェクト全体にわたり統計データを集計するステップも含んでもよい。

集計するステップは、複数のベンダーが遂行するプロジェクトに関連する取引データを集計して、分析データを生成するステップも含んでもよい。

集計するステップは、複数のバイヤーに関連する取引データを集計して、分析データを生成するステップも含んでもよい。格納するステップは、バイヤー、ベンダー、または管理者の入札およびプロジェクトに関係する個々の取引データを、それぞれバイヤー、ベンダー、または管理者のデータベースシステムに格納するステップと、データベースシステムに格納した取引データの少なくとも一部を、複数のデータベースシステムからの複数の取引データを格納する中央データベースに転送するステップを含んでもよく、分析データは複数の取引データから生成する。

一または複数の入札および一または複数のプロジェクトを管理し、取引データを格納するシステムで分析データを作り出す方法は、オンライン入札プロセス中に取引データの一部として入札データの構成要素を入札のデータフィールドに入力するステップと、取引データの一部としてプロジェクトに関連するプロジェクト追跡パラメータの構成要素を、入札に関連するデータフィールドに入力するステップと、取引データの一部としてプロジェクト遂行データの構成要素を、プロジェクトに関連するデータフィールドに入力するステップと、取引データの一または複数の構成要素の関数として分析データの要求を受け取るステップと、要求に応答して取引データに基づいて分析データを生成するステップを含む。

複数のバイヤーが委託する複数の入札および複数のプロジェクトを管理し、複数のプロジェクトに関係する取引データを格納するシステムで分析データを作り出す方法は、取引データの関数として業界分析データの要求を受け取るステップで、取引データがプロジェクトに関連する一または複数のベンダーによるプロジェクトの遂行を示す少なくともプロジェクト遂行データを含む、前記受け取るステップと、要求に基づいて取引データにアクセスするステップと、要求に応答してアクセスした取引データに基づいて分析データを生成するステップとを含む。

本方法は、バイヤー、ベンダー、または管理者の入札およびプロジェクトに関係する個々の取引データを、それぞれバイヤー、ベンダー、または管理者のデータベースシステムに格納するステップと、データベースシステムに格納した取引データの少なくとも一部を、複数のデータベースシステムからの複数の取引データを格納する中央データベースに転送するステップとを含んでもよく、分析データは複数の取引データから生成する。

プロジェクトを管理し、取引データを格納するシステムで課税額情報を作り出す方法は、取引データの一部として課税情報をプロジェクトに関連するデータフィールドに入力するステップと、取引データの一部として伝票情報をプロジェクトに関連するデータフィールドに入力するステップと、課税情報に基づいて、伝票情報に関連する課税額を生成するステップとを含む。本方法は、承認のためにプロジェクトに関連するバイヤーおよびベン
ダーに課税額を提示するステップを含んでもよい。

当業者には、本明細書で述べたシステムおよび方法論に加えて、本発明は前述の特徴および機能を実装するために使用できるコンピュータ・データベース、ソフトウェア・アプリケーション、プログラム、プロトコル、ルーチン、および命令（集合的に、「コンピュータプログラミング命令」という）に向けられていることは認識されるであろう。コンピュータプログラミング命令はメモリ内に格納することが好ましいが、通信インターフェースを介して受信または送信してもよい。

当業者には認識されるであろうが、本出願に述べる革新的な概念は幅広い範囲のアプリケーションで修正または変更できる。従って、特許を求める主題の範囲は論じたそのままの例示的な教唆のいずれかにも制限されるものではなく、以下の請求項によって定義される。
≪表の簡単な説明≫
データベース表１〜１１２に加えて、本発明の様々な実施例を添付のデータベース表を参照しながら説明する。

表１１３は、バイヤー・エンティティが利用するプロジェクトグループのアイデンティティと一般的なビジネスデータを入れる例示的な記憶表である。

表１１４は、バイヤー・エンティティが利用するプロジェクトマスター記録のアイデンティティと一般的なビジネスデータを入れる例示的な記憶表である。

表１１４Ａは、プロジェクトグループ内に含まれるプロジェクト間の関係を入れる例示的な記憶表である。

表１１５は、プロジェクトグループ内のプロジェクト間の関係を定義するために使うそれぞれの値を入れる例示的な記憶表である。

表１１６は、バイヤー・エンティティ内で利用する原価中心点、別名、部署に適用されるアイデンティティと基本属性を入れる例示的な記憶表である。

表１１７は、原価中心点とプロジェクトとのマッピング関係を入れる例示的な記憶表である。

表１１８は、バイヤー・エンティティが利用する予算グループのアイデンティティと一般的なビジネスデータを入れる例示的な記憶表である。

表１１９はバイヤー・エンティティが利用する予算マスター記録のアイデンティティと一般的なビジネスデータを入れる例示的な記憶表である。

表１２０は、プロジェクトと予算との所属関係を入れる例示的な記憶表である。

表１２１は、バイヤー・エンティティが利用するビジネスイベントのアイデンティティと一般的なビジネスデータを入れる例示的な記憶表である。

表１２２は、プロジェクトとビジネスイベントとの所属関係を入れる例示的な記憶表である。

表１２３は、バイヤー・エンティティが利用する契約記録のアイデンティティと一般的
なビジネスデータを入れる例示的な記憶表である。

表１２４は、プロジェクトと契約との所属関係を入れる例示的な記憶表である。

表１２５は、バイヤー・エンティティが利用する資産グループのアイデンティティと一般的なビジネスデータを入れる例示的な記憶表である。

表１２６は、バイヤー・エンティティが利用する資産マスター記録のアイデンティティと一般的なビジネスデータを入れる例示的な記憶表である。

表１２７は、プロジェクトと資産との所属関係を入れる例示的な記憶表である。

表１２８は、プロジェクトとＲＦｘ入札とのマッピング関係を入れる例示的な記憶表である。

表１２９は、プロジェクトと発注申請書とのマッピング関係を入れる例示的な記憶表である。

表１３０は、供給者発注書に関連するアイデンティティと属性を入れる例示的な記憶表である。

表１３１は、バイヤー発注書に関連するアイデンティティと基本属性を入れる例示的な記憶表である。

表１３２は、バイヤー発注書行に関連するアイデンティティと基本属性を入れる例示的な記憶表である。

表１３３は、バイヤー発注書行に記載されるプロジェクト作業活動に関連するアイデンティティと属性を入れる例示的な記憶表である。

表１３４は、バイヤーＰＯ作業範囲記述書（ＳＯＷ）記録に関連するアイデンティティと属性を入れる例示的な記憶表である。

表１３５は、発注書およびＳＯＷ記録に含まれるプロジェクト作業活動間のマッピング関係を入れる例示的な記憶表である。

表１３６は、プロジェクトフェーズ区分記録に関連するアイデンティティと属性を入れる例示的な記憶表である。

表１３７は、プロジェクトフェーズ区分記録とＳＯＷ記録とのマッピング関係を入れる例示的な記憶表である。

表１３８は、ＳＯＷ記録間に適用される従属性マッピング関係を入れる例示的な記憶表である。

表１３９は、利用するＳＯＷとＳＯＷ記録との従属の種類の値を入れる例示的な記憶表である。

表１４０は、ＳＯＷ記録と予算とのマッピング関係を入れる例示的な記憶表である。

表１４１は、ＳＯＷ記録と資産とのマッピング関係を入れる例示的な記憶表である。

表１４２は、ＳＯＷ記録と契約とのマッピング関係を入れる例示的な記憶表である。

表１４３は、ＳＯＷ記録とビジネスイベントとのマッピング関係を入れる例示的な記憶表である。

表１４４は、バイヤーＰＣＩＰ／Ｓリスクセッションに関連するアイデンティティと属性を入れる例示的な記憶表である。

表１４５は、利用するＰＣＩＰ／Ｓリスクセッション状態コードに適用される値を入れる例示的な記憶表である。

表１４６は、利用するＰＣＩＰ／Ｓリスクセッション種類コードに適用される値を入れる例示的な記憶表である。

表１４７は、ＰＣＩＰ／Ｓセッション内に含まれるＳＯＷ記録に適用されるアイデンティティと属性を入れる例示的な記憶表である。

表１４８は、ＰＣＩＰ／Ｓセッション中にバイヤーユーザの応答状態に適用される値を入れる例示的な記憶表である。

表１４９は、ＰＣＩＰ／Ｓセッション中にプロジェクト作業発注活動記録に行われる状態または可変データの修正を入れる例示的な記憶表である。

表１５０は、ＰＣＩＰ／Ｓセッション中に作成される新規プロジェクト作業活動に適用されるアイデンティティと属性を入れる例示的な記憶表である。

表１５１は、利用するプロジェクト作業活動の可変データフィールドを定義する値を入れる例示的な記憶表である。

表１５２は、利用する可変データフィールドの修正アクションを定義する値を入れる例示的な記憶表である。

表１５３は、ＰＣＩＰ／Ｓセッション中にマスターデータ記録に行われる可変データの修正を入れる例示的な記憶表である。

表１５４は、利用するマスターデータの可変データフィールドの修正の種類を定義する値を入れる例示的な記憶表である。

表１５５は、利用するマスターデータの可変データフィールドの修正アクションを定義する値を入れる例示的な記憶表である。

表１５６は、バイヤーＰＣＩＰ／Ｓ供給者承認パッケージセッションに関連するアイデンティティと属性を入れる例示的な記憶表である。

表１５７は、利用するＰＣＩＰ／Ｓ供給者承認パッケージセッション状態コードに適用される値を入れる例示的な記憶表である。

表１５８は、ＰＣＩＰ／Ｓ供給者承認パッケージセッションに所属する供給者一斉配信
／投稿記録に適用されるアイデンティティと属性を入れる例示的な記憶表である。

表１５９は、利用するＰＣＩＰ／Ｓ供給者承認パッケージセッション応答状態コードに適用される値を入れる例示的な記憶表である。

表１６０は、ＰＣＩＰ／Ｓ供給者承認パッケージセッション中に処理する記録に関係する供給者データの検証と課税査定応答を入れる例示的な記憶表である。

表１６１は、ＰＣＩＰ／Ｓ供給者承認パッケージセッション中に処理する新規活動記録に関係する供給者データ提供、データ検証、および課税査定応答を入れる例示的な記憶表である。

本発明に関わるプロジェクト作業入札プロセスの高次機能図である。本発明のコンピュータシステムのネットワーク図である。バイヤーのネットワークで実施される本発明のコンピュータシステムの代替ネットワーク図である。本発明のコンピュータシステムの物理的なネットワーク・アーキテクチャを図示する。本発明のコンピュータシステムの物理的なネットワーク・アーキテクチャを図示する。図２Ａおよび２Ｂに図示するユーザ・モジュールの各々に関連付けられる例示的なホーム・ウエブページである。図２Ａおよび２Ｂに図示するユーザ・モジュールの各々に関連付けられる例示的なホーム・ウエブページである。図２Ａおよび２Ｂに図示するユーザ・モジュールの各々に関連付けられる例示的なホーム・ウエブページである。図２Ａおよび２Ｂに図示するユーザ・モジュールの各々に関連付けられる例示的なホーム・ウエブページである。本発明の実施例によるプロジェクト作業入札プロセスに参加するための例示的なステップを図示するフローチャートである。本発明の実施例により、ベンダーが提供するおよび／またはバイヤーが依頼するプロジェクト作業の種類を定義し、バイヤーに適したベンダーの資格審査をするベンダー資格審査プロセスの電子化促進法を図示する。本発明の実施例により、バイヤーに適したベンダーの資格審査をする例示的なステップを図示するフローチャートである。入札依頼書に対する応答に伴う情報処理と、情報処理に責任を負う様々なユーザ役割を図示する。本発明の実施例により、プロジェクト作業プロセスに関わる様々なリソースを定義して割り当てる例示的なステップを図示するフローチャートである。本発明の実施例により、ユーザ役割の定義および割り当てを図示するデータベース表である。ユーザ役割へのリソース割り当ての例示的な画面である。本発明の実施例により、入札またはプロジェクト取引中にユーザ役割を定義し割り当てる例示的なステップを図示するフローチャートである。本発明の実施例により、ユーザ役割に基づき入札またはプロジェクト取引に関係するワークフローを管理する例示的なステップを図示するフローチャートである。本発明の実施例により、ユーザ役割に基づき入札またはプロジェクト取引に関係するワークフローを管理する例示的なステップを図示するフローチャートである。本発明の実施例により、ユーザ役割分担を修正する例示的なステップを図示するフローチャートである。本発明の実施例により、入札テンプレート作成ツールとあるプロジェクトの入札依頼書を生成する入札依頼書作成ツールを図示するデータフロー図である。入札テンプレート、入札テンプレートからの入札依頼書、および入札依頼書からの応札書を作成する例示的なステップを図示するフローチャートである。入札テンプレート、入札テンプレートからの入札依頼書、および入札依頼書からの応札書を作成する例示的なステップを図示するフローチャートである。入札テンプレート、入札テンプレートからの入札依頼書、および入札依頼書からの応札書を作成する例示的なステップを図示するフローチャートである。入札テンプレート、入札テンプレートからの入札依頼書、および入札依頼書からの応札書を作成する例示的なステップを図示するフローチャートである。入札テンプレートを作成できる階層的な入札項目リストを図示するデータベース表である。階層的な入札項目リストにアクセスして入札テンプレートを作成する例示的なステップを図示するフローチャートである。入札テンプレートの作成を図示する画面である。本発明の実施例により、入札テンプレートを利用して入札依頼書を生成する例示的なステップを図示するフローチャートである。そこから選択して入札テンプレートの種類の入札に含めることのできる特定の入札テンプレートに対応付けられる様々な種類の入札項目を図示する画面である。そこから選択して入札テンプレートの種類の入札に含めることのできる特定の入札テンプレートに対応付けられる様々な種類の入札項目を図示する画面である。入札依頼書の適格ベンダーへの通信を管理する例示的なステップを図示するフローチャートである。入札依頼書を受け取る適格ベンダーの選定を図示する画面である。本発明の実施例により、ベンダー応札プロセスの例示的なステップを図示するフローチャートである。ベンダー応札プロセスを図示する画面である。ベンダー応札プロセスを図示する画面である。ベンダー応札プロセスを図示する画面である。ベンダー応札プロセスを図示する画面である。本発明の実施例により、入札依頼書とベンダー応札書データとの相関関係を図示するデータベース表である。バイヤーに提供される様々な入札処理の特徴を図示する画面である。本発明の実施例により、ベンダー応札書等級格付けの電子化促進法を図示するデータフロー図である。本発明の実施例により、ベンダー応札書を等級格付けする例示的なステップを図示するフローチャートである。本発明の実施例により、ベンダー応札書を等級格付けする例示的なステップを図示するフローチャートである。サンプルの応札書等級格付けプロセスを図示する画面である。サンプルの応札書等級格付けプロセスを図示する画面である。サンプルの応札書等級格付けプロセスを図示する画面である。サンプルの応札書等級格付けプロセスを図示する画面である。サンプルの応札書等級格付けプロセスを図示する画面である。本発明の実施例により、入札依頼書、ベンダー応札書、ベンダー応札書等級格付けの相関関係を図示するデータベース表である。本発明の実施例により、ベンダー応札書等級格付けに基づくベンダー再見積もりプロセスを図示するフローチャートである。本発明の実施例により、プロジェクトをベンダーに決定し、プロジェクトの条件を最終決定して、マイルストーンおよび成果物を追跡するコンピュータシステムに入力するプロジェクト運営のセットアッププロセスの例示的なステップを図示するフローチャートである。本発明の実施例により、プロジェクトに割り当てたリソースの承認のための例示的なステップを図示するフローチャートである。例示的なバイヤーのプロジェクト運営の特徴を図示する画面である。例示的なベンダーのプロジェクト運営の特徴を図示する画面である。例示的なプロジェクト課税情報を入力するためのインターフェースを図示する画面である。入力したプロジェクト課税情報を含む例示的な必須情報を図示する画面である。プロジェクト課税情報を入力し処理するための例示的なステップを図示するフローチャートである。本発明のコンピュータシステムが取り扱う様々なプロジェクト運営の構成要素を図示するデータベース表である。本発明のコンピュータシステムが管理できる責任問題の種類を図示する画面である。本発明の実施例により、プロジェクト請負人の作業時間を入力するための例示的なステップを図示するフローチャートである。サンプルの作業時間記録プロセスを図示する画面である。サンプルの作業時間記録プロセスを図示する画面である。サンプルの作業時間記録プロセスを図示する画面である。本発明の実施例により、プロジェクトの成果物および伝票作成の追跡を図示するデータベース表である。本発明の実施例により、支払伝票を提出及び承認し、支払伝票を作成するための支払伝票作成プロセスの電子化促進法を図示する。本発明の実施例により、伝票支払いプロセスを図示するフローチャートである。本発明の実施例により、支払伝票の生成を図示するデータベース表である。プロジェクト財務データを図示する画面である。情報の分析を容易にするためにバイヤー、ベンダー、およびシステム間での情報交換を図示するフロー図である。本発明の実施例により、プロジェクトの遂行に関連するプロジェクト遂行データをシステムに入力するための例示的な機能を図示する。プロジェクト遂行データを入力するための例示的なステップを図示するフローチャートである。プロジェクト遂行データを入力するための例示的なステップを図示するフローチャートである。プロジェクト遂行データを入力するための例示的なステップを図示するフローチャートである。本発明の実施例により、プロジェクト遂行データの格納を図示するデータベース表である。本発明のデータベースシステム内に格納する入札／プロジェクトのプロセスに関連する例示的な取引データを図示する。取引データを複数のバイヤーのデータベースから中央データベースに転送する例を図示する。本発明の実施例により、取引データの分析および報告の電子化促進法を図示する。本発明の実施例により、取引データを分析し、分析データを提示するための例示的なステップを図示するフローチャートである。本発明の実施例により、取引データを分析し、分析データを提示するための例示的なステップを図示するフローチャートである。本発明の実施例により、取引データを分析し、分析データを提示するための例示的なステップを図示するフローチャートである。本発明の実施例により、取引データを分析し、分析データを提示するための例示的なステップを図示するフローチャートである。本発明の実施例により、取引データを分析し、分析データを提示するための例示的なステップを図示するフローチャートである。本発明の実施例により、取引データを分析し、分析データを提示するための例示的なステップを図示するフローチャートである。本発明の実施例により、取引データを分析し、分析データを提示するための例示的なステップを図示するフローチャートである。本発明の実施例により、取引データをフィルタリングして、フィルタリングした取引データに関連する分析データを提示するフィルタリング・プロセスの電子化促進法を図示する。本発明の実施例により、取引データをフィルタリングして、フィルタリングした取引データから分析データを生成するための例示的なステップを図示するフローチャートである。分析データを生成し表示するための例示的なプロジェクト報告の種類を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。それぞれが分析データを含めた例示的なプロジェクト報告画面を図示する画面である。プロジェクト作業および計画または範囲に適用される変更に関連する複雑な企業活動ダイナミクスの画面である。ビジネスアプリケーション処理環境を表した図である。プロジェクト作業運営管理プロセスに参加するための例示的なステップを図示するフローチャートである。必須調達機能に依存せずにＰＣＩＰ／Ｓソリューションに参加するための例示的なステップを図示するフローチャートである。本発明の様々な実施例で採用される全体的なＰＣＩＰ／Ｓビジネス方法論を表すプロセスフロー図である。プロジェクトグループ記録の作成を表すプロセスフロー図である。プロジェクトマスター記録の作成を表すプロセスフロー図である。予算グループ記録の作成を表すプロセスフロー図である。予算マスター記録の作成を表すプロセスフロー図である。資産グループ記録の作成を表すプロセスフロー図である。資産マスター記録の作成を表すプロセスフロー図である。契約マスター記録の作成を表すプロセスフロー図である。ビジネスイベント記録の作成を表すプロセスフロー図である。プロジェクトマスター記録を他のマスターデータ成分にマッピングするステップを表すプロセスフロー図である。バイヤーであるユーザのための例示的なプロジェクト運営ホームページのユーザインターフェースを図示する。事前調達データの取得、格納、および構成活動をサポートする例示的なイネーブリングデータベーススキーマを図示する。プロジェクトマスター記録をＲＦＸ入札プロセスに統合する変型プロセスワークフローである。プロジェクトマスター記録のプロジェクト作業取引データへの統合をサポートする変型データベーススキーマである。発明の原理における作業範囲記述書ダイナミクス（ＳＯＷ）の図である。プロジェクト運営ホームページからユーザナビゲーションおよび記録の選択によりアクセスする例示的なバイヤーユーザのプロジェクトマスターウエブページである。プロジェクト作業と成果物／ＳＯＷ記録との所属関係を表す例示的なプロセスワークフロー図である。プロジェクトフェーズ区分記録の作成を表す例示的なプロセスフロー図である。発注書ＳＯＷ記録をプロジェクトフェーズ区分記録に所属／マッピングするステップを表す例示的なプロセスフロー図である。ＳＯＷ記録とＳＯＷ記録との連携および従属構成を表す例示的なプロセスフロー図である。ＳＯＷ記録と予算記録との所属関係を表す例示的なプロセスフロー図である。ＳＯＷ記録と資産記録との所属関係を表す例示的なプロセスフロー図である。ＳＯＷ記録と契約記録との所属関係を表す例示的なプロセスフロー図である。ＳＯＷ記録とビジネスイベント記録との所属関係を表す例示的なプロセスフロー図である。プロジェクトグループおよびプロジェクトマスター記録の報告サマリーを表す例示的なユーザインターフェースのウエブページである。ＳＯＷ記録の構成をサポートする例示的なデータベーススキーマである。プロジェクト作業取引データを処理および追跡したデータを使って、問題のある従属ＳＯＷおよび所属するマスターデータ記録に関係する結果を報告する例示的なプロセスフロー図である。ＰＣＩＰ／Ｓリスク通信セッションを表す例示的なプロセスワークフロー図である。ＰＣＩＰ／Ｓリスク通信セッションを表す例示的なプロセスワークフロー図である。ＰＣＩＰ／Ｓリスク通信セッションを表す例示的なプロセスワークフロー図である。ＰＣＩＰ／Ｓリスク通信セッションをサポートする例示的なデータベーススキーマである。ＰＣＩＰ／Ｓ供給者承諾パッケージを表す例示的なプロセスワークフロー図である。ＰＣＩＰ／Ｓ供給者承諾パッケージを表す例示的なプロセスワークフロー図である。ＰＣＩＰ／Ｓ供給者承諾パッケージをサポートするデータベーススキーマを統合した図１２０の拡張図である。ＰＣＩＰ／Ｓ記録の承認および統合セッションのプロセスフローを図示する。

Claims

バイヤーから、プロジェクト運営構成を受け取るステップと、
供給者がバイヤーのために遂行するプロジェクト作業に関するプロジェクト作業取引データを格納するステップと、
バイヤーから、プロジェクト作業範囲記述書（ＳＯＷ）記録の構成を受け取るステップと、
バイヤーのプロジェクト計画／範囲変更記録セットを処理するステップと、
供給者のプロジェクト計画／範囲変更記録セットを処理するステップと、
バイヤーの記録セットと供給者の記録セットを使って、統合プロジェクト計画／範囲変更記録セットを作成するステップと、
を有するプロジェクト作業運営管理方法。
プロジェクト運営構成が、
プロジェクト記録セットと、
予算記録セットと、
資産記録セットと、
契約マスター記録と、
プロジェクト以外のビジネスイベント記録とを有し、
プロジェクト記録セット、予算記録セット、および資産記録セットのうちの少なくとも１つが複数の層状の記録を有する、請求項１の方法。
プロジェクト作業取引データを格納するステップが、
バイヤー発行のＲＦｘ入札を供給者に提出するステップと、
供給者のＲＦｘ応札書を提出するステップと、
供給者のＲＦｘ応札書のバイヤーの承認を受け取るステップと、
バイヤーが承認した供給者のＲＦｘ応札書の要素に基づいて、少なくとも１つの発注書を生成するステップと、
提供されるプロジェクト作業のサービスに対して、供給者作業確認伝票をバイヤーに提出するステップと、
供給者作業確認伝票のバイヤー処置を受け取るステップと、
承認済みの供給者作業確認伝票の財務処理を行うステップと、
を有する、請求項１の方法。
ＲＦｘ入札項目を利用してプロジェクト作業活動を設定するステップをさらに有する、請求項３の方法。
ＲＦｘ入札項目を利用してプロジェクト作業活動を設定するステップが、
人的資源の割り当てと、
人的資源の労働の種類と
人的資源の賃率の種類と
人的資源の経費の種類と、
材料と、
その他プロジェクト経費と、
セット価格／出来高払いの成果物と、
固定価格の成果物と、
少なくとも１つの成果物のＲＦｘ入札項目の種類の利用を有し、
取引データオブジェクトのうちの少なくとも１つに対してデータを取得して処理するようになされたＲＦｘ入札項目を利用するステップを有する、請求項４の方法。
バイヤーのＲＦｘ入札に対する供給者の応答が、
ＲＦｘ入札項目に該当するデータと、
少なくとも１つの成果物のプロジェクト作業活動に該当するデータを有する、請求項３の方法。
供給者のＲＦｘ応札書に対するバイヤーの承認が、
バイヤーのプロジェクト作業活動に該当する供給者のＲＦｘ応札書要素の承認と、
少なくとも１つの成果物のプロジェクト作業活動を有する供給者のＲＦｘ応札書要素の承認とを有する、請求項３の方法。
少なくとも１つの発注書を生成するステップが、承認済みの供給者ＲＦｘ応札書要素のデータを発注書に統合するステップを有する、請求項３の方法。
承認済みのＲＦｘ応札書要素のデータを発注書に統合するステップが、
発注書を作成するステップと、
発注書の行を設定するステップと、
ＲＦｘ応札書要素のデータを発注書行に所属させて、プロジェクト作業取引データを設定するステップとを有する、請求項８の方法。
プロジェクトＳＯＷ記録の構成が、
発注書の成果物記録をＳＯＷ記録として指定するステップと、
成果物アウトプットの作業活動に所属させた非納入プロジェクト作業活動を有する発注書行項目の構成と、
プロジェクトフェーズの構成と、
ＳＯＷ記録の従属性の構成と、
ＳＯＷ記録マスターデータの所属の構成とを有する、請求項１の方法。
バイヤーのプロジェクト計画／範囲変更記録セットを処理するステップが、
プロジェクトＳＯＷ従属性およびマスター記録の所属の出力を生成するステップで、
プロジェクトを企業全体の連結性に関して記述する、前記生成するステップと、
プロジェクトリスク通信パッケージを一斉配信するステップと、
プロジェクトリスク通信パッケージの応答を受け取るステップと、
プロジェクトリスク通信パッケージの応答を処理するステップとを有する、請求項１の方法。
供給者のプロジェクト計画／範囲変更記録セットを処理するステップが、
プロジェクト計画／範囲変更承諾パッケージを作成するステップと、
プロジェクト計画／範囲変更承諾パッケージを一斉配信するステップと、
一斉配信されたプロジェクト計画／範囲変更承諾パッケージを処理するステップと、
一斉配信されたプロジェクト計画／範囲変更承諾パッケージの完了を受け取るステップとを有する、請求項１の方法。
統合プロジェクト計画／範囲変更記録セットを作成するステップが、
少なくとも１つのプロジェクト計画／範囲変更の変更指示を受け取るステップと、
少なくとも１つのプロジェクト計画／範囲変更の変更指示を処理するステップと、
少なくとも１つのプロジェクト計画／範囲変更の変更指示の承認に応じて、少なくとも１つのマスターデータ記録を処理するステップと、
少なくとも１つの処理したマスターデータ記録を更新するステップとを有する、請求項１の方法。
プロジェクトポートフォリオ記録セットを作成するステップと、
予算ポートフォリオ記録セットを作成するステップと、
資産ポートフォリオ記録セットを作成するステップと、
契約マスター記録を作成するステップと、
プロジェクト以外のビジネスイベント記録を作成するステップとを有する、
プロジェクト作業ポートフォリオ運営記録セットの作成方法。
プロジェクトポートフォリオ記録セットを作成するステップが、
プロジェクトグループ属性、バイヤー組織、ビジネス所有権責任データを格納するようになされたプロジェクトグループ記録を作成するステップと、
バイヤープロジェクトデータを格納するようになされた少なくとも１つのプロジェクトマスター記録を作成するステップと、
プロジェクトグループ記録と少なくとも１つのプロジェクトマスター記録との対応付けを格納するステップと、
プロジェクトグループ内に所属する少なくとも１つのプロジェクトマスター記録間の適用される従属関係を格納するステップと、
プロジェクトマスターに適用されるデフォルトのバイヤー組織データとビジネス所有権データをデフォルトのプロジェクトグループデータの制約として格納するステップとを有する、請求項１４の方法。
予算ポートフォリオ記録セットを作成するステップが、
バイヤー組織、ビジネス所有権責任、および財務データを格納するようになされた予算グループ記録を作成するステップと、
バイヤー予算データを格納するようになされた少なくとも１つの予算マスター記録を作成するステップと、
予算グループ記録と少なくとも１つの予算マスター記録との対応付けを格納するステップと、
予算マスター記録に適用されるデフォルトのバイヤー組織データ、ビジネス所有権データ、および財務データをデフォルトの予算グループデータの制約として格納するステップとをさらに有する、請求項１４の方法。
資産ポートフォリオ記録セットを作成するステップが、
バイヤー組織、ビジネス所有権責任、および財務データを格納するようになされた資産グループ記録を作成するステップと、
バイヤー資産データを格納するようになされた少なくとも１つの資産マスター記録を作成するステップと、
資産グループ記録と少なくとも１つの資産マスター記録との対応関係を格納するステップと、
資産マスターに適用されるデフォルトのバイヤー組織データ、ビジネス所有権データ、および財務データを資産グループデータの制約として格納するステップとをさらに有する、請求項１４の方法。
契約マスター記録を作成するステップが、
バイヤーの契約に適用されるバイヤー組織データ、ビジネス所有権責任データ、財務データ、および契約データを格納するようになされた契約マスター記録を作成するステップをさらに有する、請求項１４の方法。
バイヤー組織データ、ビジネス所有権責任データ、およびビジネスイベントデータを格納するようになされた少なくとも１つのプロジェクト外ビジネスイベント記録を作成するステップをさらに有する、請求項１４の方法。
少なくとも１つのプロジェクトマスター記録を作成するステップが、
少なくとも１つのプロジェクトマスター記録の各々を少なくとも１つの予算マスター記録に所属させるステップと、
少なくとも１つのプロジェクトマスター記録の各々を少なくとも１つの資産マスター記録に所属させるステップと、
少なくとも１つのプロジェクトマスター記録の各々を少なくとも１つの契約マスター記録に所属させるステップと、
少なくとも１つのプロジェクトマスター記録の各々を少なくとも１つのビジネスイベントマスター記録に所属させるステップのうち、
少なくとも１つをさらに有する、請求項１５の方法。
非納入プロジェクト作業活動の発注書行項目を少なくとも１つの発注書行の成果物種類の記録に対応付けるステップと、
発注書成果物記録に応じた属性データを指定するステップと、
少なくとも１つのプロジェクト作業フェーズ区分記録を作成するステップと、
少なくとも１つのプロジェクトフェーズ区分記録に応じた属性データを指定するステップと、
発注書成果物記録の従属性を構成するステップと、
マスターデータ記録への発注書成果物記録の所属を構成するステップとを有する
プロジェクトＳＯＷ成果物記録を構成する方法。
少なくとも１つのプロジェクト作業フェーズ区分記録を作成するステップが、少なくとも１つのプロジェクトフェーズ区分記録をマスタープロジェクト記録に所属させるステップを有する、請求項２１の方法。
少なくとも１つのプロジェクトフェーズ区分記録を作成するステップが、発注書成果物記録を少なくとも１つのプロジェクトフェーズ区分記録に所属させるステップを有する、請求項２１の方法。
発注書成果物記録の従属性を構成するステップが、プロジェクト内の発注書成果物記録同士の関係を確立するステップを有する、請求項２１の方法。
プロジェクト内の発注書成果物記録同士の関係を確立するステップが、
関係し合う発注書成果物記録間の従属性関係の種類を指定するステップと、
下流の従属発注書成果物記録の完了状態が、関係する発注書成果物記録の完了状態によって制約されるかどうかを指定するステップとを有する、請求項２４の方法。
発注書成果物記録の従属性を構成する方法が、プロジェクトグループ内の複数のプロジェクトの発注書成果物記録同士の関係を確立するステップを有する、請求項２１の方法。
複数のプロジェクト内の発注書成果物記録同士の関係を確立するステップが、
関係し合う発注書成果物記録の従属関係の種類を指定するステップと、
下流の従属発注書成果物記録の完了状態が、関係する発注書成果物記録の完了状態によって制約されるかどうかを指定するステップとを有する、請求項２６の方法。
マスターデータ記録への発注書成果物記録の所属を構成するステップが、
発注書成果物記録を、プロジェクトマスター記録にマッピングされた少なくとも１つの予算マスター記録に所属させるステップと、
少なくとも１つの材料記録を含む発注書成果物記録を、プロジェクトマスター記録にマ
ッピングされた少なくとも１つの資産マスター記録に所属させるステップと、
発注書成果物記録を、プロジェクトマスター記録にマッピングされた少なくとも１つの契約マスター記録に所属させるステップと、
発注書成果物記録を、プロジェクトマスター記録にマッピングされた少なくとも１つのビジネスイベントマスター記録に所属させるステップのうち、
少なくとも１つを有する、請求項２１の方法。
マスターデータ記録への発注書成果物記録の所属を構成するステップが、
発注書成果物記録とマスターデータ記録の所属関係に適用される属性データを指定するステップと、
発注書成果物記録とマスターデータ記録の所属関係の責任を有するバイヤーの要員を指定するステップとを有する、請求項２８の方法。
構成した発注書成果物記録とマスターデータ記録の所属関係、およびＳＯＷ記録の従属性をデータベースに格納するステップと、
発注書成果物記録とマスターデータ記録のバイヤー責任者に、データベースに格納した発注書成果物記録の所属関係を通知するステップと、
通知を受けたバイヤー責任者に、それぞれの記録の所属の詳細へのアクセス権を提供するステップとをさらに有する、請求項２９の方法。
供給者提出のプロジェクト作業確認伝票のバイヤー処置に応じて、
プロジェクト成果物従属性とマスター記録の所属分析を行うステップと、
予定完了日に適合しない発注書成果物ＳＯＷ記録を特定するステップと、
少なくとも１つの不適合成果物記録の選択を受け取るステップと、
プロジェクトリスク通信セッションを生成するステップと、
プロジェクトリスク通信パッケージを一斉配信するステップと、
プロジェクトリスク通信パッケージ応答を受け取るステップと、
プロジェクトリスク通信パッケージ応答を処理するステップと、
を有するプロジェクト計画／範囲変更を評価する方法。
少なくとも１つの不適合成果物記録の選択に応じて、
選択した不適合成果物記録に所属し影響を受ける可能性のある成果物記録およびマスターデータ記録を含む問題のある成果物の出力を生成するステップと、
選択した不適合成果物記録に所属し問題のある成果物記録を特定するステップと、特定した問題のある成果物記録の状態または完了日の修正を受け取るステップとをさらに有する、請求項３１の方法。
修正に応じて、
問題のある成果物記録に影響を受けるマスターデータ記録および成果物記録の更新モデルを生成するステップと、
問題のある成果物記録に影響を受ける成果物記録のバイヤー責任者を特定するステップと、
リスク通信セッションを開始するステップとをさらに有する、請求項３２の方法。
プロジェクトリスク通信セッションを生成するステップが、
プロジェクトリスク通信セッションの記録セットを作成するステップと、
プロジェクトリスク通信セッションのオーナーによって、少なくとも１つの不適合成果物記録に所属する発注書プロジェクト作業活動の行項目へのアクセス権を提供するステップと、
発注書プロジェクト作業活動の行項目の修正に応じて設定を格納するステップとを有す
る、請求項３１の方法。
格納するステップに応じて、バイヤー要員の責任別に集計した影響を受けるビジネス記録を、プロジェクトリスク通信セッションのオーナーに提示するステップをさらに有し、ユーザが影響を受ける要員に一斉配信を出すようになされた、請求項３４の方法。
プロジェクトリスク通信パッケージ応答を処理するステップが、
成果物記録の上流または下流の従属性を表示するステップと、
所属する成果物記録の状態を表示するステップと、
成果物記録の修正を可能にするステップと、
マスターデータ記録の修正を可能にするステップとを有する、請求項３１の方法。
成果物記録の修正を格納するステップをさらに有する、請求項３６の方法。
成果物記録の修正を格納するステップに応じて、
従属成果物記録に対して成果物完了日の妥当性を検査するステップと、
所属する成果物記録の完了日の不一致がないことに応じて、バイヤー要員に妥当性検査の合格通知を提示するステップと、
プロジェクトリスク通信パッケージ応答状態コードを完了に更新するステップとをさらに有する、請求項３７の方法。
成果物完了日の妥当性を検査するステップに応じて、
少なくとも１つの影響を受ける成果物記録の完了日の不一致に応じて、妥当性検査不合格通知を提示するステップと、
プロジェクトリスク通信パッケージの応答状態コードを不一致に更新するステップと、
不一致のある特定の影響を受ける成果物記録の詳細を表示するステップと、
不一致のある記録の詳細をユーザ入力に応じて修正するステップとをさらに有する、請求項３７の方法。
プロジェクトリスク通信パッケージの応答状態コードを完了に更新するステップに応じて、プロジェクトリスク通信パッケージの応答記録の更新をプロジェクトリスク通信セッションのオーナーに提出するよう指示するステップをさらに有する、請求項３８の方法。
プロジェクトリスク通信パッケージの応答記録の更新をプロジェクトリスク通信セッションのオーナーに提出したことに応じて、全プロジェクトリスク通信パッケージの応答の完了状態の妥当性を検査するステップと、
通信パッケージの応答記録の更新が発注書の変更を含んだかどうかを判断するステップと、
下流の成果物記録のオーナーに、提出されたプロジェクト問題のある通信応答を通知するステップとをさらに有する、請求項４０の方法。
全通信パッケージ応答の完了状態の妥当性を検査するステップに応じて、プロジェクトリスク通信セッションの状態コードをレビュー待ちに設定するステップをさらに有する、請求項４１の方法。
通信パッケージ応答内に発注書の行項目の修正がないことに応じて、
プロジェクトリスク通信セッションのオーナーに、成果物記録の修正とマスターデータ記録の修正をアクティブな企業データに統合できるようになされたユーザインターフェースを提供するステップと、
アクティブな企業データを、プロジェクトリスク通信セッションオーナーの動作に応じ
た成果物記録の修正とマスターデータ記録の修正で更新するステップとをさらに有する、請求項４２の方法。
プロジェクト計画／範囲変更承諾パッケージを作成するステップと、
プロジェクト計画／範囲変更承諾パッケージを一斉配信するステップと、
一斉配信されたプロジェクト計画／範囲変更承諾パッケージを完了まで処理するステップと、
完了して一斉配信されたプロジェクト計画／範囲変更承諾パッケージを提示するステップとを有する、プロジェクト計画／範囲変更の処理方法。
プロジェクト計画／範囲変更承諾パッケージを作成するステップが、
属性情報を格納するようになされたプロジェクト計画／範囲変更承諾パッケージ記録を作成するステップと、
計画／範囲変更承諾パッケージ記録にオープンな状態コードを割り当てるステップとを有する、請求項４４の方法。
プロジェクト計画／範囲変更承諾パッケージを一斉配信するステップが、
供給者の責任別に集計した影響を受ける発注書記録を提示するステップと、
承諾パッケージを一斉配信するようになされたユーザインターフェースを提供するステップとを有する、請求項４４の方法。
一斉配信したプロジェクト計画／範囲変更承諾パッケージを処理するステップが、
供給者の担当者にペンディング中のプロジェクト計画／範囲変更承諾パッケージデータの処理を通知するステップを有し、
所定の供給者の要員にとってのデータ処理が、その供給者の要員の個別の影響を受ける発注書行項目の記録セットに制限される、請求項４４の方法。
一斉配信した受取りに対してプロジェクト計画／範囲変更承諾パッケージを処理するステップが、
供給者の要員に、影響を受ける発注書行項目の記録を提示するステップと、
影響を受ける発注書行項目の記録の供給者の要員による承認を受け取るステップと、
記録の承認に応じて承認取引を格納するステップとを有する、請求項４４の方法。
一斉配信したプロジェクト計画／範囲変更承諾パッケージを完了まで処理するステップが、
少なくとも１つの影響を受ける発注書行項目の記録に、供給者の課税査定が必要かどうかを判断するステップと、
少なくとも１つの影響を受ける発注書行項目の記録に供給者の課税査定が必要だとの判断に応じて、課税査定データを格納するステップと、
影響を受ける全発注書行項目の記録の課税査定データが格納されたとの判断に応じて完了を示すように、プロジェクト計画／範囲変更承諾パッケージの状態コードを更新するステップとを有する、請求項４８の方法。
完了して一斉配信したプロジェクト計画／範囲変更承諾パッケージを提示するステップが、
バイヤーのプロジェクト計画／範囲変更セッションのオーナーに、プロジェクト計画／範囲変更パッケージの応答を通知するステップと、
発注書行項目記録の関連するバイヤー要員記録オーナーに、プロジェクト計画／範囲変更承諾パッケージ応答を通知するステップと、
プロジェクト計画／範囲変更承諾パッケージ応答の状態の妥当性を検査するステップと
を有する、請求項４４の方法。
妥当性検査するステップが、
バイヤーのプロジェクト計画／範囲変更セッションオーナーに、プロジェクト計画／範囲変更承諾パッケージ応答の完了を通知するステップと、
プロジェクト計画／範囲変更承諾パッケージの状態を承認を示すように修正するステップとを有する、請求項５０の方法。
少なくとも１つのプロジェクト計画／範囲変更の変更指示を作成するステップと、
少なくとも１つのプロジェクト計画／範囲変更の変更指示を処理するステップと、
少なくとも１つのプロジェクト計画／範囲変更の変更指示の承認に応じて、少なくとも１つのマスターデータ記録を処理するステップと、
処理した少なくとも１つのマスターデータ記録を更新するステップと、
全プロジェクト計画／範囲変更記録の修正を起動するステップとを有する、
統合プロジェクト計画／範囲変更記録セットを作成する方法。
少なくとも１つのプロジェクト計画／範囲変更の変更指示を作成するステップが、
修正したプロジェクト作業発注書記録をバイヤー責任者記録オーナー別に集計するステップと、
変更指示承認要求を開始するステップと、
変更指示承認要求を一斉配信するステップとを有する、請求項５２の方法。
変更指示の承認要求を一斉配信するステップが、
発注書記録オーナーであるバイヤー責任者にペンディング中の変更指示承認要求を通知するステップと、
発注書記録オーナーであるバイヤー責任者の入力に応じて、変更指示承認要求を処理するステップとを有し、
あるバイヤー要員について、バイヤー要員の変更指示承認処理が、そのバイヤー要員が担当記録オーナーである発注書記録に制限する、請求項５３の方法。
変更指示の承認要求を処理するステップが、
変更指示承認要求の状態を承認を示すように修正するステップと、
変更指示承認要求の取引をデータベースに格納するステップと、
バイヤーのプロジェクト計画／範囲変更セッションのオーナーに、変更指示の承認を通知するステップとを有する、請求項５４の方法。
少なくとも１つのマスターデータ記録を処理するステップが、
バイヤーのプロジェクト計画／範囲変更セッションのオーナーに、所属承認済み変更指示に所属し、該当するバイヤー要員の記録オーナー別に集計したプロジェクトマスターデータ記録を提示するステップと、
承認済み変更指示に所属するプロジェクトマスターデータ記録のバイヤー責任者に、所属するプロジェクトマスターデータ記録が追加処理に利用できる旨の通知を発行するステップとを有する、請求項５２の方法。
承認済み変更指示に所属するマスターデータ記録のバイヤー責任者に通知を発行するステップが、
バイヤー要員に、マスターデータ記録に修正が行えるようになされたユーザインターフェースを提供するステップと、
記録の修正に対して入力設定を格納するステップとを有する、請求項５６の方法。
記録の修正に応じて入力設定を格納するステップに応じて、
バイヤーのセッションオーナーに、保存されたマスターデータ記録の入力設定を通知するステップと、
全変更指示に所属する全マスターデータ記録が格納されているかどうかを判断するステップと、
プロジェクト計画／範囲変更のセッションの状態を、全変更指示に所属する全マスターデータ記録の格納に応じてさらに統合を行う必要があることを示すように修正するステップとをさらに有する、請求項５７の方法。
起動するステップが、
記録の修正がアクティブになる更新手順を行うステップと、
更新手順に応じて記録の修正をアクティブな企業データとして格納するステップと、
バイヤーの要員に記録の修正を通知するステップとを有する、請求項５２の方法。
供給者がバイヤーのために遂行するプロジェクト作業に関係するプロジェクト運営構成とプロジェクト作業取引データを受け取るようになされたインターフェースと、
受け取ったプロジェクト運営構成とプロジェクト作業の取引データを格納するデータベースシステムと、
インターフェースに接続するとともに、データベースシステムに接続するサーバとを有し、
サーバが、
予定完了日に対して不適合なプロジェクト作業取引データの発注書成果物データを判断するようになされ、
判断に応じて、プロジェクト作業取引データとプロジェクト運営構成を使って、プロジェクトリスク通信セッションを生成するようになされ、
プロジェクトリスク通信パッケージ応答を処理するようになされた、
プロジェクト作業運営のためのコンピュータシステム。
少なくとも１つのコンピュータ読み取り可能媒体と、
少なくとも１つのコンピュータ読み取り可能媒体に内蔵されるプロセッサ命令とを有し、
プロセッサ命令が少なくとも１つのプロセッサにより少なくとも１つのコンピュータ読み取り可能媒体から読取可能なように構成され、それによって少なくとも１つのプロセッサに、
バイヤーから、プロジェクト運営構成を受け取るように動作させ、
供給者がバイヤーのために遂行するプロジェクト作業に関するプロジェクト作業取引データを格納するように動作させ、
バイヤーから、プロジェクト作業範囲記述書（ＳＯＷ）記録の構成を受け取るように動作させ、
バイヤーのプロジェクト計画／範囲変更記録セットを処理するように動作させ、
供給者のプロジェクト計画／範囲変更記録セットを処理するように動作させ、
バイヤーの記録セットおよび供給者の記録セットを使って、統合プロジェクト計画／範囲変更記録セットを作成するように動作させる、
プロジェクト作業運営管理の製造物。