Cisco Service Portal 設計者ガイド リリース 9.3.2

Service Designer のコンポーネント

Service Designer モジュールを構成している主なコンポーネントは次のとおりです。

上記のすべてのコンポーネントは、Service Designer のすべてのユーザに表示されるわけではありません。Service Designer モジュールを選択したときに表示されるコンポーネントは、Organization Designer で付与されたロールに対応します。

Design Services の準備

サービスの設計は複雑なタスクですが、良く考えて計画することで、より簡単に実行できます。

必要な情報を事前に収集している場合、Service Designer でサービスを設計すると、より簡単にすばやく行うことができます。自分の組織、または設計を提供する組織のメンバーにインタビューを行い、企業内ですでに使用されているソフトウェア ツールのレビューを参照し、サービスの管理に現在使用されている書面のフォームや内部データ ソースを収集することで、可能な限り多くの情報を集めます。

次に、以下の準備作業を完了してから、Service Designer を使用します。

ステップ 1 提供するサービスに関する情報を収集します。

サービス カタログの実装を開始する前に、以下を把握しておきます。

• 提供するサービスの内容

• それらのサービスの提供者

• それらのサービスの使用者

• ユーザがサービスを購入するために必要な許可または確認

• サービス要求の許可または確認の権限を持っている人と、それらを実行する必要のある人の一方または両方。

• それらの許可および確認を管理するポリシー（グローバルまたはローカル）

• それらのサービスの提供を管理するサービス レベル

• サービスの提供における通常の過程の中で従うステップの内容

• それらの提供アクティビティを実行する人

• サービスの提供を管理する人

• サービスの提供が遅延または中断されたときに発生する事柄

• サービスを購入するためにコンシューマが提供する必要のある情報

• サービスの提供チームがユーザから得る必要のある情報

• 含める必要のある既存データ ソースの有無

• オーダー フォームのモデルとして使用できる既存フォームの有無

• サービスによって提供されるアセットまたは項目 サービスが提供された後に、これらの項目を追跡するかどうか

ステップ 2 Organization Designer および Administration で作業を開始します。

Service Designer でサービスを作成する前に、Organization Designer で以下の作業を完了することが重要です。

• サービス カスタマーおよびサービス提供チーム用に組織単位を作成します。

• これらの組織単位に配置するための人と作業のキューを作成します。

• ユーザの事業部門とサービス チーム用の役職を作成し、それらに人を割り当てます。システムは特定の組み込み型価格設定プロセスでこの役職を使用するため、事業部門とサービス チームの両方に関して管理者が割り当てられていることが特に重要です。

• ユーザ ロールを設定して、適切な機能と許可を各組織またはユーザに付与します。

Administration モジュールで以下を行う必要があります。

• 電子メール テンプレートを作成します。これは、タスクに承認やエスカレーションが必要な場合、またはサービス提供が一度完了した場合など、主なシステムの時点の間にユーザに送信されるように作成および設定される標準の電子メールです。これらの電子メール テンプレートは、後で Service Designer のサービスと関連付けられます。

ステップ 3 Service Item Manager でサービス項目を作成します（任意）。

Service Item Manager モジュール（Lifecycle Center のライセンスを持っているカスタマーのみ使用可能）を使用して、設計者は特定の項目を「サービス項目」として指定し、それらの履歴を Request Center 内で追跡することができます。サービス項目定義によって、サービスで使用されるディクショナリのテンプレートを作成できます。

ステップ 4 Service Designer で、ディクショナリとアクティブ フォーム コンポーネントを作成します。

• ディクショナリには、さまざまなアクティブ フォーム コンポーネント、または再利用可能なフォーム コンポーネントに使用されるフィールドが含まれています。

• フォーム コンポーネントは 1 つ以上のディクショナリ、各ディクショナリの使用方法を指定するアクセス コントロール ルール、サービス フォーム上でディクショナリとそれらのフィールドをレンダリングするための表示プロパティ、および各ディクショナリと特定のディクショナリ内の潜在的な個々のフィールドに関連付けられた動作ルールで構成されています。それぞれのアクティブ フォーム コンポーネントは一度のみ設定され、1 つ以上のサービス フォームに追加されます。

ステップ 5 Service Designer で、カテゴリ、キーワード、およびサービス グループを作成します。

理想的には、サービス グループ、カテゴリ、およびキーワードは、サービスを作成するときに一緒に指定すべきです。カテゴリとキーワードを作成して、サービスを作成した 後 にそれらをサービスに関連付けることもできますが、効率が良くありません。

完全なサービスとは

Service Designer モジュールを使用して、「完全なサービス」を作成できます。しかし、これは何を意味するのでしょうか。

「完全」なサービスとは、次のような、エンドユーザが把握する必要のあるすべての事柄を理解できるように非常にうまく定義されたサービスのことです。

• このサービスでオーダーするもの

• 含まれる内容

• 費用

• サービスの必要性 (または、自分に適したサービスであるかどうか)

• サービスのオーダー方法

• 提供までの所要時間

サービスには、次のような詳細情報がさらに含まれている場合もあります。

• サービス提供プロバイダーに対する追加のタスク指示

• サービス要求を実行するために完了する必要のある一連のタスクのチェックリスト

• サービスの提供が遅れた場合の条件付き文章を使用した安全策

完全なサービスでは、サービスの内容と、プロセスの各段階においてサービスの提供に関連して期待される事柄を明確に伝える必要があります。エンドユーザは、My Services に表示される情報を使用できる必要があります。同様に、サービス要求を受け取り、サービスを提供するサービス チームに対しても同じようにサービス定義とサービスに対する期待を明確に示す必要があります。

プロセスが直感的になればなるほど、エンドユーザが実施チームまたはサービス提供チームに質問しなければならない可能性は減ります。

主な用語

Service Designer を使用する際に熟知しておく必要のあるいくつかの主な用語を以下に示します。

この章の内容

前述の Service Designer の 7 つのコンポーネントについて、以下に示します。

この章では、サービス カタログの一部となるサービス定義を指定するためのメイン ツールであるサービス コンポーネントに重点を置きます。簡単に使用できるコンポーネントであるカテゴリとキーワードについても簡単に触れます。サービス設計者はこれらを使用して、My Services モジュールと My Services Executive モジュールで使用するために、検索語を使用してサービスをクロス参照できます。

この章に含まれない事柄

ディクショナリとアクティブ フォーム コンポーネントの設定は、通常、先行するアクティビティであり、サービスを定義するための前提条件です。ディクショナリとアクティブ フォーム コンポーネントの両方の定義と使用についての詳細は、「アクティブ フォーム コンポーネント」を参照してください。

スクリプトは、JavaScript 関数とライブラリであり、これらは動的に変化するサービス フォームの外観と動作の一方または両方でアクティブ フォーム コンポーネント ルールを補足できます。JavaScript 関数とライブラリ、対話型サービス フォーム（ISF）、ディクショナリおよびフィールドと対話するための JavaScript API の定義および使用について詳細は、「アクティブ フォーム コンポーネント」を参照してください。

名前空間とは、Request Center 内で使用されるデータ オブジェクトを処理する有効な名前のセットを記述するために使用される用語であり、これらのオブジェクトはサービス設計者に公開されます。これにより、設計者はこれらのエレメントを電子メールで使用し、受信者、件名、または電子メール本文内の参照を動的に解決できます。また、ワークフロー内で使用して、提供計画内の確認、承認、またはタスクを条件付きで実行したり、式内で使用して、承認または提供タスクの割り当て先となる人またはキューを決定したり、属性で使用して、タスクと承認を設定したりすることができます。使用可能な名前空間の完全なリストと、それらの使用法に関する詳細な説明については、「名前空間」を参照してください。

サービスの実施計画には、My Services Authorizations モジュールと Service Manager モジュール内で実行される承認および提供タスクのほかに、外部システムに委任する必要のあるタスクが含まれる場合があります。たとえば、ユーザは、ヘルプ デスクや他のシステムで処理する必要のある要求を Request Center に入力する場合があります。統合モジュールであるサービス リンクは、外部システムと通信する必要のある要求の設定を処理します。詳細は、『 Cisco Service Portal Integration Guide 』を参照してください。

堅牢な Request Center インストール済み環境では、組織、その構造、およびユーザに関する情報にアクセスして、適切なユーザ コミュニティがサービス要求を使用でき、実施計画が適切な組織と担当者に指定されるようにすることが必要です。組織の基本情報を設定することは、通常、サービスの開発よりも前に行う必要があります。このような前提条件アクティビティは、『 Cisco Service Portal Configuration Guide 』で説明されています。

サービスに対して目標を定義できますが、これらは Request Center では使用されません。むしろこれらは、ポートフォリオ用のコンポーネント サービスを指定するポートフォリオ設計者にとって有益です。目標についての詳細は、Service Designer のオンライン ヘルプで入手できます。

Request Center を使用して、サービス項目および企業資産を作成および追跡できます。これらは、一意に特定することができ、サービス要求を介してプロビジョニング、変更、または使用からの削除を行えます。サービス項目は、ディクショナリの設計に加え、サービスのタスク計画にも影響を及ぼす場合があります。サービス項目の設定と、サービス定義へのそれらの統合についての詳細は、「Lifecycle Center」を参照してください。

サービス グループの表示と検索

サービス グループは、Service Designer のサービス コンポーネントで作成および指定されます。すべてのサービス グループは、ページの左側にある [Services] パネルにアルファベット順にリストされます。次の作業を実行できます。

• サービス グループ名を選択して、そのサービス グループの詳細と設定タブを開く。

• サービス グループ名の横にある + アイコンを展開して、グループ内で「有効」なサービスを表示する。

サービス グループを追加するには、[Services] パネルの上部にある [New] ボタンをクリックして、[New Service Group] を選択します。

サービス グループの一般情報

サービス グループの指定には、以下の表に要約された情報を入力する作業が含まれます。

Service Team

サービス チームは、Organization Designer モジュールで作成および管理される組織単位です。

サービス グループに対して適切なサービス チームを指定することが重要です。「サービス チーム」は、ディクショナリのアクセス コントロールを設定するときに、デフォルトの参加者としてリストされます。これにより、サービス チームのメンバーは、サービス実施のサービス提供時点で、ディクショナリを表示および/編集できるようになります。サービス チームのすべてのメンバーは、サービス グループ内のサービスに定義されているすべてのタスクについて、何も設定しなくても、作業を実行できます。他のサービス チームがサービス内のタスクを実行するには、サービスに使用されているフォーム コンポーネントの [Access Control] サブタブで、[Additional Participants] としてリストされる必要があります。

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

• このグループのサービスで使用されているアクティブ フォーム コンポーネントに指定されている [Access Control] を再設定して、以前に指定したサービス チームに関連付けられたキューを [Additional Participants] のリストに明示的に追加する必要が生じる場合があります。これは、タスクがそのキューに割り当てられている場合に必要です。

• すべての人の役職への割り当てが削除されます。これは、サービス グループを所有するサービス チームのメンバーしか、そのグループ内の役職をこなせないからです。そのような割り当ては、すべて再指定する必要があります。

Functional Positions

役職は、次のいずれかに関連付けられたジョブの記述です。

• 組織単位

• サービス

• サービス グループ

Service Designer では、役職を承認、確認および提供の各プロセスでのアクティビティの実行者に割り当てて、人やキューを直接参照することを回避できます。役職を使用して、エスカレーション通知の受信者を特定することもできます。たとえば、電子メールを、特定の人やキューにルーティングするのではなく、特定の組織またはサービス グループの「エスカレーション管理者」に指定できます。あるいは、単にいくつかの役職を使用して、特定のサービス グループまたはサービスに責任のある人や他のエンティティを文書化することができます。

役職をサービス グループに追加するには、以下のようにします。

ステップ 1 [Add] ボタンをクリックします。

[Select Functional Positions] ダイアログが表示されます。

（注） ここに追加する役職は、システムにすでに存在する必要があります。それらは、Organization Designer にセットアップされて、選択できる必要があります。

ステップ 2 追加する役職の横にあるボックスをオンにします。

ステップ 3 [Add] をクリックします。

これで、サービス グループの役職に人を割り当てる準備ができました。役職は、関連付けられたサービス チームから配属されます。

サービス グループ内の人への役職の割り当て

人を役職に割り当てるには、以下のようにします。

ステップ 1 役職の行にある [...] ボタンをクリックして、[Select a Person] ダイアログ ボックスを表示します。

ダイアログ ボックスによって、サービス グループに関連付けられたサービス チームのメンバーである人に選択が限定されます。Organization Designer 内のサービス チームに人が割り当てられます。

ステップ 2 希望する人が見つからない場合は、検索機能を使用できます。上部のテキスト フィールドに有効な識別情報を入力するか、使用可能なすべての人を検索する場合にはアスタリスク（*）を入力して、[Search] をクリックします。

ステップ 3 人またはキューの横にあるオプション ボタンをクリックして、それらを選択します。

ステップ 4 [OK] をクリックします。

人の名前が [Assigned Person] 列に表示されます。

サービス グループの承認と確認

サービス グループの [Authorizations] タブを使用して、そのグループ内のサービスに対して、承認と確認のタスク、およびそれらが行われる指定済みの順番を設定します。サービス グループ内のサービスに対する遅延した承認/確認作業についてのエスカレーション層、受信者、および電子メール メッセージをカスタマイズすることもできます。

承認および確認構造は、サービス グループで設定して、そのサービス グループに含まれているすべてのサービスに構造を適用することも、個々のサービス レベルで設定することもできます。

サービス グループ レベルで承認構造を設定する場合、その構造を使用するサービス グループ内の 各サービスの [Authorizations] タブにある [Use service group authorization structure only] 設定を選択する必要があります。これを選択する利点は、同じ承認構造を共有するサービスの詳細を繰り返しすべて設定する必要がなくなるということです。

「承認」という語は、承認と確認の両方を含むプロセスを示すためにも使用される場合があります。

承認構造

サービス グループごとに、以下の 3 つのオプションから選択できます。

