サービスオペレーション

【サービスオペレーション】
サービスオペレーションは、サービス・ライフサイクルの段階の1つであり、サービスを、合意されたレベルで事業のユーザと顧客に提供し管理するために必要な活動とプロセスを調整して実行します。サービスオペレーションは、サービスの提供と、サポートに使用される技術の継続的な管理にも責任を負います

ITサービスは、サービスストラテジで戦略を立て → サービスデザインで設計し → サービストランジションで導入、の段階を経て、サービスオペレーションで運用されます。サービスオペレーションは、顧客がはじめてITサービスを導入したことの価値を認識できる段階です。
十分に計画されたサービスでも、適切に運用され、管理されなければ意味がありません。また、サービスを改善するためには、パフォーマンスの監視、測定基準の評価、運用データの収集という日々の活動も必要です。これらの活動を行うサービスオペレーションは、サービス・ライフサイクルの中でも非常に重要な段階です。

【サービスオペレーションのプロセス】
サービスオペレーションの主なプロセスは以下のとおりです。
これらのプロセスはサービスオペレーションに関連付けられていますが、ほとんどのプロセスには、サービス・ライフサイクルの複数の段階にわたって行われる活動があります。

【サービスオペレーションの機能】
サービスオペレーションには「サービスデスク」「技術管理」「IT運用管理」「アプリケーション管理」といった4つの機能も含まれます。

サービスデスクとIT運用管理は、実際に運用活動を行う機能です。
技術管理とアプリケーション管理は、ITサービスを提供するために必要となるITインフラストラクチャやアプリケーションを管理する機能です。

【サービスオペレーションにおけるコミュニケーションの役割】
サービスオペレーションでは、ユーザや顧客、他のITチームや部門との間で良好なコミュニケーションをとることが必要です。適切なコミュニケーションによって、課題の発生を予防できたり課題を緩和できます。
すべてのコミュニケーションは目的を持って行い、コミュニケーションの結果として何らかの処置を行います。また、コミュニケーションの対象者が明確でない場合は、情報を伝えるべきではありません。

以下は、サービスオペレーションにおける典型的なコミュニケーションの種類です。

・運用に関する日常的なコミュニケーション
サービスオペレーションの定期的な活動を調整します。すべてのスタッフがスケジュールされた活動や、通常の運用に影響を及ぼす可能性がある変更を認識するようにします。

・シフト間のコミュニケーション
シフト制で作業している人々が、シフト間で行う引き継ぎです。

・パフォーマンス報告
ITサービスのパフォーマンスと、サービスオペレーションのチームや部門のパフォーマンス、ITインフラストラクチャやプロセスのパフォーマンスを報告します。

・プロジェクトにおけるコミュニケーション
プロジェクト・チームで作業の割り当てや、プロジェクトの進捗の確認、報告などを行います。

・変更に関するコミュニケーション
変更によって発生するインパクトや変更に必要なリソースを評価したり、変更に関する情報を報告したりすることによって、変更管理プロセス、「リリース管理および展開管理」プロセスをサポートします。

・例外に関するコミュニケーション
通常または予測された活動やパフォーマンスから外れるすべての事象が発生した場合の情報を共有します。

・緊急事態に関するコミュニケーション
インシデントのインパクトと重大度を迅速に調査して、緊急事態であることを確認します。また、このインシデントがサービスデザインの「ITサービス継続性計画」に記載された災害や緊急事態に当てはまらないことも確認します。ITサービス継続性計画で網羅されていない事態に対処するために、緊急事態の適用範囲を明確化した後、処置計画を策定し、解決するためのリソースを割り当てます。

・グローバルなコミュニケーション
サービスオペレーションの活動が複数の国で実施される場合に、言語、カルチャ、国ごとの規制要件の違いによる運用リスクや顧客満足度の低下を防ぐために、明確な戦略と方針を整備します。

・ユーザおよび顧客とのコミュニケーション
ユーザおよび顧客に、インシデントに関する最新の情報を提供し続けたり、インパクトを与える変更を通知したり、顧客満足度をレビューしたりと、多くのコミュニケーションがあります。ユーザおよび顧客とのコミュニケーションでは、ITサービス・プロバイダが実行していることに焦点をあてるべきで、技術的な説明や内部プロセスの詳細な情報は含むべきではありません。

【問題管理】
問題管理は、サービスオペレーションのプロセスの1つであり、すべての問題のライフサイクルを管理することが責務です。

