次の方法で共有

IO 機能 : ITIL/COBIT ベースの管理プロセス - 基本インフラストラクチャから標準化インフラストラクチャへの移行

  • [アーティクル]
このページのトピック

はじめに はじめに
要件 : サポートと変更の管理プロセス 要件 : サポートと変更の管理プロセス
チェックポイント : サポートと変更の管理プロセス チェックポイント : サポートと変更の管理プロセス

はじめに

最高の利益とパフォーマンスを実現するためには、インフラストラクチャ最適化モデルで説明しているすべてのタスクでベスト プラクティス プロセスを定義する必要があります。次の表に、ITIL/COBIT ベースの管理プロセスで標準化レベルに移行する際の、高レベルな課題、適用可能なソリューション、および利点を示します。

課題

ソリューション

利点

ビジネス上の課題

システムが複雑で互換性がなく、コストが高くなっており、組織全体で提供するサービスも限られている

IT の課題

使用中の IT ポリシーおよび自動化プロセスが少ない

ハードウェアとソフトウェアの構成が複数存在する

サポート、インシデント、および問題に対する管理手順が事後対応型である

資産のライフサイクル管理の戦略がない

変更またはリリースの管理プロセスがない

プロジェクト

自己評価ツールを使用して現在の運用フレームワークを評価する

リリース準備プラクティスで変更の準備状況を検証する

インシデントおよび問題の管理手順を定義する

包括的なヘルプ デスク戦略を開発して実装する

ビジネス上の利点

エンド ユーザーには、既知のサービス レベル契約と問題解決のための連絡先が通知され、従業員の生産性が改善される

既知の繰り返し可能なプロセスにより変更の実装がさらに簡単になる

IT の利点

IT 担当者とビジネス組織によって IT の運用が文書化され、運用について理解が深まる

簡単な構成管理により IT の運用効率と将来の展開アクティビティが改善される

最適化の標準化レベルでは、インシデント管理、問題管理、ユーザー サポート、構成管理、および変更管理のための定義済みの手順が、組織に準備されている必要があります。

要件 : サポートと変更の管理プロセス

対象読者

問題、インシデント、サービス、構成、および変更を管理するプロセスがない場合、このセクションをお読みください。

概要

インフラストラクチャの最適化は、製品やテクノロジよりも重要です。組織の IT サービスの成熟度の大部分は、社員とプロセスによって決まります。数多くの標準とベスト プラクティスを実践する組織が、IT サービス管理における社員とプロセスの領域に取り組んでいます。MOF (Microsoft® Operations Framework) では、ITIL (IT Infrastructure Library) および COBIT (Control Objectives for Information and related Technology) 標準に含まれる多くの知識が採用されており、Microsoft ユーザーがそうした知識をすぐに利用できるようになっています。

第 1 段階 : 査定

運用管理の査定段階での目標は、組織の現在の能力と課題を評価することです。Microsoft では、運用査定プロセスをサポートできるように、MOF (Microsoft Operations Framework) の継続的な改善ロードマップの一環として MOF サービス管理評価 (SMA) とそのオンライン簡易版である MOF 自己評価ツールを開発しました。

image011.jpg

MOF サービス管理評価では、社員と IT サービスの管理プロセスのパフォーマンス強化、およびビジネス価値を向上させるテクノロジの利用に重点が置かれています。サービス管理評価の結果生成されたすべての推奨事項の詳細が示され、ビジネス価値が裏付けされます。また、改善が実装されるに従って進捗状況を監視する、特定の主要業績評価指標によってサポートされた詳細なサービス改善ロードマップが提供されます。

第 2 段階 : 識別

MOF サービス管理評価の結果が、識別段階の基盤になります。通常、評価を行うことにより、IT 運用におけるいくつかの改善の余地がある領域が明らかになります。識別段階では、これらの結果を考慮して、ビジネス ニーズに基づいて改善プロジェクトに優先度を設定します。この優先度設定をサポートできるように、MOF の継続的な改善ロードマップにはツールと参考資料が含まれています。

第 3 段階 : 評価と計画

