Japan [変更]

ホーム

製品

サービス & ソリューション

サポート & ダウンロード

マイアカウント

developerWorks Japan > Autonomic computing >

カタログ・ベースのサービス要求管理

IBM Systems Journal: IBM Service Management: Volume 46, Number 3, 2007

グローバルな規模で競争力のあるサービス・デリバリーを管理するために、IT (情報技術) サービス・プロバイダーは、サービス・デリバリー・リソース、特に、優秀なサービス・デリバリー・チームを効果的に活用する必要があります。サービス要求は、クライアントの IT インフラストラクチャーの管理の中で大きな、そして重要な部分を占めています。しかし、現状では多くの場合、IT サービス要求の履行がアカウント単位に管理されています。サービス・デリバリー・チームは、アカウント固有のサービス要求管理環境を使用して、アカウント固有のプロセスに従ってサービス要求を履行しています。これでは、複数のアカウントに対してさまざまなデリバリー・チームのスキルを活用することができません。サービス・デリバリー管理プラットフォーム (SDMP) は、複数のデリバリー・チームが実行することができ、複数のクライアントが加入するサービス・コンポジションに組み立てることができる再利用可能なサービス・コンポーネントを使用します。SDMP カタログは、サービス・コンポーネント、コンポジション、プロバイダー、および加入を管理し、特定のお客様のサービス要求を満たすためにランタイム環境で使用される情報リポジトリーです。本稿では、サービス・デリバリーを管理するためのカタログ・ベースのアーキテクチャーについて説明し、それを使用することによって、グローバル・サービス・デリバリー組織に、生産性の大幅な向上を実現するためのプラットフォームが提供されることを示します。

はじめに

IT (情報技術) サービスの提供ビジネスは、グローバルなゆえに競争が激しく、従来の IT サービス・プロバイダーから、インドや中国などの新興経済圏からの新規参入者にポートフォリオを拡大している電気通信企業まで、さまざまな市場参加者で溢れています。グローバルな規模で IT サービス・デリバリーの競争力を維持し、複数のアカウントを管理するために、IT サービス・プロバイダーは、IT インフラストラクチャーやベスト・プラクティスはもちろん、優秀なサービス・デリバリー・チームを効果的に活用して規模の経済を実現する必要があります。

サービス要求は、クライアント組織の従業員から出されることが多く、クライアントの IT インフラストラクチャー管理の中で大きな、そして重要な部分を占めています。管理作業の半分以上になることも多いものです。そのため、それらの要求をタイムリーかつ効果的に処理することによって、サービス・プロバイダーとクライアントの両方に多大な価値が提供されます。通常、新しいサービスのプロビジョニングや、パッチや新しいアプリケーションのインストールなどのサービスは、自動と手動の両方で遂行する必要があります。本稿では、この作業の効果的な処理を中心に説明します。

現在は、サービス要求のほとんどが顧客のアカウントごとに別々の方法で管理されています。サービス・デリバリー・チームは、アカウント固有のサービス管理環境を使用してアカウント固有のプロセスに従ってサービス要求を履行しています。この「サイロ」アプローチは、さまざまな顧客から要求されるデリバリー・プロセスや手順の違いによって必然的に生じたものです。これまで、IT デリバリー・チームまたは複数のサイロに関する彼らの作業を整理して最適化できるテクノロジー・プラットフォームは存在しませんでした。この制約は、顧客の多様性だけが原因ではなく、IT のデリバリー作業が巨大な融通の効かない 1 つのプロセスに構造化され、作業の 1 部を変更するにもその前後のプロセスまたはプロセス全体を設計し直さなければならないために克服することができませんでした。

この制約がある限り、デリバリー・チームのスキルの活用や個別のアカウントを超えたベスト・プラクティスの実施はほとんど不可能です。逆に言えば、すべてのアカウントとサービス・デリバリー・チームに関するプロセスの単純な標準化におけるどんな試みも、顧客のビジネスにとって重要な固有の要件を解決することはできません。また、IBM Integrated Technology Delivery (ITD) などの巨大なサービス組織に属しているサービス・デリバリー・チームは、組織を整理して作業をやりやすくするためのさまざまな方法と、作業内容を管理するためのさまざまなテクノロジーを使用しています。大手 IT サービス・プロバイダー向けのサービス・デリバリー管理プラットフォームは、顧客の特定の要件と個々のサービス・デリバリー・チームの効率性のどちらも犠牲にすることなく、デリバリー・プロセスの標準化の恩恵を享受できる必要があります。

SDMP は、アトミック・サービスと呼ばれる再利用可能なサービスの構成要素をコンポーネントとして提供することによって、この課題を解決します。たとえば、このようなサービスの 1 つが、オペレーティング・システム (OS) イメージのインストールです。アトミック・サービスには、クライアントからのサービス要求にとって意味のあるサービス・コンポジションに組み立てることが可能な標準の入力と出力 (OS のバージョンなど) があります。サービス・コンポジションは、複数のクライアント間で共有することができます。たとえば、新しいデータベース・サーバーのプロビジョニングに関するコンポジションには、OS インストール・アトミック・サービスをコンポーネントとして含めることができます。最終的に、サービス・コンポジションは、アトミック・サービスの再利用可能性を損なうことなく、アカウントごとにカスタマイズすることができます。アトミック・サービスは内部または外部のサービス・プロバイダーが提供することができる上、複数のサービス・プロバイダーが同じアトミック・サービスを提供することができます。サービス・プロバイダーの多くが、IT サービス管理 (ITSM) プラットフォームを利用してサービスを提供しています。SDMP は、Tivoli ITSM プラットフォームの中核となるプロセス・マネージャー・コンポーネントとして統合することができます。

SDMP カタログは、さまざまなタイプのアトミック・サービス、サービス・コンポジション、アカウント加入、および特定のカスタマイズを管理する中核の情報リポジトリーです。また、どのデリバリー・チームまたはサード・パーティー・ベンダーがアトミック・サービスを実行できるかも指定されます。さらに、SDMP カタログは、クライアント組織の従業員がサービス要求時に使用する顧客サービス・カタログの内容を作成するための基礎にもなります。クライアントの顧客サービス・カタログ・システムは、サービス要求を SDMP に提出することも、建物の保守管理やケータリングなどのより単純なサービス用のサービス・デリバリー・システムに提出することもできます。

SDMP カタログの内容は、標準の ITSM プラクティスに準拠した一連の表示ツールを使用して管理することができます。サービス・デリバリー・カタログのエントリーは、デリバリー・チームが保持しているアカウント・サービス・カタログからインポートすることができます。サービス要求ランタイム環境がこのリポジトリーにアクセスして、特定の顧客サービス要求を履行および管理します。

