前回は、当該の活動で重点的に対応（再構築）するプロセスとして、選定し、設計した業務プロセスのひとつ、 「変更管理プロセス」の概要を紹介しました。今回は、同様に選定し、設計した業務プロセスのひとつ、「問題管理プロセス」を紹介します。 当該のモデルは「インシデント管理」を含んだ「問題管理プロセス」としています。 「インシデント管理プロセス」の役割を担う「サービスデスク」が、統合化された利用者の総合窓口として存在する場合は、 「インシデントの管理」と「問題の管理」の、個別の連携するプロセスとして、構築すべきかと思います。 ここで言う、統合化された利用者の総合窓口とは、基幹系・オープン系のシステム全ての利用者に対するサービスを担っている組織を指します。この場合、設置される利用者窓口（サービスデスク）は第一レベルの問題解決を担います。 そして、第二レベルの問題解決は運用技術者、第三レベルの問題解決はシステム技術者が担うことになります。 当該のモデルは、この第一レベルと第二レベルを厳格に分離しない中規模の組織に適用したものです。

目次

1.コントロール目標と成果指標

2.管理プロセス

1.コントロール目標と成果指標

　当該の「問題管理プロセス」の目的は、ビジネスに与える悪影響を最小にするために、発生する問題に対処し、再発防止と予防の措置を講じることです。

　 〈　問題の範囲を最小にすること　〉
　 〈　問題の回復時間を短縮すること　〉
　 〈 　適切にかつ、迅速に問題を解決すること　〉
　 〈　同様な問題の再発を防止すること、予防すること　〉
　 〈　問題の発生から回復までに要する労力を減少させること　〉
　・・・によって、提供するIT運用のサービスレベルを向上し、情報システムの利便性を高め、利活用者の満足度を維持し向上させることを目標にします。

システム利活用者からの問合せを含むインシデント、あるいは自らが検知したインシデントの通報先（窓口）を一元化し、問題の回復から解決するまでの手続きを標準化する。また、その手続きの実行を記録する。
記録は、問題の管理手続きに沿って並行して行う。その記録は、各プロセスを担う技術者や管理者、その他の必要な関係者と共有する。
インシデントを含むすべての問題は、その管理目的に即して区分（　「問合せ」「警告」「障害」　）する。「問題の回復措置」と「問題の解決」は、その区分の定義に従って実施する。当該の問題管理プロセスで扱う「警告」とは、障害ではないが、何らかの予防措置を必要とする問題を言う。また、回避手順が準備され運用されているインシデントも、この区分に含むこととする。
「障害」と区分された問題は、定義された影響度区分（ビジネスに与える損害の度合）と報告基準に従って、関係者・関与者および組織管理者に連絡する。必要に応じて、問題管理者は必要なメンバーを招集し、「対策会議」を開催する。
問題を回避する、回復する、解決する（恒久的な再発防止・予防措置を講じる）などにより生じる、情報リソースに対する変更は、「変更管理プロセス」と密接（システム的）に連携して、これを実施する。また、変更する情報リソースのインテグリティは、「アクセス管理プロセス」との連携によって保証する。
問題の発生と処置の結果、および問題解決（恒久の再発・予防対策）の進捗状況は、設定するサービスレベルオブジェクト（SLO）により、モニタリングし、その結果を評価する。また、「変更管理プロセス」に含まれる「システム利活用者の満足度調査」の結果から、その評価を検証する。
IT部門を統括するマネージャーは、率先して、問題の「管理状況」と「活動の成果」をレビューし、必要な対策を指示する。

＜　成果指標　＞

　上述のコントロール目標の達成状況を測定します。成果指標は当該の問題管理プロセスの中で測定し、IT部門の目標管理プロセス（システム）で管理されます。

インシデントの件数と、回避あるいは回復に費やした時間
ＩＴ運用のロス時間（再処理に要した時間、停止した時間）
問題解決（恒久対策）によってクローズしたインシデントの件数
変更要求件数と未処理の件数
未解決の問題件数
サービスレベルオブジェクトの達成率

 

2.管理プロセス