「問題」とは、1つまたは複数のインシデントを引き起こす根本原因です。
問題管理は、インシデントおよび問題による事業へのインパクトを最小限に抑え、インシデントの再発をプロアクティブに防止するよう努めます。これを達成するために、問題管理はインシデントの根本原因を特定し、既知のエラー(後述します)として文書化し、状況を改善するための処置を行います。

以下は、問題管理の達成目標です。

・問題と、その結果によるインシデントの発生を防ぐ。
・再発するインシデントを排除する。
・防止できないインシデントのインパクトを最小限に抑える。

問題管理がインシデント管理と違う点は、インシデント管理の主な目的は通常のサービス運用をできるかぎり迅速に回復させることですが、問題管理プロセスの目的は、インシデントの根本原因の特定、解決、予防です。問題管理プロセスの活動によってインシデントの数が減り、ITサービスの高い品質や可用性を維持できるようになります。

【問題モデル】
問題モデルは、特定の種類の再発する問題を処理するステップを、事前に定義する方法です。
多くの問題はそれぞれ原因が異なり個別に対処する必要がありますが、一部の問題は再発することが考えられます。例えば、根本的な解決を行うためのコストが高いため、あえて解決せずに問題と共存していくことを選択しなければならない場合などです。

【ワークアラウンド】
ワークアラウンドは、まだ完全な解決策が存在しないインシデントや問題のインパクトを低減、排除することです。一時的な回避策です。例えば、障害が発生した構成アイテムを再起動することや、プログラムへの入力ファイルに手動で修正を加えるなどがあります。
問題に対するワークアラウンドは、既知のエラー・レコードとして文書化します。問題と関連付けられていないインシデントに対するワークアラウンドは、インシデント・レコードとして文書化します。

【既知のエラー】
既知のエラーは、文書化された根本原因とワークアラウンドがある問題です。既知のエラーは問題管理が作成、管理します。開発者やサプライヤが既知のエラーを特定する場合もあります。

【既知のエラー・データベース(KEDB: Known Error Database)】
すべての既知のエラーの詳細は「既知のエラー・レコード」として、既知のエラー・データベース(KEDB)に格納します。既知のエラー・レコードには、それが関係する問題レコード(問題の詳細を含むレコード)の識別、解決するための処置のステータス、根本原因、ワークアラウンドが含まれます。
既知のエラー・レコードは、問題の診断が完了し、恒久的な解決策はまだ不明でも、ワークアラウンドが見つかった時点ですぐに作成する必要があります。これは、さらなるインシデントや問題が発生した場合に、迅速な診断と解決ができるようにするためです。
しかし、診断が完了していない場合やワークアラウンドが見つかっていない場合でも、もっと早い段階で既知のエラー・レコードを提起する方がよい場合もあります。これは、問題に対処できるかもしれないが完全には確認されていない根本原因やワークアラウンドを識別するために、もしくは情報として、既知のエラー・レコードが使用される場合です。よって、既知のエラー・レコードを提起するタイミングの具体的な決まりはなく、そうすることが有益となった時点で提起すべきです。
既知のエラー・データベースは問題管理が作成、管理し、インシデント管理と問題管理が使用します。
既知のエラー・データベースは構成管理システム(CMS)の一部として、またはサービス・ナレッジ管理システム(SKMS)の任意の場所にも格納できます。

【問題管理の活動】
問題管理プロセスの活動は、それがどのように開始されるかによって、「プロアクティブな問題管理」と「リアクティブな問題管理」の2つに分かれます。

[プロアクティブな問題管理]
プロアクティブな問題管理では、過去のインシデント・レコードを分析したり、他のプロセスによって収集されたデータを使用して傾向を識別することで、インシデントの発生を予防します。
プロアクティブな問題管理のプロセス活動は、サービスの改善を求める活動によって引き起こされます。例えば、過去のインシデントに共通する根本原因を見つけて再発を防止するための傾向分析活動などがあります。

[リアクティブな問題管理]
リアクティブな問題管理では、インシデントが発生してから調査、分析を行い、根本原因を特定することで、インシデントの再発を防止します。
リアクティブな問題管理では、以下の活動を行います。