サービス・デリバリーを管理するための SDMP カタログ・ベースのアーキテクチャーによって、グローバルなサービス・デリバリー組織に、クライアント固有の要件を満たしながら、生産性を大幅に向上させるためのプラットフォームが提供されます。カタログ駆動型のサービス・デリバリー管理は、今日の地理的に分散した環境、外部委託された環境、または高度にマトリックス化された環境での IT サービスのデリバリー管理に対する新しいアプローチです。このアプローチの中心は、クライアント企業の要件に合うように調整されているが、標準的な一連のデリバリー・ベスト・プラクティスに基づいているサービス定義のカタログです。これによって、実績のある効果的なデリバリー・メカニズムとの整合を保証しながら、ローカルな要件を満たすクライアントごとのカスタマイズが可能になります。

図 1. サービス・デリバリー管理アーキテクチャー

拡大図

本稿は次のように編成されています。次のセクションでは、サービス要求処理の主な課題と要件について概説します。その次に、サービス・コンポーネントとサービス・コンポジションの作成モデルを紹介します。続く 3 つのセクションでは、サービス・カタログのデータ構造の編成とカタログ・コンポーネントのライフ・サイクルについて詳述します。その次に、ビジネス目標の調整のためのカタログの使用方法、カタログ実装のプロセスと課題、および関連作業について説明します。最後に、我々が実現した成果と今後の計画について説明します。

上に戻る

大規模な IT サービス・デリバリー環境におけるサービス要求の管理

このセクションでは、サービス要求管理アーキテクチャーを紹介し、大規模なサービス要求インフラストラクチャーの要件とその構築に関する課題について説明します。

サービス要求管理アーキテクチャー

IT サービス・プロバイダーは、図 1 に示されているように、複数のコンポーネントで構成されたサービス・デリバリー管理環境でサービス要求を管理しています。

デリバリー管理環境の中心に、サービス要求処理コンポーネントがあります。このコンポーネントは、クライアントからサービス要求を受け取って、それを管理的に処理し (要求資格のチェック、要求価格の設定、請求書作成への連絡など)、サービス要求タスクをサービス提供チームまたはそのサービスを提供する外部のサービス・プロバイダーに委託するサービス計画を策定します。SDMP サービス要求処理コンポーネントの詳細については、参考文献1 を参照してください。サービス計画は、サービス要求の履行に必要なタスクと、それらのタスクに関連した制御とデータ・フローを定義するワークフロー仕様です。このサービス計画に基づいて、タスクごとにサービス・プロバイダーを選定することができます。

ITSM コンポーネントは、クライアントに提供される IT インフラストラクチャーに影響を与えるサービス運用を管理するために使用されます。通常はサービス要求の履行に応じて IT インフラストラクチャーの一部が変更されるため、サービス要求の多くは変更管理に関連します。構成管理は、IT サービス・インフラストラクチャーの構成を維持管理します。どちらのコンポーネントも、IT インフラストラクチャーの状態と変化を記録する IBM Tivoli Change and Configuration Management Database (CCMDB) をベースにしています。

サービス・デリバリー・カタログは、サービス計画、クライアント加入、およびサービス・プロバイダーとその機能をサービス要求処理コンポーネントで使用可能にするメタデータ・リポジトリーです。サービス要求処理コンポーネントがサービス要求の運用管理 (サービス・プロバイダーの決定やサービス計画のスケジューリングなど) を提供するのに対して、サービス・デリバリー・カタログは戦術的かつ戦略的なサービス・デリバリー管理手段です。サービス・デリバリー・カタログは、サービス要求管理のさまざまな側面を解決する、サービス管理、サービス・プロバイダー管理、およびアカウント管理の 3 つのコンポーネントによって管理されます。

サービス管理は、アトミック・サービス定義とサービス・コンポジションの設定を処理します。この機能は、サービス組織から提供されるサービス範囲の分析および定義と、それらを顧客に価値を提供するサービスに反映させる方法を支援します。サービス・プロバイダー管理は、以下のような問題を解決しながら、リソース・キャパシティー管理を処理します。どのアトミック・サービスを社内のデリバリー・チームが提供し、どのアトミック・サービスを外部のサービス・プロバイダーに委託するか?、サービスのタイプごとにどのチームを投入し、それぞれのサービスにどの程度のサービス・キャパシティーが必要か?、加えて、サービス・プロバイダーの所在地、タイム・ゾーンへの対応、セキュリティ適合性などに関連した特定の顧客要件を考慮する必要があります。アカウント管理では、クライアントごとにどのサービスが利用できるかを定義します。加えて、特定のタスクを処理するサービス・プロバイダーの所在地に関する要望などのサービスの提供方法に関するアカウント固有の要件を収集します。また、サービスのターンアラウンド・タイムなどの主要業績評価指標 (KPI) に関連した特定のサービス・レベル要件もアカウントごとに収集されます。

IT サービス・プロバイダー組織は、顧客サービス・レベル目標を評価するためだけでなく、競合他社との差別化を図るサービス・デリバリー目標に集中するためにも KPI を利用することができます。サービス・デリバリー KPI の例として、ターンアラウンド・タイムの短縮、デリバリー・チームの処理能力の強化、SLA (サービスレベル・アグリーメント) 違反の削減、QoS (サービス品質) の向上などが挙げられます。ベンチマークに対して実際のパフォーマンスを評価するためには、履歴レポートを作成するだけでは不十分です。ベンチマークを達成または上回るためには、より粒度の細かいレベル (つまり、アトミック・サービスまたはタスクのレベル) でデリバリー・チームのパフォーマンスを積極的に管理して、段階ごとに是正処置を実施する必要があります。

アトミック・サービス・レベルでサービス・デリバリー・チームを管理するためには、主に要求側の視点に立ったサービス全体の遂行を示すベンチマークのほかに、そのレベルの内部的なベンチマークを定義する必要があります。たとえば、デリバリー・チームは、新しいデータベース・サーバーの構築要求を遂行するためのターンアラウンド・タイムだけでなく、サーバーの構築、ストレージの割り当て、データベース・ソフトウェアのインストールと構成、サーバーのネットワークへの接続、およびサーバーのテストに必要なターンアラウンド・タイムも定義する必要があります。このレベルで測定することによって、デリバリー・チームは、ボトルネック領域、マーケティング機会、自動化機会などを識別することができます。

大規模なサービス要求インフラストラクチャーの課題と要件

IBM ITD などの IT サービス・プロバイダーは、社内のエンタープライズ IT 組織が直面している課題とは全く異なるさまざまな課題に対処する必要があります。これらの課題の一部を以下に示します。