• Use service group authorization structure only（デフォルト）：サイト全体の承認構造のみを使用します。詳細は、『Cisco Service Portal Configuration Guide』の「Site Administration」の章を参照してください。サービス グループまたはサービス レベルで設定された承認と確認は無視されます。

• [Use service-level authorization structure only]（サービス グループ レベルは使用しない）：ロール、オーダーとエスカレーションの一方または両方の固有スキームに基づいて、承認構造を作成できます。

• [Use both service group-level and service-level authorization structures]：ロール、オーダー、エスカレーションの一方または両方のサイト全体のスキームを受け入れ、承認プロセスを拡張するために構築したカスタマイズ スキームを使用して、それを補足できます。

承認タイプ

サービス グループの承認タイプには、次の 2 つがあります。

• 承認 は、サービスを要求している人に、その要求を受ける資格があるかどうかを判別するための機会を承認者に提供します。承認が拒否されると、プロセスは停止し、サービスは提供されません。

• 確認 は情報のみです。確認者は、サービスを拒否したり、提供プロセスを取り消したりすることはできません。ただし、提供プロセスは、確認者が確認タスクで [OK] ボタンをクリックするまで進みません。

承認と確認のもう一つの大きな相違点は、承認は順番に実行されるのに対し、確認は同時に実行されるということです。複数のサービス グループの承認または確認を持ち、それぞれが異なる人によって実行されるようにすることができます。承認は指定した順序で順番に実行されます。つまり、前の承認者がサービス要求を拒否すると、そのサービス要求での作業はそれ以上行われなくなります。確認者はサービスの提供を取り消せないため、同時に実行することで、提供プロセスを効率的に処理します。

「not currently enabled via the Administration module」というメッセージが表示された場合は、特定のサービス グループの承認/確認がサイトで有効になっていません。これは、サイト全体の標準に関してサイト管理者が行った決定を反映している可能性があります。この設定は、Administration モジュールで変更できます。

サービス グループの承認の設定

サービス グループ承認に提供される必要のある構成の詳細情報は、サービス レベル承認を設定するために必要な詳細情報と同一です。これらは、同様に、提供計画タスクの設定に使用できる設定オプションのサブセットです。サービス グループ承認の設定についての詳細は、「提供計画の設定」を参照してください。

エスカレーション

エスカレーションは、承認、確認、または提供タスクが遅れた場合に、関心のあるパーティ（たとえば、要求者、スーパーバイザ、またはタスク実行者）に送信される必要のある通知と、通知セットを提供するためのスケジュールを指定します。エスカレーションは「層」で配置されます。たとえば、エスカレーションの最初の層は、サービス実行者に割り当てられたタスクが 1 時間遅れた場合に、その実行者に通知できます。2 番めの層は、エスカレーションの最初の層が実施された後、さらに 8 時間タスクが遅れた場合に、そのタスクに責任を持っているサービス チームのスーパーバイザに通知できます。

エスカレーションを受け取った人は、サービスを実行する許可を持たず、それを承認するか、そのエスカレーションが生成された元となったタスクを実行します。エスカレーションは通知のみであり、承認または提供タスクの所有権の移転や、現在の実行者の変更などは行えません。

Escalation Manager は、エスカレーションがトリガーされたときに電子メール通知を送信する役目を持つ、Request Center のソフトウェア コンポーネントです。デフォルトで、Escalation Manager は、標準的な月曜日から金曜日までの平日の午前 8 時から午後 9 時までの労働時間内に、1 時間に 1 回、遅れているタスクをチェックするように設定されています。エスカレーション通知が週末にも提供されるようにするか、「平日」や「週末」の概念があいまいであるグローバルなインストール済み環境でエスカレーション通知を提供するために、システム管理者に依頼して、Escalation Manager がより頻繁に実行されるようにするか、追加日にも実行されるように変更できます。この手順の詳細については、『 Cisco Service Portal Configuration Guide 』を参照してください。

サービス グループの承認

サービス グループの [Permissions] タブを使用して、サービス グループのオブジェクト レベルの承認を設定します。これらのオブジェクト レベルの承認は、人、組織単位、グループ、役職、およびロールが実行できるアクションのタイプです。次の表は、付与できる許可のタイプを定義しています。

サービス グループ内のサービスを設計できるようにすると、ユーザは自動的にそのグループ内のサービスを表示できるようになりますが、グループ内のサービスをオーダーする権限は、個々に割り当てる必要があります。

サービスをオーダーする権限は、サービス レベルで割り当てることもできます。サービス レベルの許可は、オーバーライドはしませんが、サービス グループ レベルで割り当てられた許可を補足します。したがって、次のようにします。

• 同じセットのユーザが、サービス グループ内のすべてのサービスをオーダーする許可を持っている場合、サービス グループ レベルでオーダーの許可を割り当てます。これにより、時間が節約され、メンテナンスが容易になります。

• 異なるセットのユーザが、グループ内の異なるサービスをオーダーする許可を持っている場合、サービス グループ レベルですべてのサービスに対してユーザのみを割り当てて、サービス レベルでサービス固有のユーザを割り当てます。

• 個々の人に許可を割り当てる場合より、組織単位に許可を割り当てるほうがかなり効率的です。組織単位のすべてのメンバーが、許可を継承します。許可のセットを人の別個のセットに割り当てる必要がある場合、それらの人を 1 つのグループに入れるか、1 つのロールのメンバーにして、そのグループまたはロールに許可を割り当てます。単一のグループまたはロールのメンバーシップを使用するほうが、多数の人に割り当てられた許可を変更するより維持が非常に簡単になります。

サービス グループの削除

サービス グループが不要になった場合は、削除できます。サービスがまだ存在しているサービス グループを削除することはできません。サービスが存在する場合、それらを削除するか、他のサービスに転送してから、グループを削除します。

サービスの一般情報

新しいサービスを作成したら、[General] タブに情報を入力して、サービスの設定を開始します。

[General] タブは、エンドユーザがサービス カタログを参照するときに、コンシューマ エクスペリエンスに影響を及ぼすために主に使用されます。[General] タブを使用して、説明情報を組み込んでサービスのコンテキストを設定し、サービスのレポート機能と表示動作に影響を及ぼす重要な属性と設定を指定します。

設定を開始する場合は、このページのどこからでも開始できます。フィールドを完成させるための参考として、次の表を使用してください。

実行期日の予測

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

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

• サービスに関連付けられたすべての承認または確認 すべての初期予測では、これらの各承認に関連付けられた特定の期日を使用します。ただし、実行期日はすべての承認が算出された後、再計算されます。承認と確認の完了時刻における差異（通常、提供計画に指定したものより時間がかかる）により、非現実的な予測が行われる可能性があります。

• 提供計画に含まれたすべての条件付きタスク。タスクの実行を管理する条件式は、サービス提供時点にしか評価できないため、どの予測も条件付きタスクの実行を考慮できません。このため、実際には実行されていないタスクが含まれることによって、見積もりが水増しされる可能性があります。一方、見積もりは常に最悪のシナリオ（すべてのタスクを実行することを想定）であるため、サービス要求がより早い時期に実行されると、ユーザが予想外に助かることがあります。

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

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

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

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

サービスの表示と検索

サービスは、Service Designer の サービス コンポーネントに表示されます。このコンポーネントは、デフォルトで最初に Service Designer モジュールに入ったときに表示されます。

左側の [Services] パネルでツリー メニューを使用して、サービス グループを展開します（各グループの横にある + 記号をクリックする）。次に、サービス名をクリックして、フレームの右側に詳細を表示します。

サービスの簡易検索を行うには、以下の手順を実行します。

ステップ 1 [Services] パネルの上部にある [Search...] ボタンをクリックします。

[Select Service] ウィンドウが開きます。

ステップ 2 サービス名または名前の一部をテキスト フィールドに入力して、[Search] をクリックします。

検索ストリングにワイルドカード文字を使用する必要はありません。Request Center は、検索ストリングを名前に含むすべてのサービスを自動的に検索します。

ステップ 3 リスト結果から希望するサービスを選択し、[Select] をクリックします。

サービスのコピー

Service Designer には、サービス定義をコピーする機能があります。サービスをコピーすると、キーワードとカテゴリとのすべての関連に加え、含まれているアクティブ フォーム コンポーネントに対する関連など、完全なサービス定義がコピーされます。

サービス定義をコピーするには、サービス定義の [General] タブにある [Copy] ボタンをクリックします。[Copy Service] ポップアップ ウィンドウが表示されます。新しいサービスの名前を入力して、新しいサービス定義を入れるサービス グループを選択します。現在のユーザが「フォームの設計」を行う許可を持っているサービス グループのみを選択できます。

新しいグループにサービスをコピーしても、ターゲット グループのサービス グループ承認に影響は及ぼされません。これらは変更されません。

サービスのエクスポートとインポート

エクスポート/インポートは、主に、前のバージョンの Request Center に搭載されているバックグラウンド機能用に提供されています。これは、サービス定義をローカル ワークステーションにダウンロードし、サービス名を変更して、改定したサービス定義をインポートすることで、既存のサービスをコピー、つまり「クローン作成」することができます。サービスのクローン作成は、上述のとおり、「サービスのコピー」によって最も効率的に実行されます。

サービスのエクスポート/インポートを使用する手順は、次のとおりです。

1. サービスを設定します。

2. サービスをエクスポートします。

3. エクスポートした XML ファイルでサービス名を修正します。

4. 修正した XML ファイルをインポートします。

サービスのエクスポート/インポートは、あるサイトから別のサイトにサービス定義を転送することで実行できますが、これは推奨されません。エクスポートには、サービス定義の一部ではない人、OU、キュー、ロール、および他のエンティティへの関連が含まれます。サービスをインポートしても、これらのエンティティがまだ存在しない場合、ターゲット環境にそれらのエンティティは作成されません。エラー メッセージを出さずに、関連を単に除去するだけです。Catalog Deployer は、サイト間で Request Center のコンテンツを転送するための推奨ツールです。

サービスのエクスポート

サービスをエクスポートするには、次の手順を実行します。

ステップ 1 Service Designer で、 サービス コンポーネントを選択します。

ステップ 2 エクスポートするサービスを選択します。

ステップ 3 [General] タブから、[Export] ボタンをクリックします。

[Export Service] ウィンドウが表示されます。

ステップ 4 [File Name] リンクを右クリックして、[Save Target As] を選択し、希望する場所にファイルを保存します。

Service Designer は、XML フォーマットで希望する場所にサービスをエクスポートします。

サービスのエクスポート済み XML ファイルの編集

エクスポートした XML ファイルを編集するには、次の手順を実行します。

ステップ 1 XML ファイルを Windows のメモ帳などのプレーン テキスト エディタで開きます。

ステップ 2 次のように、ファイル内のサービス名を変更します。

XML ファイル内でサービス名を変更しなければ、インポート プロセスによって元のサービスが上書きされます。（XML ファイルの他のエレメントを変更することもできますが、この方法は推奨できません。無効な XML が生成された場合、インポートは失敗します。)

ステップ 3 [Save] をクリックして、編集した XML ファイルを保存します。

これで、編集した XML ファイルをインポートする準備が整いました。

サービスのインポート

以前に XML ファイルにエクスポートされ、ServiceDefinition が名前変更されたサービスをインポートできます。サービスは、一度インポートすると、希望どおりに編集できます。

サービスをインポートするには、次の手順に従います。

ステップ 1 サービス コンポーネントで、[New] > [Import] をクリックします。

[Import Data] ウィンドウが表示されます。

ステップ 2 [Import from file:] フィールドで、ファイル名（パスを含む）を参照するか、入力します。

以前にエクスポートされ、デフォルトの場所か、ローカル マシンの任意の場所に保存された XML ファイルしかインポートできません。

また、参照機能を使用してワークステーション上のファイルを選択することもできます。

ステップ 3 [Import] をクリックします。

インポートを確認するために、Service Designer に [Imported Data] 画面が表示されます。

ステップ 4 [OK] をクリックして、Service Catalog の画面をリフレッシュします。

インポートされたサービスが、XML ファイルに指定されたサービス グループに表示されます。

サービスの削除

サービスが以前に要求されたことがない場合、あるいはサービスからのすべての要求がシステムから消去された場合 のみ 、サービスが不要になればそれを削除できます。サービス要求がサービスに対して送信された場合は、それらの要求がすでに完了していても、サービスを削除できません。

オーダーに対してサービスを使用不可にしたい場合は、そのステータスを Inactive に変更できます。さらに、サービス設計者が非アクティブなサービスのリスト内を参照して目的のものを探さなくても済むように、サービスを別のサービス グループに移動すると便利になる場合があります。たとえば、zz_<Service Group> という名前のシャドー グループが非アクティブなサービスを安全に、独立して取得する一方、サービス グループの構造は維持されます。

他のタブの設定

[Offer] タブを使用して、次を行います。

• サービス バンドルを作成する

• 推奨される前提条件または推奨されるアクセサリ サービスを指定する

• サービスの価格を設定する

Request Center の動作は [Objectives] サブタブに関連付けられていません。Objectives は Demand Center によって使用されます。

サービス バンドル

[Bundles] サブタブを使用して、サービスをサービス バンドルの一部にするかどうかを示します。サービスのバンドルとは、サービスのグループであり、これらはバンドル（親）がオーダーされると自動的に要求されます。

バンドルの詳細は、「サービスのバンドル」を参照してください。

Pre-Requisites と Recommended Accessories

[Pre-requisites] と [Recommended Accessories] を使用して、サービス設計者は追加サービスを現在のサービスに関連付けることができます。これらのオプションは、バンドルされたサービスと、バンドルされていないサービスの両方に指定できます。

• [Pre-requisites] は、このサービスをオーダーする前に必要な他のサービスです。たとえば、カスタマーはソフトウェアのインストールをオーダーする前に、コンピュータを購入して、インストールしておく必要があります。

• [Recommended Accessories] はサービスへのアドオンとして推奨される他のサービスです。たとえば、サービスが携帯電話に関するものである場合、推奨されるアクセサリとしてヘッドセットやケースなどがあります。

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

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

