この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「概要」
• 「組織単位」
• 「グループ」
• 「キュー」
• 「人」
• 「役職」
• 「ロール」
• 「承認」
Organization Designer は、サービス組織を構築するための主要ツールです。このモジュールでは、Cisco Service Portal(Service Portal)実装の次のコンポーネントを設定および管理します。
Organization Designer モジュールは、Service Portal のすべてのインストール環境で使用できます。Organization Designer を使用する機能を付与されているすべてのユーザのモジュール ドロップダウン メニューに表示されます。
Organization Designer の [Home] ページは、次の領域に分かれています。
• [Navigation] ペイン。このモジュールおよび現在のページで使用可能なオプションが表示されます。さまざまなオプションを移動している間、([Home] ページから始まる)「ブレッドクラム」のトレールが残るため、前に表示したすべてのページに簡単に戻ることができます。
• [Common Tasks] ペイン。頻繁に使用するタスクを 1 つの場所にグループ化することにより、新しいエンティティを簡単に作成できます。エンティティは、コンポーネント固有のページで使用可能な [Add] ボタンをクリックして作成することもできます。
• [Organization Summary] ペイン。組織単位、グループ、人、およびキューのエントリ数が表示されます。
• [Content] ペイン。組織エンティティの検索、新しいエンティティの作成、または既存のエンティティの変更を行うことができます。
ブラウザ ウィンドウの上部にあるナビゲーション バーにより、任意の Organization Designer コンポーネントから別のコンポーネントにすばやく移動したり、Organization Designer の [Home] ページに戻ったりすることができます。
特定の組織単位、グループ、人、キュー、またはロールを表示するごとに、Organization Designer において何をどのコンポーネントで表示したかがナビゲーション トレールに表示されます。このトレールは、ブラウザ ウィンドウの上部に作成され、これにより、Organization Designer での現在の位置およびそれまでの足跡を簡単に把握できます。
次に、 [component] > [name of the object you are viewing] 形式を使用するブレッドクラム トレールの例を示します。
Organization Designer の別のコンポーネントに移動するもう 1 つの方法として、後で説明しているように、[Home] ページ検索を使用する方法があります。特定のエンティティ タイプを検索し、そのタイプのエンティティを選択すると、対応するコンポーネントに制御が移ります。
Organization Designer では、さまざまな組織コンポーネントへの移動および検索を支援するために 2 つの検索方法が用意されています。
[Home] ページを使用すると、さまざまなコンポーネントの簡単な検索を 1 箇所で実行できます。[Home] ページ上の [Search] 領域を使用して、エンティティをタイプ別および名前別(任意)ですばやく見つけることができます。
• 表示するエンティティ タイプを選択することから始めます。選択を行うと、指定したタイプのすべてのエンティティが、検索ボックスの下のコンテンツ ペインに表示されます。検索結果は、アルファベット順に表示されます。
• コンテンツ ペインに表示されたエンティティのリストをブラウズできます。各エンティティ名の上にマウスを動かすと、ハイパーリンクが表示されます。そのリンクをクリックして Organization Designer ページに移動し、そのエンティティ定義の詳細を表示または変更できます。
• 表示されるエンティティのリストを絞り込むには、エンティティ タイプを選択してから、エンティティ名の全部または一部をテキスト フィールドに入力して、[Search] をクリックします。検索条件を満たすすべてのオブジェクトが表示されます。たとえば、入力した語を含むか完全に一致する名前のエンティティが表示されます。次に、これらのエンティティをブラウズして 1 つを選択し、さらに詳細なビューを表示します。
コンポーネント固有の検索により、[Home] ページに戻らずに、特定のコンポーネントでの検索結果を表示できます。これにより、コンポーネントから移動する必要がなくなり、コンポーネント内にとどまって作業を続けることができます。
Organization Designer で管理されているすべてのエンティティに対してコンポーネント固有の検索を実行できます。
階層構造を持つエンティティ(組織単位やロールなど)の場合は、階層を表示することもできます。検索結果の横にある をクリックします。
各組織エンティティ タイプには独自のホームページがあります。ここにアクセスするには、Organization Designer のホームページで対応するタブをクリックするか、または対応するタイプのエンティティを検索してから選択します。ホームページには、エンティティの「General」プロパティが表示されます。下に示すサンプル グループのように、その他のページがコンテンツ ペインの右に示されます。これらのページは、エンティティのタイプによって異なる場合があります。
Organization Designer でのエンティティの作成には、次の 2 つの方法があります。
• Organization Designer ホームページの [Common Tasks] ページで、[Create] リンクをクリックします。
• 作成するエンティティ タイプに対応するナビゲーション ペインのタブをクリックします。エンティティのホームページが表示されたら、[Add] をクリックします。
いずれの場合も、選択したエンティティ タイプの作成ページが表示されます。
このページには、通常、エンティティの作成に必要なすべての属性が表示されます。これらの属性にデータを指定し、[Create] をクリックすると、そのエンティティが作成されます。これで、標準のページ セットが使用できるようになり、そのエンティティ定義のその他の側面を管理できます。
エンティティの複製方法として、組織エンティティをコピーできます。エンティティをコピーすると、そのエンティティのすべてのプロパティ(そのエンティティのメンバを含む)がコピーされます。ただし、アイデンティティを固有に識別するプロパティ(組織名または個人の名前やログイン ID など)は除きます。
エンティティをコピーするには、その定義を表示し、[General] ページの [Copy] ボタンをクリックします。次に、新しい名前を割り当て、そのエンティティを保存します。新しいエンティティ定義のすべてのページを編集できるようになります。
Organization Designer では、エンティティをシステムから削除することなく、他のモジュール(Service Manager や Service Designer など)内のビューでエンティティを「非表示」にできます。非アクティブなエンティティは、いずれの検索ウィンドウにも表示されません。たとえば、サービス設計者がタスクを特定のキューに割り当てようとすると、アクティブなキューだけが表示されます。エンティティのステータスを変更すると、変更の確認が求められます。
エンティティは、アクティブではなく、使用されていない場合にのみ削除できます。たとえば、提供計画に使用されているキューは削除できません。キューを削除する前に、キューをまず非アクティブ化します。
すべての組織エンティティには [Administration] ページがあります。エンティティの [Administration] 部分では、そのエンティティ用に作成されたレコードの表示または編集を実行できるユーザを指定できます。
エンティティに対する管理権限は、指定した組織単位(その OU 内のすべての人にも継承されます)、役職、キュー、グループ、またはロールに割り当てることができます。また、権限を「Anyone」に割り当てることができます。この場合は、Organization Designer にアクセスできるすべてのユーザがそのエンティティの情報を変更できます。「Anyone」を追加する場合は、慎重に行う必要があります。
|
|
ユーザには、エンティティの読み取り(情報の表示)、書き込み(情報の変更と更新)、および権限の変更(読み取り/書き込みアクセス権の変更)の権限があります。 |
|
ユーザは、エンティティへの読み取り/書き込みアクセス権を変更できます。ユーザが変更を許可されていない権限は「グレー表示」になります。 |
システム定義エンティティには、事前設定済み管理権限セットが自動的に付与されます。これらのエンティティはグレー表示され、削除や変更はできません。ただし、追加の組織単位、人、ロール、グループ、または役職に管理権限を割り当てることができます。
正常に機能する実装を設定するには、組織エンティティが相互にどう関係しているかを理解することが重要です。次に例を示します。
• すべてのユーザは、Organization Designer で表示可能かつ管理可能な 人 として表される必要があります。
• すべての 人 は、少なくとも 1 つの 組織 に属している必要があります。サービスを要求できるようになるために、人は事業単位(組織のタイプ)に属している必要があります。サービス提供タスクを実行する人は、1 つ以上のサービス チームに属していることも必要です。
• 人 および 組織 には ロール が付与されており、これにより、アクセスできるモジュール、および各モジュールで持つことができる機能が決まります。組織にロールを付与すると、その組織のすべてのメンバがそのロールを継承します。たとえば、同じ事業単位で働く人は、通常、同じサービス セットをオーダーします。
• 組織に加えて、 人 のアドホック グループ を設定できます。次に、これらのグループに ロール を割り当てることができます。たとえば、チーム全体ではなく、複数のサービス チームの 1 人または 2 人が、Request Center レポートを実行し、カスタム レポートを作成できる必要がある場合があります。グループを設定すると、適切な人セットに適切な機能を簡単に付与できるようになります。
エンティティ間の依存関係は、Organization Designer でこれらのエンティティを操作する方法に影響します。個々のエンティティ タイプに関する項では、こうした依存関係について詳細に説明します。
原則として、次の組織エンティティは、ディレクトリ統合を使用して作成およびリフレッシュできます。
• 人(ロール、グループ、および組織でのその人のメンバーシップを含む)
• 組織(メンバによるサービスのオーダーが許可されている会社の部署または部門である事業単位、および Request Center 内でタスクを実行する会社従業員であるサービス チームの両方を含む)
多くのインストール環境では、事業単位はディレクトリ統合の一部として自動的に作成されます。事業単位は企業エンティティの実際の部門に対応しており、ほとんどの企業ベース ディレクトリの一部である必要があるため、これは理にかなっています。Organization Designer のユーザは、テスト目的などで追加の事業単位を作成したり、ディレクトリ統合で管理されていない組織単位の側面を変更したりといったことを自由に行えます。
ディレクトリ統合機能では、サービス チームの自動作成がサポートされていますが、一般的ではありません。サービス チームは、カスタマイズされた人セットが特定のタスクで作業できるように、完全な Service Portal のアーティファクトとして作成されることがあります。Service Portal の外部の企業は、そのような組織に関する知識を持つ必要がないため、こうしたサービス チームや事業単位の作成および管理は管理者が行うことになります。
同様に、ディレクトリ統合では、人へのロールおよびグループの割り当てを、ディレクトリから Service Portal にインポートできます。ただし、多くの場合、ディレクトリにはそのような情報は含まれていません。これは、ロールとグループは一般的に Service Portal のアーティファクトであり、Service Portal を簡単に使用することを目的に作成され、他の企業アクティビティには適用できないためです。したがって、Organization Designer のユーザは、通常、ロール定義と、人、組織、およびグループへのロール割り当ての両方を管理する必要があります。
組織単位は、その組織単位のメンバ(人)が含まれている場合と、キューにリンクされている場合があります。実際は、新しい個人をシステムに追加する場合は、デフォルト(ホーム)の組織単位を選択する必要があります。
サービス チームは、要求されたサービスを提供します。サービス チームは、Organization Designer で作成されたキュー、および Service Designer で作成されたサービス グループにリンクされています。サービス チームは、サービスを提供する人(サービス実行者)で構成されます。サービス グループは、サービス提供のためのチームとシステム プロセスの両方を表します。サービス チームは、サービスのグループを「所有」できるため、これらのサービスの提供に関連する作業の管理を担当します。
サービス実行者は、1 つ以上のサービス チーム OU に属すことができます。実行者のスキル セットに基づいてサービス チームを作成することを推奨します。
事業単位には、サービスを要求および受領する人がメンバとして含まれています。事業単位のみが課金可能であり、サービスの要求を行うと、[Bill To] フィールドの [My Services] に表示されます。したがって、多くの場合、事業単位は会社のコスト センター構造に基づいて構成します。
サービス実行者は複数のサービス チームに属することができますが、事業単位は、サービス チームではなく、個人のホーム組織単位として割り当てることを推奨します。事業単位のみが課金可能であるため、事業単位をホーム OU として割り当てると、実行者が自分自身のためにサービスを要求した場合にコストと料金を適切に追跡し、課金することができます。
(注) すべてのユーザを、1 つの「ホーム」組織単位(OU)に割り当てる必要があります。ユーザを、その他の組織単位に割り当てることができますが、「ホーム」として設定できるのは 1 つだけです。
組織単位を作成すると、次に説明するように、その組織単位を使用して追加データの変更および入力を行うことができます。
|
|
ディレクトリ統合が配置されており、人と組織をリフレッシュするように設定されている場合は、非アクティブ化する組織単位が、企業ディレクトリ内の有効でアクティブなユーザに関連付けられていないことを確認する必要もあります。そのユーザがログインすると、その組織単位は再アクティブ化されます。また、組織単位の非アクティブ化により、その組織単位に関連付けられているキューが非アクティブ化されることはありません。
組織単位の [General] ページで、OU の作成時に提供される情報を編集できます。組織単位をアクティブ化または非アクティブ化したり、サブ組織単位の追加や削除により階層構造をさらに拡張したりできます。
|
|
サービス実行者が事業単位の要求を完了するためにかかった作業時間に対して請求できるかどうかを確認します。このオプションは、事業単位にのみ使用できます。 |
|
Service Portal では、親組織単位と子組織単位の階層構造を作成できます。各組織単位には、1 つの親 OU と、1 つ以上の子(サブ)OU を設定できます。
• 統計情報(SLA コンプライアンスまたは処理されるタスクや要求の量など)は、Advanced Reporting モジュール内でアカウンティングやレポーティング目的で親 OU に統合できます。
• 設計者は、(画面の外観を制御する)さまざまなスタイルを親組織単位または子組織単位に関連付けることにより、ユーザ エクスペリエンスをカスタマイズできます。
• サブ組織単位は、親からロールおよび権限を継承できるため、責任の割り当てが容易になります。
サブ組織単位、およびそのサブ OU のメンバは、その親組織単位に割り当てられているロールと権限をすべて継承します。この継承規則があるため、ロールベースのアクセスは慎重に設定する必要があります。例として、ボトムアップ手法の使用があります。この手法では、最も低い子組織単位に最も多いロールを割り当てる、つまり最大の責任を持たせ、親組織単位に近づくにつれ、割り当てるロールを少なくします。
組織単位に属する人を指定できます。個人は、複数の OU に割り当てられる場合がありますが、持つことができるホーム OU は 1 つのみです。組織単位を個人に関連付けるプロセスは、次のとおりです。
3. 個人を組織単位に関連付けます。個人と OU の関係を作成するには、次の 2 つの方法があります。
– 個人を組織単位に割り当てる:People コンポーネントの [Org Units] ページを使用して個人を追加すると、複数の人を 1 つの OU に割り当てることができます。
– OU を個人に割り当てる:People コンポーネントの [Members] ページを使用して組織単位を追加すると、複数の OU を特定の個人に一度に追加できます。
サービス チームの場合、チームが担当するキューを指定できます。組織単位を個人に関連付けるプロセスは、次のとおりです。
2. キューを作成します。サービス チームを作成する場合、作業を受領するサービス チーム用のキューを作成する必要があります。キューを組織単位に割り当てる前に、まずキューを作成する必要があります。
3. キューを組織単位に関連付けます。キューと OU の関係を作成するには、次の 2 つの方法があります。
– キューを組織単位に割り当てる:組織単位情報内でキューを追加すると、複数のキューを 1 つの OU に割り当てることができます。
– OU をキューに割り当てる:個人の情報内で組織単位を追加すると、複数の OU すべてを特定の個人に一度に割り当てることができます。
キューや個人の名前の左側にあるボックスは、現在の組織がそのエンティティのホームである場合はグレー表示になります。ホーム OU として割り当てられている OU を持つ個人は削除できません。個人を OU から削除するには、その個人エントリを保持して、新しいホーム OU をその個人に再割り当てする必要があります。これで、その個人は非ホーム OU のメンバとして削除できるようになります。
エンティティのホーム所属を変更するには、キューや個人の名前の左側にあるボックスをクリックし、次に [Assign as Home] をクリックします。エンティティ ホーム所属が確立された後に変更するには、Organization Designer の Person コンポーネントまたは Queue コンポーネントの [Organizations] ページに移動する必要があります。
組織単位に関連付けられているキューまたは個人は、その組織のすべての役職に割り当てることができます。エンティティを役職に割り当てる前に、役職が存在している必要があります。Organization Designer には事前定義された役職が複数ありますが、役職を作成して組織単位に関連付けることもできます。
役職と割り当てられた個人との関係を作成する順序は、次のとおりです。
3. 組織単位の [Positions] ページで、その組織単位のメンバであるエンティティ(個人またはキュー)を割り当て、その役職への割り当てを行います。
役職名の左側にある「X」は、その役職が割り当てられていないことを示します。
個人またはキューを役職に割り当てるには、[Assign] ボタンをクリックします。ポップアップ ウィンドウが表示されます。これを使用して、割り当てる個人またはキューを検索および選択できます。
エンティティは、[Unassign] ボタンをクリックして役職から削除できます。タスクの実行またはその他の作業の実行を担当する役職である場合は、未割り当てのまま放置しないでください。
Organization Designer を使用して、組織単位の承認構造、つまり「部門承認」および「部門確認」を設定します。設定機能は、サイト レベルおよびサービス グループ レベルで使用可能な設定機能と似ています。このマニュアルの承認に関するセクションを参照してください。
権限により、どのエンティティが何を組織単位に対して実行できるかを制御できます。次の権限を設定できます。
• Order on Behalf:My Services を使用して事業単位 OU の他のメンバの代理でオーダーできる人を指定します。
• Manage Service Team:Service Manager のナビゲーション ペインのツリー ビューでサービス チーム OU を表示できる人を指定します。
OU の権限を割り当てるには、[Add Permission] をクリックして、[Add Permission] ウィンドウを表示します。次に、追加する権限、および権限を追加するエンティティを指定します。
一般的に、権限は、個々の人に付与するよりも、組織単位、グループ、またはロールに付与する方が、より効率的で管理も簡単になります。
組織単位のすべてのメンバは、その組織単位に割り当てられているロールを継承します。また、サブ組織単位は親組織単位からロールを継承します。
[Show inherited roles] オプションを使用して、親組織単位から継承したロールを表示するかどうかを選択できます。選択しない場合、組織単位に直接割り当てられたロールのみが表示されます。
組織には、作成後に My Services Consumer ロールが自動的に付与されます。これにより、組織(またはサブ組織)のすべてのメンバは、My Services にアクセスし、オーダー権限を付与されているサービスをオーダーできます。(サービスをオーダーする権限は、サービスまたはサービス グループを介して付与されます)。
Request Center で定義されているすべてのロール(Service Portal で提供されるデフォルト ロール、および各インストールで作成されたカスタム ロールの両方)を組織に付与できます。使用可能なロールおよびカスタム ロールの作成方法の詳細については、このマニュアルのロールに関するセクションを参照してください。
ユーザは、通常、ディレクトリ統合によってリフレッシュされる組織定義の部分を変更しないようにする必要があります。変更が必要な場合は、データのソースであるディレクトリのコンテンツに対して変更を適用する必要があります。
組織に対する変更を許可するすべての管理特権は、ホーム以外のサイトでエンティティに適用されるエンティティ保護によってオーバーライドされます。エンティティ保護レベルの設定の詳細については、『 Cisco Service Portal Designer Guide 』を参照してください。
Administration のオプションには、現在の組織でユーザに付与されている読み取り、書き込み、または権限変更の権限が示され、管理者は、これらの権限をカスタム ロールに割り当てることができます。事前作成されたロールにより、関連する権限がすべての組織に付与されます。カスタム ロールや、特定の個人、OU、または役職を追加すると、組織データの読み取りや書き込みの権限をオブジェクト レベルで、つまり組織ベースで 1 つの組織に対して割り当てることができます。
Organization Designer では、権限を使用して選択済みの OU やキューが「非表示」になりませんが、ユーザによる特定の OU やキューの読み取りまたは変更ができなくなります。ユーザが読み取りまたは書き込みを許可されていないエンティティは、イタリック体で示され、そのユーザがそのエンティティにアクセスしようとすると、次のようなポップアップが表示されます。
特定のエンティティの [Administration] ページでこれを直接行うか、または次を実行できます。
1. Access Organizational Unit Configuration および Access Queues Configuration の機能を持つロールを作成します。
2. ロールの [Permissions] ページに移動します。
グループは、サービスの構成、コストの割り当て、権限の割り当て、およびアクセス権の付与をサイトで行う機能を向上するための組織および管理ツールです。グループを使用すると、なんらかの共通の特性を持つ OU や人を単一のエンティティに統合できます。これにより、複数の組織や人ではなく、1 つのグループにロールを割り当てることができます。
グループには、複数のサブグループを含めることができます。サブグループは、親グループに割り当てられているメンバやロールを継承します。
|
|
グループ情報の [General] で、グループ作成時に提供される情報を編集できます。グループをアクティブまたは非アクティブにしたり、サブグループの追加や削除により階層構造をさらに拡張したりできます。
サブグループにより、親グループと子グループの階層構造を作成できます。各グループには、1 つの親グループと、1 つ以上の子(サブ)グループを設定できます。サブグループは、親グループ内でグループ化されます。
サブグループおよびサブグループのメンバは、その親グループに割り当てられているロールと権限をすべて継承します。この継承規則があるため、ロールおよび権限システムは慎重に設定する必要があります。例として、ボトムアップ手法の使用があります。この手法では、最も低い子グループに最も多いロールを割り当てる、つまり最大の責任を持たせ、親グループに近づくにつれ、割り当てるロールを少なくします。
グループ メンバは、組織単位と個々の人の組み合わせで構成されています。グループに属する人および組織単位を指定できます。グループを個人または OU に関連付けるプロセスは、次のとおりです。
2. 人または組織単位を作成します。個人または OU をグループに割り当てる前に、まずシステムで個人または OU を作成する必要があります。
ロールをグループに割り当てると、そのグループのすべてのメンバがそのロールを継承します。また、サブグループは親グループからロールを継承します。[Show inherited roles] オプションを使用して、親グループから継承したロールを表示するかどうかを選択できます。選択しない場合、グループに直接割り当てられたロールのみが表示されます。
ロールをグループに割り当てる前に、まずそのロールが存在していることを確認する必要があります。Service Portal では、複数の事前設定済みロールが提供されており、これを使用できますが、会社のニーズを満たす新しいロールを作成することもできます。
権限は、個々の人または組織に割り当てるのではなく、グループに割り当てることができます。これは、異なる人や組織をグループ化し、同じ権限を付与するための方法です。
Service Designer では、グループは、サービス グループ、サービス、およびフォーム グループに関連するオブジェクトレベル権限を付与するときに 直接 使用できます。これらのオブジェクトレベル権限は、次のとおりです。
|
|
グループは、ディクショナリのアクセス コントロールを割り当てるときに、追加の参加者として使用することもできます。
また、グループはロールのメンバになることもできるため、ロールを使用できるときは、グループを 間接的に 使用することもできます。たとえば、条件付きルールには、ユーザ ロールおよびカスタマー ロールの条件タイプが含まれています。この場合、グループを作成し、それをロールのメンバにし、条件付きルールの条件を定義するときに使用できます。
Organization Designer では、ロールを使用して作業する場合は、そのロールを付与する人や OU をひとまとめにするためにグループを使用できます。
最後に、Organization Designer でオブジェクトレベル権限を OU や人に割り当てる場合も、グループを使用できます。
キューはリポジトリであり、実行する必要があるタスクの「受信ボックス」として機能します。作業はキューに割り当てられるため、タスクは 1 人のユーザに依存しません。
キューの作成後、キューへのアクセス オブジェクトレベル権限を使用して、キューに送信されたタスクにアクセスできる人を指定します。人は、キューの「メンバ」ではありません。キューへのアクセス権を使用してキューを操作するだけです。キューへのアクセス権を持つ人はすべて、そのキューに割り当てられているタスクを実行できます。キューのホーム OU であるサービス チームのメンバは、キューへのアクセス権限を自動的に付与されます。
Service Portal では、1 つの事前設定済みキュー(デフォルトのサービス提供キュー)を提供しています。タスクがタスク実行者に割り当てられていないか、またはタスクの動的割り当てに使用される名前空間が有効なキューに評価されない場合、そのタスクはデフォルトのサービス提供キューに配置されます。
キューの定義は、次に要約されている [Queue] ページに入力する情報で構成されます。
|
|
• キューは、サービス チームにマッピングされます。サービス チームはキューのホーム OU としてのみ使用します。
• 各サービス提供タスクは、タスク実行のためにキューにマッピングされる必要があります。
• キューのカレンダーおよび時間帯が正しく設定されていることを確認します。Request Center では、タスクが割り当てられているキューのカレンダーおよび時間帯設定に基づいてタスクの期日を計算します。
キューの [General] ページでは、キューの作成時に提供された情報を編集できます。キューをアクティブまたは非アクティブと見なしたり、キューの時間帯を設定したりできます。
キューに割り当てるサービス チームを指定できます。新しいキューを作成した場合は、デフォルト(ホーム)の組織単位を割り当てる必要があります。複数のサービス チーム OU が 1 つのキューを担当できますが、1 つのキューが持つことができるホーム OU は 1 つのみです。組織単位とキューとの間にアソシエーションを作成するには、次のいずれかの方法を使用します。
管理者は、特定のキューに割り当てられているタスクの提供に問題が発生した場合、キュー連絡先情報を参照できます。さまざまな連絡先タイプ(電子メール、電話番号)が提供されています。複数の電子メール アドレスを、キュー連絡先の [Email] フィールドに入力できます。電子メール アドレスは、セミコロンで区切る必要があります(jdoe@company.com;dsmith@company.com など)。
[Calendar] ページを使用して、勤務時間と勤務日を設定し、非勤務日と休日を割り当てます。カレンダー情報を使用して、キューの作業時間に応じたタスクおよびサービスの期日を計算します。
新しいキューの場合、作業スケジュールは、[Calendar] ページの [Time Schedule] 部分で示しているように、キューに指定された時間帯([General] ページで指定)で週 5 日、午前 8 時~午後 6 時にデフォルトで設定されます。この勤務時間に必要な変更を加えることができます。
• HH:MM AM/PM 形式を使用して、[From] フィールドと [To] フィールドに時間を入力します。
• [From] フィールドと [To] フィールドに同じ時間(12:00 AM と 12:00 AM など)を入力して、作業しない日を指定します。
[Calendar] ページの [Additional Dates] 部分を使用して、特定の日を休日または勤務日としてタグ付けすることができます。[Add New] を選択して、新しい日付を追加します。カレンダー アイコン( )から選択して日付を入力し、その日付の名前を指定し(内部ドキュメンテーション用)、[Holiday] または [Working Day] のタイプを指定してから、[Update] をクリックします。追加したこれらの日付も、タスクおよびサービスの期日の計算時に考慮されます。
権限により、キューへのアクセス権限を付与する対象を制御できます。キューにアクセスすることにより、ユーザは、Service Manager で特定のキューのタスクを確認および実行できます。
デフォルトで、一部の事前設定済みロールは、自動的にすべてのキューにアクセスできます。このため、これらのいずれかのロールを付与されているエンティティ(個人、組織、またはグループ)はすべて、キューにアクセスできます。また、キューに関連付けられている OU のメンバは、自動的にそのキューにアクセスできます。
人はすべて、My Services を介してサービスを受領するか、または Service Manager を介してサービスを提供する個人であり、すべての管理者、マネージャ、およびその他すべてのアプリケーション モジュールのユーザでもあります。
システムのユーザであるすべての個人を、その個人が組織の内部関係者であるか外部関係者であるかに関係なく、設定する必要があります。次の 2 つの文は重要です。
• 個人は、1 つの OU の「ホーム」にだけ設定できます。
Service Portal では、人を追加するために次の 3 つのメカニズムが提供されています。
• Organization Designer では、管理者は、このセクションで説明しているページを使用して、個人をインタラクティブに作成できます。
• ディレクトリ統合の Import Person イベントにより、個人およびそのホーム OU を作成できます。詳細については、『 Cisco Service Portal Integration Guide 』を参照してください。
• サービスのワークフロー(提供計画)で使用可能なディレクトリ タスクにより、サービス フォーム データに基づいて個人を作成できます。詳細については、『 Cisco Service Portal Designer Guide 』を参照してください。
個人が作成された方法に関係なく、その個人情報は Organization Designer を使用して管理できます。
新しい個人を作成したら、デフォルト(ホーム)の組織単位をその個人に割り当てる必要があります。したがって、新しい個人を作成する前に、組織単位を作成しておく必要があります。
システムへのログインに使用するパスワード。Organization Designer を使用している場合は、確認のためにパスワードを再入力します。アプリケーションでサポートされている文字セット内の任意の文字をパスワードに使用できます。 |
|
|
個人情報の [General] ページで、次の情報を編集できます。
個人のプライマリ アドレスに関連付けられている時間帯。これは、個人の時間帯に応じてタスクおよびサービスの適切な期日を計算および表示するために使用されます。 |
|
従業員のスーパーバイザ。これは、特定の承認など、「スーパーバイザ」タスクに使用されます。Service Designer を使用して、これらのタスクを作成します。 |
|
個人を作成した場合は、デフォルト(ホーム)の組織単位をその個人に割り当てる必要があります。個人は 1 つのホーム OU しか持つことができませんが、複数の組織単位のメンバになることができます。組織単位と人との間にアソシエーションを作成するには、次のいずれかの方法を使用します。
• それぞれの個人の情報の [Org Units] ページを開き、組織単位をその個人に割り当てます。
これらの方法は機能的に同等であるため、便利な方を選択してください。
個人ごとに、会社や個人のアドレス、および特定のロケーション情報を入力できます。
個人に関する有効な情報を持つことは、次のことを行うために重要です。
• タスク実行者は、ワークステーションのハードウェア構成の変更など、特定の個人へのサービスを実行する必要がある場合にその個人を検索できます。
• 提供計画では、動的に評価される式を使用して、サービスの要求者が位置する領域にサービスを提供するキューに作業をルーティングできます。このような「ロケーションベースのキュー」は、地理的に分散した組織で一般的です。
個人と連絡を取るための複数の方法を入力できます。それぞれ電話、ファクス、ページャ番号などの連絡先タイプで識別されます。
• 個人の作成時に指定した電子メール アドレスが、最初の連絡先として表示されます。この電子メール アドレスは、変更は可能ですが削除はできません。このことは「グレー表示」のチェックボックスで示されます。
• 電子メール アドレスを除くすべての連絡先タイプは、個人の連絡先情報に追加することも、そこから削除することも自由にできます。
拡張機能の主な目的は、LDAP 属性を「個人レコードの拡張」にロードして、この属性から条件付きワークフローを使用できるようにすることです。拡張機能により、個人に関するその他の情報を追加できます。この情報は、会社の業務や財務コードおよび構造に合わせて調整できます。たとえば、個人の部門やコスト センターの番号または名前を入力できます。また、検索時など、個人のプロファイル情報を表示するときに表示される個人の画像をアップロードできます。
個人プロファイルのほとんどのフィールドはアプリケーション処理に使用されるため、マッピングでは、ソース属性により適切な値がフィールドに指定されるようにする必要があります。これらのフィールドは、フィールド名で示されている以外の情報や、フィールド名に一致しない情報でオーバーロードしないでください。
Service Portal には、標準の個人データに対する拡張を指定するフィールドも含まれています。これらのフィールドは、個人情報の [Extensions] ページに表示されます。頻繁に必要となる拡張フィールドの一部には、意味のある名前が割り当てられていますが(Company Code や Division など)、その他のフィールドには Custom 1 ~ Custom 10 という名前が付けられており、事前に想定されたセマンティックスはないため、自由に使用できます。Request Center で公開する必要がある追加の個人情報が LDAP ディレクトリにある場合は、その情報を含む属性をいずれかの個人拡張フィールドにマッピングします。
「Custom」を別のフィールド名に変更することはできません。ただし、これらのフィールドがサービス フォームに含まれている場合は、フィールドの内容を正しく反映したラベルを割り当てることができます。
カレンダー情報により、個人のアベイラビリティを設定できます。個人の勤務スケジュールを、曜日ごとの勤務時間まで詳しく入力します。また、休日や、個人が作業できないその他の日を指定できます。サービス グループ メンバの場合は、この情報を使用して、タスクの実行にかかった勤務時間を計算し、タスクの提供が予定どおりであったか、または遅延したかを判別します。
ローカル時刻および時間帯には、[General] ページで個人に割り当てられた時間帯が反映されます。
• [Time Schedule] で、HH:MM AM/PM 形式を使用して、[From] フィールドと [To] フィールドに時間を入力します。
• [From] フィールドと [To] フィールドの両方に同じ時間(12:00 AM など)を入力して、勤務日ではない日を指定します。
休日が通常の勤務日である曜日にあたる場合は、その日をタイプ [Holiday] の [Additional Date] として指定します。反対に、勤務日が通常の勤務日ではない曜日にあたる場合は、その日をタイプ [Working Day] の [Additional Date] として指定します。
個人は、モジュール メニューの横に表示される [Profile] オプションを使用して独自のカレンダーにアクセスできます。
権限により、選択した個人に影響するオブジェクトの機能を定義します。これらのオブジェクトには、組織単位、グループ、その他の 人 、ロール、および役職があります。人の場合、選択した個人の代理でオーダーできる人を定義するための権限を設定できます。
[Permissions] ページでは、承認者が承認の責務を果たすことができない場合(承認者が休暇中の場合など)に備えて、選択した個人の代理承認者も指定します。代理者は、[Delegation Start Date] フィールドと [Delegation End Date] フィールドを使用して指定した期間中、個人に代わって承認を実行できます。
個人は、[Profile] オプションの [Preferences] ページを使用して、独自の代理承認者を割り当てることができます。代理者は、異なる期間で何度も指定される可能性があるため、Organization Designer を使用して指定するよりも、個人が独自の代理者を指定する責任を持つようにすることを推奨します。
個人の代理承認者を割り当てるには、次に要約されている情報を指定します。
代理機能を使用している場合は、次のことに留意する必要があります。
• 代理者は、次回の承認に関する通知を自動的には受信しません。代理者に通知するには、適切な名前空間(#Alternate...#)を電子メールの [To:] フィールドに使用する必要があります。有効な代理者がいない場合、通知における名前空間の値は空白になります。
• 委任された承認タスクに関して代理者がアクション ボタン([Approve]、[Reject]、または [OK])をクリックすると、代理者はそのオーナーになります。つまり、タスクの所有権が、アクション ボタンをクリックしたユーザに実際に移行します。
• この所有権の移行後、元の承認者がそのタスクを「確認」できるかどうかは、そのロールおよび OU メンバーシップによって決まります。完了した承認タスクを(My Services で)確認するには、元の承認者が My Services Professional ロール(または、少なくとも「View Authorizations for My Units」機能を持つロール)を付与されており、承認を実際に行う個人と同じ OU に属している必要があります。
個人とロールの関係を作成するには、次の 2 つの方法があります。
• ロール(複数可)を個人に割り当てる:個人情報内にロールを追加すると、複数のロールを 1 人の特定の個人に一度に割り当てることができます。
• 個人をロールに割り当てる:ロール情報内に個人を追加すると、複数の人を 1 つのロールに割り当てることができます。ロールに割り当てる人を確認します。
ディレクトリ統合が配置されており、人と組織をリフレッシュするように設定されている場合、またはシングル サインオンを実行するように設定されている場合は、非アクティブ化する個人が、企業ディレクトリ内のアクティブなユーザではなくなっていることを確認する必要もあります。そのユーザがログインすると、その個人エントリは再アクティブ化されます。
個人が Service Portal でなんらかのアクティビティを実行すると、その個人エントリは削除できなくなります。個人を非アクティブ化することにより、ログインやその他のアクティビティを実行できないようにすることができます。
役職により、サービスの提供計画を設定したり、Service Portal アプリケーションのさまざまな側面に責任を割り当てたりする場合の柔軟性を高めることができます。システム内のタスクを役職に割り当てることができます。次に、人、キュー、またはロールを割り当て、その役職への割り当てを行うことができます。役職は、(タスク実行者として割り当てられた)タスクや、(適切な個人または人に送信された電子メールに含まれる)名前空間で参照できます。
役職は、次の 3 つのエンティティ タイプのいずれかと関連付けることができます。
Service Portal では、複数の標準の役職を提供しており、これらは変更できません。下の図では、システム定義の役職の左のチェックボックスがグレー表示され、これらの役職が削除または更新できないことを示しています。「Queue Approver」の役職は、このサイトで作成されました。
各エンティティ タイプに関連付けられている役職は、対応するエンティティ タイプを管理するために [Organization Designer] または [Service Designer] ページに表示されます。たとえば、組織に関連付けられている標準の役職の場合、組織を管理するための [Positions] ページは次のようになります。
システム定義の役職が会社の要件を満たさない場合は、新しい役職を作成できます。[Functional Position] ページの [Add] ボタンをクリックします。新しい行が役職のリストの下に表示されます。
役職に割り当てる名前には、許可されている場合でも、スペースを含めることはできません。スペースが含まれた名前は、名前空間の変数として使用できません。[Type] を選択して、役職を組織単位、サービス グループ、またはサービスに関連付けます。
• 標準の役職では、その役職名の横にあるチェックボックスがディセーブル(「グレー表示」)になっており、使用しない場合でも削除できません。
• 役職のアソシエーションは更新できません。サービス グループからサービスへの変更など、アソシエーションを変更する必要がある場合は、その役職を削除して、新しい役職を作成する必要があります。[Used] カラムのチェックマーク( )で示されている、使用中の役職は削除できません。
システム定義の標準の役職は削除できません。これは「グレー表示」のチェックボックスで示されます。使用中である場合も削除できません。これは [Used] カラムのチェックマークで示されます。ただし、使用されなくなった役職は削除する必要があります。不要な役職を削除するには、それらにチェックマークを付け、[Remove] をクリックします。
Service Portal では、「ロールベース アクセス コントロール」(RBAC)が提供されています。これにより、管理者は、特定のモジュールにアクセスできる人、組織単位、またはグループを制御したり、各モジュールで実行できる機能を制御したりできます。さらに、このような権限が特定のタイプのすべてのエンティティ(オブジェクト)で機能することを許可したり、指定したエンティティ セットに制限したりすることもできます。
したがって、ロールにより、モジュールへのアクセスと、1 つ以上の機能、および場合によっては 1 つ以上のオブジェクトレベル権限とが結合されます。
• [Permissions]:オブジェクトを操作できる権利を付与します。
• [Capabilities]:モジュール内で特定の機能を実行するための方法を提供します。
Service Portal では、複数のシステム定義ロールが提供されています。このロールにより、複数の機能が、Service Portal 実装の参加者に通常割り当てられる責任ごとにまとめられます。サイト管理者は、カスタム ロールを使用してこれらのロールを補強し、特定の実装チームの責任区分に適合するようにします。
ロールはコンテナの階層構造を使用して構成され、フォルダに非常によく似ています。この構造により、子ロールが親ロールから機能、権限、およびメンバを継承する、ロール間の親子関係を作成できます。
コンテナとロールは、その名前で区別されます。「Roles」で終了する名前はコンテナです。オレンジのアイコンは、 システム定義 ロールであることを示しています。
|
|
|
Service Portal では、一般的な企業が各ユーザに対して必要とする大半の使用例を反映したシステム定義ロールが提供されています。通常は、これらのロールはほとんどの会社のロール要件を満たしています。システム定義ロールには、 のマークが付いています。ITIL(IT インフラストラクチャ ライブラリ)ガイドラインに準拠して分類および割り当てられた機能であるロールには、注釈が付いています。
これらのシステム定義ロールのいずれかがニーズに合わない場合は、新しいロールを作成するか、またはより簡単な方法として既存のロールをコピーしてニーズに合うように変更できます。
次に、システム定義ロールの階層構造を示します。ロール名をクリックして、ロールに関する簡単な説明、および関連付けられている機能のリストを表示します。モジュール単位の機能リストを表示することもできます。
上記の表の下にリストされている「Anyone」ロールと「Site Administrator」ロールは、ITIL ロール構造に適合しません。これらのロールは、Service Portal 固有のアクセス コントロール機能を提供します。
「Anyone」ロール(ロールの説明をカッコで囲みます)は、「機能およびオブジェクトベース権限を論理上全員(すべての人)に割り当てることをサポートするために作成された特別なロールです」。すべての個人が、自動的に Anyone ロールのメンバになります。メンバのリストは変更できません。
小規模なインストール環境では、すべてのサービスをオーダーする機能を Anyone に割り当てるのが有用な場合があります。他の権限または機能を割り当てるときは、慎重に検討してください。Service Portal にアクセスできるすべての個人が、それらのロールや機能により提供される機能を実行できるようになります。
「Site Administrator」ロール(ロールの説明を再度カッコで囲みます)は、「Site Administration 組織単位のメンバであるすべてのユーザに自動的に割り当てられるロールであり、Request Center および Demand Center のすべての機能と権限を提供します」。「admin」ユーザは、自動的に Site Administrator ロールのメンバになります。その他のメンバに割り当てる場合は、このロールにより付与される能力を考慮して慎重に行う必要があります。
[Roles] タブの [Search] ボックスにロール名の一部またはすべてを入力して、ロールを検索できます。
[Search Results] リストで、[Item Hierarchy] アイコンをクリックして、ロールのツリー ビューにおける正確な位置を表示します。
上記の例では、「My Services Consumer」が [Search] フィールドに入力されています。このロールが見つかり、[Search Results] タブにリストされています。階層アイコンをクリックして、このロールが、[Request Fulfillment Roles] の [Request Self-Service Roles] コンテナに存在することを確認できます。
ロール名をクリックして、名前や説明、ロールに割り当てられているエンティティ、含まれている機能、オブジェクトレベル権限などの一般的な詳細情報を表示し、どのエンティティがこのロールへのアクセス権を持つかを設定します。
[Roles] タブを使用して、ロールの検索、表示、作成、変更、非アクティブ化、または削除を実行します。作業するロールを検索すると、次の 5 つのセクションが表示されますが、これらに精通する必要があります。
ロールのメンバは、そのロールに割り当てられた個々の人、グループ、および組織単位で構成されます。グループまたは組織単位が割り当てられている場合、そのグループまたは組織単位のすべてのメンバがそのロールを継承します。また、サブ組織単位およびサブグループはその親からロールを継承します。[Show inherited roles] オプションを使用して、親組織単位または親グループからロールを継承したメンバを表示するかどうかを選択できます。選択しない場合は、そのロールに直接割り当てられた組織単位およびグループのみが表示されます。
個人、グループ、または組織単位をロールに割り当てる前に、まずそのエンティティが存在していることを確認する必要があります。
ロールとメンバのアソシエーションを作成するには、次の 2 つの方法があります。
• それぞれの個人、グループ、または組織単位に移動して、ロールを割り当てます。
上記の画面は、すべての OU に自動的に付与され、継承によりすべての OU 内のすべての個人に付与される My Services Consumer ロールです。
|
|
すべてのモジュールにオブジェクトレベル権限を持つオブジェクトが含まれているわけではありません。つまり、すべてのロールにオブジェクトレベル権限が割り当てられているわけではありません。オブジェクトレベル権限が含まれているロールの例として、「Service Team Administrator」ロールがあります。このロールは、[Request Fulfillment Roles] > [Fulfillment Management Roles] コンテナにあります。「Service Team Administrator」ロールには、次のように 2 つのモジュールにわたる機能が含まれます。
このロールが、Service Manager の管理アクションすべてをイネーブルにし、 かつ Organization Designer でサービス チームとキューを作成して管理する機能をイネーブルにすることを目的としている場合は、次に示すように、このロールではオブジェクトレベル権限を組織単位、人、およびキューに付与する必要があります。
「機能」とは、Service Portal 内の特定の機能を実行できる能力のことです。事前定義済みロールを適切なユーザに割り当てたり、カスタム ロールを作成するニーズを認識したりするために、使用可能な機能について確認し、かつそれらが事前定義済みロールでどのように結合されているかを確認すること重要となります。
使用可能な機能をオンラインで簡単に確認するには、カスタム ロールを作成する「ふりをして」、[Add Capabilities] をクリックし、表示されるリストをブラウズします。機能はモジュールごとに分かれています。これは、各機能により特定のモジュール内で機能を実行する権利が付与されるためです。
My Services の機能は、サービスのオーダー、要求の表示、および My Services モジュールで使用可能なタブやリンクへのアクセスに関連します。
Service Designer の機能により、さまざまなユーザ セットがサービス定義のさまざまな側面で作業できます。異なるサービス セットやサービス グループ セットで作業するさまざまなユーザ セットに権限を割り当てる機能と併用すると、分散開発環境に対する堅牢なサポートを提供できます。
Service Link の機能により、異なるセットのユーザを、実稼動環境で統合ステータスをモニタリングする管理者ではなく、統合開発者として指定できます。
Reporting の機能により、権限を持つユーザは Reporting および Advanced Reporting モジュールにアクセスしてレポートを開発できます。
Service Manager モジュールにより、タスク実行者は割り当てられた内部タスクを表示および更新できます。タスク マネージャは、タスクの割り当てやスケジュールを管理するだけでなく、タスクを表示または更新することもできます。
Organization Designer の機能により、人、組織、キュー、ロール、役職を管理するためのオプションへのアクセス権が付与されます。これらのオプションは、ディレクトリ統合(『 Cisco Service Portal Integration Guide 』を参照)やディレクトリ タスクの実行(『 Cisco Service Portal Designer Guide 』を参照)によって提供されるオブジェクトの管理機能を補足しています。オブジェクトレベルの権限とともに使用すると、特定の組織エンティティへの読み取り権や書き込み権がユーザに付与され、複数テナント環境で細かい制御が可能になります。
Administration モジュールでは、すべてのオプションの個々の機能は使用できません。機能の範囲外のオプション([Debugging] ページへのアクセスなど)については、Site Administrator ロールがユーザに付与されている必要があります。
Catalog Deployer の機能により、権限を持つユーザは Catalog Deployer モジュール内でパッケージを構築および展開できます。
|
|
Portal Designer および Portal Manager を使用するための機能の詳細については、Portal Manager を参照してください。
Organization Designer には、事前定義された多数のロールが用意されています。これらのロールは、一般的な企業がユーザに対して必要とするほとんどのロールに適しています。ただし、追加のロールが必要な場合は、新しいロールを最初から作成するか、既存のロールをコピーしてニーズに合うように変更することによって、カスタム ロールを作成できます。
機能および権限の使用可能な組み合わせは非常に多いため、これらの組み合わせを把握しておくことは困難な場合があります。このため、必要なすべての機能またはほとんどの機能が含まれているシステム定義ロールを特定して、新しいロールを作成することを推奨します。子ロールから機能を削除することはできないため(子ロールは親ロールからすべての機能を継承します)、必要以上の機能を持つシステム定義ロールは使用しないでください。
– 類似したロールをコピーし、新しいロールのテンプレートとして使用します。
2. ユーザ定義ロールを、システム定義ロールの子ロールにします。
カスタム ロールの場合は、[General] ページで、ロールの作成時に表示される情報を編集できます。親ロールの割り当て、ロールのアクティブ/非アクティブの設定、ロールの説明の追加を行うことができ、変更が生じた時点で変更内容を記録できます。また、サブロールを追加または削除することによって、階層構造を作成することもできます。
サブロールを使用すると、親ロールと子ロールの階層構造を作成できます。各ロールには、1 つの親ロールと 1 つ以上の子(サブ)ロールの両方を設定できます。サブロール階層を作成するときは、カスタム ロールのみを使用できます。システム定義ロールの階層構造は変更できません。
サブロール、およびそのサブロールのメンバには、親ロールに割り当てられたすべての機能が継承されます。この継承ルールのため、ロール システムの設定は十分に注意して行ってください。
機能は、特定のモジュールで実行できるアクティビティを定義します。システム定義ロールの機能は事前に定義されており、変更できません。カスタム ロールには、目的の機能を指定できます。
権限は、特定のモジュール内で組織単位やグループなどのオブジェクトに権限を付与します。これには、オブジェクト固有の権限だけでなく、他のモジュールに対する読み取り/書き込みアクセス権も含まれます。次の作業を行います。
|
|
|
このサービス グループでサービスおよび他の情報を表示できるユーザ |
||
オブジェクトレベルの新しい権限をカスタム ロールに追加するには、上記の表を使用して次の項目を選択します。
All objects of this type:たとえば、組織単位を選択すると、すべての組織単位がこの権限に割り当てられます。 |
システム定義ロールでは、ロールに割り当てられたメンバおよびロールへの読み取り/書き込みアクセス権のみを変更できます。カスタム ロールについては、適切な管理権限を持つユーザが、機能および権限を含めすべての変更を行うことができます。
顧客が直面する問題には、サポート チームが対応します。このチームは、すべての要求を表示できる必要がありますが、それに対する変更は行いません。このロールには、すべての要求への読み取りアクセス権が必要です。
1. 機能 Perform Global Delivery Search を使用して新しいロールを作成します。これにより、このロールのすべてのメンバが、Service Manager モジュールにアクセスしてすべてのタスクおよび要求を検索できるようになります。
上記のセクションのオブジェクトレベル権限で説明している事前設定された「Service Team Administrator」ロールでは、ロールのメンバは、サービス チームを管理したり、組織単位やキューに関する情報を変更したりできます。
このロールは、同じ機能を提供しながら、各タイプの「すべてのオブジェクト」ではなく、特定の組織単位およびキューの作業にメンバが限定されるため、カスタム ロールにコピーする最適な候補といえます。組織でサービス チームを管理する役割は、複数の Service Team Administrator ロールに分割でき、ロールごとに異なるセットの組織およびキューを管理できます。組織が階層構造になっている場合は、親組織を特定の権限のオブジェクトとして指定するだけで十分です。子オブジェクトもすべて同じ権限になります。
多くの要求(すべてではない)が Remedy などの外部システムに統合されているとします。Remedy アプリケーションで作業を行うアナリストは、Remedy への統合を含む Request Center 要求を確認できる必要があり、このような要求に添付ファイルやコメントを追加できる必要がある場合があります。
1. たとえば、Service Team タイプの OU を Remedy Team という名前で作成します。
2. これらの要求にアクセスする必要があるすべての人を、この OU のメンバにします。
3. Remedy Team OU に所属するキューを作成し、 Remedy Team という名前を付けます。これで、対応する名前のキューに対するキューへのアクセス権限が Remedy Team OU に自動的に付与されます。
4. Remedy 統合が提供計画の一部となっているサービスには、タスクを追加します。
a. Remedy Team キューに実行者を割り当てます。
これは次の仕組みで動作します。Request Center は、ユーザが要求と「関連」しているか(つまり、ユーザが顧客または開始者であるか、あるいは 要求の提供において何らかの役割を果たすか )どうかに基づいて、要求へのアクセス権を付与します。個人が要求におけるタスクの実行者である(または実行者であるキューへのアクセス権を持つ)場合、その個人は要求にアクセスできます。
組織の複数の部門にまたがる Request Center の実装では、サービス設計の役割を複数の開発者グループに分散することが望ましい場合があります。別のグループが管理する設計コンポーネントが偶発的または意図的に変更されるのを防ぎながら、別のグループで作成およびテストするサービスまたはサービス コンポーネントを再利用して、開発者の互いの作業を活用できるのが理想的です。
このような環境は、Service Designer コンポーネントに関連付けられた権限を使用することで確立できます。カスタム ロールは、開発グループごとに設定できます。(サービス チームまたはグループのメンバーシップを使用して、メンバを直接的または間接的に割り当てることができます)。Service Designer では、そのロールは次の操作を実行できます。
• このサービス グループ(チームが管理するサービスを含むサービス グループ)でサービスを設計する
• 関連するサービス グループまたは興味深い技法を持つグループでサービスを表示する
• サービスに含める必要がある可能性のある他の(共通?)グループでフォームを表示する
すでに存在する Service Designer ロールをカスタム ロールに付与するのではなく、適切な Service Designer 機能をロールに付与することを推奨します。この方法は設定には手間がかかることがありますが、柔軟性が向上します。サービスをインポートする権限をグループに付与する場合には、注意が必要です。サービスをインポートすることにより、通常は変更権限がないコンポーネント(ディクショナリまたはフォーム)を上書きしてしまうことがあります。[Import Service] オプションではオブジェクトレベルの権限がチェックされず、すべて上書き(または作成)されます。
Service Portal には、My Services 経由で要求を送信できるユーザに加え、Requisition API(RAPI)を使用して Web サービス要求経由で外部システムから要求を送信できる機能が用意されています。このような要求では My Services がバイパスされるため、オーダー時点でサービス フォームが表示されることはありません。したがって、対話形式でオーダーするサービスとは設計が異なる必要があります。たとえば、ルールや JavaScript 関数にデフォルト値を設定できず、チェックボックスやドロップダウン リストなどの複数オプション フィールドは使用できません。
これらの制限により、RAPI 経由でのみオーダー可能な一連の並列サービスを作成することがあります。このようなサービスは、管理者ではないユーザのサービス カタログに表示されることはありません。代わりに、オーダー権限は管理者に対してのみ付与されます。RAPI サービスは、重要な機能である「Order My Services for Others」が割り当てられたユーザによって常にオーダーされます。この場合の「Other」は、要求の顧客として指定されます。
承認は、割り当てられた承認者に対してサービス要求の拒否または承認を求めるタスクです。確認は、実行者に対して提供プロセスのステップの確認を求めるタスクです。
Request Center では、複数のタイプの承認と確認をサポートしています。
サービス チーム マネージャによる購買承認のための承認。通常、サービス チーム マネージャは、自分のサービス チームに所属する人を承認します。 |
|
1. まず、Administration モジュールを使用して、使用可能にする承認およびその実行順序を指定します。
サイトごとに承認タイプを 5 つまでイネーブルにすることができます。実行の順序を変更するには、正しい順序になるまで [Authorization/Review] の右にある上矢印または下矢印をクリックします。
承認または確認のタイプがイネーブルになっている場合は、このタイプに対して詳細を指定できます。承認の詳細は、次のように定義できます。
• サイト レベル([Administration] > [Authorizations] オプションを使用)
• 組織ごと([Departmental Authorization] または [Departmental Review] 用)
• サービス グループまたはサービス単位([Service Group Authorization] または [Service Group Review] 用)
[Departmental Authorization] または [Service Group Authorization] では、次の選択肢があります。
• Administration で作成されたサイト全体の承認構造のみを使用します。
• 組織単位またはサービス グループ用に確立された承認構造のみを使用します。
• サイト全体の承認構造を使用しますが、組織単位またはサービス グループ固有の承認で補足します。
サイトの承認構造のみを使用することを選択した場合、以降の手順は必要ありません。それ以外の場合は、設定する承認タイプを選択できます。
• An authorization:承認時間内に承認が順番に処理されます。各承認者は、要求を拒否または承認する必要があります。要求が承認されると、次の承認または提供プロセスの次のステップに渡されます。要求がキャンセルされると、以降のタスクは実行されません。
• A review:承認時間内に確認プロセスが同時に実行されます。確認者は、[OK] をクリックするだけで要求を確認したことを示すことができます。確認者には、提供を停止する権限はありません。
(注) すべての承認タスクと確認タスクは、提供プロセスが開始する前に完了する必要があります。
エスカレーションとは、指定された期間内に実行されなかった特定のアクティビティにフラグを立て、解決のために適切な実行者、スーパーバイザ、または顧客に送信するプロセスのことです。受信者は、遅延タスクの通知を電子メール形式で受け取ります。
エスカレーション プロセスを設定するときは、次の点に注意してください。
• エスカレーション リストの各行は、層を表します。層はいくつでも指定できます。[Add] をクリックして、別の層を追加します。(対応するチェックボックスをオンにして [Delete] をクリックすると、層を削除できます)。
• 最初の層は、タスクが標準期間を超えた場合に最初に通知されるグループを表します。時間([After (hours)])は、期日が過ぎて通知が送信されるまでの時間数を表します。
• 最初の通知後の、後続の層に指定された時間は、前のエスカレーション以降の経過時間を表します。たとえば、2 番目の層の時間が 8 時間である場合、最初の通知の送信後に解決されず 8 時間が経過すると、2 番目のグループに通知が送信されます。
• 層ごとに 3 人までの受信者がエスカレーション通知を受信できます。[Recipient] ボックスごとに、有効な電子メール アドレスをカンマで区切って入力します。#変数# タイプの名前空間参照も使用できます。たとえば、#Perfomer.Manager.Email# は、タスク実行者のマネージャに通知を送信します。
– 受信者ごとに、対応するドロップダウン ボックスを使用して、受信者への通知に使用する電子メールを選択します。通知は、Administration モジュールで作成されたテンプレートから派生します。
実際には、エスカレーションは、ワークフロー マネージャである Business Engine の一部である Escalation Manager によって送信されます。デフォルトでは、通常の勤務時間中に、関連するエスカレーションが指定された遅延タスクが、Escalation Manager により 1 時間に 1 回(正時)チェックされます。したがって、上記で示しているように、承認が指定時間遅れた後で電子メール通知が送信されるというのは必ずしも正確でありません。通知が実際に送信されるのは、エスカレーション期間が期限切れとなった後で Escalation Manager による遅延タスクのチェックが次に行われたときです。たとえば、承認が午後 12:30 に予定されており、エスカレーション通知をその 1 時間後(午後 1:30)に送信するよう設定されている場合、通知が実際に送信されるのは、Escalation Manager の実行が次に行われる午後 2 時となります。
管理者は、Escalation Manager の設定を変更できます。これを行うための手順については、「システム管理」を参照してください。