• エンタープライズ・ソフトウェアの制約 - アウトソーシングに適合するように設計された IT サービス・デリバリーの管理用ソフトウェア製品が、市場にほとんど流通していません。最も無視されがちな設計原則の 1 つがマルチテナンシーです。システムは、1 つの会社向けのサービスを管理するために設計されます。サービス・プロバイダーの組織構造をサービスを受ける側の組織構造から分離するという概念がありません。そのため、IT サービス・プロバイダーの多くが、IT サービスのデリバリーを管理するために、顧客ごとに別々の IT システムのインスタンスを構築しなければなりません。これは、インフラストラクチャー・コストを増大させるだけでなく、サービスを遂行する要員の問題も引き起こします。彼らは、このようなシステムの複数のインスタンスにログインして、実行すべき作業を決定する必要があります。さらに、これらのシステムは、やがて、ソフトウェアの複数のリリースを使用しなければならなくなります。もう一つの重要な設計上の欠陥は、SLA を算出する際に複数の顧客のビジネス・カレンダーに対応できないことに起因します。

• 顧客固有のプロセス - IT サービスが外部委託された場合は、ほとんどのサービス・プロバイダーが顧客からレガシー・プロセスを引き継ぎます。このようなプロセスを合理化または標準化するための移行時間や予算はほとんどありません。その結果、IT サービス・プロバイダーは、大量のプロセスを処理することになります。最大の課題の 1 つは、プロセスの再利用可能性を促進すると同時に、顧客によって異なる部分に対応できるツールを見つけることです。

• 顧客固有のシステムの使用 - サービス・プロバイダーはプロセスとともにレガシー・ツールも引き継ぎます。多くの場合、顧客の従業員が、要求の提出、変更の承認、および作業の実施に関与します。機能停止を最小限に抑えるために、顧客は (アウトソーシング契約の中で) 既存のツールの使用を命じます。これによって、サービス・プロバイダーが ITSM ツールを標準化するのも制限されます。さらに、顧客ツールの統合に要する時間とコストがかなりになるために、サービス・プロバイダーは、顧客に命じられたツールを使ってサービスを提供する羽目になります。

• アカウント専任の遂行チーム - 上記問題によって、サービス・プロバイダーが従業員に複数のプロセスとツールを教育するためのコストが増大するだけでなく、アカウント間でのリソースの共有が制限され、デリバリー・チームの柔軟性が失われます。また、このような特性によって、規模の経済を実現するために使用可能なリソースやベスト・プラクティスの共有が阻害されます。すべてのアカウントにわたるベンチマーク実施が困難 - ツールの違いやアカウントごとに異なるプロセスのために、すべてのアカウントのデリバリー効率に関する統計情報の収集がほとんど不可能です。さまざまなシステムが基本統計値を収集するための機能を提供しており、複数の顧客に対して同様のビジネス価値を提供するプロセス (パッチのインストールやサーバーのプロビジョニングなど) で手順が異なるために、標準化されたパフォーマンス・データの収集が困難になっています。その結果、複数のチームのパフォーマンスの比較が困難になる可能性があります。

このようなサービス・プロバイダーの課題を踏まえた上で、我々は、サービス要求管理システムが上述した問題を克服するために解決しなければならない一連の要件を抽出しました。これは、特に、サービス要求に対する戦術的管理手法であるサービス・デリバリー・カタログに該当します。

サービス・デリバリー・チームとアカウント間の直接依存性を取り除く必要があります。そのためには、「はじめに」で説明したように、サービス・チームがアトミック・サービスとしてアカウントに依存しない方法で成し得る貢献度を定義可能なサービス・プロセス・モデルが必要です。サービス・プロセス定義は、アカウント間で共有可能にする必要があります。

アカウント固有のサービス要件は、サービス・チームへの影響を最小限に抑えながら、解決する必要があります。理想は同じプロセスを使ってすべてのクライアントに対処することですが、顧客の内部システムへの接続やサービス・プロセスの進捗の他のサービス・プロバイダーへの通知などのベスト・プラクティス・プロセスを変更しなければならない正当な顧客要件がよくあります。サービス・デリバリー・カタログは、このような特定の要件を収集できる必要があります。また、ランタイム・システムは、既存のサービス・チーム・プロセスへの影響を最小限に抑えながら、変更されたプロセスを実行できる必要があります。さらに、複数の顧客が、複数のサービス・レベルでサービスを受けることができる必要があります。

サービス・プロバイダー、社内のサービス・デリバリー・チーム、および外部のサービス・プロバイダーは、独自の内部プロセスを使用して、他のサービス・プロバイダーとは無関係に、サービス・プロセスの担当部分を実行できる必要があります。そのためには、サービス・デリバリー・チームへのインターフェースを正確に定義する必要があります。この独立性に基づいて、サービス・プロバイダーは、サービス全体に影響を与えることなく、内部プロセスを改善することができます。さらに、すべてのサービス・プロバイダー・チームのソフトウェアとツールのレベルが同じとは限らないため、大規模なグローバル・デリバリー組織の場合は複雑な投入作業が必要になります。最後に、データ・センターによってスキル・レベルや労働コストが異なることがあるため、デリバリー・スタッフをより良くサポートするには、さまざまなレベルの自動化や複数のツールが必要になります。サービス・デリバリー・カタログのすべての内容は、適切なガバナンス・プロセスに従う必要があります。これは、その内容が、デリバリー組織のサービス製品戦略、デリバリー・チームのキャパシティー管理、およびクライアントに対する契約上の義務の中核を成すものだからです。

図 2. 重複要素を含むサービス・ワークフロー

拡大図

本稿では、サービス・デリバリー・カタログの観点からこれらの要件を解決します。

上に戻る

大規模なサービス・デリバリーのためのサービス・コンポジション・モデル