サービスの価格設定

[Pricing] サブタブを使用して、サービスの概略価格設定と詳細コスト情報を設定します。サービス コストと価格は、サービスを提供するためのチャージバックの基盤として使用できます。

[Cost Details] を設定するときは、次の表を参考用に使用してください。作業が完了したら、[Update] をクリックすることを忘れないでください。

[Pricing Summary] を設定するときは、次の表を参考用に使用してください。作業が完了したら、[Save Pricing Summary] をクリックすることを忘れないでください。

価格設定オプションと動的価格設定

[Pricing Summary] に指定されたオプションによって、My Services のサービス [Overview] に価格情報がどのように表示されるかが決定します。[Pricing Required] オプションのみが、要求が送信された後に価格設定時点を挿入することで、サービスのワークフローに影響を及ぼします。この動作は融通が利かないため、価格を動的に決定する必要のある大部分の状況には適さない可能性があります。

柔軟性をより高めるために、サービス設計者は、サービスの価格を動的に設定するアクティブ フォーム ルールを作成できます。他のアクティブ フォーム ルールと同様、特定のサービス要求の価格を設定するルールは、承認、確認、提供サイクルの間のいつでも、条件付きで実行することができます。サービス要求の更新された「取引上の価格」は、My Services の [Requisition Status] ページに表示されます。

動的価格設定ルールはすべてのサービスに使用できますが、これは単に「動的に価格を設定する」だけのものではありません。このオプションと「固定」オプションを使用する唯一の利点は、カスタマーの期待に沿ってより適切に設定できるということです。

サービスの価格を動的に設定するためのルールの使用方法についての詳細は、「アクティブ フォーム コンポーネント」を参照してください。

カタログでのサービスのフォーマット設定

サービス カタログ内のサービスの外観は、サービスの [Presentation] タブで設定されます。次の内容が含まれています。

• イメージとサービスの関連付け

• テキストの入力。これに HTML フォーマットを含めて、サービスの説明をさらに追加することができます。

• 1 つ以上の外部リンク（URL）とサービスの関連付け

• フォーム内のどのセクションが表示されるかということと、それらが表示される方法の決定

イメージとサービスを関連付けるには、次の手順を実行します。

ステップ 1 サービスの [Presentation] タブをクリックします。

ステップ 2 [Select an image to insert] ボタンをクリックします。

次のように、[Select an image to insert] ダイアログ ボックスが表示されます。

ステップ 3 イメージがすでに Request Center にアップロードされている場合、そのイメージがリストされ、[View] アイコンをクリックすることでプレビュー表示できます。以前にアップロードしたイメージを選択するには、イメージをクリックしてから、[Add Selected Files] をクリックします。

ステップ 4 イメージがまだアップロードされていない場合は、[New document:] テキスト ボックスにその名前を入力するか、[Browse...] をクリックしてワークステーション上のイメージを見つけます。[Attach] をクリックして、イメージとサービスを関連付けます。

標準的な Web ページに配置できるほぼすべてのイメージを、サービスのカタログ表示に含めることができます。カテゴリ表示内でイメージに割り当てられるサイズは、68 pixel（幅）x 50 pixel（高さ）です。画像編集ソフトウェアを使用して、イメージのサイズとアスペクト比の一方または両方がそれらの寸法と一致しているかを確認できます。画像のサイズが正しくない場合、ブラウザによってサイズ変更され、ぼかし表示またはピクセル分解表示されることがあります。

[Service Details] セクションを使用して、追加の説明情報とサービスを関連付けます。どの説明入力データにも、HTML フォーマットを含めることができます。追加した HTML エレメントまたは JavaScript 関数さえも、エディタによって提供される [Source] ボタンを使用して HTML ソースを編集することで参照できます。

ステップ 1 コンテンツを表示（およびフォーマット設定）するセクションを次の中から選択します。

• Overview：ここに入力された情報は、ユーザがサービス名またはサービス アイコンをクリックして、サービスの [Overview] を表示すると、My Services に表示されます。

• More Details：ここに情報が入力されると、[My Services Overview] ページの [Overview] リンクのすぐ下に、[More Details] リンクが組み込まれます。この情報は、サービス情報の右側に表示されます（以下の画像に表示されている [IMPORTANT NOTE] が [More Details] セクションです）。

• Service Form: ここに入力された情報は、ディクショナリ モニタのすぐ下のサービス フォームの右側に表示されます（以下の画像の右下にある [Note] を参照）。

セクションの [Show] ボタンをクリックすると、ウィンドウの下の部分に HTML エディタでデータが取り込まれます。このツールバーの凡例については「HTML エディタのツール アセンブリ」を参照してください。

ステップ 2 複数のコンテンツ ペインを表示するように選択する場合は、フォーマット設定するセクションの名前をクリックします。

ステップ 3 必要であれば、URL を入力して、コンテンツ セクションの左右または下部に表示します。URL は、「http://」で始まる完全修飾にする必要があります。

ステップ 4 組み込まれている HTML エディタを使用して、テキストとグラフィックの一方または両方を入力およびフォーマット設定します（これは、デフォルトで選択されています）。

また、HTML コードを挿入するには、[Source] ボタンをクリックして、HTML 編集ツールを無効にし、コーディングを直接入力します。[Source] ボタンをもう一度クリックし、HTML エディタに戻って、レンダリングされた HTML コードを表示します。

ステップ 5 [Save] をクリックして変更を保存します。

サービス表示のプレビュー

手順を進める前に、My Services でサービス表示をプレビューすることを推奨します。

次の手順を実行します。

ステップ 1 [My Services] モジュールを選択します。

ステップ 2 サービスに移動して、作業をチェックします。

ステップ 3 [Service Designer] に戻って、サービスを選択します。

ステップ 4 必要な修正を行ってから、[Save] をクリックして変更を保存します。

ステップ 5 [My Services] に戻って、サービス表示が正しいことを確認します。

[My Services] と [Service Designer] の間を何度も行き来するより、Request Center を実行している 2 つのブラウザ ウィンドウを開いた方が簡単です。Service Designer サービスの [Presentation] サブタブを一方のブラウザで開いたままにして、もう一方のブラウザにサービスの My Services のオーダー ページを開きます。必要に応じて、サービス表示に変更を行います。[Save] をクリックして、変更を保存することを忘れないでください。[Save] をクリックするとすぐに My Services ページがリフレッシュされ、変更を確認できます。

中核概念

サービスの提供計画を設定するには、次の概念を明確に把握しておく必要があります。

• 名前空間 変数の使用と、式の設定（「名前空間」を参照）。

• 電子メール テンプレートの設定と使用（『 Cisco Service Portal Configuration Guide 』を参照）。

• 実行期限の算出

提供計画の作成には、次のようないくつかの手順が含まれています。

• サービスの提供プロセス用にプロジェクト マネージャを設定します。

• タスク名、期間、条件、優先順位、およびその他のパラメータなど、個々のタスクを設定します。

• タスクの実行者とスーパーバイザを指定します。

• タスクに関連する通知電子メールを指定します。

• タスク指示を設定します。

• タスクのチェックリストを作成します。

• タスク実行の順序、タスクの実行を同時に行うか連続して行うか、および共通のマイルストーンを共有するタスクまたは共通の通知要件を持つタスクの潜在的なグループ化など、タスクのワークフローを指定します。

[Plan] タブでの作業

サービスのワークフローを設計するには、サービスの利害関係者と数回の設計セッションを行う必要が生じる場合があります。サービスの設定と提供に関連するすべての人をインタビューして、タスク（または一連のタスク）の内容、サービスに電子メール通知が必要かどうか、および実行者、スーパーバイザ、および電子メール受信者を誰にするかなどを決定することが理想的です。要件が収集されたら、[Plan] タブを使用して、それらの要件に従うようにサービスを設定します。

Service Designer には、サービスのワークフローを構成するタスクと、それらのタスクが実行される順番を指定するための 2 つの補足的な方法が用意されています。

• [Tasks] サブタブではその名前が示すとおり、タスクを適切な順番でリストすることでタスクを定義します。サブタスクと親タスクは、プロジェクト マネージャのソフトウェアがプロジェクトと、プロジェクト内の成果物を示す方法とほとんど同じ方法で示されます

• Graphical Workflow Designer は描画ツールです。これを使用して、タスクとそれらの関係を示す図を描画できます。

[Plan] タブには、次のサブタブが含まれています。

• Tasks：[Tasks] サブタブはデフォルトで開きます。これを使用して、ウィンドウの上部にあるサービス提供計画のタスクを指定します。次に、ウィンドウの下部にある各タスクの詳細アクティビティを指定します。

• Escalations：[Escalations] サブタブを使用して、アクティビティが遅延したときに、実行者、スーパーバイザ、およびカスタマーに送信される電子メール通知を指定します。

• Graphical Designer：Graphical Workflow Designer では、提供計画を構成するタスクとサブタスク、それらが実行される順番、および実行を順次に行うか同時に行うかを指定する図を描画できます。

プロジェクト マネージャと「モニタ」タスク

すべての提供計画には自動的に 1 つの全体的なタスクが組み込まれており、これを使用して、指定されたプロジェクト マネージャは提供計画の進捗をモニタできます。

次の図には、「モニタ」タスク、つまり全体的な提供計画に関連する [Tasks] サブタブのフィールドがまとめられています。

提供タスク

次の表には、[Tasks] サブタブのフィールドがまとめられています。

提供計画のタスクごとに、[General]、[Participants]、[Email]、[Task Instructions]、および [Checklist] の各サブタブを移動して、タスク アクティビティと提供計画を定義します。

Request Center ワークフローの設計

Request Center には、提供計画を構成するタスクのワークフローを設計するための、2 つの方法が用意されています。

• [Plan] タブの中央にある [Task] 領域を使用してタスクを入力し、さらに、使用可能なボタン（[Indent]、[Outdent]、[Up]、[Down]）を使用してワークフローを設定することで、タスクが正しい順番で実行され、正しくグループ化されるようにします。

• [Graphical Designer] タブから使用できる Graphical Workflow Designer を使用して、タスク、コネクタ、およびサブタスクのグループ化を描画領域にドラッグ アンド ドロップすることで、ワークフローを描画します。

ワークフローはいずれかのツールを使用して設定できます。実際に、サービス設計者は Graphical Designer と、[Task] タブによって提供されるダイアログの間を切り替えながら行き来できます。Graphical Designer にはタスク用のワークフローが備わっており、そのプロパティ シートを使用することで、ユーザはタスクに関する大部分の一般情報と、実行者のロールを入力できます。タスクの実行に関連付けられた電子メール、チェックリスト、およびタスクの参加者など、個々のタスクの詳細は、[Plan] タブのサブタブを使用して入力する必要があります。

[General] サブタブ

[General] サブタブでは、タスクまたは一連のタスクの詳細な提供アクティビティを定義します。理想的には、詳細な提供アクティビティを作成するために、以下に示したフィールド内を移動できる必要があります。[Plan] タブに複数のタスクがリストされている場合は、設定するタスク名をクリックします。タスクが青色/灰色で強調表示されている場合、開始する準備が整っています。各タスクには、独自のサブタブのセットである [General]、[Participants]、[Email]、[Task Instructions]、および[Checklist] があります。

