(57)【要約】  アウトソーシングされたサービスレベルアグリーメント（ＳＬＡ）デリバラブルのマネジメント方法は、ＳＬＡクライアントおよびセカンダリＳＬＡプロバイダのマスタデータを設定するステップと、セカンダリＳＬＡプロバイダプロビジョンサービスネットワークを調達するステップと、セカンダリＳＬＡプロバイダヒューマンリソースネットワークを管理するステップと、ＳＬＡクライアントプロビジョニング要件を処理するステップと、ＳＬＡプロビジョニングサービスバウチャーを処理するステップと、そしてＳＬＡプロビジョニングワークオーダーの支払いを処理するステップと、を含む。本要約の提供は、情報検索者または他の読者による迅速な技術開示首題の確認を可能とするために要約を義務付けた規定に準拠するものである。本要約は、本願請求項の範囲または意味を解釈または限定するために用いられるものではないという理解に基づいて提出するものである。
2009503733.tif 000002
【特許請求の範囲】
【請求項１】
アウトソーシングしたサービスレベルアグリーメント（ＳＬＡ）デリバラブルのマネジメント方法であって、
ＳＬＡクライアントおよびセカンダリＳＬＡプロバイダのマスタデータを設定するステップと、
セカンダリＳＬＡプロバイダプロビジョンサービスネットワークを調達するステップと、
セカンダリＳＬＡプロバイダヒューマンリソースネットワークを管理するステップと、
ＳＬＡクライアントプロビジョニング要件を処理するステップと、
ＳＬＡプロビジョニングサービスバウチャーを処理するステップと、
ＳＬＡプロビジョニングワークオーダーの支払いを処理するステップと
を含む方法。
【請求項２】
ＳＬＡクライアントおよびセカンダリＳＬＡプロバイダのマスタデータを設定するステップは、
ＳＬＡプロビジョンロジスティクスコントロールライブラリを設定するステップと、
ＳＬＡクライアントマスタデータレコードを設定するステップと、
ＳＬＡクライアントパーチャスオーダーレコードを設定するステップと、
セカンダリＳＬＡプロバイダネットワークを採用するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
セカンダリＳＬＡプロバイダプロビジョンサービスネットワークを調達するステップは、
１つ以上のＳＬＡクライアントプロビジョニングディテールレコードからＲＦｘビッドを生成するステップと、
前記ＲＦｘビッドをセカンダリＳＬＡプロバイダの事前設定リストへと公示するステップと、
前記ＲＦｘビッドの受信に応えてセカンダリＳＬＡプロバイダがＲＦｘビッド応答を生成することができるようにするステップと、
１つ以上のセカンダリＳＬＡプロバイダＲＦｘビッド応答を処理するステップと、
ＲＦｘビッド応答の受信に応えて、１つ以上のセカンダリＳＬＡプロバイダパーチャス要請を処理するステップと、
完成したパーチャス要請の受信に応えて１つ以上のセカンダリＳＬＡプロバイダパーチャスオーダーを処理するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項４】
セカンダリＳＬＡプロバイダヒューマンリソースネットワークを管理するステップは、
セカンダリＳＬＡプロバイダパーチャスオーダーにアフィリエイトする１人以上のヒューマンリソースサブミッタルを選択するステップと、
前記１人以上のヒューマンリソースプロビジョニング要員を採用するステップと、
前記１人以上のヒューマンリソースプロビジョニング要員のデフォルトワークアベラビリティカレンダ情報設定を処理するステップと、
非デフォルトのヒューマンリソースプロビジョニングアベラビリティカレンダの管理をイネーブルするステップと、
非デフォルトのワークアベラビリティカレンダ情報の設定を処理するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項５】
ＳＬＡクライアントプロビジョニング要件を処理するステップは、
ＳＬＡクライアントサービスプロビジョンリクエストを処理するステップと、
サービスプロビジョンディスパッチリクエストを処理するステップと、
プロビジョンヒューマンリソースディスパッチ通知レコードを処理するステップと、
受けたプロビジョニングヒューマンリソースディスパッチ通知レコードを処理するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項６】
ＳＬＡプロビジョニングワークバウチャーを処理するステップは、
プロビジョニングヒューマンリソースによる入力に応えて、ＳＬＡプロビジョニングサービスバウチャーを作成し、格納するステップと、
前記格納されたＳＬＡプロビジョニングサービスバウチャーを適切なセカンダリＳＬＡプロバイダのユーザーにより処理するステップと、
適切なプライマリＳＬＡプロバイダのユーザーによる入力に応えて、前記承認されたセカンダリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップと、
適切なＳＬＡクライアントのユーザーによる入力に応えて、前記承認されたプライマリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項７】
ＳＬＡプロビジョニングワークオーダーの支払いを処理するステップは、
ＳＬＡクライアントに承認されたプロビジョニングワークバウチャーを抽出するステップと、
請求明細書ファイルを生成するステップと、
ＳＬＡクライアント請求明細書ファイルを処理するステップと、
ＳＬＡクライアントからの支払いを処理するステップと、
セカンダリＳＬＡプロバイダへの支払いを実施するステップとを含む
ことを特徴とする請求項１に記載の方法。
【請求項８】
サービスレベルアグリーメント（ＳＬＡ）クライアントおよびセカンダリＳＬＡプロバイダのマスタデータを設定する方法であって、
ＳＬＡプロビジョンロジスティクスコントロールライブラリを設定するステップと、
ＳＬＡクライアントマスタデータレコードを設定するステップと、
ＳＬＡクライアントパーチャスオーダーレコードを設定するステップと、
セカンダリＳＬＡプロバイダネットワークを採用するステップと
を含む方法。
【請求項９】
ＳＬＡプロビジョンロジスティクスコントロールライブラリを設定するステップは、
プライマリＳＬＡプロバイダにより提供されるプロビジョニングサービスに適用可能な１つ以上の指定されたＳＬＡプロビジョンスキルプロフィールを受けるステップと、
前記プライマリＳＬＡプロバイダにより提供されるプロビジョニングサービスに適用可能な１つ以上の指定されたＳＬＡプロビジョンタイプを受けるステップと、
前記プライマリＳＬＡプロバイダにより提供されるプロビジョニングサービスに適用可能な１つ以上の指定されたＳＬＡプロビジョンレーバータイプを受けるステップと、
前記プライマリＳＬＡプロバイダにより提供されるプロビジョニングサービスに適用可能な１つ以上の指定されたＳＬＡプロビジョンレーバー応答時間増分値を受けるステップと、
必要に応じて、前記プライマリＳＬＡプロバイダにより提供されるプロビジョニングサービスに適用可能な指定されたＳＬＡプロビジョンマテリアルレコードを受けるステップとのうち、１つ以上を含む
ことを特徴とする請求項８に記載の方法。
【請求項１０】
ＳＬＡクライアントマスタデータレコードを設定するステップは、
１つ以上のＳＬＡクライアントに適用可能な、指定された一般ビジネス情報設定を受けるステップと、
１人以上のＳＬＡクライアントのユーザーに適用可能な設定を受けるステップと、
１つ以上のＳＬＡクライアントロケーションに適用可能な設定を受けるステップと、
１つ以上のＳＬＡクライアントプロビジョニングコントラクトに適用可能な設定を受けるステップと、
ここで前記プライマリＳＬＡプロバイダが前記コントラクトの当事者であることを特徴とし、
１つ以上のＳＬＡクライアントプロビジョニングディテールレコードに適用可能な設定を受けるステップと、
１つ以上のＳＬＡクライアントプロビジョニングパーチャスオーダーに適用可能な設定を受けるステップとを含む
ことを特徴とする請求項８に記載の方法。
【請求項１１】
１人以上のＳＬＡクライアントのユーザーに適用可能な設定を受けるステップは、
ユーザーロケーションおよびコントラクトディテールを特定する設定を受けるステップと、
ユーザートランザクション認可ディテールを指定する設定を受けるステップと、
ユーザーシステムアクセス信用証明を指定する設定を受けるステップとのうち、１つ以上を含む
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
１つ以上のＳＬＡクライアントロケーションに適用可能な設定を受けるステップは、
非従業員労働者のアクセスおよび認可ディテールを指定する設定を受けるステップと、
貨物輸送のディテールを指定する設定を受けるステップと、
構築されたリレーショナルデータベースの形態でロケーション説明を指定する設定を受けるステップとのうち、１つ以上を含み、
前記１つ以上のＳＬＡクライアントロケーションは、
プライマリＳＬＡプロバイダに採用された地理的マネジメントスキーマへと論理的にマッピングさる
ことを特徴とする請求項１０に記載の方法。
【請求項１３】
１つ以上のＳＬＡクライアントコントラクトに適用可能な設定を受けるステップは、
コントラクトの有効化および継続期間のディテールを指定する設定を受けるステップと、
コントラクトの支払い、報奨金、およびペナルティのディテールを指定する設定を受けるステップと、
コントラクトのプロビジョニングサービス数を指定する設定を受けるステップとのうち、１つ以上を含む
ことを特徴とする請求項１０に記載の方法。
【請求項１４】
１つ以上のＳＬＡクライアントプロビジョニングディテールレコードに適用可能な設定を受けるステップは、
１人以上のプライマリＳＬＡプロバイダのユーザーとのアフィリエーションを指定する設定を受けるステップと、
１つ以上のＳＬＡクライアントユーザーとのアフィリエーションを指定する設定を受けるステップと、
１つ以上のＳＬＡクライアントコントラクトとのアフィリエーションを指定する設定を受けるステップと、
１つ以上のＳＬＡプロビジョンスキルプロフィールとのアフィリエーションを指定する設定を受けるステップと、
１つ以上のＳＬＡプロビジョンタイプとのアフィリエーションを指定する設定を受けるステップと、
１つ以上のＳＬＡプロビジョンレーバータイプとのアフィリエーションを指定する設定を受けるステップと、
１つ以上のＳＬＡプロビジョンレーバー応答時間増分値とのアフィリエーションを指定する設定を受けるステップと、
１つ以上のＳＬＡクライアントプロビジョンロケーションとのアフィリエーションを指定する設定を受けるステップと、
所要のプロビジョンカバレッジ期間に関わるディテールを指定する設定を受けるステップと、
関連するプロビジョンマテリアルに関わるディテールを指定する設定を受けるステップとのうち、１つ以上を含む
ことを特徴とする請求項１０に記載の方法。
【請求項１５】
ＳＬＡクライアントパーチャスオーダーレコードを設定するステップは、
ＳＬＡクライアントパーチャスオーダーヘッダディテールを指定する設定を受けるステップと、
１つ以上のＳＬＡクライアントプロビジョニングディテールレコードとのアフィリエーションを指定する設定を受けるステップと、
前記ＳＬＡクライアントプロビジョニングマテリアルレコードの設定を受けたことに応えて、ＳＬＡクライアントプロビジョニングマテリアルレコードとのアフィリエーションを指定する設定を受けるステップと、
ＳＬＡクライアントパーチャスオーダーおよびＳＬＡクライアントプロビジョニングディテールレコードのアフィリエーションを格納するステップとを含む
ことを特徴とする請求項８に記載の方法。
【請求項１６】
ＳＬＡクライアントパーチャスオーダーおよびＳＬＡクライアントプロビジョニングディテールレコードのアフィリエーションの格納に応えて、１つ以上のＳＬＡクライアントパーチャスオーダーの設定を構成するステップをさらに含み、
ここでＳＬＡクライアントパーチャスオーダーおよびＳＬＡクライアントプロビジョニングディテールレコードのアフィリエーションの格納に応えて、１つ以上のＳＬＡクライアントパーチャスオーダーの設定を構成するステップは、
ＳＬＡクライアントパーチャスオーダー価格設定ディテールを指定する設定を受けるステップと、
適用可能なＳＬＡクライアントパーチャスオーダー非プロビジョニングペナルティ費用ディテールを指定する設定を受けるステップと、
適用可能なＳＬＡクライアントパーチャスオーダー日付ディテールを指定する設定を受けるステップと、
受けたＳＬＡクライアントパーチャスオーダー指定をパーチャスオーダー行項目として格納するステップと、
完成したＳＬＡクライアントパーチャスオーダーを承認するステップと、
適切なＳＬＡクライアントのユーザーに完成したパーチャスオーダートランザクションについて通知するステップと、
設定したとおりのＳＬＡクライアントパーチャスオーダーおよび関連するマスタデータレコードへのユーザーアクセスを提供するステップとを含む
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
セカンダリＳＬＡプロバイダネットワークを採用するステップは、
管理された一時的システムアクセスをセカンダリＳＬＡプロバイダに提供するステップと、
セカンダリＳＬＡプロバイダビジネス認定情報を指定する設定を受けるステップと、
受けた特定のビジネス認定情報に応えてセカンダリＳＬＡプロバイダ認定ステータスを決定するステップと、
条件を満たす認定レビューに応えて、
条件を満たす認定レビューに応えてセカンダリＳＬＡプロバイダに管理された非一時的システムアクセスを提供するステップと、
セカンダリＳＬＡプロバイダサービスプロビジョン能力および関連するサービスプロビジョン地理的テリトリを指定する設定を受けるステップとを含む
ことを特徴とする請求項８に記載の方法。
【請求項１８】
セカンダリＳＬＡプロバイダサービスプロビジョン能力を指定する設定を受けるステップは、
選択されたＳＬＡサービスプロビジョン能力を受けるステップであって、リレーショナルデータベースを介してユーザースキルプロフィール選択が提示されると、非文章ベースのＳＬＡプロビジョンスキルファミリプロフィールが得られることを特徴とするステップと、
構築されたリレーショナルデータベースの形態でスキルファミリプロフィールロケーションカバレッジテリトリを指定する設定を受けるステップであって、プライマリＳＬＡプロバイダが採用した地理的マネジメントスキーマへとテリトリが論理的にマッピングされることを特徴とするステップとを含む
ことを特徴とする請求項１７に記載の方法。
【請求項１９】
セカンダリサービスレベルアグリーメント（ＳＬＡ）プロバイダプロビジョンサービスネットワークを調達する方法であって、
１つ以上のＳＬＡクライアントプロビジョニングディテールレコードからＲＦｘビッドを生成するステップと、
セカンダリＳＬＡプロバイダの事前設定リストへと前記ＲＦｘビッドを公示するステップと、
前記ＲＦｘビッドの受信に応えてセカンダリＳＬＡプロバイダがＲＦｘビッド応答を生成することができるようにするステップと、
１つ以上のセカンダリＳＬＡプロバイダＲＦｘビッド応答を処理するステップと、
ＲＦｘビッド応答の受信に応えて１つ以上のセカンダリＳＬＡプロバイダパーチャス要請を処理するステップと、
完成したパーチャス要請の受信に応えて１つ以上のセカンダリＳＬＡプロバイダパーチャスオーダーを処理するステップと
を含む方法。
【請求項２０】
ＲＦｘビッドを生成するステップは、
アクティブなＲＦｘビッドにアフィリエイトされていない１つ以上のＳＬＡクライアントプロビジョンディテールレコード、または前記ＲＦｘビッドに含めるべきセカンダリＳＬＡプロバイダパーチャスオーダーを選択するステップと、
前記アフィリエイトされていない１つ以上のＳＬＡクライアントプロビジョニングディテールレコードの選択に応えて前記ＲＦｘビッドを作成するステップと、
１つ以上の選択されたＳＬＡクライアントプロビジョンディテールレコードセットからデフォルトのＲＦｘビッド情報設定を受けるステップと、
非デフォルトのユーザー所望情報設定を構成するステップと、
ＲＦｘビッド情報設定を格納するステップとを含む
ことを特徴とする請求項１９に記載の方法。
【請求項２１】
デフォルトのＲＦｘビッド情報設定を受けるステップは、
ＳＬＡクライアントディテール、ＳＬＡクライアントプロビジョンサービスロケーションディテール、ＳＬＡプロビジョンスキルプロフィール、ＳＬＡプロビジョン要件、予測されるＳＬＡプロビジョンサービス頻度、適用可能なＳＬＡプロビジョンマテリアルディテールのうち、少なくとも１つに関する情報の取得を含む
ことを特徴とする請求項２０に記載の方法。
【請求項２２】
非デフォルトのユーザー所望情報設定を構成するステップは、
最大セカンダリＳＬＡプロバイダレーバーおよび適用可能な経費率、セカンダリＳＬＡプロバイダ非プロビジョンペナルティ条件、最多および最少ヒューマンリソースサブミッタルおよびＳＬＡプロビジョンレーバータイプのうちの１つ以上を指定するステップと、
後のＲＦｘビッド応答データ処理用のデフォルトおよび非デフォルト情報設定を格納するための事前設定されたＲＦｘビッドテンプレートを指定するステップとを含む
ことを特徴とする請求項２０に記載の方法。
【請求項２３】
ＲＦｘビッドを公示するステップは、
ビジネスファミリおよび地理的プロビジョン能力の一致に基づいて前記ＲＦｘビッドに論理的にマッピングされたセカンダリＳＬＡプロバイダのリストを受けるステップと、
セカンダリＳＬＡプロバイダＲＦｘビッドリストの作成に応えて、ＲＦｘビッドを受領する１つ以上のセカンダリＳＬＡプロバイダを指定するステップと、
指定されたセカンダリＳＬＡプロバイダにＲＦｘビッドを同報通信するステップとを含む
ことを特徴とする請求項１９に記載の方法。
【請求項２４】
前記ＲＦｘビッドの受信に応えてセカンダリＳＬＡプロバイダがＲＦｘビッド引用を生成することができるようにするステップは、
前記ＲＦｘビッドが処理用に公示された旨の通知を受けるステップと、
ＲＦｘビッド応答レコードを生成するステップと、
ＲＦｘビッド応答のディテールへのアクセスを許可するステップと、
ＲＦｘビッド質問項に応えて情報設定を指定するステップと、
前記ＲＦｘビッド応答に適用可能な情報設定を格納するステップとを含む
ことを特徴とする請求項１９に記載の方法。
【請求項２５】
ＲＦｘビッド質問項に応えて情報設定を指定するステップは、
平日、週末、休日、稼働時間、および非稼働時間のうち、少なくとも１つを含む可変の時間属性に適用可能な複数のプロビジョニング請求料率に関する情報を取得するステップと、
可変の経費タイプシナリオに適用可能な複数のプロビジョニング経費率に関する情報を取得するステップと、
プロビジョニング応答時間および非プロビジョニングペナルティのうち、少なくとも１つを含むＳＬＡプロビジョニング条件の承諾に関する情報を取得するステップと、
１つ以上のセカンダリＳＬＡプロバイダプロビジョニングヒューマンリソースサブミッタルに関する情報を取得するステップとを含む
ことを特徴とする請求項２４に記載の方法。
【請求項２６】
ＲＦｘビッド応答に適用可能な情報設定の格納に応えて、ＲＦｘビッド応答を評価用にプライマリＳＬＡプロバイダへと提出するステップをさらに含む請求項２４に記載の方法。
【請求項２７】
１つ以上のセカンダリＳＬＡプロバイダＲＦｘビッド応答を処理するステップは、
提出されたセカンダリＳＬＡプロバイダＲＦｘビッド応答を受けるステップと、
前記セカンダリＳＬＡプロバイダＲＦｘビッド応答の受け入れまたは拒絶を決定するステップと、
ＲＦｘビッド応答処遇決定を格納するステップとを含む
ことを特徴とする請求項１９に記載の方法。
【請求項２８】
前記ＲＦｘビッド応答処遇決定の格納に応えて、
セカンダリＳＬＡプロバイダにＲＦｘビッド応答処遇決定について通知するステップと、
ＲＦｘビッド応答が受け入れであった場合に応えて、セカンダリＳＬＡプロバイダパーチャス要請を作成するステップとをさらに含む
請求項２７に記載の方法。
【請求項２９】
１つ以上のセカンダリＳＬＡプロバイダパーチャス要請を処理するステップは、
受け入れたセカンダリＳＬＡプロバイダＲＦｘビッド応答からパーチャス要請情報設定を統合化するステップと、
セカンダリＳＬＡプロバイダパーチャスオーダーを作成するステップとを含む
ことを特徴とする請求項１９に記載の方法。
【請求項３０】
セカンダリＳＬＡプロバイダパーチャス要請を処理するステップは、
プライマリＳＬＡプロバイダによりパーチャス要請情報を承認するステップと、
承認されたパーチャス要請を適切なセカンダリＳＬＡプロバイダへと提出するステップと、
セカンダリＳＬＡプロバイダにパーチャス要請の受信を通知するステップと、
セカンダリＳＬＡプロバイダパーチャス要請の承認をアクナリッジするステップと、
セカンダリＳＬＡプロバイダから承認されたパーチャス要請を受けるステップと、
完成したパーチャス要請領収書をプライマリＳＬＡプロバイダに通知するステップとを含む
ことを特徴とする請求項２９に記載の方法。
【請求項３１】
１つ以上のセカンダリＳＬＡプロバイダパーチャスオーダーの処理に応えて、
セカンダリＳＬＡプロバイダパーチャスオーダーに、完成したパーチャス要請レコード中に含まれるデフォルト情報機能を投入するステップと、
非デフォルトパーチャスオーダー情報を指定するステップと、
セカンダリＳＬＡプロバイダパーチャスオーダーを承認するステップとをさらに含む
請求項１９に記載の方法。
【請求項３２】
セカンダリＳＬＡプロバイダパーチャスオーダーを承認するステップは、
セカンダリＳＬＡプロバイダにパーチャスオーダー承認トランザクションを通知するステップと、
セカンダリＳＬＡプロバイダパーチャスオーダーへのユーザーアクセスを可能にするステップとを含む
ことを特徴とする請求項３１に記載の方法。
【請求項３３】
セカンダリサービスレベルアグリーメント（ＳＬＡ）プロバイダヒューマンリソースネットワークを管理する方法であって、
セカンダリＳＬＡプロバイダパーチャスオーダーにアフィリエイトする１人以上のヒューマンリソースサブミッタルを選択するステップと、
前記１人以上のヒューマンリソースプロビジョニング要員を採用するステップと、
前記１人以上のヒューマンリソースプロビジョニング要員の、デフォルトのワークアベラビリティカレンダ情報設定を処理するステップと、
非デフォルトのヒューマンリソースプロビジョニングアベラビリティカレンダの管理をイネーブルするステップと、
非デフォルトのワークアベラビリティカレンダ情報設定を処理するステップと
を含む方法。
【請求項３４】
セカンダリＳＬＡプロバイダパーチャスオーダーにアフィリエイトする１人以上のヒューマンリソースサブミッタルを選択するステップは、
セカンダリＳＬＡプロバイダＲＦｘビッド応答ヒューマンリソースプロビジョニングサブミッタルをアクセスするステップと、
１人以上のヒューマンリソースプロビジョニングサブミッタルについて任務承認を指定するステップと、
前記１人以上のヒューマンリソースプロビジョニングサブミッタルの任務承認処遇決定を格納するステップと、
セカンダリＳＬＡプロバイダに前記１人以上の特定されたヒューマンリソースプロビジョニングサブミッタルの任務承認処遇決定について通知するステップと、
セカンダリＳＬＡプロバイダが前記１人以上の特定されたヒューマンリソースプロビジョニングサブミッタルの任務承認処遇決定を追認することができるようにするステップとを含む
ことを特徴とする請求項３３に記載の方法。
【請求項３５】
１人以上のヒューマンリソースプロビジョニング要員を採用するステップは、
ヒューマンリソース派遣労働者アグリーメントの署名を受けるステップと、
前記署名を受けるステップに応えて、ヒューマンリソース派遣労働者アグリーメント情報を受けるステップと、
ヒューマンリソース派遣労働者アグリーメント情報を承認するステップと、
ヒューマンリソース派遣労働者の承認処遇決定を格納するステップと、
セカンダリＳＬＡプロバイダに、承認されたヒューマンリソース採用を通知するステップとを含む
ことを特徴とする請求項３３に記載の方法。
【請求項３６】
前記１人以上のヒューマンリソースプロビジョニング要員の、デフォルトのワークアベラビリティカレンダ情報設定を処理するステップは、
前記１人以上のヒューマンリソースプロビジョニング要員の標準スケジュールブラックアウトおよびアベラビリティ時間設定の指定を受けるステップと、
指定された標準スケジュールブラックアウトおよびアベラビリティ時間設定を格納するステップと、
格納した標準スケジュールブラックアウトおよびアベラビリティ時間設定をプライマリＳＬＡプロバイダのレビュー用に提出するステップとを含む
ことを特徴とする請求項３３に記載の方法。
【請求項３７】
前記１人以上のヒューマンリソースプロビジョニング要員の、デフォルトのワークアベラビリティカレンダ情報設定を処理するステップは、
提出され、格納された標準スケジュールブラックアウトおよびアベラビリティ時間設定を受けるステップと、
ヒューマンリソースプロビジョニング要員デフォルトカレンダアベラビリティ設定の承認を受けるステップと、
プロビジョニング要員デフォルトカレンダアベラビリティの承認を格納するステップと、
前記１人以上のヒューマンリソースプロビジョニング要員のアベラビリティカレンダをアクティブ化するステップと、
プロビジョニング要員デフォルトカレンダアベラビリティの承認およびアクティブ化をセカンダリＳＬＡプロバイダに通知するステップと、
アクティブなプロビジョニング要員アベラビリティカレンダにアクセスするステップとを含む
ことを特徴とする請求項３３に記載の方法。
【請求項３８】
非デフォルトのヒューマンリソースプロビジョニングアベラビリティカレンダの管理をイネーブルするステップは、
ヒューマンリソースプロビジョニング要員カレンダアベラビリティレコードへのアクセスを許可するステップと、
ヒューマンリソースプロビジョニング要員カレンダアベラビリティに適用可能な非デフォルト情報設定の指定を受けるステップと、
指定されたヒューマンリソースプロビジョニング要員非デフォルトカレンダアベラビリティ情報設定を格納するステップと、
適切なユーザーにヒューマンリソースプロビジョニング要員非デフォルトカレンダアベラビリティ情報設定の変更を通知するステップとを含む
ことを特徴とする請求項３３に記載の方法。
【請求項３９】
非デフォルトのワークアベラビリティカレンダ情報設定を処理するステップは、
いずれかの要求されるＳＬＡクライアントプロビジョンカバレッジ期間について、ヒューマンリソースプロビジョニング要員カバレッジアベラビリティが無い場合を判定するステップと、
適切なプライマリＳＬＡプロバイダのユーザーに、要求プロビジョンカバレッジ期間完全ブラックアウトリソースアベラビリティについて警告するステップと、
適切なセカンダリＳＬＡプロバイダにプロビジョンカバレッジ変更リクエストを同報通信するステップと、
受けたプロビジョンカバレッジ変更リクエストに関わる情報設定を格納するステップと、
セカンダリＳＬＡプロバイダ情報設定の格納に応えて、プロビジョンリソースの非アベラビリティシナリオが改善された旨を適切なプライマリＳＬＡプロバイダのユーザーに通知するステップとを含む
ことを特徴とする請求項３８に記載の方法。
【請求項４０】
サービスレベルアグリーメント（ＳＬＡ）クライアントプロビジョニング要件を処理する方法であって、
ＳＬＡクライアントサービスプロビジョンリクエストを処理するステップと、
サービスプロビジョンディスパッチリクエストを処理するステップと、
プロビジョニングヒューマンリソースディスパッチ通知レコードを処理するステップと、
受けたプロビジョニングヒューマンリソースディスパッチ通知レコードを処理するステップと
を含む方法。
【請求項４１】
ＳＬＡクライアントサービスプロビジョンリクエストを処理するステップは、
ＳＬＡクライアントパーチャスオーダーおよびアフィリエイトするプロビジョニングマスタデータレコードへのアクセスを許可するステップと、
ＳＬＡクライアントプロビジョニングリクエストレコードを作成するステップと、
デフォルトのＳＬＡクライアントプロビジョニングリクエスト情報を受けるステップと、
非デフォルトのＳＬＡクライアントプロビジョニングリクエスト情報を指定するステップと、
ＳＬＡクライアントプロビジョニングリクエスト情報設定を格納するステップとを含む
ことを特徴とする請求項４０に記載の方法。
【請求項４２】
デフォルトのＳＬＡクライアントプロビジョニングリクエスト情報を受けるステップは、ユーザーによるレコードの選択に応えてＳＬＡプロビジョニングレコードディテールを検索するステップを含むことを特徴とする請求項４１に記載の方法。
【請求項４３】
非デフォルトのＳＬＡクライアントプロビジョニングリクエスト情報を指定するステップは、提示されるＳＬＡクライアントプロビジョニングリクエストデータフィールドに適用可能な所望の情報を入力するステップを含むことを特徴とする請求項４１に記載の方法。
【請求項４４】
ＳＬＡクライアントプロビジョニングリクエスト情報設定の格納に応えて、
ＳＬＡクライアントプロビジョニングリクエストが完成し、格納されたことをユーザーに通知するステップと、
ＳＬＡクライアントプロビジョニングリクエストを下流処理用にプライマリＳＬＡプロバイダに提出するステップとをさらに含む
ことを特徴とする請求項４１に記載の方法。
【請求項４５】
サービスプロビジョンディスパッチリクエストを処理するステップは、
ＳＬＡクライアントサービスプロビジョンリクエストへのレコードアクセスを可能にするステップと、
前記ＳＬＡクライアントにサービスを提供するように設定された、アフィリエイトされているセカンダリＳＬＡプロバイダのリストを受けるステップと、
前記ＳＬＡクライアントにサービスを提供するように設定された、アフィリエイトされているセカンダリＳＬＡプロバイダの就労可能なプロビジョニングヒューマンリソースのリストを受けるステップと、
前記ＳＬＡクライアントにサービスを提供する上で就労可能なプロビジョニングヒューマンリソースを指定するステップと、
情報設定を格納するステップとを含む
ことを特徴とする請求項４０に記載の方法。
【請求項４６】
情報設定を格納するステップは、サービスプロビジョンディスパッチリクエストを生成するステップを含むことを特徴とする請求項４５に記載の方法。
【請求項４７】
サービスプロビジョンディスパッチリクエストを処理するステップがサービスプロビジョンディスパッチリクエストを同報通信するステップを含む場合、
前記サービスプロビジョンディスパッチリクエストを同報通信するステップは、
前記サービスプロビジョンディスパッチリクエストをアフィリエイトされたセカンダリＳＬＡプロバイダへと送信するステップと、
アフィリエイトされたセカンダリＳＬＡプロバイダに対し、入って来るサービスプロビジョンディスパッチリクエストについて通知するステップと、
送信されたサービスプロビジョンディスパッチリクエストへのアクセスを提供するステップとを含む
ことを特徴とする請求項４０に記載の方法。
【請求項４８】
プロビジョニングヒューマンリソースディスパッチ通知レコードを処理するステップは、
プロビジョニングヒューマンリソースアベラビリティを検証するステップと、
ヒューマンリソースアベラビリティに関する情報設定を格納するステップとを含む
ことを特徴とする請求項４０に記載の方法。
【請求項４９】
情報設定を格納するステップは、
プロビジョニングヒューマンリソースディスパッチ通知を生成するステップと、
プロビジョニングヒューマンリソースディスパッチ通知レコードをプライマリＳＬＡプロバイダへと伝送するステップとを含む
ことを特徴とする請求項４８に記載の方法。
【請求項５０】
プロビジョニングヒューマンリソースディスパッチ通知レコードを処理するステップは、
プロビジョニングヒュマンリソースディスパッチ通知レコードへのアクセスを許可するステップと、
ＳＬＡクライアントプロビジョニングディスパッチ通知を作成するステップと、
前記ＳＬＡクライアントプロビジョニングディスパッチ通知を格納するステップと、
ＳＬＡクライアントプロビジョニングディスパッチ通知を、元のＳＬＡクライアントサービスプロビジョンリクエストにアフィリエイトする適切なＳＬＡクライアントのユーザーに送信するステップとを含む
ことを特徴とする請求項４０に記載の方法。
【請求項５１】
ＳＬＡクライアントプロビジョニングディスパッチ通知を送信するステップは、
適切なＳＬＡクライアントのユーザーに通知するステップと、
前記伝送されたＳＬＡクライアントプロビジョニングディスパッチ通知へのアクセスを許可するステップとを含む
ことを特徴とする請求項５０に記載の方法。
【請求項５２】
サービスレベルアグリーメント（ＳＬＡ）プロビジョニングワークバウチャーを処理する方法であって、
プロビジョニングヒューマンリソースによる入力に応えて、ＳＬＡプロビジョニングサービスバウチャーを作成および格納するステップと、
前記格納したＳＬＡプロビジョニングサービスバウチャーを適切なセカンダリＳＬＡプロバイダのユーザーが処理するステップと、
適切なプライマリＳＬＡプロバイダのユーザーの入力に応えて、前記承認されたセカンダリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップと、
適切なＳＬＡクライアントのユーザーの入力に応えて、前記承認されたプライマリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップと
を含む方法。
【請求項５３】
ＳＬＡプロビジョニングサービスバウチャーを作成するステップは、
適切なヒューマンリソースプロビジョンディスパッチレコードを指定するステップと、
前記指定されたヒューマンリソースプロビジョンディスパッチレコードにアフィリエイトするＳＬＡプロビジョニング情報に適用可能なデフォルトの情報を受けるステップと、
実施された物理的プロビジョニングサービスディテールに関する非デフォルト情報を指定するステップと、
ＳＬＡプロビジョニングワークバウチャー情報設定を格納するステップとを含む
ことを特徴とする請求項５２に記載の方法。
【請求項５４】
ＳＬＡプロビジョニングワークバウチャー情報設定の格納に応えて、
適切なセカンダリＳＬＡプロバイダのユーザーに、格納されたＳＬＡプロビジョニングワークバウチャーのレビューが可能である旨を通知するステップと、
前記格納されたＳＬＡプロビジョニングワークバウチャーへのアクセスを許可するステップとをさらに含む
ことを特徴とする請求項５３に記載の方法。
【請求項５５】
前記格納したＳＬＡプロビジョニングサービスバウチャーを適切なセカンダリＳＬＡプロバイダのユーザーが処理するステップは、
適切なセカンダリＳＬＡプロバイダパーチャスオーダーから継承したデフォルトのＳＬＡプロビジョニングサービスバウチャーパーチャスオーダー情報を受けるステップと、
ＳＬＡプロビジョニングサービスバウチャーパーチャスオーダー情報の非デフォルトデータ値を指定するステップと、
情報設定を承認するステップと、
セカンダリＳＬＡプロバイダＳＬＡプロビジョニングワークバウチャー情報設定を格納するステップとを含む
ことを特徴とする請求項５２に記載の方法。
【請求項５６】
セカンダリＳＬＡプロバイダＳＬＳプロビジョニングワークバウチャー情報設定を格納するステップに応えて、
適切なプライマリＳＬＡプロバイダのユーザーに、承認されたセカンダリＳＬＡプロバイダプロビジョニングワークバウチャーがレビュー用に提出された旨を通知するステップと、
前記承認されたセカンダリＳＬＡプロバイダプロビジョニングワークバウチャーへのアクセスを許可するステップとをさらに含む
ことを特徴とする請求項５５に記載の方法。
【請求項５７】
前記承認されたセカンダリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップは、
適切なＳＬＡクライアントパーチャスオーダーから継承されたデフォルトのＳＬＡプロビジョニングサービスバウチャーパーチャスオーダー情報を受けるステップと、
ＳＬＡプロビジョニングサービスバウチャーパーチャスオーダー情報の非デフォルトデータ値を指定するステップと、
プライマリＳＬＡプロバイダプロビジョニングワークバウチャー情報設定を格納するステップとを含む
ことを特徴とする請求項５２に記載の方法。
【請求項５８】
プライマリＳＬＡプロバイダＳＬＡプロビジョニングワークバウチャー情報設定の格納に応えて、
適切なＳＬＡクライアントのユーザーに、承認されたプライマリＳＬＡプロバイダプロビジョニングワークバウチャーがレビュー可能である旨を通知するステップと、
前記承認されたプライマリＳＬＡプロバイダプロビジョニングワークバウチャーへのアクセスを許可するステップとをさらに含む
ことを特徴とする請求項５７に記載の方法。
【請求項５９】
前記承認されたプライマリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップは、
ＳＬＡクライアントのユーザーによるプロビジョニングワークバウチャー情報設定を受けるステップと、
前記プロビジョニングワークバウチャー情報設定を受けたことに応えて、承認または拒絶の処遇決定を指定するステップと、
前記指定されたプロビジョニングワークバウチャー承認処遇決定を格納するステップとを含む
ことを特徴とする請求項５２に記載の方法。
【請求項６０】
前記指定されたプロビジョニングワークバウチャー承認処遇決定を格納するステップは、
デフォルトのＳＬＡプロビジョニングサービス品質保証査定情報を受けるステップと、
前記受けた品質保証査定の質問項に適用可能な情報を指定するステップと、
品質保証情報の指定を前記システム内に格納するステップとを含む
ことを特徴とする請求項５９に記載の方法。
【請求項６１】
前記指定されたプロビジョニングワークバウチャー承認処遇決定を格納するステップに応えて、
適切なプライマリＳＬＡプロバイダおよびセカンダリＳＬＡプロバイダのユーザーにＳＬＡクライアントプロビジョニングワークバウチャー処遇決定を通知するステップと、
適切なプライマリＳＬＡプロバイダおよびセカンダリＳＬＡプロバイダのユーザーに前記ＳＬＡクライアントプロビジョニングワークバウチャー処遇決定へのアクセスを許可するステップとをさらに含む
ことを特徴とする請求項５９に記載の方法。
【請求項６２】
サービスレベルアグリーメント（ＳＬＡ）プロビジョニングワークオーダーの支払いを処理する方法であって、
ＳＬＡクライアント承認済みプロビジョニングワークバウチャーを抽出するステップと、
請求明細書ファイルを生成するステップと、
ＳＬＡクライアント請求明細書ファイルを処理するステップと、
ＳＬＡクライアントからの支払いを処理するステップと、
セカンダリＳＬＡプロバイダへの支払いを実施するステップと
を含む方法。
【請求項６３】
ＳＬＡクライアント承認済みプロビジョニングワークバウチャーを抽出するステップは、
格納された未処理ＳＬＡクライアント承認済みプロビジョニングワークバウチャーレコードを特定するステップと、
前記未処理ＳＬＡクライアント承認済みプロビジョニングワークバウチャーレコードから継承されたデフォルトの情報を受けるステップと、
承認済みプロビジョニングワークバウチャーレコードセット情報設定を格納するステップとを含む
ことを特徴とする請求項６２に記載の方法。
【請求項６４】
請求明細書ファイルを生成するステップは、
プライマリＳＬＡプロバイダからＳＬＡクライアントへの請求書ファイルを生成するステップと、
セカンダリＳＬＡプロバイダからプライマリＳＬＡプロバイダへの請求書ファイルを生成するステップとを含む
ことを特徴とする請求項６２に記載の方法。
【請求項６５】
プライマリＳＬＡプロバイダからＳＬＡクライアントへの請求書ファイルを生成する前記ステップは、
ＳＬＡクライアントに指定された請求書ファイル情報テンプレートを用いるステップと、
格納された承認済みプロビジョニングワークバウチャーレコードセット情報設定をＳＬＡクライアントに指定された請求書ファイル情報テンプレートに投入するステップと、
データ投入に応えてＳＬＡクライアント請求明細書ファイルを格納するステップとを含む
ことを特徴とする請求項６４に記載の方法。
【請求項６６】
セカンダリＳＬＡプロバイダからプライマリＳＬＡプロバイダへの請求書ファイルを生成するステップは、
プライマリＳＬＡプロバイダに指定された請求書ファイル情報テンプレートを用いるステップと、
格納された承認済みプロビジョニングワークバウチャーレコードセット情報設定をプライマリＳＬＡプロバイダに指定された請求書ファイル情報テンプレートに投入するステップと、
データ投入に応えてプライマリＳＬＡプロバイダ請求明細書ファイルを格納するステップとを含む
ことを特徴とする請求項６４に記載の方法。
【請求項６７】
データ投入に応えてＳＬＡクライアント請求明細書ファイルを格納するステップに応えて、
適切なＳＬＡクライアントのユーザーに、請求明細書ファイルがデータ処理用に利用可能である旨を通知するステップと、
適合した適切なＳＬＡクライアントのユーザーに前記明細書ファイルへのアクセスを提供するステップとをさらに含む
ことを特徴とする請求項６５に記載の方法。
【請求項６８】
ＳＬＡクライアント請求明細書ファイルを処理するステップは、
ＳＬＡクライアント請求明細書データを承認するステップと、
適切なプライマリＳＬＡプロバイダのユーザーに請求書ファイルの承認を通知するステップと、
前記ＳＬＡクライアントから前記プライマリＳＬＡプロバイダへと支払いを実施するステップと、
プライマリＳＬＡプロバイダへの支払いに応えて代金支払いファイルを生成し、格納するステップとを含む
ことを特徴とする請求項６２に記載の方法。
【請求項６９】
ＳＬＡクライアントからの支払いを処理するステップは、
代金支払いを受けるステップと、
格納された代金支払いファイルへのアクセスを許可するステップと、
代金支払いファイルデータを適切なＳＬＡクライアント請求明細書ファイルへと適用するステップと、
請求明細書支払いレコードを格納するステップとを含む
ことを特徴とする請求項６２に記載の方法。
【請求項７０】
請求明細書支払いレコードを格納するステップに応えて、
セカンダリＳＬＡプロバイダ明細書支払いファイルを生成するステップと、
前記セカンダリＳＬＡプロバイダ明細書支払いファイルを格納するステップとをさらに含む
ことを特徴とする請求項６９に記載の方法。
【請求項７１】
セカンダリＳＬＡプロバイダ明細書支払いファイルを格納するステップに応えて、
適切なプライマリＳＬＡプロバイダのユーザーに、セカンダリＳＬＡプロバイダ請求明細書ファイルがデータ処理用に使用可能である旨を通知するステップと、
通知に応えて、セカンダリＳＬＡプロバイダ請求明細書ファイルへのアクセスができるように適合した適切なプライマリＳＬＡプロバイダのユーザーにユーザーインターフェースを提供するステップとをさらに含む
ことを特徴とする請求項７０に記載の方法。
【請求項７２】
セカンダリＳＬＡプロバイダへの支払いを実施するステップは、
セカンダリＳＬＡプロバイダ請求明細書データを承認するステップと、
前記セカンダリＳＬＡプロバイダへと支払いを実施するステップと、
セカンダリＳＬＡプロバイダへの支払いに応えて、代金支払いファイルを生成および格納するステップとを含む
ことを特徴とする請求項６２に記載の方法。
【請求項７３】
セカンダリＳＬＡプロバイダへの支払いに応えて代金支払いファイルを生成および格納するステップに応えて、
前記格納されたセカンダリＳＬＡプロバイダ代金支払いファイルへのアクセスを提供するステップと、
代金支払いファイルデータを適切なセカンダリＳＬＡプロバイダ請求明細書ファイルに対して適用するステップと、
セカンダリＳＬＡプロバイダ請求明細書の支払いレコードを格納するステップとをさらに含む
ことを特徴とする請求項７２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本特許出願は、２００５年８月１日に出願された米国暫定特許出願第６０／７０４，３５２号からの優先権を主張し、参照によりこれを本願に組み込むものである。本出願は、参照により以下の特許出願を組み込むものである：２００２年９月３０日出願の米国特許出願第１０／２６２，４８７号（６７７３７−５３２ＵＳＰＴ）；２００３年４月１０日出願の米国特許出願第１０／４１２，０９６号（６７７３７−５３２ＵＳＰ１）；２００４年３月１０日に出願の米国特許出願第１０／７９７，５５６号（６７７３７−５３２ＵＳＰ２）；２００２年５月９日出願の米国特許出願第１０／１４１，８０１号（６７７３７−５４２ＵＳＰＴ）；２００２年４月２４日出願の米国特許出願第１０／１２８，７５１号（６７７３７−５４３ＵＳＰＴ）；および２００５年３月２日出願の米国特許出願第１１／０７１，８３１号（６７７３７−１００２ＵＳＰＴ）。
【０００２】
本発明は、プロキュアメント、ロジスティクスプランニング、人的資本配置、サービスプロビジョン要請、サービスプロビジョンデリバラブルの追跡、経理取引データ処理、そしてサービスレベルアグリーメント（ＳＬＡ）のアウトソーシングまたは他の第三者機関顧客サービス／機器要件に関わる意思決定支援アナリティクスを促進するシステムおよび方法に関する。
【背景技術】
【０００３】
多くの企業はダウンストリームのクライアントベースにサービスまたは商品を提供することを目的としたビジネス努力を続けている。ダウンストリームクライアントにサービスまたは商品を提供するこれらの企業はプライマリＳＬＡプロバイダ（Primary SLA Provider）と呼ばれ、一方でこれらの商品またはサービスが提供される側のダウンストリームクライアントはＳＬＡクライアント（SLA Client）と呼ばれる。一部の事例においては、サービス／商品の提供は、一般保守または保証契約を通じてロジスティクス的に管理される。他の事例においてはプライマリＳＬＡプロバイダのサポートするインフラの性質が重大なもので、このためにＳＬＡクライアントにとってはそのダウンタイム（例えばコンピュータシステム、遠隔通信ネットワークまたは製造ラインの故障などが含まれる）が長引くと過剰なコストがかかることから、一般保守または保証契約によってサポートしきれない場合がある。これらの重大なサポート要求に対応するために、プライマリＳＬＡプロバイダおよびＳＬＡクライアントはサービスレベルアグリーメント（Service Level Agreement: SLA）を通じてサービスサポート条件を管理することが一般的である。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
過去においては、ＳＬＡプロビジョニングはサービスまたは商品を提供しているプライマリＳＬＡプロバイダにより、その組織内で実施されることが一般的であり、このモデルによればプライマリＳＬＡプロバイダによる全ＳＬＡビジネス機能のコントロールが可能であった。ＳＬＡビジネス機能には、例えばロジスティクス、契約マネジメント、プロキュアメント、ヒューマンリソース（HR：人材）配置、デリバラブルマネジメントおよび経理データ処理などが含まれる。現在のビジネス環境は劇的な変化をとげ、ＳＬＡビジネス機能の多くが、コアコンピテンシーとしてプロビジョニングサービスを提供することを目的とした業者にアウトソーシングされる方向にある。これらの業者は、一般にセカンダリＳＬＡプロバイダ（Secondary SLA Provider）と呼ばれる。一部の企業はこのビジネスモデルによってサービスの幅を広げ、収入および利益を上げることができたが、新たなプロビジョニング層が導入されたことでプライマリＳＬＡプロバイダにとってはコントロールを、そして大抵の場合は利益をも失う結果となった。
【０００５】
これまでの努力で、ＳＬＡビジネス機能の一部では最小限の取り組みがなされたが、ほとんどの手法は内部管理という視点から発したものであった。従って従前のソリューション開発は、ＳＬＡプロビジョニングのアウトソースを考慮した場合に遭遇する商取引上、ロジスティクス上、データ処理上、および管理上の多大な問題を解決するものではなかった。よってＳＬＡプロビジョニングサービスをＳＬＡクライアントへと提供するために、プライマリＳＬＡプロバイダが適任のセカンダリＳＬＡプロバイダを利用しつつも、ＳＬＡビジネス機能に対してより大きなコントロールを行使することができるシステムおよび方法が必要とされているのである。
【課題を解決するための手段】
【０００６】
アウトソーシングしたサービスレベルアグリーメント（ＳＬＡ）デリバラブルのマネジメント方法は、ＳＬＡクライアントおよびセカンダリＳＬＡプロバイダのマスタデータを設定するステップと、セカンダリＳＬＡプロバイダプロビジョンサービスネットワークを調達するステップと、セカンダリＳＬＡプロバイダヒューマンリソースネットワークを管理するステップと、ＳＬＡクライアントプロビジョニング要件を処理するステップと、ＳＬＡプロビジョニングサービスバウチャーを処理するステップと、そしてＳＬＡプロビジョニングワークオーダーの支払いを処理するステップとを含む。
【０００７】
サービスレベルアグリーメント（ＳＬＡ）クライアントとセカンダリＳＬＡプロバイダのマスタデータを設定する方法は、ＳＬＡプロビジョンロジスティクスコントロールライブラリを設定するステップと、ＳＬＡクライアントマスタデータレコードを設定するステップと、ＳＬＡクライアントパーチャスオーダー（PO：発注）レコードを設定するステップと、そしてセカンダリＳＬＡプロバイダネットワークを採用するステップとを含んでいる。
【０００８】
セカンダリサービスレベルアグリーメント（ＳＬＡ）プロバイダプロビジョンサービスネットワークを調達する方法は、ＲＦｘビッドを１つ以上のＳＬＡクライアントプロビジョニングディテールレコードから生成するステップと、ＲＦｘビッドを事前設定リストにあるセカンダリＳＬＡプロバイダに公示するステップと、ＲＦｘビッドの受信を受けてセカンダリＳＬＡプロバイダがＲＦｘビッド応答を生成することができるようにするステップと、１つ以上のセカンダリＳＬＡプロバイダＲＦｘビッド応答を処理するステップと、ＲＦｘビッド応答の受信に応えて１つ以上のセカンダリＳＬＡプロバイダパーチャス要請を処理するステップと、完成したパーチャス要請の受信に応えて少なくとも１つのセカンダリＳＬＡプロバイダパーチャスオーダーを処理するステップとを含む。
【０００９】
セカンダリサービスレベルアグリーメント（ＳＬＡ）プロバイダヒューマンリソースネットワークを管理する方法は、セカンダリＳＬＡプロバイダパーチャスオーダーにアフィリエイトする１人以上のヒューマンリソースサブミッタルを選択するステップと、１人以上のヒューマンリソースプロビジョニング要員を採用するステップと、その１人以上のヒューマンリソースプロビジョニング要員のデフォルトのワークアベラビリティ（work availability：就労可能性）カレンダ情報設定を処理するステップと、非デフォルトヒューマンリソースプロビジョニングアベラビリティカレンダ管理をイネーブルするステップと、そして非デフォルトワークアベラビリティカレンダ情報設定を処理するステップとを含む。
【００１０】
サービスレベルアグリーメント（ＳＬＡ）クライアントプロビジョニング要件を処理する方法は、ＳＬＡクライアントサービスプロビジョニングリクエストを処理するステップと、サービスプロビジョンディスパッチ（Dispatch：派遣）リクエストを処理するステップと、プロビジョニングヒューマンリソースディスパッチ通知レコードを処理するステップと、そして受けたプロビジョニングヒューマンリソースディスパッチ通知レコードを処理するステップとを含む。
【００１１】
サービスレベルアグリーメント（ＳＬＡ）プロビジョニングワークバウチャーを処理する方法は、プロビジョニングヒューマンリソースの入力に応えてＳＬＡプロビジョニングサービスバウチャーを作成および保存するステップと、適切なセカンダリＳＬＡプロバイダのユーザーによって保存されたＳＬＡプロビジョニングサービスバウチャーを処理するステップと、適切なプライマリＳＬＡプロバイダユーザーの入力に応えて承認されたセカンダリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップと、そして適切なＳＬＡクライアントユーザーの入力に応えて承認されたプライマリＳＬＡプロバイダプロビジョニングサービスバウチャーを処理するステップとを含む。
【００１２】
サービスレベルアグリーメント（ＳＬＡ）プロビジョニングワークオーダーの支払いを処理する方法は、ＳＬＡクライアントの承認したプロビジョニングワークバウチャーを抽出するステップと、請求明細書ファイルを生成するステップと、ＳＬＡクライアント請求明細書ファイルを処理するステップと、ＳＬＡクライアントからの支払いを処理するステップと、そしてセカンダリＳＬＡプロバイダに支払いを行うステップとを含む。
【００１３】
上述した発明の概要は、実施例の各々を表すものでも、本発明の全態様を表すものでもない。
【発明を実施するための最良の形態】
【００１４】
本発明の方法および装置に関するより完全な理解は、以下の詳細説明を添付図表と共に参照することにより得ることができる。
【００１５】
当業者には明らかなように、表１〜９１に示す記入例は、潜在的なデータ値を網羅するものではない。他のデータ値を付加することは単純にデータベースに変更を加えることであり、当業者であれば容易に実施可能である。
【００１６】
本発明の様々な実施例は、総合的なインターネット対応コンピュータシステムと、プライマリＳＬＡプロバイダ、セカンダリＳＬＡプロバイダおよびＳＬＡクライアント間でのアウトソーシングされたサービスレベルアグリーメント（ＳＬＡ）プロビジョニングに適用可能な基本的ビジネス機能とをイネーブルし、管理するための方法とを提供する。基本的ビジネス機能は、コントラクトマネジメント、プロキュアメント、ヒューマンリソース配置、ＳＬＡロジスティクス、ＳＬＡデリバラブルマネジメント、経理データ処理、企業間システム協力およびレポート／情報マネジメントを含む。本特許出願の目的上、「ビジネス機能」という語は、最良の形で実施されるＳＬＡマネジメントシステムにおいて行われる複数のコアビジネス活動のうち、いずれを指すものであっても良く、これにはマスタデータ機能、プロキュアメント機能、ヒューマンリソースサービスプロビジョンマネジメント機能、プロビジョン管理機能、ＳＬＡワークアクノリッジメント（Acknowledgment：確認）および品質保証機能、請求／支払い機能、および情報マネジメント／レポート機能が含まれる。
【００１７】
高位の観点からいえば、代表的な実施例においては、アウトソースされるＳＬＡプロビジョニング商品に適用可能なデータを取得、処理、および管理するように特別に設計されたデータベースによって支持されるコラボレーティブなインターネット対応型データ処理環境全体にわたり、堅牢なビジネス機能が組み込まれている。このデータ処理環境（ＳＬＡプロビジョニングマネジメント環境と呼ぶ）は、代表的にはマスタデータ機能、プロキュアメント機能、ヒューマンリソースサービスプロビジョン機能、プロビジョン管理機能、ＳＬＡワークアクノリッジメントおよび品質保証機能、請求／支払い機能および情報マネジメント／レポート機能を含む。
【００１８】
マスタデータ機能は、例えば一般ビジネス情報、ロジスティックスコントロール情報、ＳＬＡコントラクト（契約）情報、ＳＬＡプロビジョンディテール（詳細）情報、およびパーチャスオーダー（発注）情報にあたるＳＬＡクライアントマスタデータを格納するものである。このマスタデータ機能はさらに、ＳＬＡプロビジョンスキルプロファイリングおよびジョブディスクリプション（職務記述）ソースライブラリ、ＳＬＡプロビジョンスキルプロフィールライブラリ、そしてＳＬＡプロビジョンディテール〜ＳＬＡプロビジョンスキルプロフィールのマトリクスを格納するものであってもよい。
【００１９】
プロキュアメント機能は、代表的には：セカンダリＳＬＡプロバイダに適用可能なビジネス情報をプライマリＳＬＡプロバイダが取得および格納できるようにすること；プライマリＳＬＡプロバイダによるセカンダリＳＬＡプロバイダのＳＬＡスキルプロビジョンおよび地理的カバレッジ（網羅）能力という観点からの分類を可能にすること；マスタデータ機能によりディテールが示されるＳＬＡクライアントカバレッジ要件をプライマリＳＬＡプロバイダが系統的に特定および数量化できるようにすること；プライマリＳＬＡプロバイダが、ＳＬＡクライアントカバレッジレコードから系統的なＲＦｘビッドを生成するようにすること；プライマリＳＬＡプロバイダが、作成された各ＲＦｘビッド（入札）についてセカンダリＳＬＡプロバイダビッド勧誘リストを系統的かつ論理的に生成できるようにすること；セカンダリＳＬＡプロバイダがＲＦｘビッド応答を系統的に生成し、必要に応じてその応答にアフィリエイトする適切な人的資本リソースを提出できるようにすること；ビッド（ＲＦｘ）ビッド応答の提案／リクエストに対する見積もり／リクエストについて、プライマリＳＬＡプロバイダが提出された要求を系統的にレビューできるようにすること；そしてプライマリＳＬＡプロバイダが、ＲＦｘビッド応答を系統的に受け入れ／落札を決め、そのＲＦｘビッド応答のディテールに関するセカンダリＳＬＡプロバイダパーチャスオーダーを作成できるようにすること；の複数機能を実施するものである。
【００２０】
ヒューマンリソースサービスプロビジョンマネジメント機能は、代表的には：プライマリＳＬＡプロバイダが、提出されたＲＦｘビッド応答候補のレビューおよび承認の処遇決定を実施できるようにすること；提出されたＲＦｘビッド応答候補について、プライマリＳＬＡプロバイダの処遇決定／ステータス通知をセカンダリＳＬＡプロバイダに系統的に可能にすること；提出されたＲＦｘビッド応答候補の承認／受諾時に、プライマリＳＬＡプロバイダによるＳＬＡプロビジョンリソースレコードの作成を可能とすること；セカンダリＳＬＡプロバイダがヒューマンリソースシステムにアクセスできるようにすること；セカンダリＳＬＡプロバイダのヒューマンリソースが系統的にアグリーメントに署名できるようにすること；セカンダリＳＬＡプロバイダおよび承認されたヒューマンリソースによるワークアベラビリティカレンダの管理／設定を可能とすること；プライマリＳＬＡプロバイダのロジスティックスタイムカバレッジ評価を可能とすること；そしてプライマリＳＬＡプロバイダのプロアクティブなヒューマンリソースブラックアウト期間の調停を可能とすること；の複数機能を実施するものである。
【００２１】
プロビジョン管理機能は、代表的には：ＳＬＡクライアントがサービスプロビジョンリクエストを作成し、プライマリＳＬＡプロバイダへと提出することができるサービスプロビジョンリクエスト機能をイネーブルすること；そして設定されたセカンダリＳＬＡプロバイダと共に、それらの適用可能な価格とサービスプロビジョンディスパッチに指定される適正な人的資源のアベラビリティリストを出力するために用いることができるプライマリＳＬＡプロバイダシステムクエリー機能をイネーブルすること；の複数機能を実施するものである。クエリー基準は選択的なユーザー入力により、または明らかなＳＬＡクライアントサービスプロビジョンリクエストを受信した場合は系統的な入力により生成することができる。
【００２２】
プロビジョン管理機能はさらに、代表的には：プライマリＳＬＡプロバイダがサービスプロビジョンディスパッチリクエストレコードをセカンダリＳＬＡプロバイダへと系統的に提出できるようにすること；セカンダリＳＬＡプロバイダがリソースのアベラビリティを確認できるように、そしてその後プライマリＳＬＡプロバイダにリソースを派遣（ディスパッチ）できるようにすること；およびプライマリＳＬＡプロバイダがＳＬＡクライアントへのリソースの派遣を確認できるようにすること；の複数機能を実施する。
【００２３】
ＳＬＡワークアクナリッジメントおよび品質保証機能は、代表的には：例えば実施される仕事、配備されるマテリアルおよび時期などに関するディテールをサービスプロビジョンディスパッチリクエストに応えて入力するものであるサービスディスポジションバウチャー機能に、セカンダリＳＬＡプロバイダのリソースがアクセスできるようにすること；セカンダリＳＬＡプロバイダがサービスディスポジションバウチャーをレビューおよび承認の処遇決定用にＳＬＡクライアントへと提出することができるようにすること；ＳＬＡクライアントがセカンダリＳＬＡプロバイダサービスディスポジションバウチャーを処理し、品質保証評価情報を提供できるようにすること；そしてＳＬＡクライアントが処遇の決まったセカンダリＳＬＡプロバイダサービスディスポジションバウチャーをプライマリＳＬＡプロバイダへと提出することができるようにすること；の複数機能を実施するものである。
【００２４】
請求／支払い機能は、代表的には：承認されたＳＬＡクライアント承認済みサービスディスポジションバウチャーの系統的抽出；プライマリＳＬＡプロバイダからＳＬＡクライアントへの請求明細書ファイルの系統的生成；セカンダリＳＬＡプロバイダからプライマリＳＬＡプロバイダへの請求明細書ファイルの系統的生成；ＳＬＡクライアントの支払い時におけるプライマリＳＬＡプロバイダ支払い領収書データアップロード機能；そしてＳＬＡクライアントの支払いを前提としたセカンダリＳＬＡプロバイダの機能に対するプライマリＳＬＡプロバイダの支払い発生；を設定された形で可能とする経理データ処理機能を実施するものである。
【００２５】
情報マネジメント／レポート機能は、代表的には一般情報出力機能を実施するものである。この機能は、取得したシステムデータを利用してレポートおよびアナリティクスを生成する。
【００２６】
ここで図を参照するが、図１は物理的な通信／データネットワークのハイレベルブロック図である。図１には、コンピュータネットワークポイントとして５つの主要タイプ、具体的にはブラウザまたは他のユーザーインターフェース（ＵＩ）、通信／ウェブサーバ、アプリケーションサーバ、アプリケーションモジュール、データベースサーバ、およびデータベースが描かれている。代表的な環境としてはホストされたインターネットベースのソリューションが含まれるが、様々な実施例はイントラネットを使いつつワイドエリアネットワーク（ＷＡＮ）に移植することができる。ハードウェアおよびアプリケーションのプログラミングに最小限の変更を加えると、本願に記載の様々な原理の適用はコンピュータ環境という観点に限定されたものではなくなる。
【００２７】
再度図１を見ると、コンピュータシステム１００は、プロキュアメント／ＳＬＡマネジメントシステム１５０と、システムブラウザ１１５（ａ）〜（ｅ）を介してシステムユーザー１１０（ａ）〜（ｅ）が操作できるユーザーシステム１０１〜１０５と、インターネット／イントラネット通信ネットワーク１２０と、データ処理モジュール１６０〜１８０を含むアプリケーションサーバ１５５と、そしてデータベースシステム１８５とを含んでいる。ユーザーシステム１０１〜１０５は、システムの入口であり、通常は最低ログイン／セキュリティ機能とグラフィカルユーザーインターフェース（ＧＵＩ）により代表されるアクセスポータルである。
【００２８】
データ処理モジュール１６０〜１８０は、管理モジュール１６０、プライマリＳＬＡプロバイダモジュール１６５、セカンダリＳＬＡプロバイダモジュール１７０、レーバー（Labor：就労者）モジュール１７５、そして例えばＳＬＡクライアントモジュールを含む。プライマリＳＬＡプロバイダがソリューション全体を購入またはライセンスを得てそのインフラ内部にシステム１００を置いた場合、一部の実施例においては管理モジュール１６０を排除することが可能である。
【００２９】
プライマリＳＬＡプロバイダモジュール１６５はコンピュータシステム１００のビジネス管理者として機能するものであり、代表的な実施例においては、ＳＬＡクライアント、セカンダリＳＬＡプロバイダ、アプリケーションのユーザー、そしてＳＬＡヒューマンリソースレーバーのアップロードを制御する。当業者には明らかなように、プライマリＳＬＡプロバイダとは、ＳＬＡクライアントを持ち、ＳＬＡおよび他のサービスを提供する契約を結び、セカンダリＳＬＡプロバイダとの下請け契約を結び、そして究極的にはＳＬＡプロビジョンの人材および実施されるＳＬＡプロビジョンの仕事品質についての責任を負う企業体である。
【００３０】
セカンダリＳＬＡプロバイダモジュール１７０は、ＳＬＡプロビジョンカバレッジを提供するための下請け契約をプライマリＳＬＡプロバイダと結んでいる企業体の通信および業務処理をサポートするものである。ＳＬＡレーバーモジュール１７５は、下請けしたセカンダリＳＬＡプロバイダと契約する個々のＳＬＡプロビジョンレーバーの通信および業務処理をサポートするものである。ＳＬＡクライアントモジュール１８０は、ＳＬＡプロビジョンを必要とし、契約を結んでいる個々のＳＬＡクライアントの通信および業務処理をサポートするものである。
【００３１】
様々な実施例においては、協調的通信および業務処理能力は、コンピュータシステム１００の一部として描かれた様々な企業体を管理されたリアルタイムデータ処理の一設定にまとめるものである。対照的に、多くの従来システムの場合、これらのビジネス努力を管理することを意図して一般には複数のシステムが利用されている。過去においては、クライアントデータおよび活動は代表的にはカスタマーリレーションシップマネジメント（ＣＲＭ）または他のカスタムアプリケーションにおいて管理され、一方でロジスティクスは何らかのプロジェクトマネジメントアプリケーション中で管理されていた。それと同時に、サプライヤおよびヒューマンリソース管理機能およびディテールは、それらが仮にある場合、通常はさらなるアプリケーション中で管理されるのである。
【００３２】
システム１００は、プライマリＳＬＡプロバイダ、セカンダリＳＬＡプロバイダそしてＳＬＡクライアントを１つの協調的事業環境へと結びつけるプロキュアメント、ロジスティクスマネジメントおよび管理の完全ライフサイクルソリューションである。システム１００は、ＳＬＡプロビジョンロジスティクスプランニング、プロビジョンリソースのスキルレベル／習熟度、プロビジョンリソースのアベラビリティ／能力、ＳＬＡプロビジョンリソースのディスパッチ、ＳＬＡプロビジョンプロセス通信、ＳＬＡプロビジョン品質保証、および投資収益について、プライマリＳＬＡプロバイダがコントロールすることができるように働く。加えて、システム１００は、業者マネジメント、プロキュアメント、経理、財務およびリスク管理を含むがこれらに限られない全ての基幹機能的ビジネスプロセスを統合化することにより、複数ある異種かつ高コストのアプリケーションの使用を回避することができる。
【００３３】
図２Ａおよび図２Ｂは、アウトソーシングしたサービスレベルアグリーメント（ＳＬＡ）および非ＳＬＡデリバラブルをマネジメントするシステムおよび方法のハイレベルなエンドツーエンドのフロー図である。図２Ａにおいては、プロセスフロー２００はステップ２０２から始まる。ステップ２０２においては、プライマリＳＬＡプロバイダが、１つ以上の地理的ロケーションにある１つ以上のＳＬＡクライアントに関して定義された、または予想される特定のサービスコールデリバラブルを持っている。ステップ２０４においては、ＳＬＡクライアントおよびセカンダリＳＬＡプロバイダに対応するマスタデータが設定される。ステップ２１０においては、潜在的なセカンダリＳＬＡプロバイダの価格およびリソース能力を確認するためにＳＬＡ要件レコードからＲＦｘビッドが作成される。ステップ２１２においては、ＲＦｘ応答がレビューされ、サービスプロビジョン能力および価格に基づいてビッド落札が決定される。ステップ２１４においては、適切なサービスプロバイダと最終価格およびサービスデリバラブル条件を交渉する。
【００３４】
ステップ２１６においては、適切なセカンダリＳＬＡプロバイダへのブランケットパーチャスオーダーが設定される。ステップ２１８においては、ＳＬＡプロビジョンマトリクスが設定され、セカンダリＳＬＡプロバイダのブランケットパーチャスオーダーが系統的にＳＬＡマスタデータレコードにアフィリエイトされる。プライマリＳＬＡプロバイダはマトリクスに対する編集コントロールを維持しており、例えばセカンダリＳＬＡプロバイダが非競争入札プロセスにより特定された場合、手動で関係を構築することができる。ステップ２２０においては、適切なセカンダリＳＬＡプロバイダがプライマリＳＬＡプロバイダにリソース候補を提出する。承認されたリソースは、それぞれのセカンダリＳＬＡプロバイダブランケットパーチャスオーダーへと関連付けられる。ステップ２２２においては、セカンダリＳＬＡプロバイダにヒューマンリソース（ＨＲ）承認が通知される。ステップ２２４においては、セカンダリＳＬＡプロバイダリソースライブラリにデータが投入され、システムにより提供されるリソースの日／時間アベラビリティスケジュールが設定される。
【００３５】
ステップ２２６においては、セカンダリＳＬＡプロバイダのヒューマンリソースにシステムアクセス信用証明が付与される。ステップ２２８においては、セカンダリＳＬＡプロバイダのヒューマンリソースがシステム１００にアクセスし、アグリーメントに署名、そしてクライアントＳＬＡ設備アクセス要件ルールをアクナリッジする。ステップ２３０においては、ＳＬＡクライアントの要求をマネジメントするためのプライマリＳＬＡプロバイダの準備が完了する。
【００３６】
次に図２Ｂを参照すると、実行処理はステップ２３０からステップ２４０へと進む。ステップ２４０においては、ＳＬＡクライアントのユーザーがサービスプロビジョンリクエストを作成し、それをプライマリＳＬＡプロバイダへと提出する。ステップ２４２においては、プライマリＳＬＡプロバイダのユーザーがＳＬＡ管理モジュール１６０に入る。ステップ２４４においては、システム１００にクエリーが送られ、システムがＳＬＡクライアントサービスプロビジョンリクエストに対するサービスを提供するように設定された全セカンダリＳＬＡプロバイダのリストを返す。ステップ２４６においては、サービスプロバイダリストが、例えば承認されたサービスプロバイダのリソース、リソースのアベラビリティ、ブランケットパーチャスオーダーの参照とコントラクトサービス料金、および適用可能な過去のパフォーマンスデリバリマトリクスを表示する。ステップ２４８においては、セカンダリＳＬＡプロバイダレコートが選択される。ステップ２５０においては、プライマリＳＬＡプロバイダのユーザーがサービスプロビジョンディスパッチリクエストをセカンダリＳＬＡプロバイダに提出する。ステップ２５２においては、セカンダリＳＬＡプロバイダがディスパッチ可能性を確認する。
【００３７】
ステップ２５４においては、プライマリＳＬＡプロバイダがＳＬＡクライアントのユーザーに確認を送付する。ステップ２５６においては、セカンダリＳＬＡプロバイダが対応できるリソースをＳＬＡクライアントロケーションへと派遣する。ステップ２６０においては、サプライヤのリソースがＳＬＡクライアントロケーションにて仕事を実施する。ステップ２７０においては、サプライヤリソースが設定されたデータ要件をＳＬＡタイムキーピング／デリバリモジュールへと入力する。ステップ２７２においては、セカンダリＳＬＡプロバイダリソースデリバリバウチャーがＳＬＡクライアントのユーザーに提出される。ステップ２７４においては、ＳＬＡクライアントのユーザーが提出されたバウチャーを処理し、デリバラブル評価を入力する。ステップ２７６においては、バウチャーがプライマリＳＬＡプロバイダへと提出され、承認される。ステップ２７８においては、系統的に設定された承認バウチャーのディテール抽出が生じ、ＳＬＡクライアントへの請求ファイルが生成される。ステップ２８２においては、請求ファイルがＳＬＡクライアントへと伝送される。ステップ２８４においては、ＳＬＡクライアントがプライマリＳＬＡプロバイダに支払いを実行する。ステップ２８６においては、プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダに支払いを実行する。
【００３８】
図３はプライマリＳＬＡプロバイダのユーザー向けウェブホームページの説明図である。図３においては、ＵＩ３００はユーザーナビゲーションバー／メニュー３１０およびアクティビティダッシュボード３２０の２つの主要部分へと区分化されている。ナビゲーションバー／メニュー３１０は、所望に応じてアプリケーション機能をアクティブ化するための主要ＵＩモードであり、アクティビティダッシュボード３２０は注目を要する特定のビジネスアクティビティをハイライト／プロンプトするためにユーザーが利用するものである。ユーザーはユーザーナビゲーションバー／メニュー３１０またはアクティビティダッシュボード３２０のいずれを介しても同じアプリケーション機能およびフォームへと行くことができる。
【００３９】
マスタデータ機能の代表的な情報の態様は、一般ビジネス情報、ロジスティクスコントロール情報、ＳＬＡコントラクト情報、およびＳＬＡプロビジョンディテール情報である。一般ビジネス情報は、プライマリＳＬＡプロバイダおよびＳＬＡクライアントに関する情報を含んでいる。一般ビジネス情報の格納に利用されるデータベーステーブル例を表１、２、８、９、２７および２９に示した。一般ビジネス情報の例としては、企業タイプ、法人ＩＤ、事業ロケーション、企業規模、従業員数およびユーザー情報に関するビジネス情報要素が含まれる。物理的な地理上のロケーションは、例えば表１０〜表１３に示したようなデータベース設定の観点から定義される。メールコード、または商業地区などの他の一意の設定を含むように拡張可能な、この地理スキーマは、国（Country）、地方（Region）、群（County）、および町／居留区（City）という観点からロケーションを定義することができる。
【００４０】
ロジスティクスコントロール情報は、ＳＬＡプロビジョニングという意味におけるプライマリＳＬＡプロバイダのビジネスモデル基本定義を表すものである。様々なタイプの情報が定義されており、その情報の１グループはプロビジョンサービスタイプ、プロビジョンレーバータイプ、プロビジョン時間フレーム、プロビジョンマテリアルおよびプロビジョンマテリアル備蓄施設に関するものである。ロジスティクスコントロール情報の格納に使用されるデータベーステーブル例を表３〜表７と表８８および表８９に示した。
【００４１】
特定のプライマリＳＬＡプロバイダが使うデータ値は選好的なものであり、産業によっても、企業によっても大きく異なることがある。格納テーブルは特定の取引レコードを管理する一方でプライマリＳＬＡプロバイダが利用することができる基本データを示している。従ってコンフィギュレーションデータは、プライマリＳＬＡプロバイダが遭遇する潜在的なデータ値をプロビジョンサービスタイプおよびプロビジョンＳＬＡ応答時間フレームという意味において定義するためのソースライブラリと見ることができる。ロジスティクスコントロール情報のソースとして定義される他の情報グループは、ＳＬＡジョブディスクリプションソースライブラリ、ＳＬＡプロビジョンスキルプロフィールライブラリ、そしてＳＬＡプロビジョンディテール−ＳＬＡプロビジョンスキルプロフィールマトリクスである。
【００４２】
情報（例えばＳＬＡジョブディスクリプションソースライブラリ、ＳＬＡプロビジョンスキルプロフィールライブラリおよびＳＬＡプロビジョンディテール−ＳＬＡプロビジョンスキルプロフィールマトリクス）は、代表的にはプライマリＳＬＡプロバイダのリソースにより集合的ＳＬＡクライアントに対して提供されるサービスプロビジョンに適用可能なビジネスまたは技術適性に関するディテールを含む。上記に説明したロジスティクスコントロール情報要素がどのようにビジネスを運営するのかを説明するものである一方、このコントロールデータはその努力活動のプロビジョン分野は何なのかを定義するものである。ＳＬＡプロビジョンリソーススキルプロフィール情報を格納するために用いられるデータベーステーブル例には表２３〜表２６が含まれる。これらのテーブルは、プライマリＳＬＡプロバイダにより作成された特定のＳＬＡリソースプロビジョンスキル／属性プロフィールのＩＤと、そのプロフィールに適用可能なディテールとを格納している。
【００４３】
表２６は、必要であると認められた場合、あらゆる適用可能なマテリアルのマスタレコードをプロビジョンリソースプロフィールへと具体的にマッピングするものである。これに適した代表的な例は、ガス燃焼発電機の製造企業である。このような場合、特定のＳＬＡプロビジョンプロフィールが修理技師または工事担任者について作成される。また、その製造企業は特定の発電機モデルのみをそのＳＬＡプロビジョンプロフィールに指定することを望むこと、そしてさらには、そのＳＬＡプロビジョンプロフィールに取り扱いに対する技術習熟度を持っていることが含まれていなければならない特定の装置部品を指定したいと望むことがある。
【００４４】
表２３〜表２５からわかるように、これらのテーブルに含まれるデータ要素のほとんどがテキストフィールドではなく整数であり、その理由はシステム１００がＳＬＡリソースプロビジョンスキル／属性プロフィールテーブルのソースとして作用する階層的データライブラリにより明確に定義されているためである。リソースライブラリデータは表１４〜表２２に含まれている。表１４〜表２２は、スキルセットプロフィールデータを含む一方、表２３〜表２５は特定の設定・保存されたＳＬＡプロビジョンリソースプロフィールに関わる情報を含むものである。明確に説明されてはいないが、スキルセットプロフィール作成に関連するソースデータは、プライマリＳＬＡプロバイダの必要に合わせるためにこのデータ環境へと導入することができる。
【００４５】
上記にステップ２０２〜ステップ２０４で概要を記載したマスタデータ機能は、これらに基づいて全ＳＬＡプロビジョニングアクティビティがこれらによりマネジメントされる基本的な拠りどころを表すものである。上述した説明においては、プライマリＳＬＡプロバイダは、例えば何のビジネスをしているのか、どのようにビジネスをしているのか、クライアントサービスの提供に用いているビジネス／技術リソースのタイプ、および通常はどこでビジネスを行っているのか、について定義する。図４〜図９および表１〜表３６は、マスタデータ機能についてのさらなる情報を提供するものである。
【００４６】
図４は、ＳＬＡクライアントマスタデータ機能のハイレベル機能性を説明するフロー図である。データレコードタイプの作成は、図４では線形処理として説明されている。説明されているプロセスは、必須事項でも制約でもなく、一般的な理解を得る目的に限りこのように示したものである。当業者には明らかなように、特定のデータレコードタイプはマスタデータレコード前提条件に論理的に依存するものである。例えば、関連付けるＳＬＡクライアント企業体レコードが存在しなければ、ＳＬＡクライアントのユーザー情報をロードすることは不可能である。
【００４７】
図４に戻ると、プロセスフロー４００はステップ４０２から始まる。ステップ４０２においては、ＳＬＡクライアントレコードが手動またはデータフィードにより作成される。ステップ４０４においては、ＳＬＡクライアントビジネスデータが手動またはデータフィードによりロードされる。ステップ４０４では、ＳＬＡクライアントユーザーデータが手動またはデータフィードによりロードされる。ステップ４０８においては、ＳＬＡクライアントロケーションが手動またはデータフィードによりロードされる。ステップ４１０においては、ＳＬＡクライアントコントラクトがロードされる。ステップ４１２においては、ＳＬＡクライアントプロビジョニングレコードが作成される。ステップ４１４においては、適用可能なＳＬＡクライアントプロビジョニングマテリアルレコードが作成される。ステップ４１６においては、ＳＬＡクライアントパーチャスオーダーレコードが作成される。ステップ４１８においては、ＳＬＡクライアントプロビジョニングレコードがパーチャスオーダーと関連付けられ、パーチャスオーダー行項目が作成される。
【００４８】
図５はＳＬＡプロビジョンレーバープロフィールの作成およびライブラリへの格納プロセスを説明するフローチャートである。一般に、このプロフィールはヒューマンリソースレーバー（就労者）が、プライマリＳＬＡプロバイダの製品またはシステムに関連するプロビジョニングサービスを実施するために必要とするスキル属性を表すものである。図５において、プロセス５００はステップ５０２から始まる。ステップ５０２においては、プライマリＳＬＡプロバイダのユーザーが、ホームページから「ＳＬＡサービスプロビジョンスキルプロフィール」コントロールに入る。ステップ５０４においては、ユーザーは「新たなプロビジョンスキルプロフィールの作成」コントロールを選択する。ステップ５０６においては、ユーザーはプルダウンリスト表示から「ビジネスセクタ」を選択する。ステップ５０８においては、ユーザーは限定されたプルダウンリスト表示から「ビジネスアリーナ」を選択する。ステップ５１０においては、ユーザーは限定されたプルダウンリスト表示から「ビジネスファミリ」を選択する。
【００４９】
ステップ５１２においては、ユーザーは限定されたプルダウンリスト表示から「総合機能」を選択する。ステップ５１４においては、ユーザーは限定されたプルダウンメニューから「スキル／属性」を選択する。ステップ５１６においては、ユーザーがソースデータライブラリ中に含まれていないカスタム認証、属性などを付加する。ステップ５１８においては、ユーザーがサービスプロフィールをマテリアルマスタレコードと関連付け、要求される習熟度を指定する。ステップ５２０においては、ユーザーがジョブタイトルおよびオプションの文章による記述を付加する。ステップ５２２においては、ユーザーは作成したレコードを保存する。ステップ５２４においては、ジョブタイトルが一意のものであるかどうかが判定される。もし一意であれば、処理はステップ５２６へと進み、レコードがＳＬＡプロビジョンレーバープロフィールライブラリ中に格納される。ステップ５２４においてジョブタイトルが一意ではないと判定された場合、処理はステップ５２０へと戻る。最適化された環境において、プライマリＳＬＡプロバイダは全てのプロビジョニング義務を充当するサービスプロフィールの完全なリストを作成する。
【００５０】
図６は、ＳＬＡプロビジョンマテリアルの作成およびライブラリへの格納のプロセスを説明するフロー図である。図６においてプロセス６００はステップ６０２から始まり、このステップにおいてプライマリＳＬＡプロバイダのユーザーがＳＬＡプロビジョンマテリアルモジュールに入る。ステップ６０４においては、ユーザーが「新たなマテリアルマスタレコードの作成」を選択する。ステップ６０６においては、ユーザーがマテリアル略称を指定する。ステップ６０８においては、ユーザーがマテリアルの説明を指定する。ステップ６１０においては、ユーザーがマテリアルは機能であるか完成品であるかを指定する。ステップ６１２においては、ユーザーがマテリアルに在庫があるかどうかを指定する。ステップ６１４においては、ユーザーがマテリアルの製造者を指定する。ステップ６１６においては、ユーザーがマテリアルの最終コストを指定する。ステップ６１８においては、ユーザーがマテリアルの最終コスト日付を指定する。ステップ６２０においては、ユーザーがマテリアルの在庫数を指定する。ステップ６２２においては、ユーザーがマテリアルの補充ストックポイントを指定する。ステップ６２４においては、ユーザーがマテリアルの補充ストック量を指定する。ステップ６２６においては、ユーザーが設定を保存する。
【００５１】
ステップ６２８においては、マテリアルがストックされたマテリアルであるかが判定される。ステップ６２８においてストックされていると判定された場合、処理はステップ６３０へと進む。ステップ６３０においては、ロケーションレコードの選択を可能とするＧＵＩがユーザーに提示される。ステップ６３２においては、ユーザーがロケーションを選択し、在庫数を定義する。ステップ６３４においては、ユーザーが設定保存を選択する。ステップ６３６においては、保存された設定がＳＬＡプロビジョンマテリアルライブラリに格納される。ステップ６２８においてマテリアルにストックがあると判定されなかった場合、処理はステップ６３６へと進む。
【００５２】
ジョブディスクリプションの様々な態様を、例えば非文章的な、即ちデータベースのタームとして定義することができる。それがプライマリＳＬＡプロバイダの所望するビジネスモードである場合、単純なジョブディスクリプションプロファイリングをイネーブルすることができる。このような場合、スキルプロファイリングツールを迂回して、ＳＬＡクライアントサービスのプロビジョンに必要とされるスキルを表す定義付けられたジョブタイトルおよびディスクリプションのアップロードまたは手動作成が可能である。図５および図６は、これらの概念を説明するものである。
【００５３】
ロジスティクスコントロール情報の定義はプライマリＳＬＡプロバイダのコアコンピテンシーを中心としたものである。よって特定のＳＬＡクライアントのプロビジョニングの必要性という文脈の外においては、可能なプロビジョニングサービスの範囲を、レーバー、保証、時間、機器などについて定義および文書化することが論理的であり、その定義はこの情報マネジメント努力活動において作られるのである。
【００５４】
システム１００は、プライマリＳＬＡプロバイダがＳＬＡクライアントコントラクトに関する基本ディテールをアップロードまたは入力することができる参照サイクルを実行する。表２８は、特定のコントラクトに関して格納されたハイレベル情報の事例を示す。データのほとんどは基本ビジネス情報であるが、しかしながら表２８はこのコントラクトレコードに適用可能な具体的個別プロビジョニングサービスも複数格納している。このプロビジョニング計数の理由の１つは、プロセスの進行に従い、プロビジョニングネットワークに欠落が無いように、そして確実に全ての契約サービスが実行され、責任が全うされるようにするためである。基本コントラクトデータの入力後、プライマリＳＬＡプロバイダは、より正確なＳＬＡプロビジョンディテールレコードを作成する基準ポイントとして、特定のＳＬＡコントラクトレコードを使用することができるようになる。表３０〜表３３を参照のこと。
【００５５】
図７はＳＬＡプロビジョンレコードに関わる作成および格納プロセスを説明するフロー図である。図７において、プロセスフロー７００はステップ７０２から始まり、このステップにおいてプライマリＳＬＡプロバイダがコントラクトデータフィールドをロードし、tblSLAclientContract（表２８参照）中にレコードを作成する。プロセス７００は例えば基本コントラクト情報の入力から続く線形処理であっても、複数のＳＬＡコントラクトレコードのリスト表示の中からＳＬＡクライアントまたは他の変数によりフィルタされた特定のＳＬＡコントラクトレコードをユーザーが選択することができるＧＵＩがユーザーに提示されるようになっていてもよい。
【００５６】
ステップ７０４〜ステップ７０８は、ＳＬＡプロビジョンディテールレコードの作成に関するものである。ステップ７０４においては、システムＧＵＩが関連するＳＬＡプロビジョンディテールレコードを作成するようにユーザーにプロンプトする。ステップ７０６においては、ユーザーが「ＳＬＡプロビジョンディテールの作成」コントロールをアクティブ化する。ステップ７０８においては、システム１００がＳＬＡクライアントコントラクトレコードからのデフォルトデータを新たなレコードに投入する。
【００５７】
ステップ７１０〜ステップ７１２は、アプリケーションコンフィギュレーションを通じ、例えば表３中に格納された可能な値で既に確立されているはずの特定のプロビジョンタイプの選択に関するものである。ステップ７１０においては、システム１００がプロビジョンタイプを選択するようにユーザーにプロンプトする。ステップ７１２においては、ユーザーがプロビジョンタイプを選択し、入力を保存する。
【００５８】
ステップ７１４〜ステップ７１６は、アプリケーションコンフィギュレーションを通じ、例えば表４中に格納された可能な値で既に確立されているはずの特定のプロビジョンレーバータイプの選択に関するものである。ステップ７１４においては、システム１００がプロビジョンレーバータイプを選択するようにユーザーにプロンプトする。ステップ７１６においては、ユーザーがプロビジョンレーバータイプを選択し、入力を保存する。
【００５９】
ステップ７１８〜ステップ７２０は、ＳＬＡアクティビティの請求可能性または請求不可性に関するユーザー仕様に関するものである。請求不可なアクティビティとは、例えば保証サービスを命じるコントラクトの場合を言う。ステップ７１８においては、システム１００がユーザーに請求可能または請求不可プロビジョンを指定するようにプロンプトする。ステップ７２０においては、ユーザーが請求可能または請求不可を指定し、入力を保存する。処理はステップ７２０からステップ７２２へと進む。
【００６０】
ステップ７２２〜ステップ７２４は、このレコードに対する時間制約の適用可能性に関するユーザー指定についてのものであり、ここではステップ７２４からの決定経路が「イエス」である場合を説明する。ステップ７２２においては、システム１００がユーザーに応答時間が必要であるかどうかを指定するようプロンプトする。ステップ７２４においては、ユーザーが、応答時間が必要であるかどうかを指定し、入力を保存する。
【００６１】
ステップ７２６〜ステップ７２８は、アプリケーションコンフィギュレーションを通じ、例えば表５中に格納された可能な値で既に確立されているはずの特定のプロビジョンサービス応答時間の選択に関するものである。このＳＬＡサービス応答時間とは、ＳＬＡクライアントからの問題発生通知からＳＬＡサービスプロバイダによるサービスの実施までの時間差であり、これは両者間で確立され、適用可能なＳＬＡコントラクトで文書化されていることが一般的である。ステップ７２６においては、システム１００が適用可能であれば応答時間メトリック（測定基準・単位）を指定するようにユーザーにプロンプトする。ステップ７２８においては、ユーザーが必要応答時間またはメトリックを指定し、入力を保存する。
【００６２】
ステップ７３０〜ステップ７３２は、望まれた場合における特定のディテール、コントラクト情報または一般情報のユーザー説明コメント入力に関する。ステップ７３０においては、システム１００が「プロビジョンディテール説明」を完成するようにユーザーにプロンプトする。ステップ７３２においては、ユーザーが「ディテール」を入力し、その入力を保存する。
【００６３】
ステップ７３４〜ステップ７３６は、プライマリＳＬＡプロビジョンコストのユーザー指定／見積もりに関する。ステップ７３４においては、システム１００がプロビジョニングのコストを提示するようにユーザーにプロンプトする。ステップ７３６においては、ユーザーがプロビジョニングのコストを入力し、その入力を保存する。
【００６４】
ステップ７３８〜ステップ７４０は、適用されるＳＬＡプロビジョンサービスの発生件数のユーザー指定／見積もりに関する。基本的なロジスティクスプランニングでは、通常そのような予想が要求される。そのような情報は後に続くＲＦｘビッドプロセスに直接的な影響を持つ。情報は数量からなり、これを通じて最良の交渉価格を確定するためにサービスプロバイダがリソースアベラビリティの計画を立て、ビッドプロセスを利用する。ステップ７３８においては、システム１００が予想または予定されるサービスプロビジョン頻度を指定するようにユーザーにプロンプトする。ステップ７４０においては、ユーザーがプロビジョン頻度予想を入力し、入力を保存する。
【００６５】
ステップ７４２〜ステップ７４６に説明されるプロセスにおいては、ユーザーはＳＬＡプロビジョンディテールレコードと関連付ける特定のＳＬＡプロビジョンスキルプロフィールを選択するようにプロンプトされる。ユーザーは、ＳＬＡプロビジョンスキルプロフィールを選択するか、もしくは上述したようにプライマリＳＬＡプロバイダがこのモードの利用を選ぶ場合には格納されたジョブタイトルを選択するか、のオプションを持っている。このプロセスは先に格納されたレコードの選択について説明しているが、システム１００はＳＬＡプロビジョンスキルプロフィールのジョブタイトル／説明のいずれかの可変的作成をサポートするものであってもよい。最良の実施例によれば、先に作成され、格納されたＳＬＡリソースプロビジョンプロフィールレコードは、プライマリＳＬＡプロバイダのビジネスダイナミクスに基づいたものである。先に保存されたリソースプロフィールレコードのディテールは、例えば表２３〜表２５に格納されている。ステップ７４２においては、システム１００が、適切なＳＬＡサービスプロビジョンスキルプロフィールまたはジョブタイトルを指定するようにユーザーにプロンプトする。ステップ７４４においては、ユーザーが「プロフィール」／「ジョブタイトル」をプルダウンメニューから選択する。ステップ７４６においては、システム１００がプロビジョンディテール−レーバープロフィールの関連付けを保存するようにユーザーにプロンプトし、ユーザーはその関連付けを保存する。
【００６６】
ステップ７４８〜ステップ７５０に記載のプロセスにおいては、ユーザーが適切なＳＬＡクライアントプロビジョンサービス施設／ロケーションを選択し、関連付けるようにプロンプトされる。ステップ７４８においては、ユーザーは適切なクライアントＳＬＡサービスロケーションを指定するようにプロンプトされる。ステップ７５０においては、ユーザーがクライアントＳＬＡロケーションをプルダウンメニューから選択し、入力を保存する。
【００６７】
ステップ７５２〜ステップ７６０に記載のプロセスの間、ユーザーはＳＬＡプロビジョンディテールレコードについて存在し得るいずれかのマテリアル関係を選択するようにプロンプトされる。ステップ７５２は代表的には単純な「イエス／ノー」プロンプトであり、ステップ７５２においては説明の便宜上「イエス」が選択されている。ステップ７５２では、システム１００がＳＬＡプロビジョンマテリアル要件のいずれかを指定するようにユーザーにプロンプトする。ステップ７５４においては、ユーザーがマテリアルをプルダウンメニューから選択する。ＳＬＡプロビジョンスキルプロフィールと、例えば表２６中にあるマテリアルマスタレコードとの間に先に確立した関係により、デフォルトのマテリアルリストが提示される。このようなリストは最適ビジネス処理モードとして提供されるが、ユーザーは所望すれば全マテリアルマスタリストにアクセスすることができるため、これが必ずしも制約になることはない。
【００６８】
ステップ７５６〜ステップ７５８に記載のプロセスの間、ユーザーはいずれかの選択されたマテリアルマスタレコードに適用可能なコンフィギュレーション設定を確立するようにプロンプトされる。ユーザーは例えばそのマテリアルの請求可能性／請求不可性、保証商品、在庫商品、ストック要件などを表示する。当業者には明らかなように、表３１に示されたコンフィギュレーション属性は限定されたものではなく、アプリケーションおよびデータベースにはさらなる属性を付加することが可能である。ステップ７５６においては、ユーザーがストック要件や保証指定などのＳＬＡマテリアル要件を設定するようにプロンプトされる。ステップ７５８においては、ユーザーがマテリアルのレコードを設定する。ステップ７６０においては、ユーザーが設定およびマテリアルの関連付けを保存する。
【００６９】
ステップ７６２〜ステップ７６８に記載のプロセスの間、ユーザーはＳＬＡプロビジョンディテールレコードを保存し、名称をつけるようにプロンプトされる。プロセスフローは明確にはこの機能を描いてはいないが、プライマリＳＬＡプロバイダのユーザーはレコードを一時的なステータスで保存しておき、別の時点で完成させることができる。この場合データベースは、完了または未完了、およびアクティブまたはインアクティブのステータスコードにより履歴を維持する。ステップ７６２においては、システム１００がプロビジョンディテールレコードを保存するようにユーザーにプロンプトし、ユーザーはレコードを保存する。ステップ７６４においては、システム１００がプロビジョンディテールネームを指定するようにユーザーにプロンプトする。ステップ７６６においては、ユーザーがプロビジョンディテールネームを入力し、入力を保存する。ステップ７６８においては、ＳＬＡプロビジョンディテールレコードが作成され、格納される。
【００７０】
ＳＬＡクライアントから何の要求も生成されなければ、プライマリＳＬＡプロバイダがＳＬＡコントラクト情報能力を使うことは一般には期待されない。通常は、サービスレベルアグリーメントはコントラクトを通じて管理されている。ＳＬＡコントラクトのディテールは一般に別個のコントラクトマネジメントアプリケーション中にあり、企業プロキュアメント、プロジェクトマネジメント、または経理データ処理アプリケーションとの、アプリケーション間横断能力が限られている、またはまったく無いことから、プロビジョニングアクティビティを、実行されたコントラクトとリンクし、参照するというビジネス要求があるのは明らかである。多くの場合、コントラクトディテールは紙面上にしか存在しない。よって基本コントラクトディテールを、特定のＳＬＡアクティビティを実際に管理するアプリケーション中に入力することは、標準的なビジネスの手続きからの改良である。これら基本コントラクトディテールをマネジメントアプリケーションに入力することにより、ダウンストリームのＳＬＡおよび管理データ処理アクティビティを、元のＳＬＡコントラクトへと通じるビジネスの「スレッド（糸）」を維持した形で実施することが可能なのである。
【００７１】
図８は、ＳＬＡクライアントパーチャスオーダーに関わる作成および格納プロセスを説明するフロー図である。図８に関連して説明するパーチャスオーダー情報は、ＳＬＡプロビジョンアウトソースプロキュアメントプロセスとは区別される。多くの企業体は、経理取引を制御された経理システムの保護下で実施することを好む。残念なことに、ＳＬＡプロビジョンワークの複雑な性質により、多くのコントロールディテールをＳＬＡコントラクトから経理システムへと移植／移動させることができずにおり、その理由はほとんどの経理／プロキュアメントシステムが、簡単に言えば、数量−コストモードで設定されているためである。この結果、通常は実際のディテールはコントラクト中にあり、そして実際上の経理システムは経理取引データ典拠レコードを格納することになる。
【００７２】
様々な実施例は、多数の用途向けにこのＳＬＡコントラクトディテールの抽出をかなえるものであり、そのうちの１つはパーチャスオーダープロセスの最良の実施例を確立するものである。最終的に多くのＳＬＡプロビジョンアクティビティが請求可能取引となる。従ってこのビジネスニーズを予見し、特定のＳＬＡプロビジョンディテールレコードと、ＳＬＡクライアントおよびプライマリＳＬＡプロバイダのために作成されたパーチャスオーダーとの間に関係を確立して経理取引を実施することは、論理的に理にかなうことなのである。
【００７３】
再度図８を参照すると、プロセスフロー８００はステップ８０２から開始され、このステップにおいてプライマリＳＬＡプロバイダがプロビジョンディテールレコードの設定を完了する。ステップ８０２は、先のＳＬＡプロビジョンディテール情報に関する部分で説明した前提条件アクティビティを表す。処理はステップ８０２からステップ８０４へと進む。
【００７４】
ステップ８０４〜ステップ８０８は、プライマリＳＬＡプロバイダのユーザーが、それぞれのＳＬＡクライアントパーチャスオーダーとは無関係なＳＬＡプロビジョンディテールレコードへのアクセスを得、そして所望に応じてそのようなアフィリエーションを作る特定のレコードを選択するプロセスを説明している。ＳＬＡプロビジョンディテールレコードは、経理システム支払い認可レコードのない特定のＳＬＡクライアントについて特定される。このプロセスにおいては、ユーザーは、例えばＳＬＡクライアント名称、日付、プライマリＳＬＡクライアントのユーザーといったデータベースフィルタを利用して出力されるレコードセットを絞り込むことができる。システム１００は、経理取引処理機構を確立するようにプライマリＳＬＡプロバイダのユーザーにプロンプトする。ステップ８０４においては、システム１００がプロビジョンディテールレコードをパーチャスオーダーと関連付けるようにプライマリＳＬＡプロバイダのユーザーにプロンプトする。ステップ８０６においては、ユーザーがパーチャスオーダーに関連付けられていないプロビジョンディテールレポートにアクセスする。ステップ８０８においては、ユーザーがＧＵＩを介して限定されたプロビジョンディテールレコードを選択する。
【００７５】
ステップ８１０においては、ユーザーが「ＳＬＡクライアントパーチャスオーダー」コントロールをアクティブ化する。ステップ８１２においては、システム１００が、新たな未決状態のパーチャスオーダーを生成する。ステップ８１４においては、パーチャスオーダー行がＳＬＡプロビジョンディテールレコードからディテールを継承する。ステップ８１０〜ステップ８１４は、フロー８００の間に作成できるものが、新たなパーチャスオーダーレコードに限られていることを示唆するものではない。明確には描かれていないが、既存のＳＬＡクライアントパーチャスオーダーレコードを表示、選択することは可能であり、これはＳＬＡクライアントの推奨するモードによりマスタブランケットパーチャスオーダーを利用することになった場合である。ステップ８１０〜ステップ８１４に説明するプロセスの際立つ特徴を曖昧にしないために、このプロセスを新たなパーチャスオーダーレコードの作成として表現したものである。ステップ８１０〜ステップ８１４に説明したプロセスにおいては、特定の設定されたＳＬＡプロビジョンディテールレコード要素が、通常は自動的にパーチャスオーダー行中に投入される。同様の態様において、特定のＳＬＡコントラクトディテールは設定されたように、パーチャスオーダーヘッダに置かれる。
【００７６】
ステップ８１６〜ステップ８２６は、プライマリＳＬＡプロバイダのユーザーがパーチャスオーダーに適用可能な従来の経理情報を完成させるプロセスを説明している。説明される情報要素の例には、パーチャスオーダー最高消費額、サービスレーバー料率およびマテリアル料率が含まれる。ステップ８１６においては、システム１００がパーチャスオーダー最高消費額を指定するようにユーザーにプロンプトする。ステップ８１８においては、ユーザーが最高消費額を指定し、入力を保存する。ステップ８２０においては、システム１００がサービスレーバー請求料率を指定するようにユーザーにプロンプトする。ステップ８２２においては、ユーザーがレーバー請求料率を指定し、入力を保存する。ステップ８２４においては、システム１００がマテリアル請求料率を指定するようにユーザーにプロンプトする。ステップ８２６においては、ユーザーがマテリアル請求料率を指定し、入力を保存する。
【００７７】
ステップ８２８〜ステップ８３０はパーチャスオーダーを保存する基本ステップである。プロセス８００のこの段階においては、パーチャスオーダーは未だアクティブにはなっていない。ステップ８２８においては、システム１００が完成したパーチャスオーダーを保存するようにユーザーにプロンプトする。ステップ８３０においては、ユーザーが完成したパーチャスオーダーを保存する。
【００７８】
ステップ８３２〜ステップ８４０は、ＳＬＡクライアントのパーチャスオーダー取り扱いおよび承認プロセスを表している。ステップ８３２においては、例えばステップ８３０においてレコードに付随するステータスコードによりトリガされることで、システム１００が完成したパーチャスオーダーを設定されたＳＬＡクライアントのユーザーへと送付する。通知が、例えばｅメールおよびシステムダッシュボード更新により発行される。ステップ８３４においては、ＳＬＡクライアントのユーザーがＧＵＩを介して未決のパーチャスオーダーにアクセスする。ステップ８３６においては、ＳＬＡクライアントのユーザーがパーチャスオーダーデータを検証する。ステップ８３８においては、システム１００がパーチャスオーダーの承認およびＳＬＡクライアントパーチャスオーダーナンバの割り当てを実施するようにＳＬＡクライアントにプロンプトする。ステップ８４０においては、ＳＬＡクライアントユーザーがパーチャスオーダーを承認し、ＳＬＡクライアントパーチャスオーダーナンバを割り当てる。ステップ８３６〜ステップ８４０では、ＳＬＡクライアントのユーザーがパーチャスオーダーデータの有効性を認めなかった場合のシナリオを明確には示していない。しかしながらシステム１００は、修正を要する場合、またはデータ要素が争われている場合においては、やり取りを実施する機能を提供するものである。システム１００中には協調的な有効性の検証および承認プロセスが含まれており、このプロセスが後のデータ処理アクティビティにおける適正なデータを促進し、保証している。
【００７９】
ステップ８４２〜８４８は、プライマリＳＬＡプロバイダのユーザーがＳＬＡクライアントパーチャスオーダープロセスを完了させ、そしてパーチャスオーダーをシステム１００中で検証するためにとるアクションを表している。ステップ８４２においては、システム１００が承認されたＳＬＡクライアントパーチャスオーダーをプライマリＳＬＡプロバイダへと返送する。通知が、例えばｅメールおよびシステムダッシュボード更新により発行される。ステップ８４４においては、プライマリＳＬＡプロバイダのユーザーがＧＵＩを介して承認されたパーチャスオーダーにアクセスする。ステップ８４６においては、システム１００がプライマリＳＬＡプロバイダのユーザーに、パーチャスオーダーをアクティブ化するようにプロンプトする。ステップ８４８においては、プライマリＳＬＡプロバイダのユーザーがパーチャスオーダーをアクティブ化する。
【００８０】
マスタデータサポート用データベースモデルを図９に示した。当業者には明らかなように、このサポート用データモデルおよびアプリケーションモジュールは、基本的にＳＬＡプロビジョニングサービスを実施するためのフレームワークとして働く。統合データモデルは、ビジネスを最適な形で実施するために必要な、主要かつ基本的なビジネス情報の態様を集約する一方、ビジネス情報の本質的にリレーショナルな性質を表現するものである。先に述べたように、これらの本質的にリレーショナルなビジネス情報の態様は従来、もともと相互にコミュニケーションすることのない、本質的に異なるデータ処理システム中にあったのである。このアプリケーションモジュールとこれをサポートするデータベーススキーマのお陰で、現在ではプライマリＳＬＡプロバイダは、例えばコントラクト、契約要員、物理ロケーション、必要とされるプロビジョニングレーバー属性、ロジスティクスパラメータ、実施しない場合のペナルティ、および経理処理認可などを考慮しなければならない彼等のビジネスダイナミクスを真に反映する方式で、単一のデータ処理システム中に自分達のＳＬＡプロビジョニング要件を定義および格納することができるのである。
【００８１】
プロキュアメント機能は、具体的にはプライマリＳＬＡプロバイダおよびセカンダリＳＬＡプロバイダにより実施される調達、入札およびパーチャスオーダー生成活動に関する。これらのアクティビティは代表的には以下の結果を生じるものである：１）プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダに適用可能なビジネス情報を取得し、格納することができるようになる；２）プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダをＳＬＡスキルプロビジョンおよび地理的カバレッジ能力という意味において類別することができるようになる；３）プライマリＳＬＡプロバイダがＳＬＡクライアントのカバレッジ要件を、マスタデータ機能中に詳述されるように系統的に識別、数量化することができるようになる；４）プライマリＳＬＡプロバイダがＳＬＡクライアントカバレッジレコードから、系統的ＲＦｘビッドを生成することができるようになる；５）プライマリＳＬＡプロバイダが系統的にセカンダリＳＬＡプロバイダのビッドリストを生成し、ビッド応答プロセス用にＲＦｘビッドを掲示することができるようになる；６）セカンダリＳＬＡプロバイダが系統的にＲＦｘビッド応答を生成し、必要に応じてその応答にアフィリエイトする適正な人的資源リソースを提出することができるようになる；７）プライマリＳＬＡプロバイダが提出されたＲＦｘビッド応答を系統的にレビューすることができるようになる；８）プライマリＳＬＡプロバイダがＲＦｘビッド応答を系統的に受け入れ／落札し、ＲＦｘビッド応答のディテールを参照してセカンダリＳＬＡプロバイダパーチャスオーダーを作成することができるようになる。表３７〜表５２、および図１０〜図１３は、特にこれらのアクティビティに関連するものである。マスタデータ機能に関わる上述の論理的、系統的方法論は、プライマリＳＬＡプロバイダが自分達の潜在的ＳＬＡプロビジョンサービスを個別人員プロビジョンスキル要件、マテリアル／部品適正、および物理的ロケーション／地理という意味において定義することを可能とし、セカンダリＳＬＡプロバイダを類別し、調達するための基本情報プラットフォームとして作用する。
【００８２】
図１０は、セカンダリＳＬＡプロバイダシステムのイネーブルメントプロセスを説明するフロー図である。図１０においてプロセスフロー１０００はステップ１００５〜ステップ１０８０を含む。ステップ１００５〜ステップ１０２５は、セカンダリＳＬＡプロバイダを承認し、システム１００中に入れるための基本ステップである。プロセスフロー１０００はステップ１００５から始まり、このステップにおいては、プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダに関わるビジネス情報フィールドおよび何らかの適用可能な認定条件パラメータデータを設定する。ステップ１０１０においては、セカンダリＳＬＡプロバイダの認定用に設定された基本ビジネス情報の完成後、潜在的なセカンダリＳＬＡプロバイダに暫定的なシステムアクセス信用証明がプライマリＳＬＡプロバイダから付与される。これらの信用証明は、例えば電話や暗号化メッセージなど、複数の様式で送ることができる。
【００８３】
信用証明により、セカンダリＳＬＡプロバイダのユーザーはシステム１００をアクセスすることができるようになる。セカンダリＳＬＡプロバイダのユーザーには図３に示したものと類似のＧＵＩが提示され、これを使って基本ナビゲーション技術により主要ビジネス情報入力フォームをアクセスする。ステップ１０１５においては、セカンダリＳＬＡプロバイダが総合認定用ビジネス情報入力を完了し、これをレビュー用にプライマリＳＬＡプロバイダへと提出する。
【００８４】
ステップ１０２０〜ステップ１０２５は、プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダの提出した認定用情報のレビューおよび処遇決定について説明している。このワークフローは、このセカンダリＳＬＡプロバイダがビジネスの実施を認定／承認されるという、良い結果の場合に限り説明している。ステップ１０２０においては、セカンダリＳＬＡプロバイダが認定条件を満たしているとプライマリＳＬＡプロバイダが認めた場合にプライマリＳＬＡプロバイダがこのセカンダリＳＬＡプロバイダを承認する。ステップ１０２５においては、セカンダリＳＬＡプロバイダが承認の通知を受け、正規のシステムログイン信用証明を付与され、そしてプロビジョンプロフィールマトリクスを完成させるように指示される。ステップ１００５〜ステップ１０２５の間、プライマリＳＬＡプロバイダは、認定条件パラメータとして作用するあらゆる事前設定条件値の可視性を望むと共に、システム１００にとっての識別性も得られるように情報機能を設定する。基本ビジネス情報要素の例は、表４０〜表４１に含まれている。プライマリＳＬＡプロバイダには、システム１００中で機能させることを望む認定条件パラメータに関して設定上の制約はない。
【００８５】
ステップ１０３０〜ステップ１０５５は、セカンダリＳＬＡプロバイダが彼等の活動分野および地理的分野におけるサービスプロビジョン能力を文書化する基本ステップを説明するものである。セカンダリＳＬＡプロバイダには、ＧＵＩが提供され、これによりビジネスプロファイリングツールにアクセス可能となる。ビジネスプロファイリングツールは、ユーザーをセクタ−アリーナ−ファミリの階層的リレーショナルドリルダウンツールへと行くようにプロンプトする。ステップ１０３０においては、セカンダリＳＬＡプロバイダのユーザーが「プロビジョンプロファイリング機能」をアクセスする。ステップ１０３５においては、事前設定されたルールに基づいてセカンダリＳＬＡプロバイダはプロビジョンビジネスファミリの完全なリスト、またはそれを限定したプライマリＳＬＡプロバイダのサブセットを閲覧する。このツールを使い、セカンダリＳＬＡプロバイダはどの具体的機能／技術専門エリアが、彼等のコアコンピテンシーを表しているのかを指定することができる。ステップ１０４０においては、セカンダリＳＬＡプロバイダが、そのリソース供給能力に適用可能なビジネスファミリレコードを選択する。
【００８６】
ビジネスファミリを選択すると、セカンダリＳＬＡプロバイダは選択したビジネスファミリについての地理指定ツール（例えば国−地方−郡−市）および関連するテリトリカバレッジエリアの利用が可能となる。ステップ１０５０においては、セカンダリＳＬＡプロバイダが地理的リレーショナルデータベースユーザーインターフェースを使用してサービステリトリを指定する。国、地方、郡または居留区それぞれのカバレッジの指定。代表的な実施例においては、ユーザーインターフェースが集合体または個体としてのビジネスファミリと地理的テリトリとのマッピングをサポートする。例えば表４２〜表４６に格納されている所望の選択の保存にあたっては、セカンダリＳＬＡプロバイダはその選択を、レビューおよび処遇決定用にプライマリＳＬＡプロバイダへと提出するようになっていても良い。ステップ１０５５においては、セカンダリＳＬＡプロバイダがビジネスファミリーを保存し、地理的テリトリカバレッジマトリクスに提出する。
【００８７】
プライマリＳＬＡプロバイダは所望であれば、セカンダリＳＬＡプロバイダのサービスプロビジョンマトリクス指定を、マスタデータ機能内で定義されるプロビジョンスキルプロフィールおよび地理指定に限定することもできる。例示の目的上、これらの制約は詳細には説明しない。当業者には明らかであるように、そのような制約を用いることで通常はセカンダリＳＬＡプロバイダの採用プロセスが容易になるが、しかしビジネス要件の変更を視野に入れた場合、セカンダリＳＬＡプロバイダのプロビジョン能力のマクロデータビューが最適であることから、これは一般には最良の実施例とはいえない。
【００８８】
ステップ１０６０〜ステップ１０８０は、プロセスフロー１０００の完了を説明するものである。上述と同様、セカンダリＳＬＡプロバイダが提出したものについて肯定的処遇決定が下された場合のみについて詳述する。プロセスフロー１０００の最終結果は、ビジネスファミリおよび地理的テリトリカバレッジエリアの両方へのセカンダリＳＬＡプロバイダのマッピングである。ステップ１０６０において、セカンダリＳＬＡプロバイダにより作成された、地理的テリトリカバレッジマトリクスに、提出されたビジネスファミリーをプライマリＳＬＡプロバイダがレビューする。ステップ１０６５において、プライマリＳＬＡプロバイダがビジネスファミリーを地理的テリトリカバレッジマトリクスに承認する。ステップ１０７０においては、地理的テリトリカバレッジマトリクスのステータスへのセカンダリＳＬＡプロバイダのファミリーが、承認済みかつアクティブに変更される。ステップ１０７５においては、例えばオンラインおよびｅメール通知によりセカンダリＳＬＡプロバイダに提出の承認およびマトリクスステータスの変更が通知される。ステップ１０８０においては、セカンダリＳＬＡプロバイダがビジネスファミリプロビジョンおよび地理的テリトリ基準に基づく系統的ＲＦｘビッドを受けることが可能となる。
【００８９】
プロセスフロー１０００の終わりには、プライマリＳＬＡプロバイダは潜在的ＳＬＡクライアントプロビジョンの要求に関する情報と共に、潜在的セカンダリＳＬＡプロバイダのサービスカバレッジ能力を取得し、保存している。全体プロセス２００における次のステップは、ＲＦｘビッド要件ＩＤ、ＲＦｘビッド生成およびＲＦｘビッド勧誘に関するものである。
【００９０】
図１１は、１つ以上のセカンダリＳＬＡプロバイダパーチャスオーダーと関連付けられていないＳＬＡプロビジョンディテールレコードを詳述するサンプル出力レポートである。プライマリＳＬＡプロバイダ向けのシステムレポート出力１１００は、アクティブなＲＦｘビッドにもアクティブなセカンダリＳＬＡプロバイダパーチャスオーダーにもアフィリエイトされていない全てのアクティブなＳＬＡクライアントプロビジョンディテールレコードを詳述するものである。
【００９１】
ここで採用する方法は、全ての要件を考慮し、全ての要件を特定のレコードへと関連付け、各レコードをＳＬＡプロビジョンスキルプロフィールへとマッピングし、そしてその要件にアフィリエイトする地理的カバレッジポイントを割り当てるという様式化したデータベース法において潜在的ＳＬＡクライアント要件を記録することである。この方式の結果が出力レポート１１００であり、これは見積書を受けるためにセカンダリＳＬＡプロバイダへと発行されるべきＲＦｘビッドを作成する段階を設定するものである。
【００９２】
コントロール１１１５、１１２０、１１２５は、プライマリＳＬＡプロバイダのユーザーが、より広い地理的区分においてレコードセットをグループ化し、閲覧することを可能とするユーザー用の可変ビューコントロールを表す。コントロール１１１５、１１２０、１１２５は、代表的な便宜上、ビジネス慣行上の選好的設定である。
【００９３】
コントロール１１０５は、詳細なＳＬＡジョブディスクリプションへの見識をユーザーに提供するものである。このパスはより高い可視性を提供するために用意されている。プライマリＳＬＡプロバイダがこのフィールドが使用しない場合、リンクはインアクティブまたはゴースト表示となり、ユーザーがディテールへと掘り下げることはできなくなる。
【００９４】
コントロール１１１０は、適用可能な詳しいＳＬＡプロビジョンスキルプロフィールへの見識をユーザーに提供するものである。このパスはより高い可視性を提供するために用意されている。さらに、プライマリＳＬＡプロバイダがこのフィールドが使用しない場合、リンクはインアクティブまたはゴースト表示となり、ユーザーがディテールへと掘り下げることはできなくなる。
【００９５】
コントロール１１０１、１１３０および１１３５は、特定のレコードまたはレコードグループを選択して新たなＲＦｘビッドへと包含するため、および選択したレコードが単一のＲＦｘビッドへとグループ化されるものであるか、または選択されたレコードの各々が一意のＲＦｘビッドと関連付けられるものであるか、についてそれぞれ指定するために利用される主要コントロールである。コントロール１１３５は、少なくとも２つのレコードが選択されるまではインアクティブである。
【００９６】
コントロール１１０１を介して所望レコードの選択が行われ、複数のＲＦｘまたは単一のＲＦｘへの包含の選好が指定されると（コントロール１１３０またはコントロール１１３５）、ユーザーは「ＲＦｘ作成」コントロール（コントロール１１４０）をアクティブ化し、ＲＦｘ作成プロセスを開始する。関連付けられていないＳＬＡプロビジョンディテールレコードレポートにおいてはビジネス目的にレコードが無く、これはその適切なＳＬＡクライアントについてはアウトソーシングした、または下請け契約したプロビジョンサービスカバレッジが無いためである。
【００９７】
図１２Ａ、図１２Ｂは、アウトソーシングされたセカンダリＳＬＡプロバイダサービスプロビジョンのプロキュアメントに適用可能なハイレベルプロセスを説明するフロー図である。ここで図１２Ａを見ると、ＲＦｘビッドの作成と、セカンダリＳＬＡプロバイダＲＦｘビッド選択および勧誘のためのプロセスフロー１２００が説明されている。プロセスフロー１２００はステップ１２０２から始まる。ステップ１２０２においては、プライマリＳＬＡプロバイダが、システムの提供する、関連付けられていないＳＬＡクライアントプロビジョンディテールレポートを起動する。ステップ１２０４においては、システム１００が選択された「レポートレコード」からプライマリＳＬＡプロバイダのユーザーがＲＦｘビッドを生成するための機能を提供する。ステップ１２０６においては、システム１００がステップ１２０４において設定されたようにＲＦｘビッドレコードを作成する。ステップ１２０８においては、プライマリＳＬＡプロバイダのユーザーのためのＲＦｘビッド作成セッションが開始される。当業者には明らかなように、ステップ１２０８は「ＧＵＩメニュー」コントロールとは別に開始することができるもので、このことはプライマリＳＬＡプロバイダのユーザーが先にステップ１２０２〜ステップ１２０６に説明したレポート出力を起動することによりＲＦｘビッドを作成する必要が必ずしもないことを意味する。このような場合システム１００は、ＲＦｘへの包含を予定したが、何等かの理由により未完了である全てのレコードをユーザーに提示することが可能である。しかしながら例示上の目的により、プロセスフロー１２００は、図１１のサンプル出力レポートに関連してとられるユーザーアクションからＲＦｘ作成ビッドセッションを直接起動するものとして説明されている。
【００９８】
説明したように、プライマリＳＬＡプロバイダのユーザーはステップ１２０８においてＲＦｘビッド作成セッションを開始し、利用可能なレコードセットの提示を受けている。ステップ１２１０においては、ユーザーが所望するプロビジョンディテールレコードに関連付けられた特定のＲＦｘビッドを選択する。複数のプロビジョンディテールレコードを単一のＲＦｘへとまとめることができる。
【００９９】
ステップ１２１２においては、プロビジョンディテールレコードに適用可能な事前設定データベース要素を使ってＲＦｘビッドの要素群が埋められる。ＲＦｘビッドは、ＳＬＡプロビジョニングレコードセットから情報ディテールを引き継ぐものであり、これには例えばＳＬＡプロビジョンスキルプロフィール、サービスロケーションディテール、プロビジョンＳＬＡ要件および予測されるサービス頻度が含まれる。ステップ１２１２は代表的には提示したＧＵＩ形式を若干超えるもので、標準的ナビゲーション技術によりユーザーによる個々のレコードへのアクセスを可能とするものである。このプロセスがユーザーに管理上の容易性を提供することはもちろん、データ入力エラーが事実上、排除されることは当業者に明らかである。物理的プロビジョンサービスおよびそのロジスティクスに適用可能な関連ディテールは、ＳＬＡクライアントコントラクトレコードに直接リンクするＳＬＡプロビジョンディテールレコードから直接的に取得されるのである。
【０１００】
ＲＦｘにコアレコードセットが確立されると、次にプライマリＳＬＡプロバイダのユーザーは、ステップ１２１５においてレコードへの編集／設定アクセスを得る。ステップ１２１５においては、プライマリＳＬＡプロバイダのユーザーが、例えばレーバータイプオプション、ＳＬＡペナルティ条件、最高レートなどを設定する。
【０１０１】
ユーザーは何のアクションもとらないこともできるが、ユーザーにビジネス努力をさらに押し広げるオプションが提供されるようになっていてもよい。ビッドプロセスの過程で収益性およびサービスプロビジョン品質目標が確実に確立されるように、例えば請求するレーバータイプ、最高請求料率、ＳＬＡペナルティ条件、およびサービスプロビジョニング応答時間といったデータ要素を設定することができる。一例は請求料率である。プライマリＳＬＡプロバイダの観点から言えば、セカンダリＳＬＡプロバイダの見積もる請求料率が、最終的に適切なＳＬＡクライアントが支払うことになる請求料率以下となるように上限を設けておくと有利である。他の例としては、サービスプロビジョン応答時間が挙げられる。この場合も、プライマリＳＬＡプロバイダの観点から言えばサービスプロビジョン応答時間をプライマリＳＬＡプロバイダに適用される契約上の時間フレームよりも短く設定しておくと有利である。編集可能なユーザーインターフェースにより、プライマリＳＬＡプロバイダは系統的なフレームワークにおいてその利益を守ることが可能である。
【０１０２】
ステップ１２１８は、ステップ１２１５完了時の保存プロセスである。このステップにおいては、プライマリＳＬＡプロバイダにとって潜在的に問題を生じる可能性のあるユーザー設定を調べ、検証する意思決定支援機構をシステム１００に作りこむことができる。特定のビッド項目に適用可能なパラメータがビジネス努力リスクを大きくする可能性があることをユーザーに示すために、収益性または品質保証分析といった検証を用いることができる。
【０１０３】
この時点でＲＦｘビッドをセカンダリＳＬＡプロバイダへと送り出すために必要な主要ディテールが完成する。しかしながら、様々な管理上のディテールは未完成のまま残っている。代表的には、ＲＦｘビッドは例えばビッドヘッダ部、ビッドディテール部、およびビッド応答部のような特定の要素を伴う。ＲＦｘビッドは通常、ビッド応答処理時に実行される一群の定義づけられたサプライヤアグリーメントを伴う。さらにＲＦｘビッドの性質として、発行された大部分のビッドに関する情報は、フォーマットおよび内容が企業全体を通じて重複し、標準的なものが多い。従ってＲＦｘビッドの内容およびフォーマットに関する問題を管理するためにビッドテンプレートツールが用いられる。
【０１０４】
ＲＦｘビッドテンプレートについては、特定のデータベーステーブルが、例えばクエッションアンドステートメントのようなデフォルトのＲＦｘビッド情報要素を格納している。プライマリＳＬＡプロバイダは、デフォルトのＲＦｘビッド情報要素に適用可能な標準的なデフォルト内容を設定することができる。よって情報要素を事前定義し、ユーザー編集の必要性をなくすことができる。さらにシステム１００は特定の設定可能情報要素を格納するものであっても良く、これは即ち、ユーザーがビッド項目を作成し、この項目をステートメント、クエッションなどに指定し、そしてその情報要素がサプライヤの応答を要するものか否かを指定し、その応答が例えば数値、テキスト、日付または金額といった特定のデータタイプに限定されているか否かを指定することができることを意味する。
【０１０５】
様々な実施例において、サービスプロビジョンフレームワークはＲＦｘビッド項目を含む。ＲＦｘビッド項目は、論理的デフォルトＲＦｘビッドカテゴリおよびセクションへと関連付けることができる。各ビッド項目は論理的グループ、即ちカテゴリへと割り当てることができ、そして１階層上では各カテゴリを論理的にグループ化してセクションとすることができる。よってＲＦｘビッドコンテンツのグループ化が可能となる。
【０１０６】
ビッドコンテンツグループ化の上には、より複雑なＲＦｘビッドテンプレート層があり、この層はプライマリＳＬＡプロバイダがセクション、セクション中のカテゴリ、およびカテゴリ中のＲＦｘビッド項目という順番のＵＩ表示を確立することを可能にしている。従って様々なＲＦｘビッド項目を作成し、構造化されたコンテンツおよびレイアウトフォーマット中に格納することができる。よってＲＦｘビッドテンプレートはビジネスコンテンツコントロール機構であり、これがプロビジョンディテールＲＦｘデータと組み合わせられた場合、高速かつ詳細なＲＦｘビッド生成の基盤を構成するのである。
【０１０７】
ＲＦｘビッドテンプレートはシステム１００中に格納され、そしてステップ１２２０においてはプライマリＳＬＡプロバイダのユーザーが、選択したい事前設定ＲＦｘビッドテンプレートを選択するようにプロンプトされる。プライマリＳＬＡプロバイダのユーザーは、ＲＦｘビッド設定を非プロビジョンディテールＲＦｘビッドデータフィールドの残りの部分を定義する事前定義のコンテンツビッドテンプレートへと関連付けるようにプロンプトされる。ビッドテンプレートデータフィールドはデフォルトで完成されるものであっても、特定のユーザー入力を要するものであっても良い。システム１００は、ユーザーが自分の特定の要求に対して適正だと思う特定のビッド項目をイネーブル、またはディセイブルするオプション（企業設定されている場合）をユーザーに提供するものであってもよい。例えば、ユーザーが老舗の有名なサプライヤベースと取引する場合である。このような場合、ユーザーは潜在的セカンダリＳＬＡプロバイダの、例えば過去の履歴または品質保証上の疑問といった特定の情報を要求する特定のビッド項目のディセイブルを選択する場合がある。反対に、プライマリＳＬＡプロバイダが設定を通じて特定のビッド項目をロックする能力も持っており、これはその後、ＲＦｘビッド作成プロセス中にユーザーがディセイブルすることができない。
【０１０８】
適切なＲＦｘビッド項目を選択すると、適切な場合、ユーザーは処理される特定のＲＦｘビッドに適合する必要情報をステップ１２２２において入力する。この入力の単純な例として、プライマリＳＬＡプロバイダのビッド管理者または要求されるビッド応答期日が挙げられる。所望の入力が完了すると、ユーザーはステップ１２２４においてデータ変更を保存する。プロセスフロー１２００には記載されていないが、ユーザーが編集能力を持つ場合もある。システム１００はステータスコードマネジメント技術を用いて一時格納ができるものであってもよく、これによりデータ処理は、他の時点または他のユーザーが実施することができる。
【０１０９】
ＲＦｘビッドの全ての情報が完成すると、ステップ１２２６〜ステップ１２３２においてＲＦｘビッド勧誘リストが確立される。プライマリＳＬＡプロバイダのユーザーが所望のビッド項目入力を完了し、保存した時点でステップ１２２６が実行可能となる。この時点においてシステム１００は、先にはインアクティブであった「ＲＦｘビッドの掲示」コントロールを提供する。このコントロールは、ステップ１２２８においてアクティブ化され、ステップ１２３０においては、例えばビジネスファミリおよびテリトリカバレッジを提供するために認可されたＲＦｘビッドにアフィリエイトする全ての承認セカンダリＳＬＡプロバイダのリスト表示がユーザーに提供される。系統的アフィリエーションは、代表的にはステップ１０７０において先に説明したプロビジョンスキルビジネスファミリと地理的パラメータのデータベースマッピングである。
【０１１０】
ステップ１２３２においては、プライマリＳＬＡプロバイダのユーザーが、潜在的ＲＦｘビッド勧誘リスト中に含まれるセカンダリＳＬＡプロバイダレコードの全て、またはサブセットを選択する。通常はこのユーザーの選択プロセスを支援するために複数の意思決定支援ツールがあり、これらが、例えば追跡した品質保証、価格およびＳＬＡプロビジョンペナルティマトリクスに関わるセカンダリＳＬＡプロバイダについての貴重な情報をユーザーに提供する。
【０１１１】
ユーザーにより所望のセカンダリＳＬＡプロバイダが選択され、保存されると、ステップ１２３４においてシステム１００がユーザーに、選択したセカンダリＳＬＡプロバイダにＲＦｘビッドを掲示するようにプロンプトする。ステップ１２３６においては、ユーザーが「ＲＦｘビッドの掲示」コントロールをアクティブ化し、これによりステップ１２３８においてＲＦｘビッドが同報通信されることになり、そしてステップ１２４０においてｅメールおよびダッシュボード更新によりセカンダリＳＬＡプロバイダに通知される。ユーザーが確立した掲示リストは、例えば表４７に格納される。ＲＦｘビッドプロセス中に使われる主要ＳＬＡプロビジョンディテールレコード情報は、例えば表３７〜表３９に格納される。
【０１１２】
次に図１２Ｂを見ると、ステップ１２４４においては、セカンダリＳＬＡプロバイダがＲＦｘビッドをアクセスし、テンプレート定義されたビッド処理アグリーメントを実行する。ステップ１２４４は通常、アプリケーションＧＵＩを通じてイネーブルされる。先に開示したように、機密保持契約および知的所有権契約を含むがこれらに限られないサプライヤアグリーメントの履行；よって特定のコントロールがセカンダリＳＬＡプロバイダのユーザーに使用可能となっており、オンライン、またはそれ以外の手段でアグリーメントに署名することができる。プロセスフロー１２００の目的上、セカンダリＳＬＡプロバイダは、プライマリＳＬＡプロバイダにより制定されたいずれの設定されたアグリーメントにも署名することを前提としている。
【０１１３】
ステップ１２４６においては、セカンダリＳＬＡプロバイダが応答を要求する全てのアプリケーションＲＦｘビッド機能に対して入力を行う。システム１００は代表的には単純なビッド項目応答カウンタを用いており、これにより要求される全てのビッド応答要素が埋められるまでビッド応答を提出することができないようになっている。さらに、代表的な設定を持つシステム１００はデータ検証機能を持っており、これによりビッド応答項目が所定の正しいデータオブジェクトおよびフォーマットによらない限りは完了することができない。ＲＦｘビッド応答ディテールは、例えば表４８、表４９、表９０および表９１中に格納される。
【０１１４】
ステップ１２４８においては、セカンダリＳＬＡプロバイダがＳＬＡプロビジョンレーバープロフィールに適用可能なヒューマンリソースサブミッタルレコードを作成する。ステップ１２４８は代表的にはステップ１２４６内のサブプロセスとして発生するものであるが、説明を明確にする目的でＳＬＡリソースサブミッタルプロセスは別個のプロセスステップとして強調した。ステップ１２４８の間、セカンダリＳＬＡプロバイダは通常、提供されるＧＵＩを使ってＲＦｘビッド中に含まれるいずれかの適用可能なＳＬＡリソースプロフィールへとドリルダウンし、そのＳＬＡリソースプロフィールにアフィリエイトするリソースサブミッタルを作成する。サブミッタル情報は、例えば表５０中に格納される。システム１００は、関連付けモードにおいて全般的なセカンダリＳＬＡプロバイダレーバーリソースライブラリを使うことができるように適合させることができ、これによりリソースはＳＬＡプロビジョンスキルプロフィールへと、本願に説明されるミクロモード（個々のＲＦｘ）とは反するマクロモードでマッピングされる。このモードは、特定のプライマリＳＬＡプロバイダが競争ＲＦｘビッドの実施には興味がなく、マスタアグリーメントを使ってセカンダリＳＬＡプロバイダと仕事をすることを望む場合に有用な場合がある。
【０１１５】
他のモードにおいては、リソースのサブミッタルはＲＦｘビッド応答プロセスの最中ではなく、ＲＦｘビッド応答プロセスの後に実施される。これは、ＲＦｘビッドへの勧誘が何ヶ月も先になるプロビジョンサービスをカバーするものである場合にあり得る。この場合、実際のビッドプロセス中における特定のレーバーリソースのサブミッタルは無意味である。当業者には明らかなように、図示したプロセス例は、セカンダリＳＬＡプロバイダリソースをＳＬＡクライアント要件と関連付ける唯一のモードではないのである。
【０１１６】
ステップ１２５０においては、セカンダリＳＬＡプロバイダが情報設定を保存し、ビッド応答をプライマリＳＬＡプロバイダへと送付する。ステップ１２５０は、要求されたビッド応答情報の完成を表すものであり、従ってセカンダリＳＬＡプロバイダは彼等の完成したＲＦｘビッド応答を提出することができるようになる。ステップ１２５０によりレコードが更新され、そしてステップ１２５２において、いずれかの事前設定されたユーザーへの系統的なアプリケーション通知がトリガされる。
【０１１７】
ステップ１２５４〜ステップ１２５８は、プライマリＳＬＡプロバイダビッド応答処遇決定プロセスを表す。ステップ１２５４においては、プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダからのビッド応答をレビューする。ステップ１２５６においては、プライマリＳＬＡプロバイダが所望のビッド応答を受け入れる。ステップ１２５８においては、セカンダリＳＬＡプロバイダにビッド落札が例えばシステム更新およびｅメールで通知される。
【０１１８】
１つ以上のセカンダリＳＬＡプロバイダのビッド応答がビッド落札に相応である場合を想定した場合、プライマリＳＬＡプロバイダは１つ以上のビッド応答レコードの落札を指定する。プライマリＳＬＡプロバイダは複数のビッド応答の落札を決定し、ビッドプロビジョンディテール応答項目の全てまたはサブセットに落札を発行する。例えば、あるセカンダリＳＬＡプロバイダは、ビッドの１つのサービスカバレッジエリアについて指名され、他には指名されないことがある。他の事例では、あるセカンダリＳＬＡプロバイダは１つのＳＬＡプロビジョンサービスカバレッジ時間には指名されるが、他には指名されないことがある。これは例えば、そのビッド応答が時間外または週末のプロビジョンコールアウトに法外な値段を表示している場合などがそうである。ビッド応答の落札処遇決定は、可変で柔軟であり、プライマリＳＬＡプロバイダがこのプロセス中、プロキュアメントの最良の履行法を採用することができるようになっている。
【０１１９】
ステップ１２６０〜ステップ１２７０は、落札したセカンダリＳＬＡプロバイダのビッド応答からプライマリＳＬＡプロバイダがパーチャス要請を作成するプロセスを説明するものである。ステップ１２６０においては、プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダパーチャス要請を作成するようにプロンプトされる。ステップ１２６２においては、プライマリＳＬＡプロバイダが「ＰＯ要請の作成」コントロールをアクティブ化する。ステップ１２６４においては、システム１００が継承したビッド応答データを使ってパーチャス要請を作成する。ステップ１２６６においては、システム１００が、そのＲＦｘビッドに適用可能なビッド落札を受けたセカンダリＳＬＡプロバイダ全てのリスト表示を提供する。ステップ１２６８においては、プライマリＳＬＡプロバイダが作成されたパーチャス要請が正確であるかについてレビューし、必要があれば変更。ステップ１２７０においては、プライマリＳＬＡプロバイダがパーチャス要請を保存し、これをレビュー／承認用にセカンダリＳＬＡプロバイダに提出する。
【０１２０】
関連付けられていないＳＬＡプロビジョンディテールレポート同様、システム１００はデータベース主導型ステータスコードを使い、パーチャスオーダーへと処理すべき全ビッド応答落札のレポート出力をプライマリＳＬＡプロバイダに提供することができる。図示したプロセスは、説明の便宜上、落札からパーチャス要請処理へとジャンプする線形処理を表している。一部の実施例においてはこのプロセスは独立したものであり、別の時点において、そして恐らくは他の人員により実施される可能性がある。
【０１２１】
図示したプロセスが独立モードで実施される場合、パーチャス要請処理モジュールがアクティブ化され、プライマリＳＬＡプロバイダユーザーに処理を待つ全ての未決のビッド応答落札のリスト表示が提供される。プロセスは述べたように線形モードで示されており、従ってユーザーは未決の落札されたビッド応答を選択する必要はない。このプロセスは、特定のＲＦｘビッドレコードセットから生じる要請プロセスを想定していることから、システム１００は、要請に含まれるべき情報を落札されたビッド応答レコードから継承してパーチャス要請を作成する。パーチャス要請は、デフォルトモードにあってはセカンダリＳＬＡプロバイダ毎に１つ作成され、必要に応じて複数の行項目を含ませることができる。これは、１つの適用可能なＲＦｘビッド落札が複数のＳＬＡプロビジョンディテールレコードへとアフィリエイトされた場合にそうである。
【０１２２】
パーチャス要請が作成されると、システム１００はプライマリＳＬＡプロバイダを、例えばレビューおよびコメントの付加をすることができるようにイネーブルする。パーチャス要請に含まれる情報が満足なものである場合、プライマリＳＬＡプロバイダのユーザーはそのパーチャス要請を保存および承認する。このアクションにより、システム１００内においてステータスコードの更新がトリガされると共に、システムベースの通知が適切なセカンダリＳＬＡプロバイダに発行される。
【０１２３】
ステップ１２７２〜ステップ１２７８は、プライマリＳＬＡプロバイダが作成したパーチャス要請の、セカンダリＳＬＡプロバイダでの取り扱いを表すものである。システム１００は様々なセカンダリＳＬＡプロバイダ承認ワークフローをサポートする。本願においては、このプロセス中に発生し得るデータまたは情報の矛盾に適用可能なワークフローについては明確には記載していない。
【０１２４】
ステップ１２７２〜ステップ１２７８の間、セカンダリＳＬＡプロバイダはレビュー、承認し、完成したパーチャス要請をプライマリＳＬＡプロバイダへと再提出する。ステップ１２７２においては、セカンダリＳＬＡプロバイダに未決のパーチャス要請が通知される。ステップ１２７４においては、セカンダリＳＬＡプロバイダがパーチャス要請のディテールをレビューしてパーチャス要請を承認する。ステップ１２７６においては、システム１００が承認されたパーチャス要請をプライマリＳＬＡプロバイダに提出する。ステップ１２７８においては、プライマリＳＬＡプロバイダに承認済パーチャスが通知される。
【０１２５】
ステップ１２８０においては、プライマリＳＬＡプロバイダが承認済パーチャス要請にアクセスする。ステップ１２８２においては、プライマリＳＬＡプロバイダが「パーチャスオーダーの作成」コントロールをアクティブ化する。ステップ１２８４においては、システム１００がパーチャスオーダーを作成する。ステップ１２８６においては、プライマリＳＬＡプロバイダが社内パーチャスオーダーナンバを定義し、パーチャスオーダーを承認する。ステップ１２８８においては、セカンダリＳＬＡプロバイダに承認済パーチャスオーダーが通知される。ステップ１２９０においては、セカンダリＳＬＡプロバイダによるパーチャスオーダーの利用が可能となる。説明の便宜上、パーチャス要請およびパーチャスオーダーデータ両方の保存場所として同じ表５１および表５２を使った単純なデータベーステーブル構造を示した。
【０１２６】
図１３は、プロキュアメント機能をサポートするデータベーススキーマである。データベーススキーマ１３００は、この最終トピックとなる処遇決定において説明されるデータ処理機能をサポートするハイレベルな説明用データベーススキーマである。当業者には明らかなように、展開していくダウンストリームデータ処理セッションを通じてシームレスな情報スレッドが続いており、この結果、プロキュアメントモジュールのビジネス情報の接続性はマスタデータ機能まで完全に遡るのである。継承情報デザインにより、様々な実施例においてユーザー入力が減ることになり、データ入力エラーを排除して最適化された監査能力が提供されるものである。
【０１２７】
方法全体における次のプロセスは、ヒューマンリソースサービスプロビジョンマネジメント機能であり、これは：１）プライマリＳＬＡプロバイダが提出されたＲＦｘビッド応答候補のレビューと承認処遇決定を実施できるようにすること；２）提出されたＲＦｘビッド応答候補に関するプライマリＳＬＡプロバイダの処遇決定／ステータス通知を系統的にセカンダリＳＬＡプロバイダに送ることができるようにすること；３）提出したＲＦｘビッド応答候補の承認／受諾時にプライマリＳＬＡプロバイダによるＳＬＡプロビジョンリソースレコードの作成を可能とすること；４）セカンダリＳＬＡプロバイダのヒューマンリソースによるシステムアクセスを可能とすること；５）セカンダリＳＬＡプロバイダヒューマンリソースによるアグリーメントの系統的実行を可能とすること；６）セカンダリＳＬＡプロバイダおよび承認されたヒューマンリソースによるワークアベラビリティカレンダの管理／設定を可能とすること；７）プライマリＳＬＡプロバイダロジスティクス時間カバレッジ評価を可能とすること；および８）プライマリＳＬＡプロバイダのプロアクティブなヒューマンリソースブラックアウト期間の調停を可能とすること；を含んでいる。ブラックアウト期間とは、特定のヒューマンリソース、または集合的リソースグループがサービスプロビジョニングを提供できない期間のことである。
【０１２８】
一般にＳＬＡプロビジョンアウトソーシングが実施される様式は、管理マネジメントの特異性として、ＳＬＡプロビジョンレーバーリソースレベルについて実際のビジネス分析を最低限しか、または全く行わない状態でプライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダ企業体の経営者または営業要員と契約に至るというものである。これは、そのセカンダリＳＬＡプロバイダの適正評価または過去のパフォーマンス評価を全て無視することを示唆するものではなく、むしろ、どのレベルのビジネスマネジメントが実施されるかについての全体的な状況を示唆するものである。究極的には、品質／クライアントＳＬＡプロビジョンの成功とは、ＳＬＡプロビジョンレーバー品質、能力およびアベラビリティに適正なロジスティクスプランとコミュニケーションを加味した結果なのである。
【０１２９】
図１４Ａおよび図１４Ｂは、ヒューマンリソースサービスプロビジョンマネジメントに適用可能なハイレベルプロセスを説明するフロー図である。図１４Ａでは、プロセスフロー１４００はステップ１４０２で始まる。ステップ１４０２〜ステップ１４０６は、１つ以上のＳＬＡプロビジョンリソースアサイメント（assignment：割り当て）レコードに関連付けられていない既存のセカンダリＳＬＡプロバイダパーチャスオーダーについてプライマリＳＬＡプロバイダに系統的に通知するプロセスを説明している。ステップ１４０２においては、プライマリＳＬＡプロバイダのユーザーがヒューマンリソースレーバーマネジメントモジュールにアクセスする。ステップ１４０４においては、プライマリＳＬＡプロバイダがメニュー方式のＧＵＩを操作して割り当てられていないセカンダリＳＬＡプロバイダパーチャスオーダーを選択する。ステップ１４０６においては、システム１００がセカンダリＳＬＡプロバイダおよびパーチャスオーダーでグループ化されたリスト表示レポートを提供する。明記はしていないが、レーバーアサイメントのアフィリエーションが既に存在する場合は、レコードマネジメントへのアクセスは存在している。必要な人員変更がある場合のレコード変更は、必然的にそのような機能が指定される。
【０１３０】
ステップ１４０８〜ステップ１４１６は、プライマリＳＬＡプロバイダのユーザーが所望のＳＬＡプロビジョンレーバーリソースを選択することに対応するものであり、このプロセスはセカンダリＳＬＡプロバイダが先のＲＦｘビッドプロセスの間にリソースレコードを提出した時の様式を説明するものである。このプロセスは可変であり、明確には説明していないが、セカンダリＳＬＡプロバイダがレビュープロセス中の比較的に自由な時点でレビュー用のリソースレコードを送るための機能がある。これは、提出されたリソースレコードが要求を満たしていない、または何等かの理由で割り当てることができなくなった場合などのためである。ステップ１４０８においては、ユーザーが適切なセカンダリＳＬＡプロバイダのレコードを選択し、「管理ヒューマンリソース」コントロールをアクティブ化する。ステップ１４１０においては、システム１００が関連付けられたソースのＲＦｘビッド応答に適切な全セカンダリＳＬＡプロバイダリソースサブミッタルのリストをユーザーに提示する。ステップ１４１２においては、システム１００がリソースサブミッタルディテールへとリンクするためのコントロールをユーザーに提示する。ステップ１４１４においては、ＳＬＡプロビジョンカバレッジを提供するために所望される特定のヒューマンリソースをユーザーがＧＵＩを介して選択する。ステップ１４１６においては、ユーザーが承認されたリソースレコードセットを保存し、システム１００がそれに関する通知をセカンダリＳＬＡプロバイダに送付する。
【０１３１】
このプロセスにより、プライマリＳＬＡプロバイダのユーザーはサブミッタルのディテールを確認し、それに応じた所望の選択を実施することができる。本願に開示していない追加可能な機能は多数あるが、当業者には明らかなように、プライマリＳＬＡプロバイダはこのレビューと選択プロセスの結果として、究極的には自分らに代わりサービスを提供するリソースに対するコントロールを得るのである。レーバーリソースシステムイネーブルメントに関するディテールは表５３に含まれ、一方でアサイメントディテールは表５４に含まれている。
【０１３２】
所望リソースの選択時、システム１００は、ステップ１４１８〜ステップ１４２４において、セカンダリＳＬＡプロバイダがリソースのアベラビリティと、そのリソースを適用可能なプロビジョンアサイメントにアフィリエイトさせることを引き続き望んでいるかどうかを確認することができる逆確認プロセスをイネーブルする。ステップ１４１８においては、未決ステータスを持つその承認されたリソースについて、システム１００がヒューマンキャピタルレーバーアサイメントレコードを作成する。ステップ１４２０においては、セカンダリＳＬＡプロバイダがＧＵＩを介してリソースアサイメント承認を追認する。ステップ１４２２においては、プライマリＳＬＡプロバイダにアサイメントアクナリッジメントが、例えばシステム通知により通知される。ステップ１４２４においては、セカンダリＳＬＡプロバイダに適用可能リソースへのシステムアクセス信用証明が提供される。
【０１３３】
ステップ１４２６〜ステップ１４３０は、ＳＬＡプロビジョンレーバーリソースの管理システムイネーブルメントに関するものである。システムアクセス時にプライマリＳＬＡプロバイダにより、例えばＮＤＡ、ＩＰ保護、および派遣労働契約のアクナリッジメントを含む様々なレーバーリソース保護契約を設定することができる。このプロセスはレーバーリソースによる肯定的アクションについて説明している。レーバーリソース契約がタイムリーに実行されない、または契約自体が不調であった場合には別の結果となる。ステップ１４２６においては、セカンダリＳＬＡプロバイダのリソースが提供された信用証明によりシステム１００をアクセスする。ステップ１４２８においては、セカンダリＳＬＡプロバイダのリソースが設定されたオンラインアグリーメントに署名する。ステップ１４３０においては、プライマリＳＬＡプロバイダとセカンダリＳＬＡプロバイダの両方にシステム通知が送付される。
【０１３４】
レーバーリソースのイネーブルメントが全てうまく運んだと想定すると、次のプロセスとしてレーバーリソースアベラビリティカレンダの設定がステップ１４３２〜ステップ１４４２において発生する。ステップ１４３２においては、セカンダリＳＬＡプロバイダがヒューマンリソースカレンダをアクセスおよび設定するようにプロンプトされる。ステップ１４３４においては、セカンダリＳＬＡプロバイダがヒューマンリソースカレンダモジュールをアクセスする。ステップ１４３６においては、セカンダリＳＬＡプロバイダが特定のヒューマンリソースレコードをアクセスする。ステップ１４３８においては、セカンダリＳＬＡプロバイダが標準ヒューマンリソースブラックアウト（就労不可）期間および一般アベラビリティ（就労可能）期間を提供する。ステップ１４４０においては、セカンダリＳＬＡプロバイダが、それぞれのセカンダリＳＬＡプロバイダにアフィリエイトする全ての適切な割り当てられたヒューマンリソースについてステップ１４３４〜ステップ１４３８を繰り返す。ステップ１４４２においては、全てのリソースカレンダ設定が完了すると、セカンダリＳＬＡプロバイダはプライマリＳＬＡプロバイダにパーチャスオーダーアサイメントカレンダ設定を送付する。
【０１３５】
プロセス１４００のこの段階にあっては、所望されたレーバーリソースはそれぞれのＳＬＡプロビジョンサービスアクティビティへと指定されている。プロセスフロー１４００は、レーバーリソースカバレッジ期間をシステム１００へと入力し、プランニングをサポートする目的でこれを分析することができる高度かつ効率的なロジスティクス手段を含んでいる。様々な実施例に基づくヒューマンリソースサービスプロビジョンマネジメントの高いレベルにおいては、セカンダリＳＬＡプロバイダは、任務に割り当てられた（assigned）ＳＬＡプロビジョンレーバーリソースの基本スケジュールを入力するようにプロンプトされる。基本設定は通常、週末または夜間、もしくは特定の休暇または休日期間といった標準的ブラックアウト期間の指定を伴う。１人のレーバーリソースに毎日２４時間待機を要求することはできないが、対照的にセカンダリＳＬＡプロバイダには当然、２４時間カバレッジの責任を課すことができる。
【０１３６】
通常、ＲＦｘビッドはコントラクト上のカバレッジ時間フレームに関する情報を含んでいる。一方で、多くの場合、全カバレッジ期間のプロビジョンには一般に複数のレーバーリソース、そしてしばしば複数のセカンダリＳＬＡプロバイダの利用を伴うことがあることは言うまでもない。従って、ステップ１４４５〜ステップ１４５６に説明する次のプロセスの間、プライマリＳＬＡプロバイダは潜在的なサービスプロビジョンギャップがあれば、これを定義する。理想的には、プライマリＳＬＡプロバイダは：１）各セカンダリＳＬＡプロバイダによる完全なロジスティクス的カバレッジ；または２）複数のセカンダリＳＬＡプロバイダによる完全な集合的カバレッジ；を確立する。システム１００は、プライマリＳＬＡプロバイダがレーバーリソースカレンダアベラビリティデータの入力／アップロード、およびそのデータの分析を通じ、上述したシナリオを統計学的に検証することを可能とするものである。この統計学的検証は、ステップ１４４５〜ステップ１４５６の重要な部分である。
【０１３７】
ステップ１４４２からは、処理は図１４Ｂのステップ１４４５へと進む。ステップ１４４５においては、プライマリＳＬＡプロバイダのユーザーが、ヒューマンリソースレーバーマネジメントモジュール中のパーチャスオーダーリソースアサイメントリストにアクセスする。ステップ１４４８においては、プライマリＳＬＡプロバイダのユーザーが「カバレッジ」コントロールをアクティブ化し、評価する。ステップ１４５０においては、システム１００が潜在的なノンカバレッジ期間、即ちブラックアウト時間を指定するレポートをプライマリＳＬＡプロバイダに提示する。ステップ１４５２においては、システム１００が、特定のＳＬＡクライアントプロビジョンディテールレコードの適用可能なカバレッジについて、全セカンダリＳＬＡプロバイダによる集合的カバレッジを評価するためのオプションをプライマリＳＬＡプロバイダのユーザーに提示する。ステップ１４５４においては、プライマリＳＬＡプロバイダのユーザーが集合的カバレッジ評価レポートを起動する。ステップ１４５６においては、システム１００が潜在的な集合的ノンカバレッジ期間、即ちブラックアウト時間を指定するレポートをプライマリＳＬＡプロバイダに提示する。
【０１３８】
システム１００は時間を論理的に区分化されたデータベース単位で定量化するため、ＳＬＡプロビジョンレーバーリソースカバレッジレポートを提示することは容易である。カバレッジ分析は個々に、または集合的セカンダリＳＬＡプロバイダ層において実施することができる。従って個々のセカンダリＳＬＡプロバイダカバレッジ分析をレビューすること、または単一のＳＬＡクライアントプロビジョンディテールレコードにアフィリエイトする複数のセカンダリＳＬＡプロバイダリソースカバレッジ期間を集合的にレビューすることが可能である。プライマリＳＬＡプロバイダには、そのカバレッジが適当であるかを定義するために必要なデータが提供される。さらには、ＲＦｘビッドプロセス中に見積もられたカバレッジ時間と調和しないデータ入力、またはプライマリＳＬＡプロバイダが決定したカバレッジ範囲において過剰に限定的なデータ入力を持つ特定のセカンダリＳＬＡプロバイダを特定することも可能である。他の実施例においては、ＲＦｘビッド応答カバレッジ期間にロックすることにより、適切なセカンダリＳＬＡプロバイダにリソースレーバーカレンダレコードを適宜に完成させることを強制する、より高度なデータベースマネジメントシステムを採用することができる。
【０１３９】
ステップ１４５８〜ステップ１４６６はプライマリＳＬＡプロバイダのユーザーに提供されるインターフェースに関わるものであり、これにより、個々のセカンダリＳＬＡプロバイダのブラックアウトカバレッジ期間を選択し、これをプライマリＳＬＡプロバイダのユーザーが予想する予測スケジュール変更に関するコメントと共に適切なセカンダリＳＬＡプロバイダへと転送することが可能となる。その良い結果としては、潜在的なカバレッジのギャップを埋めることになる既存カレンダレコードカバレッジの変更、または追加レーバーリソースのサブミッタルが含まれる。新たなサブミッタルが生じた場合、上述したサブミッタルレビュープロセスが実施される。この分析および問題解決プロセスは、プライマリＳＬＡプロバイダが適正なＳＬＡプロビジョンカバレッジを保証することができると見なすまで繰り返されるのである。
【０１４０】
図１４Ｂに戻ると、ステップ１４５８においては、システム１００が選択したセカンダリＳＬＡプロバイダへのカバレッジ変更要求を発行するためのオプションをプライマリＳＬＡプロバイダに提示する。ステップ１４６０においては、プライマリＳＬＡプロバイダのユーザーが適切なセカンダリＳＬＡプロバイダを選択する。ステップ１４６２においては、プライマリＳＬＡプロバイダのユーザーが、特定されたセカンダリＳＬＡプロバイダの各々について、レビューを要することが判明している特定のブラックアウト期間を選択する。ステップ１４６４においては：既存の任務に割り当てられたヒューマンリソースのカレンダ変更の、ブラックアウト期間を軽減するための変更；またはカバレッジ範囲を改善するためのさらなるヒューマンリソースサブミッタルの作成；またはＲＦｘビッドを通じたさらなるセカンダリＳＬＡプロバイダの勧誘；のいずれかが実施される。ステップ１４６６においては、ブラックアウト期間に関して必要とされる変更にかかわらず、リアルタイムでリソースアベラビリティ査定が提供されるように個々のセカンダリＳＬＡプロバイダが独自のヒューマンリソーススケジュールを管理する。ヒューマンリソースカレンダ機能に関連して利用されるデータライブラリは、例えば表５８〜表６３のようなテーブル中に格納される。個々のレーバーリソースに適用可能な実際のカレンダデータのディテールは、例えば表５５〜表５７のようなテーブル中に格納される。
【０１４１】
図１５はヒューマンリソースカレンダ設定プロセスを説明するフロー図である。プロセスフロー１５００に確立された３つの設定モードとは：１）標準ワークスケジュールモード；２）非標準ワークスケジュールモード；そして３）日割りアクティビティモード；である。標準ワークスケジュールとは期待される標準スケジュールである。このモードにおいてセカンダリＳＬＡプロバイダは、あるパーチャスオーダーアサイメントにアフィリエイトする特定のレーバーリソースの基本スケジュールを確立する。このモードにおける入力により、就労者が就労可能な標準稼働日および標準稼働時間が確立されるのである。
【０１４２】
図１５に戻ると、フロー１５００はステップ１５０２から始まり、このステップにおいては、セカンダリＳＬＡプロバイダのユーザーがヒューマンリソースレーバーマネジメントモジュールをアクセスする。ステップ１５０５においては、セカンダリＳＬＡプロバイダがＧＵＩにより起動するメニューに入り、任務に割り当てられたヒューマンリソースレコードを選択する。ステップ１５０８においては、システム１００が任務に割り当てられた全てのヒューマンリソースのリスト表示レポートを提示する。ステップ１５１０においては、ユーザーが所望のヒューマンリソースレコードを選択する。ステップ１５１２においては、システム１００が関連するディテールおよび適切なカレンダへのリンクのリスト表示レポートを提示する。ステップ１５１５においては、ユーザーが「カレンダ」コントロールをアクティブ化する。ステップ１５１８においては、システム１００が以下を含む場合のあるオプションメニューを提示する：（１）標準スケジュールの設定；（２）他の予定されるブラックアウトの設定；（３）日割りアクティビティの維持。ステップ１５２０においては、ユーザーが「標準スケジュールの設定」コントロールをアクティブ化する。ステップ１５２２においては、システム１００がユーザーに、例えばその週全７日間の週単位カレンダ表示をプロンプトする。ステップ１５２５においては、ユーザーが入力し、これを保存する。ステップ１５２８においては、ユーザーが「他の予定されるブラックアウトの設定」コントロールをアクティブ化する。
【０１４３】
代表的な実施例においては、ユーザーは標準休日を表す全ての日について、１つのブラックアウトラジオボタンをアクティブ化させ、設定を保存するだけで良い。ユーザーにはさらに、各非ブラックアウト日の表示も提示されており、３０分毎に増分する時間休みが含まれているが、しかしこれは標準設定であり、必要であれば分刻みに変えることもできる。それぞれの増分する休みには：１）開始；および２）終了；の２つのコントロールがついている。ユーザーは開始時間および終了時間の両方を確立することにより、各日を設定する。終わると、ユーザーは設定を保存し、この標準カレンダ設定は適切なＳＬＡプロビジョンリソース用のデータベースへと格納される。非標準ワークスケジュールを入力すると、他の予定されるブラックアウト期間の指定が実施される。このタイプの予定されたブラックアウト期間の例は、休暇時期や標準的な会社休日である。これらの期間はその本質的性格から可変であり、従って非標準である。
【０１４４】
ステップ１５３０においては、システム１００がユーザーに：（１）レーバーの合意した休日の設定；および（２）予定された休暇の設定；をプロンプトする。ステップ１５３２においては、ユーザーが入力し、これを保存する。ユーザーは予定された休日および休暇／個人的な用事のある日を設定するようにプロンプトされる。ユーザーがコントロールをアクティブ化すると、例えば１２ヶ月に区分された年間カレンダ表示が提示される。ユーザーが適切な月を選択すると、その月の日付で区分化されたドリルダウン式表示が返される。するとユーザーは適切な日を選択し、その入力を保存する。ユーザーは、その選択が休日であるのか、個人的な休みであるのかを指定するようにプロンプトされる。ユーザーは入力を保存し、完全に終わるまで設定を続ける。
【０１４５】
ステップ１５３５においては、システム１００が、サービスプロビジョンリソースカレンダが現在アクティブであることを知らせるユーザー通知を提示する。ステップ１５３８においては、システム１００が、サービスプロビジョンリソースカレンダが現在アクティブであることを知らせる通知をプライマリＳＬＡプロバイダおよびセカンダリＳＬＡプロバイダヒューマンリソースのユーザーに提示する。ステップ１５４０においては、セカンダリＳＬＡプロバイダのユーザーが「日割りアクティビティの維持」コントロールをアクティブ化する。ステップ１５４２においては、特定のリソースに予定されたサービスプロビジョンコールアウトがかかっているかどうかが判定される。ステップ１５４２での答えが「はい」である場合、処理はステップ１５４５へと続く。
【０１４６】
日割りアクティビティのスケジュールは、個人的レーバーリソースに適用可能な現行の／連続的カレンダアベラビリティを表す。アウトソーシングされたレーバーを利用することの性質とは、一般に問題が生じた特定のクライアントの呼び出しを待つレーバーが存在しないことを意味する。従って、特定のレーバーリソースは、多数のＳＬＡクライアントへの、そして同様に多数のプライマリＳＬＡプロバイダへのサービスの提供に用いられることが一般的である。このカレンダモードは、システム１００において特定のブラックアウト期間を管理し、リアルタイムでアベラビリティレポートを提供することができる、現在のリソースレーバーを追跡するための機構を可能とするものである。
【０１４７】
ステップ１５４５〜ステップ１５５５の間、ユーザーは日割りブラックアウト管理をアクセスすることができるポイントに入る。ステップ１５４５においては、システム１００が稼働週および稼働日を選択するようにユーザーにプロンプトする。ステップ１５４８においては、システム１００がブラックアウト期間の開始を選択するようにユーザーにプロンプトする。ステップ１５５０においては、システム１００が、適切なヒューマンリソースにアフェイリエイトする予想されるサービスコールの継続期間を入力するようにユーザーにプロンプトする。ステップ１５５２においては、システム１００が追加ディテールフィールドを埋めるようにユーザーにプロンプトする。ステップ１５５５においては、システム１００がステップ１５４５〜ステップ１５５２の入力を保存する。適切なＳＬＡプロビジョンリソースがセカンダリＳＬＡプロバイダのユーザーにより指定され、そしてこのユーザーには、代表的には３０分毎に増分する画面で、現在の日割りカレンダ表示がデフォルトで提示される。ユーザーは日割りのアクティビティ開始時間および終了時間を選択し、その設定を保存する。この入力は格納され、そのＳＬＡプロビジョンリソースがブラックアウト時間フレーム中は派遣に対応できないことが表示される。カレンダディテールデータは、例えば表５５〜表５７のようなテーブル中に格納される。表５５は、レーバーリソースのＩＤおよび適切なＰＯアサイメントを格納する制御テーブルである。一人のレーバーリソースについて、複数のアサイメントカバレッジ期間が存在し得る。表５６は基本ワークスケジュールを格納し、表５７はセカンダリＳＬＡプロバイダが管理する非標準ブラックアウト期間のディテール並びに日割りブラックアウト期間を格納する。
【０１４８】
図１６はヒューマンリソースサービスプロビジョンマネジメント機能をサポートするデータベーススキーマを描いたものである。当業者には明らかなように、様々な実施例は、プライマリＳＬＡプロバイダにプロビジョニング労働力のロジスティクス的可視性と、彼らのクライアントのＳＬＡ需要を満たすために必要なプランニング機能を提供するものである。明確には示されていないが、１つ以上のＳＬＡクライアントプロビジョニングディテールレコードについて完全なレーバーブラックアウトが発生した場合のプライマリＳＬＡプロバイダへの系統的な警告通知は当然のプロビジョニング機能である。様々な実施例において、ＳＬＡクライアントプロビジョニングカバレッジのブラックホールに対抗するために系統的アクションおよび適切な通知が実施されることになるように、事前設定を実施することができる。
【０１４９】
先のアクティビティは、ＳＬＡサービスプロビジョンのロジスティクス的管理／マネジメントおよび適切なＳＬＡクライアントによる品質保証検証までの必要条件であった。ＳＬＡプロビジョンディスパッチに関する主要トピックには：１）ＳＬＡクライアントがサービスプロビジョンリクエストを作成し、プライマリＳＬＡプロバイダに提出するためのサービスプロビジョンリクエスト機能をイネーブルすること；２）設定されたセカンダリＳＬＡプロバイダのリスト並びにそれらの適用される価格およびサービスプロビジョンディスパッチに指定される適切な人材リソースのアベラビリティの出力に用いることができるプライマリＳＬＡプロバイダシステムクエリー機能をイネーブルすること；３）プライマリＳＬＡプロバイダが、潜在的なディスパッチに望ましい特定の就労可能なＳＬＡプロビジョンリソースを選択できるようにすること；４）プライマリＳＬＡプロバイダがサービスプロビジョンディスパッチリクエストレコードをセカンダリＳＬＡプロバイダへと系統的に提出できるようにすること；５）セカンダリＳＬＡプロバイダがリソースアベラビリティを確認し、そのリソースのプライマリＳＬＡプロバイダへの後の派遣が可能となるようにすること；そして６）リソースのＳＬＡクライアントへの派遣をプライマリＳＬＡプロバイダが確認することができるようにすること；が含まれる。
【０１５０】
図１７Ａはロジスティック的プロビジョンおよび管理機能に適用可能なプロセスフローを説明するフロー図である。プロセスフローはステップ１７０２から始まる。ステップ１７０２〜ステップ１７２０は、ＳＬＡクライアントがサービスプロビジョンリクエストをプライマリＳＬＡプロバイダへと提出するプロセスを説明するものである。ステップ１７０２においては、ＳＬＡクライアントのユーザーがシステム１００をアクセスして適切なメニューに入り、「プロビジョンリクエストの作成」コントロールをアクティブ化する。ステップ１７０２はユーザー制限または特定の認可権の行使について記載してはいないが、ＳＬＡクライアントが望む場合、本発明の様々な実施例にはユーザーの役割と特定のデータ処理権利／権限を組み入れることが可能である。ステップ１７０５においては、システム１００がユーザーにＳＬＡクライアントロケーションおよび識別子を指定するようにプロンプトする。ステップ１７０５はクエリー処理を始めるためのロケーションのＳＬＡクライアントのユーザーの選択を表す。これは単なるサンプルモードであり、固有の制約ではない。例えば、クエリー処理はコントラクトの照会または特定のプロビジョンディテールレコードの検索から開始することができる。ステップ１７０８においては、コントラクトおよび適切なＳＬＡアグリーメントプロビジョンサービスのリスト表示をシステム１００がユーザーに提示する。ステップ１７０８は図１７Ｂで補足されており、図１７ＢはＳＬＡクライアントのユーザーによる重要なＳＬＡプロビジョン情報へのアクセスをかなえるアクティブコントロールに埋め込まれた形式の単純なＧＵＩを描いたものである。ＳＬＡクライアントのユーザーは、適用可能なＳＬＡプロビジョンディテールレコードを即座に認識する、または埋め込み型コントロールを使った情報レビューを通じてどの関連するＳＬＡプロビジョンディテールレコードにプロビジョニングが必要かを確認する。図１７Ｂにおいては、コントロール群は、ユーザーにさらなる情報ビューを提供するために全て潜在的にアクティブである。しかしながら、符号１７０８―Ａ９は、少なくとも１つのレコードが符号１７０８−Ａ１において選択されるまでは、インアクティブ／ゴースト表示である。各埋め込みリンクは、その列見出しに適切な情報を提示する新たなＵＩをユーザーに提供する。ＳＬＡクライアントのユーザーは、ＳＬＡサービスプロビジョンリクエストにどのＳＬＡプロビジョンディテールレコードを関連付けるのかを指定するために設けられたチェックボックスを使用する。ステップ１７１０における特定レコードの選択は、更なるＵＩ入力フォームをトリガすることになり、ＳＬＡクライアントのユーザーは所望の場合、これを使ってステップ１７１２においてコメントを付加することができる。
【０１５１】
ステップ１７１０においては、ユーザーが所望のＳＬＡプロビジョンサービスレコードを選択し、選択を保存する。ステップ１７１２においては、システムＧＵＩが追加の入力フィールドをユーザーに提示する。ユーザーは追加入力を完了し、保存する。表６４〜表６６を見れば当業者には明らかなように、代表的な実施例においては、ステップ１７０２〜ステップ１７１２に説明したプロセス中にＳＬＡクライアントのユーザーが入力するのはわずかなフィールドだけであり、残りは全てデフォルトデータである。プロビジョンサービスワークの性質が追加データ要素を要するものである場合、そのような追加入力フィールドオプションをデータベースに追加することは容易である。
【０１５２】
ステップ１７１５においては、システム１００がユーザーに、ＳＬＡプロビジョンサービスリクエストをＳＬＡプロバイダに提出するようにプロンプトする。ステップ１７１５では明確には示していないが、様々な実施例においてはＳＬＡクライアントのユーザーは、ビジネス条件がそのようなシナリオを要求する場合、サービスプロビジョンリクエストを例えばテクニカルアカウントマネージャーなど、指定されたプライマリＳＬＡプロバイダのユーザーに可変的にルーティングする能力を持つものであっても良い。ステップ１７０２〜ステップ１７１５に適用可能なディテールは、例えば表６４〜表６７のようなテーブル中に格納される。ステップ１７２０においては、ユーザーがＳＬＡプロビジョンサービスリクエストをＳＬＡプロバイダに提出する。
【０１５３】
ステップ１７２１〜ステップ１７２８は、プライマリＳＬＡプロバイダがＳＬＡクライアントサービスプロビジョンリクエストにアフィリエイトするセカンダリＳＬＡプロバイダディテールに対する系統的なアクセスを得るためのプロセスを説明するものである。ステップ１７２１においては、システム１００が新たに提出されたＳＬＡプロビジョンサービスリクエストについてプライマリＳＬＡプロバイダに通知する。ステップ１７２１には明確に示してはいないが、サービスプロビジョンリクエストの応答性は代表的にはシステム１００内で管理およびマネジメントされており、このことは、適切なパーティによるサービスプロビジョンリクエストの取り扱いが事前設定された期待値／スケジュール通りに進められていない場合に表３０の「DispatchResponseTimeID」フィールドがアクティブかつ探索通知を作成するために用いられることを意味する。さらに様々な実施例においては、探索通知を特定のプライマリＳＬＡプロバイダのユーザーへと可変的にルーティング／指定するために、拡張したユーザーの役割機能が用いられる。一方でＳＬＡクライアントのユーザーには、サービスプロビジョンリクエストの取り扱いのステータスが通知される。
【０１５４】
ステップ１７２３においては、プライマリＳＬＡプロバイダのユーザーが、例えばＧＵＩを介して新たなＳＬＡプロビジョンサービスリクエストにアクセスする。ステップ１７２５においては、プライマリＳＬＡプロバイダのユーザーが「プロビジョンカバレッジの表示」コントロールをアクティブ化する。ステップ１７２８においては、システム１００がユーザーに、認可されたセカンダリＳＬＡプロバイダおよびそれぞれのプロビジョンディテールレコードに関するプロビジョンサービスを提供するために承認された適切なヒューマンリソースのリスト表示を提示する。ディスプレイは、代表的には例えばアベラビリティ、値段、サービスメトリクスを示す。ステップ１７２８は、図１７Ｃに示すように、アフィリエイトするセカンダリＳＬＡプロバイダの概要出力画面を適切なプライマリＳＬＡプロバイダのユーザーに提示する。
【０１５５】
図１７Ｃにおいては、符号１７２８−Ａ１は、プライマリＳＬＡプロバイダのユーザー向けの単純な選択チェックボックスオプションである。しかしながら、符合１７２８−Ａ５中の利用可能なリソース数が０である場合、このオプションは通常、インアクティブ／ゴースト表示される。ユーザーが符号１７２８−Ａ５中のアクティブコントロールを立ち上げると、それぞれの利用できるヒューマンリソースと、彼等のカレンダアベラビリティの概要のリスト表示が提示される。プライマリＳＬＡプロバイダのユーザーは利用可能なビジネス情報により潜在的なディスパッチ用リソースの可視性が得られるだけではなく、重要な経理および品質保証ビジネス情報へのウィンドウも提供されることになり、クラス最高の意思決定プロセスが可能となるのである。
【０１５６】
ステップ１７３０〜ステップ１７３２は、所望された場合、プライマリＳＬＡプロバイダが適切なＳＬＡクライアントロケーションへと派遣すべき推奨される特定の就労可能なＳＬＡプロビジョンリソースを選択するプロセスを説明するものである。ステップ１７３０においては、就労可能なリソースが複数いる場合、プライマリＳＬＡプロバイダのユーザーが所望のセカンダリＳＬＡプロバイダレコードおよびヒューマンリソースの優先順位を選択する。ステップ１７３２においては、プライマリＳＬＡプロバイダのユーザーが選択を保存する。ステップ１７３０は１つのセカンダリＳＬＡプロバイダレコードのみが選択されたプロセス例を説明するものであるが、複数レコードを選択することは可能である。プライマリＳＬＡプロバイダのユーザーは、プロビジョンディスパッチリクエストレコードを受ける複数のセカンダリＳＬＡプロバイダを選択することができる。この場合、代表的な実施例においては、システム１００はＦＩＦＯ方式でワークフローを取り扱う。他のシナリオにおいては、性質上、状況が重大であり、セカンダリＳＬＡプロバイダのアフィリエーションの如何を問わず、全ての就労可能リソースを派遣することが命じられる場合もあり得る。本発明の様々な実施例は、複数のセカンダリＳＬＡプロバイダからの複数のＳＬＡプロビジョンリソースディスパッチリクエストを可能とするものである。
【０１５７】
セカンダリＳＬＡプロバイダレコードを選択すると、その後のアプリケーション機能は所望があればユーザーによるさらなる詳細へのドリルダウンを可能とし、プライマリＳＬＡプロバイダのユーザーは推奨される一人のＳＬＡプロビジョンリソース、またはそのプロビジョンコールアウトに望ましいリソース群のリストを指定することができる。特定のリソースが望まれる理由は多数ある。その理由に含まれるのは、例えば過去の品質評価指標またはＳＬＡクライアントの選好性である。この情報は、例えば表６８および表６９のようなテーブル中に格納される。表７０および表７１のようなテーブル中に格納されるデータは、表６８中のフィールドへのソースデータとして作用する。派遣に予定された推奨ＳＬＡプロビジョンリソースのＩＤは、例えば表６９中に格納される。
【０１５８】
ステップ１７３５〜ステップ１７３８は、プライマリＳＬＡプロバイダがサービスプロビジョンディスパッチリクエストを発行するプロセスを説明するものである。ステップ１７３５においては、プライマリＳＬＡプロバイダのユーザーは、サービスプロビジョンディスパッチリクエストを送るようにプロンプトされる。ステップ１７３８においては、プライマリＳＬＡプロバイダのユーザーが適切なセカンダリＳＬＡプロバイダにサービスプロビジョンディスパッチリクエストを提出する。
【０１５９】
ステップ１７４０〜ステップ１７５５は、セカンダリＳＬＡプロバイダがリソースアベラビリティと適切なプライマリＳＬＡプロバイダへのリソースディスパッチとを系統的に確認するプロセスを説明するものである。ステップ１７４０においては、システム１００はセカンダリＳＬＡプロバイダに新たなサービスプロビジョンディスパッチリクエストについて通知する。ステップ１７４２においては、セカンダリＳＬＡプロバイダのユーザーが新たなサービスプロビジョンディスパッチリクエストをアクセスする。説明にはないが、ステップ１７４０〜ステップ１７４２はステップ１７２１の説明と同様、システム１００内でより厳格に管理／マネジメントすることが可能である。
【０１６０】
ステップ１７４５においては、セカンダリＳＬＡプロバイダのユーザーがヒューマンリソースアベラビリティを確認する。ステップ１７４５はリソースアベラビリティが肯定的な結果である場合に限り説明している。当業者には明らかなように、常にそうであるわけでは、必ずしもない。しかしながら、本発明の様々な実施例の突出した特徴を明確に示すために否定的な結果から生じる処理については省略する。もし、管理されているカレンダデータに反してリソースアベラビリティが否定された場合、代表的な実施例においては、システム１００が品質評価指標を取る目的でそのようなセカンダリＳＬＡプロバイダの欠陥を追跡し、セカンダリＳＬＡプロバイダのリソース能力およびアベラビリティに関する非効率性の係数を計算する。リソースアベラビリティがあることが検証されると、システム１００は通常、ディスパッチ確認を適切なプライマリＳＬＡプロバイダへと送るようにセカンダリＳＬＡプロバイダをプロンプトする。このプロセスの間、さらなるディテールが入力、格納され、これが保存されると、表７２中に格納されるデータベースに新たなレコードがアップロードされる。
【０１６１】
ステップ１７４８においては、システム１００がセカンダリＳＬＡプロバイダにヒューマンリソースディスパッチ通知をプライマリＳＬＡプロバイダに送付するようにプロンプトする。ステップ１７５０においては、セカンダリＳＬＡプロバイダのユーザーが「ディスパッチ確認の提出」コントロールをアクティブ化する。ステップ１７５２においては、セカンダリＳＬＡプロバイダが追加の入力フィールドを埋め、入力を保存する。ステップ１７５５においては、セカンダリＳＬＡプロバイダがディスパッチレコードを提出する。
【０１６２】
ステップ１７４０〜ステップ１７５５の間、セカンダリＳＬＡプロバイダはステップ１７４５においてＳＬＡプロビジョンリソースのＩＤ、派遣時間、そして予想される到着時間を確立するように強制され、そしてその入力は例えば表７２中に格納される。さらには、施設へのアクセス、道順などに関するロケーション情報が提供され、そしてこのプロセス中にセカンダリＳＬＡプロバイダによりアクナリッジされる。ステップ１７４０〜ステップ１７５５がセカンダリＳＬＡプロバイダにロジスティクス的なレーバー派遣を強制するものである分、これらのステップはセカンダリＳＬＡプロバイダに適正なプロビジョンディスパッチに向けたＳＬＡクライアントの重要なロジスティクス的情報を提供するものでもある。
【０１６３】
ステップ１７５８〜ステップ１７６８は、プライマリＳＬＡプロバイダがＳＬＡクライアントに、プロビジョンロケーションへのＳＬＡプロビジョンリソースディスパッチについて系統的に通知するプロセスを説明するものである。ステップ１７５８においては、システム１００がプライマリＳＬＡプロバイダにディスパッチレコードについて通知する。ステップ１７６０においては、プライマリＳＬＡプロバイダがディスパッチ確認レコードをアクセスし、受領を確認する。ステップ１７６２においては、システム１００がプライマリＳＬＡプロバイダに、ディスパッチ確認通知をＳＬＡクライアントへと送るようにプロンプトする。ステップ１７６５においては、プライマリＳＬＡプロバイダのユーザーが「ディスパッチ確認の送付」コントロールをアクティブ化する。ステップ１７６８においては、システム１００がＳＬＡクライアントに通知を送付し、ディスパッチレコードがオンラインで利用可能となる。ステップ１７５８〜ステップ１７６０は、所望であれば探索設定により時間管理およびマネジメントが可能である。ステップ１７５８〜ステップ１７６８のプロセスにより、ＳＬＡクライアントでの問題に始まり、ＳＬＡクライアントのユーザーにプロビジョンリソースの予定到着時間の通知が行くことで終わる一巡が完了する。
【０１６４】
図１８は、ロジスティクス的プロビジョンおよび管理機能をサポートするデータベーススキーマを描いたものである。当業者には明らかなように、本発明の様々な実施例は、切望されていた可視性とロジスティクス的コントロールをプロビジョニング努力活動へと導入するだけではなく、必要とされる人材とコミュニケーションを単一のプラットフォームへと統合化する支援データスキーマおよびアプリケーション処理を用いている。明確に説明はしていないが、様々な実施例においては、自動化を強化した構成設定を確立することで系統的なプロビジョニングリクエストおよびレーバーディスパッチを可能とすることができる。このようなシナリオは、ＳＬＡクライアントプロビジョニングサービスリクエストに対して適切なプライマリＳＬＡプロバイダの人材が対応することができない時に望ましい場合が多い。
【０１６５】
図１９Ａおよび図１９ＢはＳＬＡプロビジョンワークアクナリッジメントおよび品質保証に適用可能なプロセスを説明するものである。図１９Ａおよび図１９Ｂの説明は、サービスプロビジョンディスパッチの後に続いて発生する対応するプロビジョンアクティビティの追跡とドキュメンテーションに焦点を置いたものである。セカンダリＳＬＡプロバイダまたはＳＬＡクライアントが、派遣されたプロビジョンリソースがプロビジョンロケーションサイトに現れなかったことを通知するためにプライマリＳＬＡプロバイダに連絡するというシナリオにおいて、システム１００はそのようなシナリオを取り扱うための機能を含むものとすることができる。ＳＬＡクライアントのユーザーに、無断欠勤（No-Show）ワークフロープロセスを起動するための機能を提供すること、またはプライマリＳＬＡプロバイダのユーザーとの、例えば電話での直接コミュニケーションにより、既に格納されている現行のプロビジョンワークに適切なデータベースレコードを参照しつつ就労可能なプロビジョンリソースのレビュー（図１７Ｃ参照）を行うポイントであるステップ１７２５においてワークフロープロセスを再始動することができる。
【０１６６】
図１９Ａおよび図１９Ｂの説明は：１）サービスプロビジョンディスパッチリクエストに応えて、セカンダリＳＬＡプロバイダのリソースが、例えば実施した仕事、配備されたマテリアル、および時間に関するディテールをシステム１００へと入力するためにサービスディスポジションバウチャー機能にアクセスできるようにすること；２）セカンダリＳＬＡプロバイダがサービスディスポジションバウチャーをレビューおよび承認処遇決定用にプライマリＳＬＡプロバイダへと提出することができるようにすること；３）プライマリＳＬＡプロバイダが、セカンダリＳＬＡプロバイダからのサービスディスポジションバウチャーをレビューして承認することができるようにすること；４）プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダサービスディスポジションバウチャーを参照してプライマリＳＬＡプロバイダサービスディスポジションバウチャーを作成し、これをＳＬＡクライアントにレビューおよび処遇決定用に提出することができるようにすること；５）ＳＬＡクライアントがプライマリＳＬＡプロバイダサービスディスポジションバウチャーを処理して品質保証評価情報を提供することができるようにすること；そして６）ＳＬＡクライアントのサービスディスポジションバウチャー処理に応えて、プライマリＳＬＡプロバイダおよびセカンダリＳＬＡプロバイダへの系統的通知を可能にすること；に焦点を当てたものである。
【０１６７】
図１９Ａを参照すると、プロセスフロー１９００はステップ１９０２から始まり、このステップにおいてはセカンダリＳＬＡプロバイダのリソースがサービスプロビジョニングコールアウトを完了する。ステップ１９０４〜ステップ１９１８はＳＬＡプロビジョンリソースのサービスディスポジションバウチャーの取り扱いプロセスを説明するものである。ステップ１９０４においては、セカンダリＳＬＡプロバイダのリソースがメニュー方式のＧＵＩに入り、「ワークバウチャー」機能を選択する。ステップ１９０６においては、システム１００がオープンステータスにある全てのプロビジョンディスパッチレコードのリスト表示レポートを提示する。ＳＬＡプロビジョンリソースに提示されるこのリスト表示は、一般に複数の任務（例えばオープンディスパッチレコードが多い場合の複数任務）を取り扱うことができる。
【０１６８】
ステップ１９０８においては、ユーザーが所望のプロビジョンレコードを選択する。ステップ１９０８にてとったアクションにより、システム１００はステップ１９１０においてサービスディスポジションバウチャーＵＩを提示する。ＵＩは通常、プロビジョンディスパッチレコードセットにアフィリエイトする関連ディテールの全てを継承している。従って、ＳＬＡプロビジョンリソースは一般に、実施したサービスプロビジョンワークに適切なデータ入力を完了する（これはステップ１９１２にて実行される）だけで良いのである。ステップ１９１４の入力の保存においては、システム１００が、例えば表７３〜表７７にあるトランザクションディテールを格納する。
【０１６９】
バウチャーレコードが保存されると、ＳＬＡプロビジョンリソースはそのバウチャーを事前設定されたセカンダリＳＬＡプロバイダのユーザーへと、レビュー用、そしてステップ１９１６および１９１８における後のトランザクション処理用に提出するようにプロンプトされる。ステップ１９１８においてとられるアクションにより、ステップ１９２０において事前設定されたセカンダリＳＬＡプロバイダのユーザーへの通知がトリガされる。
【０１７０】
ステップ１９２２においては、ユーザーはメニューまたは提供されるリンクから、新たなプロビジョンバウチャーにアクセスする。ステップ１９２２は、セカンダリＳＬＡプロバイダのユーザーがサービスディスポジションバウチャーの処理をすることができる特定の機能的アプリケーションモジュールに入るプロセスを説明するものである。このアクセスは、標準的メニューの利用により、またはそのバウチャートランザクションに適切な特定のダッシュボード通知リンクをアクティブ化することにより可能となる。
【０１７１】
ステップ１９２４〜ステップ１９３４は、セカンダリＳＬＡプロバイダのサービスディスポジションバウチャーの取り扱いについて説明するものである。ステップ１９２４においては、システム１００がユーザーにバウチャーインターフェースＧＵＩを提供する。バウチャーはセカンダリＳＬＡプロバイダパーチャスオーダーに記載された値段を含んでいる。システム１００は、ＳＬＡプロビジョンリソースにより提出されたバウチャー情報と共に、適切なセカンダリＳＬＡプロバイダパーチャスオーダーおよび適切なＰＯ行項目から統合化された情報をセカンダリＳＬＡプロバイダのユーザーに提示する。ステップ１９２４は基本的に、セカンダリＳＬＡプロバイダにプロビジョンワークが完了したことを認識させ、バウチャーに含まれるパーチャスオーダーディテールのレビューを提供する検証ステップである。
【０１７２】
ステップ１９２６においては、ユーザーがシステム入力を介してバウチャーディテールを検証して保存する。ステップ１９２６はセカンダリＳＬＡプロバイダのユーザーによる、データベース中に格納された情報の物理的検証である。検証アクションの結果、ステップ１９２８においてシステムはセカンダリＳＬＡプロバイダのユーザーに何らかの適切な課税割り当てを入力するようにプロンプトすることになる。課税データ入力または検証が終わると、課税査定が事前設定されている場合は、セカンダリＳＬＡプロバイダのユーザーはステップ１９３０においてデータ設定を保存する。
【０１７３】
ステップ１９３２〜ステップ１９３４により、設定されたプライマリＳＬＡプロバイダのユーザーへとワークアクナリッジメントバウチャーが提出される。ステップ１９３２においては、システム１００がユーザーに、バウチャーをプライマリＳＬＡプロバイダへと提出するようにプロンプトする。ステップ１９３４においては、ユーザーがバウチャーをレビュー／承認用にプライマリＳＬＡプロバイダへと提出する。
【０１７４】
ステップ１９３６〜ステップ１９４４は、プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダサービスディスポジションバウチャーの提出を受けてレビューおよび処遇決定を実施するプロセスを説明するものである。ステップ１９３６〜ステップ１９３８では、設定されたプライマリＳＬＡプロバイダのユーザーが提出されたセカンダリＳＬＡプロバイダサービスディスポジションバウチャーにアクセスすることができるようになる。ステップ１９３６においては、システム１００がプライマリＳＬＡプロバイダに新たなプロビジョンバウチャーについて通知する。ステップ１９３８においては、プライマリＳＬＡプロバイダのユーザーがメニューまたは提供されるリンクから、新たなプロビジョンバウチャーをアクセスする。
【０１７５】
ステップ１９４０においては、システム１００がバウチャーインターフェースＧＵＩをユーザーに提示する。バウチャーはセカンダリＳＬＡプロバイダパーチャスオーダーにて確立された値段を含んでいる。プライマリＳＬＡプロバイダのユーザーには通常、適切なサービスプロビジョンアクティビティはもちろん、セカンダリＳＬＡプロバイダパーチャスオーダーにも関連する全ディテールを詳述するレコード表示が提供される。ステップ１９４２においては、ユーザーはその中に提供されるディテール情報を承認するか、拒否するかの選択支を持っている。ステップ１９４４には、提出されたサービスディスポジションバウチャーが承認されるという肯定的アクションが描かれている。ステップ１９４４の後、セカンダリＳＬＡプロバイダは、提出したサービスディスポジションバウチャーの承認について系統的に通知される。
【０１７６】
ステップ１９４６〜ステップ１９５４は、プライマリＳＬＡプロバイダが、承認されたセカンダリＳＬＡプロバイダサービスディスポジションバウチャーからの詳細を、適切なＳＬＡクライアントパーチャスオーダーデータを引き継ぐ独自のプライマリＳＬＡプロバイダサービスディスポジションバウチャーへと統合化することができるプロセスを説明するものである。ステップ１９４４においてバウチャーが承認されると、ステップ１９４６において、プライマリＳＬＡプロバイダのユーザーが、例えば提供されたＵＩのコントロールをアクティブ化することにより、新たなサービスディスポジションバウチャーを作成するようにプロンプトされる。説明するプロセスは、単に説明の便宜上の理由から直線的性質を持っている。新たなサービスディスポジションバウチャーの作成は、プライマリＳＬＡプロバイダの設定しだいで別の時点、別の人間により、様々な方法で実施することができる。ステップ１９４８においてユーザーが新たなサービスディスポジションバウチャーを作成すると、これがサービスディスポジションバウチャーをステップ１９０８〜ステップ１９１０で取り扱ったセカンダリＳＬＡプロバイダの場合と類似したデータの統合化プロセスをトリガすることになる。
【０１７７】
図１９Ｂを参照すると、ステップ１９５０において、システム１００がユーザーにバウチャーインターフェースＧＵＩを提示する。このバウチャーはＳＬＡクライアントパーチャスオーダーで確立された値段を含んでいる。システム１００は、実施された物理的サービスプロビジョンワークに適用可能なディテールと共にＳＬＡクライアントパーチャスオーダーに関連する経理的ディテールを含むプライマリＳＬＡプロバイダサービスディスポジションバウチャーを作成する。
【０１７８】
ＳＬＡプロビジョンリソースが入力したサービスプロビジョンワークに関するデータ入力以外については、ＳＬＡクライアントがセカンダリＳＬＡプロバイダに適用可能な関連ディテールを見なければならないビジネス上の理由が必ずしもあるわけではない。従って作成される新たなプライマリＳＬＡプロバイダサービスディスポジションバウチャーは、ＳＬＡクライアントとプライマリＳＬＡプロバイダ間の関係に関わるディテールを含むものである。
【０１７９】
ステップ１９５２〜ステップ１９５４は、プライマリＳＬＡプロバイダのユーザーが完成したプライマリＳＬＡプロバイダサービスディスポジションバウチャーを承認し、ＳＬＡクライアントへと提出するために取るアクションを説明するものである。システム１００は新たなプライマリＳＬＡプロバイダサービスディスポジションバウチャーを作成するが、そのデータは、実際は表７３〜表７７に含まれるデータのサブセットである。当業者には明らかなように、参照データベース接続を使って他の単純なデータベース構造により個別のテーブル中にこのデータを格納して保持することも可能である。
【０１８０】
ステップ１９５６〜ステップ１９８８は、提出されたプライマリＳＬＡプロバイダのサービスディスポジションバウチャーを処理する間、ＳＬＡクライアントが取るステップを説明するものである。ステップ１９５６においては、システム１００が新たなプロビジョンバウチャーについてＳＬＡクライアントに通知する。ステップ１９５８においては、システム１００がユーザーにバウチャーインターフェースＧＵＩを提示する。バウチャーはＳＬＡクライアントパーチャスオーダーに確立された値段を含んでいる。
【０１８１】
ステップ１９６０においては、提出されたサービスディスポジションバウチャーを承認または拒絶するようにＳＬＡクライアントのユーザーがプロンプトされる。明確に説明はしていないが、様々な実施例においては、ＳＬＡクライアントはユーザーの役割とワークフローを強化し、承認設定をより複雑かつ堅牢にすることができる。ＳＬＡクライアントユーザーがステップ１９６０においてサービスディスポジションバウチャーに含まれる情報を承認したと想定した場合、ステップ１９６４においてユーザーは、システム１００によりステップ１９６４〜ステップ１９６６の品質保証査定セッションを始めるコントロールをアクティブ化するようにプロンプトされる。ステップ１９６４においては、システム１００がＱ／Ａ査定を完成するようにユーザーにプロンプトする。ステップ１９６６においては、ユーザーが「Ｑ／Ａセッション」コントロールをアクティブ化する。Ｑ／Ａセッションが開始されると、システム１００はステップ１９６８においてユーザーにＧＵＩフォームを提示し、ＳＬＡクライアントはサービスプロビジョンワークの品質および適時性、並びに物理的サービスプロビジョニングに先立つ予備的ロジスティクスの適時性および管理の容易性を査定することができるようになる。
【０１８２】
査定が完了すると、ステップ１９７０において、ＳＬＡクライアントはその入力を保存するようにプロンプトされる。このアクションは、ステップ１９７２におけるシステム１００の更新およびその後のステップ１９７４における適切なプライマリＳＬＡプロバイダおよびセカンダリＳＬＡプロバイダのユーザーへの系統的な承認通知をトリガする。
【０１８３】
ステップ１９６０において、ＳＬＡクライアントのユーザーがサービスディスポジションバウチャーを拒絶した場合、処理はステップ１９７８へと進む。この時点からプロビジョニングサービスの状況に関する論議が存在することになるため、ステップ１９７８においては、ＳＬＡクライアントのユーザーは、拒絶査定を完成させるようにプロンプトされる。
【０１８４】
ステップ１９８０においては、システム１００がＳＬＡクライアントのユーザーに、特定の情報に対する異議申し立てと、その異議の正当性を支持するためのコメント入力の設定が可能なＧＵＩを提示する。ステップ１９８２においては、ＳＬＡクライアントのユーザーが査定を完了し、入力を保存する。このアクションによりシステム１００がトリガされてステップ１９８４においてレコードを格納し、その後のステップ１９８６において適切なプライマリおよびＳＬＡプロバイダのユーザーに拒絶通知を格納する。ステップ１９８８は、アプリケーション処理を永久ループにする目的で設計することができる再開点を表し、ここで調停プロセスを導入することができ、そして入力を複数パーティから取得して格納することができる。バウチャー拒絶に関するディテールは、例えば表８１のようなテーブル中に格納され、拒絶コード自体は例えば表８０のようなテーブル中に格納される。
【０１８５】
図２０はＳＬＡプロビジョンワークアクナリッジメントおよび品質保証をサポートするデータベーススキーマを描いたものである。
【０１８６】
プロビジョンの失敗が、代表的には：１）派遣の非適時性；２）プロビジョン到着の適時性；または３）プロビジョン失敗；の問題であることを前提とすると、ＳＬＡペナルティ査定はデータベース比較の問題である。シナリオ１）および２）の場合、ステータスコードマネジメント、日時レコード刻印、およびユーザー検証を系統的に用いることで適切にプロビジョニングのこれらの側面を監視することが可能である。シナリオ３）の場合、ペナルティ査定はＳＬＡクライアントのバウチャー処遇決定に応じたものとなる。請求／支払い機能の問題は、システム１００の経理データ処理機能に関わる。情報スレッドは以下のようにシーケンスされる。
【０１８７】
セカンダリＳＬＡプロバイダＰＯレコードに、
ＳＬＡクライアントコントラクト情報が結び付けられる、
プロビジョンディテールレコードが結び付けられる、
ＳＬＡクライアントＰＯレコードが結び付けられる、
プライマリＳＬＡプロバイダＲＦｘビッドが結び付けられる、
セカンダリＳＬＡプロバイダＲＦｘビッド応答が結び付けられる、
ＲＦｘビッド落札が結び付けられる。
【０１８８】
上述の情報スレッドは結果としてＳＬＡプロビジョンカバレッジをもたらす管理上の設定を完了するものである。
【０１８９】
続く情報スレッドは以下の通りである。
【０１９０】
ＳＬＡクライアントサービスディスポジションバウチャー処理に、
ＳＬＡクライアントサービスプロビジョンリクエスト（プロビジョンディテールレコードを参照して生成される）が結び付けられる、
プライマリＳＬＡプロバイダサービスプロビジョンディスパッチリクエストが結び付けられる、
セカンダリＳＬＡプロバイダサービスプロビジョンディスパッチが結び付けられる、
プロビジョンリソースサービスディスポジションバウチャーが結び付けられる、
セカンダリＳＬＡプロバイダサービスディスポジションバウチャーが結び付けられる、
プライマリＳＬＡプロバイダサービスディスポジションバウチャーが結び付けられる。
【０１９１】
以下に説明する様々な要素には：１）承認されたＳＬＡクライアント承認サービスディスポジションバウチャーの、設定された系統的抽出；２）プライマリＳＬＡプロバイダからＳＬＡクライアントへの請求明細書ファイルの系統的生成；３）セカンダリＳＬＡプロバイダからプライマリＳＬＡプロバイダへの請求明細書ファイルの系統的生成；４）ＳＬＡクライアントの支払時に支払い領収書をアップロードするプライマリＳＬＡプロバイダ支払い受領データ；および５）ＳＬＡクライアントの支払い時に仮定されたセカンダリＳＬＡプロバイダへのプライマリＳＬＡプロバイダ支払い解除；が含まれる。
【０１９２】
図２１は、請求・支払い機能に適用可能なプロセスを説明するフロー図である。ステップ２１０２〜ステップ２１０５は、ＳＬＡクライアントの承認したサービスディスポジションバウチャーの基本的抽出を説明するものである。この抽出は、プログラムのセットアップ時に設定可能であり、抽出サイクル期間の指定が要求される。抽出レコードセット情報は、例えば表８２、表８３のようなテーブル中に格納される。表８３は個々のサービスディスポジションバウチャー行項目のＩＤを含んでいる。従ってデータ抽出の条件として、抽出処理により確実にこのテーブル内でレコードが不在となるため、そのレコードが誤って繰り返し抽出されることがないのである。明確に説明はしていないが、レコードの抽出は、特定のレコードセット抽出のために支払い条件や経理サイクルといった可変要因を導入した、より堅固な方式で設定することもできる。
【０１９３】
ステップ２１０８〜ステップ２１１０は、請求明細書ファイルが基本抽出から生成されるプロセスを説明するものである。ステップ２１０８においては、システム１００が設定どおりに各ＳＬＡクライアントの請求明細書ファイルを作成する。ステップ２１１０においては、システム１００が設定どおりに各セカンダリＳＬＡプロバイダの請求明細書ファイルを作成する。システム１００は完全ライフサイクルトランザクションで企業中心的であるため、明細書ファイルは、プライマリＳＬＡプロバイダに代わってのＳＬＡクライアントへの請求、およびセカンダリＳＬＡプロバイダに代わってのプライマリＳＬＡプロバイダへの請求の両方について生成される。抽出サイクル期間内において複数のＳＬＡクライアントおよび複数のセカンダリＳＬＡプロバイダとのトランザクションがあった場合、明細書ファイルは複数となる。
【０１９４】
ステップ２１１２〜ステップ２１２８は、ＳＬＡプロバイダの請求明細書ファイルの取り扱いを集合的に説明するものである。これらのステップは、指定されたプライマリＳＬＡプロバイダのユーザーがコンパイルされたファイルをアクセスし、レビューすることができる制御プロセスを説明している。プロセスは設定可能であり、様々な実施例においては、プライマリＳＬＡプロバイダがレビューおよびリリース処理を実施しないことを選択した場合は無視することができる。ステップ２１１２においては、システム１００が、認可されたプライマリＳＬＡプロバイダのユーザーに新たな請求明細書ファイルが処理可能となったことを通知する。ステップ２１１５においては、プライマリＳＬＡプロバイダのユーザーが「経理マネジメントモジュール」をアクセスする。ステップ２１１８においては、プライマリＳＬＡプロバイダが請求明細書ファイルをアクセスする。ステップ２１２０においては、プライマリＳＬＡプロバイダが新たな請求明細書ファイルを選択する。ステップ２１２２においては、システム１００が「請求明細書概要」画面をユーザーに表示する。ステップ２１２５においては、システム１００が請求明細書ファイルをリリースするようにユーザーにプロンプトする。ステップ２１２８においては、ユーザーが請求明細書ファイルをリリースする。ステップ２１３０においては、システム１００が可変ＳＬＡクライアント請求明細書ファイルを生成する。
【０１９５】
ステップ２１２８において請求明細書ファイルがリリースされると、システム１００はステップ２１３０〜ステップ２１３２においてパースされたＳＬＡクライアントおよびセカンダリＳＬＡプロバイダ請求明細書ファイルの画面を生成する。ステップ２１３５においては、認可されたシステムユーザーに、請求明細書ファイルがレビュー用に閲覧可能となったことが通知される。これらのファイルは、システム１００内において認可され、設定されたユーザーのみに閲覧可能である。通常は特定の企業体に関わるレコードのみが、その企業体（例えばＳＬＡクライアントまたはセカンダリＳＬＡプロバイダ）のユーザーにより閲覧可能である。ビジネスメソッドがそのようなトランザクションモードを保障するものである場合、所望であれば例えばＥＤＩなどを介して明細書ファイルを伝送してもよい。
【０１９６】
ステップ２１３８〜ステップ２１４８は、セカンダリＳＬＡプロバイダおよびＳＬＡクライアントがファイルの受領をアクナリッジするプロセスを説明するものである。ＳＬＡクライアントのアクナリッジメントは、いかなる形においてもセカンダリＳＬＡプロバイダファイルの受領アクナリッジメントとは関連していない、即ち独立したものである。ＥＤＩおよびＥＦＴ技術があれば、これはサービスディスポジションバウチャー承認に基づいて金銭を動かすサイレントトランザクションプロセスとすることができる。結局のところ、経理トランザクションは既に様々な承認プロセスを経たであろうソースデータ要素に限定されているはずなのである。
【０１９７】
ステップ２１３８においては、認可されたＳＬＡユーザーが経理マネジメントモジュールをアクセスする。ステップ２１４０においては、ＳＬＡクライアントが請求明細書ファイルをアクセスする。ステップ２１４２においては、システム１００が請求明細書受領アクナリッジメントをプライマリＳＬＡプロバイダに通知する。ステップ２１４５においては、システム１００がＳＬＡクライアントのユーザーに請求明細書ファイルの受領を検証するようプロンプトする。ステップ２１４８においては、ＳＬＡクライアントのユーザーが請求明細書ファイルを検証する。
【０１９８】
ステップ２１５０においては、ＳＬＡクライアントが契約諸条件に基づいてプライマリＳＬＡプロバイダに支払いを実行する。ステップ２１５２においては、プライマリＳＬＡプロバイダが代金受け取りファイルデータをシステム１００にアップロード、または手動で請求明細書レコードのステータスを「支払い済み」に更新する。ステップ２１５５においては、プライマリＳＬＡプロバイダがセカンダリＳＬＡプロバイダの未決請求明細書レポートを起動する。ステップ２１５８においては、システム１００がユーザーに支払いを認可するようにプロンプトする。ステップ２１６０においては、ユーザーが支払いを認可する。ステップ２１６２においては、セカンダリＳＬＡプロバイダに支払いの認可が通知される。ステップ２１６５においては、プライマリＳＬＡプロバイダが契約諸条件に基づいてセカンダリＳＬＡプロバイダに支払いを実行する。ステップ２１６８においては、プライマリＳＬＡプロバイダが代金支払いファイルデータをシステム１００にアップロード、または手動でセカンダリＳＬＡプロバイダの請求明細書レコードのステータスを「支払い済み」に更新する。ステップ２１７０においては、支払いデータがオンラインで認可されたユーザーに閲覧可能となる。
【０１９９】
図２２は請求−支払い機能をサポートするデータベーススキーマを描いたものである。
【０２００】
図２３は本発明の原理に基づく情報マネジメントおよび意思決定支援機能のマクロレベルの図である。図２３において、システム２３００はマスタデータ処理スループット２３１０、プロキュアメント処理スループット２３２０、ＳＬＡプロビジョニング処理スループット２３３０および経理処理スループット２３４０を入力として受けるＳＬＡプロビジョニングマネジメントアプリケーションデータベース２３５０を含んでいる。
【０２０１】
ＳＬＡプロビジョニングマネジメントアプリケーションデータベース２３５０からの出力には、ＳＬＡクライアントプロビジョン要件プランニング＆戦略的カバレッジアナリティクス出力２３５５、ＳＬＡプロバイダパフォーマンス数的指標＆進行中の意思決定支援要件プロビジョニング出力２３６０、契約上のＳＬＡプロビジョニングアナリティクス出力２３６５、保証＆マテリアルズパフォーマンス分析出力２３７０、そしてＳＬＡプロビジョニング収益性＆経理分析出力２３７５が含まれる。ここで特に出力２３５５を参照すると、ＳＬＡクライアントのＳＬＡサービスプロビジョン要件に対応するためにアウトソーシングモードを使うプライマリＳＬＡプロバイダは、そのプロビジョンサービスネットワークの最初のセットアップが不適切である場合、失敗のリスクを冒すことになる。
【０２０２】
様々なプロセスが出力２３５５に固有の意思決定支援機能を可能にする。それらには：１）コントラクト情報のプロビジョンディテールレコードへの変換；２）ヒューマンリソースプロビジョンスキルプロファイリング；２）プロビジョンディテールレコードへのＳＬＡクライアントロケーションのマッピング；３）セカンダリＳＬＡプロバイダＲＦｘビッドおよびＳＬＡプロビジョンリソースサブミッタル応答の処理；４）ＳＬＡプロビジョンリソースアサイメント；および５）ＳＬＡプロビジョンリソースカレンダ設定／管理；が含まれる。この方法は、コントラクトを結んだＳＬＡプロビジョンカバレッジに着手する前に、ＳＬＡプロビジョンネットワークのギャップまたは非効率性を特定することができる手段をプライマリＳＬＡプロバイダに提供するものである。プライマリＳＬＡプロバイダがアナリティクス用の履歴データを全く持っていない場合、方法は、例えば：１）地理的カバレッジ；２）スキル習熟度カバレッジ；または３）時間フレームカバレッジに基づいて潜在するＳＬＡプロビジョン欠陥を特定するために利用することができる。一方、プライマリＳＬＡプロバイダが分析時にＳＬＡサービスプロビジョン頻度についての既存データを持っていた場合、より詳細な、様々な視点を作ることでプロビジョンギャップの特定範囲を広げることができる。
【０２０３】
リスク特定意思決定支援モードの値は、カバレッジネットワーク設定時にその利用という域を大きく超える。プロビジョンネットワークが設定されると、特定のプロビジョンディテールレコード／ＰＯにアフィリエイトする全ての割り当てられたリソースがブラックアウト状態である場合にプライマリＳＬＡプロバイダへと系統的に通知するアラームモニタを設定することができる。
【０２０４】
次に出力２３６０に移ると、様々なプロセスがＳＬＡプロビジョンのパフォーマンス分析を可能にしている。プロセスには：１）プロビジョンディテールレコードにアフィリエイトするＳＬＡプロビジョン応答時間フレームの指定；２）プロビジョンディテールレコードにアフィリエイトするオンラインＳＬＡクライアントサービスプロビジョンリクエストの処理；３）追跡したプライマリＳＬＡプロバイダサービスプロビジョンリクエストの処理；４）追跡したセカンダリＳＬＡプロバイダサービスプロビジョンディスパッチリクエストの処理；５）追跡したセカンダリＳＬＡプロバイダサービスプロビジョンディスパッチの処理；６）ＳＬＡプロビジョンリソースサービスディスポジションバウチャーの処理；７）セカンダリＳＬＡプロバイダサービスディスポジションバウチャーの処理；８）プライマリＳＬＡプロバイダサービスディスポジションバウチャーの処理；そして９）ＳＬＡクライアントサービスディスポジションバウチャーの処理；が含まれる。これらのプロセスは、ＳＬＡプロビジョンのパフォーマンスを適正に追跡してマネジメントするために必要なディテールを取得する手段を提供する。当業者には明らかなように、サービスプロビジョンライフサイクルという文脈において、ＳＬＡサービスプロビジョニングはＳＬＡクライアントサービスリクエストから始まり、プロビジョンサービスワークの品質に関する評価が下されることで終わる。この文脈で見た場合、ライフサイクルは計測および分析可能な補助機能群へと分割することができる。様々な実施例は以下に関する数量化およびアナリティクスを可能とするものであるが限定するものではない：１）ＳＬＡプロビジョン時間フレーム上の目標に対するプライマリＳＬＡプロバイダの影響；２）ＳＬＡプロビジョン時間フレーム上の目標に対するセカンダリＳＬＡプロバイダの影響；３）ＳＬＡプロビジョン時間フレーム上の目標に対するＳＬＡプロビジョンリソースの影響；４）ＳＬＡプロビジョンサービス上の目標に対するＳＬＡプロビジョンリソースの影響；および５）ＳＬＡクライアントの満足度／不満足度。分析はセカンダリＳＬＡプロバイダのマクロ的パフォーマンス（例えば企業体としての）、またはミクロ的パフォーマンス（例えば個々のプロビジョンリソースのパフォーマンス）について実施することができる。
【０２０５】
次に出力２３６５に移ると、様々なプロセスが契約上のＳＬＡプロビジョニングアナリティクスを可能にする。プロバイダのパフォーマンスに重点を置く出力２３６０とは対照的に、出力２３６５は契約ＳＬＡパフォーマンスを、例えばＳＬＡノンプロビジョンペナルティおよびＳＬＡプロビジョン目標数的指標に目を向けた、逆の視点に重点を置いたものである。ＳＬＡプロビジョンパフォーマンスは、例えば１つの製品および／またはサービスおよび／または企業内ビジネス組織に特定的な複数のＳＬＡクライアント契約について、複数契約ＳＬＡクライアント集合的プロビジョンパフォーマンスまたは集合的ＳＬＡパフォーマンスの視点からなど、様々な側面から見ることができる。
【０２０６】
さらには様々な実施例において、プライマリＳＬＡプロバイダは独自の視点からコントラクトを見ることができる。スキルプロファイリング機能およびデータベース主導型ＳＬＡ応答時間フレームコードのおかげで、具体的に似た製品および／またはサービスのカバレッジを伴うＳＬＡクライアント契約の類似点および相違点を容易に指摘することができるコントラクト比較視野が可能となる。ＳＬＡコントラクトは、ＳＬＡクライアントによって異なる場合が多い。一部の相違は小さく、また一部の相違は大きい可能性がある。様々な実施例は、レビューおよび分析用にこれらの相違点を好適な方法で浮き彫りにする手段を提供するものである。
【０２０７】
特定の地域または、例えばテレコミュニケーションなどの特定産業におけるＳＬＡクライアントとのＳＬＡコントラクトが含むプロビジョン応答時間フレームは、他の適切なＳＬＡ契約の半分である。この大きな差は、例えば特定の販売組織、または繰越のコントラクト条件に関連するものである可能性がある。さらには、様々な実施例はそれら相違の影響に関する直接的な数的指標出力を提供するものである。システムの目的は、プライマリＳＬＡプロバイダにＳＬＡコントラクトプロビジョンを識別するだけではない、必要とされるあらゆる視野を提供することである。
【０２０８】
次に出力ステップ２３７０に目を向けると、契約パラメータ分析と同様の方式で、特定のサービスおよびマテリアル保証パラメータを追跡し、マネジメントすることができる。次にステップ２３７５に移ると、ＳＬＡプロビジョニング収益性＆経理分析出力とは、例えば契約額、セカンダリＳＬＡ額、ＳＬＡプロビジョンペナルティおよびマテリアルコストに関わるものである。アナリティクスは、結果的な経理上のビジネスパフォーマンスを向上することを究極の目的として実現されたものである。
【０２０９】
本発明の実施例は、例えばハードウェア、ソフトウェア（例えばプロセッサにより起動され、コンピュータ可読命令を実行するもの）、またはそれらの組み合わせとして実現可能である。コンピュータ可読命令とは、例えばランダムアクセスメモリ（ＲＡＭ）などのメモリに記憶された、または例えばリードオンリーメモリ（ＲＯＭ）などの記憶媒体からロードされるプログラムコードである。例えばプロセッサは、本発明の原理に基づく一連のステップを実施するように適合したソフトウェアを実行させるように動作可能である。ソフトウェアは、例えばディスクドライブ装置中の磁気ディスクなど、コンピュータ可読媒体上に記憶されるように適合したものとすることができる。コンピュータ可読媒体には、例えばフラッシュメモリカード、ＥＥＰＲＯＭ型メモリ、バブルメモリ記憶装置、またはＲＯＭ記憶装置が含まれる。本発明の原理に基づいて実行するように適合したソフトウェアはさらに、スタティックまたはダイナミック主要メモリ中、またはプロセッサ中のファームウェア（例えばマイクロコントローラ、マイクロプロセッサ、またはマイクロコンピュータの内部メモリ）に全体的または部分的に記憶されたものであってもよい。
【０２１０】
例示した表１〜表９１は以下の通りである。
【０２１１】
【表１】
2009503733.tif 000003
【０２１２】
【表２】
2009503733.tif 000004
【０２１３】
【表３】
2009503733.tif 000005
【０２１４】
【表４】
2009503733.tif 000006
【０２１５】
【表５】
2009503733.tif 000007
【０２１６】
【表６】
2009503733.tif 000008
【０２１７】
【表７】
2009503733.tif 000009
【０２１８】
【表８】
2009503733.tif 000010
【０２１９】
【表９】
2009503733.tif 000011
【０２２０】
【表１０】
2009503733.tif 000012
【０２２１】
【表１１】
2009503733.tif 000013
【０２２２】
【表１２】
2009503733.tif 000014
【０２２３】
【表１３】
2009503733.tif 000015
【０２２４】
【表１４】
2009503733.tif 000016
【０２２５】
【表１５】
2009503733.tif 000017
【０２２６】
【表１６】
2009503733.tif 000018
【０２２７】
【表１７】
2009503733.tif 000019
【０２２８】
【表１８】
2009503733.tif 000020
【０２２９】
【表１９】
2009503733.tif 000021
【０２３０】
【表２０】
2009503733.tif 000022
【０２３１】
【表２１】
2009503733.tif 000023
【０２３２】
【表２２】
2009503733.tif 000024
【０２３３】
【表２３】
2009503733.tif 000025
【０２３４】
【表２４】
2009503733.tif 000026
【０２３５】
【表２５】
2009503733.tif 000027
【０２３６】
【表２６】
2009503733.tif 000028
【０２３７】
【表２７】
2009503733.tif 000029
【０２３８】
【表２８】
2009503733.tif 000030
【０２３９】
【表２９】
2009503733.tif 000031
【０２４０】
【表３０】
2009503733.tif 000032
【０２４１】
【表３１】
2009503733.tif 000033
【０２４２】
【表３２】
2009503733.tif 000034
【０２４３】
【表３３】
2009503733.tif 000035
【０２４４】
【表３４】
2009503733.tif 000036
【０２４５】
【表３５】
2009503733.tif 000037
【０２４６】
【表３６】
2009503733.tif 000038
【０２４７】
【表３７】
2009503733.tif 000039
【０２４８】
【表３８】
2009503733.tif 000040
【０２４９】
【表３９】
2009503733.tif 000041
【０２５０】
【表４０】
2009503733.tif 000042
【０２５１】
【表４１】
2009503733.tif 000043
【０２５２】
【表４２】
2009503733.tif 000044
【０２５３】
【表４３】
2009503733.tif 000045
【０２５４】
【表４４】
2009503733.tif 000046
【０２５５】
【表４５】
2009503733.tif 000047
【０２５６】
【表４６】
2009503733.tif 000048
【０２５７】
【表４７】
2009503733.tif 000049
【０２５８】
【表４８】
2009503733.tif 000050
【０２５９】
【表４９】
2009503733.tif 000051
【０２６０】
【表５０】
2009503733.tif 000052
【０２６１】
【表５１】
2009503733.tif 000053
【０２６２】
【表５２】
2009503733.tif 000054
【０２６３】
【表５３】
2009503733.tif 000055
【０２６４】
【表５４】
2009503733.tif 000056
【０２６５】
【表５５】
2009503733.tif 000057
【０２６６】
【表５６】
2009503733.tif 000058
【０２６７】
【表５７】
2009503733.tif 000059
【０２６８】
【表５８】
2009503733.tif 000060
【０２６９】
【表５９】
2009503733.tif 000061
【０２７０】
【表６０】
2009503733.tif 000062
【０２７１】
【表６１】
2009503733.tif 000063
【０２７２】
【表６２】
2009503733.tif 000064
【０２７３】
【表６３】
2009503733.tif 000065
【０２７４】
【表６４】
2009503733.tif 000066
【０２７５】
【表６５】
2009503733.tif 000067
【０２７６】
【表６６】
2009503733.tif 000068
【０２７７】
【表６７】
2009503733.tif 000069
【０２７８】
【表６８】
2009503733.tif 000070
【０２７９】
【表６９】
2009503733.tif 000071
【０２８０】
【表７０】
2009503733.tif 000072
【０２８１】
【表７１】
2009503733.tif 000073
【０２８２】
【表７２】
2009503733.tif 000074
【０２８３】
【表７３】
2009503733.tif 000075
【０２８４】
【表７４】
2009503733.tif 000076
【０２８５】
【表７５】
2009503733.tif 000077
【０２８６】
【表７６】
2009503733.tif 000078
【０２８７】
【表７７】
2009503733.tif 000079
【０２８８】
【表７８】
2009503733.tif 000080
【０２８９】
【表７９】
2009503733.tif 000081
【０２９０】
【表８０】
2009503733.tif 000082
【０２９１】
【表８１】
2009503733.tif 000083
【０２９２】
【表８２】
2009503733.tif 000084
【０２９３】
【表８３】
2009503733.tif 000085
【０２９４】
【表８４】
2009503733.tif 000086
【０２９５】
【表８５】
2009503733.tif 000087
【０２９６】
【表８６】
2009503733.tif 000088
【０２９７】
【表８７】
2009503733.tif 000089
【０２９８】
【表８８】
2009503733.tif 000090
【０２９９】
【表８９】
2009503733.tif 000091
【０３００】
【表９０】
2009503733.tif 000092
【０３０１】
【表９１】
2009503733.tif 000093
【０３０２】
＜表の簡単な説明＞
（表１）プライマリＳＬＡプロバイダのＩＤおよび一般ビジネスデータを収容するストレージテーブル例を示す。
【０３０３】
（表２）ＳＬＡプライマリプロバイダに関わるユーザーのＩＤおよび一般情報を収容するストレージテーブル例を示す。
【０３０４】
（表３）様々なＳＬＡプロビジョンタイプ（SLA Provision Types）のＩＤを収容するストレージテーブル例を示す。
【０３０５】
（表４）様々なＳＬＡプロビジョンレーバータイプ（SLA Provision Labor Types）のＩＤを収容するストレージテーブル例を示す。
【０３０６】
（表５）様々なＳＬＡプロビジョン応答時間（Response Time）計測値のＩＤを収容するストレージテーブル例を示す。
【０３０７】
（表６）ＳＬＡマテリアルのＩＤおよびプロパティを収容するストレージテーブル例を示す。
【０３０８】
（表７）ＳＬＡマテリアルおよびロケーションのマッピング関係を収容するストレージテーブル例を示す。
【０３０９】
（表８）物理的サイトロケーションのＩＤおよびプロパティを収容するストレージテーブル例を示す。
【０３１０】
（表９）表８に格納される物理的サイトロケーションタイプのＩＤを収容するストレージテーブル例を示す。
【０３１１】
（表１０〜表１３）システム内に格納された地理的ロケーションのＩＤおよび関係を収容する階層的／リレーショナル的ストレージテーブル例を示す。
【０３１２】
（表１４〜表２２）システム内のレーバースキル／属性プロファイリングデータを収容する階層的／リレーショナル的ストレージテーブル例を示す。
【０３１３】
（表２３〜表２５）プライマリＳＬＡプロバイダの作成したＳＬＡプロビジョンレーバープロフィールおよび関連するスキル／属性のＩＤを収容するストレージテーブル例を示す。
【０３１４】
（表２６）ＳＬＡプロビジョンレーバープロフィールおよびＳＬＡマテリアルマスタレコード間のマッピング関係および習熟度要件を収容するストレージテーブル例を示す。
【０３１５】
（表２７）ＳＬＡクライアントに関わる一般ビジネス情報を収容するストレージテーブル例を示す。
【０３１６】
（表２８）ＳＬＡクライアントコントラクトに関わる関連詳細を収容するストレージテーブル例を示す。
【０３１７】
（表２９）ＳＬＡクライアントのユーザーに関わる関連詳細を収容するストレージテーブル例を示す。
【０３１８】
（表３０）ＳＬＡクライアントサービスプロビジョンレコードに関する関連詳細を収容するストレージテーブル例を示す。
【０３１９】
（表３１）ＳＬＡクライアントサービスプロビジョンマテリアルレコードに関する関連ディテールおよび表３０中に格納された関連するサービスプロビジョンレコードとのマッピング関係を収容するストレージテーブル例を示す。
【０３２０】
（表３２）ＳＬＡクライアントサービスプロビジョンレコードおよびシステム格納されたＳＬＡプロビジョンレーバープロフィール間のマッピング関係を収容するストレージテーブル例を示す。
【０３２１】
（表３３）ＳＬＡプロビジョンディテールレコードおよび物理ロケーション間のマッピング関係を収容するストレージテーブル例を示す。
【０３２２】
（表３４〜表３６）プライマリＳＬＡプロバイダおよびＳＬＡクライアント間のパーチャスオーダーに関するディテールを収容するストレージテーブル例を示す。
【０３２３】
（表３７，表３８）プライマリＳＬＡプロバイダＲＦｘビッドに関するディテールを収容するストレージテーブル例を示す。
【０３２４】
（表３９）ＳＬＡクライアントプロビジョンディテールレコードおよびプライマリＳＬＡプロバイダＲＦｘビッド間のマッピング関係を収容するストレージテーブル例を示す。
【０３２５】
（表４０）セカンダリＳＬＡプロバイダに適用可能なＩＤおよび一般ビジネス情報を収容するストレージテーブル例を示す。
【０３２６】
（表４１）セカンダリＳＬＡプロバイダのユーザーに適用可能なＩＤおよび一般ビジネス情報を収容するストレージテーブル例を示す
（表４２〜表４６）セカンダリＳＬＡプロバイダの提供するＳＬＡレーバープロビジョンプロフィールビジネスファミリおよびこれに適用可能な地理的カバレッジ領域のＩＤを収容するストレージテーブル例を示す。
【０３２７】
（表４７）セカンダリＳＬＡプロバイダに対して掲示するＲＦｘビッドに関わるディテールを収容するストレージテーブル例を示す。
【０３２８】
（表４８，表４９）セカンダリＳＬＡプロバイダＲＦｘビッド応答に適用可能なディテールを収容するストレージテーブル例を示す。
【０３２９】
（表５０）ＲＦｘビッド応答プロセスの過程においてセカンダリＳＬＡプロバイダが提出するヒューマンリソースプロビジョン候補に関わるディテールを収容するストレージテーブル例を示す。
【０３３０】
（表５１，表５２）プライマリＳＬＡプロバイダおよびセカンダリＳＬＡプロバイダ間のパーチャスオーダーに適用可能な詳細を収容するストレージテーブル例を示す。
【０３３１】
（表５３）サービスプロビジョンレーバーリソースに適用可能なＩＤおよびディテールを収容するストレージテーブル例を示す。
【０３３２】
（表５４）個別のサービスプロビジョンレーバーリソースに適用可能な仕事（Assignment）のディテールを収容するストレージテーブル例を示す。
【０３３３】
（表５５〜表５７）サービスプロビジョンレーバーリソースのカレンダ／時間アベラビリティに関わる情報を収容するストレージテーブル例を示す。
【０３３４】
（表５８〜表６３）カレンダシステムが使用する基本ソースデータを収容するストレージテーブル例を示す。
【０３３５】
（表６４〜表６６）ＳＬＡプロビジョンサービスリクエストに適用可能なＩＤおよび詳細を収容するストレージテーブル例を示す。
【０３３６】
（表６７）ＳＬＡプロビジョンサービスリクエストと共に使用することができるステータスコードを収容するストレージテーブル例を示す。
【０３３７】
（表６８）プロビジョンディスパッチリクエストに関わるＩＤおよび基本ディテールを収容するマスターストレージテーブル例を示す。
【０３３８】
（表６９）ＳＬＡプロビジョンサービスリクエストと共にＳＬＡリソースアベラビリティに関わるディテールを収容するストレージテーブル例を示す。
【０３３９】
（表７０）プロセスの過程でプライマリＳＬＡプロバイダのユーザーが利用することのできるＳＬＡリソース優先順位オプションを収容するストレージテーブル例を示しており、その値は表６８に格納される。
【０３４０】
（表７１）ＳＬＡプロビジョンサービスリクエストのライフサイクル中に、これに適用可能な潜在的ステータスコードを収容するストレージテーブル例を示すものであって、その値は表６８中に格納される。
【０３４１】
（表７２）プロビジョンディスパッチリクエストに関する特定のディテールを収容するストレージテーブル例を示す。
【０３４２】
（表７３）ＳＬＡプロビジョンバウチャーに関するＩＤおよび基本ディテールを収容するマスターストレージテーブル例を示す。
【０３４３】
（表７４）ＳＬＡプロビジョンバウチャーに適用可能なサービスディテールを収容するストレージテーブル例を示す。
【０３４４】
（表７５）ＳＬＡプロビジョンバウチャーに適用可能なマテリアルディテールを収容するストレージテーブル例を示す。
【０３４５】
（表７６）ＳＬＡプロビジョンバウチャー項目に適用可能な潜在的プロビジョン結果（Provision Outcome）の処遇決定タイプを収容するストレージテーブル例を示す。
【０３４６】
（表７７）ＳＬＡプロビジョンバウチャーのライフサイクル中に、これに適用可能な潜在的ステータスコードを収容するストレージテーブル例を示す。
【０３４７】
（表７８）ＳＬＡプロビジョンバウチャー項目に適用可能な潜在的品質パフォーマンス処遇決定コードを収容するストレージテーブル例を示す。
【０３４８】
（表７９）ＳＬＡプロビジョンバウチャー項目に適用可能な潜在的管理パフォーマンス処遇決定コードを収容するストレージテーブル例を示す。
【０３４９】
（表８０）ＳＬＡプロビジョンバウチャーのレビュー中にＳＬＡクライアントが利用するプライマリデクライン（一次拒絶）コードのＩＤを収容するストレージテーブル例を示す。
【０３５０】
（表８１）拒絶されたＳＬＡプロビジョンバウチャーに関するディテールを収容するストレージテーブル例を示す。
【０３５１】
（表８２）承認されたＳＬＡバウチャー抽出バッチファイルに関するＩＤおよび基本情報を収容するストレージテーブル例を示す。
【０３５２】
（表８３）承認されたＳＬＡバウチャー抽出バッチファイルに関係する特定のレコードに関わるＩＤおよび基本情報を収容するストレージテーブル例を示す。
【０３５３】
（表８４）ＳＬＡクライアント請求明細書−請求書ファイルに関するＩＤおよび基本情報を収容するストレージテーブル例を示す。
【０３５４】
（表８５）ＳＬＡクライアント請求明細書−請求書ファイルに関係する特定のレコードに関わるＩＤおよび情報を収容するストレージテーブル例を示す。
【０３５５】
（表８６）セカンダリＳＬＡプロバイダ請求明細書−請求書ファイルに関するＩＤおよび基本情報を収容するストレージテーブル例を示す。
【０３５６】
（表８７）セカンダリＳＬＡプロバイダ請求明細書−請求書ファイルに関係する特定のレコードに関わるＩＤおよび情報を収容するストレージテーブル例を示す。
【０３５７】
（表８８）様々なＳＬＡクライアントプロビジョンカバレッジ期間のＩＤを収容するストレージテーブル例を示す。
【０３５８】
（表８９）ＳＬＡクライアントにサービスを提供する過程でレーバーリソースが課すことができる様々なＳＬＡプロビジョン費用タイプのＩＤを収容するストレージテーブル例を示す。
【０３５９】
（表９０）特定のＳＬＡクライアントプロビジョンカバレッジ期間に適用可能なセカンダリＳＬＡプロバイダビッド応答請求料率の値を収容するストレージテーブル例を示す。
【０３６０】
（表９１）特定のＳＬＡプロビジョン費用タイプに適用可能なセカンダリＳＬＡプロバイダビッド応答請求料率の値を収容するストレージテーブル例を示す。
【０３６１】
上述した詳細な説明は、本発明の実施例のものである。本発明の範囲は、この説明により必ずしも限定されるものではない。本発明の範囲は、本願請求項およびその同等物によってのみ定義されるものである。
【図面の簡単な説明】
【０３６２】
【図１】物理的な通信／データネットワークのハイレベルブロック図である。
【図２Ａ】アウトソーシングしたサービスレベルアグリーメント（ＳＬＡ）および非ＳＬＡデリバラブルをマネジメントするシステムおよび方法のハイレベルフロー図である。
【図２Ｂ】アウトソーシングしたサービスレベルアグリーメント（ＳＬＡ）および非ＳＬＡデリバラブルをマネジメントするシステムおよび方法のハイレベルフロー図である。
【図３】プライマリＳＬＡプロバイダのユーザー用ウェブホームページの説明図である。
【図４】ＳＬＡクライアントマスタデータ機能のハイレベル機能性を説明するフロー図である。
【図５】ＳＬＡプロビジョンレーバープロフィールの作成およびライブラリへの格納のプロセスを説明するフロー図である。
【図６】ＳＬＡプロビジョンマテリアルの作成およびライブラリへの格納のプロセスを説明するフロー図である。
【図７】ＳＬＡプロビジョンレコードに関わる作成および格納プロセスを説明するフロー図である。
【図８】ＳＬＡクライアントパーチャスオーダーに関わる作成および格納プロセスを説明するフロー図である。
【図９】マスタデータ機能をサポートするデータベーススキーマを描いたものである。
【図１０】セカンダリＳＬＡプロバイダシステムのイネーブルメントプロセスを説明するフロー図である。
【図１１】１つ以上のセカンダリＳＬＡプロバイダパーチャスオーダーに関連付けられていないＳＬＡプロビジョンディテールレコードの詳細を示すサンプル出力である。
【図１２Ａ】アウトソースされたセカンダリＳＬＡサービスプロビジョンのプロキュアメントに適用可能なハイレベルプロセスを説明するフロー図である。
【図１２Ｂ】アウトソースされたセカンダリＳＬＡサービスプロビジョンのプロキュアメントに適用可能なハイレベルプロセスを説明するフロー図である。
【図１３】プロキュアメント機能をサポートするデータベーススキーマを描いたものである。
【図１４Ａ】ヒューマンリソースサービスプロビジョンマネジメントに適用可能なハイレベルプロセスを説明するフロー図である。
【図１４Ｂ】ヒューマンリソースサービスプロビジョンマネジメントに適用可能なハイレベルプロセスを説明するフロー図である。
【図１５】ヒューマンリソースカレンダ設定プロセスを説明するフロー図である。
【図１６】ヒューマンリソースサービスプロビジョンマネジメント機能をサポートするデータベーススキーマを描いたものである。
【図１７Ａ】ロジスティック的プロビジョンおよび管理機能に適用可能なプロセスフローを説明するフロー図である。
【図１７Ｂ】図１７Ａのプロセスフローに関連して使うための、アクティブなコントロール群を埋め込んだインターフェースを描いたものである。
【図１７Ｃ】図１７Ａのプロセスフローに関連して使うための、アクティブなコントロール群を埋め込んだインターフェースを描いたものである。
【図１８】ロジスティクス的プロビジョンおよび管理機能をサポートするデータベーススキーマを描いたものである。
【図１９Ａ】ＳＬＡプロビジョンワークアクナリッジメントおよび品質保証に適用可能なプロセスを説明する図である。
【図１９Ｂ】ＳＬＡプロビジョンワークアクナリッジメントおよび品質保証に適用可能なプロセスを説明する図である。
【図２０】ＳＬＡプロビジョンワークアクナリッジメントおよび品質保証をサポートするデータベーススキーマを描いたものである。
【図２１】請求−支払い機能に適用可能なプロセスを説明するフロー図である。
【図２２】請求−支払い機能をサポートするデータベーススキーマを描いたものである。
【図２３】情報マネジメントおよび意思決定支援機能のマクロレベルの図である。
【図１】
2009503733.tif 000094
【図２Ａ】
2009503733.tif 000095
【図２Ｂ】
2009503733.tif 000096
【図３】
2009503733.tif 000097
【図４】
2009503733.tif 000098
【図５】
2009503733.tif 000099
【図６】
2009503733.tif 000100
【図７】
2009503733.tif 000101
【図８】
2009503733.tif 000102
【図９】
2009503733.tif 000103
【図１０】
2009503733.tif 000104
【図１１】
2009503733.tif 000105
【図１２Ａ】
2009503733.tif 000106
【図１２Ｂ】
2009503733.tif 000107
【図１３】
2009503733.tif 000108
【図１４Ａ】
2009503733.tif 000109
【図１４Ｂ】
2009503733.tif 000110
【図１５】
2009503733.tif 000111
【図１６】
2009503733.tif 000112
【図１７Ａ】
2009503733.tif 000113
【図１７Ｂ】
2009503733.tif 000114
【図１７Ｃ】
2009503733.tif 000115
【図１８】
2009503733.tif 000116
【図１９Ａ】
2009503733.tif 000117
【図１９Ｂ】
2009503733.tif 000118
【図２０】
2009503733.tif 000119
【図２１】
2009503733.tif 000120
【図２２】
2009503733.tif 000121
【図２３】
2009503733.tif 000122
【国際調査報告】
2009503733.tif 000123