　上述のコントロール目標に適応したプロセスを再設計します。以下に、その概要を示します。

《　0.00　問題管理プロセス　》

ここで紹介する問題管理プロセスは、次の５つの業務(上図)で構成されています。それは、情報サービスを提供する側および利活用する側の期待に反する現象を”問題”として捉えて、管理するものです。たとえば、

-　情報処理機器や設備の誤作動、ダウン
-　適用業務システムの異常終了、データの誤った入出力
-　機密情報の漏えい、データの流出や紛失
-　情報処理パフォーマンスの低下
-　手順、操作の誤り、ルール違反
-　等々の問合せやワーニング(warning)を含む、これらの現象を対象にします。

　　
　　1.00　インシデントの受付と調整
　　2.00　業務支援（ヘルプサービス）
　　3.00　障害の除去／復旧措置
　　4.00　問題の解決（恒久措置）
　　5.00　マネジメントレビュー

　上記の業務、「1.00　インシデントの受付と調整」と、「2.00　業務支援（ヘルプサービス）」、「3.00　障害の除去／復旧措置」の基本要件は、検知したインシデントを速やかに対処することです。そして、ＩＴ運用のサービスを迅速に復旧させることです。
上記の業務、「4.00　問題の解決（恒久措置）」の基本要件は、問題の根本原因を追究し、再発の防止あるいは予防のための対策を実施することです。
上記の業務、「マネジメントレビュー」は、これらの業務がうまく行われているかどうか、その管理状況をモニタリングし、継続的な品質改善の活動を促進します。
特に上述の「サービスの復旧」と「問題の解決」には、本質的に異なる概念が存在します。
ひとつは時間的な概念です。前者は急ぎます。したがって、その措置はワークアラウンド（回避する手段）が中心となります。後者は、それ程には急ぎません。・・と、いうより時間を要すると言ったほうが正しいかも知れません。また、個々のインシデントに対応すると言うよりは、インシデントを原因別に層別したりして、まとめて対応することが一般的です。
もうひとつは、コストの概念です。後者は情報基盤の入れ替えなどの大きな投資が必要になることがあります。解決策とその措置には採算性（投資＜利益）に対する検討が必要になります。

したがって、次の点について考慮すべきです。

（１）　「変更管理プロセス」に対する変更要求は、前述の相反する概念を十分に認識し、識別してコントロールする必要があります。
（２）　前述の「サービスの復旧」で対応を終了するインシデントもあることから、「問題の解決」を必要とするインシデントが、未解決の　　　　まま放置されてしまう危険があります。無事に復旧した安堵感から解決すべき問題を結果として放置することのないように区分　　　　し、コントロールする必要があります。

 

《　1.00　インシデントの受付と調整　》

当該のプロセス（上図）は、インシデント発生の通報を受付けて、そのインシデントを分類し、通報の内容を記録する業務です。インシデントの受付は一元化された窓口で行われることがベスト（あるべき姿）です。・・が、当該のモデルでは、課業別（グループ別）の対応としています。（課業は、それぞれが管理する情報リソースを保有しています。）
この場合、システムの利活用者に対する窓口の周知と窓口間（受付けた人同士）の連携が、重要な要件となります。検知し通報した人と、最初に通報を受付けた人の関係は、復旧措置が完了するまで維持されるべきです。また、記録する文書（問題報告書）を共有する仕組み（データベース）も用意すべきです。

裏返して言えば、誰に相談したら良いか分からない。問題をたらい回しされた。通報したインシデントがどうなったか尋ねても分からない。・・等々の迅速性を損なうことの、リスクを排除する仕組みが必要です。

１.10　インシデントの検知
　インシデントを検知し通報します。通報先（インシデントの受付窓口）は、社内Web（掲示板）や連絡文書等によって周知して置きます

　通報する内容は次のとおりです。

　 ＊　通報者と通報者の所属組織
　 ＊　インシデント発生部署
　 ＊　インシデントを検知した日時
　 ＊　インシデントの対象
　 ＊　状況（インシデントの内容と起きている悪影響等々）
　 ＊　状況を示す資料等
1.20　インシデントの受付
　受付窓口はインシデント発生の通報を受付けます。上述（１.10　インシデントの検知）の通報内容を確認し検証します。「問題報告書」を起票し、上述の通報内容と次の内容を付加し、記録します