フィールド	説明
Workflow Type	デフォルトは、[Internal] です。これは、外部システムを使用して定義された Service Link 統合がなく、Service Item タスクがないサイト用に表示される唯一のオプションです。タスクが Request Center 内で実行される場合は、[Internal] を選択します。 タスクが外部アプリケーションで実行される場合（Request Center ないではない場合）、該当する [External] オプションを選択します。外部タスクの場合のみ、タスクを保存した後に、[Workflow Type] の横に省略（...）ボタンが表示されます（詳細は、「ワークフローでの外部タスク」を参照）。 Lifecycle Center の Service Item Manager モジュールを使用して、サービス項目を設計し、それらの項目を追跡する場合は、[Service Item Task] を選択します。サービス項目タスクについての詳細は、「ワークフロー内のサービス項目タスク」と「Lifecycle Center」を参照してください。 操作内容が Organization Designer の人またはキューの追加または更新である場合、[Directory Task] を選択します。詳細については、「ワークフロー内のディレクトリ タスク」を参照してください。
Create Agent	タスクを保存すると、[Create Agent] ボタンが表示されます。このボタンをクリックして、[Integration] ウィザードを使用します。詳細については、『Cisco Service Portal Integration Guide』を参照してください。 （注） 注意：[Integration] ウィザードは、Service Link エージェントの作成と変換を行えるロールを付与されたサービス設計者しか使用できません。 [Integration] ウィサードは、統合の実装に関連する多くのステップを自動化します。 これは、Request Center と Web サービスの間の統合を作成する場合にのみ使用できます。 [Integration] ウィザードは、Web サービス統合によって呼び出される WSDL とオペレーションを取得することで機能します。 統合の定義に基づいて、[Integration] ウィザードは次を作成します。 • 統合を実行するために外部タスクで使用できる Service Link エージェント • nsXML を Web サービスによって要求される SOAP メッセージに変換する変換機能 • 初期 Web サービス要求とその応答の両方に必要なすべてのデータに対するエージェント パラメータ • エージェント パラメータにマップされたフィールドを含むディクショナリ • エージェントのパラメータ値を保持するために作成されたディクショナリを含むアクティブ フォーム コンポーネント
Task name	タスクの簡単なタイトル。これは、Service Manager でタスクのサブジェクトとして表示されます。
Subtasks execute	トップダウン メニューを使用して、このタスクのすべての「子」タスクが実行される順番を選択します。1 つずつ順番に実行（順次）するか、同時に実行（並列）するかを選択します。 子タスク（サブタスク）が提供計画でアクティブ（進行中）になります。これらは、親タスクがアクティブになる前に完了する必要があります。 子タスクを順次に実行すると、サービス期間にそのようなすべてのタスクの期間が含まれるようになります。タスクを並列で実行すると、サービス期間にはすべての子タスクの最大期間が含まれるようになります。
Duration	システムによってタスクがアクティブ（開始）であると判断されてから、タスクが完了するまでの予想時間で、最も近い時間単位で見積もられます。 たとえば、ソフトウェア プログラムのインストールに 1 時間しかかからない場合、タスクの実行者のワークロードと優先順位は 2 営業日のコース全体にわたってさまざまである可能性があるため、その実行者に、タスクを完了するために 16 時間の期間を与えることができます。 [Duration] の値はカスタマーまたは実行者には表示されませんが、タスクの実行期日の算出に使用されます。
Effort	実行者がタスクを完了するのにかかった実際の時間であり、最も近い時間単位で見積もられます。たとえば、ソフトウェア プログラムのインストールに 1 時間かかる場合があります。[Duration] は「合計経過時間」であるのに対し、[Effort] は「タスクを実行した時間」です。 [Effort] の値はどのユーザにも表示されず、実行期日の算出にも使用されません。代わりに、内部生産性目標として使用されます。
Priority	タスクの優先順位を [Low]、[Normal]、または [High] に設定します。フラグ以外は、タスクの優先順位に関連付けられたシステム動作はありません。このフラグは、Service Manager で表示されます。 • 優先順位が [High] に設定されると、システムは、タスクが表示される [Service Manager] ビューに赤色の感嘆符を設定します。 • 優先順位が [Low] に設定されると、システムは、タスクが表示される [Service Manager] ビューに青色の下矢印を設定します。 • 優先順位が [Normal] に設定されると、Service Manager にフラグは表示されません。
Condition	特定の条件下でのみタスクを実行する必要がある場合は、タスクを実行するタイミングを指定する [Condition] フィールドに式を入力します。 詳細については、「条件」を参照してください。
Allow a scheduled start date	タスクを遅延タスクにするには、[Allow a scheduled start date] をオンにします。次に、[Start Date] フィールドの [Form] データで、以下のいずれかを行います。 • 日付と時刻を「YYYY-MM-DD HH:MM」のフォーマットで入力します。たとえば、「2006-12-23 13:30」のようになります（引用符が必要です）。 • あるいは、タスクの開始ポイントの日付と時刻を保持するのに使用するディクショナリ フィールドの名前を入力します。次の構文を使用します。 – Data.DictionaryName.FieldName（サービスのアクティブ フォーム コンポーネントのいずれかにあるディクショナリからのフィールド用）。 – ParentData.DictionaryName.FieldName（親サービスのディクショナリのいずれかからのフィールド用。バンドルされたサービスの場合）。 遅延タスクの詳細については、「スケジュールされた開始タスクの作成」を参照してください。
Form data for start date	[Allow a scheduled start date] オプションをオンにすると、開始日のフォーム データを入力して、[Validate] をクリックできます。
Evaluate condition when delivery phase starts	何らかの条件を指定した場合、このオプション ボタンをクリックして、その条件が評価される時期を示します。このサービスの提供時点が開始した時点で条件を評価する場合は、これを選択します。これは、提供時点が開始する前に、式を正しく評価するために必要な情報が使用可能になる必要があることを示します。
Evaluate condition when task becomes active	何らかの条件を指定した場合、このオプション ボタンをクリックして、その条件が評価される時期を示します。提供計画で提供プロセスがこのタスクに到達したときのみ、条件を評価する場合は、これを選択します。
Re-evaluate expressions as plan advances	この機能により、タスクに対する実行者の割り当てに加え、タスクの名前も、フォーム データに基づいて動的に変更できます。これは、タスク名と実行者の一方または両方の割り当てが、フォーム データを使用した名前空間式から導き出される必要があるように指定した場合に、提供プロセス中にフォーム データが変更されるときに便利です。 このフラグを設定すると、タスクがアクティブになったときに（提供計画全体が開始されるときではない）、式が評価されるように指定されます。 （注） 重要：タスクの実行者の再評価は、タスクの実行期日に影響を及ぼしません。提供時点が開始した後に、実行期日は再計算されません。
Do not allow cancellation of service after task starts	このボックスをオンにすると、このタスクがアクティブになった後に、カスタマーはサービスを取り消すことができなくなります。 たとえば、タスクによって提供チームに多大なコストが生じたり、簡単には元に戻せないアクションを行ったりする場合に、これをオンにします。 My Services の [Cancel] オプションは、提供チームがこのタスクを開始すると、非アクティブになります。
Display Effort sub-page on a delivery task	このボックスをオンにすると、提供タスクの [Effort] サブタブが Service Manager に表示されます。

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

提供タスク名

提供タスク名には、#Name# 名前空間を使用したサービス名を含めることができます。サービス データ（#Service.Data....#）も使用できます。フォームが送信されるときにすべてのタスクが作成されるため、指定した名前空間の値はオーダー時点で使用可能である必要があります。このプラクティスは推奨されません。

タスク名にフォーム データを使用すると、タスク実行者は Service Manager で、より簡単にタスクを識別できるようになります。ただし、これにより、タスクはタスク名によって自動的にグループ分けされなくなるため、レポート作成モジュールでいくつかの課題が生じます。たとえば、レポート設計者は、[Custom Groups] を使用して、そのようなタスクごとに集約する必要があります。また、管理者は、「contains」検索を行えるように Service Manager を設定しなければならない場合があります。これは、パフォーマンスに悪影響を及ぼす可能性があります。サービス設計者は、タスク名の一部としてフォーム データ名前空間を含める前に、慎重に検討する必要があります。

ワークフローでの外部タスク

デフォルトで、[Workflow] タイプのドロップダウン リストには、[Internal] という 1 つのエントリしか含まれていません。これは、そのタスクが Service Manager モジュール内で実行されることを示しています。統合専門家が Service Link モジュールを使用して外部システムと統合する「エージェント」を定義した場合、各エージェントに関連付けられたアクションもドロップダウン リストに表示されます。たとえば、「SAP Integration」エージェントのワークフロー タイプが「Send data to SAP」のように表示される場合があります。Remedy と統合されるエージェントのワークフロー タイプは「Send Ticket to Remedy」のように表示される可能性があります。

Service Link と統合されるサービスおよびタスクの詳細については、サイト管理者に連絡してください。

外部タスクの場合のみ、タスクを保存した後に、[Workflow Type] の横に省略（...）が表示されます。

Service Link モジュールに対して適切な許可を持っている場合、[...] ボタンをクリックして、[Agent Parameter Override] ダイアログ ボックスにアクセスできます。このダイアログ ボックスには、外部システムに送信されるデータが、サービス フォームのフィールド、または要求に関する他のデータにどのようにマップされるかを示す設定が含まれています。これらの設定を変更する許可を持っている場合、ダイアログ ボックスは編集可能です。それ以外の場合は、読み取り専用です。

ワークフロー内のサービス項目タスク

Service Item Manager モジュール（Lifecycle Center のライセンスを持っているカスタマーのみ使用可能）を使用して、設計者は特定の項目を「サービス項目」として指定しし、それらの履歴を Request Center 内で追跡することができます。典型的なサービス項目として、ラップトップ、デスクトップ、ソフトウェア ライセンス、または固有に識別でき、それらの使用法（および所有権）を追跡する必要のあるすべての企業資産が挙げられます。

サービス項目タスクは、サービスにサービス項目ベースのディクショナリ（SIBD）が含まれている場合にのみ使用できます。サービス項目タスクを設定するには、次の手順に従います。

ステップ 1 [Workflow Type] として [Service Item Task] を選択します。

ステップ 2 計画を保存します。

ステップ 3 [Workflow Type] の横に表示される省略形をクリックします。[Service Item Task Parameter] ポップアップ ウィンドウが表示されます。

ステップ 4 使用する SIBD と、適用する操作（[Create]、[Update]、または[Delete]）を選択します。次に [OK] をクリックします。

サービス項目とサービス項目タスクの詳細については、「Lifecycle Center」を参照してください。

ワークフロー内のディレクトリ タスク

ディレクトリ タスクを使用して、フォーム データを使用する人およびキューの追加または更新を実行するための操作を呼び出せます。操作が失敗すると、タスクには完了のマークが付けられ、エラー メッセージがサービス フォームに書き込まれます。

次の操作がサポートされます。

必須フィールドを含むフリー フォームのディクショナリをディレクトリ タスクで使用できます。操作によって返されたエラーを算出するために、ディクショナリには「ErrorDescription」という名前のテキスト フィールドも含まれている必要があります。オーダー時点の間はこのフィールドを非表示にし、このフィールドの値を使用してエラー処理用の手動タスクを条件付きでトリガーすることを検討します。

ディレクトリ タスクを設定するには、次の手順に従います。

ステップ 1 [Workflow] タイプとして [Directory Task] を選択します。

ステップ 2 計画を保存します。

ステップ 3 [Workflow Type] の横に表示される省略形をクリックします。[Directory Task Parameter] ポップアップ ウィンドウが表示されます。

ステップ 4 使用するディクショナリと、適用する操作を選択します。次に [OK] をクリックします。

ディレクトリ操作の必須フィールドとオプション フィールドを以下にリストします。

条件

提供計画の設定に式を使用することは、汎用的で強力な機能です。条件付きステートメントにより、条件に使用されている式が True（このタスクを含む）か False（このタスクをスキップする）のどちらに評価されるかに基づいて、タスクを開始したり、スキップしたりできます。式は、「名前空間」に記載されている名前空間と演算子を使用して作成されます。

式を入力した後、[Validate] をクリックして、その式が正しいことを確認します。[Validate] ウィンドウが表示されます。Service Designer は、式の構文が正しいか、エラーを含んでいるかをここに示します。

「unexpected token」というメッセージは、使用されている名前空間がこのコンテキスト内で無効であるということか、アルファベット文字を引用符で囲むのを忘れた可能性があるということを示します。

検証では、ディクショナリ フィールド（Data. DictionaryName.FieldName ）を除いて、指定した名前空間が現在の範囲（確認、承認、またはタスクの特定のレベル）で有効であるかをチェックします。ただし、指定した名前空間（たとえば、Data.EUIT_ACCESS.Access_Type）が存在しない場合、ランタイム エラーが生じる場合があります。

検証では、正しい関係演算子と算術演算子が使用されているかどうかもチェックされます。

条件が入力された場合、ステートメントが評価される時期を決定する必要があります。各タスクの条件（承認、確認、または提供）は、いずれかの時期に評価できます。

• 段階（承認または提供時）の開始時

• アクティビティがアクティブになったとき。

承認/提供段階の開始時に条件を評価

設計者が、指定したタスクで [Evaluate condition when delivery phase starts (if condition evaluates to "false", times will be computed as zero)] オプションを選択すると、その 段階 の開始時に条件文が評価されます。「段階」とは、要求を処理するために定義されたシステムの任意のタイミングに対応しています。承認または確認にはそれぞれ固有のタイミングがあり、すべての提供タスクはサービス提供時に実行されます。

承認タスクは常に 1 つずつ実行されます。たとえば、field= "somevalue" で別の条件が field<> "somevalue" のように、1 つのタスクに 1 つの条件を配置できます。このように、常に承認タスクが 1 つ実行され、[when authorization phase starts] を選択すると、プロセス ビューには承認タスクが 1 つだけ表示されます。[when task becomes active] を選択すると両方のタスクが表示されますが、1 つはスキップされます。

[if conditions evaluate to "false", times will be computed as zero] 文は、Service Portal が段階の開始時に条件を評価することを表しています。これらの条件が満たされなかった場合は、対応するタスクが実行されず、サービスの [Due Date] はこれらのタスクの実行期間を含まずに計算されます。

アクティビティがアクティブ時に条件を評価

一方、設計者が [Evaluate condition when activity becomes active (times will not be affected, scheduling will be done by using these efforts)] オプションを選択すると、タスクの開始時に条件文が評価されます。

Request Center は、各タスクの開始時に条件を評価します。条件が満たされなかった場合は、対応するタスクが実行されません。このオプションが設定されたすべてのタスクの実行期間は、送信時の期日の計算に使用されます。

計画進行時の式の再評価

式の再評価機能は、複数の順次承認またはタスクが存在する設計で役立ちます。これを使用すると、タスクの実行者は、後続のタスクの実行者を割り当てるために使用される式の再計算に使用されるサービス フォームに情報を入力できます。このオプションをオンにしなかった場合は、承認タスクの式で使用されるすべての情報が、注文時に指定されている必要があります。

この機能により、ユーザ（人またはキュー）へのタスクの動的割り当てと、タスク タイトルの動的調整を行えます。タスクがアクティブになると、式が評価され、タスクが適切に割り当てられます。

ヒントとテクニック

自動的にスキップされるタスクを指定する条件文では、常に False と評価される条件（「1=2」など）を使用します。

この最も一般的な使用例には、次のものがあります。

• いずれかのタスクが完了してなくても、サービスが「自動完了」する必要がある場合。スキップされるタスクは、提供計画内の唯一のタスクです。これがスキップされると、要求には完了のマークが付けられます。

• タスクが完了しなくても電子メールを送信する必要がある場合、または次のように、あるタイミングで複数の電子メールが必要な場合。

– 親タスクを作成する。[Email] サブタブで、完了時に送信される電子メールを選択します（アクティビティがアクティブになったときに、通知が出されるように設定することもできます）。

– 条件 1=2 で子タスクを作成する。アクティビティがアクティブになったときに条件が評価されるように設定します。

Graphical Workflow Designer

Graphical Workflow Designer を使用して、サービス設計者はタスクのドラッグ アンド ドロップ、命名、接続を行えます。Graphical Designer には、タスク間で親/子関係を定義する機能も備わっています。付属のタスク プロパティ シートを使用して、タスク定義と実行に関する詳細をさらに指定できます。

Graphical Designer には、提供計画の [General] サブタブで提供されているダイアログを使用することで、サービス提供計画を設計するための、ビジュアル指向の代替策が用意されています。設計者はタスクを定義して、いずれかの方法を使用してそれらの間のワークフローを指定し、Graphical Designer とダイアログの間を自由に切り替えて行き来することができます。