前のセクションでは、デリバリー・チームが特定のアカウントのプロセス構造を越えて機能できるようにするためのサービス・デリバリー・コンポーネントの作成の必要性について説明しました。このセクションでは、図 2 に示されているように、新しい従業員のユーザー ID を作成するシナリオを使ってこの問題を解説します。作成する ID のタイプと必要なアクセス承認は、顧客によってかなり異なる可能性があります。プロセスと手順がワークフロー・システムに反映された結果、新しい従業員の異なる複数のワークフローが生じます。単一のワークフローですべての手順を定義するのではなく、フローを DB2*、AIX*、NT などのユーザー ID のタイプごとに 1 つずつの複数のフロー (マイクロフロー) に分解することができます。ここでは、アトミック・サービスという用語を、マイクロフローを通して提供されるサービスが単一の論理チームによって所有されたり、「ブラック・ボックス」として機能したりすることも可能なように分解されるサービスを説明するために使用しています。マイクロフローがアトミック・サービスの基準を満たすには、サービスの実行に必要な入力、成果物、および応答が明確に定義されている必要があります。ユーザー ID ごとに異なるアトミック・サービスのセットは、サービス・デリバリー・チームが新しい顧客向けの新規雇入れ用ワークフローを構成するためのビルディング・ブロックとして機能することができます。コンポジションは、どのアトミック・サービスがどの順序で完全なサービスの遂行を支援するかに関する仕様に過ぎません。このようなアトミック・サービスのコンポジションに対しては、複合サービスという用語を使用します。アトミック・サービスと同様に、複合サービスには、サービスの実行に必要な入力メッセージ、成果物、および応答メッセージが明確に定義されている必要があります。

この方法は、デリバリー・チームによって実行されるすべてのサービスに適用することによって、デリバリー・プロセスを再利用可能にすることができます。たとえば、スペース割り当てサービスは、ファイル・システムの作成、データベースの構築、またはアプリケーションのインストールに再利用することができます。このような再利用可能なアトミック・サービスのカタログが作成できれば、新しい IT サービスの構築または既存の IT サービスのカスタマイズがかなり容易になります。より高度なサービスを構成する場合は、特定のアクティビティーの完了にどのアトミック・サービスを使用し、その順序はどうするかを指定するための計画を立てることもできます。この計画は、標準化したり、顧客固有にしたり、契約固有にしたり、業界固有にすることもできます。たとえば、標準の「ビルド DB2」サブシステム・コンポジションは、ファイル・システムを作成して、DB2 イメージをプッシュし、DB2 インスタンスを作成して、DB2 データベースを作成するアトミック・サービスを利用することができます。カスタマイズされた「ビルド DB2 」サブシステム・コンポジションは、SAN 接続ストレージが要求された場合に、追加のアトミック・サービスを利用して、SAN (ストレージ・エリア・ネットワーク) を割り当てます。

サービス・プロバイダーの多くは、特定の顧客専門、および複数の顧客で共用されるチームを扱わなければなりませんし、また、作業の一部分を顧客チームが担当して、他の部分はパートナーまたはサード・パーティー・プロバイダーに外部委託する場合もあります。このような多様性はワークフロー・ツールでは解決できません。また、このような多様性に対処するためには、同じワークフローの複数のバージョンを作成する必要がある場合が多くあります。分解は再利用可能性を促進しますが、実際のワークフローからリソース割り当てを切り離していない分解は、顧客間のプロセスの再利用を著しく制限する可能性があります。

アトミック・サービスと複合サービスから構成され、注文または要求ごとに複数の実行チームとサービス・プロバイダーにアトミック・サービスを動的に割り当てられる能力を持ったデリバリー・カタログが、効果的なサービス・デリバリー組織には不可欠です。

このアプローチには、他にもメリットがあります。コンポーネントを使用することによって、合成サービス・レベルやアトミック・サービス・レベルなどの複数のレベルで KPI を定義することができます。また、コンポーネントを使用すれば、より細かいレベルでサービス・デリバリー・チームのパフォーマンスを測定することができます。ワークフローからプロバイダーを分離することによって、サービス・デリバリーの回復力が向上します。あるチームの作業負荷だけが高い場合やあるチームが障害が原因で機能できない場合は、別のチームが作業を引き継ぎ同じ結果を提供することができます。チームを有効に活用すれば次のような結果も得られます。スケジューリング・エンジンは、単一のサービス・プロバイダーのリソースに限定されることなく、複数のサービス・プロバイダー間の作業負荷を最適化することができます。

サービス・デリバリー・カタログは、成果物を保存するためのリポジトリーと、成果物を作成してそのライフ・サイクルを管理するためのサービス管理コンポーネントを提供することによって、サービス・コンポジション・モデルを支援します。加えて、アカウントの観点とサービス・プロバイダーの観点を提供します。

上に戻る

サービスの管理

サービス・デリバリー・カタログの中心は、アトミック・サービスと複合サービスの両方の管理です。

アトミック・サービスと複合サービスの表現方法

アトミック・サービス定義 (ASD) では、サービス・デリバリー・カタログ内のアトミック・サービスのタイプと、そのサービス名を持つサービスの現行バージョンを表すサービス識別子、サービス名、およびバージョン番号などの属性が指定されます。複数のバージョンを平行してアクティブにすることができます。そのため、ASD の新しいバージョンごとに独自のサービス識別子が付与されます。また、ASD 属性には、1 つ以上のサービス・カテゴリー、キーワード (特定の ASD の検索に役立つ)、および成果物の属性 (サービスの機能とその実行効果の自然言語による記述) も含まれます。

資格特性属性では、サービスを実行するサービス・プロバイダーに関する要件が記述されます。これらの要件は、平易な自然言語で表現され、サービス・プロバイダーが特定の ASD で定義されたサービスの提供を契約する前に読み、デリバリー組織がその ASD に対してサービス・プロバイダーを認定する前にチェックすることになっています。正式な特性定義は、場所や営業時間などの ASD の属性に関する機械可読仕様です。この定義は変数定義に似ています。各サービス・プロバイダーは、これらの特性に関する値の提供を要求されます。この正式な特性定義に対して制約を定義することができます。この制約は、正式な制約言語で表現され、サービス・プロバイダーが ASD に対して登録したときに自動的に評価されます。正式な特性定義と制約によって、資格特性を管理するための自動化されたアプローチが提供されます。予定時間属性では、この ASD で定義されたアトミック・サービスの標準提供時間が定義されます。実時間または予定時間は、サービス・プロバイダーまたはサービスのインスタンスによって異なります。

抽象インターフェース定義属性では、アトミック・サービスの呼び出し方法が定義されます。サービス指向アプローチに従って、SDMP では、Web サービス記述言語 (WSDL) を使ってインターフェースが指定されます。ただし、サービス・デリバリーにおけるアトミック・サービスは、サービス指向アーキテクチャー (SOA) におけるサービスの概念と全く等価ではありません。各アトミック・サービスは、1 つの WSDL ポート・タイプ内の 1 つのオペレーション (指定された一連の抽象オペレーションとして定義される) に対応します。そのため、抽象インターフェース定義は、WSDL ファイル、ポート・タイプの名前、およびオペレーションの名前で構成されます。さらに、WSDL ファイルでは、バインディング・レベル情報が指定されません。これは、この種の情報が特定のサービス・プロバイダーとのバインディングに関連しているためです。ポート・タイプ・レベル WSDL と、参照を通してポート・タイプ・レベル WSDL を含むことの多いバインディング・レベル WSDL の分離は、サービス指向システムを設計する場合によく見られるアプローチです。

