サービスデザイン
サービスデザインは、サービス・ライフサイクルの段階の1つであり、ITサービス・プロバイダの戦略を実現し、サポートする環境へサービスを円滑に導入するために、ITサービスやプロセスを設計します。サービス戦略を、事業達成目標を実現するための計画に変換する段階です。
サービスデザインの達成目標は、サービス・ライフサイクルにおいて必要となる改善が最小限になるように、ITサービスを効果的に設計することです。例えば家を新築する場合、最初に間取りや建材、完成までのスケジュールなど多くの内容を決める必要があります。顧客がはじめてサービスの価値を認識できるのはサービスオペレーション(運用)の段階に入ってからですが、設計の段階を過ぎると、修正にかかるコストは大きくなる傾向があります。後で手直しが発生しないように、設計の段階であらゆる観点からサービスを考慮することが重要です。また、ソリューションや設計がより効果的になるように、そして事業のニーズの変化に対応するために、サービスデザインのすべての活動に継続的な改善を組み込んでおくべきです。
サービスデザイン段階で優れた設計を行うことで、総所有コスト(TCO: Total Cost of Ownership、システムを導入・維持・管理するのにかかる費用の総額)の削減、サービス品質の改善につながり、良質で費用対効果の優れたITサービスを提供できるようになります。
【サービスデザイン・パッケージ】
ITサービスとその要件のすべての側面について、ライフサイクルの各段階を通して定義する文書を、サービスデザイン・パッケージ(SDP)といいます。サービスデザイン・パッケージは、サービスの設計により作成される成果物で、事業要件や設計、移行の計画などが含まれます。
サービスデザイン・パッケージは次のものに対して作成され、サービストランジションに渡されます。
・新規のITサービス
・ITサービスへの重大な変更
・ITサービスの廃止
・サービスデザイン・パッケージそのものへの変更
【サービスデザインの5つの側面】
サービスデザインではサービスの設計だけではなく、サービスの導入、運用に必要な内容もあわせて設計することで、サービスデザインの後の段階で発生する問題を最小限に抑えられるようになります。
サービスデザインで設計すべき対象として、次の5つの側面があります。
・新規または変更されるサービスに対するサービス・ソリューション
事業部門と合意した要件に基づいてサービスを設計します。
・管理情報システムとツール(特にサービス・ポートフォリオ)
サービス・ポートフォリオやシステム管理ツールなど、サービスマネジメントを支援する仕組みやツールを設計します。新規や変更されるサービスが、既存の仕組みやツールで一貫性を保って管理できるかを確認します。
・技術アーキテクチャと管理アーキテクチャ
技術アーキテクチャは、ITインフラストラクチャやアプリケーション、データなどのアーキテクチャを設計します。
管理アーキテクチャは、ITやサービスを管理するツールの利用方法や自動化の実現方法を設計します。
・必要なプロセス
プロセスの活動内容や、役割、責任、スキルなどを設計します。
・測定方法と測定基準
ITサービスの品質やプロセスを管理、評価するために、測定方法と測定基準を設計します。
【4つのP】
サービスデザインでは前述した5つの側面を設計するとともに、人(People)、プロセス(Process)、製品(Products)、パートナ(Partners)の4つの要素をバランスよく組み合わせて準備し、設計していくことが重要です。
これらの要素は、それぞれの頭文字のPから「4つのP」と呼ばれます。
人(People)：スタッフの能力やスキル
プロセス(Process)
製品(Products)
パートナ(Partners)
【サービスデザインのプロセス】
サービスデザインの主なプロセスは以下のとおりです。
これらのプロセスはサービスデザインに関連付けられていますが、ほとんどのプロセスにはサービス・ライフサイクルの複数の段階にわたって行われる活動があります。
■デザインコーディネーション
デザイン・コーディネーションは、サービスデザインのプロセスの1つであり、サービスデザインのすべての活動、プロセス、およびリソースの調整を責務とします。
デザイン・コーディネーションの目的は、サービスデザインのすべての活動とプロセスに対し、調整とコントロールの単一ポイントを提供することによって、サービスデザインの目標を確実に実現することです。
デザイン・コーディネーション・プロセスは、サービスデザインで行うすべての活動、プロセス、スケジュールやリソースなどを調整し、スムーズに設計を進められるようにします。また、サービスデザインでの活動の結果についても責任を持ちます。
【デザイン・コーディネーションの活動】
デザイン・コーディネーションの活動には、サービスデザイン段階の全体の設計活動を調整する活動と、個々の設計活動を調整する活動の2種類があります。
[全体の設計活動]
すべての設計が最も効果的で効率的な方法で進められるようにするには、すべての設計活動の監督が必要となります。
サービスデザイン段階の全体の設計活動の調整には、次の①～⑤の活動が含まれ、これらの活動はデザイン・コーディネーション・プロセスのプロセス・マネージャによって行われます。
①方針と手法の定義および維持
②設計におけるリソースと能力の計画
③設計活動の調整
④設計のリスクと課題の管理
⑤サービスデザインの改善
[個々の設計活動]
個々のプロジェクトや変更に関する設計活動の調整には、次の①～④の活動が含まれます。これらの活動は、プロジェクト・マネージャか、プロジェクトまたは変更に責任を持つ人が、デザイン・コーディネーション・プロセスのプロセス・マネージャの支援と手引きにより実施します。
①個々の設計の計画
②個々の設計の調整
③個々の設計のモニタ
④設計のレビューとサービスデザイン・パッケージ(SDP)の確実な引き継ぎ
※サービスデザイン・パッケージは、ITサービスとその要件のすべての側面について、ライフサイクルの各段階を通して定義する文書です。
■サービス・カタログ管理
■サービスレベル管理
サービスレベル管理(SLM: Service Level Management)は、サービスデザインのプロセスの1つであり、達成可能なサービスレベル・アグリーメントの交渉と、そのサービスレベルが満たされているようにすることを責務とします。
「サービスレベル・アグリーメント(SLA: Service Level Agreement)」とは、ITサービス・プロバイダと顧客との間で交わされる合意です。サービスレベル・アグリーメントでは、ITサービスについて記述し、サービスレベル目標値を文書化して、ITサービス・プロバイダおよび顧客の責任を規定します。
現在および計画中のすべてのITサービスが、合意された達成可能な目標値を満たすように提供されることが、サービスレベル管理の目的です。そのためにサービスレベル管理は、具体的で測定可能な目標値を設定し、サービスレベルをモニタ、測定、報告、レビュー、是正します。また、ITサービスに対する顧客満足度もモニタし、改善します。
【サービスレベル要件(SLR: Service Level Requirement)】
サービスレベル要件(SLR)は、ITサービスのある面に対する顧客の要件です。顧客からビジネスに必要なIT要件をヒアリングし、ITサービスの業務要件を文書にまとめます。
サービスレベル要件は事業達成目標に基づいており、顧客とのサービスレベル目標値の交渉に利用されます。
【SLA体系の設計】
サービスレベル管理は、組織のニーズに最も適した方法で、すべてのサービスとすべての顧客を網羅できるように、最も適したSLA体系を設計しなければなりません。
SLA体系の設計方法には「サービスベースのSLA」「顧客ベースのSLA」「マルチレベルSLA」の3つがあります。
[サービスベースのSLA]
サービスベースのSLAは、単一のサービスを規定し、そのサービスを利用するすべての顧客を対象とするSLAです。1つのITサービスとそれを利用する複数の顧客に対して、1つのSLAを規定し、合意します。
[顧客ベースのSLA]
顧客ベースのSLAは、特定の顧客グループと、その顧客が利用するすべてのサービスを対象とするSLAです。特定の顧客とその顧客に提供している複数のITサービスに対して、1つのSLAを規定し、合意します。
[マルチレベルSLA]
マルチレベルSLAは、階層構造でSLAを管理します。例えば、企業レベル→顧客レベル→サービスレベルのように3層構造をとり、上位レベルの内容は下位レベルに引き継がれるようにします。こうすることで、SLAを扱いやすいサイズに維持できるようになり、不必要な重複や頻繁な更新を回避できます。
・企業レベル
どの顧客に対しても適切な一般的な内容をSLAとして規定します。これらの内容はそれほど流動的ではないため、頻繁に更新は要求されません。
・顧客レベル
顧客レベルでは企業レベルのSLAを引き継ぎ、顧客が利用するサービスに関係なく、特定の顧客グループまたは事業部門に対してのSLAを規定します。
・サービスレベル
サービスレベルでは顧客レベルのSLAを引き継ぎ、特定の顧客に提供している特定のITサービスに対してSLAを規定します。
ITサービス・プロバイダが顧客の期待するサービスを提供するためには、顧客との間にSLAを締結するだけではなく、通常、関連する他の組織やサプライヤとの間にもSLAの目標達成を確実にするための合意文書を作成します。これらは、「オペレーショナルレベル・アグリーメント」と「外部委託契約」です。
【オペレーショナルレベル・アグリーメント(OLA: Operational Level Agreement)】
オペレーショナルレベル・アグリーメント(OLA)は、ITサービス・プロバイダと、同じ組織内の別の部署との間で交わされる合意です。オペレーショナルレベル・アグリーメントは、ITサービス提供を支援し、提供する商品やサービス、両当事者の責任を定義します。
例えば、合意された期間内にハードウェアを入手するための、ITサービス・プロバイダと調達部門とのOLAなどがあります。
【外部委託契約(UC: Underpinning Contract)】
外部委託契約(UC)は、ITサービス・プロバイダとサードパーティ(外部サプライヤ)との間で交わされる契約です。外部委託契約では、1つ以上のSLAに記載された合意済みサービスレベル目標値を満たすために必要な目標値および責任を定義します。
サプライヤとの契約に関しては、サプライヤ管理プロセス(この章の後半で解説します)が最終的な説明責任者ですが、サービスレベル管理プロセスにもSLAの目標達成を支えるための契約を監督する責任があります。
外部委託契約は法的な拘束力がある「契約」です。法的拘束力がない文書は「合意」と呼ばれます。
SLAに関しては、ITサービス・プロバイダがタイプⅠかタイプⅡの場合(内部サービス・プロバイダ)は、SLAは内部文書のため法的拘束力を持たないことが多いです。ITサービス・プロバイダがタイプⅢ(外部サービス・プロバイダ)の場合は、法的拘束力のある「契約」の一部にスケジュールや仕様としてSLAが含まれる可能性が高くなります。
【サービス・レビュー】
サービス・レビューとは、先期のサービスの達成度をレビューし、翌期の課題を前もって確認するために、ITサービス・プロバイダが顧客と定期的に開催するミーティングです。サービス・レビューは毎月、または四半期に一度は開催します。
目標値を達成できていない部分は、改善するための処置を顧客およびITサービス・プロバイダに割り当てます。処置内容はすべて記録し、次回のミーティングで進捗状況をレビューしフォローアップすることで、確実に実施されるようにします。
【SLAMチャート(Service Level Agreement Monitoringチャート)】
サービスレベル・アグリーメント・モニタリング・チャート(SLAMチャート)は、サービスレベル目標値に照らし合わせた達成度(どの程度達成できたか)のモニタリングと報告を支援するために使用される有益な技法です。
SLAMチャートでは通常、過去12ヶ月間の各月ごとに、合意済みのサービスレベル目標値を違反したものを赤(Red)、違反しそうなものを黄(Amber)、達成したものを緑(Green)で色分けして表し、一目で概要を把握できます。それぞれの色の頭文字をとって「RAGチャート」とも呼ばれます。
【サービスレベル・マネージャ】
サービスレベル・マネージャは、サービスレベル管理のプロセス・マネージャです。SLAとOLAを文書化する責任を持ち、SLAが満たされるようにします。
サービスレベル・マネージャは常に顧客のニーズを理解し情報を収集するなど、顧客向けの活動を行います。その点において、分野「サービスストラテジ」でも述べたように、サービスレベル管理プロセスは事業関係管理と強いつながりを持ちます。事業関係マネージャはサービスレベル・マネージャの役割も兼務することが多いです。
ITサービスを利用している顧客へのITサービスの説明責任は、SLAを合意したサービスレベル・マネージャが負います。IT担当役員やサービスマネジメント役員に対して、担当する特定のITサービスの提供について説明責任を負うのはサービス・オーナです。
【サービス改善計画(SIP: Service Improvement Plan)】
サービス改善計画(SIP)とは、プロセスまたはITサービスに対する改善を実施するための正式な計画のことです。SLAを守れない(違反した)状況が発生した場合には、サービス改善計画を推進し改善していきます。
サービスレベル管理プロセスは「継続的サービス改善」段階のサービス改善計画にトリガを提供するプロセスの1つです。
■可用性管理
可用性管理は、サービスデザインのプロセスの1つであり、現在および将来の、ITサービスの可用性に関する事業のニーズを高い費用対効果でタイムリーに満たすことを責務とします。
「可用性」とは、サービスなどが、必要とされたときに合意済みの機能を実行する能力です。
可用性管理は、ITサービスの可用性のすべての側面を定義、分析、計画、測定、改善し、すべてのITインフラストラクチャ、プロセス、ツール、役割などが、可用性に関する合意済みサービスレベル目標値を満たすようにします。
事業に必要とされるレベルの可用性でサービスが提供されなければ、顧客はサービスの価値を感じることができません。可用性管理はサービスの保証の最も重要な部分の1つです。可用性管理はサービス・ライフサイクル全体にわたる継続的なプロセスであり、対象のITサービスが使用停止または廃止されたときにのみ終了します。
可用性管理には、次の2つの重要な要素があります。
・リアクティブな活動
すべてのイベント、インシデント、問題のモニタリング、測定、分析、管理です。これらの活動は、主に運用上の役割の一環として行われます。
「イベント」は、ITサービスの管理にとって重要性のある状態のあらゆる変更です。
「インシデント」は、ITサービスの計画外の中断や品質低下です。
「問題」は、インシデントの根本原因です。
・プロアクティブな活動
可用性のプロアクティブ(先回りした)な計画立案、設計、改善です。これらの活動は、主に設計と計画立案の役割の一環として行われます。
また、可用性管理は相互に関連する「コンポーネント可用性」「サービス可用性」の2つのレベルで考えます。
[コンポーネント可用性]
サービスを構成するソフトウェアやハードウェアなどのコンポーネントの可用性です。
[サービス可用性]
サービスそのものの可用性です。これには、コンポーネント可用性がサービス可用性に及ぼすインパクトや潜在的なインパクトも含まれます。
「インパクト」とは、インシデント、問題、変更による、ビジネスに及ぼす影響の指標です。サービスレベルが受ける影響の程度に基づくことが多いです。
【可用性の側面】
可用性管理では、「可用性」「信頼性」「保守性」「サービス性」のモニタリング、測定、分析、報告を行います。
[可用性]
可用性とは、サービス、コンポーネント、構成アイテムが、必要とされたときに合意済みの機能を実行する能力です。「構成アイテム」とは、ITサービスを提供するために管理する必要がある、あらゆるコンポーネント、またはその他のサービス資産のことです。
可用性は以下の式で計算します。
可用性（％）＝（合意済みサービス時間 ‐ 停止時間 ）÷
合意済みサービス時間 × 100
例) 合意済みサービス時間: 3000時間、停止時間: 15時間の場合
(3000 - 15) ÷ 3000 × 100 = 99.5 (%)
[信頼性]
信頼性とは、サービス、コンポーネント、構成アイテムが、中断せずにどれだけ長く合意された機能を実行できるかを示す指標です。信頼性を向上させるには、個々のコンポーネントの信頼性を高めるか、ロード・バランシング(負荷分散)技術などでコンポーネントの冗長性を確保します。
信頼性は、平均サービス・インシデント間隔(MTBSI: Mean Time Between Service Incidents)、または平均故障間隔(MTBF: Mean Time Between Failures)として計算します。
MTBSIは、システムに障害が発生した時点から、次に障害が発生した時点までの平均時間です。
MTBSI（時間） = 使用可能な時間 ÷ 中断の回数
例) 使用可能な時間: 3000時間、中断の回数: 2回の場合
3000 ÷ 2 = 1500 (時間)
MTBFは、ITサービスまたは構成アイテムが、合意済みの機能を中断せずに実行できる平均時間です。故障間隔といわれます。
MTBF(時間) = (使用可能な時間 - 総停止時間) ÷ 中断の回数
例) 使用可能な時間: 3000時間、総停止時間: 15時間、中断の回数: 2回の場合
(3000 - 15) ÷ 2 = 1492.5 (時間)
[保守性]
保守性とは、障害の発生後、サービス、コンポーネント、構成アイテムをどの程度迅速かつ効果的に通常の稼働状態に戻せるかを表す指標です。
保守性は、平均サービス回復時間(MTRS: Mean Time to Restore Service)として計算します。
MTRS（時間）= 総停止時間 ÷ サービスの中断の回数
例) 総停止時間: 15時間、サービスの中断の回数: 2回の場合
15 ÷ 2 = 7.5 (時間)
MTBSI = MTBF + MTRS となります。
※ITILコア書籍では、信頼性の計算式の分母は「中断の回数」、保守性の分母は「サービスの中断の回数」と、異なる用語が記述されていますが、上記の式より「中断の回数」と「サービスの中断の回数」は同じ意味と考えられます。
[サービス性]
サービス性とは、サードパーティ・サプライヤがその契約条件を満たす能力です。サプライヤとの契約には、支援サービスまたはコンポーネントに関して合意したレベルの可用性、信頼性、保守性が記載されます。
【重要事業機能(VBF: Vital Business Function)】
重要事業機能(VBF)は、事業が成功を収めるために不可欠なビジネス・プロセスの一部です。ビジネス・プロセスとは事業が所有し、実施するプロセスで、多くのビジネス・プロセスはITサービスに依存しています。重要事業機能は、ITサービスを構成する、特に重要で不可欠な機能を指します。
例えば、現金自動預け払い機(ATM)の重要事業機能は「現金の出し入れ」です。一方、利用明細書を発行する機能は故障したとしてもそれほど大きな支障はなく、不可欠ではないと考えられます。一般的に事業機能が重要であればあるほど、サービス設計時に組み込むべき可用性のレベルは高くなるので、この違いを確認することは重要です。
重要事業機能は、可用性管理の他、事業継続性管理、ITサービス継続性管理に関する重要な考慮事項となります。
■キャパシティ管理
キャパシティ管理は、サービスデザインのプロセスの1つであり、現在および将来の、ITサービスとITインフラストラクチャのキャパシティおよびパフォーマンスに関する事業のニーズを、高い費用対効果でタイムリーに満たすことを責務とします。
「キャパシティ」とは受け入れる能力であり、ITサービス・プロバイダの立場から表現すると、ITサービスや構成アイテム(ITサービスを提供するために管理する必要があるコンポーネントやサービス資産)が提供できる最大量になります。
キャパシティ管理では、コストを抑えつつ事業のニーズを満たすのに十分なITサービスのキャパシティを提供できるように、次のようなバランスを取る活動を行います。
・必要なリソースとコストのバランス
・需要と供給のバランス
必要以上のキャパシティを提供して過剰投資とならないように、事業のITサービスの需要を把握し、将来の要件に対する予測を立てて必要な分だけ供給するようにします。
【キャパシティ計画】
キャパシティ計画は、ITサービスの提供に必要なリソースを管理するために使用される計画です。キャパシティ計画には、ITサービスとコンポーネントの現在の利用情報と、事業の需要を予測したさまざまなシナリオとキャパシティの開発計画が含まれます。キャパシティ計画で将来必要になるITリソースを予測し、投資を計画します。
【キャパシティ管理のサブプロセス】
キャパシティ管理プロセスには、「事業キャパシティ管理」「サービス・キャパシティ管理」「コンポーネント・キャパシティ管理」の3つのサブプロセスがあります。
[事業キャパシティ管理]
事業キャパシティ管理は、キャパシティ計画で使用する将来の事業要件の把握が責務です。将来の事業要件や事業計画をできるだけ早い段階で入手し、将来、必要になるキャパシティを適切な時期に計画、実装できるようにします。
例えば、来年度に営業スタッフを増員し新しい営業所をオープンする場合、他の2つのサブプロセスと連携して、現在のリソースの使用状況とパフォーマンスから来年度に必要となるキャパシティを予測して計画します。
[サービス・キャパシティ管理]
サービス・キャパシティ管理は、ITサービスのパフォーマンスとキャパシティを把握することが責務です。各ITサービスで使用されるリソースと、使用状況のパターンを収集、記録、分析してキャパシティ計画で使用します。
具体的には、SLA(ITサービス・プロバイダと顧客との間で交わされる合意)とSLR(ITサービスに対する顧客の要件)にサービス目標値として記述されているすべてのサービスのパフォーマンスを監視、測定し、収集したデータを記録、分析し、報告します。
[コンポーネント・キャパシティ管理]
コンポーネント・キャパシティ管理は、構成アイテムのキャパシティ、使用率、パフォーマンスを把握することが責務です。メモリ使用量や、CPU使用率など、ITインフラストラクチャを構成する各コンポーネントを監視し、データを収集、記録、分析してキャパシティ計画で使用します。
サービス目標値の違反のおそれがある状況を迅速に特定するために、管理ツールを導入してしきい値を設定するなど、先を見越した対応をすることが重要です。
各サブプロセスの活動は似ていますが、活動の焦点は次のように大きく異なります。
事業キャパシティ管理：現在と将来の事業要件
サービスキャパシティ管理：事業をサポートするITサービスの提供
コンポーネント・キャパシティ管理：ITサービスの提供を支えるITインフラ
■ITサービス継続性管理
ITサービス継続性管理は、サービスデザインのプロセスの1つであり、ITサービスに深刻な影響を与える可能性のあるリスクの管理が責務です。
ITサービス継続性管理は、合意された許容可能なレベルまでリスクを低減し、ITサービスの復旧を計画し準備することで、ITサービス・プロバイダが最小限の合意済みサービスレベルを常に、確実に提供できるようにします。
ITサービス継続性管理は、組織が「災害」と考える非常時に焦点を当て、リスク管理や復旧計画の策定、計画のテストなどの活動を行います。
【事業継続性管理(BCM: Business Continuity Management)】
事業継続性管理(BCM)とは、事業に深刻な影響を与える可能性のあるリスクの管理を責務とするビジネス・プロセス(事業が所有し、実施するプロセス)です。
ITサービス継続性管理がITサービスの継続性を対象としているのに対して、事業継続性管理は事業のすべてのサービスを対象としています。ITサービス継続性管理はBCMプロセスの一部であり、BCMプロセス全体を支援することがITサービス継続性管理の目的です。事業継続性管理はITサービス継続性管理の達成目標、適用範囲、要件を設定します。
【事業継続性計画(BCP: Business Continuity Plan)】
事業継続性計画(BCP)は、ビジネス・プロセスの中断後に、そのプロセスを回復するために必要なステップを定義した計画です。計画では、発動のトリガ、関与する人、コミュニケーションなども特定します。
「ITサービス継続性計画」は、 1つ以上のITサービスの復旧に必要なステップを定義する計画で、事業継続性計画の重要な部分を占めます。
【ビジネス・インパクト分析(BIA: Business Impact Analysis)】
ビジネス・インパクト分析(BIA)は、サービスが中断することでもたらすであろう事業へのインパクトを定量化することです。重要事業機能(VBF、事業が成功を収めるために不可欠なビジネス・プロセスの一部)とそれら機能間の依存関係を識別する、事業継続性管理の活動です。依存関係には、サプライヤ、人材、ビジネス・プロセス、IT サービスなどが含まれる場合があります。
ビジネス・インパクト分析によって、ITサービスごとの目標復旧時間、目標復旧時点、最小限のサービスレベル目標値などの、ITサービスの復旧要件が定義されます。
【リスク・アセスメント】
リスク・アセスメントとは、事業にとっての資産の価値を分析し、資産に対する脅威を識別して、それらの脅威に対する各資産の脆弱性を評価することです。リスク・アセスメントを実施することで、リスクに対応する手段やリスクの優先度を決定できます。リスク・アセスメントには、定量的(数値を表す)なものと定性的(性質、特性を表す)なものがあります。
リスク・アセスメントは、次の図のように「リスク管理」の最初のステップです。リスク管理は、リスクの識別、アセスメント、およびコントロールを責務とするプロセスです。リスク管理は他の多くの活動と関連しますが、特にITサービス継続性管理、情報セキュリティ管理、およびライフサイクルのサービストランジション段階と深く関連します。ITサービス継続性管理は、合意された許容可能なレベルまでリスクを低減し、ITサービスの復旧を計画し準備することで、ITサービス・プロバイダが最小限の合意済みサービスレベルを常に、確実に提供できるようにします。
ITサービス継続性管理は、組織が「災害」と考える非常時に焦点を当て、リスク管理や復旧計画の策定、計画のテストなどの活動を行います。
【事業継続性管理(BCM: Business Continuity Management)】
事業継続性管理(BCM)とは、事業に深刻な影響を与える可能性のあるリスクの管理を責務とするビジネス・プロセス(事業が所有し、実施するプロセス)です。
ITサービス継続性管理がITサービスの継続性を対象としているのに対して、事業継続性管理は事業のすべてのサービスを対象としています。ITサービス継続性管理はBCMプロセスの一部であり、BCMプロセス全体を支援することがITサービス継続性管理の目的です。事業継続性管理はITサービス継続性管理の達成目標、適用範囲、要件を設定します。
【事業継続性計画(BCP: Business Continuity Plan)】
事業継続性計画(BCP)は、ビジネス・プロセスの中断後に、そのプロセスを回復するために必要なステップを定義した計画です。計画では、発動のトリガ、関与する人、コミュニケーションなども特定します。
「ITサービス継続性計画」は、 1つ以上のITサービスの復旧に必要なステップを定義する計画で、事業継続性計画の重要な部分を占めます。
【ビジネス・インパクト分析(BIA: Business Impact Analysis)】
ビジネス・インパクト分析(BIA)は、サービスが中断することでもたらすであろう事業へのインパクトを定量化することです。重要事業機能(VBF、事業が成功を収めるために不可欠なビジネス・プロセスの一部)とそれら機能間の依存関係を識別する、事業継続性管理の活動です。依存関係には、サプライヤ、人材、ビジネス・プロセス、IT サービスなどが含まれる場合があります。
ビジネス・インパクト分析によって、ITサービスごとの目標復旧時間、目標復旧時点、最小限のサービスレベル目標値などの、ITサービスの復旧要件が定義されます。
【リスク・アセスメント】
リスク・アセスメントとは、事業にとっての資産の価値を分析し、資産に対する脅威を識別して、それらの脅威に対する各資産の脆弱性を評価することです。リスク・アセスメントを実施することで、リスクに対応する手段やリスクの優先度を決定できます。リスク・アセスメントには、定量的(数値を表す)なものと定性的(性質、特性を表す)なものがあります。
リスク・アセスメントは、次の図のように「リスク管理」の最初のステップです。リスク管理は、リスクの識別、アセスメント、およびコントロールを責務とするプロセスです。リスク管理は他の多くの活動と関連しますが、特にITサービス継続性管理、情報セキュリティ管理、およびライフサイクルのサービストランジション段階と深く関連します。
【復旧オプション】
ITサービスの中断に対応するための戦略として、以下のように、さまざまな復旧オプションがあります。
手作業のワークアラウンド ＩＴサービスを使用しない 手作業による一時的な対応
相互協定 非常時にリソースを共有する 適用できるケースは少ない
段階的復旧（コールド・スタンバイ） ハードウェアの設置から実施 復旧時間：4日以上
中間的復旧（ウォーム・スタンバイ） 場所とハードウェアを用意しておき、データバックアップ復旧 復旧時間：1～3日
高速復旧（ホット・スタンバイ） データでの冗長化 復旧時間：24時間以下
即時復旧（ホット・スタンバイ） 冗長化している 復旧時間：即時
【ITサービス継続性管理と可用性管理の違い】
ITサービス継続性管理と可用性管理は、障害に備えるという点において似ていますが、両者の違いは次のとおりです。
ITサービス継続性管理
ポイント：災害が発生した時に備える対策。
目的：災害発生時に迅速に復旧
手段：非常事態に備えた復旧計画
可用性管理
ポイント：日常の障害に備える対策
目的：合意された期間にわたってITサービスを提供し、可用性を高める
手段：対障害弾力性のあるシステム
■情報セキュルティ管理
■サプライヤ管理
サプライヤ管理は、サービスデザインのプロセスの1つであり、投資に見合う価値をサプライヤから取得すること、サプライヤとのすべての契約と合意が事業のニーズに対応すること、すべてのサプライヤが契約上の義務を果たすようにすることを責務とします。
ITサービスを提供するためには、ハードウェアやソフトウェア、ネットワーク機器などのさまざまなリソースが必要です。ITサービス・プロバイダのみですべてのリソースを調達するのは難しいため、「サプライヤ」と呼ばれる外部のメーカやサードパーティから必要なリソースを調達し、組み合わせてITサービスを提供します。
サプライヤ管理ではSLAで合意された目標値を達成できるように、サービスレベル管理と連携してサプライヤとの外部委託契約(UC)を交渉、合意します。また、サプライヤのパフォーマンスなど、サプライヤとサプライヤが提供するサービスを管理します。
※「SLA(サービスレベル・アグリーメント)」は、ITサービス・プロバイダと顧客との間で交わされる合意です。
※「外部委託契約(UC)」は、ITサービス・プロバイダとサードパーティ(外部サプライヤ)との間で交わされる契約です。
【サプライヤのカテゴリ】
サプライヤの例としては、ネットワークのサービス・プロバイダ、ハードウェアやソフトウェアのベンダ、アウトソーシング組織などがあります。ITサービス・プロバイダにとってのサプライヤの重要度はさまざまですので、サプライヤ管理プロセスでは、重要度の低いサプライヤよりも、主要なサプライヤの管理により多くの時間と労力をかけます。
サプライヤの重要度を判断するために、サプライヤの利用に関する「リスクとインパクト」、および事業に対するサプライヤとサービスの「価値と重要性」に基づいて、サプライヤを4つのカテゴリに分類します。
「戦略的サプライヤ」「戦術的サプライヤ」「運用上のサプライヤ」「コモディティ・サプライヤ」があります。
[戦略的サプライヤ]
戦略的サプライヤは、長期的な計画を推進するために、戦略の機密情報を共有する重要な「パートナ」関係にあたるサプライヤです。通常、ITサービス・プロバイダ組織内の上級マネージャが関与し、定期的で頻繁な打ち合わせとパフォーマンス・レビューが行われます。
戦略的サプライヤの例としては、世界規模でネットワーク・サービスとサポートを供給するネットワーク・サービス・プロバイダがあります。
[戦術的サプライヤ]
戦術的サプライヤは、顕著な商業活動や事業でITサービス・プロバイダとやり取りがあるサプライヤです。通常、中級マネージャによって管理され、定期的な打ち合わせとパフォーマンス・レビューが行われます。
戦術的サプライヤの例としては、サーバのハードウェアの故障を解決するハードウェアの保守組織などがあります。
[運用上のサプライヤ]
運用上のサプライヤは、運用上の製品やサービスの供給をするサプライヤです。通常、現場の責任者である運用マネージャによって管理され、頻繁ではありませんが、定期的な打ち合わせとパフォーマンス・レビューが行われます。
運用上のサプライヤの例としては、利用頻度の低いウェブサイト運営などがあります。
[コモディティ・サプライヤ]
コモディティ・サプライヤは、容易に入手できる製品とサービスを提供するサプライヤです。比較的容易に代替できる、価値の低いサプライヤとなります。
コモディティ・サプライヤの例としては、プリンタ用紙やトナーカートリッジを供給するサプライヤなどがあります。
【契約】
契約とは、複数の当事者間における、法的な拘束力のある合意のことです。
ITサービス・プロバイダが外部サプライヤと結ぶ外部委託契約(UC: Underpinning Contract)は「契約」です。外部委託契約には、契約の期間、サービスの詳細、責任の範囲など、交渉によって合意された内容が含まれます。
【サプライヤおよび契約管理情報システム(SCMIS: Supplier and Contract Management Information System)】
サプライヤおよび契約管理情報システム(SCMIS)は、サプライヤ管理の支援に使用される、一連のツール、データ、および情報です。SCMISでは、サプライヤとの契約の詳細と共に、各サプライヤが提供する製品とサービスの詳細が管理されます。
サプライヤ管理プロセスがSCMISを維持、管理します。
リンク
いいなと思ったら応援しよう！