Graphical Designer には、提供計画の簡略ビューがあります。計画についてさらに詳細に設定するには（[Participants]、[Email]、[Task Instructions]、および[Checklist] サブタブで使用可能なものを設定するには）、[Plan] タブに切り替えます。

概要

Graphical Designer には、以下のセクションがあります。

• 左上の ツール ペイン には、Workflow Designer の構成要素が含まれています。これらの構成要素を作業領域にドラッグ アンド ドロップして接続し、完全なワークフローを作成できます。

• ツールバー には、提供計画の保存、計画の印刷、および作業領域のコンテンツの操作を行うためのボタンが含まれています。

• 作業領域 には、ワークフロー図が含まれています。新しい提供計画のために Designer が呼び出されると、計画の開始を示す明るい緑色の円を除き、作業領域はブランクになります。

• ページの左側の中央にある アウトライン ペイン には、図の大まかな概要が示されます。

• 左下にある表示ツールの [Zoom/Layout] ボタンを使用して、設計者は、ワークフロー図のサイズを拡大または縮小したり、図の方向を変えたりすることができます。

Graphical Designer のツールバー

作業領域の上部にあるメニュー バーには、以下に要約されているオプションが含まれています。

凡例には、ワークフロー図に含まれているオブジェクトを表すために使用されるカラー コーディングがリストされます。

[Tools] パネル

[Tools] パネルには、ワークフローを構成するオブジェクトの基本タイプを図に追加するためのツールが含まれています。

[Tools] パネルのオプションに加えて、コンテキスト依存型のタスク カーソルを使用して、図の内容を操作するのに役立てることができます。図に以前に配置したタスクの上にカーソルを合わせると、カーソルの形が変わり、どのアクションが使用可能であるかが示されます。

表示ツール

[Zoom] および [Layout] ボタンを使用して、図のサイズと方向を操作できます。最初のタスクを一番上に置き、後続のタスクをその下に置いて、図を縦方向に配置できます。あるいは、最初のタスクを左側に置いて、後続のタスクがその右側に表示されるように配置できます。

Graphical Designer を介した提供計画の作成

Graphical Designer を使用して提供計画を作成するには、Service Designer でサービスを編集し、[Plan] タブをクリックしてから、[Graphical Workflow] サブタブをクリックします。作業領域には、[Start Workflow] アイコンのみ表示されます。

タスクの定義

通常、最初のステップはタスクをワークフローに置くことです。（[Tool] パネルから）[Task] ツールをクリックし、それを作業領域までドラッグします。タスクが表示されます。タスクをダブルクリックして、作業領域の下部に [Task Properties] ダイアログを表示します。

図 1-1 [Task Properties]：黄色のアラート アイコン

[Task Properties] ウィンドウには、タスクの [General] サブタブに表示されるすべてのデータと、主に設計セッションで便利な [Performer Role Name] が含まれています。ここに表示されているフィールドの詳細については、「[General] サブタブ」を参照してください。ここでタスクのワークフローの定義を開始できますが、タスク定義を完了するには、タスクごとに [Plan] タブのサブタブを使用する必要があります。

タスク定義の重要な側面は、[Task Name] を割り当てて、[Workflow Type] を選択することです。新しい「内部」タスク（すべてが Service Manager 内で実行されるタスク）を作成し、以前に定義されたサービス タスク（Service Link エージェントを介して指定された外部タスク）を指定するか、サービス項目タスク（Service Item Manager を介して指定されるサービス項目を作成、更新、または削除するタスク）がワークフローに組み込まれるように設定できます。

[Task Properties] ダイアログから図に戻るとすぐに、タスク名が表示され、図の [Task] アイコンがワークフロー タイプを反映して変わる場合があります。タスクをダブルクリックすることで、いつでも [Task Properties] ダイアログに戻ることができます。

ワークフローの指定

黄色のアラート アイコンは、現在の状態の図が有効ではないことを警告しています（図 1-1を参照）。アラート アイコンの上にカーソルを合わせると、問題の説明が表示されます。ただし、図 1-1 では問題はかなり明確です。タスクは [Start Workflow] アイコンと関連付けられ、ワークフロー内で適切な順序に割り当てられる必要があります。

ワークフロー内にタスクを配置するには、[Associate] ツールをクリックします。次に、ワークフロー内の最初の項目（この場合は [Start Workflow] アイコン）をクリックして、次の項目（この場合は、図内の最初で唯一のタスク）までマウスでドラッグします。マウスを放すと、図に矢印が追加され、[Start Workflow] からワークフロー内の最初のタスクまでのフローが表示されます。

タスクを接続するより簡単な方法は、接続カーソルを使用する方法です。

1. 別のタスクを図に追加し、必要であれば、それに名前を付けます（たとえば、「Pull Memory」など）。このタスクは、ワークフロー内で [Check Inventory] の後、次に来るタスクです。

2. この順番でタスクを関連付けるには、最初のタスク（Check Inventory）の真ん中に接続カーソルが表示されるまでカーソルを動かします。

3. 2 番めのタスクまでマウスをドラッグします。タスクとターゲット タスクの間に太い点線が表示され、ターゲット タスクが太い実線で強調表示されます。選択カーソルが 2 番めのタスクに表示されます。

4. マウスを放します。関連が描画され、図は有効になります。

親タスクとサブタスク

タスクはいくつかの理由でグループ化することができます。次に例を示します。

• 一部のタスクは条件付きであり、特定のタスクが実行されているかどうかに関係なく、連続するタスク内の最初のタスクと最後のタスクが完了したら、電子メール通知を送信したいと思っています。

• タスクは 2 番めのタスクと同時に実行される必要があります。サービスの Service Level Agreement（SLA）を算出する際に、両方のタスクをカウントするのではなく、より長く時間がかかった方のみをカウントしたいと思っています。

これらのシナリオや他のシナリオに対応するために、Request Center はタスクのグループ化をサポートしています。親タスクには、1 つ以上の子またはサブタスクがあります。サブタスクは、順次または同時のいずれかで実行できます。

サブタスクを作成するには、次の手順に従います。

ステップ 1 [Start Subtasks] アイコンを適切な順番で作業領域までドラッグします。

ステップ 2 タスク アイコンを [Start Subtask] アイコンの下にある作業領域までドラッグします。必要に応じて、タスクを定義します。

ステップ 3 タスクが同時に実行されることを示すには、接続カーソル（カーソル ハンドル付き）が表示されるまで、カーソルを [Start Subtasks] アイコンの真ん中まで動かした後、各サブタスクまでマウスをドラッグします。以下の左側の図のように、それぞれが [Start Subtasks] に接続されます。

ステップ 4 タスクが順次に実行されることを示すには、接続カーソルを使用して、[Start Subtasks] アイコンを最初のタスクに接続します。次に、最初のサブタスクを次のサブタスクに接続します。その結果、図は以下の右側の例のようになります。

ワークフローの保存

有効なワークフローしか保存できません。図に何らかのアラート アイコンが表示されている場合、ワークフローは有効ではないことを示しています。アラート アイコンの上にカーソルを合わせて、問題の詳細説明を取得できます。多くの場合、図のエレメントがお互いに適切に接続されていないことが原因です。エラーを修正したら、もう一度 [Save] をクリックして、ワークフローを保存します。

Graphical Designer または [Plan] タブ ダイアログのどちらを使用しても、Request Center は完全に同じ方法でワークフローを保存します。この方法は、最も使いやすいツールをどれでも使用できるという点で優れています。ただし、Request Center は図自体を保存しません。以前に保存した提供計画からそれを再構築した後、図で作業を続けながらその提供計画に追加します。印刷用にワークフローの外観をカスタマイズできます。たとえば、より長い説明を表示するために、タスクを移動したり、タスク アイコンのサイズを大きくしたりします。ただし、図を保存するときに、そのような変更はすべて除去され、ワークフローはデフォルトのレイアウトに戻されます（水平または垂直）。

図の印刷

図を印刷するには、ツール バーから [Print] オプションをクリックします。印刷に適したバージョンでは、スケールや方向など、現在の図の表示が反映されます。必要に応じて、図を複数のページに広げることができます。図を印刷するには、標準ブラウザの [File] > [Print] コマンドを使用します。

手動で図を変更できます。たとえば、個々のタスク アイコンのサイズを変更できます。そのような変更が行われると、変更は印刷に適したバージョンで反映されます。ただし、そのような変更はすべて一時的なものであり、ワークフローを保存しても、保存されません。

Graphical Designer と [Plan] タブ ダイアログ

Graphical Designer には、実際に [Plan] タブのダイアログを使用するより、効率がかなり高く、優れた点がいくつかあります。たとえば、タスクの順番を変更する場合は、データの行を上下に動かすよりかなり簡単に、Designer で単にタスクを別のタスクに再接続するだけで行えます。

Graphical Designer には、図を印刷するためのオプションが含まれています。印刷したバージョンを、Catalog Deployer で入手可能なサービス プレビュー（これには、テキスト フォーマットで詳細なワークフローなど）と比較して、どちらの方がニーズに合致しているかを確認する必要があります。おそらく、ユーザ表記では印刷された図が必要で、開発者文書の場合は Catalog Deployer プレビューのほうが適しているでしょう。

一般タスク プロパティを指定する場合、設計者は [Plan] タブまたは Graphical Designer のいずれかを使用できます。同じプロパティの大部分が Graphical Designer の [Task Properties] シートと、タスクの [General] サブタブの両方に表示されます。ただし、[General] サブタブのダイアログには、次の利点があります。

• スケジュール設定された開始日の条件式とフォーム データを両方の場所に入力できますが、[General] サブタブのダイアログに対してのみ、式を検証するオプションや名前空間を入れることができます。通常、設計時に検証することは、フォームをテストしたときに始めてエラーを発見するより、望ましいことです。

• サブタスクを [Start Subtask] アイコンに接続する方法によって、親タスクが「サブタスクが順次に実行される」と「サブタスクが同時に実行される」のどちらで定義されているかが決定されます。[General] サブタブで親タスク定義の「Top Level Tasks Execute」属性を単に変更するほうが、図ですべてのサブタスクを再接続するより、かなり簡単に行えます。

もちろん、いつでも [Plan] タブのダイアログを使用して、提供計画の定義を完成させ、参加者、タスク指示、電子メール通知、およびタスクのチェックリストを必要に応じて指定できます。

タスク参加者

[Participants] サブタブで、タスクの実行者と、オプションで作業の監視方法を指定します。このタブの変更を保存するには、[Save] をクリックします。

タスク実行者

タスク実行者とは、タスクが割り当てられている人、キュー、または役職です。

通常、タスクは特定の人には割り当てられず、キューまたは役職に割り当てられます。このようにすると、複数の人がそのタスクで作業できるため、1 人の人が作業できなくてもタスクが遅れなくなります。

Task Supervisor

タスク スーパーバイザは、タスク パフォーマンスを制御する方法を提供します。管理設定 [Allow Task Supervisor to cancel task] と組み合わされると、指定した人、キュー、または役職がタスクを取り消せる（スキップできる）ようになります。

式へのロール ベースの割り当て

承認と同様、提供計画のタスクに割り当てられるサービス チームまたは個人は、カスタマーの場所など各要求のデータによって異なります。可能性のあるシナリオごとに異なるフォームやワークフローを作成しなくても、式を使用するとインテリジェントにタスクをルーティングできます。

実行者、スーパーバイザ、およびプロジェクト マネージャのロールは、すべて動的に割り当てることができます。

式から割り当てるには、そのオプションを [Assign] ドロップ ダウンから選択し、[Assign to] フィールドの横にある [...] ボタンをクリックします。[Edit Expression] ダイアログ ボックスが表示され、そこに式を入力できます。式は、個人の ID（Organization Designer で割り当てられる）またはログイン名のいずれかを使用した、個人を一意に特定できる名前空間（またはサービス フォーム上のフィールド）を参照する必要があります。個人のフルネームの式も使用できますが、一般的には使用すべきではありません。同じインストール済み環境を持つ 2 人のユーザが同じ名前である可能性があるからです。

ダイアログ ボックスの [Set Expression] をクリックして式を保存するか、[Close] をクリックして式を設定せずに [Edit Expression] ウィンドウを閉じます。このタブの変更を保存するには、[Save] をクリックします。

電子メール

各タスクには複数のイベントが関連付けられています。電子メールを各イベントに関連付けることで、サービスのカスタマー、タスクの実行者、または要求の現在の状況の他のグループまたは個人に通知できます。

[Email] サブタブを使用して、どのイベントの応答としてどの通知を送信するのかを指定します。通知は、Administration モジュールの通知コンポーネントを使用して定義する必要があります。Request Center にはいくつかのデフォルト電子メール テンプレートが出荷時に付属していますが、大部分のサイトでは、カスタム通知を設計するほうが好まれます。

提供計画のタスクごとに（および承認または確認ごとに）、設計者はタスクで使用されるエスカレーション構造内の層の数を選択できます。

たとえば、次のように 3 つのエスカレーション層を設定できます。

• 層 1：タスクが遅延した時点から 1 時間

• 層 2：層 1 の後 8 時間

• 層 3：層 2 の後 16 時間

[Maximum Tier] の設定によって、最初の層から開始して、いくつのエスカレーション層が特定のタスクによって使用されるかが決まります。

• [As much as there are in escalations] の場合は、すべての層

• [Specified As] の場合は、このタスクに使用する層の数。層の数以下の任意の数が定義されます。

この場合、たとえば、最大層が [Specified As 2] であれば、タスクが遅延した時点から 1 時間後と 9 時間後に通知が送信され、3 つめの層のエスカレーションは適用されません。

タスク指示

[Task Instructions] サブタブで、タスクに指示を与えたり、タスク指示に関連する URL へのリンクを設定したりできます。

HTML エディタを使用して、HTML を [URL Description] フィールドと [Task Instructions] フィールドに組み込みます。

チェックリスト