運用改善の評価と計画段階は、改善の余地があることが明らかになり、優先度が設定された領域に基づきます。MOF サービス改善プログラム (SIP) ガイダンスにより、この段階を実行することができます。SIP は、 特定の MOF/ITIL プロセス改善とサービス改善ガイダンスの 2 の大きな領域で構成されています。このガイダンスは、ユーザーが特定の問題点を識別するのを支援するツールによって提供され、修正のガイダンスを提供し、プロセス改善を測定するために主要業績評価指標によってサポートされています。   

標準化レベルに移行するための推奨プロセス

このセクションに記載された推奨事項は、基本レベルで一般的に見られる問題点、および標準化レベルで求められる改善領域に基づいています。これらは推奨事項であり、組織や業界によっては当てはまらないことがあります。

基本レベルでは、問題の管理または要求に対するサービスの提供で多くの時間が費やされます。IT サービスの管理が標準化レベルに移行するにつれて、問題と要求には優先度が設定され、ツールによる管理がますます増えていきます。ポリシーで定められていない場合でも、許容できるサービス レベルが維持されて通知されているので、ユーザーは IT サービスについて問い合わせるべき相手を知っています。さらにチームの役割、責任、および運用上の所有権の領域が定義されます。

標準化レベルでは、IT の運用とインフラストラクチャの管理および監視のために、ツールがますます利用されるようになります。同様に、変更管理、構成管理、およびリリース管理のプロセスは、標準化されて予測性が高まります。特に、実装前の確認テストと安定化の優先度は高くなります。また標準化レベルでは、プロジェクト管理能力が高まりますが、複数ある同時進行プロジェクトと構想の統合を改善する機会もあります。

Microsoft では、IT 運用の定義と改善を行うための反復モデルとして MOF (Microsoft Operations Framework) を提供しています。MOF は、IT 組織内の論理的な運用機能としてサービス管理機能 (SMF) を定義します。SMF は、 変更、運用、サポート、最適化という 4 つの大きな領域に分けられます。このガイドでは、最適化の基本レベルにある組織で一般的に見られる、次のような改善領域に焦点を当てます。

  • インシデント管理

  • 問題管理

  • エンドユーザー サポート サービスの改善

  • サービス定義と構成管理

  • 変更管理のベスト プラクティスの実装

組織によって、これらの管理機能を改善することで運用上の効率と改善に大幅に影響する場合もあれば、それほどでもない場合もあります。組織は少なくともオンライン自己評価を実施し、可能であれば完全なサービス管理評価を実施して、プロセスまたはサービスの改善を必要とする最重要の領域を特定することをお勧めします。

インシデント管理

インシデント管理は、最初にインシデントを検出し、次に可能な限り迅速にインシデントを解決する適切なサポートを見つけられるようにする重要なプロセスです。

インシデント管理の主な目標は、できる限り迅速に正常なサービス運用を復旧して、業務に及ぼす悪影響を最小限に抑えることにより、サービス品質のレベルと可用性を最良の状態に保つことです。正常なサービス運用とは、サービス レベル契約 (SLA) の限度内でのサービス運用のことです。

インシデント管理の目標は次のとおりです。

  • 通常のサービスをできる限り迅速に復旧する。

  • 業務に対するインシデントの影響を最小限に抑える。

  • インシデントとサービスの要求は一貫して確実に処理され、見落としがないようにする。

  • 最もサポートが必要な領域にサポート リソースを割り当てる。

  • サポート プロセスの最適化、インシデント数の削減、管理計画の実行に役立つ情報を提供する。

次のセクションでは、インシデント管理の主要なプロセスを説明します。

第 4 段階 : 展開 (インシデント管理)

検出、セルフサービス、および記録

検出プロセスでは、サービス デスクに問い合わせたユーザーが報告する情報、またはイベント管理システムの警告で通知されたインシデントなど、さまざまな媒体でインシデントが記録されます。

エンド ユーザーは、セルフサービス機能にアクセスして自分のインシデントを報告したり、既存のインシデントの解決状況を確認したり、セルフヘルプ情報を表示したりすることができます。

ライフ サイクルを通じてインシデントの追跡、監視、および更新ができるように、すべてのインシデントは記録する必要があります。この情報は、問題管理、レポート作成、プロセスの最適化、および計画の目的で利用できます。

サービス要求の処理