　「問題報告書」に付加する記録内容は次のとおりです。

　 ＊　受付者と受付者の所属組織
　 ＊　受付番号（「問題報告書」の識別番号
　 ＊　受付の手段と受付日時
　 ＊　状況の情報添加（通報の状況に対して、IT運用面からの情報添加）
1.30　インシデントの判別
　受付けたインシデントの状況から、次の判断により、そのインシデントを区分し「問題報告書」に、その区分を記録します。

判断（１）　インシデントの種類による区分
　　　　　　（　区分の内容は、前述「１．コントロール目標の（３）」を参照　）

区分１　：　問合せ　→「2.00　業務支援（ヘルプサービス）」へ
区分２　：　警告　　用意された回避手順がある場合は
→「2.00　業務支援（ヘルプサービス）」へ
回避手順を作成する場合は
→「2.20　回避方法の提示」へ
区分３　：　障害　　→「3.10　障害発生の連絡」へ

　　　　判断（２）　インシデントの対象区分

　　　　　　　　　　回復・回避措置に伴うエスカレーション（専門技術者、管轄組織）および再発防止・予防措置に伴う対策の策定と実施等のコントロールを目的とする区分で、インシデント発生の対象（情報基盤）を識別する区分です。（例えば、適用業務システム、オペレーションシステム、サーバー、ネットワーク等々、コントロール目的に副って設定します）

　　　　判断（３）　影響度のレベル（予測）

　　　　　　　　　　上述の判断（１）インシデントの種類による区分で「障害」と区分されたインシデントについて、その障害が内外に及ぼす影響度合を予測し判別します。後続する以降のプロセス（3.00　障害の除去／復旧措置）を適切に実施するために、その影響度のレベルを定義しておきます。

　　　　　　　　　　次に、そのサンプルを例示します

レベル１：　緊急度＝大。ビジネスに重大な影響を及ぼし、金銭的な損失(xxx円以上)、信用の失墜を招く障害のレベル。社内業務に及　　　　　　　ぼす影響の範囲は、全社的で復旧に長時間（xx時間以上）を要する。
　　　　　　　　【　障害の参照事例
　　　　　　　　　　→xxxxxxxxxx／xxxxxxxxxx／xxxxxxxxxx／・・・・　】
レベル２：　緊急度＝大。ビジネスに影響を及ぼす。金銭的な損失(xxx円以下)を伴う場合があり、一時的な信用の失墜を招く障害のレ　　　　　　　ベル。社内業務に及ぼす影響の範囲は、限られた複数の利用部門あるいは不特定多数の利用者で復旧に長時間（xx時間　　　　　　　　以上）を要する。
　　　　　　　　【　障害の参照事例
　　　　　　　　　　→xxxxxxxxxx／xxxxxxxxxx／xxxxxxxxxx／・・・・　】
レベル３：　緊急度＝中。ビジネスへの影響はほとんどない。直接的な金銭的損失もない。社内業務に及ぼす影響の範囲は限定され　　　　　　　復旧に要する時間は許容できる局所的で許容できる障害のレベル。
　　　　　　　【　障害の参照事例
　　　　　　　　　　→xxxxxxxxx／xxxxxxxxxx／xxxxxxxxxx／・・・・　】
レベル４：　緊急度＝中以下。ビジネスへの影響はなく、内部の限定的な障害で一部の利活用者および短時間の業務遅延を伴うレベ　　　　　　　ルの障害。
　　　　　　　【　障害の参照事例
　　　　　　　　　　→xxxxxxxxxx／xxxxxxxxxx／xxxxxxxxxx／・・・・　】
レベル５：　緊急度＝小。支障なく（利活用者および部門に影響を及ぼすことなく）復旧する障害のレベル。
　　　　　　　【　障害の参照事例
　　　　　　　　　　→xxxxxxxxxx／xxxxxxxxxx／xxxxxxxxxx／・・・・　】

 