[Checklist] サブタブでは、リマインダのリストを作成したり、タスクを完了するための特定の手順を詳細化したりできます。これらは、Service Manager にチェックリストとして表示され、作業を完了するための手順が詳細化されます。チェックリストは実行期日に影響を及ぼしません。また、レポート機能はありません。

次のことも実行できます。

• 新しい項目をリストに追加するには、チェックリスト項目を右側の [Item Properties] ボックスに入力して [Add New] ボタンをクリックします。

• リストから項目を削除するには、項目を強調表示して [Delete] をクリックします。

承認

[Authorizations] タブを使用して、サービスの承認、確認、およびエスカレーション タスクを設定し、それらを実行する順番を指定します。

[Authorizations] タブを使用して、サービスに対する遅延した承認/確認タスクについてのエスカレーション層、受信者、および電子メール メッセージをカスタマイズすることもできます。

承認構造

サービスごとに、以下の 3 つのオプションから選択できます。

• Use service group authorization structure only：サービスはサービス グループに定義された承認構造を継承します（[Administration] > [Authorizations] で指定）。追加設定は必要ありません。詳細については、『Cisco Service Portal Configuration Guide』の「Site Administration」の章を参照してください。

• Use service-level authorization structure only（サービス グループ レベルは使用しない）：サービス グループ用に定義されているすべての承認は無視されます。サービス用に設定された承認のみが適用されます。

• Use both service group-level and service -level authorization structures：サービス グループ用に定義された承認構造を受け入れ、サービスごとにカスタマイズされたスキームでそれを補足できます。

承認タイプ

サービス グループの承認タイプには、次の 2 つがあります。

• 承認 は、サービスを要求している人に、その要求を受ける資格があるかどうかを判別するための機会を承認者に提供します。承認が拒否されると、プロセスは停止し、サービスは提供されません。複数の承認が定義されている場合、指定された順番で順次に実行されます。前の承認が認められるまで、次の承認は開始できません。

• 確認 は情報のみです。確認者はサービスを拒否したり、提供プロセスを取り消したりすることはできません。サービスを確認したことを示すのみです。複数の確認が指定されている場合、それらは同時に実行されます。ただし、すべての確認が完了するまで、提供プロセスは開始されません。

「not currently enabled via the Administration module」というメッセージが表示された場合は、特定のサービスの承認/確認がサイトで有効になっていません。これは、Administration モジュールで変更できます。

[Authorizations] および [Reviews] サブタブ

[Authorizations] および [Reviews] サブタブでは、サービスを承認または確認する人を決定します。固有のロールを設定して、それらのロールが要求を確認および承認する順番を定義できます。選択する承認タイプに基づいて、[Authorizations - Sequential Process] または [Reviews - Concurrent Process] サブタブが表示されます。

（注） 各行の右側にある上下の矢印ボタン（）を使用して、承認プロセスでロールを上または下に移動できます。

（注） [Update] ボタンをクリックして、変更を保存します。

次の表には、[Add] ボタンをクリックした後、あるいは [Name] フィールドの左側にあるチェックボックスをクリックすることで以前に定義した承認/確認のロールを選択することで表示される [Details] 画面にあるフィールドが定義されています。

サイト承認スキームの使用

Administration モジュールの [Authorizations] タブに設定されているように、サイト承認スキームを使用できます。これはデフォルト設定であり、多くの場合、実装が最も簡単です。詳細については、『Cisco Service Portal Configuration Guide』の「Site Administration」の章を参照してください。

サイト承認ロールを使用して、スキームの順番を付けるには、次の手順を実行します。

1. まだ選択していない場合は、[Use service group authorization structure only] の横にあるオプション ボタンをクリックします。

2. [Area Authorizations] および [Reviews] リストで項目を選択し、サイト定義の承認ロールとエスカレーションの詳細を表示します。

承認を設定してサービス リンクとともに使用

ビジネス プロセスで、このプロジェクト以外のシステムを介して承認を実行する必要がある場合、[Service Link] を使用して、その外部システムによって承認タスクが実行されるようにすることができます。外部タスクとその処理方法を定義するために必要な設定は、ロールの [Details] 画面にある [Authorization] タブに表示されます。

1. [Workflow Type] ドロップ ダウン メニューのデフォルト設定は [Internal] であり、これはタスクがユーザによって手動で実行されることを意味します。サードパーティ製システムの外部タスクとして実行されるようにタスクを設定するには、ドロップ ダウン リストを使用して、このリストから該当するアクションを選択します。

2. 何らかの理由で、サードパーティ製アプリケーションが承認タスクを正常に完了しなかった場合、このタスクのサービス リンク統合で問題が生じたことを管理者に通知できます。[Notify when external tasks fail] メニューで、そのような通知を送信するテンプレートを選択できます。

3. Service Link モジュールに対する適切な許可を持っている場合、[Workflow Type] ドロップ ダウン メニューの右側に省略（...）ボタンが表示されます。このボタンをクリックすると、[Task Data Mapping] ダイアログ ボックスが表示されます。

このダイアログ ボックスには、外部システムに送信されたデータがサービスオーダーフォームのデータ、またはシステム内の任意の場所にどのようにマップされるかを示す設定が含まれます。これらの設定を変更する許可を持っている場合、ダイアログ オックスは編集可能になります。それ以外の場合は、読み取り専用です。

これで、エスカレーション電子メールを設定する準備が整いました。詳細については、「エスカレーション」を参照してください。

サービスをオーダーするための許可

[Permissions] タブには、どの参加者がこのサービスのオーダーを許可されているかが示されています。

サービスをオーダーするための許可を付与するには、次の手順を実行します。

ステップ 1 参加者がオーダーできるようにするサービスの [Permissions] タブを開きます。

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

ステップ 2 [Add Participants] をクリックして、[People]、[Organizational Units]、[Functional Positions]、[Groups]、[Roles] を追加するか、[Anyone] にアクセスできるようにします。

ステップ 3 追加するエンティティ（1 つまたは複数）を検索して選択します。

Organization Designer モジュールで（あるいは、実装されている場合は Directory Integration を使用して）以前に作成/定義された人、組織単位、役職、グループ、またはロールを検索して、選択できます。

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

[Anyone] にアクセス権を付与すると、すべての Request Center ユーザがこのサービスをオーダーできるようになります。本質的に完全にすべての人に共通で、すべてのカスタマー ベースに公開されているサービスについてのみ、付与対象に [Anyone] を使用するようにしてください。[Site Administrator] ロールは、定義によって、すべてのサービスをオーダーする許可を持っています。

スケジュールされた開始タスクの作成

デフォルトで、サービス要求のすべての承認が完了するか、承認がない場合はサービス要求が送信されるとすぐに、提供計画はアクティブになります（また、サービスの実行者がタスクを時間どおりに完了するかどうかについて、クロックが開始します）。場合によっては、この動作は好ましくないことがあります。たとえば、新しい従業員の代わりに数週間以内に作業が開始するようにスケジュールされた要求を入力したり、将来増加するようにスケジュールされたプロジェクト用の新しいサーバを開発チームが要求したりする場合があります。このような場合、Request Center では、指定された開始日に到達するまで進行中（アクティブ）にならない、スケジュールされた開始タスクを作成できます。

スケジュールされた開始タスクが次のタイミングで実行されるように指定できます。

• カスタマー、あるいは承認や確認を実行する他の人によってサービス フォームに指定された日時。

• Service Designer の [Plan] タブでサービスの設計に指定した固定日時。

サービス フォームのフィールドを使用して、スケジュールされた開始タスクを作成するには、以下の手順を実行します。

ステップ 1 サービス定義で、サービスで使用されているアクティブ フォーム コンポーネントの [Form] タブに移動して、データを保持しているディクショナリ フィールド（たとえば、NewHire.StartDate）を見つけます。フィールドのデータ タイプは、[Date] または [Date and Time] のいずれかにすることができます。

ステップ 2 必要に応じて、前のステップで見つけたディクショナリ フィールドを含むアクティブ フォーム コンポーネントに移動します。[Access Control] タブと [Display Properties] タブをクリックして、適切なディクショナリ許可と、使用するフィールドの HTML 表現を設定します。

ステップ 3 サービスの [Plan] タブをクリックして、遅延するタスクを特定するか作成します。

ステップ 4 タスクの [General] サブタブで、[Allow a scheduled start date] をオンにします。

ステップ 5 [Form data for start date] フィールドに、データの保持に使用するディクショナリ フィールドの名前と、タスクの開始点となる日時を入力します。これは、ステップ 1 で見つけたフィールドと同じです。次の構文を使用します。

• Data. DictionaryName.FieldName （サービスのフォーム コンポーネントの 1 つにあるディクショナリからのフィールド用）。

• ParentData. DictionaryName.FieldName （親サービスのディクショナリのいずれかからのフィールド用。バンドルされたサービスの場合）。

固定された日時を使用して、スケジュールされた開始タスクを作成するには、以下の手順を実行します。

ステップ 1 サービスの [Plan] タブをクリックして、遅延するタスクを特定するか作成します。

ステップ 2 タスクの [General] サブタブで、[Allow a scheduled start date] をオンにします。

ステップ 3 [Form data for start date] フィールドに、次のフォーマットで日時を入力します。

たとえば、「2006-12-23 13:30」のように、「YYYY-MM-DD HH:MI」というフォーマットで入力します（引用符は必要）。HH は、GMT での 24 時間表記です。たとえば、このタスクは GMT で 12 月 23 日の午後 1 時 30 分に開始します。

スケジュールされた開始タスクに指定された開始日が、（残りの計画に関して）考えられる最も早い開始日より早い場合、システムは単に指定された開始日を無視して、タスクが遅延タスクではないかのように処理します。これは、システム履歴にログ記録されます。

あるいは、指定された開始日が必須ではなく、カスタマー/承認者が開始日を指定していない場合、Request Center は、遅延タスクではないかのようにタスクを処理します。

スケジュールされた開始タスクに対するシステムの動作

システムは、提供計画タスクごとに、[Scheduled Start Date] と [Actual Start Date] の両方を保持します。これらの日付は、Service Manager のタスク フォームで確認できます。

システムは、先行するタスクが完了した後に、スケジュールされた開始タスクを自動的には開始しません。スケジュールされた開始タスクは、指定された開始点に到達するまで、[Scheduled] ステータスになります。この時点で、システムはタスク ステータスを [Ongoing] に変更し、割り当てられた実行者がタスクを処理できるようになります。フィールドの [Scheduled Start] と [Started] は、スケジュールされた開始タスクに関して同じです。

スケジュールされた開始タスクの開始点がフォーム データから定義されており、[Date] フィールドを使用してこの開始点を定義する場合、システムはタスクの実行者の就業時間に時間を設定します。たとえば、タスクが HR グループ キューによって実行される場合に、キューの就業時間が 8:00 から 16:00 である場合、システムはユーザによって入力された日付に 8:00 という時間を設定します。

システムは、ワークフロー プロセスのサービス提供フェーズが開始した後、すべての提供計画タスクをスケジュールします（サービス提供フェーズは、承認フェーズが完了してから開始します）。

システムは、サービス提供フェーズの開始時にすべての提供計画タスクをスケジューリングするまで、スケジュールされた開始タスク用に指定された開始点を評価しません。これは、開始点が（サービスをオーダーするカスタマーではなく）承認または確認ステップの実行者によって指定される可能性もあることを意味しているため、サービスを設計するときにこれを活用できます。

無効な日付の入力

サービス設計者は、スケジュールされた開始タスクの開始点としてカスタマーが何を入力するかを制御できません。たとえば、カスタマーはサービス内の先行するタスクが完了する前に起こることになる将来の日付を入力する可能性があります。

システムは、提供計画タスクをスケジュールするときに、開始点の日付を評価します。タスクに指定された開始点が、（残りの計画に関して）考えられる最も早い開始日より早い場合、システムは単に指定された開始日を無視して、タスクが遅延タスクではないかのように処理します。システムはコメントを [System History] フィールドに入力し、開始日が無視されることを示します。

同様に、開始点がサービス フォームで必須フィールドではない場合、カスタマーはスケジュールされた開始タスクの開始点を指定しない可能性があります。システムはブランクの開始点フィールドを無視し、タスクがスケジュールされた開始タスクではないかのように処理します。

バンドルの作成

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

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

ステップ 1 サービスの [Offer] タブから、[Bundle] サブタブを選択します。

ステップ 2 [This service is a bundle] を選択します。Service Designer はバンドル内のバンドルされたサービスをサポートしないため、システムは自動的に [This service cannot be included in a bundle] オプションを選択します。

[Include Service] ボタンが有効になります。

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

ステップ 3 [Include Service] をクリックします。[Select a service] ダイアログが表示されます。このダイアログには、[This service cannot be included in a bundle] オプションがオフになっているサービスのみがリストされます。

ステップ 4 バンドルに組み込むサービスを選択し、[Add Selected Services] をクリックします。子サービスが、[Offer/Bundle] サブタブの [Includes] セクションに表示されます。親サービスの詳細情報の一部として、子サービスは My Services に表示されます（[Included Services] サブタブに表示）。

ステップ 5 ステップ 3 とステップ 4 を繰り返して、他の子サービスをバンドルに追加します。

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

ステップ 1 [Includes] セクションで、移動するサービスのチェックボックスをクリックします。

ステップ 2 上矢印または下矢印のアイコンをクリックして、サービスを移動します。

バンドルの回避

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

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

ステップ 1 バンドルされないようにするサービスを選択します。

ステップ 2 [Offer] タブをクリックしてから、[Bundle] サブタブをクリックします。

ステップ 3 [This service cannot be included in a bundle] オプションを選択します。

包含タスクの確認

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

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

ステップ 1 [Service] パネルから、親サービスを選択します。

ステップ 2 [Plan] タブをクリックします。

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

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

• 包含サービス タスクを削除することはできません。[Plan] タブの [Delete] ボタンは無効です。このタスクを削除するには、バンドルから対応する子サービスを削除します。

• [Duration] の値は設定できません。これらは、子サービスの提供計画から、合計期間として算出されます。

• [Task Type] を編集できません。これは、デフォルトで [Included Service] に設定されています。

