Cisco Prime Service Catalog 11.0 設計者ガイド
サービスおよびサービス バンドルの設定
サービスおよびサービス バンドルの設定

サービスおよびサービス バンドルの設定

この章は次のトピックで構成されています。

サービスおよびサービス バンドルの設定

サービスは、Service Designer モジュールで特定のサービス チームにより「所有される」同様サービスまたは関連サービスのセットをまとめるために設計およびグループ化できます。 サービス グループを使用して、次のことを行えます。

  • グループ内のサービスに対する承認とエスカレーション プロセスの設定
  • グループ内のサービスをオーダーするための権限の設定
  • グループによって使用される役職の割り当て

サービス グループ フォルダは、エンド ユーザが My Services を介して参照するカテゴリとは異なります。 サービス グループの名前はエンド ユーザに表示されません。

たとえば、組織の電話サービスの取得およびセットアップのためのサービスを含む「電話サービス」サービス グループを作成するには、サービスを提供するためのサービス チームを割り当て、他の人に電話サービス グループの管理を担当させる必要があります。 サービス グループは携帯電話をオーダーできる人を指定し、電話がオーダーされると、承認プロセスを適切に配置します。 電話サービス グループには、サービスの承認や確認が遅れた場合に担当者にアラートを出すように設定される一連のエスカレーション メッセージも含めることができます。

サービス グループの作成

同様のサービスは、Service Designer モジュールを使用してグループ化できます。 グループを使用して、サービス グループ レベルで認証プロセス、オーダー権限、およびエスカレーションの通知を設定できます。 サービス レベルでの権限の設定については、サービスをオーダーするためのサービス レベルの権限の定義を参照してください。

はじめる前に

