メインコンテンツまでスキップ

 

 

Coupa Japanese

プログラムの設計に関する考慮事項

このページは機械翻訳を使用して翻訳されています。


以下は、リスクアセスメントにおけるさまざまなプログラム設計の考慮事項です。

プログラム設計の考慮事項

プログラムタイプ

リスクアセスメントは2つの異なるカテゴリーのプログラムを提供します:

  • 関係ベース>関係を通じて単一のサプライヤーに関連付けられます。利用可能なタイプには、コンプライアンスプログラムとパフォーマンスプログラムがあります。詳細については、リスクアセスメントのオンラインヘルプトピック「関係ベースのプログラムの作成方法」を参照してください。
  • エンタープライズ>クライアントエンタープライズ全体の複数のオブジェクト(サプライヤー、サプライヤーの場所、関係、関係の場所、契約および契約候補サプライヤー)に関連付けられています。利用可能なタイプには、コンプライアンスプログラム、パフォーマンスプログラム、リスクプログラム、情報管理プログラム(SIM)およびロボット(ロボ)プログラムが含まれます。詳細については、リスクアセスメントのオンラインヘルプトピック「エンタープライズプログラムを作成する方法」を参照してください。

これらのカテゴリーの下で、アプリケーションは5種類のプログラムを組み込みます:

  • リスクアセスメント
  • コンプライアンス証明書
  • 業績評価
  • 情報管理
  • ロボット ロボ

いくつかの類似点がありますが、各プログラムタイプにはいくつかのユニークな特徴といくつかの使用法があります。

リスクアセスメント

リスクアセスメントプログラムは通常、サプライヤー一般と、または特定の関係の下でサプライヤーとビジネスを行うという文脈のいずれかで、サプライヤーとのビジネスに関連するリスクのさまざまな側面を評価するために管理されます。これらの側面は、財務リスク、ビジネス継続性リスク、情報プライバシーとセキュリティリスク、実行可能性、組織にとっての戦略的重要性、および他の多くのカテゴリを含む広い範囲に及びます。リスクの決定は連続体で評価されるので、リスクプログラムは一般に結果として数値を返しますが、この値は「高中低」や「赤黄色」などの評価スケールを使用して個別のバンドに変換されることがよくあります。 -緑。」リスクアセスメントで評価された個々の項目は「リスク項目」と呼ばれます。リスクアセスメントは内部の参加者によって評価されるように設計することができます、またはサプライヤーは評価で役割を果たすかもしれません。

コンプライアンス証明書

コンプライアンスプログラムは、サプライヤー/関係が、自発的に、または関係の条件として強制的に準拠しなければならない一連の要件です。これらのコンプライアンス要件は、法律や規制からポリシーやガイドラインに至るまで、サプライヤーのあらゆる要素への適合を判断するために使用されます。保険証明書、雇用適格性の証拠、健全な財務原則の順守、調達方針および行動規範の承認について、コンプライアンスを求める場合があります。一般に、コンプライアンス証明書はサプライヤーに管理され、結果は内部でレビューされるか、自動的に承認されます(応答が100%コンプライアンスの場合)。コンプライアンスプログラムは通常、最終的な「スコア」が「合格」または「不合格」のバイナリ結果を返します。

業績評価

業績プログラムは、完了時にサプライヤーが合意された作業明細書(SOW)、サービスレベル契約( SLA)、または関係のコンテキスト内のサービスレベル期待値(SLE)。業績スコアカードは、毎年の顧客満足度調査から外部委託されたサービスプロバイダー向けの正式な四半期ごとのビジネスレビューまで、ほとんどすべてのタイプの契約に対するサプライヤーの業績を測定するために使用できます。多くの場合、業績評価には複数の業績カテゴリーが含まれ、それぞれにさまざまなKPIがあります。カテゴリーとKPIの両方に個別に加重することができ、任意の数の評価者が評価に参加でき、各評価者のスコアに異なる加重が割り当てられます。最終スコアは数学的に「ロールアップ」され、総合スコアに到達します。この値は範囲に変換することもできますが、業績評価では通常、0%から100%までの数値式になります。業績評価は、サプライヤーとの正式な定期的なビジネスレビューの実施に使用できます。