《　2.00　業務支援（ヘルプサービス）　》

当該のプロセス（上図）は、「1.00　インシデントの受付と調整」で判別された「問合せ・警告」や、「回避手順を用意している、あるいは用意する必要のある障害」などに対応するもので、次の４つの要素で構成されています。対応の内容は「問題報告書」に記録します。

2.10　業務支援（ヘルプサービス）
　システム利活用者の問合せに対して、必要な回答やオペレーションの支援をします。また、定常業務として回避手順が用意されているインシデントについて、その回避手順を適用します。そして、その対応の内容を「問題報告書」に記録し、所属する部署の管理者に報告します。管理者は報告内容を確認し、承認します。
定常業務として用意されている回避手順とは、運用上の手順とシステムの内部ロジックとして組み込まれている手順があります。組み込みの手順には、自動的に適用されるものと、適用のためのアクションが必要なものがあります。すべての回避手順は、当該業務をアシストする「回避手順書」に収録します。
「問題報告書」に記録する内容は次のとおりです。

インシデントの分類（IT運用の品質を管理し改善するために定義する、層別された分類コードです）

　 ＊　インシデントの分類（IT運用の品質を管理し改善するために定義する、層別された分類コードです）
　 ＊　対応の内容
　 ＊　対応の日時
　 ＊　対応に要した時間と対応の工数
　 ＊　対応者の名前と所属する組織名
　 ＊　管理者の名前（確認のサイン）

2.20　回避方法の提示
　非障害のインシデント（インシデントの種類による区分＝警告）で回避手順が用意されていないものについて、その回避手順を検討し、システムの利活用者に提示し適用します。システム基盤や適用業務システム等々の変更が必要な場合は「変更申請書」を発行し、変更管理プロセスと連携します。また、作成された回避の方法は「回避手順書」に記述し、収録します。

「問題報告書」に記録する内容は、次のとおりです。

　 ＊　インシデントの分類（IT運用の品質を管理し改善するために定義する、層別された分類コードです）
　 ＊　対応の内容（作成した回避手順と、その手順を識別する番号）
　 ＊　対応の日時
　 ＊　対応に要した時間と対応の工数
　 ＊　対応者の名前と所属する組織名
　 ＊　変更申請書の番号（システム基盤や適用業務システム等々の変更が必要な場合））

2.30　回避措置の実施
上述の「2.20　回避方法の提示」で提示した手順に従って、回避措置を実施します。回避措置の実施は、システムの利活用者にお願いする場合と、IT運用の内部的な措置作業の場合があります。

実施の結果を検証し、所属する部署の管理者に報告します。管理者は報告内容を確認し、回避措置の完了を承認します。
「問題報告書」に記録する内容は、次のとおりです。

　 ＊　上述、管理者の名前（確認のサイン）

2.40　業務の継続

当該のプロセスで実行された「業務支援（ヘルプサービス）」や「回避措置の実施」の結果を継続して監視します。監視の期間は原則として適用して１週間、あるいは運用の１サイクルとします。監視の結果、検知した不具合は、新たなインシデントとして処理（１.10　インシデントの検知）します。

 

《　3.00　障害の除去／復旧措置　》

当該のプロセス（上図）は、「1.00　インシデントの受付と調整」で障害（インシデント区分＝３）と判別されたインシデントに対応するもので、次の７つの要素で構成されています。対応の内容は、「問題報告書」に記録します。「問題報告書」は、対応するメンバーおよび組織管理者／マネージャーの、共有文書（データベース）とします。当該の共有文書は、アクセス権限の設定下で、システム的に常時、検索可能とします。

障害の除去あるいは復旧措置を担う技術者は、その作業と並行して、その都度、その作業の内容を記録していくことが重要です。作業に没頭するあまり、復旧してから、まとめて記録することになりがちです。この場合、復旧するまで記録されないことになりますから、多分、他のメンバーおよび組織管理者／マネージャーは、いらいらした長～い時間を過ごすことになります。孤軍奮闘、うまく問題を解決しても、問題は共有できていません。マネジメントのレベルも向上しません。結果として、常に、優秀な技術者がトラブルシューティングに追われることになります。