ASD は、サービス・コンポジションに組み込まれることによって、特定のサービス・プロバイダーから切り離されます。ASD と同様に、サービス・コンポジションには、サービス識別子、サービス名、サービス・カテゴリー、サービス説明、およびキーワードが設定されます。サービス・コンポジションの予定時間は、そのサービス・コンポジションの基礎をなす ASD の予定時間の見積もりに基づく推定ターンアラウンド・タイムです。サービス・コンポジションごとにバージョン番号が割り当てられます。同じ名前でバージョンの異なるサービス・コンポジションには、別々のサービス識別子が設定されます。サービス・コンポジションは、特定のバージョンの ASD を参照します。そのため、新しいバージョンの ASD をサービス・コンポジションに含める場合は、新しいバージョンのサービス・コンポジション自体も必要です。

サービス・コンポジションの中心は、サービス計画です。これは、サービスを実装するために実行されるワークフローを記述したものです。コンポジションは、サービス・デリバリー・カタログで使用可能な ASD を使用して、WS-BPEL² (Web サービス・ビジネス・プロセス実行言語) 仕様で定義されます。サービス計画は、ASD の抽象サービス仕様で定義されたオペレーションを参照します。また、サービス計画は、サービス要求の時点で SDMP ランタイム・システムによって取り出され、サービス要求インスタンスが実行される前にサービス・コーディネーターによって変更することができます。

サービス・コンポジションの開始日は、特定のバージョンのコンポジションをアカウントに対して使用可能にすることができる時間です。終了日は、このサービス・コンポジションのバージョンに対してサービス要求を以後発行できなくなる時間を示します。取消可能属性では、サービス・プロセスの進行中にクライアントがサービスの実行をキャンセルできるかどうかが定義されます。サービスのタイプによっては、この属性が必要になる場合があります。

サービスの資格方針では、サービスを要求できる環境が定義されます。抽象インターフェースでは、クライアントがサービスを要求するときに指定しなければならないサービス要求のパラメーターが定義されます。これは、それに相当する ASD に対応し、ポート・タイプ・レベル WSDL 仕様に基づきます。

サービス・コンポジションには、そのコンポジションの QoS を定義するために関連付けられたサービス・レベル定義を含めることができます。この定義は、一連の QoS 属性定義、サービスの KPI、および QoS 属性に対する制約としてのサービス・レベル目標の定義で構成されます。また、サービス・レベルは、サービス・レベルによって異なるクライアントへのデリバリー・コストにも関連付けられます。サービス・コンポジションは、複数のサービス・レベルで提供および実行することができます。

アトミック・サービスと複合サービスのライフ・サイクル

ASD とサービス・コンポジションは、サービス・デリバリー・カタログの中核となる概念です。おおむね、その設計によって、サービス・デリバリー組織の振る舞いが決定されます。この重要性ゆえに、ASD とサービス・コンポジションの作成と変更は、サービス・デリバリー組織内のすべての利害関係者 (アカウント・エグゼクティブ、マーケティングおよび全般管理者、デリバリー・チーム、外部のサービス・プロバイダーとの連絡窓口など) が変更が生じたときに確実に情報を提供できるようにガバナンス・プロセスに従う必要があります。

図 3 は、個々の ASD のガバナンス・プロセスを示しています。WebSphere* Business Integration Modeler の表示フォーマットで描かれています。2 つの役割が関与しています。サービス・デザイナーは、前のセクションで説明したように、ASD の内容の作成および変更を担当するチームまたは個人です。すべての作成タスクと編集タスクがサービス・デザイナーに割り当てられます。サービス・デザイナーは、変更をアクティブにする時期も決定します。認定委員会は、ASD が作成または変更されたときに評価します。この委員会が、特定の ASD に含まれるすべての利害関係者を代表します。

図 3. ASD ガバナンス・プロセス

拡大図

最初の手順で、新しい ASD がサービス・デザイナーによって作成されます。次に、認定委員会が、提案された ASD の影響を評価します。これには、その ASD を実装可能なサービス・プロバイダーとその ASD が使用されるサービス・コンポジションの決定を含めることができます。承認が下りたら (または ASD がサービス・デザイナーに送り返されたら)、サービス・コンポジションの要件と ASD を実装するサービス・プロバイダーの都合に基づいて、サービス・デザイナーが ASD をアクティブにすることができます。アクティブにされた ASD は、サービス・コンポジション内で使用可能になります。

編集には 2 つのモードがあります。「クイック編集」手順では、マイナー・チェンジ (説明の変更など) を承認なしで適用することができます。サービス・プロバイダーやサービス・コンポジションに影響が及ぶ変更は、改訂として実施されます。改訂したものをサービスに投入する場合は、認定委員会が新しい評価と認定を実施する必要があります。特に、サービス・プロバイダーに対するアトミック・サービスの影響を評価する必要があります。改訂がアクティブになると、現時点でアクティブな改訂が非アクティブになります。つまり、現行の改訂は既存のサービス・コンポジションの実行には使用できますが、新しい改訂に含めることはできません。したがって、同じ ASD の複数のバージョンが平行して存在する場合があります。

各サービス・コンポジションには、図 3 に示した ASD の 1 つと正確に対応するメンテナンス・フローが設定されます。また、アクティブにされた ASD のリポジトリーは作成手順に情報を提供します。認定委員会が、サービス・コンポジションを評価して認定します。評価の目的は、改訂されたサービス・コンポジションが顧客のニーズを満たしており、その実装がコンポジションで使用されるアトミック・サービスで使用可能なことを保証することです。サービス・コンポジションがアクティブな状態でそのコンポジション内の ASD を非アクティブにしても、そのコンポジション自体は非アクティブになりません。サービス・コンポジションのバージョンを非アクティブにすると、そのコンポジションを使用したサービス要求の発行はできなくなりますが、その時点で処理中のサービス要求は影響を受けません。

上に戻る

サービス・プロバイダーの管理: サービス・プロバイダーとその機能の表現方法

前述のように、我々のモデルでは、サービスを提供している外部組織のチームだけでなく、サービス・デリバリー組織内部のチームに対しても、「サービス・プロバイダー」という用語を使用しています。外部のサービス・プロバイダーが会計処理や請求処理などを促進させるためにはさまざまな情報を収集する必要がありますが、我々のサービス要求管理システムではこれらの財務面は考慮しません。

