Itil-quick-guide
ITIL-概要
*ITIL* は、エンドツーエンドのサービス管理のすべての側面に関するベストプラクティスガイドラインを提供するフレームワークです。 これは、人、プロセス、製品、およびパートナーの使用の全範囲を網羅しています。現在、ITILは、顧客にITサービスを提供するほぼすべての企業で実践されています。
ITILで説明されているプロセス、タスク、およびチェックリストは組織固有ではありませんが、どの組織でも実装できます。 組織にITサービスを計画、実装、および測定するためのフレームワークを提供します。
ITILは1989年に*英国の* Her Majesty’s Stationery Office（HMSO）によって Central Communications and Telecommunications Agency（CCTA）*に代わって発行され、現在はOffice of Government Commerce（OGC）に組み込まれています。
ITILが必要な理由
ITILは、ビジネスマネージャーとITマネージャーが顧客に効果的な方法でサービスを提供し、それによって顧客の信頼と満足を得ることを支援します。 ITILが効果的な役割を果たす分野は以下のとおりです-
- ITおよびビジネス戦略計画
- ITとビジネスの目標の統合と調整
- 継続的な改善の実施
- 適切なリソースとスキルセットの取得と保持
- コストと総所有コストの削減
- ITに対するビジネス価値の実証
- お金の価値と投資収益率の達成と実証。
- IT組織の有効性と効率性の測定
- ビジネスとITのパートナーシップと関係の発展
- プロジェクト実施の成功の改善
- 絶え間ないビジネスとITの変化の管理
ITILバージョン
最初の形のITILは、ITサービス管理のすべての側面を網羅した書籍のコレクションです。 それ以来、ITILには多くの変更が加えられたため、以下に示すようにITILの多くのバージョンが存在します-
ITIL V1
これはITILの最初のバージョンで、最初は31冊の本で構成されていました。
ITIL V2（2000年から2004年）
V1は7冊の本に置き換えられ、2000年から2004年にかけて非常に有名になりました。 現在、いくつかの国の多くの企業がこのバージョンを採用しており、これも受け入れられているバージョンになっています。
ITILV2（2007）
これは、以前のITILV2のもう1つの修正および統合バージョンであり、サービスライフサイクルをカバーする5つのコアブックで構成されるITILの第3バージョンで呼び出されます。 ITIL V3には、* 26プロセスと4つの機能*が含まれていました。
2011年、V3の2011年版が公開されました。 2007年にリリースされた更新バージョンでした。
ITIL出版物
ITILコア出版物には、サービス戦略、サービス設計、サービス移行、サービス運用、継続的なサービス管理という5つのマニュアルのセットが含まれています。
ITILの利点
次の図は、ITILが提供する利点を示しています-
ITIL V2対ITIL V3
ITIL V2とITIL V3の比較は、次の表に示されています-
| ITIL V2 | ITIL V3 |
|---|---|
| Focused on product, process and people. | Focused on product, process, people and partner. |
| Process oriented approach | Lifecycle based approach. |
| Security management is part of evaluation | Security management is a separate process |
| Emphasizes on service design and service strategy | Equal attention to all processes |
| Comprises 10 processes and 2 functions | Comprises 26 processes and 4 functions. |
ITIL-用語
この章では、チュートリアルを簡単かつ迅速に理解するのに役立つITILの基本的な用語について説明します。 次の表は、ITILを学習するために必要なすべての基本的な用語で構成されています。
| Sr.No. | ITIL Terminologies |
|---|---|
| 1 |
ITIL 情報技術インフラストラクチャライブラリは、ほとんどのインフラストラクチャサービスプロバイダーが実践している一連のベストプラクティスであり、顧客にサービスを提供して、希望するコストと品質でビジネスニーズを満たします。 |
| 2 |
Service サービスは、与えられた制約の範囲内で作業しながら顧客の希望する結果を達成することにより、顧客に価値を提供する手段です。 |
| 3 |
Service Level これは、1つ以上のサービスレベルターゲットに対する測定および報告された成果です。 |
| 4 |
Service Level Agreement これは、サービスプロバイダーと顧客の間の契約です。 SLAはITサービスを記述し、サービスレベルターゲットを文書化し、プロバイダーと顧客の責任を指定します。 |
| 5 |
Service Strategy サービス戦略は、組織の能力および戦略的資産としてのサービス管理の設計、開発、実装にも役立ちます。 これにより、サービスプロバイダーは、ビジネスサイクル、業界の混乱、リーダーシップの変化など、長期にわたって競合他社の選択肢を一貫して上回ることができます。 |
| 6 |
Service Model サービスモデルは、サービスとそのサービスを提供するために必要なコンポーネントの高レベルの説明です。 |
| 7 |
Service Portfolio サービスポートフォリオは、サービスプロバイダーが提供するサービスのセットです。 |
| 8 |
Service Catalogue サービスカタログは、サービスプロバイダーによって特定の顧客に提供される特定のサービスのセットです。 |
| 9 |
Customer Portfolio 顧客ポートフォリオは、ITサービスプロバイダーのすべての顧客を記録するために使用されます。 |
| 10 |
Demand Management 需要管理は、サービス戦略において非常に重要かつ重要なプロセスです。 サービスに対する顧客の需要を理解すると、それらの需要を満たすために適切な容量をプロビジョニングできるようになります。 |
| 11 |
Pattern of Business Activity PBAは、顧客がどのように動作し、将来必要になる可能性があるかを知ることによって達成される非常に重要な活動です。 |
| 12 |
Service Design サービス設計は、サービスの青写真を提供します。 これには、新しいサービスの設計が含まれるだけでなく、既存のサービスに対する変更や改善も考案されます。 |
| 13 |
Operational Level Agreement (OLA) OLAは、ITサービスプロバイダーと同じ組織の別の部分との間の契約です。 |
| 14 |
Service Level Report 合意されたサービス品質を提供するサービスプロバイダーの能力に関する洞察を提供します。 |
| 15 |
Service Level Requirements 詳細なサービスレベルターゲットを定義する、クライアントの観点からのサービスの要件を含むドキュメントです。 |
| 16 |
Service Asset サービス資産は、サービスプロバイダーが所有するリソースと機能であり、サービスプロバイダーが顧客にサービスを提供できるようにします。 |
| 17 |
Configuration Item (CI) 構成アイテムはサービス資産のサブセットであり、サービスの提供に直接影響します。 実動に影響を与えるすべてのサーバー、ネットワーク、アプリケーションは、構成アイテムとして知られています。 |
| 18 |
SACM サービス資産および構成管理（SACM）は、すべての資産およびCIの最新かつ検証済みのデータベースの保守を扱い、これらのデータベースは他のサービス管理プロセスでも利用できます。 |
| 20 |
Change 変更とは、既存のサービスを変更することです。 |
| 21 |
Event イベントは、ITサービスの提供にとって重要な検出可能な発生として定義されます。 イベントは、構成アイテム（CI）または監視ツールによって作成されます。 |
| 22 |
Incident インシデントは、ITサービスの中断として定義されます。 インシデントは、サービスデスクまたはイベント管理からインシデント管理ツールへのインターフェースを介して報告できます。 |
| 23 |
Service Request サービスリクエストとは、ユーザーからの要求を指します。 これらの要求には、小さな変更、パスワードの変更、追加のソフトウェアアプリケーションのインストール、情報の要求などが含まれます。 |
| 24 |
Problem ITILでは、問題は1つ以上のインシデントの未知の原因として定義されます。 |
| 25 |
Known Error 既知のエラーは、その原因と解決策に関する問題として明確に特定されています。 既知のエラーデータベース（KEDB）に保存されます。 |
ITIL-サービスの基本
この章では、ITILのサービスの基本について詳しく説明します。
サービス
サービスは、与えられた制約の範囲内で作業しながら顧客の希望する結果を達成することにより、顧客に価値を提供する手段です。
サービス対 製品情報
次の表は、サービスと製品の比較を示しています-
| Services | Products |
|---|---|
| Services are not tangible. | Products are tangible. |
| Services are produced and consumed at same time. | Products are not produced and consumed at same time. |
| Services are inconsistent. | Products are consistent. |
| The user participates in the production of services. | The user doesn’t participate in the production of products. |
サービス管理
サービス管理とは、ITサービス提供の管理のあらゆる側面を指します。 ITILによると、サービス管理には、サービスとして顧客に付加価値をもたらすためのすべての組織機能が含まれています。
サービス管理の目標
サービス管理の主な目標は次のとおりです-
- 組織および顧客の現在および将来の要件に合わせてITサービスを適応可能にします。
- ビジネスとの良好で応答性の高い関係を開発および維持します。
- すべてのITリソースを効果的かつ効率的に使用します。
- 提供されるサービスの品質を最適化します。
- サービス提供の長期コストの削減。
サービス管理の達成
ビジネスと顧客の満足を達成するために実行する必要のある主要な活動を以下に示します-
- サービスレベル契約（SLA）で、顧客およびビジネスの品質目標と責任を文書化し、交渉し、同意します。
- 顧客フィードバックおよび顧客満足度調査における顧客意見の定期的な評価。
- IT担当者は、顧客とビジネスの観点を取り入れ、常に顧客とのやり取りをできるだけシンプルにしようとしています。
- ICTインフラストラクチャを理解する。
- IT担当者は定期的にカスタマージャーニーに参加し、カスタマーエクスペリエンスをサンプリングします。
ITIL-サービスライフサイクル
ITILの完全なフレームワークは、サービスライフサイクルに基づいています。 各ライフサイクルは、効果的なサービス管理のための特定のプロセスを定義します。
サービスライフサイクルは、サービス管理アプローチを拡大し、その構造をよりよく理解するのに役立ちます。 今後の章では、そのようなライフサイクルすべてを、プロセスと機能とともに個別に説明します。
プロセスと機能
ITIL V3には26のプロセスと4つの機能があります。 これらのプロセスと機能については、各サービスライフサイクルで詳細に説明します。
プロセス
プロセスは、ポリシー、標準、ガイドライン、アクティビティ、および作業指示を定義します。 必要な結果を生成するために、いくつかの定義された入力が必要です。
関数
機能は、1つ以上のプロセスとアクティビティを実行するために必要な人またはツールのグループとして定義されます。
ITIL-サービス戦略の概要
- サービス戦略*は、組織の能力および戦略的資産としてのサービス管理の設計、開発、実装にも役立ちます。 これにより、サービスプロバイダーは、ビジネスサイクル、業界の混乱、リーダーシップの変化など、長期にわたって競合他社の選択肢を一貫して上回ることができます。
サービス戦略は、次の重要な概念で構成されています-
- 価値創造
- サービス資産
- サービスプロバイダーの種類
- サービス構造
- サービス市場の定義
- サービス提供の開発
- 財務管理
- サービスポートフォリオ
- 需要管理
- 投資収益率
戦略的評価
サービス戦略を作成する前に、プロバイダーはまず、すでに何を行っているかを注意深く調べる必要があります。 次の質問は、サービスプロバイダーの特徴的な機能を明らかにするのに役立ちます-
- 最も特徴的なサービスまたはサービスの種類はどれですか？
- 最も収益性の高いサービスまたはサービスの種類はどれですか？ *バリューチェーンまたはバリューネットワークでのどの活動が最も異なっていて効果的ですか？
戦略的評価の要因
戦略的評価で重要な役割を果たす重要な要因は以下のとおりです-
| Sr.No. | Factors & Description |
|---|---|
| 1 |
組織の属性。 たとえば、リソースと機能、サービス品質、スキル、コスト構造、製品知識、顧客関係など。 |
| 2 |
Business Strategy 視点、位置、計画、パターンはビジネス戦略から得られます。 |
| 3 |
Critical Success factors サービスプロバイダーは、成功したときにどのように知るのでしょうか？ |
| 4 |
Threats and opportunities 競争的思考を含みます。 たとえば、サービスプロバイダーは代替に対して脆弱ですか？または競合する代替を上回る手段がありますか？ |
価値創造
サービス戦略は、より良い価値を提供するための独自のアプローチを定義します。 顧客のニーズに応じて、サービスは2つの要素で構成される必要があります-
- 実用性
- 保証
実用性
顧客は、目的のビジネス成果に関連するタスクのパフォーマンスにプラスの影響を与えるサービスの属性から顧客に認識されます。 これは目的のためのモミです。
効用は一般的に次の点で述べられています-
- サポートされる成果
- 所有コストとリスクを回避
保証
保証は、十分な容量、継続性、およびセキュリティを備えたサービスのユーティリティが必要に応じて利用可能であることを保証します。 保証の価値は、確実性のレベルで伝えられます。
通常、保証は、サービスの利用の可用性、容量、継続性、およびセキュリティの観点から定義されます。
可用性
合意された条件の下でサービスを利用できることを顧客に保証します。
容量
サービスが特定レベルのビジネスアクティビティまたは需要をサポートすることを保証します。
連続
これにより、重大な障害が発生してもサービスがビジネスをサポートし続けることが保証されます。
セキュリティ
サービスプロバイダーが提供するサービスが安全であることを保証します。
サービス資産
以下にリストされているように、2種類のサービス資産があります-
- リソース
- 能力
リソース
リソースは生産のためのインプットです。 リソースは、経営陣、組織、人、知識によって変わります。
能力
能力とは、生産のためのリソースを開発および制御するスキルを指します。 スキルは、知識、経験、情報に基づいています。
サービスプロバイダーの種類
以下に説明するように、サービスプロバイダーは大きく3つのタイプに分類できます-
タイプI-内部サービスプロバイダー
内部サービスプロバイダーは、組織内のビジネス機能を指します。 管理、財務、人事、およびITサービスプロバイダーはすべて、内部サービスプロバイダーの管理下にあります。
タイプII-共有サービスプロバイダー
これにより、IT、人事、ロジスティクスなどのビジネス機能が、共有サービスユニット（SSU）と呼ばれる自律的な特別ユニットに統合されます。
タイプIII-外部サービスプロバイダー
外部サービスプロバイダーとは、サードパーティのサービスプロバイダーを指します。 競争力のある価格を提供し、需要を統合することで単価を下げることができます。
戦略の4つのP
下記の4つのPは、サービス戦略のさまざまな形式を識別し、サービス戦略へのエントリポイントと見なされます。
遠近法
ビジョンと方向性を記述し、顧客とやり取りするというビジネス哲学を明確にします。
ポジション
明確に定義されたスタンスを採用する決定について説明します。 それは、顧客の心の中の特徴として表現されます。 これは、他の人と同じ空間で競争することを意味しますが、差別化された価値提案は顧客にとって魅力的です。 特定のタイプの顧客に幅広いサービスを提供することであろうと、最低コストの選択肢であろうと、それは戦略的な位置です。
Plan
計画では、「高価値または低コストのサービスをどのように提供するのか？」または「専門サービスをどのように達成し、提供しますか？」
パターン
組織の物事の基本的な方法を説明します。
サービス戦略プロセス
次の図は、サービス戦略におけるさまざまなプロセスとそれらの関係を表しています-
戦略管理
このプロセスには、市場の定義、提供物の開発、戦略的資産の開発、および戦略の実装の準備という4つのアクティビティが含まれます。
サービスポートフォリオ管理
サービスポートフォリオは、サービスプロバイダーが提供できるすべてのサービスを定義します。 企業全体のサービス管理投資を制御し、その価値を積極的に管理するのに役立ちます。
ビジネス関係管理
このプロセスは、顧客のニーズに合わせて適切なサービスが開発されるようにすることで、サービスプロバイダーと顧客との良好な関係を確立することを扱います。
需要管理
このプロセスにより、サービスの消費とその配信のバランスが維持されます。
財務管理
財務管理は、IT組織のすべてのコストを決定するのに役立ちます。 サービスプロバイダータイプの3種類すべて-内部、外部、および共有サービスプロバイダーの戦略的ツールとして機能します。
ITIL-サービス戦略の役割
サービス戦略のさまざまな重要な側面の管理を担当する役割がいくつかあります。 この章では、それぞれの役割について詳しく説明します。
| Sr.No | Role & Responsibility |
|---|---|
| 1 |
Business Relationship Manager
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
ITIL-戦略の生成
肯定的な結果を得るには、サービスプロバイダーはサービスを戦略的に計画する必要があります。 優れたサービス戦略は、より良い価値を提供するための独自のアプローチを定義します。
- Service Strategy Managerは、このプロセスのプロセス所有者です。*
サービス生成サブプロセス
戦略管理は、以下で説明する4つのアクティビティで構成されます-
市場の定義
市場で利用可能なサービスの調査を取る必要があります。 既存のサービスのコストと品質、および競争環境で提供できる新しいサービスの明確な見通しを提供します。
製品の開発
このサービスプロバイダーでは、顧客に表示され、利用可能なすべてのサービスを含むポートフォリオを開発します。 サービスポートフォリオは、市場に対するすべての拘束力のあるサービス投資を代表するために開発されています。
戦略的資産の開発
低コストで価値の高いサービスを顧客に提供するための新しいテクノロジー、リソース、機能の購入を扱っています。
戦略の実施のための測定と準備
戦略の成功または失敗を測定するために、すべての重要な成功要因が測定されます。 また、市場の完成が観察され、それに応じて優先度が調整されます。
ITIL-サービスポートフォリオ管理
サービスポートフォリオ
サービスポートフォリオには、サービスライフサイクル全体で使用されるすべてのサービスの説明が含まれています。 また、すべての顧客と市場空間にわたってサービスプロバイダーが行ったコミットメントと投資を表しています。
サービスカタログはサービスポートフォリオのサブセットであり、サービス運用フェーズで現在アクティブなサービスが含まれています。 サービス設計プロセスの一環として、サービスカタログについて詳しく説明します。
サービスポートフォリオ管理
サービスポートフォリオ管理により、サービスプロバイダーは、顧客のニーズを満たす適切なサービスの組み合わせを提供します。
- Service Portfolio Managerはこのプロセスのプロセス所有者です。*
サービスポートフォリオ管理の目的は、次の質問に答えを提供することです-
- 顧客がこのサービスを購入する必要があるのはなぜですか？
- なぜ彼らは私たちから購入する必要がありますか？
- 価格体系はどのような形をとっていますか？
- 私たちの長所と短所、優先事項、リスクは何ですか？
- リソースと機能をどのように適用する必要がありますか？
サブプロセス
サービスポートフォリオ管理には、次の図に示すサブプロセスが含まれます-
定義する
このプロセスの目的は、サービスの望ましい結果を定義することです。
分析する
このプロセスの目的は、提案された新しいサービスまたは変更されたサービスがサービスポートフォリオ内の既存のサービスに与える影響を分析することです。
承認する
このプロセスの目的は、変更管理に変更提案を提出し、変更提案が承認された場合に新規または変更されたサービスの設計段階を開始することです。
チャーター
このプロセスの目的は、意思決定の伝達、リソースの割り当て、およびチャーターサービスです。
ITIL-ビジネス関係管理
この章では、ITILのビジネス関係管理の側面について詳しく説明します。
関係
関係とは、2人の人間または物事間のつながりです。 ビジネスリレーションシップマネジメントの場合、ITサービスプロバイダーとビジネス間の接続であり、構成管理では、互いに依存する2つの構成済みアイテム間の接続です。
- ビジネス関係管理*プロセスにより、サービスプロバイダーと顧客との良好な関係が確保されます。 一般に、顧客のニーズを特定、理解、サポートすることで達成され、それらのニーズを満たすために適切なサービスが開発されます。
ビジネスリレーションシップマネジメントには通常、
- マネージャーとの個人的な関係の管理
- サービスポートフォリオ管理への入力の提供
- ITサービスプロバイダーが顧客のニーズを満たしていることを確認する
Business Relationship Managerは、このプロセスのプロセス所有者です。
サブプロセス
ビジネス関係管理には、次のサブプロセスが含まれます-
顧客との関係を維持する
このプロセスにより、サービスプロバイダーは顧客のニーズを理解し、新しい潜在顧客との関係を確立できます。
サービス要件を特定する
このプロセスにより、サービスプロバイダーはサービスの出力を完全に理解し、既存のサービスを使用して顧客のニーズを満たすことができるか、または新しいサービスを作成する必要があるかを判断できます。
顧客を標準サービスに登録する
このプロセスでは、顧客の要件とサービスレベル契約を扱います。
顧客の苦情を処理する
このプロセスの目的は、顧客の苦情を記録し、必要に応じて是正措置を取ることです。
顧客の苦情を監視する
このプロセスの目的は、顧客の苦情の処理ステータスを監視することです。
顧客満足度調査
このプロセスの目的は、顧客の期待に応えられない範囲を特定することです。
ITIL-需要管理
- デマンド管理*は、サービス戦略において非常に重要かつ重要なプロセスです。 サービスに対する顧客の需要を理解すると、それらの需要を満たすために適切な容量をプロビジョニングできるようになります。
不適切な需要管理は、サービスとリソースの不適切な使用につながります。 したがって、顧客の需要を分析する価値があります。
- Demand Managerはこのプロセスの所有者です。*
戦略的レベルの需要管理
戦略的需要管理は、以下で説明する2つの重要なことに焦点を当てています-
ビジネス分析のパターン（PBA）
*PBA* は、顧客がどのように動作し、将来必要になる可能性があるかを知ることによって達成される非常に重要な活動です。ユーザープロファイル
ユーザーが示す需要パターンです。 プロセス、人、または機能になります。
戦術レベルの需要管理
戦術レベルの需要管理の下で、差分充電に焦点を当てます。 異なる時間に同じITサービス機能に対して異なる金額を請求することにより、需要管理をサポートする手法です。
需要管理の課題
需要管理は、サービス戦略の重要なプロセスです。 このプロセスで発生する課題は以下のとおりです-
- 顧客の要求の不適切な分析は、容量の不適切な使用につながります。 過剰な容量は、価値を生み出すことなくコストを生み出します。
- サービスレベルを提供するには、一定量の未使用容量が必要になる場合があります。 そのような能力は、より高い能力で可能になったより高いレベルの保証を通じて価値を生み出しています。
- 需要の不確実性を減らすには、サービスレベル契約、予測、計画、および顧客との緊密な調整が必要です。
- サービスの生産は、出力を消費する需要が同時に存在しない限り発生しません。
- 需要の到着は、オフピーク価格設定、ボリューム割引、差別化されたサービスレベルなどの需要管理手法の影響も受けます。
サービスパッケージ
以下に説明するように、2つのコンポーネントがあります-
コアサービス、これは顧客が喜んで支払う基本的なサービスです。 彼らは顧客に実際の価値をもたらします。
- サポートサービス*コアサービスの価値提案を強化します。 主要サービスに機能を追加しました。
差別化された製品の開発
コアサービスとサポートサービスのパッケージ化は、設計および運用サービスに影響を及ぼします。 コアまたはサポートサービスで標準化するかどうかを決定する必要があります。 次の図に示すように、パッケージ化に対して異なるアプローチをとるインサービスオファリングと同じレベルの差別化を実現できます。
サービスレベルパッケージ
サービスパッケージには、1つ以上のサービスレベルパッケージ（SLP）があります。 各サービスレベルパッケージは、顧客の成果、資産、およびPBAの観点から、明確なレベルのユーティリティと保証を提供します。
- ビジネス成果は、サービスレベルパッケージの究極の基盤です。*
ITIL-財務管理
- 財務管理*では、サービスの会計、予算編成、および課金活動を扱います。 直接および間接コストに基づいてIT組織のすべてのコストを決定します。 このプロセスは、3種類すべてのサービスプロバイダー（内部、外部、または共有サービスプロバイダー）で使用されます。
- Financial Managerは、このプロセスのプロセス所有者です。*
財務管理の利点
財務管理の利点のいくつかはここにあります-
- 強化された意思決定
- 変化の速度
- サービスポートフォリオ管理
- 業務管理
- 価値の獲得と創造
財務管理の重要な決定
財務管理の決定を下すために、次の決定が行われます-
原価センタ、バリューセンタまたは会計センタ
資金の補充方法を決定することが重要です。 運用モデルに関する明確さは、サービスプロビジョニングコストの必要性、可視性の理解に大きく貢献します。資金調達は、ビジネスのITに対する自信と認識の良いテストです。
IT財務サイクルは、顧客が価値として特定する出力を作成するリソースに適用される資金調達から始まります。 この値には、再び開始するための資金調達サイクルが含まれます。
チャージバック-充電するかしないか
チャージバックモデルは、追加の説明責任と可視性を提供します。 充電はビジネスに価値をもたらすはずです。
チャージバックモデルは、計算の単純さと、ビジネスがそれらを理解する能力に基づいて異なります。 サンプルのチャージバックモデルには、次のコンポーネントが含まれています。
想定元本
これは、企業の金融システムに対して仕訳が行われるかどうかに対応します。 ここでは、1つは企業の財務システムにコストを記録し、もう1つは記録するが記録しない2本の方法があります。
この2冊目の本は同じ情報を提供しますが、別の録音方法を使用した場合に何が起こるかを反映しています。
階層型サブスクリプション
これは、サービスに提供されるさまざまなレベルの保証および/またはユーティリティを指し、それらはすべて適切なチャージバックモデルが適用されて価格設定されています。
従量制
これには、需要モデリングにユーティリティコンピューティング機能が組み込まれており、リアルタイムの使用状況を把握する上で自信が持てます。
固定費またはユーザー費用
これでは、コストはユーザー数のような合意された分母で割られます。
ITIL-サービス設計の概要
サービス設計はITILの不可欠な部分です。 この章では、これについて詳しく説明します。
前書き
- サービス設計*は、サービスの青写真を提供します。 これには、新しいサービスの設計だけでなく、既存のサービスの変更や改善も含まれます。
また、サービスプロバイダーは、サービス管理の設計機能を開発および取得する方法を知ることができます。
バランスの取れたデザイン
サービスは、変化するビジネス要件に動的に適応できる必要があります。 このためには、次の3つの要因の間のバランスを維持する必要があります-
- 必要な品質の機能
- リソース、すなわち スタッフ、技術、利用可能な財政
- 時刻表
サービス設計の側面
サービス設計は、次の側面に焦点を当てています-
- ビジネス目標を満たすように設計されたITサービス。
- 目的に適合し、使用に適合するように設計されたサービス。
- 投資収益率を達成するために計画された所有コスト。
- バランスの取れた機能、コスト、パフォーマンス。
- より安定した予測可能なITサービス。
- 潜在的なリスクが軽減されるため、ITサービスはセキュリティの脅威から保護されます。
- 技術アーキテクチャ、管理アーキテクチャ、およびシステム管理ツールを設計します。
- サービス、プロセス、アーキテクチャ、および基礎となるコンポーネントの測定システム、方法、およびメトリックの設計。
- 合意されたすべての機能要件、リソース、および機能を含むサービスソリューションの設計。
サービス指向アーキテクチャー
サービス指向アーキテクチャ（SOA）*は、独立した使用可能なサービスの開発を指します。 SOAは、 Advancement of Information Structured（OASIS）*のために組織によって定義されています。 SOAは、モジュール性により柔軟性を高めます。
SOAアプローチの前提条件
SOAアプローチの実装に必要な前提条件は次のとおりです-
- サービスの定義
- サービス間のインターフェイスと依存関係に関する明確性
- サービスの開発と定義のための標準の適用 *広範囲に渡る技術とツールの使用。
サービス設計プロセス
次の表は、サービス設計のいくつかのプロセスを説明しています-
| Sr.No. | Process & Description |
|---|---|
| 1 |
サービス設計活動のポリシー、ガイドライン、標準、および予算の維持を扱います。 |
| 2 |
Service Catalogue Management このプロセスは、支払いを希望する顧客に固有のサービスを含むサービスカタログの設計を担当します。 |
| 3 |
Service Level Management このプロセスの目標は、サービスの品質がプロビジョニングされた品質契約を満たすことを保証することです |
| 4 |
Capacity Management キャパシティ管理は、既存のリソースの最適かつ経済的な使用と将来のキャパシティ要件計画を保証します。 |
| 5 |
Availability Management 可用性管理は、運用サービスが合意されたすべての可用性目標を確実に満たすようにします。 |
| 6 |
IT Service Continuity Management このプロセスにより、災害が発生してもITサービスの継続性が確保されます。 |
| 7 |
Information Security Management このプロセスにより、データの機密性、整合性、可用性が確保されます。 |
| 8 |
Supplier Management このプロセスにより、サプライヤとの関係とパフォーマンスが保証され、サプライヤとの適切かつ関連する契約の管理も保証されます。 |
ITIL-サービスカタログ管理
サービスカタログ
サービスカタログには、顧客が支払う意思のある特定のサービスの情報が含まれています。 これは、従業員やコンサルタントがサービスに対する要求やサービスに関する要求をルーティングできるようにするナレッジマネジメントツールです。
サービスカタログはサービスポートフォリオのサブセットであり、サービス運用フェーズで現在アクティブなサービスが含まれています。
サービスカタログの構成
カタログ内の各サービスには、次の要素が含まれています-
- サービスの識別ラベル
- サービスの説明
- 関連するサービスリクエストタイプ
- サポートまたは基盤となるサービス
- 他の同様のサービスとグループ化できるサービスの分類またはタイプ
- すべてのサービス間のインターフェイスと依存関係、およびサービスカタログとCMS内のサポートコンポーネントと構成アイテム（CI）
- サービスの所有権と説明責任を明確にする
- 関連費用
- サービスをリクエストする方法とその提供方法
- エスカレーションポイントと主要な契約
- サービスレベル契約（SLA）データ
サービスカタログの側面
サービスカタログには2つの側面があります-
ビジネスサービスカタログ
顧客に提供されるすべてのITサービスと、ITサービスに依存するビジネスユニットおよびビジネスプロセスとの関係が含まれています。
技術サービスカタログ
顧客に提供されるすべてのITサービスと、サポートサービス、共有サービス、コンポーネント、およびビジネスへのサービスの提供をサポートするために必要なCIとの関係が含まれます。
サービスカタログ管理プロセスは、すべての承認された人にすべての合意されたサービスに関する情報を提供する責任があります。 このプロセスでは、正しい更新された情報を使用してサービスカタログの作成と保守も行います。
- Service Catalog Managerはこのプロセスのプロセス所有者です。*
サービスポートフォリオまたはサービスカタログの変更は、変更管理プロセスの対象となります。
SCMアクティビティ
Service Catalog Managementに含まれる主要なアクティビティは次のとおりです-
- すべての関係者とのサービス定義の同意と文書化。
- サービスポートフォリオ管理の内容に同意し、サービスポートフォリオおよびサービスカタログの内容に同意するためのインターフェースおよびサービスポートフォリオ管理
- ビジネスユニットとそのビジネスプロセスの依存関係について、ビジネスサービスカタログに含まれるサポートITサービスとのビジネスおよびITサービス継続性管理とのインターフェイス
- サービスポートフォリオと併せて、サービスカタログとそのコンテンツを作成および保守する
- ビジネスリレーションシップマネジメントおよびサービスレベルマネジメントと連携して、情報がビジネスおよびビジネスプロセスに合わせられるようにします。
ITIL-サービスレベル管理
この章では、サービスレベル管理に関連するさまざまな側面について詳しく説明します。
概要
- サービスレベル管理（SLM）*は、既存のサービスをあるレベルのポリシーでネゴシエート、合意、および文書化します。
- Service Level Managerはこのプロセスのプロセス所有者です。*
SLMは次の2種類の契約を扱います-
サービスレベル契約（SLA）
これは、サービスプロバイダーが提供するサービス品質のレベルに関する保証を保証する合意文書です。 サービスプロバイダーと顧客の間です。
運用レベル契約（OLA）
SLAとは異なり、これは組織内の合意です。
SLMアクティビティ
次の図は、SLMプロセスに関係するアクティビティを示しています-
サービスレベル要件（SLR）は、サービスライフサイクルのサービス設計における最も初期のアクティビティの1つです。 サービスカタログが作成され、SLA構造が合意されたら、SLRを作成する必要があります。
目的
SLMの目的は次のとおりです-
| Sr.No. | Objectives |
|---|---|
| 1 | Define, document, agree, monitor, measure, report, and review the level of IT service provided. |
| 2 | Provide and improve the relationship and communication with the business and customers. |
| 3 | Ensure that specific and measurable targets are developed for all IT services. |
| 4 | Monitor and improve customer satisfaction with the quality of service delivered |
| 5 | Ensure that IT and customers have a clear and unambiguous expectation of the level of service to be delivered |
ITIL-キャパシティ管理
*Capacity Management* は、利用可能なリソースの適切な利用を保証し、将来の容量要件を費用対効果の高いタイムリーな方法で利用可能にします。 キャパシティ管理は、サービス戦略およびサービス設計フェーズで検討されます。また、キャパシティプランを作成し、定期的にアップグレードすることにより、ITが最適で費用対効果の高い方法でサイジングされるようにします。
- Capacity Managerは、このプロセスのプロセス所有者です。*
キャパシティ管理活動
次の表は、キャパシティ管理プロセスに関連するいくつかのアクティビティを示しています-
| Sr.No. | Capacity Management Activities |
|---|---|
| 1 | Producing capacity plans, enabling service provider to continue to provide services of quality defined in SLA. |
| 2 | Assistance with identification and resolution of any incident associated with any service or component performance. |
| 3 | Understanding customer’s current and future demands for IT resources and producing forecasts for future requirements |
| 4 | Monitoring Pattern of Business activity and service level plans through performance, utilization and throughput of IT services and the supporting infrastructure, environmental, data and applications components. |
| 5 | Influencing demand management in conjunction with Financial Management |
| 6 | Undertaking tuning activities to make the most efficient use of existing IT resources. |
| 7 | Proactive improvement of service or component performance |
目的
キャパシティ管理の目的は次のとおりです-
| Sr.No. | Objectives |
|---|---|
| 1 | Produce and maintain an appropriate up-to-date capacity plan reflecting the current and future needs of the business. |
| 2 | Provide advice and guidance to all other areas of the business and IT on all capacity and performance related issues. |
| 3 | To manage performance and capacity of both services and resources. |
| 4 | Assisting with diagnosis and resolution of performance and capacity related incidents and problems. |
| 5 | Assess the impact of all changes on the capacity plan, and the performance and capacity of services and resources. |
| 6 | Ensure that proactive measures to improve the performance of services are implemented wherever it is cost justifiable to do so. |
キャパシティ管理要素
キャパシティ管理には、次の3つのコンポーネントが広く含まれています。次の図に示すように、ビジネスキャパシティ管理、サービスキャパシティ管理、*および*コンポーネントキャパシティ管理
事業能力管理
このサブプロセスでは、将来のビジネスニーズの計画を予測および開発します。 これは、さまざまなサービスによる現在のリソース使用率に関する既存のデータを使用して行われます。
サービスキャパシティ管理
このサブプロセスでは、ITサービスの機能、リソースの使用状況、およびバリエーションを理解して、適切なサービス契約を設計できるようにします。
コンポーネント容量管理
このサブプロセスにより、ネットワーク容量、帯域幅などの現在のITリソースコンポーネントの使用が最適化されます。
キャパシティ管理情報システム（CMIS）
CMISは、リソース、商品などの更新されたデータベースを維持します。 これは、容量管理内のすべてのサブプロセスで使用されます。
ITIL-可用性管理
- 可用性管理（AM）*は、ITサービスが合意された可用性の目標を確実に満たすようにします。 また、新規または変更されたサービスが可用性の目標を満たし、既存のサービスに影響を与えないようにします。
可用性は次のように表されます：（合意されたサービス時間-ダウンタイム）/合意されたサービス時間
Availability Managerは、このプロセスのプロセス所有者です。
目的
可用性管理の目的は次のとおりです-
可用性管理プロセス
可用性管理プロセスは、次の主要な要素で構成されています-
- 事後活動
- 積極的な活動
事後活動
運用上の役割に関与するアクティビティは、リアクティブアクティビティと呼ばれます。 すべてのイベント、インシデント、および利用不能に関連する問題の監視、測定、分析、管理などのアクティビティは、事後対応型アクティビティになります。
積極的な活動
設計および計画の役割に関与するアクティビティは、事前対応型アクティビティと呼ばれます。 予防的な計画、可用性の設計および改善などの活動は、予防的な活動の対象となります。
可用性管理プロセスは、次の2つの相互接続されたレベルで完了します-
- サービスの可用性
- コンポーネントの可用性
サービスの可用性
サービスの可用性と非可用性、およびサービスの可用性に対するコンポーネントの可用性と非可用性の影響を扱います。
コンポーネントの可用性
コンポーネントの可用性と非可用性を扱います。
可用性管理サブプロセス
次の図は、可用性管理プロセスに関係するサブプロセスを示しています-
重要なビジネス機能（VBF）の特定
VBFは、ITサービスによってサポートされるビジネスに不可欠な要素を指します。 すべてのVBFを文書化して、ビジネスの連携と焦点を改善することが重要です。
可用性のための設計
厳しい高可用性のニーズを満たす高可用性ソリューションを提供するには追加のコストがかかりますが、より重要なVBFをサポートするサービスの高可用性を提供する必要があります。
サービス障害分析（SFA）
サービス障害分析は次のように設計されています-
- サービス中断の原因を特定するための構造化されたアプローチをユーザーに提供します。
- 可用性の不足が発生している場所と理由を評価します。
- 実装またはアクティビティプランへの入力のための一連の改善を作成することにより、ITサービスの全体的な可用性を向上させます。
ITIL-サービス継続性管理
*ITSCM* は、災害時にITサービスの継続性を保証します。 また、災害から回復するためにサービス資産と原稿を保護するために必要な保険のレベルも評価します。- IT Service Continuity Managerは、このプロセスのプロセス所有者です。*
目的
次の図は、ITSCMのいくつかの目的を示しています-
ITSCMプロセス
ITSCMプロセスは、開始、要件と戦略、実装、および継続的な運用の4つのステージで構成されます。
開始
スコープと参照条件、プロジェクト計画、リソース割り当てを定義するポリシー設定が含まれます。
要件と戦略
これには、ビジネスインパクト分析、リスク評価が含まれます。
実装
これには、リスク削減対策、復旧オプションの手配、テストおよび計画の実行が含まれます。
継続的な運用
これには、教育と認識、ITSCM計画の変更管理、継続的なテストが含まれます。
ITIL-情報セキュリティ管理
- 情報セキュリティ管理（ISM）*は、組織データとITサービスの機密性、信頼性、否認防止、整合性、可用性を保証します。 また、組織の情報リソースの合理的な使用と情報セキュリティリスクの適切な管理を保証します。
- Information Security Managerは、このプロセスのプロセス所有者です。*
情報セキュリティは次の場合に満たされると見なされます-
- 情報は、許可された人物のみに観察または開示されます
- 情報は完全かつ正確であり、不正アクセス（完全性）から保護されています
- 情報は必要なときに利用可能で使用可能であり、情報を提供するシステムは攻撃に抵抗し、障害からの回復または障害の防止を行います（可用性）
- 企業間またはパートナーとのビジネストランザクションおよび情報交換は信頼できます（信頼性および否認防止）
ISMセキュリティポリシー
ISMセキュリティポリシーがセキュリティのすべての領域をカバーし、適切であり、ビジネスニーズを満たすために必要であり、次の図に示すポリシーを含める必要があります-
ISMフレームワーク
ISMプロセス
次の図は、情報セキュリティ管理（ISM）のプロセス全体を示しています-
ISMフレームワークの主要な要素
ISMフレームワークには、次の重要な要素が含まれます-
コントロール
コントロール要素の目的は-
- 情報セキュリティポリシーを準備、承認、実装するための組織構造を確立する
- 責任を割り当てる
- ドキュメントの確立と管理
Plan
この要素の目的は、組織の要件の理解に基づいて、適切なセキュリティ対策を考案および推奨することです。
実装する
この重要な要素により、セキュリティポリシーを支える適切な手順、ツール、およびコントロールが確実に配置されます。
評価
評価要素の目的は-
- ITシステムの技術的なセキュリティの定期的な監査を実施する
- SLAおよびOLAのセキュリティポリシーおよびセキュリティ要件への準拠を監視および確認する
維持する
メンテナンス要素の目的は次のとおりです-
- SLAやOLAなどで指定されているセキュリティ契約の改善
- セキュリティ対策と制御の実装を改善する
予防的
この重要な要素により、セキュリティインシデントの発生を確実に防止できます。 この予防セキュリティ対策を有効にするには、アクセス権の制御、承認、識別、認証、アクセス制御などの手段が必要です。
還元的
発生する可能性のある損傷を最小限に抑えます。
探偵
セキュリティインシデントをできるだけ早く検出することが重要です。
抑圧的
この措置は、セキュリティインシデントの繰り返しを防止するために使用されます。
是正
この措置により、損傷が可能な限り修復されることが保証されます。
ITIL-サプライヤー管理
サプライヤ管理では、サプライヤとパートナーとの良好な関係を維持して、質の高いITサービスを確保します。
- Supplier Managerはこのプロセスのプロセス所有者です。*
目的
次の図は、サプライヤ管理のいくつかの目的を示しています-
サプライヤー管理プロセス
次の図は、サプライヤ管理に含まれるいくつかのアクティビティを示しています-
サプライヤ管理プロセスに関連するアクティビティは次のとおりです-
- サプライヤーの方針の実施と実施
- SCDのメンテナンス
- サプライヤーおよび契約の評価と選択
- サプライヤーと契約の分類とリスク評価
- 契約のレビュー、更新、終了
- 契約の策定、交渉、合意
- 標準契約、契約条件の維持
- 契約上の紛争解決の管理
- 下請業者の管理
- サービスとサプライヤーの改善計画の合意と実施
ITIL-サービス移行の概要
*Service Transition* は、新規または変更されたサービスの移行を管理します。 サービス管理プロセスに対するすべての変更が調整された方法で実行されるようにします。目的
サービス移行の目的は次のとおりです-
| Sr.No. | Objectives |
|---|---|
| 1 | Provide a consistent framework for evaluating the service capability and risk profile before a new or changed service is released or deployed. |
| 2 | Establish and maintain the integrity of all identified service assets and configurations as they evolve through the service transition stage. |
| 3 | Plan and manage the capacity and resources required to package, build, test, and deploy a release in to production and establish the service specified in the customer and stakeholder requirements. |
| 4 | Provide efficient repeatable build and installation mechanisms that can be used to deploy releases to the test and production environments and be rebuilt if required to restore service. |
| 5 | Ensure that service can be managed, operated and supported in accordance with the requirements and constraints specified in service design. |
サービス移行の利点
サービスの移行は、以下で説明するようにいくつかのことを改善するのに役立ちます-
- 新しい要件への迅速な適応性
- 合併、合併、買収、サービスの移行の移行管理
- ビジネスの変更とリリースの成功率
- ビジネスの変更とリリースの成功率
- 新規および変更されたサービスのサービスレベルと保証の予測
- 変更中のビジネス要件およびガバナンス要件へのコンプライアンスの度合いに対する信頼
- 推定および改善された計画と予算に対する実際の変動
- 法人顧客スタッフの生産性
- コンポーネントが廃止された場合のソフトウェアおよびハードウェアのメンテナンス契約のタイムリーなキャンセルまたは変更 *変更中および変更後のリスクのレベルを理解する
サービス移行プロセス
サービスの移行に関与するプロセスは次のとおりです-
| Sr.No. | Process & Description |
|---|---|
| 1 |
このプロセスは、移行計画の管理と制御を扱います。 |
| 2 |
Change Management このプロセスにより、変更管理プロセスを確実に管理および制御できます。 また、不正な変更が発生するのを防ぎます。 |
| 3 |
Service Asset and Configuration Management (SACM) サーバー、スイッチ、ルーターなどの構成アイテムのデータベースを保持します。 |
| 4 |
Release and Deployment Management このプロセスは、テストおよびライブ環境へのリリースの移動の管理と制御を扱います。 |
| 5 |
Service validation and Testing このプロセスでは、提供されるサービスの品質を扱います。 |
| 6 |
Knowledge Management このプロセスは、知識の収集、保存、分析、共有を扱います。 |
ITIL-プロジェクト管理
- 移行計画とサポート（プロジェクト管理）*は、予測されたコスト、時間、および品質の見積もり内でメジャーリリースを展開するためのリソースの計画を扱います。
- プロジェクトマネージャーはこのプロセスのプロセス所有者です。*
目的
次の図は、プロジェクト管理プロセスのいくつかの目的を説明しています-
サービス移行戦略は、サービス移行とリソースの割り当てを整理するために、次のいくつかの側面を考慮します-
- サービス移行の目的、目標、目的
- サービス移行のフレームワーク
- コンテキスト、例えば サービス顧客、契約ポートフォリオ
- 基準
- 移行に関与する組織と利害関係者
- 人
- アプローチ
- マイルストーンのスケジュール
- 財務要件
個別のサービス移行の計画
サービス移行計画は、テスト環境にリリースをリリースおよび展開するために必要なタスクとアクティビティを記述します。 実証済みのサービス移行モデルからサービス移行計画を展開することをお勧めします。
サービス移行計画には以下も含まれます
- 管理すべき問題とリスク
- 実行するアクティビティとタスク
- マイルストーン、引渡し、納期のスケジュール
- 各段階での人員配置、リソース要件、予算、およびタイムスケール
- リードタイムと不測の事態
キーポイント
- リリース、ビルド、テスト計画などの下位レベルの計画にリンクされた統合された移行計画が必要です。
- 複数のリリースと展開をプログラムとして管理し、各展開をプロジェクトとして実行することをお勧めします。
計画の見直し
リリースまたは展開を開始する前に、計画を検証し、次の質問をする必要があります-
- すべての関係者によって計画が合意され、承認されているか。 顧客、ユーザー、運用およびサポートスタッフ
- 計画にはリリース日と成果物が含まれており、関連する変更要求、既知のエラーおよび問題を参照していますか？
- サービスデザインは、もはや適切ではないように大幅に変更されていますか？
- ビジネス環境の潜在的な変化は特定されましたか？
- それを使用する必要がある人々はそれを理解し、それを使用するために必要なスキルを持っていますか？
- コスト、組織、技術、および商業的側面への影響は考慮されていますか？
- サービス全体および運用能力に対するリスクは評価されていますか？
- サービスリリースはSDP内にあり、移行モデルが対処する範囲ですか？
ITIL-変更管理
前書き
ITサービスの*変更*は、サーバーの構成の試運転、使用停止、またはアップグレードを指します。
すべての変更は、ITサービスの中断を最小限に抑えて実装する必要があります。
変更管理プロセスは、変更を実装しながら次の側面を扱います-
- 変更の悪影響を調査し、最小化する
- 変更管理プロセスを作成して維持する
- 環境の不正な変更を防止する
- すべての変更の記録を維持する
- すべての変更の実装後レビュー
変更は、変更管理チームによって実装されるのではなく、技術チームによって実装されます。 変更管理チームは、変更のレビューと承認のみを行います。
- Change Managerはこのプロセスのプロセス所有者です。*
キーポイント
- 変更マネージャーは、変更を承認して終了する人です。 彼はまた、それが望ましい結果を満たしているかどうかをチェックします。
- 変更コーディネーターは変更要求を発生させます。
- 変更コーディネーターは、*実装後レポート（PIR）*の変更後にスクリーンショットを送信する必要があります。
目的
変更管理プロセスの目的は以下のとおりです-
変更管理の7つのR
これらは、すべての変更に対して回答する必要がある7つの質問です。 変更の影響、サービスへのリスクと利点を評価するのに役立ちます。
変更の要求（RFC）は、主要な情報源であり、変更活動の触媒です-
- 作成して記録する
- 見直し
- 評価と評価
- 承認する
- Plan
- 座標
- 見直し
- 閉じる
各RFCは、変更の性質とタイプに適した特定の変更モデルに従います。
モデルを変更する
以下に説明するように、基本的に3つの変更モデルがあります-
標準変更モデル
このモデルは、事前承認された反復的で低リスクで十分にテストされた変更に使用されます。
通常変化モデル
このモデルでは、変更は実装、評価、承認、変更諮問委員会（CAB）契約などの特定の手順を経る必要があります。
緊急変更モデル
この変更モデルは、失敗した高可用性サービスの障害を復元するために必要な非常に重要な変更を処理します。
変更諮問委員会（CAB）は、変更を承認し、変更管理と変更の評価と優先順位付けを支援する機関です。
サービス資産と構成管理
資産の概要
- 資産*は、減価償却率が付加された財務的価値を持つものです。 コストがあり、組織はそれを資産価値の計算に使用します。
サービスの提供に直接的な影響はありません。 サーバー、建物、ブラックベリー、スイッチ、ルーターなどのあらゆるもの。 資産の下にあります。
構成アイテム（CI）
- 構成アイテム*はサービス資産のサブセットであり、サービスの提供に直接影響します。 実動に影響を与えるすべてのサーバー、ネットワーク、アプリケーションは、構成アイテムと呼ばれます。
- Buildingはアセットですが、CIではありません。 ドキュメントはアセットではなくCIです。*
したがって、* Service Assets and Configuration Management（SACM）*は、他のサービス管理プロセスでも利用可能なすべての資産およびCIの最新の検証済みデータベースの維持を扱います。
- Configuration Managerはこのプロセスのプロセス所有者です。*
SACMは、1つ以上の構成管理データベース（CMDB）を含む構成管理システム（CMS）を使用します。
CIタイプ
CIは、次の図に示すように6つに分類されます-
サービスライフサイクルCI
サービスライフサイクルCIは、次の明確な画像を提供します-
- サービス内容
- サービスはどのように提供されますか？
- どのようなメリットが期待されますか？
- サービス費用
サービスCI
サービスCIの参照-
- サービスモデル
- サービスパッケージ
- リリースパッケージ
- サービスリソース資産
- サービス機能資産
組織CI
組織CIは組織の内部にありますが、サービスプロバイダーからは独立しています。
内部CI
個々のプロジェクトによって提供されるCIは、内部CIと呼ばれます。
外部CI
外部CIは、外部顧客の要件と契約、サプライヤーからのリリース、外部サービスを指します。
インターフェースCI
これらのCIは、Service Provider Interface（SPI）を介してエンドツーエンドのサービスを提供するために必要です。
構成管理システム（CMS）
*SACM* は、1つ以上の*構成管理データベース（CMDB）*を含む*構成管理システム（CMS）*を使用します。 データベースには、サプライヤ、コスト、購入日、ライセンスおよび保守契約の更新日などのCIに関連する情報、およびSLAなどのその他の関連文書が含まれています。次のような構成アイテムには他の属性もあります-
- 一意の識別子
- CIタイプ
- 名前/説明
- 供給日
- ロケーション
- 状態
- ライセンスの詳細
- 関連ドキュメントマスター
- 関連ソフトウェアマスター
- 歴史的なデータ
- 関係タイプ
- アプリケーションSLA
- サービス資産と構成プロセス
SACMプロセスは、次の5つのアクティビティで構成されます-
- 管理と計画
- 構成の識別
- 構成管理
- ステータスのアカウンティングとレポート
- 検証と監査
上記のアクティビティのすべては、次の図に記載されています-
ITIL-リリースおよび展開管理
- リリースおよび展開管理*には、ライブ環境での新しいソフトウェアおよびハードウェアコンポーネントの計画、設計、構築、テスト、および展開が含まれます。 正しいリリースを展開することにより、ライブ環境の整合性を維持することが重要です。
- Release Managerは、このプロセスのプロセス所有者です。*
キーポイント
- リリースユニットは、一緒にリリースする必要があるITインフラストラクチャの一部を指します。
- リリースパッケージでは、パッケージ内の各ソフトウェアは、パフォーマンスがグループ内の他のソフトウェアに依存しています。
目的
リリースおよび展開管理により、次のことが保証されます−
- 変更をより迅速かつ最適なコストで提供し、リスクを最小限に抑える
- リリースパッケージの展開がスケジュールどおりに成功しました。
- 新規または変更されたサービスは、合意されたサービス要件を提供できます。
- 顧客とユーザーがビジネス活動をサポートするためにサービスの使用を最適化できるようにするための知識移転があります。
- 本番サービス、運用およびサポート組織への予測されない最小限の影響。
- 顧客、ユーザー、およびサービス管理スタッフは、サービス移行の実践と成果に満足しています。
特定のリリースのタイプに対して適切なリリースパッケージタイプを定義することが重要です。
次の図は、リリースパッケージの例を示しています-
リリースおよび展開管理プロセス
リリースおよび展開管理プロセスに含まれるアクティビティは次のとおりです-
リリース管理サポート
リリースの展開に関するガイドラインとサポートを提供します。
リリース計画
このプロセスの目的は、承認済みの変更をリリースパッケージに割り当てることです。 また、リリースの範囲も定義します。
リリースビルド
このプロセスはリリースの構築を扱い、すべてのコンポーネントがテスト段階に入る準備ができていることを確認します。
リリース展開
このプロセスの目的は、ライブ環境に新しいリリースを展開し、エンドユーザーと運用スタッフ向けのトレーニングを手配することです。
早期サポート
このプロセスの目的は、リリース展開後の初期期間に運用上の問題を解決することです。
リリース閉鎖
このプロセスでは、アクティビティログとCMSの内容が最新かどうかを確認した後にリリースを終了します。
ITIL-サービスおよび検証テスト
概要
テスト環境を積極的に維持して、展開されたリリースが顧客の期待に応えることを確認し、IT運用が新しいサービスをサポートできることを確認する必要があります。
- Test Managerはこのプロセスのプロセス所有者です。*
次の図は、ライフサイクルのサービス移行段階までのサービステストの例を示しています。
ITIL-サービス操作の概要
サービス運用により、SLAに従ってサービスが効率的かつ効果的に提供されます。 これには、サービスの監視、インシデントの解決、リクエストの実行、運用タスクの実行が含まれます。
キーポイント
- サービス操作には、5つのプロセスと4つの機能が含まれます。
- サービス運用では、サービスを提供するために使用されている日常のアクティビティとインフラストラクチャを扱います。
- サービスオペレーションでは、すべての設計および移行計画が実行され、測定されます。 *顧客の観点から見ると、サービス運用は実際の価値が見られる場所です。
サービス運用プロセス
サービス操作には、次の表で説明する合計5つのプロセスが含まれます-
| Sr.No. | Process & Description |
|---|---|
| 1 |
このプロセスの目的は、すべてのCIが常に監視されるようにすることです。 また、適切なアクションを決定するために、イベントをフィルタリングおよび分類します。 |
| 2 |
Incident Management インシデント管理の目的は、サービスを可能な限り早期に前の段階に復元することです。 |
| 3 |
Request Fulfillment このプロセスは、パスワードの変更、新しいユーザーの作成、メールIDの作成などのリクエストの処理を扱います。 |
| 4 |
Access Management このプロセスでは、許可されたユーザーにサービスを使用する権利を付与します。 |
| 5 |
Problem Management このプロセスは、問題の根本原因を見つけ、インシデントが再び発生するのを防ぎます。 |
サービス運用機能
サービス操作は、次の図に示すように4つの機能で構成されています-
サービスデスク
サービスデスクは、最初の単一の連絡先です。 これは、顧客満足度において重要な役割を果たします。 エンドユーザーとITサービスプロバイダーチーム間のアクティビティを調整します。 また、ログに記録された要求を所有し、これらの要求を確実に閉じます。
サービスデスクには4つのタイプがあります-
中央サービスデスク
これには、中央のサービスデスクが1つしかありません。
ローカルまたは分散サービスデスク
費用はかかりますが、ユーザーに近いです。 管理と維持が困難です。
仮想サービスデスク
非常にコストがかかり、処理が高速になります。
専門サービスデスク
特定のクエリ専用の熟練したスタッフが含まれます。
IT運用管理
この機能は、組織の日常的な運用活動の管理を担当します
技術管理
技術管理スタッフには、ITインフラストラクチャ全体の管理を担当する技術専門知識が含まれます。
アプリケーション管理
アプリケーション管理は、サービスのライフサイクル全体を通してアプリケーションとソフトウェアを管理する責任があります。
ITIL-イベント管理
概要
イベントは、ITサービスの提供にとって重要な検出可能な発生として定義されます。 イベントは、構成アイテム（CI）または監視ツールによって作成されます。
- イベント管理*により、すべてのCIが常に監視され、これらのイベントを分類するプロセスを定義して、必要に応じて適切なアクションを実行できるようにします。
- IT Operation Managerは、このプロセスのプロセス所有者です。*
イベント管理は、次の側面に適用することができます-
- 構成アイテム（CI）
- セキュリティ
- 環境条件（例： 火災と煙の検出）
- 通常の活動（例： アプリケーションの使用またはサーバーのパフォーマンスの追跡）
- 法的ライセンスの使用と割り当てを保証するための使用法のソフトウェアライセンス監視
以下に説明するように、監視ツールには2つのタイプがあります-
アクティブな監視ツールは、CIのステータスと可用性を監視します。 通常の運用からの逸脱は、適切なチームに伝えられて行動します
- 受動的な監視ツールは、CIによって生成された操作上のアラートまたは通信を検出および相関させます。
イベント管理プロセス
イベント管理プロセスは、次の図に示すように自己記述的です-
利点
イベント管理のいくつかの利点はここにあります-
- インシデントを早期に検出するのに役立ちます。 したがって、サービス停止が発生する前に、インシデントを適切なチームに割り当てることができます。
- 高価でリソース集約的な監視の必要性がなくなります。
- また、可用性管理や容量管理などの一部のサービス管理プロセスにも適用できます。 適切なチームが早期に対応できるようにステータスが変化すると、自動的に信号を生成します。
- 自動化されているため、効率が向上します。
インシデント管理とリクエストの履行
概要
インシデントは、ITサービスの中断として定義されます。 インシデントは、サービスデスクまたはイベント管理からインシデント管理ツールへのインターフェースを介して報告できます。
*Incident Management* はインシデントの処理を扱い、できるだけ早くITサービスを復元します。- Incident Managerはこのプロセスのプロセス所有者です。*
インシデントモデル
常に新しいものではないインシデントがいくつかあります。 それらは一定期間にわたって再び発生する可能性があります。 したがって、このようなインシデントを処理するための事前定義モデルを用意することをお勧めします。
インシデントモデルには以下が含まれます-
- インシデントを処理するために取るべき手順
- 依存関係またはコプロセッシングを定義して、これらの手順を時系列で実行する必要があります。
- 責任-誰が何をすべきか
- アクションの完了のタイムスケールとしきい値
- エスカレーション手順;誰に連絡すべきか、いつ
- 必要な証拠保存活動
インシデント管理プロセス
次の図は、インシデントが発生したときに実行するいくつかの標準的な手順を示しています-
インシデントログ
すべてのインシデントは完全に記録され、日付/時刻が記録される必要があります。
インシデントの分類
後でインシデントタイプ/頻度を調べて、問題管理で使用する傾向を確立することが重要です。
インシデントの優先順位付け
インシデントの重大度（低、中、高）を扱います。
インシデント診断
Service Deskのアナリストは、ユーザーが通話中に初期診断を実行し、インシデントの完全な症状を発見し、何が間違っているのかを正確に判断し、修正する必要があります。
インシデントエスカレーション
インシデントエスカレーションのさまざまな側面は次のとおりです-
機能エスカレーション
Service Deskがインシデントを解決できないことが明らかになった場合、またはService Deskの目標時間を超えた場合、さらなるサポートのためにインシデントを直ちにエスカレーションする必要があります。
階層的エスカレーション
階層的なエスカレーションは、いずれかのインシデントが本質的に深刻な場合、または「調査と診断」に時間がかかりすぎる場合に行われます。
調査と診断
次のアクティビティが含まれています-
- 何が間違っているのかを正確に理解する。
- イベントの時系列の順序を理解する
- インシデントの完全な影響の確認
- インシデントを引き起こした可能性のあるイベントを特定する
- 以前の同様の種類のインシデントの検索
解決と回復
潜在的な解決策を特定し、適用し、テストする必要があります。
インシデントの閉鎖
インシデントをクローズする前に、サービスデスクはユーザーに満足しているかどうかを尋ね、インシデントをクローズすることに同意する必要があります。
フルフィルメントのリクエスト
サービスリクエストとは、ユーザーからの要求を指します。 これらの要求には、小さな変更、パスワードの変更、追加のソフトウェアアプリケーションのインストール、情報の要求などが含まれます。
- インシデントは計画外のイベントですが、サービスリクエストを計画できます。*
キーポイント
- 通常、組織には、サービスリクエストの数に応じて、それらのリクエストを満たすために結成できる専門チームがいます。
- 頻繁に繰り返されるリクエストの場合、リクエストを満たすために事前定義されたモデルを考案できます。
ITIL-問題管理
ITILでは、*問題*は1つ以上のインシデントの原因不明として定義されています。
*Problem Management* は問題の特定を保証し、根本原因分析を実行します。 また、繰り返し発生するインシデントを最小限に抑え、問題を防ぐことができます。- Problem Managerはこのプロセスのプロセス所有者です。*
キーポイント
- 問題管理は、インシデントの根本原因を診断し、それらの問題の解決策を決定するために必要なアクティビティで構成されます。
- 根本原因分析後に問題が解決されると、既知のエラーになります。
- Problem Managementは、* Known Error Database（KED）*と呼ばれるシステムの問題に関する情報も記録します。
問題管理は、次の2つのプロセスで構成されます-
- リアクティブな問題管理は、サービス操作の一部として実行されます。
- プロアクティブな問題管理はサービス運用で開始されましたが、通常は継続的なサービス改善の一環として推進されます
問題管理プロセス
次の図は、問題管理に関連するアクティビティを示しています-
問題検出
問題は次の方法で検出できます-
- テクニカルサポートグループによるインシデントの分析。
- アラートツールを自動的に使用して、問題管理の必要性を明らかにする可能性があるインシデントを発生させる、インフラストラクチャまたはアプリケーションの障害の自動検出。
- 解決する必要がある問題が存在するというサプライヤからの通知。
問題のログ
問題は完全に記録される必要があり、次の詳細が含まれています-
- ユーザーの詳細
- サービスの詳細
- 設備の詳細
- 優先度と分類の詳細
- 最初に記録された日付/時刻
問題の分類
問題の真の性質を追跡するには、インシデントと同じ方法で問題を分類する必要があります。
問題の優先順位付け
問題は、インフラストラクチャの観点から問題がどれほど深刻かを識別するために、インシデントと同じ方法で分類する必要があります。
回避策
それは困難を克服するための一時的な方法です。 回避策の詳細は、常に問題レコード内に文書化する必要があります。
既知のエラーレコードの発生
既知のエラーは、後で参照できるように既知のエラーデータベースに記録しておく必要があります。
問題解決
解決策が見つかったら、適用して問題の詳細とともに文書化する必要があります。
問題のクローズ
閉鎖時に、記録にすべてのイベントの完全な履歴記述が含まれていることを確認するためにチェックを実行する必要があります。
主要な問題のレビュー
次のもののレビューを行う必要があります-
- 正しく行われたもの
- 間違っていたもの
- 将来的にもっと良くできること
- 再発を防ぐ方法
ITIL-アクセス管理
概要
- アクセス管理*は、許可されていないユーザーへのアクセスを防止しながら、許可されたアクセスへのアクセスを許可します。
- Access Managerはこのプロセスのプロセス所有者です。*
キーポイント
- アクセス管理は「権利管理」または「アイデンティティ管理」とも呼ばれます。
- アクセス管理プロセスは、技術およびアプリケーション管理機能によって実行されます。
- アクセス管理は、サービスデスクを介したサービスリクエストによって開始できます。
ビジネスへの価値
アクセス管理は、次の方法でビジネスに価値を追加します-
- 従業員は仕事を効果的に実行するための適切なレベルのアクセス権を持っています
- サービスの使用を監査し、サービスの不正使用を追跡する機能。
- サービスへのアクセスを制御することにより、組織は情報の機密性をより効果的に維持できます。
アクセス管理プロセス
次の図に示すように、アクセス管理に関係するアクティベーションは自明です-
ITIL-CSIの概要
- 継続的サービス改善（CSI）*は、過去の成功と失敗から学習することにより、サービスの品質を改善するために講じられる措置を扱います。 その目的は、変化するビジネスニーズに対する改善を特定して実装することにより、変化するニーズに合わせてITサービスを調整および再調整することです。
目的
継続的なサービス改善のいくつかの目的は次のとおりです-
- 各ライフサイクルフェーズで改善の機会を確認および分析します。
- サービスレベルの達成結果を確認および分析します。
- 顧客満足度を犠牲にすることなく、ITサービスを提供する費用対効果を改善します。
- ITサービスの品質を向上させるために、個々のアクティビティを特定して実装します。
- 継続的な改善活動をサポートするために、適用可能な品質管理方法が使用されていることを確認します
CSIをサポートする活動
CSIをサポートするアクティビティは自動的には行われないため、責任を処理し、適切な権限を処理して物事を実現できるIT組織内で所有する必要があります。 継続的なサービス改善をサポートする活動は次のとおりです。
CSIプロセスモデル
CSIに関与する手順は、次の図に記載されているように自明です-
利益の視点
CSIの結果を議論する際に考慮される利点の4つの視点を次に示します-
改善
これは、現在のサービス状態の結果と以前の結果の比較です。
利点
それは改善の実現を通じて達成される利益です。
投資収益率
それは、利益とその利益を達成するために拡大された金額の違いです。
投資価値
それは、非金銭的または長期的な結果を含む利益の確立によって生み出される特別な価値です。
ITIL-サービスレポート
サービスレポートは、サービスレベルに対する成果と傾向のレポートの作成と配信を扱います。
顧客と合意した形式、コンテンツ、頻度に従ってレポートを生成することをお勧めします。
次の図は、サービスレポートプロセスの全体的な流れを示しています-
