メインコンテンツへスキップ
見出し画像

TPRMの運用手順(ベンダー登録からアセスメント1件を処理する手順)


    ServiceNowにTPRMを入れたものの、デモデータが1件も無く、画面を開いても何から手を付ければよいか分かりません。委託先の担当者登録からアセスメントの完了まで、実際にはどの画面で何を入力し、どこが自動で動くのでしょうか。Australia PDIでベンダー1社・担当者1名・テンプレート1件を使い、Draft作成・Submit・質問票への回答・観察の生成・FinalizeとCloseまでを1件流し切りました。stateは1→2→8→5→9→3の順に進みます。番号が飛ぶのは内部値が画面の表示順と別に振られているためで、故障や欠番のせいではありません。ボタンで進める段と、回答完了で自動的に進む段の両方があります。

    検証環境:Australia PDI/ OOTB / 2026-08-22 導入・確認。Third-party Risk Management(sn_vdr_risk_asmt)を導入済み

    TPRMとは:Third-party Risk Management(第三者リスク管理)の略です。委託先や外部ベンダーとの契約に伴うリスクを、担当者の登録からアセスメント(質問票による評価)、観察、是正まで一連のレコードとして管理します。

    この記事で通す範囲:担当者の登録、テンプレートの確認、エンゲージメントとアセスメントの作成、Submit、質問票への回答、観察の生成、FinalizeとCloseまでです。読むだけでなく、実際にレコードを作りながら1本つなぎました。

    TPRMシリーズ(全9本) — 導入から設計・運用・トラブルまで通しで書いています。

    実際に1件流し切ると、アセスメントの画面はこうなります。


    画像

    上部の進捗バーが最後まで埋まるところまで、担当者登録から6段階を実機で動かしました。ここから先は、その手順を1つずつ追います。

    TPRMは何のためのアプリなのか

    委託先が数十社に増えると、「どのベンダーにどんなリスクがあるか」を個別のExcelやメールで追いかけるのは早々に限界が来ます。誰が今どのベンダーを評価中で、どの回答が返ってきていて、何件が未回答なのかを、担当者任せではなく1つの記録として残しておきたい。TPRMはその期待に応えるためのアプリです。

    公式のsys_remote_appには、アプリの狙いがこう書かれています。

    Centralized process to identify, assess, and manage risk associated with third-party engagements.

    (訳:第三者との契約に伴うリスクを特定・評価・管理するための一元化されたプロセス)

    引用元:/sys_store_app_list.do?sysparm_query=scope=sn_vdr_risk_asmt(導入前は sys_remote_app、導入後は sys_store_app に行が移ります)

    GRCスイート全体を入れなくても単体で成立する

    TPRM(sn_vdr_risk_asmt)は単独のアプリではなく、GRC(Governance, Risk, Compliance)系の6スコープに依存して動きます。中心になるのはsn_grc(GRC: Profiles)で、ポータルやワークスペース、コンプライアンス評価の共通部分を提供する依存プラグインcom.snc.grc_vrm_depの公式説明はこうです。

    Installs all the dependent plugins required to support the GRC Vendor Risk Management application.

    (訳:GRC Vendor Risk Managementアプリケーションの動作に必要な依存プラグインをすべてインストールします)

    引用元:/v_plugin_list.do?sysparm_query=id=com.snc.grc_vrm_dep

    同じGRCファミリーのAudit・Policy & Compliance・Risk Managementといった同族アプリの依存プラグインは、導入後もInactiveのままでした。TPRMはGRCの共通基盤に乗りながらも、他のGRC機能を巻き込まずに単体導入が成立する作りです。監査(Audit)や全社のリスク管理(Risk Management)まで一気に入れる必要はなく、まず委託先の評価だけを回したい会社にとっては始めやすい設計だと感じました。監査寄りの記録管理という意味では、標準のSystem Audit(監査証跡)がテーブル単位の変更履歴を追います。一方でTPRMは「委託先ごとの評価結果」という業務レベルの記録を、専用テーブルで持つ点が異なります。

    7つのロールは「管理する側」と「答える側」に分かれる

    TPRM単体が持つロールは7つです。上から下へ権限を包含する形になっています。


    画像

    管理系のvendor_risk_managerの公式説明はこうです。

    Manages third parties, third-party contacts, third-party assessment templates, questionnaire templates, documentation request templates, and scheduled assessments.

    (訳:第三者・第三者の担当者・第三者アセスメントテンプレート・アンケートテンプレート・資料要求テンプレート・定期アセスメントを管理します)

    引用元:/sys_user_role_list.do?sysparm_query=name=sn_vdr_risk_asmt.vendor_risk_manager

    承認を担うapproverロールには、直接紐づくACLが1件もありませんでした。運用上の承認行為であって、データへのアクセス権そのものは別ロールが担うという分担です。一方external_assessment_responderが継承するのはsn_smart_asmt.actorだけで、社内のinternal_assessment_responderはここにsn_grc_workspace.userを足しています。内と外の違いは、GRCワークスペースに入れるかどうかだけという作りでした。

    導入直後に困るのは「テンプレートが無いと何も進まない」点

    TPRMにはデモデータが1件もありません。ただし何も見えないわけではありません。取引先マスタのcore_companyには既に177社の会社データがあり、そのうちvendor=trueが付いた78社がTPRMの「第三者(Third Party)」として最初から一覧に表示されます。ベンダーマスタを新規に作る作業は不要で、既存の取引先からそのまま選べます。

    問題はその先です。Vendor Management Workspace(/now/vendor-management)を開くとTotal third partiesは78ですが、Total engagementsは0のままでした。アセスメントのテンプレート(sn_vdr_risk_asmt_template)も0件です。質問票の素材(asmt_metric_type)はESG・Privacy・Basicなど5件用意されていますが、それらをまとめて1件のテンプレートに組むところまではやってくれません。素材は入っているのに、管理者が最初の1件を自分で組むまではアセスメントを1件も実行できないというのが、導入直後にぶつかる壁でした。

    ベンダー登録からCloseまで9ステップの全体像

    今回は実在しない委託先という想定で、core_companyの1社「Meridian Data Services」を対象に、担当者の登録からアセスメントのClose(完了)までを1本つなぎました。全体の流れは次のとおりです。


    画像

    実際のフォーム上部の進捗バーが6つの状態を進んでいく様子は、次のアニメーションが分かりやすいはずです。


    画像

    手で押しているのはSubmit・Generate observations・Finalize・Closeの4回だけです。残りは質問票のコピーやアセスメント回答用レコードの生成、状態の遷移まで、ビジネスルールが裏側で動いています。ここから先は、この流れをSTEPごとに画面で追います。

    STEP1:【TPRM管理者】担当者(Contact)を登録する

    第三者を1社選んだら、まずその会社の連絡先となる担当者を登録します。ここを飛ばすと、後のSubmitで止まります。

    • 目安:1分ほど・可逆

    • 実施者:TPRM管理者(vendor_risk_manager)

    • 画面:Third Parties > Third-party Contacts で New(対象のVendorにMeridian Data Servicesを指定)

    • 入力項目:Name=Alex Rivera/Email=vendor.contact@example.com(架空ドメイン)/Primary contact=true/Active=true

    • 操作:入力してSubmit

    • 成功条件:保存した直後にRegistration statusがSentへ自動で変わる

    • 注意点:Primary contactを1件も登録しないままアセスメントをSubmitしようとすると、「At least one primary contact must exist」という必須エラーで止まる。担当者登録を最初に済ませておくのはこのためです


    画像

    メールを1通も送っていないのに、Registration statusだけが先に進む点は次の「実機で気づいたこと」で扱います。

    購入すると何が手に入るか

    ここまでで、全体の流れと最初の関門(担当者登録)までが終わりました。ここから先は、テンプレートの作成からアセスメントをベンダーへ送り、回答を受け取り、Closeまで完了させる操作手順書です。

    入っているもの:

    • STEP2からSTEP9までの8手順(テンプレート作成、エンゲージメント登録、Draft作成、Submit、質問票への回答、観察の生成、Finalize、Close)

    • 各STEPの実画面スクリーンショット(Draft・回答受領・観察生成・Finalize・Closeの各状態のフォームを同じレコードで撮影)

    • state遷移の対応表(画面で押す操作と、裏で動く内部値のずれを1枚で確認できる表)

    • 3つのつまずきポイント(プライマリコンタクト必須エラー/回答URLの権限エラー/risk_ratingが空のまま残る理由)

    • 実機で気づいたこと(続き)と、現場にそのまま使える確認URL・用語一覧

    分量は本文の約7割です。実際にPDIでレコードを作り、Closeまで進めた画面を見ながら書いています。

    💰 ここから先は有料エリア

     
     
    ServiceNowのPDI(Personal Developer Instance)を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