この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章は次のトピックで構成されています。
Organization Designer は、サービス組織を構築するための主要ツールです。このモジュールでは、Service Catalog 実装の次のコンポーネントをセットアップし、保守します。
(注) | バージョン 10.0 より前の Service Portal モジュールには、デフォルトで My Workspace および System モジュールのページ グループが含まれていました。これらのページは、10.x で廃止され、Prime Service Catalog が 9.x バージョンからアップグレードされた場合に表示されます。管理者が [Organization Designer] > [ロール(Roles)] > [任意のユーザ(Anyone)] ロールからページの読み取り権限を削除すると、これらのページは無効になり、すべてのユーザに対して非表示になります。 |
Organization Designer モジュールは、Service Catalog のすべてのインストールで使用できます。Organization Designer の使用権限が付与されたすべてのユーザのモジュール ドロップダウン メニューに表示されます。
Organization Designer のホーム ページは、次の領域に分かれています。
ブラウザ ウィンドウの上部にあるナビゲーション バーにより、任意の Organization Designer コンポーネントから別のコンポーネントにすばやく移動したり、Organization Designer のホーム ページに戻ったりすることができます。
特定の組織単位、グループ、個人、キュー、またはロールを表示するごとに、Organization Designer において何をどのコンポーネントで表示したかがナビゲーション トレールに表示されます。このトレールは、ブラウザ ウィンドウの上部に作成され、これにより、Organization Designer での現在の位置およびそれまでの足跡を簡単に把握できます。
Organization Designer の別のコンポーネントに移動するもう 1 つの方法として、後で説明しているように、ホーム ページ検索を使用する方法があります。特定のエンティティ タイプを検索し、そのタイプのエンティティを選択すると、対応するコンポーネントに制御が移ります。
Organization Designer では、さまざまな組織コンポーネントへの移動および検索を支援するために 2 つの検索方法が用意されています。
ホーム ページを使用すると、さまざまなコンポーネントの簡単な検索を 1 箇所で実行できます。ホーム ページ上の [検索(Search)] 領域を使用して、エンティティをタイプ別および名前別(任意)ですばやく見つけることができます。
コンポーネント固有の検索を使用すると、[ホーム(Home)] ページに戻ることなく、特定のコンポーネント内の検索結果を表示できます。これによって、移動することなく、コンポーネントの内部に留まって作業を続けることができます。
各組織エンティティ タイプには独自のホーム ページがあります。ここにアクセスするには、Organization Designer のホーム ページで対応するタブをクリックするか、または対応するタイプのエンティティを検索してから選択します。ホーム ページには、エンティティの [一般(General)] プロパティが表示されます。次に示すグループ例のように、その他のページがコンテンツ ペインの右に示されます。これらのページは、エンティティのタイプによって異なる場合があります。
Organization Designer でのエンティティの作成には、次の 2 つの方法があります。
いずれの場合も、選択したエンティティ タイプの作成ページが表示されます。
このページには、通常、エンティティの作成に必要な属性がすべて含まれています。これらの属性にデータを指定し、[作成(Create)] をクリックすると、そのエンティティが作成されます。これで、標準のページ セットが使用できるようになり、そのエンティティ定義のその他の側面を保守できます。
エンティティの複製方法として、組織エンティティをコピーできます。エンティティをコピーすると、そのエンティティのすべてのプロパティ(そのエンティティのメンバーを含む)がコピーされます。ただし、アイデンティティを固有に識別するプロパティ(組織名または個人の名前やログイン ID など)は除きます。
エンティティをコピーするには、その定義を表示し、[一般(General)] ページの [コピー(Copy)] をクリックします。次に、新しい名前を割り当て、そのエンティティを保存します。新しいエンティティ定義のすべてのページを編集できるようになります。
Organization Designer では、エンティティをシステムから削除することなく、他のモジュール(Service Manager や Service Designer など)内のビューでエンティティを「非表示」にできます。非アクティブなエンティティは、いずれの検索ウィンドウにも表示されません。たとえば、サービス設計者がタスクを特定のキューに割り当てようとすると、アクティブなキューだけが表示されます。エンティティのステータスを変更すると、変更の確認が求められます。
エンティティは、アクティブではなく、使用されていない場合にのみ削除できます。たとえば、提供計画に使用されているキューは削除できません。キューを削除する前に、キューをまず非アクティブ化します。
すべての組織エンティティに [管理(Administration)] ページがあります。エンティティの [管理(Administration)] 部分では、そのエンティティ用に作成されたレコードの表示または編集を実行できるユーザを指定できます。
エンティティに対する管理権限は、指定した組織単位(その組織単位内のすべての人にも継承されます)、役職、キュー、グループ、またはロールに割り当てることができます。加えて、権限は「Anyone」に割り当てることができます。この場合は、Organization Designer にアクセスできるすべてのユーザがそのエンティティの情報を変更できます。「Anyone」。読み取り権限のみを持つ Anyone ロールは、読み取りだけが許可され、変更は許可されません。このロールは追加するとしても慎重に行う必要があります。
次の権限を割り当てることができます。
右 |
説明 |
---|---|
すべて(All) |
ユーザには、エンティティの読み取り(情報の表示)、書き込み(情報の変更と更新)、および権限の変更(読み取り/書き込みアクセス権の変更)の権限があります。 |
読み取り(Read) |
ユーザは、エンティティの情報を表示する権限のみを持ち、情報を変更することはできません。 |
書き込み(Write) |
ユーザは、エンティティの情報を表示および変更する権限を持ちます。 |
権限の変更 |
ユーザは、エンティティへの読み取り/書き込みアクセス権を変更できます。ユーザが変更を許可されていない権限は「淡色表示」になります。 |
システム定義エンティティには、事前設定の管理権限セットが自動的に付与されます。これらのエンティティは淡色表示され、削除や変更はできません。ただし、追加の組織単位、人、ロール、グループ、または役職に管理権限を割り当てることができます。
正常に機能する実装を設定するには、組織エンティティが相互にどう関係しているかを理解することが重要です。次に例を示します。
エンティティ間の依存関係は、Organization Designer でこれらのエンティティを操作する方法に影響します。個々のエンティティ タイプに関する項では、こうした依存関係について詳細に説明します。
原則として、次の組織エンティティは、ディレクトリ統合を使用して作成およびリフレッシュできます。
多くのインストール環境では、事業単位はディレクトリ統合の一部として自動的に作成されます。事業単位は企業エンティティの実際の部門に対応しており、ほとんどの企業ベース ディレクトリの一部である必要があるため、これは理にかなっています。Organization Designer のユーザは、テスト目的などで追加の事業単位を作成したり、ディレクトリ統合で管理されていない組織単位の側面を変更したりといったことを自由に行えます。
ディレクトリ統合機能では、サービス チームの自動作成がサポートされていますが、一般的ではありません。サービス チームは、カスタマイズされた人セットが特定のタスクで作業できるように、完全な Service Catalog のアーティファクトとして作成されることがあります。Service Catalog の外部の企業は、そのような組織に関する知識を持つ必要がないため、こうしたサービス チームや事業単位の作成および管理は管理者が行うことになります。
同様に、ディレクトリ統合では、人へのロールおよびグループの割り当てを、ディレクトリから Service Catalog にインポートできます。ただし、多くの場合、ディレクトリにはそのような情報は含まれていません。これは、ロールとグループは一般的に Service Catalog のアーティファクトであり、Service Catalog を簡単に使用することを目的に作成され、他の企業アクティビティには適用できないためです。したがって、Organization Designer のユーザは、通常、ロール定義と、人、組織、およびグループへのロール割り当ての両方を管理する必要があります。
組織単位(OU)は、会社の組織構造を表します。
組織単位には、次の 2 つのタイプがあります。
組織単位は、その組織単位のメンバー(人)が含まれている場合と、キューにリンクされている場合があります。実際は、新しい個人をシステムに追加する場合は、デフォルト(ホーム)の組織単位を選択する必要があります。
サービス チームは、要求されたサービスを提供します。サービス チームは、Organization Designer で作成されたキュー、および Service Designer で作成されたサービス グループにリンクされています。サービス チームは、サービスを提供する人(サービス実行者)で構成されます。サービス グループは、サービス提供のためのチームとシステム プロセスの両方を表します。サービス チームは、サービスのグループを「所有」できるため、これらのサービスの提供に関連する作業の管理を担当します。
サービス実行者は、1 つ以上のサービス チーム OU に属すことができます。実行者のスキル セットに基づいてサービス チームを作成することを推奨します。
事業単位には、サービスを要求および受領する人がメンバとして含まれています。事業単位のみが課金可能であり、サービスの要求を行うと、My Services の [請求先(Bill To)] フィールドに表示されます。したがって、多くの場合、事業単位は会社のコスト センター構造に基づいて構成します。
サービス実行者は複数のサービス チームに属することができますが、事業単位は、サービス チームではなく、個人のホーム組織単位として割り当てることを推奨します。事業単位のみが課金可能であるため、事業単位をホーム OU として割り当てると、実行者が自分自身のためにサービスを要求した場合にコストと料金を適切に追跡し、課金することができます。
(注) | すべてのユーザを、1 つの「ホーム」組織単位(OU)に割り当てる必要があります。ユーザを、その他の組織単位に割り当てることができますが、「ホーム」として設定できるのは 1 つだけです。 |
組織単位を作成すると、次に説明するように、その組織単位を使用して追加データの変更および入力を行うことができます。
ページ |
説明 |
---|---|
一般(General) |
親 OU に割り当てられているサブ組織単位を含む、組織単位に関する一般情報。 |
人員(People) |
人とキューの両方を含む、組織単位のメンバー。 |
位置(Position) |
組織に指定された役職に割り当てられた人およびキュー。 |
許可(Authorization) |
組織単位の構造の承認および確認。 |
権限(Permissions) |
組織単位の代理でオーダーする権限、またはサービス チームを管理する権限のあるエンティティ。 |
ロール(Roles) |
組織単位に現在割り当てられているロール。 |
管理(Administration) |
Organization Designer で組織単位情報を表示または変更する権限を持つエンティティ。 |
ディレクトリ統合が配置されており、人と組織をリフレッシュするように設定されている場合は、非アクティブ化する組織単位が企業ディレクトリ内の有効でアクティブなユーザに関連付けられていないことを確認する必要もあります。そのユーザがログインすると、その組織単位は再アクティブ化されます。また、組織単位の非アクティブ化により、その OU に関連付けられているキューが非アクティブ化されることはありません。
組織単位の [一般(General)] ページで、OU の作成時に提供される情報を編集できます。組織単位をアクティブ化または非アクティブ化したり、サブ組織単位の追加や削除により階層構造をさらに拡張したりできます。
組織単位に関する一般情報の要約を次に示します。
Service Catalog では、親組織単位と子組織単位の階層構造を作成できます。各組織単位には、1 つの親 OU と 1 つ以上の子(サブ OU)を設定できます。
組織単位の構造には次のような効果があります。
サブ組織単位およびそのサブ OU のメンバーは、その親組織単位に割り当てられているロールと権限をすべて継承します。この継承規則があるため、ロールベースのアクセスは慎重に設定する必要があります。例として、ボトムアップ手法の使用があります。この手法では、最も低い子組織単位に最も多いロールを割り当てる、つまり最大の責任を持たせ、親組織単位に近づくにつれ、割り当てるロールを少なくします。
サブ組織単位を親に追加していくため、作業の順番として有用な方法は、次のとおりです。
組織単位に属する人を指定できます。個人は、複数の OU に割り当てられる場合がありますが、持つことができるホーム OU は 1 つのみです。組織単位を個人に関連付けるプロセスは、次のとおりです。
サービス チームの場合、チームが担当するキューを指定できます。組織単位を個人に関連付けるプロセスは、次のとおりです。
キューまたは個人の名前の左側にあるチェック ボックスは、現在の組織がそのエンティティのホームである場合はグレー表示されます。ホーム OU として割り当てられている OU を持つ個人は削除できません。個人を OU から削除するには、その個人エントリを保守して、新しいホーム OU をその個人に再割り当てする必要があります。これで、その個人は非ホーム OU のメンバーとして削除できるようになります。
エンティティのホーム所属を変更するには、キューまたは個人の名前の左側にあるチェック ボックスをオンにしてから、[ホームとして割り当てる(Assign as Home)] をクリックします。エンティティのホーム所属を確立後に変更するには、Organization Designer の Person コンポーネントまたは Queue コンポーネントの [組織(Organizations)] ページに移動する必要があります。
組織単位に関連付けられているキューまたは個人は、その組織のすべての役職に割り当てることができます。エンティティを役職に割り当てる前に、役職が存在している必要があります。Organization Designer には事前定義された役職が複数ありますが、役職を作成して組織単位に関連付けることもできます。
役職と割り当てられた個人との関係を作成する順序は、次のとおりです。
役職名の左側にある「X」は、その役職が割り当てられていないことを示します。
個人またはキューを役職に割り当てるには、[割り当て(Assign)] をクリックします。ポップアップ ウィンドウが表示され、割り当てる個人またはキューを検索して選択できます。
エンティティは、[割り当て解除(UnAssign)] をクリックして役職から削除できます。タスクの実行またはその他の作業の実行を担当する役職である場合は、未割り当てのまま放置しないでください。
Organization Designer を使用して、組織単位の承認構造、つまり「部門承認」および「部門確認」を設定します。設定機能は、サイト レベルおよびサービス グループ レベルで使用可能な設定機能と似ています。これらについては、サイト全体の承認の設定で説明しています。
権限により、どのエンティティが何を組織単位に対して実行できるかを制御できます。次の権限を設定できます。
OU の権限を割り当てるには、[権限の追加(Add Permission)] をクリックして、[権限の追加(Add Permission)] ウィンドウを表示します。次に、追加する権限、および権限を追加するエンティティを指定します。
一般的に、権限は、個々の人に付与するよりも、組織単位、グループ、またはロールに付与する方が、より効率的で管理も簡単になります。
Administration のオプションには、現在の組織でユーザに付与されている読み取り、書き込み、または権限変更の権限が示され、管理者は、これらの権限をカスタム ロールに割り当てることができます。事前作成されたロールにより、関連する権限がすべての組織に付与されます。カスタム ロールを特定の個人、OU、または役職に追加すると、組織データの読み取りおよび書き込み権限をオブジェクト レベルで(つまり組織単位で)割り当てることができます。
Organization Designer では、権限を使用して選択済みの OU やキューが「非表示」になりませんが、ユーザによる特定の OU やキューの読み取りまたは変更ができなくなります。次の手順を実行できます。
グループは、サービスの構成、コストの割り当て、権限の割り当て、およびアクセス権の付与をサイトで行う機能を向上するための組織および管理ツールです。グループを使用すると、なんらかの共通の特性を持つ OU および人を単一のエンティティに統合できます。これにより、複数の組織や人ではなく、1 つのグループにロールを割り当てることができます。
グループには、複数のサブグループを含めることができます。サブグループは、親グループに割り当てられているメンバーやロールを継承します。
グループの設定には、次のページが含まれます。
ページ |
説明 |
---|---|
一般(General) |
グループに関する一般情報 |
メンバー(Members) |
グループのメンバーである組織単位および人 |
ロール(Roles) |
グループに割り当てられたロール |
管理(Administration) |
Organization Designer でのアクセス コントロール |
グループ情報の [一般(General)] の部分で、グループ作成時に提供される情報を編集できます。グループをアクティブまたは非アクティブにしたり、サブグループの追加や削除により階層構造をさらに拡張したりできます。
サブグループを使用すれば、親グループと子グループの階層構造を作成できます。各グループには、1 つの親グループと 1 つ以上の複数の子グループまたはサブグループの両方を持たせることができます。サブグループは、親グループ内でグループ化されます。
サブグループおよびサブグループのメンバは、その親グループに割り当てられているロールと権限をすべて継承します。この継承規則があるため、ロールおよび権限システムは慎重に設定する必要があります。例として、ボトムアップ手法の使用があります。この手法では、最も低い子グループに最も多いロールを割り当てる、つまり最大の責任を持たせ、親グループに近づくにつれ、割り当てるロールを少なくします。
サブグループを親に追加していくため、作業の順序として有用な方法は、次のとおりです。
グループ メンバーは、組織単位と個々の人の組み合わせで構成されています。グループに属する人および組織単位を指定できます。グループを個人または OU に関連付けるプロセスは、次のとおりです。
メンバーは、メンバー名の左側にあるチェック ボックスをオンにして [削除(Remove)] をクリックすることにより、いつでもグループから削除できます。
権限は、個々の人または組織に割り当てるのではなく、グループに割り当てることができます。これは、異なる人や組織をグループ化し、同じ権限を付与するための方法です。
Service Designer では、グループは、サービス グループ、サービス、およびフォーム グループに関連するオブジェクトレベル権限を付与するときに直接使用できます。これらのオブジェクトレベル権限は、次のとおりです。
オブジェクト |
権限 |
---|---|
サービス グループ(Service Group) |
このサービス グループ内のサービスを設計し、データを変更する |
サービス グループ(Service Group) |
このサービス グループ内のサービスおよびその他の情報を表示する |
サービス グループ(Service Group) |
サービス グループのサービスをオーダーする |
サービス グループ(Service Group) |
権限を割り当てる |
サービス(Service) |
サービスをオーダーする |
アクティブ フォーム グループ(Active Form Group) |
フォームを表示する |
アクティブ フォーム グループ(Active Form Group) |
フォームを設計する |
ディクショナリに対してアクセス コントロールを割り当てるときに、グループを追加の参加者としても使用できます。
さらに、グループはロールのメンバーになれることから、ロールを使用できる場合はいつでも、間接的にグループも使用することができます。条件付きルールには、たとえばユーザ ロールやカスタマー ロールなどの条件タイプがあります。この場合、グループを作成し、それをロールのメンバーにし、条件付きルールの条件を定義するときに使用できます。
Organization Designer では、ロールを使用して作業する場合は、そのロールを付与する人や OU をひとまとめにするためにグループを使用できます。
最後に、Organization Designer でオブジェクトレベル権限を OU や人に割り当てる場合も、グループを使用できます。
(注) | Prime Service Catalog および UCS Director が LDAP に接続されている単一のウィンドウでは、次のようになります。
|
Prime Service Catalog が UCS Director に初めて接続したときに、Prime Service Catalog は次を作成します。
<ID> は、UCS Director サーバを表す 3 文字の ID です。このグループは、この UCS Director サーバからインポートされたすべてのグループの親グループになります。
<ID> は、UCS Director サーバを表す 3 文字の ID です。UCS Director 内の各グループに対応するグループが作成されます。このようなグループは、すべて親グループの下でグループ化されます。UCS Director のさまざまなグループに属するユーザは、Prime Service Catalog 内の該当するグループにインポートされます。
UCS Director からインポートされたすべてのユーザは、Prime Service Catalog の組織単位(OU)に割り当てられます。
その後の接続時に、Prime Service Catalog はグループ メンバーシップの変更をチェックし、それに応じてレコードを更新します。
(注) | Prime Service Catalog で UCS Director 用に作成されたコンテナ テンプレート、コンテナ カタログ、標準カタログ、およびアドバンス カタログ サービスの場合:
|
キューはリポジトリであり、実行する必要があるタスクの「受信ボックス」として機能します。作業はキューに割り当てられるため、タスクは 1 人のユーザに依存しません。
キューの作成後、キューへのアクセス オブジェクトレベル権限を使用して、キューに送信されたタスクにアクセスできる人を指定します。人はキューの「メンバー」ではありません。キューへのアクセス権の設定によって、キューへの人の割り当てのみを行います。キューへのアクセス権を持つ人はすべて、そのキューに割り当てられているタスクを実行できます。キューのホーム OU であるサービス チームのメンバーは、キューへのアクセス権限を自動的に付与されます。
Service Catalog には、1 つの事前設定済みのキュー(デフォルトのサービス提供キュー)が用意されています。タスクがタスク実行者に割り当てられていないか、またはタスクの動的割り当てに使用される名前空間が有効なキューに評価されない場合、そのタスクはデフォルトのサービス提供キューに配置されます。
キューの定義は、次に要約されている [キュー(Queue)] ページに入力する情報で構成されます。
ページ |
説明 |
---|---|
一般(General) |
キューに関する一般情報 |
組織単位(Org Units) |
キューに割り当てられた組織単位 |
連絡先(Contact) |
連絡先の電話番号および電子メール アドレス |
カレンダー(Calendar) |
勤務時間と勤務日、および休日 |
権限(Permissions) |
Service Manager 内でキュー情報にアクセスする権限を持つ人を割り当てます |
管理(Administration) |
Organization Designer でキュー情報の表示または変更を行う権限を持つエンティティ |
ここでは、キューを設定する方法について説明します。
キューの [一般(General)] ページでは、キューの作成時に提供された情報を編集できます。キューをアクティブまたは非アクティブと見なしたり、キューの時間帯を設定したりできます。
キューの一般的なプロパティの要約を次に示します。
ページ |
説明 |
---|---|
名前(Name) |
新しいキューの名前。この名前は、キューのホーム OU であるサービス チーム(組織単位)の名前と同一である場合があります。キュー名は、指定した名前に「Queue」が付加されて表示されます。キュー名の最大長は、100 文字です。名前には、英数字およびアンダースコアを使用できます。アンパサンド(&)などの特殊文字は使用しないでください。 |
タイム ゾーン(Time Zone) |
キューのプライマリ ロケーションの時間帯。キューの時間帯およびカレンダーは、キューに割り当てられているタスクの期日を推定するために不可欠です。 |
注記(Notes) |
キューについて説明する任意のテキスト。 |
キューに割り当てるサービス チームを指定できます。新しいキューを作成した場合は、デフォルト(ホーム)の組織単位を割り当てる必要があります。複数のサービス チーム OU が 1 つのキューを担当できますが、1 つのキューが持つことができるホーム OU は 1 つのみです。
組織単位とキューの間の関連付けを作成するには、次のいずれかの方法を使用します。
管理者は、特定のキューに割り当てられているタスクの提供に問題が発生した場合、キュー連絡先情報を参照できます。複数の連絡先タイプ(電子メールや電話番号など)があります。複数の電子メール アドレスをキュー連絡先の [電子メール(Email)] フィールドに入力できます。電子メール アドレスは、セミコロンで区切る(空白なし)必要があります(例:joe@cisco.com;dave@cisco.com)。
電子メールを除くすべての連絡先タイプは、キュー連絡先情報から削除できます。
[カレンダー(Calendar)] ページを使用して、勤務時間と勤務日を設定し、非勤務日と休日を割り当てます。カレンダー情報を使用して、キューの作業時間に応じたタスクおよびサービスの期日を計算します。
新しいキューの場合、作業スケジュールは、[カレンダー(Calendar)] ページの [スケジュール(Time Schedule)] 部分で示しているように、キューに指定されたタイムゾーン([一般(General)] ページで指定)で週 5 日、午前 8 時~午後 6 時にデフォルトで設定されます。この勤務時間に必要な変更を加えることができます。
[カレンダー(Calendar)] ページの [追加の日付(Additional Dates)] 部分を使用して、特定の日を休日または勤務日としてタグ付けすることができます。[新規追加(Add New)] をクリックして、新しい日付を追加します。カレンダー アイコン()から選択して日付を入力し、その日付の名前を指定し(内部ドキュメンテーション用)、[祝日(Holiday)] または [勤務日(Working Day)] のタイプを指定してから、[更新(Update)] をクリックします。追加したこれらの日付も、タスクおよびサービスの期日の計算時に考慮されます。
権限により、キューへのアクセス権限を付与する対象を制御できます。キューにアクセスすることにより、ユーザは Service Manager で特定のキューのタスクを確認および実行できます。
デフォルトでは、一部の事前設定済みロールが自動的にすべてのキューにアクセスできます。このため、これらのいずれかのロールを付与されているすべてのエンティティ(個人、組織、またはグループ)がキューにアクセスできます。また、キューに関連付けられている OU のメンバーは自動的にそのキューにアクセスできます。
人は、Service Catalog を介してサービスを受けるか、または Service Manager を介してサービスを提供するすべての個人、および他のすべてのアプリケーション モジュールのすべての管理者、マネージャ、ユーザです。
システムのユーザであるすべての個人を、その個人が組織の内部関係者であるか外部関係者であるかに関係なく、設定する必要があります。次の 2 つの文は重要です。
Service Catalog では、人員を追加するために次の 3 つのメカニズムが提供されます。
人員の作成方法に関係なく、その個人情報は Organization Designer を使用して管理できます。
新しい人員を作成したら、デフォルト(ホーム)の組織単位をその人員に割り当てる必要があります。したがって、新しい人員を作成する前に、組織単位を作成しておく必要があります。
新しい人員を追加するには、次のフィールドが必要です(アスタリスク(*)で示しています)。
ページ |
説明 |
---|---|
名(First Name) |
人員の名。 |
姓(Last Name) |
人員の姓。 |
電子メール(Email) |
連絡先の電子メール アドレス。 |
タイム ゾーン(Time Zone) |
人員のプライマリ アドレスに関連付けられているタイム ゾーン。指定しなかった場合は、デフォルトのシステム タイム ゾーンが使用されます。 |
言語(Language) |
人員のユーザ インターフェイスに表示される言語。指定しなかった場合は、英語が使用されます。 |
ホーム OU(Home OU) |
人員のデフォルトの組織単位。サービス チームではなく、事業単位を人員のホーム OU として選択することを推奨します。 |
ログイン(Login) |
一意のログイン ID。 |
パスワード(Password) |
システムへのログインに使用されるパスワード。Organization Designer を使用している場合は、確認のためにパスワードを再入力します。アプリケーションでサポートされている文字セット内の任意の文字をパスワードに使用できます。 |
次のページを使用して、人員に関する情報を設定できます。
ページ |
説明 |
---|---|
一般(General) |
個人に関する一般情報。 |
組織単位(Org Units) |
個人が属する組織単位。 |
アドレス(Address) |
会社または個人の住所情報。 |
連絡先(Contact) |
連絡先の電話番号および電子メール アドレス。 |
内線番号(Extensions) |
個人に関する追加情報。 |
カレンダー(Calendar) |
勤務時間と勤務日、および休日。 |
権限(Permissions) |
個人の代理でオーダーする権限、または代理承認者を割り当てる権限のあるエンティティ。 |
ロール(Roles) |
個人が使用可能なロール。 |
管理(Administration) |
Organization Designer 内の特定の個人に関する情報を表示または変更する権限を持つエンティティ。 |
人員の情報の [一般(General)] ページで、次の情報を編集できます。
フィールド |
説明 |
||
---|---|---|---|
役職(Title) |
個人とやり取りする場合に使用する省略形(Ms. や Mr. など)。 |
||
ロック中(IsLocked) |
ユーザのアカウントがパスワードの失効または再試行ポリシーの違反によってロックされた場合は、[ロック中(IsLocked)] フィールドが自動的に有効になります。ユーザ アカウントのロックを解除するには、[ロック中(IsLocked)] フィールドを無効にしてから、ユーザ パスワードをリセットします。 ユーザ パスワードのリセットの詳細については、人員の一般情報の [ログインしたユーザのパスワード(LoggedIn User Password)] フィールドを参照してください。 |
||
名(First Name) |
人員の名。 |
||
姓(Last Name) |
人員の姓。 |
||
ステータス(Status) |
[アクティブ(Active)] または [非アクティブ(Inactive)]。 |
||
SSN(社会保障番号) |
社会保障番号。 |
||
生年月日(Birth Date) |
誕生日。 |
||
雇用日(Hire Date) |
人員の入社日。 |
||
タイム ゾーン(Time Zone) |
人員のプライマリ アドレスに関連付けられているタイム ゾーン。これは、人員のタイム ゾーンに応じてタスクおよびサービスの適切な期日を計算および表示するために使用されます。 |
||
言語(Language) |
人員のユーザ インターフェイスに表示される言語。 |
||
従業員コード(Employee Code) |
会社由来の従業員コード(存在する場合)。 |
||
スーパーバイザ(Supervisor) |
従業員のスーパーバイザ。これは、特定の承認など、「スーパーバイザ」タスクに使用されます。Service Designer を使用して、これらのタスクを作成します。 |
||
注記(Notes) |
人員に関する追加の説明情報。 |
||
パスワードを変更する前に自分自身を認証する(Authenticate Yourself Before Changing Password) |
次のいずれかのポリシーに違反したためにアカウントがロックされた場合は、ユーザのパスワードをリセットする必要があります。 管理者は、ユーザのパスワードをリセットする権限を持っています。そのためには、ログインしたユーザが認証され、他のユーザのパスワードを変更できることをアプリケーションで確認します。 ログインしたユーザの資格情報が認証されると、管理者であるログインしたユーザは [ログイン(Login)]、[パスワード(Password)]、および [パスワードの確認(Confirm Password)] フィールドを使用してユーザ パスワードを変更できます。
パスワード ポリシーの詳細については、パスワード ポリシーを参照してください。 |
||
ログイン(Login) |
一意のログイン ID。 |
||
新しいパスワード(New Password) |
システムへのログインに使用するパスワード。 |
||
パスワードの確認(Confirm Password) |
パスワードを再度入力します。 |
人員を作成した場合は、デフォルト(ホーム)の組織単位をその人員に割り当てる必要があります。人員は 1 つのホーム OU しか持つことができませんが、複数の組織単位のメンバになることができます。組織単位と人員との間にアソシエーションを作成するには、次のいずれかの方法を使用します。
これらの方法は機能的に同等であるため、便利な方を選択してください。
また、人員は、ディレクトリ統合の Org Units 属性マッピングを介して組織単位に割り当てることができます。
組織を人員のホーム OU として割り当てると、前のホームのホーム OU 指定が自動的に削除されます。
人員ごとに、会社や個人の住所、および特定のロケーション情報を入力できます。
人員に関する有効な情報を持つことは、次のことを行うために重要です。
人員と連絡を取るための複数の方法を入力できます。それぞれ電子メール、電話などの連絡先タイプで識別されます。
拡張機能の主な目的は、LDAP 属性を「個人レコードの拡張」にロードして、この属性から条件付きワークフローを使用できるようにすることです。拡張機能によって、個人に関する追加情報を追加できます。この情報は、会社の業務や財務コードおよび構造に合わせて調整できます。たとえば、個人の部門やコスト センターの番号または名前を入力できます。また、検索時など、個人のプロファイル情報を表示するときに表示される個人の画像をアップロードできます。
個人プロファイルのほとんどのフィールドはアプリケーション処理に使用されるため、マッピングでは、ソース属性により適切な値がフィールドに指定されるようにする必要があります。これらのフィールドは、フィールド名で示されている以外の情報や、フィールド名に一致しない情報でオーバーロードしないでください。
Service Catalog には、標準の個人データを拡張するフィールドも含まれています。これらのフィールドは個人情報の [拡張機能(Extensions)] ページに表示されます。最も頻繁に必要になる拡張フィールドの一部には、意味のある名前(たとえば、会社コードや部門)が割り当てられていますが、他のフィールドの名前は Custom 1 から Custom 10 であり、事前に考えられた意味を使用せずに、自由に使用できます。LDAP ディレクトリに追加の個人情報があり、Service Catalog で公開する必要がある場合は、この情報が含まれている属性を、個人の拡張フィールドの 1 つにマップします。
「Custom」を別のフィールド名に変更することはできません。ただし、これらのフィールドがサービス フォームに含まれている場合は、フィールドの内容を正しく反映したラベルを割り当てることができます。
カレンダー情報により、個人のアベイラビリティを設定できます。個人の勤務スケジュールを、曜日ごとの勤務時間まで詳しく入力します。また、休日や、個人が作業できないその他の日を指定できます。サービス グループ メンバーの場合は、この情報を使用して、タスクの実行にかかった勤務時間を計算し、タスクの提供が予定どおりであったか、または遅延したかを判別します。
ローカル時刻および時間帯には、[一般(General)] ページで個人に割り当てられた時間帯が反映されます。
勤務時間に対して必要な変更を加えます。
休日が通常の勤務日である曜日にあたる場合は、その日をタイプ [祝日(Holiday)] の [追加日(Additional Date)] として指定します。反対に、勤務日が通常の勤務日ではない曜日にあたる場合は、その日をタイプ [作業日(Working Day)] の [追加日(Additional Date)] として指定します。
個人は、モジュール メニューの横に表示される [プロファイル(Profile)] リンクを使用して独自のカレンダーにアクセスできます。
権限は、選択された個人に影響を与えるオブジェクトの機能を定義します。これらのオブジェクトには、組織単位、グループ、他の人員、ロール、および役職が含まれます。人員の場合は、選択された個人に代わってオーダー可能な人物を定義するための権限をセットアップすることができます。
[権限(Permissions)] ページでは、承認者が承認の責任を果たすことができない場合(承認者が休暇中の場合など)に備えて、選択した個人の承認代理人も指定します。代理人は、[委任開始日(Delegation Start Date)] フィールドと [委任終了日(Delegation End Date)] フィールドを使用して指定された期間に個人に代わって承認を実行できます。
個人は、[プロファイル(Profile)] オプションの [設定(Preferences)] ページを使用して、独自の承認代理人を割り当てることができます。代理者は、異なる期間で何度も指定される可能性があるため、Organization Designer を使用して指定するよりも、個人が独自の代理者を指定する責任を持つようにすることを推奨します。
個人の承認代理人を割り当てるには、以下にまとめた情報を指定します。
ページ |
説明 |
---|---|
承認の委任(Authorization Delegate) |
[個人の選択(SelectPerson)] をクリックして、元の承認者が作業できない場合に、承認を担当する個人を検索して選択します。 |
委任開始日(Delegate Start Date) |
代理人が承認の責任を引き継ぐ開始日を MM/DD/YYYY の形式で選択します。 をクリックして、カレンダーから開始日を選択することもできます。 |
委任終了日(Delegate End Date) |
代理者の承認の責務が終了する日を、MM/DD/YYYY 形式を使用して選択します。 をクリックして、カレンダーから終了日を選択することもできます。 |
代理機能を使用している場合は、次のことに留意する必要があります。
ディレクトリ統合が配置されており、人と組織をリフレッシュするように設定されている場合、またはシングル サインオンを実行するように設定されている場合は、非アクティブ化する個人が、企業ディレクトリ内のアクティブなユーザではなくなっていることを確認する必要もあります。そのユーザがログインすると、その個人エントリは再アクティブ化されます。
個人が Service Catalog でなんらかのアクティビティを実行すると、その個人エントリは削除できなくなります。個人を非アクティブ化することにより、ログインやその他のアクティビティを実行できないようにすることができます。
役職により、サービスの提供計画を設定したり、Service Catalog アプリケーションのさまざまな側面に責任を割り当てたりする場合の柔軟性を高めることができます。システム内のタスクを役職に割り当てることができます。次に、個人、キュー、またはロールをその役職に割り当てることができます。役職は、(タスク実行者として割り当てられた)タスクや、(適切な人員に送信された電子メールに含まれる)名前空間で参照できます。
役職は、次の 4 つのエンティティ タイプのいずれかと関連付けることができます。
Service Catalog では、複数の標準の役職を提供しており、これらは変更できません。下の図では、システム定義の役職の左側のチェック ボックスがグレー表示され、これらの役職が削除または更新できないことを示しています。役職「Manager」および「Tester」は、このサイトで作成されました。
エンティティの各タイプに関連付けられた役職は、Organization Designer の組織単位の [役職(Positions)] ページ、または、Service Designer のサービスまたはサービス グループの [一般(General)] タブに表示されます。たとえば、組織に関連付けられている標準の役職の場合、組織を保守するためのアカウントの役職ページは次のようになります。
システム定義の役職が会社の要件を満たさない場合は、適切な役職を作成できます。新しい役職を追加するには、次の手順を実行します。
ステップ 1 | [役職(Functional Position)] ページの [追加(Add)] をクリックします。新しい行が役職のリストの下に表示されます。 |
ステップ 2 | 役職の名前を入力し、[タイプ(Type)] を右側のドロップダウン メニューから選択します。 |
ステップ 3 | [更新(Update)] をクリックして新しい役職を保存します。タイプが異なる場合でも、すでに定義済みの役職の名前と同じ名前にはできません。また、許可されていた場合でも、名前にはスペースを含めないでください。スペースが含まれた名前は、名前空間の変数として使用できません。 |
ステップ 4 | [タイプ(Type)] を選択して、役職を組織単位、サービス グループ、またはサービスに関連付けます。エンティティの各タイプに関連付けられた新しい役職は、Organization Designer の組織単位の [役職(Positions)] ページ、または、Service Designer のサービスまたはサービス グループの [全般(General)] タブに自動的に追加されます。
役職の定義後、Organization Designer の組織単位の [役職(Positions)] ページ、または、Service Designer のサービスまたはサービス グループの [全般(General)] タブで、個人をその役職に割り当てることができます。 |
役職を更新する場合は、次の点に留意してください。
システム定義の標準の役職は削除できません。これはグレー表示のチェック ボックスで示されます。使用中である場合も削除できません。これは [使用済み(Used)] 列のチェックマークで示されます。ただし、使用されなくなった役職は削除する必要があります。不要な役職を削除するには、それらにチェックマークを付け、[削除(Delete)] をクリックします。
Service Catalog には、「ロール ベース アクセス コントロール」(RBAC)が用意されています。これにより、管理者は特定のモジュールにアクセスできる人、組織単位、またはグループを制御したり、各モジュールで実行できる機能を制御したりできます。さらに、このような権限が特定のタイプのすべてのエンティティ(オブジェクト)で機能することを許可したり、指定したエンティティ セットに制限したりすることもできます。
したがって、ロールにより、モジュールへのアクセスと 1 つ以上の機能(および場合によっては 1 つ以上のオブジェクトレベル権限)が結合されます。
Service Catalog には、複数のシステム定義ロールが用意されています。これらのロールにより、複数の機能が、Service Catalog 実装の参加者に通常割り当てられる責任ごとにまとめられます。サイト管理者は、カスタム ロールを使用してこれらのロールを補強し、特定の実装チームの責任区分に適合するようにします。
組織単位のすべてのメンバーが、組織単位に割り当てられたロールを継承します。また、サブ組織単位は親組織単位からロールを継承します。
組織には、作成後に My Services Consumer ロールが自動的に付与されます。これにより、組織(またはサブ組織)のすべてのメンバーは、My Services にアクセスし、オーダー権限を付与されているサービスをオーダーできます(サービスをオーダーする権限は、サービスまたはサービス グループを介して付与されます)。
Service Catalog で定義されたすべてのロール(Service Catalog によって提供されるデフォルト ロールと各インストール内で作成されたカスタム ロールの両方)を組織に付与できます。ユーザは、通常、ディレクトリ統合によってリフレッシュされる組織定義の部分を変更しないようにする必要があります。変更が必要な場合は、データのソースであるディレクトリのコンテンツに対して変更を適用する必要があります。
組織に対する変更を許可するすべての管理権限は、ホーム以外のサイトでエンティティに適用されるエンティティ保護によってオーバーライドされます。エンティティ保護レベルの設定の詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
すべての設定済みの RBAC ロールと機能の詳細なリストは、ここでダウンロードできます。
ロールはコンテナの階層構造を使用して構成され、フォルダに非常によく似ています。この構造により、子ロールが親ロールから機能、権限、およびメンバーを継承する、ロール間の親子関係を作成できます。
コンテナとロールは、その名前で区別されます。「Roles」で終了する名前はコンテナです。オレンジのアイコンは、システム定義ロールであることを示しています。
Service Catalog では、一般的な企業が各ユーザに対して必要とする大半の使用例を反映したシステム定義ロールが用意されています。通常、これらのロールはほとんどの会社のロール要件を満たしています。ITIL(IT インフラストラクチャ ライブラリ)ガイドラインに準拠して分類および割り当てられた機能であるロールには、注釈が付いています。
これらのシステム定義ロールのいずれかがニーズに合わない場合は、新しいロールを作成するか、またはより簡単な方法として既存のロールをコピーしてニーズに合うように変更できます。
システム定義ロールの階層構造を次に示します。ロール名をクリックすると、ロールに関する簡単な説明、および関連付けられている機能のリストが表示されます。モジュール単位の機能リストを表示することもできます。
ロール コンテナ |
説明 |
ロール |
|
---|---|---|---|
Financial Management Roles |
サービスの戦略と設計のソリューション領域における財務管理の ITIL プロセスをサポートするロール。 |
||
Request Fulfillment Roles |
サービス運用のソリューション領域における要求履行の ITIL プロセスをサポートするロール(Request Self-Service、Request Governance、履行アクティビティの管理と自動化など)。 |
||
サブコンテナ |
説明 |
||
履行自動化ロール |
サービス リクエストの履行および提供の自動化をサポートするロール。 |
||
履行管理ロール |
サービス リクエストの履行をサポートするロール。 |
||
リクエスト統制ロール |
サービス リクエストの統制をサポートするロール。 |
||
セルフサービス リクエスト ロール |
サービス リクエストの開始および追跡をサポートするロール |
||
Service Catalog Management Roles |
サービスの戦略と設計のソリューション領域におけるサービス カタログ管理の ITIL 領域をサポートするロール。 |
||
Service Level Management Roles |
サービスの戦略と設計のソリューション領域におけるサービス レベル管理の ITIL プロセスをサポートするロール。 |
||
Service Lifecycle Management Roles |
Service Catalog のコンテキスト、およびサービスの提供におけるサービス項目の定義と管理のプロセスをサポートするロール。 |
||
Service Catalog Management Roles |
Service Catalog の定義と管理のプロセスをサポートするロール。 |
||
Service Portfolio Management Roles |
サービスの戦略と設計のソリューション領域におけるサービス ポートフォリオ管理の ITIL プロセスをサポートするロール。 |
||
Service Reporting Roles |
サービスの持続的向上のソリューション領域におけるサービス レポーティングの ITIL プロセスをサポートするロール。 |
||
上記の表の下にリストされている「Anyone」ロールと「Site Administrator」ロールは、ITIL ロール構造に適合しません。これらのロールは、Service Catalog 固有のアクセス コントロール機能を提供します。
「Anyone」ロール(ロールの説明からの引用)は、「機能およびオブジェクト ベースの権限を論理的な任意の個人、つまりすべての個人に割り当てることをサポートするために作成される特別なロール」です。すべての個人は、自動的に Anyone ロールのメンバになります。メンバのリストは変更できません。
小規模なインストール環境では、すべてのサービスをオーダーする機能を Anyone に割り当てるのが有用な場合があります。他の権限または機能を割り当てるときは、慎重に検討してください。Service Catalog にアクセスできるすべての個人が、それらのロールや機能により提供される機能を実行できるようになります。
「Site Administrator」ロール(ロールの説明からの引用)は、「Site Administration 組織単位のメンバであるすべてのユーザに自動的に割り当てられるロールで、Service Catalog および Demand Center のすべての機能と権限を提供する」です。「admin」ユーザは、自動的にサイト管理者ロールのメンバになります。その他のメンバに割り当てる場合は、このロールにより付与される能力を考慮して慎重に行う必要があります。
Prime Service Catalog では、検出された UCS Director ロールに対して次のシステム定義ロールが作成されます。次の表に、UCS Director ロールから Prime Service Catalog システム定義ロールへのマッピングを示します。
UCS Director ロール |
Prime Service Catalog システム定義ロール |
説明 |
---|---|---|
システム管理者 |
UCSD Sys Admin |
UCSD Sys Admin User は、Service Item Manager で UCS Director サービス項目のそれぞれに割り当てられたグループ権限に基づいて、My Products & Services のサービス項目としてコンテナ、vDC、および VM の詳細を表示できます。 このロールを持つユーザのみがコンテナ テンプレート サービスをオーダーできます。 |
すべてのポリシー管理者 |
||
コンピューティング管理者 |
||
Service End-User、Group Admin、Operation ロール |
UCSD End User |
UCSD End User は、Service Item Manager で UCS Director サービス項目のそれぞれに割り当てられたグループ権限に基づいて、My Stuff のサービス項目としてコンテナ、vDC、および VM の詳細を表示できます。 このロールを持つユーザは、ユーザが属するグループと UCS Director でグループに割り当てられたカタログに基づいてサービスをオーダーできます。 |
他のすべてのロール |
UCSD Operator |
このロールを持つユーザは、セルフサービス ポータルの表示と使用のみが可能であり、サービスをオーダーできません。 |
(注) | Prime Service Catalog および UCS Director が LDAP に接続されている単一のウィンドウでは、次のようになります。
|
[ロール(Roles)] タブの [検索(Search)] ボックスにロール名の一部またはすべてを入力して、ロールを検索できます。
[検索結果(Search Results)] リストで、[品目階層(Item Hierarchy)] アイコンをクリックして、ロールのツリー ビューにおける正確な位置を表示します。
上記の例では、[検索(Search)] フィールドに「My Services Consumer」と入力されました。このロールが見つかり、[検索結果(Search Results)] タブに表示されています。階層アイコンをクリックすると、このロールが Request Self-Service Roles コンテナに含まれる Request Fulfillment Roles に存在することを確認できます。
ロール名をクリックして、名前や説明、このロールに割り当てられているエンティティ、含まれている機能、オブジェクトレベル権限などの一般情報を表示し、どのエンティティがこのロールへのアクセス権を持つかを設定します。
ロールの検索、表示、作成、変更、非アクティブ化、または削除を行うには、[ロール(Roles)] タブを使用します。使用するロールを検索すると、次の 5 つのセクションが表示されるので、これらについてよく理解しておく必要があります。
ページ |
説明 |
---|---|
一般(General) |
ロールに関する一般情報(ロールの名前と説明、ロール階層での位置、ステータス(アクティブまたは非アクティブ)など)。 |
メンバー(Members) |
ロールに割り当てられている人、グループ、および組織単位。 |
機能(Capabilities) |
ロールに含まれる機能。システム定義ロールの機能を追加または削除することはできませんが、システム定義ロールにサブ ロールや子ロールを追加できます。 |
権限(Permissions) |
ロールのオブジェクトレベル権限(存在する場合)。すべてのモジュールにオブジェクトレベル権限を持つオブジェクトが含まれているわけではありません。すべてのオブジェクトまたは特定のオブジェクトを選択できます。 |
管理(Administration) |
ロール情報の表示や変更を行う権限を持つエンティティ。 |
ロールのメンバは、ロールが割り当てられた個々の人員、グループ、および組織単位で構成されます。グループまたは組織単位が割り当てられた場合は、そのグループまたは組織単位のすべてのメンバがロールを継承します。加えて、サブ組織単位とサブグループはその親からロールを継承します。[継承メンバの表示(Show inheriting members)] オプションを使用して、親組織単位または親グループからロールを継承したメンバを表示するかどうかを選択できます。オンにしなかった場合は、そのロールに直接割り当てられた組織単位およびグループのみが表示されます。
人員、グループ、または組織単位をロールに割り当てる前に、まずそのエンティティが存在していることを確認する必要があります。
ロール/メンバ関連付けを作成するには、次の 2 つの方法があります。
上の画面は、すべての OU に自動的に付与され、継承によりすべての OU 内のすべての個人に付与される My Services Consumer ロールです。
すべてのモジュールにオブジェクトレベル権限を持つオブジェクトが含まれているわけではありません。つまり、すべてのロールにオブジェクトレベル権限が割り当てられているわけではありません。オブジェクトレベル権限が含まれているロールの例として、「Service Team Administrator」ロールがあります。このロールは、Request Fulfillment Roles > Fulfillment Management Roles コンテナにあります。「Service Team Administrator」ロールには、次のように 2 つのモジュールにわたる機能が含まれます。
このロールが、Service Manager のすべての管理アクションを有効にし、かつ Organization Designer でサービス チームとキューを作成して管理する機能を有効にすることを目的としている場合は、次に示すように、このロールではオブジェクトレベル権限を組織単位、人、およびキューに付与する必要があります。
Organization Designer には、事前定義された多数のロールが用意されています。これらのロールは、一般的な企業がユーザに対して必要とするほとんどのロールに適しています。ただし、追加のロールが必要な場合は、新しいロールを最初から作成するか、既存のロールをコピーしてニーズに合うように変更することによって、カスタム ロールを作成できます。
機能および権限の使用可能な組み合わせは非常に多いため、これらの組み合わせを把握しておくことは困難な場合があります。このため、必要なすべての機能またはほとんどの機能が含まれているシステム定義ロールを特定して、新しいロールを作成することを推奨します。子ロールから機能を削除することはできないため(子ロールは親ロールからすべての機能を継承します)、必要以上の機能を持つシステム定義ロールは使用しないでください。
次の情報を入力します。
ページ |
説明 |
---|---|
名前(Name) |
新しいロールの名前。 |
親(Parent) |
|
説明(Description) |
新しいロールについて説明する任意のテキスト。 |
カスタム ロールの場合は、[一般(General)] ページでロールの作成時に表示される情報を編集できます。親ロールの割り当て、ロールのアクティブ/非アクティブの設定、ロールの説明の追加を行うことができ、変更が生じた時点で変更内容を記録できます。また、サブ ロールを追加または削除することによって、階層構造を作成することもできます。
サブ ロールを使用すると、親ロールと子ロールの階層構造を作成できます。各ロールには、1 つの親ロールと 1 つ以上の子(サブ ロール)の両方を設定できます。サブ ロール階層を作成するときは、カスタム ロールのみを使用できます。システム定義ロールの階層構造は変更できません。
サブ ロール、およびそのサブ ロールのメンバーには、親ロールに割り当てられたすべての機能が継承されます。この継承ルールのため、ロール システムの設定は十分に注意して行ってください。
親子関係は、次の 2 つの方法で作成できます。
「機能」とは、Service Catalog 内の特定の機能を実行できる能力のことです。事前定義のロールを適切なユーザに割り当てたり、カスタム ロールを作成するニーズを認識したりするためには、使用可能な機能を確認し、それらが事前定義のロールでどのように結合されているかを確認することが重要です。
使用可能な機能をオンラインで確認する一番簡単な方法は、カスタム ロールを作成する「ふり」をして、[機能の追加(AddCapabilities)] をクリックし、表示されたリストを参照します。機能はモジュールごとに分かれています。これは、各機能により特定のモジュール内で機能を実行する権利が付与されるためです。
ロールに付与されたアクセス権を無効にするには、選択された個人からロールを削除するか、割り当てられた機能を削除します。
各モジュールの機能の要約を次に示します。
My Services 機能は、サービスのオーダー、要求の表示、および Service Catalog、Order Management、および My Services の各モジュールで利用可能なタブとリンクへのアクセスに関係します。
機能 |
説明 |
||
---|---|---|---|
要求の表示 |
この機能は、ユーザが [要求(Requisitions)] リンクおよびポートレットを表示できるかどうかを制御します。この機能を持つユーザは、要求の詳細をドリルダウンして、現在のステータスを追跡することもできます。 |
||
要求の完了率の表示 |
この機能では、要求の達成率を表示できます。 完了率の表示を有効化するには、[Service Catalog] > [My Products & Services] > [オーダー(Orders)] ページで、newscale.properties ファイルの servicecatalog.display.req.percentage.completion プロパティを true に設定します。
|
||
自分の事業単位に関する要求の表示 |
この機能を持つユーザは、自分の事業単位のすべての要求を [マイスタッフ(My Stuff)] ビューに表示できます。 |
||
承認の表示と実行 |
この機能は、ユーザがトップ ナビゲーション バーの [承認(Authorizations)] リンクを表示できるかどうかを制御します。 |
||
自分の事業単位に関する承認の表示 |
この機能を持つユーザは、自分の事業単位のすべての承認を [承認(Authorizations)] ビューに表示できます。 |
||
代理オーダー |
ユーザが My Services モジュールを使用している場合は、トップ レベル ナビゲーション バーに [代理オーダー(Order on Behalf)] リンクが表示されます。なんらかの代理オーダー オブジェクト権限を持っている場合も、[代理オーダー(Order on Behalf)] リンクが表示されます。 |
||
他のユーザのマイ サービスのオーダー |
ユーザは、自分がオーダー権限を持つすべてのサービスを他のユーザに代わってオーダーできるほか、他のユーザ自身がオーダー可能なサービスもオーダーできます。 |
||
KPI の表示 |
KPI ポートレットは、My Services、My Services Executive、Relationship Manager、および Service Level Manager のホームページに表示されます(この機能は、[KPI ポートレットの表示(ShowKPIPortlet)] グローバル設定が [オン(On)] に設定された場合にのみ有効です)。 |
||
サービスの参照 |
この機能は、ユーザが [サービスの参照(Browse Services)] ポートレットを表示できるかどうかを制御します。 |
||
サービスの検索 |
この機能は、[サービスの検索(Search Services)] ポートレットを制御します。 |
||
サービスのオーダー |
この機能は、オーダー可能なサービスの横にある [オーダー(Order)] リンクがユーザに表示されるかどうかを制御します。 |
||
要求のコピー |
この機能は、ユーザがトップ ナビゲーション バーの [要求のコピー(Copy Requisition)] リンク、および要求のコピーに関連付けられているすべての機能を表示できるかどうかを制御します。 |
||
プロファイルの管理 |
この機能は、ユーザが [プロファイル(Profile)] リンク経由で使用可能な自分のプロファイルを管理できるかどうかを制御します。 |
||
サービス項目インスタンスへのアクセス |
この機能により、このロールを持つユーザは、Service Catalog モジュールで [My Products & Services] セクションを表示することができます。My Services を使用するユーザは、My Services モジュールの「サービス項目(Service Items)」タブにアクセスできます。 |
Service Designer の機能により、さまざまなユーザ セットがサービス定義のさまざまな側面で作業できます。異なるサービス セットやサービス グループ セットで作業するさまざまなユーザ セットに権限を割り当てる機能と併用すると、分散開発環境に対する堅牢なサポートを提供できます。
これらの機能の大部分は共通で Service Catalog モジュールと Order Management モジュールの同等の機能を制御します。唯一の例外は「View KPIs」で、これは [マイサービス(My Services)] 以外では使用できません。また、これらのうち一部の機能の Service Catalog における動作にも、いくつかの違いがあります。カタログ表示に Service Catalog を選択したユーザは、サービスの参照と検索が暗黙的に可能になり、「ほかの人のためにオーダー」のアクション ボタンを使用して、ほかの人の代わりにサービスをオーダーできます。
機能 |
説明 |
---|---|
サービスへのアクセス(Access Services) |
この機能は、Service Designer での Service Catalog オプションへのアクセス権を付与します。この機能を持つユーザは、「サービスの設計」権限または「サービスの表示」権限があるサービス グループに含まれるすべてのサービスにアクセスできます。この機能により、サービス定義内のすべてのタブにアクセスできるようになります。 |
サービスプレゼンテーションへのアクセス(Access Service Presentation) |
この機能は、サービスの [全般(General)]、[オファー(Offer)]、[プレゼンテーション(Presentation)] タブへのアクセス権のみを付与します。この機能を持つユーザは、「サービスの設計」権限または「サービスの表示」権限があるサービス グループに含まれるすべてのサービスでこれらのタブにアクセスできます。 |
サービスフォームへのアクセス(Access Service Forms) |
この機能は、サービスの [サービスフォーム(Service Form)] タブへのアクセス権のみを付与します。この機能を持つユーザは、「サービスの設計」権限または「サービスの表示」権限があるサービス グループに含まれるすべてのサービスでこのタブにアクセスできます。 |
サービス提供へのアクセス(Access Service Delivery) |
この機能は、サービスの [計画(Plan)] および [認証(Authorization)] タブへのアクセス権のみを付与します。この機能を持つユーザは、「サービスの設計」権限または「サービスの表示」権限があるサービス グループに含まれるすべてのサービスでこれらのタブにアクセスできます。 |
サービス管理(Service Administration) |
この機能は、サービスの [許可(Permission)] タブへのアクセス権のみを付与します。この機能を持つユーザは、「サービスの設計」権限または「サービスの表示」権限があるサービス グループに含まれるすべてのサービスでこのタブにアクセスできます。 |
サービスグループへのアクセス(Access Service Groups) |
サービス グループへのアクセス権を付与します。この機能を持つユーザは、読み取り権限または読み取り/書き込み権限があるすべてのサービス グループにアクセスできます。 |
アクティブフォームコンポーネントへのアクセス(Access Active Form Components) |
アクティブ フォーム コンポーネントへのアクセス権を付与します。この機能を持つユーザは、読み取り権限または読み取り/書き込み権限があるすべてのフォーム グループにアクセスできます。 |
サービスディクショナリの管理(Manage Service Dictionaries) |
すべてのシステム時間において、すべてのディクショナリへの読み取り/書き込みアクセス権を付与します。サービスのテストとデバッグを行う機能をサポートします。 |
ディクショナリの表示(View Dictionaries) |
ディクショナリへの読み取り専用アクセス権を付与します。 |
ディクショナリの管理(Manage Dictionaries) |
ディクショナリを編集および作成する権限を付与します。 |
スクリプトの管理(Manage Scripts) |
関数およびライブラリを含め、スクリプトのすべての機能に対して権限を付与します。 |
カテゴリの管理(Manage Categories) |
Categories のすべての機能に対して権限を付与します。 |
キーワードの管理(Manage Keywords) |
Keywords のすべての機能に対して権限を付与します。 |
目的の管理(Manage Objectives) |
Objectives のすべての機能に対して権限を付与します。 |
サービスのインポート(Import Services) |
Service Designer のインポート機能を有効にして、XML 形式のサービス定義のインポートを許可します。 |
Service Link の機能により、異なるセットのユーザを、本番環境で統合ステータスをモニタリングする管理者ではなく、統合開発者として指定できます。
機能 |
説明 |
---|---|
統合アクティビティのモニタ(Monitor Integration Activities) |
この機能は、[ホーム(Home)] ページと [外部タスク(External Tasks)] ページ、およびこれらの画面のすべての関連機能へのアクセス権を付与します。 |
アダプタの管理(Manage Adapters) |
この機能は、[アダプタ(Adapters)] タブへのアクセス権を付与し、このタブでアダプタを表示、編集、作成、削除する権限を付与します。 |
エージェントの管理(Manage Agents) |
この機能は、[エージェント(Agents)] タブへのアクセス権を付与し、このタブでエージェントを表示、編集、作成、削除する権限を付与します。 |
トランスフォーメーションの管理(Manage Transformations) |
この機能は、[トランスフォーメーション(Transformation)] タブへのアクセス権を付与し、このタブで変換を表示、編集、作成、削除する権限を付与します。 |
Reporting の機能により、権限を持つユーザは Reporting および Advanced Reporting モジュールにアクセスしてレポートを開発できます。
機能 |
説明 |
---|---|
Reports Designer |
この機能は、Advanced Reporting の [レポートデザイナ(Reports Designer)] セクションで使用可能なすべての機能へのアクセス権を付与します。 |
KPI Administration |
この機能は、KPI 管理機能、および KPI を管理、作成、変更する機能へのすべてのアクセス権を付与します。 |
Ad-Hoc Reports |
この機能は、Advanced Reporting の [Ad-Hocレポート(Ad-Hoc Reports)] セクションで使用可能な機能へのアクセス権を付与します。 |
Reporting - Administration |
この機能は、レポート フォルダの管理、ダッシュボード、IBM Cognos 管理、レポートのスケジュール、レポートの保存、権限の管理、レポートの作成など、すべてのレポート機能へのアクセス権を付与します。 |
View Service Catalog Reports |
この機能は、Reporting モジュールへのアクセスを付与し、KPI ダッシュボードを表示したり Service Catalog レポートを実行する権限を付与します。 |
Service Manager モジュールにより、タスク実行者は割り当てられた内部タスクを表示および更新できます。タスク マネージャは、タスクの割り当てやスケジュールを管理するだけでなく、タスクを表示または更新することもできます。
機能 |
説明 |
---|---|
すべての実行者の検索(Search All Performers) |
ユーザは、[ナビゲーション(Navigation)] ペインの検索ボックスで、システム内の実行者をクエリーできます。 |
作業の実行(Perform Work) |
ユーザは、次のシステム動作にアクセスできます。1.チェック イン/アウトのタスク2.クローズ アウトのタスク3.標準ビュー4.タスク スーパーバイザであるタスクのキャンセル |
作業の管理(Manage Work) |
ユーザは、次のシステム動作にアクセスできます。1.作業の割り当て2.タスク優先度の設定3.タスク期日の再スケジュール4.管理ビュー5.サービス チーム ビュー |
グローバル提供検索の実行(Perform Global Delivery Search) |
ユーザは、すべての要求を表示できます。Service Manager では、この機能により、ユーザのキュー アクセス権限にかかわらず、システム内のすべての要求およびタスクを検索できる「グローバル検索オプション」が有効になります。また、Service Manager の共有ビューの保存も有効になります。 |
追加タスクの作成(Create Ad-Hoc Tasks) |
ユーザは、Service Manager の Ad-Hoc タスク作成機能にアクセスできます。この機能が付与されると、[Ad-Hocタスク(Ad-Hoc Task)] ページの [新規Ad-Hocタスク(New Ad-Hoc Task)] フォーム セクションが使用可能になります。 |
Organization Designer の機能により、人員、組織、キュー、ロール、および役職を管理するためのオプションへのアクセスが可能になります。これらのオプションは、ディレクトリ統合(『Cisco Prime Service Catalog Integration Guide』を参照)やディレクトリ タスクの実行(『Cisco Prime Service Catalog Designer Guide』を参照)を通して提供されるオブジェクトの管理機能を補足します。オブジェクトレベルの権限とともに使用すると、特定の組織エンティティへの読み取り/書き込みがユーザに許可され、複数テナント環境で細かい制御が可能になります。
機能 |
説明 |
---|---|
基本サービス展開の管理 |
基本サービス展開パッケージを作成、送信、および管理できるようにします。 |
組織単位設定へのアクセス |
Organization Designer のホームページ検索で [組織単位(Organizational Units)] タブおよびエンティティ タイプがユーザに対して表示され、権限を持つ組織単位にアクセスできます。 |
グループ設定へのアクセス |
Organization Designer のホームページ検索で [グループ(Groups)] タブおよびエンティティ タイプがユーザに対して表示され、権限を持つグループにアクセスできます。 |
ロール設定へのアクセス |
Organization Designer のホームページ検索で [ロール(Roles)] タブおよびエンティティ タイプがユーザに対して表示され、権限を持つロールにアクセスできます。 |
人員設定へのアクセス |
Organization Designer のホームページ検索で [人員(People)] タブおよびエンティティ タイプがユーザに対して表示され、権限を持つ個人にアクセスできます。 |
キュー設定へのアクセス |
Organization Designer のホームページ検索で [キュー(Queues)] タブおよびエンティティ タイプがユーザに対して表示され、権限を持つキューにアクセスできます。 |
役職設定へのアクセス |
Organization Designer で [役職(Functional Position)] タブがユーザに対して表示されます。 |
Administration モジュールでは、すべてのオプションの個々の機能は使用できません。機能の範囲外のオプション([デバッグ(Debugging)] ページへのアクセスなど)については、Site Administrator ロールがユーザに付与されている必要があります。
機能 |
説明 |
---|---|
ディレクトリ統合設定の管理(Manage Directory Integration Configuration) |
[ディレクトリ(Directories)] オプションがユーザに対して表示され、ディレクトリ統合の設定を行うことができます。 |
承認構造の管理(Manage Authorization Structure) |
[承認(Authorizations)] オプションがユーザに対して表示され、サイト レベルの承認を設定できます。 |
グローバル設定の管理(Manage Global Settings) |
[グローバル設定(Global Settings)] オプションがユーザに対して表示され、システム動作を変更するサイト レベルのアプリケーション設定を行うことができます。 |
Eメールテンプレートの管理(Manage Email Templates) |
[Eメールテンプレート(Email Templates)] オプションがユーザに対して表示され、電子メールのテンプレートを表示または作成したり、無効にすることができます。 |
リストの管理(Manage Lists) |
[一覧表示(Lists)] オプションがユーザに対して表示され、システム参照リストを表示および変更できます。 |
サポートユーティリティの使用(Use Support Utilities) |
[ユーティリティ(Utilities)] タブおよび [サポートユーティリティの使用(Use Support Utilities)] リンクがユーザに対して表示されます。 |
ログファイルとプロパティファイルへのアクセス(Access Log and Property Files) |
[ログとプロパティ(Log and Property)] タブがユーザに対して表示され、ログ ファイルとプロパティ ファイルを表示およびダウンロードできます。 |
消去ユーティリティへのアクセス(Access Purge Utilities) |
[消去ユーティリティ(Purge Utilities)] タブがユーザに対して表示され、消去ユーティリティを使用できます。 |
バージョン履歴へのアクセス(Access Version History) |
[バージョン履歴(Version History)] タブがユーザに対して表示され、バージョン履歴を表示できます。 |
Form Data Viewerへのアクセス(Access Form Data Viewer) |
[Form Data Viewer] タブがユーザに対して表示され、Form Data Viewer を使用できます。 |
SAML SSO の設定(SAML SSO Settings) |
[SAML SSO 設定(SAML SSO Settings)] タブがユーザに対して表示され、IDP マッピング のための CRUD 操作、SAML の設定、およびメタデータの更新が実行できます。 |
Catalog Deployer の機能により、権限を持つユーザは Catalog Deployer モジュール内でパッケージを構築および展開できます。
機能 |
説明 |
---|---|
基本サービス展開の管理(Manage Basic Service Deployments) |
基本サービス展開パッケージを作成、送信、および管理できるようにします。 |
拡張サービス展開の管理(Manage Advanced Service Deployments) |
拡張サービス展開パッケージを作成、送信、管理する機能を許可します。 |
カスタム展開の管理(Manage Custom Deployments) |
カスタム展開パッケージを作成、送信、管理する機能を許可します。 |
展開のインポート(Import Deployments) |
展開パッケージのインポートおよびエクスポートを許可します。 |
展開パッケージの展開(Deploy Deployment Packages) |
新規または更新済みコンテンツのサイトへの展開を許可します。 |
Basic Offering展開の管理(Manage Basic Offering Deployments) |
Basic Offering 展開パッケージを作成、送信、管理する機能を許可します。 |
Advanced Offering展開の管理(Manage Advanced Offering Deployments) |
Advanced Offering 展開パッケージを作成、送信、管理する機能を許可します。 |
Service Item Manager に関連する標準ロールおよびそれぞれの機能を次の表に示します。
機能 |
説明 |
---|---|
標準定義の管理 |
このロールが割り当てられたユーザは、この機能を使用して、標準の定義および管理ができます(エントリの追加や削除など)。 |
サービス項目定義の管理 |
このロールが割り当てられたユーザは、この機能を使用して、新しいサービス項目とその属性を定義できます。 |
サービス項目と標準データのインポート |
このロールが割り当てられたユーザは、この機能を使用して、サービス項目と標準のデータおよび定義をインポートするためのインポート オプションにアクセスできます。 |
サービス項目のインスタンス データへのアクセス |
このロールが割り当てられたユーザは、この機能を使用して、Service Item Manager モジュールの [サービス項目の管理(Manage Service Items)] タブにアクセスできます。 |
サービス項目定義へのアクセス |
このロールが割り当てられたユーザは、この機能を使用して、Service Item Manager モジュールの [サービス項目の設計(Design Service Items)] タブにアクセスできます。 |
標準データへのアクセス |
このロールが割り当てられたユーザは、この機能を使用して、Service Item Manager モジュールの [標準の管理(Manage Standards)] タブにアクセスできます。 |
標準定義へのアクセス |
このロールが割り当てられたユーザは、この機能を使用して、Service Item Manager モジュールの [標準の設計(Design Standards)] タブにアクセスできます。 |
Portal Designer を使用するための機能の詳細については、『Cisco Prime Service Catalog Designer Guide』の「Designing Portals」の章を参照してください。
ローカリゼーション管理機能を追加すると、ユーザ ロールで Localization モジュールにアクセスできます。
さらにユーザは、Service Catalog を通じて要求を送信できます。これにより、外部システムは Requisition API(RAPI)のSOAP ベース バージョンを使用して、Web サービス要求を通じて要求を送信できます。ユーザは、REST ベースの API を使用した要求も行えます。こうした要求は Service Catalog モジュールをバイパスするため、オーダーの際にサービス フォームが表示されません。その結果、インタラクティブにオーダーされる、対応するサービスの場合とは異なる設計にする必要があります。たとえば、ルールや Java Script 関数ではデフォルト値を提供できません。また、チェック ボックスやドロップダウン リストなどのマルチ オプション フィールドは使用できません。
これらの制限により、RAPI 経由でのみオーダー可能な一連の並列サービスを作成することがあります。このようなサービスは、管理者ではないユーザの Service Catalog に表示されることはありません。代わりに、オーダー権限は管理者に対してのみ付与されます。RAPI サービスは常に、重要な機能である「他のユーザのマイ サービスのオーダー」が割り当てられたユーザによってオーダーされます。この場合の「他のユーザ」は、要求の顧客として指定されます。
権限は、特定のモジュール内で、組織単位やグループなどのオブジェクトに対する権利を付与します。これには、オブジェクト固有の権限だけでなく、他のモジュールに対する読み取り/書き込みアクセス権も含まれます。これには次が含まれます。
モジュール |
オブジェクト |
権限 |
||||
---|---|---|---|---|---|---|
Service Designer |
サービス グループ |
|
||||
サービス |
サービスのオーダー:My Services ポータル内でサービスを表示してオーダーすることができます。サービスはオーダーできるようにオーダー可能として定義する必要もあります。 |
|||||
フォーム グループ |
|
|||||
Organization Designer |
|
|
||||
Portal Designer |
|
|
||||
|
ポータル ページ グループ
|
|
||||
|
カスタム コンテンツ(Custom Content) |
|
||||
カスタム コンテンツ グループ |
|
|||||
Demand Management |
課金 |
課金レートの保守:課金レートを管理することができます。 |
||||
Service Item Manager |
|
|
||||
サービス項目インスタンス データ |
|
|||||
|
標準テーブル データ |
|
カスタム ロールに新しいオブジェクト レベル権限を追加するには、前述の表を使用して次の項目を選択します。
ページ |
説明 |
---|---|
オブジェクト タイプ(Object Type) |
リスト ボックスからオブジェクト(エンティティ)タイプを選択します。 |
このタイプに対する権限(Permission for this type) |
選択したオブジェクト タイプに基づいて、権限を選択します。 |
権限の割り当て先(Assign permission to) |
次のいずれかを実行します。 このタイプのすべてのオブジェクト(All objects of this type):たとえば、組織単位を選択した場合は、すべての組織単位がこの権限に割り当てられます。 選択したオブジェクト(Selected Objects):この権限を割り当てるオブジェクトを検索して選択します。 以下の追加の権限は、個人オブジェクト タイプ、読み取り権限タイプ、および読み取り/書き込み権限タイプにのみ適用されます。
以下の追加の権限は、組織単位オブジェクト タイプに適用されます。
|
システム定義ロールでは、ロールに割り当てられたメンバーおよびロールへの読み取り/書き込みアクセス権のみを変更できます。カスタム ロールについては、適切な管理権限を持つユーザが、機能および権限を含めすべての変更を行うことができます。
限られたユーザのみを表示または変更できるようにするなど、独自に定義したロールを使用して、読み取り権限または読み取り/書き込み権限をユーザに割り当てられます。このシナリオでは、ユーザの権限を設定します。たとえば、定義済みカスタム ロールを持つユーザは、自分と同じアカウントに属するユーザ全員のアカウントを表示できるようになります。
カスタム ロールを使用してユーザに権限を追加するには、次の手順を実行します。
アクセス権限を付与したユーザを次のモジュールで表示できます。
ここでは、カスタム ロールのさまざまなシナリオについて説明します。
顧客が直面する問題には、サポート チームが対応します。このチームは、すべての要求を表示できる必要がありますが、それに対する変更は行いません。このロールには、すべての要求への読み取りアクセス権が必要です。
サポート チームのロールを作成するには、次の手順を実行します。
ステップ 1 | 新しいロールを作成します。 |
ステップ 2 | Service Manager モジュールに表示された [グローバル提供検索の実行(Perform Global Delivery Search)] 機能を追加します。これにより、このロールのすべてのメンバが、Service Manager モジュールにアクセスしてすべてのタスクおよび要求を検索できるようになります。 |
ステップ 3 | このロールのメンバとしてサポート チームを割り当てます。詳細については、ロールへのメンバの割り当てを参照してください。 |
上記の項のオブジェクトレベル権限で説明している事前設定された「Service Team Administrator」ロールでは、ロールのメンバーがサービス チームを管理したり、組織単位やキューに関する情報を変更したりできます。
このロールは、同じ機能を提供しながら、各タイプの「すべてのオブジェクト」ではなく、特定の組織単位およびキューの作業にメンバーが限定されるため、カスタム ロールにコピーする最適な候補といえます。組織でサービス チームを管理する役割は、複数の Service Team Administrator ロールに分割でき、ロールごとに異なるセットの組織およびキューを管理できます。組織が階層構造になっている場合は、親組織を特定の権限のオブジェクトとして指定するだけで十分です。子オブジェクトもすべて同じ権限になります。
多くの要求(すべてではない)が Remedy などの外部システムに統合されているとします。Remedy アプリケーションで作業を行うアナリストは、Remedy への統合を含む Service Catalog 要求を確認できる必要があり、このような要求に添付ファイルやコメントを追加できる必要がある場合があります。
組織の複数の部門にまたがる Service Catalog の実装では、サービス設計の役割を複数の開発者グループに分散することが望ましい場合があります。理想的には、これらの開発者が互いの作業結果を活用し、他のグループによって作成およびテストされたサービスまたはサービス コンポーネントを再利用できる必要があります。ただし、開発者は別のグループによって保守されている設計コンポーネントを偶然または故意に変更しないようにする必要があります。
このような環境は、Service Designer コンポーネントに関連付けられた権限を使用することで確立できます。カスタム ロールは、開発グループごとに設定できます(メンバは直接的に、またはサービス チームまたはグループのメンバーシップを介して間接的に割り当てることができます)。Service Designer では、この役割は次のことを実行できます。
すでに存在する Service Designer ロールをカスタム ロールに付与するのではなく、適切な Service Designer 機能をロールに付与することを推奨します。この方法は設定には手間がかかることがありますが、柔軟性が向上します。サービスをインポートする権限をグループに付与する場合には、注意が必要です。サービスをインポートし、通常は変更できないコンポーネント(ディクショナリまたはフォーム)を上書きする可能性があります。[サービスのインポート(Import Service)] オプションでは、オブジェクト レベルの権限はチェックされず、すべてが上書き(または作成)されます。