サービス・プロバイダーに関する単純なコンテンツ・モデルを使用します。サービス・プロバイダーにはユニークなプロバイダー識別子が付与されます。IBM ITD 組織内部のサービス・プロバイダーには、Global Services Delivery Center (GSDC) ID が付与されます。この ID によって、特定の組織がコード化され、LDAP (Lightweight Directory Access Protocol)³ やその他の内部システムを通してその組織に関する詳細情報へのキーが提供されます。

外部のサービス・プロバイダーには、購入システム、その他の ERP (エンタープライズ・リソース・プランニング) システム、および会計処理システムへのキーを提供するベンダー ID が付与されます。サービス・プロバイダーごとに、名前、説明、所在地などの属性が付与されます。これは、クライアントへのオンサイト・サービスの場合に重要です。問い合わせとして、問い合わせに対応するサービス・プロバイダー側の従業員を複数登録できます。

各サービス・プロバイダーは、一連のサービス・プロバイダー機能 (SPC) に関連付けることができます。SPC は、特定のサービス・プロバイダーのサービスの遂行方法に関する具体的な詳細が記載された ASD とサービス・プロバイダー間の関連付けです。1 つの SPC インスタンスは、1 つのサービス・プロバイダーを 1 つの ASD に関連付けます。この関係は、ASD のサービス識別子とサービス・プロバイダー識別子を含むデータを使って把握されます。この関係には、サービス・プロバイダーがこのアトミック・サービスに関する要求を受け付ける期間の始まりと終わりを定義する開始日と終了日が設定されます。取消可能属性では、このプロバイダーによって提供されるアトミック・サービスをその開始後にキャンセルできるかどうかが定義されます。

インターフェース属性は、プロバイダーのアトミック・サービス実行の呼び出し方法についての仕様の中で決まります。インターフェースには、この SPC が関連する ASD の抽象 WSDL を参照するバインディング・レベル WSDL 仕様が含まれています。WSDL 仕様ではそれぞれ異なるプロトコルについて、複数のサービスやバインディングが含まれている場合があるため、サービス名とバインディング名も定義します。ASD の WSDL 仕様とそのポート・タイプおよびオペレーション定義を組み合わせた SPC のインターフェース定義によって、サービス・デリバリー・システムをサービス・プロバイダーの特定のアトミック・サービス実行にバインドすることができます。

資格特性属性では、ASD で指定された情報がサービス・プロバイダーによって提供されます。この情報は、要件が自然言語で表現されていれば自然言語での入力として、そうでいな場合は ASD の正式な特性定義に従った値として指定されます。サービス・デリバリー組織は、この情報に基づいて、サービス・プロバイダーが ASD の要件を満たしているかどうかを確認することができます。サービス・プロバイダーは、任意の数の SPC を持つことができます。また、各 ASD は、複数の SPC を通して複数のサービス・プロバイダーに関連付けることができます。

サービス・プロバイダーのサインオンと統合

内部のサービス・デリバリー・チームは通常のキャパシティーに見合う分のみ保持し、サービス要求のピークに対応するには外部のサービス・プロバイダーに依存する方法は、サービス・プロバイダーにとって有益な場合が多くあります。ITD のような大規模な分散サービス組織では、同じアトミック・サービスを担当する複数のデリバリー・チームが異なる地域のデリバリー・センターに分かれて配置されていますが、その他のデリバリー・チームは、機能別に分けられ、特定の狭い範囲の技術領域に特化することも考えられます。

内部と外部ともにサービス・プロバイダーの数は膨大であるため、サービス・デリバリー・カタログ内のサービス・プロバイダーに関する重要な基本情報については、これ以上の承認プロセスを行わず、プロバイダー側で保持することを前提としています。ただし、外部のサービス・プロバイダーの場合は、優良ベンダーの承認を得るために、サービス・デリバリー・カタログの範囲外で追加審査を受ける必要が生じる可能性があります。サービス・プロバイダーとして登録されるのは簡単ですが、特定の ASD に関するサービス・プロバイダーになるには、カタログ管理者による審査を受ける必要があります。図 4 に示されているように、SPC は詳細なガバナンス・プロセスに従います。

登録手順では、サービス・プロバイダーが、該当する ASD に関する SPC オブジェクトとサービス・デリバリー・カタログ内のサービス・プロバイダー独自の項目を作成します。また、この手順では、サービス・プロバイダーが、バインディング・レベル WSDL 仕様と資格特性に関する情報を指定する必要があります。その後で、カタログ管理者が、SPC を評価して、バインディング・レベル WSDL が有効であることと、プロバイダーの資格特性が ASD で定義された要件を満たしていることを確認します。認定された SPC は、サービス・プロバイダー自身ではなく、認定委員会によってアクティブにすることができます。SPC がアクティブになれば、サービス要求ランタイム・コンポーネントが、SPC の WSDL ファイル内で定義されたバインディング情報を使用して、サービス・プロバイダーにアトミック・サービスに対する要求を送ることができます。

SPC に対する変更は、ASD やサービス・コンポジションの変更と同様に管理されます。マイナー・チェンジの場合は、単純な編集手順を使用することができます。アトミック・サービスのオペレーションに影響するより大きな変更の場合は、評価と再認定を伴う正式な改訂プロセスを使用する必要があります。ASD を変更する場合は、その新しいバージョンのサービスの処理方法を定義した新しい SPC が必要です。同じサービス・プロバイダーがアトミック・サービスの複数のバージョンを平行して提供できますが、各々に別々の SPC が必要であり、またエンドポイントによって実装が異なる場合があります。サービス・デリバリー・マネージャーは、提供サービスのコンポジション内の各アトミック・サービスの実行のために独自の判断で SPC を登録しているので、実行時に、サービス・プロバイダーの 1 つを選択します。

上に戻る

アカウントの管理: 提供サービスの表現方法

アカウントが加入した一連のサービスは、提供サービスと言います。提供サービスごとに、サービス・コンポーネントとアカウントが関連付けられます。提供サービスには、サービス・コンポジション ID、アカウント ID、クライアント ID、開始日と終了日、および警告しきい値が設定されます。

警告しきい値では、クライアントが SLA コンプライアンス違反の可能性について通知してほしいパーセンテージのレベルが定義されます。たとえば、サーバーのプロビジョニングに関する最大ターンアラウンド・タイムが 5 日で、クライアントが、その平均が 4 日を超えた時点で通知するように希望している場合は、警告しきい値が 80% に設定されます。

アカウントごとに、提供サービス内のサービス・コンポジションの ASD に関するデフォルトのサービス・プロバイダーを定義することができます。アカウントには、所在地の希望または政府規制で定義された制約が設定される場合があります。プロバイダーは、施設内サービスに関する安全検査を受けなければならない場合があります。この検査は、特定の外部のサービス・プロバイダーや内部のサービス・デリバリー・チームのメンバーがすでに受けている可能性があります。