このプロセスでは、サービス要求の処理を定義します。さまざまな種類のサービス要求は、異なる方法で処理する必要があります。サービス デスクが特定の要求を処理できる場合もありますが、変更管理など、要求によっては、別のチームに割り振って処理してもらう必要がある場合もあります。

分類と初期サポート

分類プロセスでは、優先度を割り当てることでインシデントを分類します。

初期サポート プロセスは、インシデントに最初の解決策を提供します。この場合、既知のエラー、既存の問題、および以前のインシデントと照合して、文書化された解決策を見つけます。

調査と診断

このプロセスでは、インシデントの調査と診断データの収集を行って、インシデントを最速で解決できる方法を特定します。SLA の目標達成に必要な場合、このプロセスには、上位の管理者や技術的な専門家に解決を委ねる機能的エスカレーションも含まれています。

重大インシデントの対応手順

重大インシデントの対応手順では、通常のインシデント プロセスでは対応しきれない重大なインシデントに取り組みます。このようなインシデントでは、運用の維持能力や、業務を効果的に推進する能力に重大な影響が及ぶ可能性があります。これらのインシデントは通常のインシデントと同じライフ サイクルを辿りますが、重大なインシデントの対応手順では、優先度の高いイベントに必要とされる、より多くの調整、エスカレーション、コミュニケーション、リソースを提供します。

解決と復旧

解決と復旧プロセスでは、インシデントの解決に必要な手順を行います。これは、多くの場合、変更管理プロセスと整合させて是正措置を実施することによって行います。是正措置を実施した後、解決の状況が検証されます。

障害のあるハード ディスクの交換など、インシデントの解決方法を実行した後、データの復元やサービスの再起動など、状況によっては復旧作業を行う必要があります。

問題のクローズ

このプロセスでは、インシデントが解決されて顧客が満足したことを確認してから、インシデント レコードをクローズします。

問題管理

インシデント管理プロセスと同時に問題管理プロセスを実装することで、組織は重大なインシデントまたは繰り返し起こるインシデントの根本原因を特定して解決し、再発の可能性を減らすことができます。

問題管理の目標は次のとおりです。

  • インフラストラクチャとサービスに影響を及ぼす問題を特定し、所有権を取得する。

  • インシデントと問題の影響を軽減する手順を実行する。

  • 問題の根本原因を特定し、特定した問題に対して回避策または持続的な解決策を確立するために行動を開始する。

  • 記録した問題とインシデント データを利用して、傾向分析を実行し、将来の問題を予測し、問題管理アクティビティに対して優先度の設定を可能にする。

次のセクションでは、問題管理の主要なプロセスを説明します。

第 4 段階 : 展開 (問題管理)

問題の記録と分類

このプロセスでは、初期段階での問題の検出と、問題の記録を行います。問題は、インシデント管理プロセスで報告されたり、問題管理チームが収集したデータを分析して検出されたりする場合があります。問題を既存のインシデントに関連付け、問題解決の優先度設定に利用できるように問題を記録する必要があります。問題を記録した後、ビジネスに対する影響を評価して、解決の緊急性を判断します。この評価により、問題の分類が決定されます。

問題の調査と診断

このプロセスでは、問題を調査して根本原因を診断します。このデータは、問題管理チームが問題の原因を解決するために必要なリソースとスキルを評価するために利用できます。このプロセスでは、その他の計画、調整、リソース、およびコミュニケーションを必要とする主要な問題に取り組みます。その結果に、開始すべき正式なプロジェクトが確立される場合もあります。

エラー制御

エラー制御プロセスでは、既知のエラーを適切に修正します。目標は、IT コンポーネントまたは手順を変更して、IT インフラストラクチャに影響を及ぼす既知のエラーを取り除き、インシデントの再発を防止することです。

問題のクローズ

問題のクローズ プロセスでは、すべてのエラーの詳細を完全に記録することの必要性を概説します。すべての問題に関して、構成項目 (CI)、兆候、解決策、または回避方法のデータを保存することが重要です。この作業により、組織の知識ベースが構築されます。

変更を実装してエラーを正常に解決した後、関連するインシデント レコードや問題レコードと共に、エラー レコードをクローズすることができます。その後、実装後のレビュー (PIR) によって、解決策の有効性を確認できます。