3.10　障害発生の連絡
　障害の除去あるいは復旧措置を担う技術者の所属する組織管理者は、障害の発生を、あらかじめ設定されている「告知基準」に副って連絡します。告知基準は告知の手段と告知先を定めています。告知の手段は、社内Web（掲示板）、電子メール、電話、FAX等々を使用します。告知先は、前述の区分である「インシデントの対象」と「影響度のレベル」に対応して設定します。

「問題報告書」に記録する内容は、次のとおりです。

　 ＊　障害発生の連絡日時と連絡済のサイン
　 ＊　同上、メモ（考慮事項等、なにもなければ無記入）

3.20　障害の状況分析
　障害の状況と障害の発生した直接的な原因を分析し特定します。捕捉した状況や原因の事実を証明する記録や資料があれば収集します。

3.30　復旧方法の検討
　特定した障害の状況、原因から有効な復旧の方法とその手順を検討します。復旧の方法とその手順には、復旧措置の実施前に戻る方法と手順を含みます。所属する組織管理者に検討結果を報告し実施の許可を得ます。必要であれば、復旧措置に必要な関与者、およびその管理者による事前のレビューを実施します。その場合、所属する組織管理者は、レビューにおいて適時に（緊急度に応じて）最終の判断を行う必要があります。

　「問題報告書」に記録する内容は、次のとおりです。

