5.2　対象システム，プロセスの決定と体制作り

JP1/Service Supportを使って，サービスサポートに沿った運用を実施する場合，まず，どのシステムを対象とするか，また，どのプロセスを用いるかを決める必要があります。次に，各プロセスで，だれが，どのような作業をするのか，作業分担と作業の流れを決める必要があります。

なお，プロセスやステータスをカスタマイズすることで，運用に合わせた案件の処理ルートを作成することもできます。プロセスのカスタマイズについて検討する場合は，「5.2.2　対象システム，プロセスワークボードの設計」を参照してください。ステータスのカスタマイズについて検討する場合は，「5.3　案件のステータスの検討」を参照してください。

また，この節で説明しているプロセスおよびステータスはデフォルトのものです。プロセスおよびステータスをカスタマイズする場合は，カスタマイズ後のステータスに置き換えてお読みください。

ここでは，JP1/Service Supportを使って，あるシステムの運用を実施することを想定して説明します。実際にJP1/Service Supportで環境を構築する際の参考にしてください。

まず，次の図に示すように，JP1/Service Supportの管理対象となるシステムに対して，どのようなプロセスで案件を解決していくかを検討します。

図5‒2　対象システムに対応するプロセスの検討

次に，案件の状況を確認する作業担当と，その作業内容を次の表に示すように細かく検討します。

表5‒1　案件の状況を確認する作業担当，作業内容の検討
担当者	作業内容	作業内容詳細
情報システム管理者	システムを横断した案件状況の確認と対策	システムを横断して案件の状況を管理する。案件の滞留しているシステムの問題解決を図る。また，システム全体の状況を集計して評価し，運用を最適化する方法を検討する。
作業状況管理者	案件の状況管理	主に日程を管理するために，担当しているシステムでの案件の処理状況を確認する。問題のあるプロセスをフォローする。
対象システム管理者	システム内の案件状況の確認と対策	担当しているシステム内の各プロセスを管理する。案件の滞留しているプロセスの問題解決を図る。

また，各プロセス内での案件の処理の流れを作業担当，作業内容を含めて細かく検討します。

表5‒2　各プロセス内の処理の流れ，作業担当，作業内容の検討
プロセス	担当者	作業内容	作業内容詳細（「　」はキーワード）	案件のステータス
インシデント管理	インシデント担当者	インシデント作成	ユーザーからの問い合わせやシステム障害の発生を管理するため，インシデントを作成する。インシデント管理プロセスの［案件作成］画面でインシデント案件を作成する。	受付
		過去の事例検索，調査	過去同様の事例がないか検索する。同様の事例がある場合「関連案件」の設定をする。また，調査状況に合わせて案件を編集する。	調査中
		エスカレーション	長期の対策が必要な場合，問題管理へエスカレーションする。担当者には問題管理担当者を設定する。	対応依頼中
		インシデントの調査結果記入	調査結果を「回避策」「解決策」に記入する。	調査中
		承認依頼	インシデント管理者にインシデント内容について承認依頼を実施する。依頼内容を「フリー記入欄」に記入する。担当者をインシデント管理者にして，ステータスを審議中に変更する。	審議中
		インシデントの引き戻し^※	承認依頼したインシデントに入力誤りなどがあった場合，このインシデントを引き戻す。	調査中
	インシデント管理者	インシデントの承認	インシデントの内容を確認する。ステータスを承認済みにして，担当者をインシデント担当に変更する。	承認済み
	インシデント管理者	インシデントの差し戻し	承認依頼を受けたインシデントの内容に入力誤りなどがあった場合，このインシデントを差し戻す。	調査中
	インシデント担当者	インシデントのクローズ	インシデント担当は，必要に応じて案件の作業履歴や進捗を確認し，問い合わせ者に随時報告したり，滞っている作業の担当者をフォローしたりする。ステータスが承認済みとなった時点で，問い合わせ者に正式回答する。「結果」を記入して案件をクローズする。	クローズ