業績プログラムは業績ベースの報酬を決定するためにしばしば使用されるので、プログラムは個々の組織のスコアだけでなく全体のスコアに基づいて「リスクのある手数料」を計算するために使用できます。

情報管理プログラム

情報管理モジュールは、サプライヤーおよび関係情報の自動収集および保守を容易にするように設計されています。顧客がサプライヤーおよび関係レコードから標準およびUDFを取得してプログラムを作成できるようにする、情報管理固有のプログラムがあります。情報管理プログラムの例は、サプライヤーに現在の会社の住所、電話番号、アカウントエグゼクティブの名前と住所を提示するプログラムです。プログラムの受領者は、サプライヤーの記録の適切なフィールドを更新する返答をレビュー、更新、最終承認、送信できます。情報管理プログラムタイプはデータの更新のみを目的としているため、定量的な結果はありません。 「オープン」または「クローズ」の結果のみ。情報管理プログラムは多くの場合、サプライヤーが自身のデータを維持できるように外部で使用され、ビジネスユニット所有者との関係に関するデータを内部で検証できます。情報管理プログラムは定期的にサプライヤーに自動的に送信され、プロファイル情報のレビューと更新を要求できます。サプライヤーの返答により、サプライヤーと関係の記録が適宜更新されます。

詳細については、リスクアセスメントのオンラインヘルプトピック「情報管理プログラムの作成方法」を参照してください。

ロボット(Robo)プログラム

Roboプログラムはバックグラウンドで実行され、新規/更新された情報の収集を完全に自動化します。これらのプログラムは、採点、承認、またはコラボレーションされません。ワークフローに対応したコンポーネントを実行するだけです。Roboプログラムの例としては、サプライヤーに関するデータを使用して、そのサプライヤーの分類を計算するプログラムがあります。そのサプライヤーが支出が> 6,000,000ドルの戦略的サプライヤーであり、リスクの高いサプライヤーであると識別された場合、「」という分類が割り当てられます。レベル1。」Roboプログラムを使用してリスクプロファイルを作成できます。サプライヤーユーザーに通知を送信するように割り当てのデフォルトを設定できます。詳細については、リスクアセスメントのオンラインヘルプトピック「How to Create a Robo Program。」を参照してください。

プログラムと評価/評価について

プログラムと評価、評価、またはスコアカードとの間のリスクアセスメントには明確な違いがあります(最後の3つの用語は同じ意味で使用されます)。

アプリケーション内のプログラムは、ワークフローオプション、リスク項目やKPIなどの評価項目、加重と評価者を含むすべてのプログラムパラメーターの 定義のみです。プログラムは、評価や評価を打ち消すことができるゴム印と考えてください。

評価または評価は、サプライヤー、関係、または場所に関係なく、特定のオブジェクトに対して起動される プログラムのコピーです。評価または評価は、特定の期間に立ち上げられ、特定のサプライヤーまたは関係に関連する特定のプログラムの質問または評価項目のセットです。たとえば、1つのサプライヤーに対して1月1日に開始された年次サプライヤーリスクアセスメントが評価になる場合があります。st毎年。

評価が開始されると、処理中の評価または完了した評価(評価履歴)に影響を与えることなく、基礎となるプログラムを変更できます。このようにして、評価は起動時のプログラムの状態を常に反映しています。

プログラムの範囲またはコンポーネント

5つの基本的なタイプのプログラムに加えて、プログラムはさらに2つの異なる「範囲」の1つに適用するように指定できます。つまり、プログラムがデプロイされるコンテキストです。

  • 関係ベースのプログラム
  • エンタープライズプログラム

次の図は、さまざまなタイプのプログラムを示しています。特定のカテゴリに表示される可能性のあるプログラムの例が含まれています。

RA - Program types.png

コラボレーションタイプ