• チェックリストの作成または関連付けは行えません。タスクに [Checklist] タブがありません。

• [Participants] タブの情報を編集できません。

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

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

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

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

ステップ 1 タスク名をクリックします。[General] タブがタスクの情報とともに表示されます。[Task Type] には、タスクが [Included Service] であることが示されます。[Service Name] は、包含タスクが表すサービスを示しています（包含タスクの名前を変更する場合は、この情報が重要になります）。

ステップ 2 [Task Name] フィールドに新しいタスク名を入力して、[Update] をクリックします。

包含参加者の確認

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

バンドル内の包含参加者を確認するには、次の手順に従います。

ステップ 1 親サービスを選択します。

ステップ 2 [Plan] タブをクリックします。

ステップ 3 [Participants] サブタブをクリックします。

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

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

バンドルの価格設定

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

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

バンドル価格の値引き

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

• アクティブ フォーム コンポーネント ルールで使用可能な価格設定アクションを介した動的価格設定を使用して、サービスがバンドルで使用されている場合に、その価格を下げます。

• 親サービスの [Pricing] サブタブを使用します。ここで、親サービスに対して値引き価格を設定できます。これは、包含サービスの総コストから減算される数値です。

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

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

ステップ 1 [Services] パネルから、親サービスを選択します。

ステップ 2 [Offer] タブをクリックしてから、[Pricing] サブタブをクリックします。

ステップ 3 価格に対する値引き値を入力します。たとえば、サービス バンドルを 1000.00 ドル分値引きするには、-1000.00 を入力します。

ステップ 4 [Save All Settings] をクリックします。

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

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

カスタマーは My Services でバンドルをオーダーするときに、サービス名をクリックしてサービスの詳細を表示します。[Details] ページで、[Included Services] をクリックして、バンドルに含まれているすべてのサービスを表示できます。

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

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

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

カスタマーはバンドルをオーダーした後に取り消せるか

カスタマーは、オーダーした後にバンドルを取り消せます。バンドルを取り消すと、含まれているすべてのサービスも取り消されます。個々の子サービスを取り消すオプションは、[Edit Requisition] ページでエンドユーザに対して無効になっています。

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

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

バンドルのエクスポートとインポート

他のサービスを使用して実行できるのと同じように、Service Designer を使用してバンドルされたサービスをエクスポートおよびインポートできます。Service Designer でバンドルされたサービスの XML を作成すると、親の XML に加えて、各子サービスの XML も単一の XML ファイル内に生成されます。これは、バンドルをエクスポートして、子サービスがまだ含まれていない別のカタログにそれをインポートできることを意味しています。エクスポート ユーティリティによって、バンドル内に各サービスがカタログ内の別個のサービスとしてエクスポートされ、ソース カタログでリンクされているのと同じように、子を親サービスにリンクします。

バンドルされたサービスのデータ

Administration モジュールの [Personalize Your Site] に配置されている [Show Bundle Data] パラメータを介して、バンドルのオーダー フォーム上でディクショナリ フィールド サービス実行者に表示されるものを制御できます。

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

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

• ShowBundleData = On （デフォルト）は、いずれかの子サービスの中で作業項目を処理するときに、サービスの実行者にバンドルの複合オーダー フォームを表示します。

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

バンドルされたサービスの名前空間変数

システムには、バンドルされたサービスでデータを処理する場合に使用できる多数の名前空間変数が備わっています。

• サイト設定パラメータ ShowBundleData の値が On である場合、ParentService.Data. DictionaryName.FieldName は Data. DictionaryName.FieldName と同等になります。

• ShowBundleData の値が Off である場合、ParentService. Data.DictionaryName.FieldName は親サービス内のデータ エレメントを参照するために必要な構文です。

ディクショナリに関してよくある質問

以下の質問をよく調べて、使用可能なディクショナリのタイプ、それらの相違点、およびそれらの使用法についての理解を深めてください。

予約フォルダとは何ですか?

すべてのサービス ポータル インスタンスには、カスタマーと発信者の各情報用のシード データとして提供されている 2 つのディクショナリが自動的に組み込まれます。これらのディクショナリは、Service Designer の Dictionaries コンポーネントの「予約」ディクショナリ グループにあります。

アクティブ フォーム コンポーネントには「予約」フォーム グループもあり、これには Customer-Initiator フォームが含まれます。このフォームには、Customer_Information ディクショナリと Initiator_Information ディクショナリが含まれています。

個人ベースのディクショナリを使用した場合、個人情報はどこから取得されますか?

Request Center には、Service Portal アプリケーションにアクセスする必要のあるユーザ組織内のすべての人のリポジトリが保持されています。通常、このリポジトリ内の個人情報には、ディレクトリの統合によってデータが取り込まれます。ユーザが Request Center にログインするたびに、またはユーザに代わってサービスによってオーダーするたびに、リポジトリ内の個人情報を企業全体のディレクトリからの情報でリフレッシュできます。Request Center 内の個人情報は Organization Designer を介して表示できます。

なぜ個人ベースのディクショナリを作成する必要があるのですか?

要求のカスタマーまたは発信者のみを参照している場合、個人ベースのディクショナリを作成する必要はありません。代わりに、Customer-Initiator フォームですでに組み合わされている Customer_Information および Initiator_Information ディクショナリを使用します。

しかし、要求者は、要求の実行に関与するか、参照として必要になる可能性のある別の個人を指定しなければならないことがよくあります。たとえば、個人ベースのディクショナリが頻繁に使用される事例として、ディレクトリの統合から使用可能な監視構造から承認者が推測できない場合に、発信者が要求の承認者を 1 人以上指定する必要がある場合が挙げられます。このシナリオでは、使用可能な従業員のドロップ ダウン リストから検索することで、要求者は承認者を選択します。また、承認者の連絡先情報は、簡単な参照用にサービス フォーム データに含まれます。

個人ベースのディクショナリの作成と、データ フィールド type = Person を含むフリー フォームのディクショナリの作成の相違は何ですか?

内部フリー フォーマット ディクショナリで個人タイプのフィールドを使用することは、個人を選択し、その個人に関係のない他のフィールドを含むディクショナリに その個人の名前だけ をディクショナリに表示する場合である場合に便利です。

個人ベースのディクショナリは、個人名前を表示するフィールド、[Select Person] ボタン、呼び出し型の [Person Search] ウィンドウ、および個人を検索する機能が、使用するシステム構成に応じて、統合されたディクショナリか Service Portal リポジトリのいずれかに自動的に提供します。フォームによって、個人ベースのディクショナリのフィールドに対応する、選択した個人に関するすべての情報が自動的に表示されます。

これとは対照的に、内部フリー フォーム ディクショナリの個人タイプのフィールドには、個人の名前が表示され、同じ [Search Person] 機能が用意されています。しかし、個人が一度選択されると、その名前のみがサービス フォームに自動的に表示されます。他の詳細データは、SQL ステートメントを指定して、フィールドごとにマッピングすることで、データ取得ルールに従って取得する必要があります。

「Select_Person」属性は、Service Portal リポジトリ内か、サービス フォームに対してディクショナリ統合が有効になっている場合には外部ディクショナリのいずれかで、人を検索する機能を提供します。たとえば、以下のサービス フォームの [Person] フィールドは、「Select_Person」属性の HTML 表現です。

[Select] ボタンをクリックすると、[Person Search] ダイアログが表示され、これを使用して検索条件を指定し、1 人の個人を選択できます。個人が選択されたら、検索ダイアログは消え、選択した個人のプロファイルにある対応するフィールドの現在の値を使用して、ディクショナリで使用されているすべてのフィールドにデータが取り込まれます。

Customer-Initiator フォームと、標準的な内部個人ベースのディクショナリを使用する場合の違いは何ですか?

個人ベースのディクショナリには、特定の個人に関するデータを Service Portal リポジトリから取得して、個人データのどの部分をサービス フォームに表示すべきかを指定するためのメカニズムが備わっています。

Customer-Initiator フォームは、2 つの内部個人ベースのディクショナリで構成されており、1 つはカスタマーの情報用で、もう 1 つは発信者の情報用です。Customer および Initiator のディクショナリは、すべての側面についてカスタマーと発信者を自動的に記録する標準の動作を補足します。カスタマーと発信者に関するすべての情報は、「Lightweight 名前空間」を介して要求ライフ サイクル全体で使用可能であり、My Services と Service Manager の要求に関する [Requisition Summary] ページの一部として表示されます。

これらのディクショナリは、システムにとって既知の値に基づいてサービス フォームに自動的にデータが入力されますが、標準の個人ベースのディクショナリでは、上述のとおり、要求者が個人を選択できるようにできます。

設計者は、必要に応じて、他のディクショナリの Customer-Initiator フォームから「Lightweight 名前空間」を使用できます。つまり、Customer-Initiator フォームは個人情報を表示するための簡単で部分的に事前設定された方法と言えますが、方法は 1 つではありません。

Customer または Initiator のディクショナリで、一部のフィールドを使用しない場合はどのようにすればいいですか?

Customer と Initiator のディクショナリそれぞれについて、Service Designer の Dictionaries コンポーネント内で、どのディクショナリ フィールドをサービス フォームに表示するかを選択できます。予約済みディクショナリ グループの Customer または Initiator ディクショナリに単に移動して、[Use] 列のボックスをオンまたはオフにすることで、ディクショナリおよび Customer-Initiator フォームでどのフィールドを使用するか、つまり含めるかを決定します。

カスタマーまたは発信者の姓名とログイン ID のほかに、個人の電子メール アドレス、ホーム OU、およびオフィスの場所用のフィールドを追加するのが一般的です。

含めるフィールドを選択したら、サービス フォームで ディクショナリを読み取り専用に設定 することもできます。

予約済みディクショナリの 1 つでフィールドのデフォルト値を削除したらどうなりますか?

Customer または Initiator ディクショナリのフィールド内のデフォルト値によって、システムはサービス フォームに値を事前入力できます。

Active Form コンポーネントの Customer-Initiator フォーム内で、フィールドのデフォルト値を誤って削除した場合、そのデフォルト値を手動でもう一度追加する必要があります。デフォルト値を復元するための自動設定機能はありません。この値は、Customer または Initiator のいずれかの情報と関連付けられた「Lightweight 名前空間」を参照します。そのような名前空間の完全なリストについては、「名前空間」を参照してください。

Customer または Initiator ディクショナリで使用するようにフィールドを選択しなければ、それらの外観や動作を修正することはできません。Customer-Initiator フォームの [Display Properties] タブに移動して、Customer または Initiator ディクショナリ フィールドのデフォルト値を手動で再入力します。

予約済みディクショナリで[Extended Person] フィールドをどのように使用できますか?

簡単に言えば、希望するようにどのようにでも使用できますが、より詳細な説明については、Organization Designer オンライン ヘルプのトピック「Adding Extensions」と、『Cisco Service Portal Integration Guide』の属性マッピングについての説明を参照してください。

基本的に、Service Portal には標準的な個人データへの拡張を提供するフィールドが含まれています。最も頻繁に必要になる拡張フィールドの一部には意味のある名前（たとえば、会社コードや部門）が割り当てられていますが、他のフィールドの名前は Custom 1 から Custom 10 であり、事前に考えられた意味を使用せずに、自由に使用できます。アプリケーションで公開する必要のある LDAP ディクショナリに追加の個人情報がある場合、その情報を含む属性をカスタム フィールドの 1 つにマップして、対応する [Custom] フィールドが Customer または Initiator ディクショナリに含まれていることを確認します。拡張フィールドの 1 つにいずれのディクショナリ属性もマップしなかった場合、予約済みディクショナリの 1 つにそれを含めて、条件付きルールまたはデータ取得ルールを使用し、値を提供できます。

サービス項目ベースのディクショナリとは何ですか?

サービス項目ベースのディクショナリとは、Service Item Manager モジュールに定義されたサービス項目に基づく構造（フィールド）を持つディクショナリのことです。詳細については、「Lifecycle Center」を参照してください。

統合フォルダとは何ですか?

統合ディクショナリ グループは、すべての Service Portal インスタンスで自動的に作成されます。統合ウィザード（Service Portal と外部システム間の Web サービス統合を作成する Service Designer のウィザード）を通して作成されるすべてのディクショナリが、自動的にこのグループに配置されます。一度作成されると、統合ディクショナリはどのディクショナリ グループにも移動できます。設計者は、このグループに手動でディクショナリを配置することはできません。

サービスへのフォームの追加

Services コンポーネントの [Form] タブを使用して、アクティブ フォーム コンポーネントをサービスに追加し、フォームがサービス フォームに表示される順番を指定します。フォーム コンポーネントの使用法のいくつかの側面を確認して、フォーム コンポーネント用に定義されたディクショナリ許可に追加できます。

それぞれが同じディクショナリを含む 2 つのフォームを追加しようとすると、アプリケーションによってエラー メッセージが表示され、単一のサービス フォームで同じディクショナリを 2 回使用することができなくなります。フォーム コンポーネントをサービスに一度追加したら、それを検索結果から削除して、同じフォームが 2 回選択されないようにすることができます。

Customer-Initiator フォーム（予約された Customer_Information および Initiator_Information ディクショナリを含む）を「アクティブ フォーム コンポーネント」で説明されているように、各サービスに含めることを推奨します。このフォームが各サービスで表示される順番は、サービス設計者によって決定されます。

サービスに組み込むことができるフォーム コンポーネントのリストは、サービス設計者が [View Forms] または [Design Forms] に対する許可を持っているフォーム グループ内のフォームに限定されます。

サービス定義へのフォーム コンポーネントの追加

サービスにフォームを追加するには、次の手順を実行します。

ステップ 1 Service Designer のサービス コンポーネントにある目的のサービスに移動します。

ステップ 2 [Form] タブを選択します。

ステップ 3 [Add Forms...] をクリックします。

ステップ 4 サービスに追加する 1 つ以上のフォーム コンポーネントを検索して選択します。

ステップ 5 [Add] をクリックします。

ステップ 6 選択したフォームがすべてサービスに追加されます。

