サービスカタログの運用手順書

カタログで注文を受けてから履行を終えるまで、担当者は何を確認し、どこで承認を待つのか。この記事は、そのまま自社の運用手順書として使える形で手順をまとめたものです。Australia の PDI に入っている実際の申請レコードを1件ずつ開き、各段階で入っている値と、承認が止まりやすい箇所を確認したうえで作成しています。

手順書に含む内容

• 申請からクローズまでの作業手順

• 各段階で入っている項目と実レコードの記入例

• 承認が2段階に分かれる仕組みと、見落とすと何が起きるか

• 履行タスクの処理と、Close Complete／Incompleteの使い分け

• 差し戻し・停滞を防ぐ確認項目

手順書として押さえること

• 申請からクローズまでの作業は6段階で構成される

• 承認は2段階あり、2段目は1段目の確定から数秒後に別レコードで生成される

• 状態を表すフィールドは3系統あるが、現場が見るのは stage の値だけでよい

• 履行タスクには Close Code が無く、Close Notes の入力は必須にならない

1. 本手順書の目的

サービスカタログの担当者が、カタログの注文を受けてから履行タスクを終えるまでの作業を、迷わず同じ手順で実施できるようにする。

承認の見落としを防ぐことを主目的に含める。サービスカタログの承認は1件の注文につき1レコードとは限らず、金額のしきい値による承認（1段目）と、部門長による承認（2段目）が別々のタイミングで生成される。1段目だけを見て手を止めると、2段目に気づかないまま履行が始まらない。

申請から履行タスクまでの全体の流れそのものは、サービスカタログの概要 で扱っている。本手順書は、その流れの中で担当者が実際に何を押し、何を確認するかに絞る。

承認をこの2段階に分けた設計の理由や、金額のしきい値をいくらにするかという判断は、サービスカタログの運用設計書 で扱う。本手順書は、決められた運用を現場で迷わず実行する手順だけに絞る。

2. 適用範囲と前提条件

2-1. 適用範囲

本手順書は、ServiceNow のサービスカタログを使用する日常運用を対象とする。カタログアイテムの新規作成・オーダーガイドの設計は対象外とする。

2-2. 前提条件

項目内容対象バージョンAustralia対象テーブルsc_request / sc_req_item / sc_task必要なロールsn_request_write（履行担当）／sn_request_approver_read（承認者）履行エンジン品目ごとに異なる（本手順書の題材はFlow Designer）SLA監視無効。contract_sla は3テーブルとも0件

itil ロールには sn_request_write が自動で含まれるため、担当者がインシデント対応と兼務していても申請の履行は行える。ただしカタログの閲覧範囲を広げる catalog ロールは含まれないため、申請者側の見え方は別途確認が必要になる。

3. 対象者と役割

役割担当する作業申請者カタログアイテムを選んで注文する承認者1（金額しきい値）Request 全体の合計金額がしきい値を超えたときに承認する承認者2（部門長）申請者が所属する部門の責任者として承認する履行担当承認が済んだ注文を手配し、履行タスクを完了させる

承認者1と承認者2は、承認する対象が異なる。承認者1が見るのは Request（sc_request）全体の合計金額で、承認者2が見るのは Requested Item（sc_req_item）1件ごとの部門責任である。この違いが4章で扱う見落としの原因になる。

4. 作業の全体像

状態を表すフィールドは3系統ある。request_stateはRequest専用の7値の文字列、stateはRequested Item / Catalog Taskが使うtask基底の数値6値、stageはinternal_typeが「Workflow」という専用型だ。現場でいま何段階目にいるかを追うときは、stageの値だけを見ればよい。request_stateはRequest全体の大まかな区分にすぎず、stateは他のtaskテーブルと共通の汎用値である。履行の進み具合を細かく表しているのはstageだけになる。

4-1. 承認は2段階あり、2段目は数秒後に別レコードで生成される

REQ0010001／RITM0010001（Standard Laptop、$1,100の注文）で確認する。承認1（Request宛て）が確定した7秒後に、承認2（Requested Item宛て）が自動生成されていた。承認1の確定は13:19:40、承認2の生成は13:19:47である。

承認1と承認2は同じ sysapproval_approver テーブルの別レコードで、フォームの見た目もほぼ同じである。違うのは document_id（対象がRequestかRequested Itemか）だけであり、承認1を処理した直後に一覧を再確認しない限り、承認2の存在に気づけない。