問題管理	問題管理担当者	問題点作成	システム障害，問い合わせなどから傾向を分析し，問題点を作成する。問題管理プロセスの［案件作成］画面で問題点を作成する。	受付
		調査	作成した問題点，またはインシデント管理からエスカレーションされた問題点を調査する。必要に応じて過去の問題点を検索する。「機器情報」などのシステムの構成情報を参照する。障害調査時には，ログなどを添付資料として登録する。上記の調査結果から「根本原因」「解決策」などを記入する。	調査中
		承認依頼	問題管理者に調査内容や解決策の承認依頼を実施する。依頼内容を「フリー記入欄」に記入する。担当者を問題管理者にして，ステータスを審議中に変更する。	審議中
		問題点の引き戻し^※	承認依頼した問題点に入力誤りなどがあった場合，この問題点を引き戻す。	調査中
	問題管理者	承認	問題点の内容を確認する。担当者を問題管理担当にして，ステータスを承認済みに変更する。	承認済み
	問題管理者	問題点の差し戻し	承認依頼を受けた問題点の内容に入力誤りなどがあった場合，この問題点を差し戻す。	調査中
	問題管理担当者	エスカレーション	問題点に関連してシステム変更作業が必要な場合は，変更管理へエスカレーションする。担当者には変更管理者を設定する。	対応依頼中
	問題管理担当者	クローズ	問題案件の最終的な結果を記入して，問題点のステータスをクローズに変更する(必要に応じてクローズの前に再度承認を依頼する)。	クローズ
変更管理	変更管理者	変更点作成	システム変更作業を変更点として作成する。変更管理プロセスの［案件作成］画面で変更点を作成する。	受付
	変更管理者	計画依頼	作成した変更点，またはエスカレーションされてきた変更点の内容を確認する。「フリー記入欄」に計画作成の旨記入し，担当者をCABメンバーに変更する。	受付
	CABメンバー	計画作成	影響評価と変更計画を作成する。	計画中
		承認依頼	担当者をCAB代表にして，ステータスを審議中に変更する。	審議中
		変更計画の引き戻し^※	承認依頼した変更計画に入力誤りなどがあった場合，このインシデント案件を引き戻す。	調査中
	CAB代表	承認	変更計画の内容を確認し，必要に応じてCAB会議を開催する。計画の合議が取れた時点で，変更点のステータスを承認済みに変更する。	承認済み
		変更計画の差し戻し	承認依頼を受けた変更計画の内容に入力誤りなどがあった場合，この変更計画を差し戻す。	調査中
		エスカレーション	リリース管理に作業を依頼する場合は，リリース管理へエスカレーションする。担当者にはリリース管理者を設定する。	対応依頼中
	変更管理者	レビュー	リリース完了から一定期間後，関係者を集めてレビューを実施する。	レビュー中
	変更管理者	クローズ	結果を記入して変更点をクローズする。	クローズ
リリース管理	リリース管理者	リリース案件作成	リリース作業の案件を作成する。リリース管理プロセスの［案件作成］画面で変更点を作成する。リリース計画策定のため「フリー記入欄」に依頼事項を記入する。担当者をリリース担当者(計画立案者)に変更する。	受付
	リリース担当者 (計画立案者)	計画作成	リリース計画を作成する。	計画中
		承認依頼	リリース計画の承認をもらうため担当者をリリース管理者にして，ステータスを審議中に変更する。	審議中
		リリース計画の引き戻し^※	承認依頼したリリース計画に入力誤りなどがあった場合，このリリース計画を引き戻す。	計画中
	リリース管理者	承認	計画の内容を確認する。担当者をリリース担当者(調達者)にして，ステータスを承認済みに変更する。	承認済み
	リリース管理者	リリース計画の差し戻し	承認依頼を受けたリリース計画の内容に入力誤りなどがあった場合，このリリース計画を差し戻す。	計画中
	リリース担当者 (調達者)	ハードウェア，ソフトウェアの調達	リリース案件の内容を確認し，必要となるソフトウェア，ハードウェアを調達する。担当者をリリース担当者(実装チーム)に変更する。	承認済み
	リリース担当者 (実装チーム)	リリース作業の実施，構成情報の更新依頼	リリース作業を実施する。「作業結果報告」に記入し，担当者を構成変更担当者に変更，対応を依頼する。	対応依頼中
	構成変更担当者	構成情報の更新	「作業結果報告」に基づいて，構成情報を更新する。担当者をリリース管理者に変更する。	承認済み
	リリース管理者	クローズ	リリース案件の作業内容を確認し，リリース案件をクローズする。	クローズ

注※: 案件のステータスを「審議中」に変更したあとに「審議中」の担当者が編集した場合，その案件を引き戻すことはできません。

以上のような検討をした上で，各プロセスの，各作業で扱う情報を，管理が必要な項目（表5-2で出現したキーワードなど）として洗い出します。

次に，JP1/Service Supportの設定項目と比較し，名称の変更や追加が必要な項目を整理します。

〈この節の構成〉

ページの先頭へ

5.2 対象システム，プロセスの決定と体制作り

5.2　対象システム，プロセスの決定と体制作り