コラボレーションタイプは、プログラムのワークフローオプションを指定します。適切なコラボレーションタイプを選択すると、評価ルーティング、通知、タイミングの動作が確立されます。プログラム作成時に選択するコラボレーションタイプは4つあります:

  • パーティー1のみ

    • サプライヤーのみが評価を完了して承認できるのは顧客のみです。

    • リスクプログラムのデフォルト。すべてのRoboプログラムのワークフロー。

顧客とサプライヤーリレーションシップマネージャーの間で議論を終了することができます。

  • 協力:パーティー2優先

    • これは最も一般的なワークフローオプションです。両方の当事者(パーティー1 =クライアント、パーティー2 =サプライヤー)は、評価を完了するためのアクセス権を持っています。顧客が評価/承認を開始する前に、パーティー2は最初に評価と承認を完了する必要があります。

    • コンプライアンスおよびパフォーマンスプログラムのデフォルト。

  • 共同:同時

    • サプライヤーと顧客は同時に評価にアクセスでき、並行して完了することができます。これは、プログラムマネージャーが内部チームにサプライヤーの返答の影響を受けずにサプライヤーの評価を完了させたい場合、またはワークフローに必要な時間を短縮したい場合に使用されます。

  • 外部スコアのみ

    • これはパーティー1のみの反対です。このオプションは、主にサプライヤーからデータを収集するために使用されます。情報管理プログラムの場合、プログラムが完了すると、収集されたデータによってサプライヤー/関係が自動的に更新されます。

    • 情報管理プログラムのデフォルト。

評価項目

評価項目は、評価者が回答を提供するすべてのプログラムの要素である。性質は非常に似ていますが、プログラムの種類によって評価項目の参照に別の名前が使われます。

プログラムタイプ

評価項目命名法

パフォーマンス

主要業績評価指標(KPI)

コンプライアンス

要件

リスク

リスクアイテム

情報管理とロボ

データアイテム

評価項目はいくつかの共通の特性を共有します:

  • 1つまたは複数の関連する評価項目のカテゴリーへの包含(例えば、財務業績KPIはカテゴリー「財務」の下にグループ化される場合があります)。

    • 「クリティカルゲート」と呼ばれる特別なカテゴリは、評価の動作を変更して、最小許容値を下回るこれらのアイテムの評価が評価全体の不合格または却下となるようにします。事実上、クリティカルゲート評価アイテムが不合格の場合、評価全体が失敗します。

  • 一意の識別番号-評価項目の明確な参照と注文を可能にします。

  • 固有の説明-要求されているデータを理解するために十分な説明を評価者に提供します。

  • 頻度-評価の周期性を指定します(毎年、半年ごと、四半期ごと、毎月、1回)。

  • スコアタイプ-評価項目が評価されるスケールを指定します(10ポイントのスケール、5ポイントのスケール、情報のみ、文字(AE)、数字、パーセント、R / Y / G、はい/いいえ)。

  • 評価スケールパラメータ(スコアタイプに依存し、評価アイテムに関連する最小値、目標値、最大値の指定を可能にするかもしれません)。

  • 加重-別の評価項目と比較して1つの評価項目を強調する手段を提供します。

評価項目の設計

各種プログラムの評価項目にはいくつかの重要な違いがあります:

  • コンプライアンス要件は、一般的にはい/いいえの質問であり、肯定的または「はい」の回答がその要件の優先ステータスとなるように表現されています。

    • 「サプライヤーは、この契約に基づくサービスの提供においてオンサイトで作業する可能性のあるすべての従業員および下請け業者に雇用適格性の証拠を提供しましたか?」

  • パフォーマンスKPIは通常、数値による評価を提供できる要素として表現されます。

    • 「今四半期の管理下にあるすべてのプロジェクトの平均納期完了率。」