サービス要求を確認し、サービス要求を承認し、エスカレーションにも対処する組織単位(OU)または人物を選択します。


    ステップ 1   [Service Designer] を選択します。
    ステップ 2   [新規(New)] > [新しいサービスグループ(New Service Group)] の順にクリックします。
    ステップ 3   サービス グループ フィールドの詳細で規定されているようにフィールド情報を入力し、[このサービスグループを追加(Add This Service Group)] をクリックします。

    サービス グループを表示するには、サービス グループ名を選択してそのサービス グループの [詳細(details)] タブと [設定(configuration)] タブを開き、サービス グループ名の横にある [+] アイコンを展開してグループに関連付けられているサービスを表示します。

    ステップ 4   サービス グループを作成後、個人またはユーザのグループがサービス グループ内のサービスを管理できるように、サービス グループを設定します。 設定するには、サービス グループを選択し、以下の手順を実行します。
    • [全般(General)] タブで、サービス チームを選択し、役職を割り当てます。 サービス グループ設定の表を参照し、フィールドの詳細を入力します。
    • [承認(Authorizations)] タブで、承認構造、確認、およびエスカレーション プロセスを設定します。 承認および確認のワークフローを参照し、フィールドに入力します。
    • [権限(Permissions)] タブでロール ベースの権限を割り当てます。 グループ オブジェクト レベルの承認は、人、組織単位、グループ、役職、およびロールが実行できるアクションのタイプです。 サービス グループでサービスを設計できるようになると、自動的にユーザはそのグループ内のサービスを表示できます。 グループ レベルで権限を設定するには、サービス グループ権限の割り当てを参照してください。

    ただし、グループのサービスをオーダーする機能は個別に割り当てる必要があります。 グループ レベルの権限とサービス レベルの権限の違いについては、サービスをオーダーするためのサービス レベルの権限の定義を参照してください。


    サービス グループが不要になった場合は、削除できます。 サービスがまだ存在しているサービス グループを削除することはできません。 サービスが存在する場合、それらを削除するか、他のサービス グループに転送してから、グループを削除します。 サービス グループを削除するには、削除するサービス グループを選択し、[全般(General)] タブで [削除(Delete)] をクリックします。

    表 1 サービス グループ フィールドの詳細

    フィールド

    説明

    名前(Name)

    サービス グループの名前。 必須作業です。 この名前は、組織およびニーズに固有である必要があります。 エンドユーザにはこの名前は表示されません。この名前はサービス グループを作成した後に編集できます。

    たとえば、「End User IT Desktop Support」、「End User IT Desktop Software」、または「Identity Management」のような名前を付けます。

    説明(Description)

    サービス グループの簡単な説明。任意ですが、入力しておくことを推奨します。

    サービス チーム(Service Team)

    このサービス グループのサービスに対して責任のあるサービス チーム。つまり、サービス グループ内のサービスを「所有」するチーム。

    表 2 サービス グループ設定の表

    フィールド

    説明

    名前(Name)

    サービス グループの名前を入力します。

    説明(Description)

    サービス グループの説明を入力します。

    サービス チーム(Service Team)

    サービス グループの適切なサービス チームを関連付けます。 詳細については、サービスのセットアップを参照してください。

    サービス グループに割り当てられたサービス チームを変更すると、以下のようになります。

    • このグループのサービスで使用されているアクティブ フォーム コンポーネントに指定されている「アクセス制御」を再設定して、以前に指定したサービス チームに関連付けられたキューを追加の参加者のリストに明示的に追加する必要が生じる場合があります。 これは、タスクがそのキューに割り当てられている場合に必要です。 詳細については、特定のサービスへのアクセス制御設定の追加を参照してください。
    • すべての人の役職への割り当てが削除されます。 これは、サービス グループを所有するサービス チームのメンバーしか、そのグループ内の役職をこなせないからです。 このような割り当ては再指定する必要があります。

    役職(Functional Position)

    役職を追加するには、次の手順を実行します。

    1. 役職テーブルの下の [追加(Add)] をクリックし、役職を選択します。
    2. 追加する n 役職の横にあるチェック ボックスを選択します。

    役職をサービス グループ内のユーザに割り当てるには、次の手順を実行します。

    役職の行の […] ボタンをクリックし、検索オプションを使用して人物を検索します。 人物を選択し、[OK] をクリックします。

    (注)      当該の役職に割り当てられているタスクがある場合、そのタスクはデフォルトの提供キューに入ります。

    詳細については、「組織の構造化」を参照してください。 役職に関する説明については、『Cisco Prime Service Catalog 11.0 Administration and Operation Guide』を参照してください。

    保存(Save)

    このタブの変更を保存するには、[保存(Save)] をクリックします。

    表 3 承認および確認のワークフロー

    ワークフロー

    手順

    承認構造の設定

    [サービスグループの承認構造(Authorization Structure For Service Group)] の下で、次のフィールドから 1 つ選択します。

    [サイト承認構造のみを使用(Use Site Authorization Structure Only)]:サイト規模の承認構造のみを使用し、サービス グループまたはサービス レベルで設定された承認と確認を無視します。

    [サービスグループレベルの承認構造のみを使用(Use Service Group-level Authorization Structure Only)](サービス グループ レベルは使用しない):ロール、オーダーまたはエスカレーションの固有スキームに基づいて、承認構造を作成できます。

    [サイトレベルとサービスグループレベル両方の承認構造を使用(Use Both Site Level and Service Group Level Authorization Structures)]:ロール、オーダー、またはエスカレーションのサイト規模のスキームを受け入れ、承認プロセスを拡張するために構築したカスタマイズ スキームを使用して、それを補足できます。 詳細については、『Cisco Prime Service Catalog 11.0 Administration and Operation Guide』の「Configuring Site Administration」を参照してください。

    承認タイプの設定

    次の承認タイプのうち 1 つを選択します。

    • [サービスグループの確認(Service Group Review)]:これは情報に対してのみで、確認者はサービスを拒否したり、提供プロセスはキャンセルすることはできません。 提供プロセスは、確認者が確認タスクで [OK] をクリックするまで進みません。
    • [サービスグループの承認(Service Group Authorization)]:承認者はサービスを要求した人がそれを受け取る資格があるかどうかを判断できます。 承認が拒否されると、プロセスは停止し、サービスは提供されず、承認は順次実行されます。 複数のサービス グループの承認または確認を持ち、それぞれが異なる人によって実行されるようにすることができます。 承認は指定した順序で順番に実行されます。つまり、前の承認者がサービス要求を拒否すると、そのサービス要求での作業はそれ以上行われなくなります。 「管理モジュール経由で現在有効になっていません(not currently enabled via the Administration module)」というメッセージが表示された場合は、特定のサービス グループの承認/確認がサイトで有効になっていません。 これは、サイト全体の標準に関してサイト管理者が行った決定を反映している可能性があります。 この設定は、管理モジュールで変更できます。

    確認およびエスカレーション プロセスの定義

    確認の同時プロセスを定義するには、次の手順を実行します。

    [追加(Add)] をクリックし、レビューの [名前(Name)]、[件名(Subject)]、[期間(Duration)]、各レビューに対する [実行(Effort)]、およびレビューを割り当てる人を入力します。

    確認は同時に実行されます。 確認者はサービスの提供を取り消せないため、同時に実行することで、提供プロセスを効率的に処理します。

    エスカレーションの同時プロセスを定義するには、[追加(Add)] をクリックし、エスカレーションの電子メールを送信するまでの時間と、各エスカレーションの電子メールの受信者を更新します。 詳細については、「提供計画の設定」を参照してください。

    表 4 サービス グループ権限の割り当て

    許可内容

    定義

    このサービス グループ内のサービスを設計し、データを変更する

    ユーザはこのサービス グループ内のサービスを設計し、グループ データを変更できます。

    通常、これらの権限はこのサービス グループのサービスを設計および設定する個人に予約されます。

    このサービス グループのサービスと他の情報を表示する

    ユーザはサービス グループとサービス定義を表示できますが、それらを変更することはできません。

    このサービス グループのサービスをオーダーする

    ユーザは、このサービス グループのサービスをオーダーできます。

    これは、サービスのコンシューマがこれらのサービスを表示および要求できる程度です。

    人に権限を割り当てる

    ユーザはこれらの権限を他の人に割り当てることができます。

    通常、この権限はサービスの設計者と、サービス グループのオーナーに限定されています。

    サービスの作成

    新しいサービスをカタログに追加し、説明情報を追加することでサービスのコンテキストを設定し、また、サービスのレポートと表示動作に影響する重要な属性と設定を設定するには、この手順を使用します。

    はじめる前に

    サービス グループをセットアップします。 サービス グループの作成 を参照してください


      ステップ 1   [Service Designer] > [新規(New)] > [新規サービス(New Service)] の順に選択します。
      ステップ 2   提供されたフィールドに詳細を入力します。
      (注)      サポート情報にリンクすることでサービスをさらに説明するには、[URLを入力(Enter a URL)] フィールドを使用します。 My Services のサービスの説明に、その URL への [詳細情報(More information)] リンクが表示されます。
      ステップ 3   [このサービスを追加(Add This Service)] をクリックします。
      ステップ 4   サービスを追加した後、[全般(General)] タブに情報を入力することで設定を開始できます。

      [全般(General)] タブは、エンド ユーザがサービス カタログを参照するときに、コンシューマ エクスペリエンスに影響を及ぼすために主に使用されます。 フィールドを完成させるための参考として、サービス属性を使用します。

      ステップ 5   [保存(Save)] をクリックします。

      表 5 サービス属性

      フィールド

      定義

      名前(Name)

      サービスの名前。 これは、サービス カタログでエンド ユーザに表示される名前です。 サービス名は 200 文字までです。 例:Computer Memory Upgrade

      ステータス(Status)

      ステータスが [アクティブ(Active)] である場合、サービスが検索可能で、My Services でのオーダーに使用できることを意味しています。 ステータスが [非アクティブ(Inactive)] の場合は、サービス カタログ内でサービスが検索可能またはオーダー可能にならないように設定されます。 サービスがまだドラフト フォームである、期限が切れている、または常にではなく一定の間隔で提供されるように計画したサービスである場合、サービスは非アクティブである可能性があります。

      サービス グループ

      サービスが属するサービス グループ。

      オーダー可能なサービス(Orderable Service)

      My Services 内のサービスに対して「オーダー(Order)」および「他人のためのオーダー(Order For Others)」リンクを有効(はい(Yes))または無効(いいえ(No))にする設定。

      通常、オーダー不可のサービスはカスタマーにサービス カタログ内のアクション不可の情報を提供するために作成されます。

      レポート可能(Reportable)

      このフィールドは、カスタマーには影響しません。 これはサービス設計者向けのフィールドで、サービス データを Service Catalog データ マートにロードするかどうかを指定します。ロードすることで、Advanced Reporting モジュールでアドホック レポートおよび Report Designer を使用して構築されたアドホック レポートやクエリで使用できるようになります。

      サービスをレポート可能にするための詳細情報とベスト プラクティスについては、『Cisco Prime Service Catalog Reporting Guide』を参照してください。

      権限付与(Entitlement)

      このオプションを [はい(Yes)] に設定すると、すべてのエンド ユーザが承認の必要なく、このサービスを要求できるようになります。 サイト レベル、部門レベル、またはサービス グループ レベルの承認が設定されている場合、権限付与を [はい(Yes)] に設定すると、このサービスに対するこれらの承認が無視されます。

      価格の計算(Compute Price)

      このフィールドを使用して、カスタマーがサービスをオーダーする前にサービスの価格を計算できます。 ドロップダウン リストから [はい(Yes)] を選択すると、My Services でサービスをオーダーするよう選択したときに [価格の計算(Compute Price)] ボタンが表示されます。

      オーダーモード(Ordering Mode)

      このフィールドでは、ショッピング カートにサービスを追加するか、またはサービスを即座にオーダーするオプションが提供されます。 使用可能なオプションは次のとおりです。

      • [有効なレビューを追加(Add Review Enabled)]:[カートに追加(Add to Cart)] ボタン(Service Catalog)または [オーダーの追加と確認(Add and Review Order)] ボタン(My Services)が提供され、エンド ユーザはサービスをショッピング カートに追加できます。 ユーザは後でサービスを確認しオーダーを送信できます。 同じオーダー モードの他のサービスを同じショッピング カートに配置することができます。 これがデフォルトの設定です。
      • [無効なレビューを追加(Add Review Disabled)]:サービスは、個別の要求として自分のカートでのみオーダーできます。 [注文の送信(Submit Order)] ボタンのみ使用できます。
      • [1クリック(1-Click)]:[無効なレビューを追加(Add Review Disabled)] と同様、サービスは自分のカートでオーダーします。 さらに、ユーザには要求送信を確認するための単純な確認ダイアログが表示されます。 これによって、ユーザはアクションとして要求を見ることができます。 このモードは、ユーザからの入力データ(たとえば「Stop virtual machine」)を必要としない要求に特に適しています。
      (注)      1 クリック機能は、Service Catalog モジュールでのみ使用可能です。

      ページネーションビューモード(Pagination View Mode)

      このフィールドを使用して、Service Catalog モジュールでウィザードの形式でオーダー ページにディクショナリを表示し、前後へのナビゲーション コントロールが備わった複数のページにフォーム フィールドを表示することができます。 サービス項目のオーダー ページの設定方法の詳細については、ウィザードとしてのサービス フォームの表示を参照してください。

      Service Catalogで非表示にする(Hide in Service Catalog)

      Service Catalog モジュールでサービスを非表示にしたり、[マイスタッフ(My Stuff)] の [注文ステータス(Order Status)] および [完了したオーダー(Completed Orders)] ビューでこのサービスに関連付けられた要求を非表示にするには、このフィールドを選択します。 これは、サービス設計者がこれらのサービス要求をエンド ユーザが表示したり取り消したりできないようにする場合に役立ちます。 多くの場合、これらはより複雑なサービス バンドルの一部として呼び出される子サービスです。

      説明

      製品またはサービスの簡単な説明を入力するためのテキスト フィールド。 この情報は My Services または Service Catalog でコンシューマに表示されるため、可能な限り明確にして、エンド ユーザがオーダーするものを正確に把握できるようにする必要があります。

      サービス レベルの説明(Service Level Description)

      これはオプションのテキスト フィールドです。 ここに入力された内容はすべて My Services または Service Catalog でコンシューマに表示されます。コンシューマが期待するサービスのレベルについてのコンシューマに対する保証になるものとして考える必要があります。 説明は 4000 文字を超えないようにします。

      標準期間(Standard Duration)

      [標準期間(Standard Duration)] はすべての承認と確認が完了した後の、このサービスの標準(通常)の提供時間です。 コンシューマは、サービスを要求する前にこの情報を入手できます。

      [標準期間(Standard Duration)] はサービスを完了する必要のある実行期日ではなく、実行期日の計算には使用されません。 このフィールドは、サービス実施チームのカレンダーを考慮に入れません。 これは、時間を日に換算し、Advanced Reporting に使用されるサービスの標準コンプライアンス メトリックを算出するために使用されます。

      表示単位(Display Units)

      [標準期間(Standard Duration)] は、時間または営業日で表示できます。

      営業日で表示するように選択する場合、[計画(Plan)] タブの [1日あたりの稼働時間(Working Hours per Day)] 設定を使用して、時間数が日数に変換されます。

      たとえば、サービスの標準期間が 3 営業日である場合、1 日の労働時間を 8 時間と仮定して、[標準期間(Standard Duration)] フィールドに 24 時間と入力します。

      サービス提供計画を編集して準備するときに、システムはすべての計画のアクティビティを完了するのに必要な合計時間数を追跡し続けます。 また、[1日あたりの稼働時間(Working hours per day)] 設定([計画(Plan)] タブ > [タスク(Tasks)] サブタブ。タスク サブタブのフィールドを参照)を使用して、計画の実行に必要な作業日数も算出します。

      予測方法(Forecasting Method)

      サービスが送信された後、My Services でエンド ユーザにサービスの実行期日を予測するのに使用される方法を選択します。 この予測は、常に概算であると見なす必要があります。 どの予測方法が選択されても、要求のすべての承認と確認が完了した後、Service Catalog はすべての実行期日を再計算します。

      予測方法の選択には、機能的な影響(サービスの要求者に何が、いつ表示されるか)とパフォーマンス上の影響の両方があります。 詳細については、実行期日の予測を参照してください。

      追加のURL(Additional URL)

      [追加のURL(Additional URL)] フィールドを使用して、サービスの説明を追加したり、サポート情報へのリンクを提供したりできます。 たとえば、サービスがデスクトップ ソフトウェアに関するものである場合、エンド ユーザがシステム要件を参照したり、正しいソフトウェアをオーダーしているかを確認したりできるように、外部製品へのリンクを含めることができます。

      URL は、「http://」で始まる完全修飾にする必要があります。 サービスの説明には、指定した URL にアクセスする [詳細情報...(More Information …)] リンクが含まれます。

      役職(Functional Positions)

      サービスに関する、使用可能な役職と、それらに対応する個人の割り当て。 役職は Organization Designer で定義されます。 このサービスに関して、役職を追加し、その役職に人を割り当てます。

      詳細については、『Cisco Prime Service Catalog Administration and Operations Guide』の「Configuring Functional Positions」を参照してください。

      キーワード

      My Services の検索機能により、サービス名およびサービスの説明内にある任意の語を含むサービスが返されます。 キーワードをさらに追加すると、ユーザ検索をより効率的に行うことができます。

      たとえば、サービスが「Order a New Laptop」であり、ユーザは Dell または Lenovo のいずれかのラップトップを選択できる場合、追加のキーワードとして「Dell」および「Lenovo」を使用できます。

      これらはカスタマー ナビゲーションに関してのみ使用され、レポート作成には使用されません。 詳細については、「キーワードの管理」を参照してください。

      カテゴリの表示(Display Categories)

      サービスが My Services または Service Catalog に表示されるカテゴリ。 詳細については、サービスの分類を参照してください。

      実行期日の予測

      次の表には、実行期日を予測する方法がまとめられています。詳細については、以下の段落で説明します。

      表 6 実行期日の予測

      方法

      機能

      パフォーマンス上の影響

      タスク期間から実行期日を予測

      システムは、提供計画内のすべてのタスク、タスクごとの予測期日、および割り当てられた実行者に基づいて実行期日を予測します。

      すべてのタスク(承認/確認および提供)がインスタンス化され、個々のキューまたは個人のカレンダーが調べられて、スケジュールされたタスクの開始時間と終了時間が判別されます。

      標準期間を使用して実行期日を概算

      システムは、各タスクに割り当てられた実際の参加者を調べるのではなく、デフォルトのサービス提供キューの作業時間に関連付けられたカレンダーを使用して実行期日を概算します。

      すべてのタスク(承認/確認および提供)がインスタンス化されますが、個々のキューまたは個人のカレンダーは調べられません。

      実行期日を予測しない

      オーダーが送信されたときに、実行期日を予測しません。 ユーザには、My Services の実行期日として、「TBD」が表示されます。

      要求が送信されたときに、承認/確認タスクのみがインスタンス化されます。

      実行期日を予測する方法を選択する場合、機能的な影響とパフォーマンス上の影響の両方があります。 以下の要因は、実行期日の予測の正確性に影響を及ぼします。

      • サービスに関連付けられたすべての承認または確認 すべての初期予測では、これらの各承認に関連付けられた特定の期日を使用します。 ただし、実行期日はすべての承認が算出された後、再計算されます。 承認と確認の完了時刻における差異(通常、提供計画に指定したものより時間がかかる)により、非現実的な予測が行われる可能性があります。
      • 提供計画に含まれる任意の条件付きタスク。 タスクの実行を管理する条件式は、サービス提供時点でしか評価できないため、どの予測も条件付きタスクの実行を考慮できません。 このため、実際には実行されていないタスクが含まれることによって、見積もりが水増しされる可能性があります。 一方、見積もりは常に最悪のシナリオ(すべてのタスクを実行することを想定)であるため、サービス要求がより早い時期に実行されると、ユーザが予想外に助かることがあります。

      実行期日が予測されると(概算または見積もりで予測)、Service Catalog はすべてのタスクを提供計画に作成(インスタンス化)する必要があります。 計画内のタスク数によっては、これに非常に多くの処理時間が費やされる可能性があります。 計画内の各参加者に割り当てられた作業カレンダーを調べて、タスクの開始日と終了日を正しく導き出す必要があるため、実行期日の見積もりには、より長い時間が必ずかかります。

      [送信、承認、非同期的にレビュー(Submit, Approve, Review Asynchronously)] に対する管理設定は、実行期日を予測するときに、Service Catalog の認識されるパフォーマンスに影響を及ぼします。 デフォルトではこの設定はオフになっているため、「要求送信のバックグラウンド処理」は無効になっています。 したがって、Service Catalog はこれらのタスクを同期的にインスタンス化します。つまり、ユーザはオーダーを送信します。 Service Catalog は予測方式の手順どおりにタスクを作成し、ページの制御がユーザに戻ります。 複雑なタスク計画の場合、ユーザはオーダーフォームから処理を進めるのに非常に長い時間待つ可能性があります。

      [送信、承認、非同期的にレビュー(Submit, Approve, Review Asynchronously)] がオンに設定されている場合、Service Catalog は非同期的にタスクを作成します。つまり、バックグラウンドで作成を実行します。 これにより、ユーザはすべてのタスクが作成されるまで待機することなく、オーダー フォームを終了し、Service Catalog の使用を続行できます。 待機時間がなくなります。 承認がほとんどない(またはない)か、単純な提供計画のある要求については、パフォーマンスの相違は顕著に表れない場合がありますが、より複雑なワークフローを含むサービスでは明らかに示されます。 要求の送信後、Business Engine によって処理されるまで、ステータスは [発注済み(Ordered)] になります。 その後、ステータスは [進行中(Ongoing)] になります。

      非同期処理には追加の設定ステップが必要であり、一部のインストール済み環境では、パフォーマンスに認識される相違が表れないため、Service Catalog を [送信、承認、非同期的にレビュー(Submit, Approve, Review Asynchronously)] に設定することは任意です。 実行期日の予測の方法について決定を行う前に、この設定が有効になっているかどうかをシステム管理者に確認してください。

      関連サービスのバンドルの設定

      バンドルされたサービスとは、カスタマーがバンドル(親)をオーダーすると自動的にオーダーされる 1 つ以上の関連サービスを含むサービスのことです。 同時に共通してオーダーされるサービスをグループ化する場合に、バンドルを使用すると便利です。 たとえば、新しい従業員全員に次のサービスが必要であるとします。

      • LAN ID
      • デスクトップ PC またはラップトップ PC
      • ボイスメール付きの新しい電話機

      ユーザが新しい従業員に対し 3 つのすべてのサービスを必ずオーダーすることを期待するのではなく、これらの各サービスを含むバンドルを作成することができます。

      バンドルでは、2 つ以上の関連するサービスまたは既存のサービスを含む新しいサービスが、親サービスと呼ばれます。 親サービスに含まれているサービスは、子サービスと呼ばれます。

      サービスをバンドルするためのワーク フロー

      バンドルの作成と処理作業には、Service Catalog 内の複数の異なるモジュールとタスクが関与します。 簡単な概要を示します。

      • 作成:サービス グループとサービスを作成後、Service Designer モジュールを使用してバンドルを作成します。
      • オーダー:バンドルは、Service Catalog モジュールからオーダーできます。 ユーザは、サービスがバンドルであることに気付かない可能性があります。 たとえば、サービス カタログからサービスを選択するときに、ユーザが [オーダー(Order)] リンクをクリックすると、バンドルの複合オーダー フォームが表示され、オーダー フォームを確認すると、親サービスのみが表示されます。 ただし、サービス カタログに表示されているサービス名リンクをユーザがクリックすると、子サービスごとのリンクをクリックして、詳細情報を確認できます。 しかしながら、この方法ではどの子サービスも個別にオーダーできません。 オーダーが送信されると、[サービスのオーダーの確認(Service Order Confirmation)] ページに、バンドルに含まれていたすべてのサービスがリストされます。 バンドルのオーダーをキャンセルする必要がある場合は、バンドルに含まれる個々の子サービスはキャンセルできないため、オーダー一式をキャンセルする必要があります。
      • スケジュール:Service Catalog は、オーダーを、要求にある要求エントリの他のセットのように扱います。次をスケジュールします。
        • 親サービスに定義された承認および確認手順。この手順では、子サービスに定義された承認がオーバーライドされます。
        • サービスごとの提供計画タスク。
        • サービスごとの計画モニタリング タスク。
      • 提供:それぞれの子サービスの提供計画は、子サービス自体がオーダーされたように実行します。 ただし、子サービスの提供計画タスクのスケジューリングは、親サービスの提供計画内にある子サービス用の包含タスクのポジションによって左右されます。 たとえば、親サービスによって子サービスである LAN ID、デスクトップ、および新しい電話機がリストされると、タスクはそのオーダーで完了されます (これは、提供計画で、トップレベルのタスクを順次に完了するように選択したことを想定しています。 子サービス用の提供計画を同時に実行する場合、この設定を変更できます。)
      • モニタ:Service Manager ユーザが計画をモニタする場合、Service Manager の [計画(Plan)] タブで、任意のサービスの計画モニタリング タスクを確認できます。 親サービスの計画モニタリング タスクには、子サービスごとに包含タスクが表示されます。 サイト設定パラメータ [タスクリンクの表示(Show Task Link)](管理モジュールの [サイトを個人設定する(Personalize Your Site)] フォルダで入手可能)は、[オン(On)] に設定されており(デフォルト)、[計画(Plan)] タブに表示されているタスクは実際のタスク フォームにリンクされます。 包含タスクについては、これらのリンクを使用することで、包含サービスの計画モニタリング タスクに移動できます。

      次の表は、サービス バンドルに実行できるさまざまなタスクを示します。

      表 7 サービスをバンドルするためのタスク

      タスク

      手順

      説明

      バンドルの作成

      バンドルを作成するには、以下の手順を実行します。

      1. [Service Designer] > [サービス(Services)] > [オファー(Offer)] > [バンドル(Bundle)] の順に選択します。
      2. [このサービスはバンドルです(This service is a bundle)] を選択します。 Service Designer はバンドル内のバンドルされたサービスをサポートしないため、システムは自動的に [このサービスはバンドルに含めることができません(This service cannot be included in a bundle)] オプションを選択します。

      [サービスを含める(Include Service)] ボタンが有効になります。

      サービスをバンドルに追加したら(子サービスにしたら)、Service Designer は 2 つのチェック ボックスを無効にして、代わりに、サービスが含まれているバンドルのリストを表示します。

      1. [サービスを含める(Include Service)] をクリックします。 [サービスの選択(Select a service)] ダイアログボックスが表示されます。 このダイアログボックスには、[このサービスはバンドルに含めることができません(This service cannot be included in a bundle)] オプションがオフになっているサービスのみがリストされます。
      2. バンドルに含めるサービスを選択して、[サービスを含める(Include Service)] をクリックします。 子サービスが、[オファー/バンドル(Offer/Bundle)] サブタブの [次を含む(Includes)] セクションに表示されます。 親サービスの詳細情報の一部として、子サービスが「My Services」に表示されます([包含サービス(Included Services)] サブタブ)。
      3. ステップ 3 とステップ 4 を繰り返して、他の子サービスをバンドルに追加します。

      Service Designer で、親サービスとして使用するサービスを選択することから開始するか、親として機能する新しいサービスを作成します。 サービスを選択したら、[オファー(Offer)] タブをクリックして開始します。 バンドルに組み込む子サービスをすでに作成していることを前提にしています。

      他のサービスとバンドルとの関連付け

      他のサービスをバンドルに関連付けるには、次の手順を実行します。

      1. [Service Designer] > [サービス(Services)] > [オファー(Offer)] > [バンドル(Bundle)] の順に選択します。
      2. [前提条件(Pre-requisites)] テーブルの [前提条件の追加(Add Pre-requisites)] をクリックします。
      3. サービスを選択し、[追加(Add)] をクリックします。

      代替方法:

      1. [Service Designer] > [サービス(Services)] > [オファー(Offer)] > [バンドル(Bundle)] の順に選択します。
      2. [推奨されるアクセサリ(Recommended Accessories)] テーブルの [アクセサリの追加(Add Accesories)] をクリックします。
      3. サービスを選択し、[追加(Add)] をクリックします。

      [前提条件(Prerequisites)] と [推奨されるアクセサリ(Recommended Accessories)] を使用して、サービス設計者は追加サービスを現在のサービスに関連付けることができます。 これらのオプションは、バンドルされたサービスと、バンドルされていないサービスの両方に指定できます。

      • [前提条件(Prerequisites)] は、このサービスをオーダーする前に必要な他のサービスです。 たとえば、カスタマーはソフトウェアのインストールをオーダーする前に、コンピュータを購入して、インストールしておく必要があります。
      • [推奨されるアクセサリ(Recommended Accessories)] はサービスへのアドオンとして推奨される他のサービスです。 たとえば、サービスが携帯電話に関するものである場合、推奨されるアクセサリとしてヘッドセットやケースなどがあります。

      サービスに前提条件または推奨されるアクセサリがある場合、My Services にあるサービスの詳細説明の右側に、対応するリンクが表示されます。

      どちらのオプションにも、関連付けられている動作はありません。リストされる前提条件サービスまたはアクセサリは個別にオーダーする必要があります。 これらはオプションですが、エンド ユーザに役立つ可能性があります。

      バンドルの回避

      サービスのバンドルを行えないようにするには、次の手順を実行します。

      1. バンドルされないようにするサービスを選択します。
      2. [Service Designer] > [サービス(Services)] > [オファー(Offer)] > [バンドル(Bundle)] の順に選択します。
      3. [このサービスはバンドルに含めることができません(This service cannot be included in a bundle)] オプションを選択します。

      他のサービス設計者がサービスをバンドルに含めることができないようにするには、以下の手順を実行します。 この方法でマークを付けたサービスは、子サービスを選択したときに、[サービスの選択(Select a service)] ダイアログボックスに表示されません。

      子サービスの順番の変更

      子サービスの順番を変更するには、以下の手順を実行します。

      1. [次を含む(Includes)] セクションで、移動するサービスのチェック ボックスをクリックします。
      2. 上矢印または下矢印のアイコンをクリックして、サービスを移動します。

      必要であれば、サブタスク条件式の 1 つで「オプト アウト」シナリオを実行することができます。 この場合、子サービスはまだオーダーされているように見えます(すべてのタスクはスキップされます)。

      包含タスク名の変更

      包含タスク名を変更するには、次の手順を実行します。

      1. [Service Designer] > [サービス(Services)] > [計画(Plan)] の順に選択します。
      2. タスク名をクリックします。 [全般(General)] タブがタスクの情報とともに表示されます。 [タスクタイプ(Task Type)] には、タスクが包含サービスであることが示されます。 [サービス名(Service Name)] は、包含タスクが表すサービスを示しています。 (包含タスクの名前を変更する場合は、この情報が重要になります)。
      3. [タスク名(Task Name)] フィールドに新しいタスク名を入力して、[更新(Update)] をクリックします。

      組み込み参加者の確認

      バンドル内の組み込み参加者を確認するには、次の手順を実行します。

      1. 親サービスを選択します。
      2. [計画(Plan)] タブをクリックします。
      3. [参加者(Participants)] サブタブをクリックします。

      バンドルに追加する各子サービスに対して、Service Designer は親サービスの提供計画に参加者情報を自動的に割り当てます。

      [参加者(Participants)] タブ上の情報は、子サービスのプロジェクト マネージャから取得されます。 Service Designer は、子のプロジェクト マネージャとして現在定義されているものであれば何でも使用して、タスクの実行者とスーパーバイザの両方を自動的に割り当てます。 子サービスのプロジェクト マネージャを変更すると、その変更内容は包含タスクに対して動的に反映されます。

      Service Designer は包含タスクの実行者に Subplan Manager という名前を付けます。 スーパーバイザには Plan Manager という名前を付けます。

      バンドルの価格設定

      バンドルの価格には、それぞれの子サービスで定義されているように、各包含サービスの価格が含まれています。 サービスの [オファー(Offer)] タブにある [価格設定(Pricing)] サブタブで、任意のサービスの価格を設定します。 全体としてバンドルに適用されるか、そのコンポーネント サービスに適用されるアクティブ フォーム コンポーネント ルール内の価格設定アクションを使用して、価格は潜在的に調整される可能性があります。

      便宜上、バンドルされたサービスを作成するときに、各子サービスの価格は親サービスの [オファー(Offer)] タブにある [バンドル(Bundle)] サブタブにリストされます。 子サービスの価格が必須の価格として定義されている場合、システムはそのサービスに対する価格設定ステップを、My Services ユーザがバンドルをオーダーした時点でスケジュールします。

      バンドルの値引き

      バンドルを値引きするには、次の手順を実行します。

      1. [Service Designer] > [サービス(Services)] > [オファー(Offer)] > [バンドル(Bundle)] の順に選択します。
      2. [サービス(Services)] パネルから、親サービスをクリックします。
      3. [オファー(Offer)] タブをクリックしてから、[価格設定(Pricing)] サブタブをクリックします。
      4. 価格に対する値引き値を入力します。 たとえば、サービス バンドルを 1000.00 ドル分値引きするには、–1000.00 を入力します。
      5. [すべての設定の保存(Save All Settings)] をクリックします。

      バンドルの価格は、次の 2 つの方法のいずれかで値引きできます。

      • アクティブ フォーム コンポーネント ルールで使用可能な価格設定アクションを介した動的価格設定を使用して、サービスがバンドルで使用されている場合に、その価格を下げます。
      • 親サービスの [価格設定(Pricing)] サブタブを使用します。 ここで、親サービスに対して値引き価格を設定できます。これは、包含サービスの総コストから減算される数値です。

      たとえば、すべての子サービスのコスト合計が 5,000 ドルである場合に、親サービスに対する値引き価格として 1000 ドルを入力すると、バンドルの正味コストは 4000 ドルになります。 これを行うことで、各サービスを個別にオーダーするのではなく、バンドルされたサービスをオーダーするようにエンド ユーザに働きかけます。

      カスタマーはバンドルの [オーダー(Order)] をクリックした後にのみ、価格が値引きされていることを確認できます。 値引きの情報を前もってカスタマーに知らせる場合は、サービスの [全般(General)] タブにある [説明(Description)] フィールド、または [オファー(Offer)] タブ/[価格設定(Pricing)] サブタブにある [説明(Description)] フィールドを使用して、バンドル サービスを選択した場合の金銭的な利益を簡単に強調します。

      オーダー フォームでの表示パラメータの制御

      [管理(Administration)] > [ホーム(Home)] > [サイトを個人設定する(Personalize Your Site)] > [カスタマイズ(Customizations)] > [Service Manager] > [バンドルデータの表示(Show Bundle Data)] の順に選択します。

      システムによってバンドルされたサービス用の複合オーダー フォームが作成されるときに、重複するディクショナリは削除されます。 つまり、あるディクショナリが親サービスと、その親の子サービスの 1 つ(または複数の子サービス)に関連付けられている場合、システムは、バンドルされたサービス オーダー フォーム上に、そのディクショナリの最初のインスタンスのみを表示します。

      サービス フォーム データを表示するには、次の 2 つのオプションがあります。

      • [ShowBundleData] = [オン(On)](デフォルト)は、いずれかの子サービスの中で作業項目を処理するときに、サービスの実行者にバンドルの複合オーダー フォームを表示します。
      • [ShowBundleData] = [オフ(Off)] は、サービスの実行者に、彼らが処理する子サービスからのディクショナリのみを表示します。 システムは、バンドルされたサービスのデータが、そのディクショナリのすべてのインスタンスで 1 つのディクショナリ用に入力されたデータを複製していることを確認します。 このため、子サービスからのディクショナリが元のオーダー フォームで抑制された場合(親サービスのディクショナリを複製したため)、子サービスのみを処理するサービス実行者にもカスタマーによって入力されたデータが表示されます。

      包含タスクの確認

      バンドル内の包含タスクを確認するには、次の手順に従います。

      1. [サービス(Service)] パネルから、親サービスを選択します。
      2. [Service Designer] > [サービス(Services)] > [計画(Plan)] の順に選択します。

      子サービスには、「Deliver Included Service service-name .という規則に従って、自動的に名前が付けられます。たとえば、サービスがDeliver Included Service Phonesのように表示される場合があります。

      バンドルに追加する各サービスに対して、Service Designer は親サービスの提供計画にタスクを自動的に挿入します。 このタスクを、包含タスクと呼びます。

      包含サービス タスクは、大部分の提供計画タスクと同じように機能しますが、以下の点が異なります。

      • 包含サービス タスクを削除することはできません。 [計画(Plan)] タブの [削除(Delete)] ボタンは無効です。 このタスクを削除するには、バンドルから対応する子サービスを削除します。
      • [期間(Duration)] の値は設定できません。 これらは、子サービスの提供計画から、合計期間として算出されます。
      • [タスクタイプ(Task Type)] は編集できません。 これは、デフォルトで [包含サービス(Included Service)] に設定されています。
      • チェックリストの作成または関連付けは行えません。 タスクに [チャックリスト(Checklist)] タブがありません。
      • [参加者(Participants)] タブの情報を編集できません。

      タスクには自動的に「Deliver Included Service service-nam e」という名前が付けられますが、必要であればタスク名を変更できます

      また、包含タスクの 1 つを別の包含タスクの下に入れることで、タスク/サブタスクの関係に配置することもできます。 ただし、両方のサービスの提供は、同時に開始します。

      バンドルの子サービスのキャンセル制限

      サービス バンドルのタスクが開始した後にカスタマーがサービスをキャンセルできないようにするには、次の手順を実行します。

      1. [Service Designer] > [サービス(Service)] > [計画(Plan)] の順に選択します。
      2. タスク テーブルからタスクを選択します。
      3. [全般(General)] サブタブの [タスクの開始後のキャンセルを許可しない(Do not allow cancellation of service after task starts)] チェック ボックスをクリックします。

      カスタマーは、オーダーした後にバンドルを取り消せます。 バンドルを取り消すと、含まれているすべてのサービスも取り消されます。 個々の子サービスを取り消すオプションは、[要求の編集(Edit Requisition)] ページでエンド ユーザに対して無効になっています。 Service Designer は基本的に、カスタマーがサービスを取り消すための「取り消し限界点」を定義します。 このオプションは、サービスのバンドル全体またはその中の個々のサブタスクに対しオンにできます。 ただし、この限界点がバンドル内のサービスのいずれかで到達されると、カスタマーはバンドルをキャンセルできません。

      Service Designer のサービスの [計画(Plan)] タブにある [全般(General)] サブタブの [タスクの開始後のキャンセルを許可しない(Do not allow cancellation of service after task starts)] チェック ボックスによって、カスタマーがサービスを取り消すための「取り消し限界点」が原則的に定義されます。 このオプションは、バンドル全体に対してオンにすることも、含まれている個々の子サービスに対してオンにすることもできますが、バンドル内のいずれかのサービスがこの限界点に達したら、バンドルを取り消せなくなります。

      また、バンドル内のいずれかのサービスまたはサブタスクが「取り消し限界点」に達した場合、サービス オーダーの [キャンセル(Cancel)] ボタンが削除されます。


      (注)  


      名前空間の使用については、名前空間を参照してください。

      バンドルのカスタマー ビュー

      Service Catalog でバンドルをオーダーするには、サービス名をクリックしてサービスの詳細を表示し、[詳細(Details)] ページの [包含サービス(Included Services)] をクリックしてバンドルに含まれているすべてのサービスを確認します。

      そのサービスに関連する特定の詳細を参照するには、各サービス名をクリックします。 ここで、[サービスのオーダー(Order Service)] ボタンの代わりに [サービスバンドルに戻る(Return to Service Bundle)] ボタンが表示され、バンドル全体をオーダーしなければ、子サービスがバンドル内からオーダーできないことを意味しています。 サービスを個別にオーダーするには、サービス カタログに戻ります。

      バンドルをオーダーすると、[オーダーの確認(Order Confirmation)] ページに、子サービスごとの実行期日とともに、バンドル内のすべてのサービスの名前が表示されます。

      [トラック解決(Track Resolution)] ページには、バンドル内のすべての子サービスのリストが表示されます。 オーダー フォームを表示し、実行されているとおりに、サービスごとの提供プロセスを表示するには、リンクをクリックします。

      サービスをオーダーするためのサービス レベルの権限の定義

      [権限(Permissions)] タブには、どのユーザがこのサービスのオーダーを許可されているかが示されています。 サービスをオーダーするための権限を付与するには、次の手順を実行します。


        ステップ 1   参加者にオーダーを許可するサービスの [Service Designer] > [サービス(Services)] > [権限(Permissions)] タブを選択します。

        [サービスのオーダー(Order service)] は、サービス レベルで割り当てることができる唯一の権限です。これはすでに表示されています。

        ステップ 2   [参加者の追加(Add Participants)] をクリックして、ユーザ、組織単位、役職、グループ、役割を追加するか、任意のユーザにアクセスを許可します。
        ステップ 3   追加するエンティティ(1 つまたは複数)を検索して選択します。

        Organization Designer モジュールで(あるいは、実装されている場合はディレクトリ統合を使用して)以前に作成/定義されたユーザ、組織単位、役職、グループ、またはロールを検索して、選択できます。

        ステップ 4   [追加(Add)] をクリックして、選択したエンティティにサービスをオーダーする権限を付与します。

        「任意のユーザ」にアクセスを許可すると、Service Catalog の任意のユーザがこのサービスをオーダーすることができます。 本質的に完全にすべての人に共通で、すべてのカスタマー ベースに公開されているサービスについてのみ、任意のユーザを付与対象としてください。 「サイト管理」ロールは、定義によって、任意のサービスをオーダーする権限を持っています。