エンドユーザー サポート サービスの改善

サポート サービスまたはサービス デスクが、組織における最初の連絡先になります。顧客の問題や懸念事項に効率的かつ効果的に対応すると、会社に対する評価を大いに高めることができます。

サービス デスクの目標は、組織の規模、サービス デスクの機能に対して設定された対応範囲など、いくつかの要素で変わってきます。

サービスの目標は次のとおりです。

  • ユーザーと IT 部門を結ぶ連絡先として集中的な 1 つの窓口を提供する。

  • ユーザーに対して、その他のサービス管理機能への橋渡し役として機能する。

  • ビジネスの目標達成に必要とされる高品質のサポートを提供する。

  • IT サービスの総保有コスト (TCO) を特定して削減する。

  • ビジネス、テクノロジ、およびプロセスの境界を超えて変更をサポートする。

  • 顧客満足度を向上させる。

  • すべての顧客を自社につなぎ止める。

  • その他のビジネス チャンスを特定する。

サービス デスク機能の主要なプロセスは、次のセクションで説明します。

第 4 段階 : 展開 (サービス デスク)

インシデントの記録とサービス提供

インシデントとは、サービスの標準的な運用から逸脱している 1 回の発生イベントです。インシデントでは、サービスの通常の運用が妨げられたり、サービスの品質が低下したりする可能性があります。

この場合、サービス デスクの機能は、影響を受けるユーザーのために、できる限り迅速にサービスの復旧を支援することです。

サービス要求の管理

サービス要求は、次の例のいずれかに当てはまります。

  • 変更の要求

  • 情報の要求 (つまり、クエリ)

  • 必要に応じたジョブの要求

  • 調達の要求

  • ユーザーと IT 部門の間のコミュニケーション (たとえば、苦情、賛辞、コメント、または提案)

サービス要求の場合、サービス デスクの機能は、要求を直接的に満たすか、適切な解決グループに要求を割り当てることで、ユーザーが満足する要求への対応を確実に提供することです。

サービス定義と構成管理

IT インフラストラクチャを効果的に管理するための重要な原則は、各コンポーネントと、コンポーネント間の関係について文書化することです。構成管理は、変更管理、SLA の交渉、IT 処理能力の評価、その他の重要なプロセスでの意思決定のために基盤を提供します。

構成管理は、全バージョンのハードウェア、ソフトウェア、ドキュメント、プロセス、手順、IT 組織にあるその他のコンポーネントを対象として、識別、制御、追跡を行う重要なプロセスです。構成管理の目標は、構成項目 (CI) と呼ばれる承認されたコンポーネントのみを IT 環境で使用し、CI に対するすべての変更を記録して、コンポーネントのライフ サイクルを通じてこの CI を追跡することです。構成管理プロセスには、次のような目的があります。

  • 各構成項目と構成項目間の関係を特定して、これらを構成管理データベース (CMDB) に追加する。

  • その他の機能のために CMDB と CI にアクセスできるようにする。

  • リリース管理プロセス中に、IT コンポーネントの変更に続いて CI の更新と変更を実行する。

  • CMDB が正確に運用 IT 環境を反映していることを確認するレビュー プロセスを確立する。

次のセクションでは、構成管理の目標を説明します。

第 4 段階 : 展開 (構成管理)

構成項目 (CI) の確立

CMDB を設計するとき、各 CI の適切な詳細レベルを決定する必要があります。次に組織の各 CI を CMDB に追加できます。

資産管理に加えて、構成管理によってもたらされる主要な利点は、IT コンポーネント間の関係をモデル化できることです。たとえば、ワークステーションはデスクトップ コンピュータ、オペレーティング システム、アプリケーションで構成されており、ワークステーションはネットワークに接続してネットワークを使用します。IT コンポーネント間の関係を適切に理解して、文書化すると、提案された変更に対して詳細な影響分析を行うことができます。

構成項目へのアクセス

IT コンポーネントとその関係に関する情報を CMDB に追加すると、この情報は他の SMF で利用できるようになります。たとえば、変更管理では、CMDB 内で定義された関係を使用して、IT 環境内の他のコンポーネントに対する変更の影響を判断します。

構成項目の変更