それぞれが同じディクショナリを含む 2 つのフォームを追加しようとすると、アプリケーションによってエラー メッセージが表示され、単一のサービス フォームで同じディクショナリを 2 回使用することができなくなります。フォーム コンポーネントをサービスに一度追加したら、それを検索結果から削除して、同じフォームが 2 回選択されないようにすることができます。

サービス定義でのフォーム コンポーネントの順番の変更

フォーム コンポーネントがサービス フォームに表示される順番を変えるには、次の手順を実行します。

ステップ 1 サービスの [Form] タブで、移動するフォームの左側にあるボックスをオンにします。

ステップ 2 [Forms used in this service] というリストの右側にある上矢印またはした矢印をクリックします。

サービス内のフォームの順番を変更することで、アクティブ フォーム コンポーネントの [Form Content] タブにあるフォーム フィールドの順番を変更します。サービス フォームのフィールドはフォーム コンポーネントによって順番に表示され、各フォーム コンポーネント内では、フィールドに指定された [Display Order] の順番で表示されます。

同様に、フォーム コンポーネント ファイルに定義されたルールは、フォーム コンポーネントがサービスで順序付けられた順番に従って、そのフォーム コンポーネント内に指定された順番で開始されます。同じディクショナリとディクショナリ フィールドの一方または両方を起動する複数のルールを作成した場合、ルールの順番内の最後のルールが優先されます。

フォーム コンポーネント設定の確認/修正

フォーム コンポーネントをサービスに追加したら、[Form] タブでその設定の部分を確認できます。

• フォーム コンポーネント名を強調表示すると、条件付きルールおよびデータ取得ルールに対してフォーム レベルのトリガー イベントで、フォーム コンポーネントの動作を表示できます（たとえば、フォームが送信されたとき）。

• フォーム コンポーネント ノードを展開すると、フォーム内のディクショナリが表示されます。ディクショナリ名を強調表示することで、要求実施ライフ サイクルの各システムの時点で、さまざまな実行者（たとえば、カスタマー）の権利を表示できます。また、このアクセス コントロールに参加者を追加することもできます。その他の変更は行えません。

• ディクショナリ ノードを展開すると、ディクショナリを構成しているフィールドが表示されます。フィールド名を強調表示すると、以下を表示できます。

– [General] タブの、含まれているディクショナリ フィールドごとの入力タイプ（たとえば、テキスト フィールド、オプション ボタン）および表示形式。

– [Behavior] タブの、条件付きルール、データ取得ルール、または特定のフィールドに関連付けられた JavaScripts。

このページのフォーム コンポーネントの設定に行える唯一の修正は、ディクショナリのアクセス コントロールに [Additional Participants] を指定することです。これにより、フォーム コンポーネントの使用法を、このサービスに指定された承認とタスクに沿ってカスタマイズすることができます。

サービスの [Form] タブに表示される内容にその他の修正を加えるには、変更するエレメントにナビゲートする必要があります。エレメントの上にカーソルを合わせて、Ctrl キーを押しながらクリックし、必要に応じて、ディクショナリ、フィールド、またはフォームを修正します。完了したら、ページの下部にあるリンク（[Active Form Components using this Dictionary]、[Services using this Active Form Component]）をクリックして、サービス定義に戻ることができます。

アクティブ フォーム コンポーネントが実際に再利用可能である場合、サービス設計者が事前設定フォーム コンポーネントを追加して、各サービス フォームでわずかな修正のみを実行するようにできる必要があります。フォーム コンポーネント内で使用されるエレメントに対して行った変更はすべて、そのフォーム コンポーネントを使用するすべてのサービスによって継承されることを忘れないでください。

サービスからのフォームの削除

サービスからフォーム コンポーネントを削除するときは、慎重に行う必要があります。フォーム コンポーネントのルールは、その同じコンポーネントと、他のフォームにあるディクショナリとフィールドの両方を参照する可能性があります。フォーム コンポーネント内のルールによって参照されるすべてのディクショナリが（包含フォーム コンポーネント内にあるため）実際にフォーム内に存在することを確認するのはサービス設計者の役割です。大部分の場合、現在のサービスに存在しないフィールドをルールが参照している場合、ルールはサイレントで失敗し、追加のルールは影響を受けません。ただし、非常に慎重にコード化された場合を除き、ハンド コード化された ISF にはこれは当てはまらない可能性があります。この場合、ISF 関数の失敗により、JavaScript エラーが生じ、それによって同じイベント内のそれ以降のすべての機能の実行が停止して、他の結果を招く可能性があります。

サービスからアクティブ フォーム コンポーネントを削除するには、コンポーネント名の横にあるチェックボックスを選択して、[Remove Selected] をクリックするだけです。

サービスからフォームを削除しても、システムからフォームは削除されません。すべてのフォームは Service Designer のアクティブ フォーム コンポーネント領域で管理され、他のシステムにまだアクセスできます。

サービス上でフォーム コンポーネントを変更した場合の影響

フォーム コンポーネントを変更すると必ず、それらの変更はそのフォーム コンポーネントを使用するすべてのサービスに自動的に伝播されます。内部で、Request Center はサービスのバージョン番号を保持し、その番号を増分します。これは、アプリケーション モジュールのユーザには影響を及ぼしませんが、例外的に、Service Designer ユーザはフォーム コンポーネントが多数（数百）のサービス定義で使用されている場合、ごくわずかな遅延に気付く可能性があります。

同様に、ディクショナリへの変更は、そのディクショナリを使用するすべてのフォーム コンポーネントに自動的に伝播されます。フォーム コンポーネントへの変更は、上述のとおり、そのコンポーネントを使用するすべてのサービスに伝播されます。

カテゴリの定義

Categories モジュールは、カタログ内のカテゴリ、およびカテゴリ構造を作成および管理するために使用されます。親カテゴリを指定してから、その親の中に階層を指定できます。Request Center カタログには [Consumer Services Catalog] という名前が付けられており、すべてのカテゴリはそのルート カテゴリの下で編成されます。Demand Center モジュールを使用して、カスタマー向けの [Service Offering Catalog] 用に同様の階層を構築できます。

新しいカテゴリを作成すると、それが作成されるカタログ（Consumer Services Catalog または Service Offering Catalog）のホーム ページにそれが自動的に追加されます。必要な場合は、ホーム ページからカタログを削除して、カタログの該当するカテゴリおよびサブカテゴリにそれを関連付けます。

Service Designer を使用すると、新しいカテゴリをカタログに簡単に追加できます。

次の表には、[New Category] ウィンドウのフィールドがまとめられています。

新しいカテゴリを追加するには、次の手順に従います。

ステップ 1 カテゴリ コンポーネント内で、[New] > [New Category] をクリックします。

[New Category] ウィンドウが表示されます。

ステップ 2 新しいカテゴリの名前を [Name] フィールドに入力します。カテゴリ名には、60 文字までの制限があります。

ステップ 3 カテゴリの簡単な要約を [Description] フィールドに入力します。カテゴリの説明には、255 文字までの制限があります。

ステップ 4 [Add This Category] をクリックします。

ステップ 5 Service Designer によってカテゴリが追加されます。これで、カテゴリを設定する準備が整いました。

カテゴリの設定

新しいカテゴリを作成した後、以下を行うことで、カテゴリを設定します。

• [General] タブで表示オプションを設定する

• [Presentation] タブで視覚的表示を決定する

これらのカテゴリ タブで行った選択は、My Services 内に表示されます。

カテゴリ コンポーネントの [General] タブを使用して、カテゴリとサブカテゴリがサービス カタログにどのように表示されるかを決定します。

カテゴリの外観の定義

カテゴリの表示オプションを設定したら、[Presentation] タブで HTML ツールを使用して、My Services でカテゴリがどのように表示されるかをフォーマット設定します。HTML エディタの使用方法の詳細については、「HTML エディタのツール アセンブリ」を参照してください。

カテゴリの外観をフォーマット設定するには、次の手順に従います。

ステップ 1 カテゴリ コンポーネント内のカテゴリの [Presentation] タブをクリックします。

ステップ 2 [Select an image to insert] ボタンを使用して、カタログ アイコンを追加します。

• システムで現在使用可能なイメージのリストからイメージを追加するには、リスト内でそのイメージを見つけて、[Add Selected Files] をクリックします。

• 新しいイメージを追加するには、[Browse] をクリックしてイメージを見つけ、[Attach] をクリックしてイメージをシステムにアップロードします。

カタログを表すイメージは、JPG または GIF のいずれかのフォーマットにすることができます。カテゴリとサービスのイメージは、幅 64 ピクセル、高さ 57 ピクセルで表示されるため、このアスペクト比を維持するには、カスタム イメージを作成する必要があります。カスタム CSS 機能を使用して Service Portal をどのようにカスタマイズしたかに応じて、透明な背景を持つカスタム アイコンの作成を検討することもできます。

ステップ 3 [Category Details] フィールドで、カタログのカテゴリ表示領域の上部、中間部と下部の一方または両方のどこにコンテンツを表示（およびフォーマット設定）するのかを選択します。[show] ボタンを選択すると、ウィンドウの下部に HTML エディタを使用してデータが取り込まれます。

ステップ 4 複数のコンテンツ ペインを表示するように選択する場合は、フォーマット設定する図表のセクションをクリックします。

ステップ 5 必要であれば、URL を入力して、コンテンツ セクションの左右または下部に表示します。ここに入力する URL は、「http://」で始まる完全修飾にする必要があります。

ステップ 6 組み込まれている HTML エディタを使用して、テキストとグラフィックの一方または両方を入力およびフォーマット設定します（これは、デフォルトで選択されています）。

また、HTML コードを挿入するには、[Source] ボタンをクリックして、HTML 編集ツールを無効にし、コーディングを直接入力します。[Source] ボタンをもう一度クリックし、HTML エディタに戻って、レンダリングされた HTML コードを表示します。

ステップ 7 [Save] をクリックして変更を保存します。

カテゴリ表示のプレビュー

通常、カテゴリ階層の設計は反復プロセスであり、作業を進める中で、作業を確認したいと思うことがあります。これを行う最も簡単な方法は、2 つのブラウザ セッションを同時に開きます。一方では Service Designer を開き、もう一方では My Services（または My Services Executive）のホーム ページを開きます。カテゴリと関連するサービスに変更を行い、ページを更新します。次に、もう一方のブラウザ セッションで、ページ表示をリフレッシュすると、新しいカテゴリ階層が表示されます。ここで重要なステップは、My Services または My Services Executive ページのリフレッシュを試みる前に、必ず Service Designer で変更を保存するということです。

カテゴリの削除

カテゴリが不要になったら、そのカテゴリを選択して、[Delete] をクリックして削除できます。

カテゴリ、サブカテゴリ、およびサービスの削除

カテゴリが表示されるカテゴリ、カテゴリに表示されるサブカテゴリ、またはカテゴリからのサービスを削除する必要が生じる場合があります。

カテゴリ、サブカテゴリ、およびサービスを削除するには、次の手順に従います。

ステップ 1 Service Designer の [Categories] コンポーネントを選択します。

ステップ 2 カテゴリ、サブカテゴリ、またはサービスから削除するカテゴリの名前をクリックします。

そのカテゴリの詳細が [Category] ウィンドウの右側に表示されます。

ステップ 3 このカテゴリが表示されているカテゴリを削除するには、次の手順に従います。

• 削除するカテゴリの横にあるチェックボックスをクリックします。

• [Remove] をクリックします。

ステップ 4 このカテゴリからサブカテゴリを削除するには、次の手順に従います。

• 削除するサブカテゴリの横にあるチェックボックスをクリックします。

• [Hide] をクリックします。

ステップ 5 このカテゴリからサービスを削除するには、次の手順に従います。

• 削除するサービスの横にあるチェックボックスをクリックします。

• [Hide] をクリックします。

ステップ 6 [Update] をクリックして変更を保存します。

新しいキーワードの追加

新しいキーワードを追加するには、次の手順に従います。

ステップ 1 Service Designer の [Keywords] コンポーネントを選択します。

ステップ 2 [New] > [New Keyword] をクリックします。

[New Keyword] ウィンドウが表示されます。

ステップ 3 新しいキーワードの名前を入力します。

ステップ 4 [Add This Keyword] をクリックします。

Service Designer によって、新しいキーワードが使用可能なキーワードのリストに追加され、サービスまたはサービス オファリングにそれを関連付けられるようになります。

サービスまたはサービス オファリングとのキーワードの関連付け

キーワードをサービスと関連付けると、ユーザは My Services および My Services Executive でそれを使用して、サービスを検索できます。

キーワードの関連性を関連付けるには、次の手順に従います。

ステップ 1 Service Designer の [Keywords] コンポーネントを選択します。

ステップ 2 サービスまたはサービス オファリングと関連付けるキーワードの名前をクリックします。

キーワードの詳細が右側に表示されます。

ステップ 3 [Use in more services...] ボタンをクリックします。

ステップ 4 キーワードと関連付けるサービスまたはサービス オファリングの横にあるチェックボックスをクリックします。

ステップ 5 [Add] をクリックします。

ステップ 6 キーワード名を修正するか、スペルを編集する場合、[Save] をクリックして変更を保存します。

サービスまたはサービス オファリングからのキーワードの削除

サービスまたはサービス オファリングとの関連からキーワードを削除したほうがよい場合もあります。関連を削除しても、Service Designer からキーワードは削除され ません 。

キーワードの関連性を削除するには、次の手順に従います。

ステップ 1 Service Designer の [Keywords] コンポーネントを選択します。

ステップ 2 削除するキーワードの名前をクリックします。

ステップ 3 キーワードとの関連から削除する各サービスまたはサービス オファリングの横にあるチェックボックスをクリックします。

ステップ 4 [Remove] をクリックします。

キーワードの削除

Service Designer の Keywords コンポーネントで削除することで、キーワードを完全に削除することもできます。[Delete] を選択すると、Service Designer はキーワードを削除し、サービスまたはサービス オファリングへのその関連を除去します。