この注文全体で発生した承認レコードは、source_table=sc_request が1件・source_table=sc_req_item が1件、合計2件だけだった。

5. 作業手順

STEP1（Waiting for Approval）：【申請者】カタログアイテムを注文する

操作：Employee Centerでカタログアイテムのページ（/esc?id=sc_cat_item&sys_id=<品目のsys_id>）を開き、数量とRequest for（申請先の利用者）を確認して「Order Now」を押す。開く「Order Confirmation」モーダルで内容を確認し、「Checkout」を押すと注文が確定する。

確認する項目

項目記入例（RITM0010002／Office Keys）補足カタログアイテムOffice Keys価格 $0数量1既定値のままstageRequest Approval（内部値 waiting_for_approval）承認前の既定表示approvalNot Yet Requested部門長承認がまだ開始していない

成功条件：REQ番号とRITM番号が採番され、画面のタイトルが「Request Summary - REQ...」に変わる。RITMのstageが承認待ちの表示になる。

実施してはならないこと

• 数量や配送先を確認せずに注文を確定する

• 同じアイテムを重複して注文する。既存の未完了RITMを確認してから発注する

• 「Order Now」を連打する、またはCheckoutを押した直後に画面を閉じる。RequestとRITMが重複生成される、または注文が確定しないまま終わる原因になる。Request Summary画面への遷移を確認してから次の操作に移る

STEP2（In Process）：【承認者1】金額しきい値の承認を確定する

操作：承認一覧から自分宛ての承認レコード（対象がRequest）を開き、内容を確認して承認する。

入力項目

欄記入例（REQ0010001の承認1）補足document_idRequest: REQ0010001対象はRequest全体approverEric Schroeder金額しきい値グループのメンバーapproval_reasonRequest Total Price is more than $1000.合計金額がしきい値$1,000を超えた理由が入るgroupGAPRV0010002承認をまとめるsysapproval_groupへの参照

成功条件：stateがApprovedになる。REQのrequest_stateがApprovedへ進む。

注意点：ここで承認したのはRequest全体を対象にした金額の承認だけである。承認理由欄に金額の説明が入っている点が、承認2との見分け方になる。

STEP3（In Process）：【承認者2】部門長承認を確定する

操作：承認1が確定した数秒後に新規生成される、別の承認レコード（対象がRequested Item）を開いて承認する。

入力項目

欄記入例（RITM0010001の承認2）補足document_idRequested Item: RITM0010001対象は承認1と異なりRequested ItemapproverNatasha Ingram申請者の所属部門（Finance）のdept_headapproval_reason（空欄）承認1と異なり理由の記入が無いgroup（空欄）sysapproval_groupへの参照が無い

この承認は申請者の上長（manager）による承認ではない。今回の申請者もmanagerフィールドは空欄だが、所属部門（Finance）のdept_headが解決されて承認者が決まる。

成功条件：stateがApprovedになる。RITMのstageがOrder Fulfillmentへ進む。

注意点（この手順書で最も重要）：承認1と承認2は同じ画面・同じボタンで完了するため、1件処理して満足しがちである。しかし対象がRequestからRequested Itemに変わった2件目が、確定のわずか数秒後に控えている。

この見落としが実際に何を引き起こすかを、同じPDIの別レコードで確認できる。RITM0000005（Standard Laptop）はstageがDept. Head Approval、approvalがRequestedのまま止まっており、対応する承認レコードは0件だった。

同じ状態のRITMは他に3件あり、合計4件（デモデータの7件中）が承認レコード0件のまま止まっている。承認2は自分から一覧を見に行かない限り、生成されたことにも、生成されず止まっていることにも気づけない。

この記事の有料部に含まれるもの

STEP4以降の履行タスクの処理と、判断基準・異常時の対応・確認項目を記載します。

• STEP4〜STEP6：履行タスクの発生確認・処理・最終状態確認（画面つき）

• 第6章 判断基準：承認一覧の再確認タイミング、Close Complete／Incompleteの使い分け、エスカレーションの起点

• 第7章 異常時の対応：承認2が見当たらないときの調べ方、履行タスクが動かないときの対応

• 第8章 補足：1日の運用サイクル、引き継ぎの書式、クローズ前の確認項目

分量は本文の後半およそ4,000字です。記入例をそのまま自社の様式に置き換えれば、運用手順書として使えます。

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