リリース管理で IT コンポーネントの変更を開始するときは、対応する変更を CMDB にも加える必要があります。正確な最新情報がないと、構成管理の価値は失われます。このプロセスは、可能な場合は常に自動的に実行する必要があります。情報の量が多く、変更の頻度も高いため、最小規模の組織は別として、ほとんどの組織にとって、手動のデータ入力は非現実的な作業になります。

構成項目のレビュー

その他のサービス管理機能と同様に、変更管理とインシデント管理 SMF を成功させるには、CMDB に格納される情報が正確であることが重要です。データベースが運用 IT 環境を正確に反映していることを確認するレビュー プロセスを確立する必要があります。

変更管理のベスト プラクティスの実装

変更管理では、インフラストラクチャの変更の開始、変更による潜在的な影響の評価とその文書化、変更実装の承認、変更展開のスケジュール設定とレビューなどを行う、整合性の高い一連のプロセスを記述します。

変更管理の目標は、継続的な運用の中断を最小限に抑えて、IT 環境に必要な変更を加える統制されたプロセスを提供することです。この目標を達成するために、変更管理プロセスには次のような目的があります。

  • 変更要求 (RFC) を提出して変更を正式に開始する。

  • 緊急度、およびインフラストラクチャまたはユーザーに対する影響を評価した後、変更に優先度およびカテゴリを割り当てる。

  • 意思決定者が変更を承認または拒否できるように、RFC を渡す効率的なプロセスを確立する。

  • 変更の展開を計画する。

  • リリース管理を行って、運用環境へのリリースと変更の展開を管理する。MOF リリース管理 SMF の詳細については、https://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfrelmg.mspx を参照してください。

  • 実装後のレビューを実行することで、変更によって目標が達成されたかどうかを確認し、変更をそのまま適用しておくか、変更を元に戻すかを判断する。

次のセクションでは、構成管理の目標を説明します。

第 4 段階 : 展開 (変更管理)

変更要求の処理

一般的に、ビジネス環境におけるどの人員でも、変更を要求することができます。要求することで、その人は変更イニシエータになります。変更イニシエータになる可能性がある人員は多く、変更の手順についての理解度もそれぞれ異なるため、一貫した品質と完全性を備えた変更要求を作成して、不適切な要求を破棄するプロセスが必要です。

受け付けられた変更要求への変更の分類の割り当て

この段階では、要求はまだ承認されていませんが、変更要求は最初のスクリーニングを通過したことになります。次の要件は、変更に優先度を設定して、カテゴリに分類することです。優先度の設定と分類は変更の開始者が入力しますが、変更マネージャまたは任命された担当者には、変更要求をレビューして、必要に応じてこれらの設定を変更する権限があります。

変更の承認

変更マネージャが変更に適切な優先度を設定してカテゴリに分類した後、変更は承認を受ける必要があります。

変更の開発

優先度とカテゴリに基づく適切なパスで RFC が承認されると、変更要求は変更開発段階に移されます。この段階では、変更の計画、変更を反映する成果物の開発 (たとえば、新しいコードの開発または新しいハードウェアの構成など)、運用環境に変更を展開するためのリリース管理プロセスへの移行など、必要な手順を実行します。

変更のレビュー

運用環境に正常にリリースおよび展開を行った後、または標準的な変更の場合は、運用環境に展開した後、変更が目的どおりの効果を発揮したかどうか、もともとの変更要求が求めていた要件が満たされたかどうかを確認するために、レビュー プロセスを実行する必要があります。

推奨される参考情報

MOF のサポート象限

MOF の変更象限

チェックポイント : サポートと変更の管理プロセス

Tick

要件

 

インシデント管理の方法を実装した。

 

問題管理の方法を実装した。

 

エンドユーザー サポート サービスを向上した。

 

サービス定義と構成管理を実装した。

 

変更管理のベスト プラクティスを実装した。

上記の手順を完了すると、ITIL/COBIT ベース管理プロセス機能のサポートと変更の管理プロセスについて、インフラストラクチャ最適化モデルの標準化レベルに達するための最低限の要件が満たされたことになります。

Microsoft Operations Framework のサポート象限および変更象限に関するその他のベスト プラクティスに従い、MOF、ITIL、COBIT の概念に関する知識ベースを構築することをお勧めします。