ServiceNowのCIMで改善を1件流す手順：作成からClosedまでを実機でたどる

2026年8月14日 19:20

「サービスデスクの一次解決率が上がらない」。現場のその気づきを、CIM で1件の改善として登録から完了まで実際に動かしてみます。申請者から事務局、承認グループ、担当者と責任者へ順に引き継がれるシナリオで、New から Closed までの手順をSTEP1からSTEP6でたどります。状態を1つ進めるたびに、その先で必須になる項目が増えていく作りなので、先に何を埋めておくかを知っているかどうかで所要時間が変わります。入力を忘れると先に進めなくなる項目は、手順のあとに一覧でまとめました。

検証環境：Australia PDI / OOTB / 2026-08-14 確認

CIM とは：Continual Improvement Management（継続的な改善の管理）の略です。ITIL でいう継続的改善を ServiceNow の上で回すためのアプリケーションで、改善案を1件ずつレコードにし、KPI と目標値を付けて、効果が出たかどうかまで追います。プラグイン com.sn_cim を有効化すると使えるようになります。

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

結論：状態を進めるたびに条件が増える。それを知らないと進めない

改善イニシアチブは New から Closed まで7つの状態を通ります。状態を1つ進めるボタンを押すたびに、それまで必須でなかった項目が必須になっていく作りです。

さらに、フォームの入力項目だけでは分からない条件が2つあります。承認に進むには実行タスクが1件以上必要です。そして完了のボタンは、配下のタスクをすべて閉じるまで表示されません。

この記事は、実際に1件の改善案を New から Closed まで流して、各状態でどの役割の人が何を入力し、どのボタンを押すかをSTEP1からSTEP6の手順で記録したものです。入力が集中するのは事務局が担当する受理から評価までの区間で、現場の申請者と承認グループの負担は軽く済みました。進める前に埋めておく項目は、手順のあとに注意事項としてまとめています。

CIM が何を管理する仕組みかは別記事で扱いました。この記事は、その仕組みを実際に動かす側です。

似た形式の手順書として、問題管理では問題管理（Problem）運用手順書を、変更管理では変更管理（Change）運用手順書を書いています。CIM は Problem や Change とは継承元が違い、計画して進める型なので、進め方も変わります。

今回のシナリオ

手順だけ並べても、誰が何をするのかが見えません。1つの改善が現場から出て、完了するまでを追う形にします。

場面：サービスデスクの一次解決率が60%で頭打ちになっている。二次エスカレーションが多く、解決までの時間も伸びている。一次対応の担当者が「ナレッジが足りないせいでは」と気づいた。

目標：一次解決率を60%から75%へ。

登場人物は、運用設計で定義した役割にそのまま対応します。

受け渡しはこう進みます。

以降は、この流れに沿ってSTEP1からSTEP6で画面を追います。見出しに「誰が」を付けているので、自分の役割のところだけ読んでも使えます。

STEP1：【申請者】改善を1件登録する

一次対応の担当者は、ナレッジ不足で二次エスカレーションが増えていることに気づきました。改善イニシアチブの新規フォームを開き、Short description に「インシデント一次解決率を60%から75%に上げる」、Business justification に「一次解決率が伸びず、二次エスカレーションが多い。ナレッジ整備と担当者教育で改善する」と入力して登録します。

新規フォームは、ナビゲータの Create New、または Workbench の Create Improvement から開きます。

この時点で必須（アスタリスク付き）なのは Short description と Business justification の2つだけです。必須マークが付いていない項目も、状態を進める段になると必須になっていくので、あとの STEP で使う項目はここでまとめて入れておくと、あとが楽になります。

登録するとレコードが作られ、状態は New になります。

画面上部に状態インジケータが出ます。New → Accepted → Assess → Approved → In Progress → Review → Closed → Canceled が横一列に並び、現在地が緑で塗られます。自分がどこにいるかが一目で分かるのは親切な作りです。

ボタンは Follow Accept Reject Update Delete。この段階では受理するか却下するかの二択です。

STEP2：【事務局】Accept で受理し、担当と経営目標を入れる

改善事務局は、一覧に上がってきた申請者の改善案を開きます。Accept を押す前に、CIM Coordinator（調整担当）に自分を、Strategies（経営目標）に「運用効率の向上」を入力しておきます。

この2項目は、New の画面では必須マークが付いていません。 受理の段階になって初めて必須になります。受理するということは担当を決めるということで、担当のいない改善は受理できません。経営目標との紐づけも、受理の判断そのものです。

2つを入力してから Accept を押すと、状態が Accepted に変わります。

STEP3：【事務局】Assess に進める前に、確認日と承認グループを決める

改善事務局は、Target review date（効果を確認しに行く予定日）に3か月後にあたる 2026-11-14 を、Approver group（承認を依頼するグループ）に「サービスデスク承認グループ」を入力します。

New や Accept の画面では必須ではなかったこの2項目は、Assess の段階になって必須になります。Assess は評価の段階で、その先に承認が控えています。承認する相手を先に決めさせ、効果をいつ確認するかを着手前に約束させる作りです。CIM が「やりっぱなしを防ぐ」設計だと分かる箇所です。

STEP4：【事務局】実行する作業を CIM Task として登録し、Assess を押す

改善事務局は関連リストから新規レコードを作り、種別を CIM Task にして Short description に「ナレッジ記事10本を作成する」と入力します。CIM Task が入るテーブルには種別が2つあり、承認へ進む条件が数えているのは CIM Task のほうだけです。

CIM Phase（フェーズ）… 大きな改善を区切るための階層。実行の単位ではない
CIM Task（タスク）… 承認へ進む条件が数えているのはこちらだけ

種別を CIM Task にしたレコードを1件登録してから Assess を押します。承認レコードが1件、状態 Requested で自動的に作られます。

「何をやるか」が決まっていない改善は承認に回せません。 登録の時点で実行タスクを1件作っておくのが確実です。

STEP5：【承認グループ】承認して実行に進める

Assess が通ると承認依頼が自動で発行されます。承認グループのメンバーは、届いた依頼の内容を確認し、問題が無いと判断して Approve を押します。

承認すると状態が Approved に変わります。この承認は CIM Approval Workflow という Flow が動かしています。承認を挟むかどうかは sn_cim.need_approval プロパティで切り替えられ、既定は true です。

STEP6：【担当者と責任者】タスクを閉じて Close する

承認が下りると、改善事務局が Implement を押して実行フェーズに入り、CIM Task に登録したナレッジ整備を進めます。状態は In Progress に変わります。

ナレッジ10本を整備してタスクを Closed Complete にしたら、部門責任者が効果を確認しに Review を押します。状態は Monitor/Review に変わり、一次解決率が実際に75%まで改善したことを確認して Base value を60から75へ更新しました。

部門責任者が Close を押す前に、配下の CIM Phase と CIM Task をすべて Closed Complete にしておきます。 すべて閉じると Close ボタンが表示されます。

Closure Notes タブを開き、Closure code に「Completed」、Close notes に「ナレッジ10本を整備し、一次解決率が60%から75%に改善した」と入力します。Achieved outcome category の選択肢は5つです。Customer Satisfaction / Cost Reduction / Quality Improvement / Revenue Generation / Time Saving。「何が良くなったのか」を5分類のどれかに当てはめさせる設計で、部門責任者は一次解決率の改善に合う Quality Improvement を選んでから Close を押します。

埋めて Close を押すと、状態が Closed になります。進捗率も 100 になりました。