このような提供サービスを利用することによって、アカウント・マネージャーは、サービス・コンポジションの使用を自分たちのアカウントのニーズに合わせることができます。加えて、サービス・デリバリー・カタログ内で使用可能な一連の ASD に基づいて、新しいサービス・コンポジションを特定のアカウントの要件に合わせる機会が常に提供されます。ASD を再利用することによって、サービス・デリバリー・チームに追加の負担をかけることなくサービスをカスタマイズすることができます。

提供サービスの管理と顧客カタログとの統合

サービス・デリバリー・カタログの観点からは、アカウントは、関連付けられた提供サービスのライフ・サイクルの管理を通して、管理されます。図 5 に示されているように、提供サービスに関する責任はすべてアカウント・マネージャーにあります。

コンポーネントのライフ・サイクルの管理におけるその使用に加えて、アカウントの一連の提供サービスは、顧客の従業員がサービスを注文するための顧客カタログで公開されます。ほとんどの顧客が、独自のサービス・カタログ項目のすべてまたは一部の保持を選択します。この場合は、SDMP の要求者が、注文プロセスで顧客のカタログにアクセスできる必要があります。顧客のカタログにアクセスする方法には、リンク・アウト、パンチ・アウト、および完全統合の 3 つの方法があります。

図 4. SPC のライフ・サイクル

拡大図

顧客のカタログにアクセスする 3 つの方法のうち、リンク・アウト機能が最も単純です。顧客のシステムへの URL (uniform resource locator) リンクで構成されているため、ユーザーがそのリンクをクリックすれば、注文を実行する新しいサイトに移動します。注文は、SDMP から完全に独立しており、システム間の接続は全く必要ありません。パンチ・アウト機能は、もう少し複雑です。ユーザーは SDMP で項目を選択しますが、サービスは顧客のシステム内で遂行することができます。注文する項目を特定して選択すると、ユーザーは、その項目が構成および注文される顧客のカタログにシームレスに移動します。注文アクティビティーはユーザーからは見えません。完全統合機能が最も複雑です。このテクニックを使用すれば、顧客カタログを SDMP 内に表示することができます。完全統合の場合は、顧客が、自分たちのカタログを SDMP と同じデータ構造で保持するか、カタログを SDMP に適合させるための変換プログラムを使用する必要があります。

図 5. 提供サービスのライフ・サイクル

拡大図

上に戻る

実装

使いやすいカタログ管理システムを構築するには、これまでに説明したような事前に定義された規則に従ってカタログ要素を管理するだけでは不十分です。使いやすいシステムでは、カタログ要素の作成および編集を通してユーザーを誘導できる必要があります。SDMP サービス・デリバリー・カタログの管理でこの使いやすさの問題を解決するために、カタログ管理の実装をデータ管理コンポーネントとユーザー・インターフェース・コンポーネントに分解します。データ管理コンポーネントは、許可、ロール・アクセス、およびライフ・サイクルの管理を含む基になるデータベースとの通信を管理します。ユーザー・インターフェース・コンポーネントは、カタログ・コンテンツの作成および保守のプロセスでユーザーを支援する編集ツールを実装します。

データ管理

データ管理コンポーネントは、さまざまなライフ・サイクル要件を持つ複数のロールと複数のデータ・タイプ (アトミック・サービス、複合サービス、提供サービス、プロバイダーなど) をサポートする必要があります。この複雑さは、各データ・タイプのコンテンツ管理を個別のビジネス・プロセスとして処理することによって、自然に解消されます。これを実現するために、我々は、既存のツールを利用して、ビジネス・プロセス⁴の正式なモデルを開発し、それをモデル駆動型ビジネス・トランスフォーメーション・フレームワークに基づいてソフトウェアの実装に変換することができました。実装されたソフトウェアは、RMI (リモート・メソッド呼び出し)⁶ を通して対応するクライアントと通信する WebSphere Process Server⁴ Version 6.0.1 下のサーバー・アプリケーションとして動作します。

モデル駆動型ビジネス・トランスフォーメーション

モデル駆動型ビジネス・トランスフォーメーション (MDBT) は、IT プラットフォーム上でのビジネス・コンポーネントの柔軟で効果的な実現を可能にする革新的なフレームワークです。⁷ MDBT は、SOA とモデル駆動型アーキテクチャー (MDA**) からの概念を利用しています。このフレームワークは、戦略、オペレーション、実行、および実装の 4 つのレイヤーで構成されます。レイヤーごとに、異なる抽象化レベルが設定され、明確に定義された機能が実行され、対象者が区別されます。

戦略レイヤーでは、ビジネス・コンポーネントの目標と目的が定義されます。オペレーション・レイヤーでは、ビジネスで目標を達成するために実施されるオペレーションが記述されます。実行レイヤーでは、ビジネス・オペレーションの実行に必要な計算要素の抽象化が行われます。実装レイヤーでは、特定の IT プラットフォームへの計算要素の実装方法が指定されます。

オペレーション・モデルは、基幹業務マネージャーの観点を提供します。このモデルは、企業がビジネス目標を達成するために採用するビジネス・オペレーションを記述するために必要な抽象化を構成します。ビジネス・オペレーションは、運用知識をビジネス・タスクと成果物リポジトリーの 2 つの部分に分解することによってモデル化されます。ビジネス・オペレーションは、ビジネス・タスク、成果物リポジトリー、およびその他のビジネス・オペレーションを節点とし、これらの要素間の成果物の流れをりょう線とする連結グラフとして表現されます。SDMP カタログ・コンポーネントに関するビジネス・オペレーション・モデルを図 3 と図 4 に示します。

実行レイヤーにおける主要な抽象化は、適応型ビジネス・オブジェクト (ABO)⁸ の概念です。ABO は、ビジネス成果物の実行レベルの抽象化です。これによって、成果物の構造と動作がモデル化されます。ABO の主要素を以下に示します。ビジネス成果物のライフ・サイクルは、有限状態マシンを使用して定義されます。有限状態マシンの状態は、成果物のライフ・サイクル状態に対応します。ABO は、そのパブリック・インターフェースを通して外部イベントを受け取り、状態遷移の一部としてトリガーされるアクション呼び出しを使ってそれらのイベントに対処します。ABO は、データ・グラフを使用して、異種のデータ・ソースからオンデマンドで動的に情報を集約します。人やアプリケーションが、ABO とそのライフ・サイクルのさまざまなポイントで相互作用する場合があります。モデラーは、データに対する読み取りアクセス、書き込みアクセス、または検索アクセスを指定して、ビジネス・ロールと状態の組み合わせごとのイベントに関するアクセスを許可することができます。データ・グラフの一部または全体での CRUD (作成、取得、更新、および削除) オペレーションをモデル化するためにデータ・アクションが使用されます。これらのアクションは、状態遷移の副次作用として ABO によって呼び出されます。ABO は、状態遷移の一部としてトリガーされるリモート・アクションを通してその環境を変更します。ビューには、ABO の外部インターフェースまたは API (アプリケーション・プログラミング・インターフェース) が表示されます。