　 ＊　状況の補正と情報添加（証憑資料等）
　 ＊　障害発生の原因
　 ＊　インシデントの分類（IT運用の品質を管理し改善するために定義する、層別された分類コードです）
　 ＊　復旧の作業計画
　　　　（復旧方法とその手順）
　　　　（実施日時／スケジュール）
　 　　 (実施の体制／対応予定者の名前と所属する組織名）
　　　　（復旧作業に要する工数）
　＊　対応者の名前と所属する組織名
　＊　管理者の名前（計画承認のサイン）

3.40　復旧措置の手配
　上述の作業計画に基づいて、措置の実施に必要な準備をします。システム基盤や適用業務システム等々の変更が必要な場合は変更申請書を発行し、「変更管理プロセス」と連携させます。措置を担う技術者の手配、および措置を実施するシステム環境の設定、システム利活用者を含む関与者との調整、等々を行います。

「問題報告書」に記録する内容は次のとおりです。

　 ＊　変更申請書の番号
　　　　（システム基盤や適用業務システム等々の変更が必要な場合）

3.50　復旧の措置
　上述の作業計画に基づいて、復旧の措置を実施します。

「問題報告書」に記録する内容は次のとおりです。

　 ＊　復旧の作業結果
　　　　（前述の作業計画と作業を行った結果の相違点について記述します）
　 ＊　復旧の作業計画
　 ＊　復旧したことの証憑資料（添付）
　 ＊　対応者の名前と所属する組織名

3.60　復旧の措置
　組織管理者は、復旧作業の結果を検証します。添付の証憑資料などから、復旧の状態と障害の直接原因が除去されたことを確認します。特に、二次障害が発生するリスクについての検証が必要です。また、「変更管理プロセス」との連携が適正に行われたかどうかも、重要な検証事項です。

　　正常に復旧したことを確認したら、措置の完了を宣言し、対応者に関与者への報告を指示します。
「問題報告書」に記録する内容は次のとおりです。

＊　管理者の名前（復旧措置の完了サイン）
＊　復旧措置の完了年月日）
＊　影響度のレベル（結果）

3.70　復旧の報告
　組織管理者による「復旧措置」の完了宣言を受けて、関与者に復旧の連絡をします。連絡は、前述の「3.10　障害発生の連絡」における「連絡の手段」および「告知先」に対して行います。

　　
「問題報告書」に記録する内容は次のとおりです。

＊　復旧措置完了の連絡日時と連絡済のサイン

《　4.00　問題の解決（恒久措置）　》

当該のプロセス（上図）は、前述のプロセス「2.00　業務支援（ヘルプサービス）」と「3.00　障害の除去／復旧措置」で記録した「問題報告書」から、障害発生の真の原因を究明し、障害の再発防止と予防のために、必要な対策を立案して、実施します。
　基本的な当該プロセスの実行サイクルは、定期的（月毎）です。ただし、影響度のレベル＝１、および影響度のレベル＝2と判定された障害は、「問題報告書」毎のプロセスである「3.00　障害の除去／復旧措置」に続いて実行します。
　定期的なサイクルにおける「問題報告書」は、真の原因別にまとめて処理します。個々に処理する「問題報告書」は、その問題を個々に解決することになります。
当該の業務プロセスは、次の６つの要素で構成されています。

4.10　対応の適時判断
　問題の調整者は、組織管理者と協議して、影響度のレベル＝１、および影響度のレベル＝2と判定された障害で、前述のプロセス「3.00　障害の除去／復旧措置」に続いて、個別に真の原因を究明し、恒久の対策を実施するか、定期的な月毎のサイクルによる対応にするか、その適時性により、判断します。

4.20　問題の分析と評価
　問題の調整者は、真の原因を究明し、起因・原因別に問題発生件数を集計します。問題発生件数に発生の推移や影響度のレベル等を、計数化して加え、その対策実施の有効性を評価します。

4.30　恒久対策の立案
　問題の調整者は、保全（改善）会議に問題の分析と評価の結果を提示します。保全（改善）会議において、提示の内容を共有し確認し、恒久対策としての問題の再発防止・予防の対策を協議し、その実行を立案します。
—————————————————
《　保全（改善）会議　》
会議の構成員　　（１）問題の調整者（問題管理コーディネーター）
　　　　　　　　　　　 （２）組織管理者
　　　　　　　　　　　 （３）組織管理者が任命する常任のメンバー
　　　　　　　　　　　 （４）問題の調整者が、その都度、必要に応じて招集するメンバー
　　　　　　　　　　　　　　（システムの利活用者、専門技術者、メーカーの責任者等々）
会議体の機能　　（１）問題の分類／（２）調査と診断／（３）原因の分析／
　　　　　　　　　　　 （４）恒久対策のテーマ選定／（５）対策の立案と有効性の評価／
　　　　　　　　　　　 （６）対策の実行計画の作成／
　　　　　　　　　　　 （７）対策の実施状況（進捗）のモニタリングと完了の確認
　　　　　　　　　　　 （８）実施結果の有効性評価
　　　　　　　　　　　 （９）IT部門を統括するマネージャーへの報告
　　　　　　　　　　　　　　（組織管理者が代表して）
会議の成果物　　（１）実行計画書／実施報告書
　　　　　　　　　　　　　　（体裁は議事録でも可とします）
—————————————————
4.40　対策実施の可否判断
　組織管理者は「保全（改善）会議」の提案（対策の実行計画）を受けて、その対策の実施可否を判定します。影響度のレベル＝１、および影響度のレベル＝2と判定された障害に関わる対策の実施は、IT部門を統括するマネージャーに報告し、実施の許可を得ます。

4.50　対策の実施と結果の確認
　問題の調整者は組織管理者の指示で、許可された実行計画を実施に移します。システム基盤や適用業務システム等々の変更が必要な場合は変更申請書を発行し、「変更管理プロセス」と、連携します。問題の調整者は、実行計画に副って必要な作業およびシステムの環境を整え、必要なメンバーを手配し、実施の状況をコントロールします。そして、実施結果の正当性に関わる証憑資料を収集して、作業の完了を確認します。

　「問題報告書」に記録する内容は次のとおりです。

―　影響度のレベル＝１、および影響度のレベル＝2と判定された障害に関わる対策の完了について

　 ＊　再発防止・予防措置の実施内容
　 ＊　作業開始日と完了日時
　 ＊　作業工数（作業に要した時間と人数）
　 ＊　措置実施部署と実施担当者および責任者の名前とサイン
　 ＊　問題の調整者の名前とサイン
　 ＊　変更申請書の番号
　　　　（システム基盤や適用業務システム等々の変更が必要な場合）
　 ＊　作業工数（作業に要した時間と人数）
―　上記以外の定期的な月毎のサイクルで対応する対策の完了について

　 ＊　実行計画を識別する番号
　　　　（上記の内容は「実行計画書／実施報告書」に記録します） 　

「問題報告書」に記録する内容は次のとおりです。

　 ＊　復旧の作業結果
　　　　（前述の作業計画と作業を行った結果の相違点について記述します）
　 ＊　復旧の作業計画
　 ＊　復旧したことの証憑資料（添付）
　 ＊　対応者の名前と所属する組織名

4.60　対策の完了報告
　問題の調整者は、対策の実施に関係する部署および関係者と組織管理者に、計画した対策の完了を報告します。組織管理者は対策の完了を確認し、影響度のレベル＝１、および影響度のレベル＝2と判定された障害に関わる対策の完了について、IT部門を統括するマネージャーに報告します。

「問題報告書」に記録する内容は次のとおりです。

　 ＊　管理者の名前と完了を確認した日付と承認のサイン
　 ＊　IT部門を統括するマネージャーの名前と完了を確認した日付と承認のサイン（影響度のレベル＝１、
　 　　　および影響度のレベル＝2と判定された障害に関わる対策の完了についてのみ）

 

《　5.00　マネジメントレビュー　》

当該のプロセス（上図）は、「保全（改善）会議」を中心としたプロセスで、冒頭の「成果指標」の結果をモニタリングし、IT運用サービスの継続的な改善活動を促します。改善活動の主体は、品質管理（IT運用サービスの品質を維持し向上させること）活動です。成果として、《　①サービスレベルの向上　》《　②サービスコストの低減　》《　③システムの利便性向上　》をはかることによって、システム利活用者の満足度を向上させます。
当該の業務プロセスは、次の４つの要素で構成されています。

5.10　計画／実績データの収集
定期的（月末）に管理データを収集します。
計画データは、保全（改善）会議において、期初に設定した「サービスレベル・オブジェクト（SLO」です。「サービスレベル・オブジェクト」とは、サービスレベルアグリーメントの「Agreement」を「Object」に捩ったもので、世の中に通用している言葉ではありません。当該のモデルは、サービスレベルを前述の「１．コントロール目標と成果指標」の内容を基軸とした「Object（目標）」として設定します。その目標は、「Agreement（契約）」するのではなく、システム利活用者と共有する目標値とします。したがって、企業内IT部門としては、システム利活用者に情報リテラシーの向上を求め、学習を促すこともあります。
実績データは、記録された「問題報告書」に加えて、「利用者満足度調査」やオペレーション・システムから得られる「パフォーマンス情報」などから、入手します。

5.20　データの分析
収集したデータを元に、問題の内容を統計し、その傾向を分析します。そして、期初に設定した、「サービスレベル・オブジェクト」との差異について、その原因を分析します。分析した結果、導き出した改善策を明確にします。期末に、次のステージに向けた、「サービスレベル・オブジェクトの更新」および、改善テーマを策定します。

5.30　管理レポートの作成
　上述「4.20データの分析」の結果を、レポートにまとめます。レポートは次の2種類です。

「問題報告書」に記録する内容は次のとおりです。

＊　復旧の作業計画
＊　６ケ月単位（定期的な目標管理ベース）

5.40　マネジメントレビュー
IT部門を統括するマネージャーは、定期的に管理レポートに基づく報告を受けます。レビューは、冒頭に記述の「コントロール目標と成果指標／サービスレベル・オブジェクト」を中心に、その達成度を評価します。そして期初に、次のステージに向けた、「サービスレベル・オブジェクトの設定」を含む、改善活動の実行計画をレビューし、その実行を指示します。

　次回は、最終回です。連載の流れからすると「オペレーション管理プロセス」になりますが、趣を変え、《　運用管理者のメモ書き的「バランス・スコアカード」　》と題して、当該の活動のバックグランドとして作成していた、運用管理者のメモ書き的なツールを、最終回のまとめとして、紹介します。