①問題の検出
　　問題は以下の方法で検出されます。
　　・サービスデスクから、インシデントの根本原因の調査が必要な場合に問題レコードが提起される。(インシデント管理)
　　・イベント管理ツールで障害が自動検出される。(イベント管理)
　　・技術サポート・グループから、インシデントの分析によって判明した問題が報告される。(インシデント管理)
　　・プロアクティブな問題管理から、インシデントの分析の結果、さらなる根本的な原因の調査が必要な場合に問題レコードが提起される。
　　・サプライヤや委託先から、問題が報告される。
②問題の記録
　　すべての問題の詳細(関連するインシデントの情報も含む)を問題レコードに記録します。
③問題のカテゴリ化
　　ハードウェアの問題、ソフトウェアの問題など、インシデントと同じ基準で分類します。カテゴリ化によって、問題の性質を追跡しやすくなり、意味のある管理情報を取得できるようになります。
④問題の優先度付け
　　インシデント管理と同様に、インパクトと緊急度から問題の優先度を決定します。さらに、関連するインシデントの発生頻度とインパクト、問題の重大度も考慮します。
　　問題の重大度は、どれほど深刻であるかを、以下の点を踏まえて表したものです。
　　・システムは復旧可能か？交換の必要があるか？
　　・コストはどのくらいかかるか？
　　・問題の解決にはどのようなスキルを持った人が何人必要か？
　　・問題の解決にはどのくらいの期間がかかるか？
　　・問題の影響の範囲は？
⑤問題の調査と診断
　　問題の根本原因を調査、診断します。構成管理システム(CMS)を参照して障害点を特定したり、既知のエラー・データベース(KEDB)を参照して類似の事例がないか確認します。
⑥ワークアラウンドの特定
　　問題によって発生したインシデントのワークアラウンドを特定できた場合、インシデントや問題のインパクトを低減できます。また、その場合は、問題レコードをオープンのままにして、ワークアラウンドの詳細を問題レコード内に記録します。
⑦既知のエラー・レコードの提起
　　診断が完了し、根本原因かワークアラウンドのいずれかが特定できたら、既知のエラー・レコードを作成し既知のエラー・データベース(KEDB)に格納します。
⑧問題の解決
　　問題の解決策を実施します。ここでシステムの変更が必要となる場合、問題管理はサービストランジションの「変更管理」プロセスに変更要求(RFC)を提出します。
⑨問題のクローズ
　　解決策が適用されたら問題レコードをクローズします。問題に関連するオープン中のインシデント・レコードもクローズします。また、関連する既知のエラー・レコードのステータスも、解決策が適用されたことが分かるように更新します。
⑩重大な問題のレビュー
　　重大な問題のクローズ後は、その都度、活動内容のレビューを実施して将来の活動に役立てます。
　　重大な問題のレビューでは、次のことを確認します。
　　・正しく行われたこと
　　・間違って行われたこと
　　・将来的に向上できる点
　　・再発を防ぐ方法
　　・サードパーティの責任の有無、フォローアップが必要かどうか

【アプリケーション管理】
アプリケーション管理は、サービスオペレーションの機能の1つであり、アプリケーションのライフサイクルを通した管理が責務です。

アプリケーションのライフサイクルは、要件、設計、構築、展開、運用、最適化を含む、継続的なライフサイクル全体が対象です。
アプリケーション管理は、アプリケーションに関する専門的な技術力やリソースを提供し、ITサービスマネジメントの活動を支援します。アプリケーション管理機能は、運用中のアプリケーションの管理とサポートを担当する部門、グループ、チームによって実施されます。

アプリケーション管理は以下の活動によって、アプリケーションの設計と展開、継続的なサポートと改善を支援します。

・アプリケーションの設計: 対障害弾力性(障害に耐えるか、障害時に早く復旧できる能力)と費用対効果の高いアプリケーションの設計
・機能の提供: 要求された事業成果を達成するために必要な機能を利用できるようにする
・アプリケーションの保守: アプリケーションを最適な状態に維持するための技術力の提供
・サポート: 発生した技術的な障害を迅速に診断し解決するための技術力の提供

アプリケーション管理の活動は、購入されたものや社内で開発されたものなどを問わず、すべてのアプリケーションに対して実施されます。
また、サービスデザイン段階において、要求された機能をサポートするアプリケーションを購入するべきか、それとも新たに構築するべきかの決定も支援します。

【アプリケーション管理の組織】
アプリケーションを管理する活動は汎用的ですが、アプリケーションのカテゴリによって、具体的な活動の実施方法は異なります。そのため、アプリケーション管理のチーム、部門は、アプリケーションのカテゴリごとに分けられる傾向があります。カテゴリの例としては、財務アプリケーション、人事アプリケーション、メッセージング・アプリケーション、事業固有のアプリケーション(医療、保険、金融など)などが挙げられます。

【アプリケーション開発】
アプリケーション開発は、アプリケーションの要件、設計、構築のための1回限りの活動であり、多くの場合、アプリケーション管理のチームとは異なるチームとして機能します。