これらの違いに関係なく、考慮すべきすべての評価項目についていくつかの基本的なベストプラクティスのガイドラインがあります。

  • 評価項目は具体的であるべきです。

    • 良い:「予算額内で実施されたプロジェクトの割合±5%」

    • 良いかもしれません:「財務業績のレベル」

  • 評価項目は測定可能でなければなりません。

    • 良:「SLAによって確立された許容限度内のシステム停止の数と累積期間」

    • より良い可能性があります:「期間中にシステムは適切に実行されました」

  • 評価項目に回答する評価者はデータを利用できる必要があります。

  • 評価項目の総数は、評価の状況に応じて合理的でなければなりません。

    • 世界中のフォーチュン100企業のデータセンターに対する10年間のITアウトソーシング契約の2つの評価項目は、おそらく数が少なすぎるか、多すぎます。

    • 紙のリサイクルサービスを提供するための$ 50,000契約に対する300の一意のKPIは、多すぎるか、または詳細すぎます。

リスクのある手数料

リスクのある手数料により、ユーザーは、パフォーマンスプログラムからの評価の最終スコアに基づいて、サプライヤーまたは関係のパフォーマンスベースの報酬を計算することができます。リスクのある料金は、ペナルティやボーナスとは根本的に異なります。これらの料金は、評価されている期間の報酬に影響します。ペナルティとボーナスは、評価される期間に続く期間のサービスクレジットとして実装されることがよくあります。

リスクのある料金はパフォーマンスプログラムでのみ利用できます。

定義可能なリスクのある手数料の2つのレベルは次のとおりです。

  • 評価全体の全体的な結果に適用されるリスクのある手数料

  • 単一の組織単位内の業績に特有のリスクのある手数料

リスクのある手数料は加算されます。つまり、業績に基づく報酬の合計は、評価の総合スコアに基づくグローバルリスクリスク料金に、各組織ユニットのスコアに基づく個別組織ユニットリスク料金の合計です。

ユーザーがペナルティボーナススキームを作成する必要がある場合、リスクのある料金の定義と「リスクのある支払範囲」というタイトルの管理構成を使用することで、これを実現できます。この構成機能は通常、パフォーマンスの「帯域」の個別の補償量を定義するために使用されます。

例:

  • 0%〜50%の業績=リスクのある手数料の補償の0%

  • 51%〜80%のパフォーマンス=リスクのある手数料の補償の50%

  • > 80%のパフォーマンス=リスクのある料金の補償の100%

ペナルティスキームを実装するには、特定のパフォーマンス帯域に 負のパーセンテージを指定するだけです。表示されるリスクのある手数料はマイナスの金額になり、ペナルティーを示します。例:

  • 0%〜50%のパフォーマンス=リスクのある手数料の補償の-100%

  • 51%から80%のパフォーマンス=リスクのある手数料の補償の-50%

  • > 80%パフォーマンス=リスクのある手数料補償の0%

 

KPIウェイト/要件測定

パフォーマンスプログラム

リスクアセスメントにより、プログラムアーキテクトは、パフォーマンスの計算の一部として個々の評価項目に適用される加重を指定することができます。たとえば、KPIが2つあるが、一方が他方よりもはるかに重要である場合、設計者はそのKPIに75%、他の25%を割り当てることができます。最終スコアを計算するとき、アプリケーションは評価に適切な加重を掛けてスコアに到達します。

コンプライアンスプログラム

コンプライアンスプログラムは、設計による「合否」計算です。したがって、各コンプライアンス要件はこのページで指定された最小スコアを達成する必要があります。そうでない場合、評価全体で「不合格」のスコアが付与されます。

プログラムテンプレート

プログラムを作成して有効化すると、顧客はそのプログラムをテンプレートにして、後で再利用して別のサプライヤーや関係用の他のプログラムを作成したり、類似のプログラムの開始点として使用したりできます。ユーザーがプログラムを表示すると、「テンプレートを作成」の横に「プログラムをテンプレートを作成」というリンクが表示されます。このリンクをクリックすると、システムはプログラムをテンプレートとしてテンプレートライブラリに追加します。

条件付け

条件付けは、特定の質問への回答に基づいて質問を条件付きで表示する機能を提供します。条件付けはすべてのプログラムタイプで使用でき、そのロジックははい/いいえの質問に基づいて定義する必要があります。

プログラムウィザードのステップ1で[条件パネルの表示]をオフにして 、定義された条件は無効になりません。条件を無効にするには、プログラムウィザードのステップ3から削除する必要があります。