カタログ・ソリューションは、アトミック・サービス、サービス・コンポジション、提供サービス、サービス・プロバイダー、および SPC の 5 つの ABO で構成されます。次のセクションで説明するカタログのユーザー・インターフェース・コンポーネントは、ビュー・インターフェースを使用してこれらの ABO と相互作用します。

ユーザー・インターフェース

ユーザー・インターフェース・コンポーネントは、標準のモデル・ビュー・コントローラー・パラダイムを使用して動的な Web サーバー・アプリケーションとして実装されます⁹。このユーザー・インターフェースは、J2EE** Version 1.4¹⁰ をサポートしている任意のアプリケーション・サーバー上で動作します。簡単にするために、WebSphere Process Server を選択しました。このユーザー・インターフェースは、XML Bean¹² を使用して開発された Jakarta Commons¹¹ ユーティリティーと XML パーサーを利用します。ビューは、Java** Bean を通してビジネス・ロジックと通信する JavaServer Pages** (JSP**) として実装され、コントローラーは Java Servlets** を使用して実装されます。Java** Bean も JavaServer Pages** (JSP**) も J2EE 仕様の一部です。

このモデルでは、データ操作がビジネス・ロジックから切り離されます。ビジネス・ロジックは、それぞれの JSP ページに対応するアクション Java Bean によって処理されます。データ操作は、それぞれの基になるデータ・タイプ (アトミック・サービスやサービス・コンポジションなど) に対応するデータ・ラッパーによって処理されます。データ・ラッパーによって、基になるデータ管理クライアント API がビジネス・ロジックからは見えなくなります。ビジネス・ロジックは、ラッパーを Java インターフェースとしてしか操作しません。ラッパーとラッパー実装の間の結合は、ランタイムで初期化されるクラスによって仲介されます。MDBT で提供されるデータ管理クライアント API をアップグレードする場合は、ラッパー実装クラスだけの変更が必要になり、ビジネス・ロジックそのものも変更する必要はありません。このことは、データ管理とビジネス・ロジックを平行して開発する場合に有効なことがわかっています。

上に戻る

サービス・デリバリー・カタログを使用したビジネス目標の調整

サービス・デリバリー・カタログの実装は、サービスの受け手とプロバイダーの両方が求めるビジネス目標に厳密に合わせる必要があります。このカタログでは、サービスの要求方法と提供方法が標準のフレームワークで定義されるため、双方に、サービスを厳密に要求に合わせ、サービス・デリバリー・コストを見積もり、SLA 違反を回避し、請求のための正確なレコードを作成する機会が提供されます。このセクションでは、サービスがどのようにプロバイダー・ポートフォリオにマップされるか、このカタログがランタイム中およびさまざまな会計期間にビジネス目標が確実に満たされるように支援するかについて概説します。

ほとんどのサービス・プロバイダーにおいて、顧客に販売されるサービスのポートフォリオと実際に提供されるサービスのポートフォリオが異なります。SDMP の方法では、販売されるサービスのポートフォリオが、提供されるサービスのポートフォリオにマップされます。そこから、ベスト・プラクティスを利用して、顧客の特定の要件に基づいてデリバリー・カタログが作成されます。図 6 の左側に示されているように、サービスは、インフラストラクチャー・アクセス・サービスのようなデリバリー・テーマに基づいて顧客に販売されます。このテーマは、ごく一般的なもので、図の中央にあるデリバリー・ポートフォリオ内の複数のサービス要素の 1 つにマップされます。この例では、インフラストラクチャー・アクセス・サービスが、サーバー・サポートやネットワーク管理にマップされます。さらに、これらのサービス要素のそれぞれが、ベスト・プラクティスにマップされ、さらに、ベスト・プラクティスが、顧客のビジネス要件に基づいて実際のサービス・デリバリーのアトミック・サービスと複合サービスにマップされます。カタログ内でデリバリー用のサービスが作成されたら、それらをエンド・ユーザーが要求できるようにすることができます。

図 6. 販売するサービスのアトミック・サービスと複合サービスへのマッピング

拡大図

サービス要求は、実行時に、ビジネス目標の観点から、追跡および管理されます。恐らく最も一般的なビジネス目標は、デリバリー・タイムに関する SLA を確実に履行することです。SDMP は、この目標をタスク・レベル、アトミック・レベル、または複合レベルで達成することができます。SLA は、電子メール・サービスなどのサービスのタイプ、または、部門などの任意の論理的組織に対して設定することができます。SLA が設定されたら、通知に関するしきい値を設定することができます。サービスの割合と総消費量を追跡することも重要です。ランタイム・ツールで、承認済みの資格を指定したり、注文をカウントしたり、注文を資格と比較することができます。指定した資格でよければ、そのツールで、新しい注文を抑制したり、要求者に追加注文によって余分なコストが発生することを警告することができます。カタログ・データは、長期間にわたって、請求処理のために収集したり、ベースラインの設定やサービスの再設計のために調査することができます。

注文またはサービス・タイプごとの平均ターンアラウンド・タイムや平均コストなどの共通の KPI に関するベースライン・データをデータ・リポジトリーから収集することができます。KPI データは、顧客のデリバリー環境内と、プロバイダーが複数の顧客に対応している場合の顧客間の、両方で同様のサービスを比較するために使用することができます。業界標準との比較も実施することができますが、標準のサービス定義が不足しているため、これはあまり意味をなさない可能性があります。

この比較データを使用して、基準以下のサービスを特定して再設計の対象にすることができます。再設計の取り組みは、複合サービス、アトミック・サービス、またはタスク・レベルの比較データを利用することによって促進されます。これによって、非効率的な部分を特定したり、根本原因分析を実施することができます。特定の実行者または作業の複雑さが原因で再発する問題は、再設計によって解決することができます。再設計したサービスを公開して、その結果に基づいて、評価してさらに修正を加えることができます。こうして、フィードバック・ループが作成され、使用されます。最終的に、改善された結果をマーケティングに連絡して、顧客への提供価格を修正することができます。

上に戻る