プログラムの全体的なスコアに寄与する条件付き質問は、「合格」の回答が「はい」になるように定義する必要があります。

プログラム構成オプション

以下は、アプリケーションで利用可能なプログラム設定オプションです:

  • 開始リクエスト チェックボックスを有効にする-完了した有効なエンタープライズプログラムをサプライヤープログラム開始ウィジェットとプログラムワークベンチ登録開始で利用できるようにします。指示された場合、プログラムはダッシュボードのサプライヤープログラム起動ウィジェットで利用できます。

  • [計算されたライン値を非 表示]チェックボックス - 評価における最小、ターゲット、最大、評価の表示を制御します。示された場合、スコア値は評価者から隠される。

  • 情報プロファイルプログラム チェックボックス - このプログラムの結果を使用して、登録済みオブジェクトに関連付けられた情報プロファイルセクションに入力するかどうかを示します。指示された場合、プログラム結果が情報プロファイルに入力されます。 

  • 自動承認プログラム - コンプライアンスプログラムが合格の結果で自動的に承認されるか(つまり、評価ワークフロー中に承認ステップがスキップされる)、指定された承認者によるレビューと承認が必要かどうかを示します。外部コンプライアンスプログラムは、プログラムの結果が合格の場合、このプログラムが承認ワークフローを必要としない場合のみ、「はい」、「はい」にデフォルト設定されます。

  • [条件パネルを表示] チェックボックス-プログラムの設計者が基準を定義して、特定の質問をいつ行うかを制御できます。指示された場合、条件パネルがプログラムウィザードのステップ3に表示されます。

  • [最小/最大/ターゲット列を非 表示]チェックボックス-最小、ターゲット、最大、および評価列ラベル評価の表示を制御します。示された場合、列ラベルはエバリュエーターから隠されます。

  • インポート/エクスポートを許可しますか? チェックボックス-評価のインポート/エクスポートを有効にする;指示があれば、このプログラムに関連付けられた評価をスプレッドシートにエクスポートし、スプレッドシートで完了してから、回答をアプリケーションにインポートして、評価のために提出して承認を受けることができます。

  • 評価の概要を有効にしますか? -プログラムアーキテクトが、顧客が作成してインスタンスにアップロードしたXSLTに基づいて、評価のサマリービューをHTMLまたはPDFで定義できるようにします。このオプションを有効にしても、関連付けられたXSLTファイルが評価結果サマリーに設定され ていない 場合、[評価サマリー]リンクは評価の左上に表示され ません。評価結果サマリー構成ファイルは、構成ファイル管理の管理機能を使用してアップロードする必要があります。

  • Roboの実行を試行- エンタープライズプログラムをroboモードで実行できるようにします。選択すると、システムはプログラムの起動時に人の介入なしに完了を試みます。

プログラムが正常に完了するためには、プログラム内で定義されているすべての計算を完了するためにスコアが利用可能でなければなりません(UDFまたは情報プロファイルフィールドから)。

  • 登録へのプログラムのセキュリティのカスケード- プログラム設計者は、プログラムの表示と、関連するプログラム履歴の表示権を、プログラムを表示する権限を持つすべてのユーザーに付与できます。

  • 組織およびカテゴリーへの最終評価範囲のカスケード- プログラム設計者は、承認者に提示された組織およびカテゴリー/セクションのスコアを、最終評価範囲を使用して翻訳された評価に置き換えるようにプログラムを設定できます。

この機能では、KPIレベルでのみ上書きを実行できます。

プログラムコラボレーション構成オプション

コラボレーションオプション(日数を設定するオプションは暦日で表され、休日や週末は考慮されません)には以下が含まれます:

  • サプライヤーのスコアリングの日数 -プログラムのスコアリング期間が開始すると、サプライヤーが評価を完了することができる経過(カレンダー)日数(デフォルトは10)。

  • PM承認のための日数 -プログラムマネージャーまたは関係マネージャーが評価のレビュー/承認を完了する必要がある(カレンダー)日数(デフォルトは0)。

  • 協力する日数 -トップクライアントとサプライヤーマネージャーが最終評価結果をレビュー/承認し、交渉しなければならない(カレンダー)日数(デフォルトは10)。

  • サプライヤーの遅延時に評価を開始-サプライヤーの評価者がアセスメントを完了していなく ても、評価を顧客のエバリュエーターに予定どおりに開始するかどうかを示します(デフォルトはチェック済み-評価が早期に開始されると、クライアントはアセスメントを受け取りませんサプライヤーのスコア)。

  • すべての組織マネージャーに承認を必須にする チェックボックス-すべての組織マネージャーが承認を送信する前に、関係マネージャーが評価を承認できるかどうかを制御します。チェックされていない場合、関係マネージャーは、1つ以上の組織マネージャーの承認が遅れた場合に、これまでに受け取ったアセスメントを承認できます。

  • [インラインディスカッションを 禁止する]チェックボックス -評価の評価および/またはレビューの一部として、スコアカード固有のフォーラムを作成できるかどうかを制御します。指定された場合、フォーラムは作成できませ ん。

  • [承認の委任を有効にする] チェックボックス-アセスメントの開始前または後に、管理者または関係マネージャーがアセスメントの承認を委任できるかどうかを制御します(デフォルトではチェックされています。示されている場合は、承認を委任できます)。

  • 評価委任レベル- 管理者または関係マネージャーが評価の開始前または後のいずれかに評価のスコアを委任できるかどうかを制御し、プログラム設計者がプログラムの委任を無効にするか、評価全体の委任を許可するか、項目/セクションレベル

  • 遅延通知頻度 -評価/承認が滞納していることをリマインダーする頻度を定義します(期日後のリマインダー)。オプション:「なし」、「毎日」、「隔日」、「3日ごと」、「毎週」のデフォルトは「隔日」です。

  • 前のリマインダー日数 (必須)–評価/承認の開始日までにリマインダーを送信する必要がある日数を入力できます。この設定は、[リマインダーの頻度]が[ なし]でない 場合(デフォルトは1)に必要です。

  • リマインダー頻度- 評価/承認の期限となるリマインダーを送信する頻度を定義します。リマインダー頻度は、評価者が評価を完了するまでの日数を設定されたリマインダーの数で割ることによって計算されます。例:[前のリマインダー日数]が1に設定されている場合、評価者は評価期日の前日にリマインダーを1つ受け取ります。前のリマインダー日数が2に設定されている場合、評価者は2つのリマインダーを受け取ります。最初のリマインダーは完了までの時間の途中、2番目は評価期日の前日になります。選択できるオプションは、「なし」、「毎日」、「隔日」、「3日ごと」、「毎週」です。

  • 遅れてエスカレートしますか? -プログラムの指定された承認者に承認をエスカレーションするかどうかを制御します。この設定では、指定された承認者に調査が委任されます。

  • 非アクティブなオブジェクトを実行しますか? チェックボックス-プログラムがstatus = inactiveの登録されたオブジェクトで実行できるかどうかを制御します(デフォルトはチェックされています。指示された場合、プログラムは非アクティブなオブジェクトで実行されます。たとえば、有効期限が切れた関係について指示された場合、ワークフローは関係の有効期限を無視します。

  • [内部拒否]チェックボックス- 内部承認者は、明確化または追加情報のために内部評価者への評価を拒否することができます。指示された場合、内部承認者は内部および/または外部の評価者に評価を却下することができます。

  • クライアントのスコアリングの日数- プログラムのスコアリング期間が開始すると、システムが顧客が評価を完了することができる(カレンダー)経過日数(デフォルトは10)。外部スコアリングのみのプログラムに は不要です。

  • OM承認の日数 -組織マネージャーがアセスメントのレビュー/承認を完了する必要がある(カレンダー)日数(デフォルトは5)。

  • [期日 を再計算]チェックボックス-ワークフローの前のステップの実際の完了日に基づいて、ワークフローの期日を再計算するかどうかを制御します(デフォルトはチェック済み)。プログラムでこのオプションが 有効になっていない 場合は、起動時の期日の静的計算に基づいて機能します。

  • 内部カードの自動入力 チェックボックス - サプライヤーの回答を含む顧客評価の事前入力を制御します。回答が事前入力されている場合、顧客評価者は評価を変更する場合、評価を上書きできます。必要に応じて、顧客評価にサプライヤーの評価が自動入力されます。

  • [コラボレーションステップをスキップ] チェックボックス-顧客およびサプライヤーのマネージャーが最終レビューと承認を行う必要があるかどうかを制御します。指示された場合、コラボレーション手順はスキップされます。

  • [インラインアクションプランを禁止] チェックボックス - 承認者がレビューの一環としてアクションプランを作成できるかどうかを制御します。指示された場合、承認者はレビュー中にアクションプランを作成できません。

  • サプライヤースコアを表示 チェックボックス-顧客評価者がサプライヤー評価者によって割り当てられたスコアを見るかどうかを制御します。指示された場合、顧客にはサプライヤーのスコアが表示されます。

  • 遅延通知の数 -評価/承認が延滞の場合にリマインダーを送信する数を定義します。遅延通知頻度が 「なし」でない 場合は必須(デフォルトは3)。

  • 前のリマインダー日数- 開始日に近づいている評価/承認のためにリマインダーが送信される数を定義します。リマインダーの頻度が 「なし」に等しくない 場合は必須(デフォルトは1)。

  • エスカレート 期限日後チェックボックス-承認がエスカレートされる期日を過ぎた日数を定義します。 [遅刻するときにエスカレート]が表示されている場合は必須です(デフォルトは5)。

  • 承認方法 -必要な承認のタイプを示します。オプション:「通常」(組織マネージャーと関係マネージャーの承認)、「外部承認なし」、「内部承認なし」、「承認なし」(デフォルトは「通常」)。

  • [前のアイテム結果のコピーを有効にする] チェックボックス-前に完了した評価からKPIに入力された値が、次の期間の評価を受け取ったときに評価者に提示されるかどうかを示します。指示された場合、前の回答が後続の評価に繰り越されます。

  • [外部を拒否] チェックボックス-外部承認者は、明確化または追加情報を得るために、外部の評価者への評価を拒否することができます。指示された場合、外部承認者は外部の評価者に評価を却下することができます。

  • コメントの可視性 -ユーザーは、プログラムの受信者が必要ない場合に添付ファイルを含めることを禁止できます。

  • 承認表示モード -ユーザーが承認フォームの表示形式を制御できるようにします(デフォルトは「拡張」)。 「折りたたまれた」モードのスコア情報と上書きコントロールは表示されません。「拡張」モード-表示されているすべてのセクションにコンテンツが表示されます。

前提条件とその他の役立つヒント

以下は、プログラムの要件およびその他の補助的な詳細に関する追加情報です。

  • プログラムを保存または有効化するには、すべての必須フィールドに入力する必要があります。

  • 特定のプログラム詳細ページの「企業カレンダーを使用する」チェックボックスオプションを使用すると、ユーザーはプログラムカレンダーを標準カレンダー以外に設定できます。企業カレンダーは、最初に、[会社情報の管理]というセクションの管理タブで定義します。企業カレンダー機能を使用すると、ユーザーは会社の会計カレンダーと一致するカレンダーを定義できます。

  • サプライヤーユーザーは、サプライヤーの自己起動プログラムウィジェットをダッシュボードに追加できます。顧客が自分自身にプログラムを起動する機能をサプライヤーに与えた場合、サプライヤーはウィジェットにそのプログラムを表示し、プログラムを自由に起動できます。顧客は、プログラムウィザードのステップ1で[起動リクエストを有効にする]オプションを選択してアクセスを許可します。アクセスはプログラムごとに許可されます。このオプションが選択されているプログラムはサプライヤーウィジェットに表示されます。

  • プログラムのワークフローでは、プログラムウィザードの1ページ目の[パフォーマンスタイプ]オプションで[非アクティブオブジェクトの実行]オプションがチェックされていない限り、有効期限が考慮されます。

 

 

  • この記事は役に立ちましたか?