こんにちわ、あるいはこんばんわ。
どこかで見たマンガの冒頭から失礼します。
ITSMを人に説明する機会が増え、その結果、説明しながら気が付いた点が多々あり、それを備忘的にかつ自分の理解のさらなるブラッシュアップのため、改めて記載させていただければと考えた次第です。本日はさわりです。さわりのみで3000文字。。
すみませんが、どうぞお付き合いください。
1.プロセスがプラクティスに変わった理由
そもそも、ITILv3からITIL4にバージョンアップした際、「Information Technology Infrastracture Library version 3( 2011 Edition)」から、「ITIL 4」というように「ITインフラの書籍群」という立ち位置から「ITSMの教科書」として独立したのです。ここには歴史がかかわります。
事実、v2時代からプロセス原理主義的で官僚的であるという指摘は言われていました。そんな重厚長大なプロセスを整備しても、ビジネスのスピードを止めるだけだ！という指摘ですね。
おっしゃる通りです。そこでv3からは少しプロセス原理主義のトーンは控えめになりました。具体的には、それぞれの頭文字をとって4Pとなり、プロセスは4つの構成要素の一つになりました。つまり、プロセスの影響力は1/4に薄まりました。
今回のITIL4では、4Pをさらに拡張し、4つの側面(便宜的に4Dと表現します)の中のたった一つの構成要素になり、プロセスの占める割合は1/8にまで低下しました。プロセスを軽視しているわけではありません。
これは、プロセスだけを整備しても、ITSMを実装できる時代ではなくなったということです。ITSMの目的である「適切なコストとリードタイムでユーザに価値あるサービスを届ける」ことにフォーカスした時に、処理の手順や手続きを定めたプロセスだけではその目的が達成できないということです。決してプロセス軽視ではなく、ITILv2の時代よりも、求められるものがより高度化したということです。
昔はとにかく作り、提供さえすればユーザは満足してくれました。しかし、ユーザは品質や価格についてシビアになってきた。さらに競合が増え、ただサービスやプロダクト(製品)を作っても顧客が付かなくなった。
より真にユーザの満足度を測り、かつそれが妥当なコストであることを計っていかないと過剰コストで儲けがなくなったりしてしまう。つまりは倒産してしまう。サービスやプロダクトを作るうえで必要となる要素を明確に定めそれぞれを有機的に結び付けていかないといけなくなった。それにはプロセスだけを整備するのでは足りなくて、それぞれの4つの側面に作用するプラクティス(知見・ノウハウ・ナレッジ)として定義する必要があった。
ゆえに、プラクティスに変化したのです。「組織と人材」「情報と技術」「パートナとサプライヤ」「バリューストリームとプロセス」それぞれを有機的に結び付けかつ効率的に組み合わせる。そのためのナレッジ集それがプラクティス、というわけです。「ITIL4」という固有名詞に変更したのは、そういった背景があります。
こちらは、第2回でより深く語ります。
2.プラクティスを大きく3つに大別したの背景と理由
ITILv3からITIL4に切り替わった際、いくつかのプロセスは分割し、または統合しました。さらに、今まではITIL単体として確立させたプロセスだったものを、
- ITサービス管理として特に使うもの→「サービスマネジメントプラクティス」
- ビジネス全般に対して汎用的に使うもの→「一般的マネジメントプラクティス」
- ITサービスを構成するテクノロジの管理に使うもの→「技術的マネジメントプラクティス」
という大きく3つに分類しなおしました。
ITILは、サービスを「製造」・「管理」するうえで、「ITに寄らず使う汎用的な部分」や「進化の激しい開発や運用管理」の部分を切り出し、誰のためのプラクティスなのかを明確にしました。
ITIL4は、ITILv3で言われていた価値の創出の部分は自分たちで定義し、汎用的な管理部分や開発・運用の部分はもっと詳しいフレームワークがあるからそっちも使ったり取り込んだりするよ、と自分たちの限界を認めたわけです。
餅は餅屋。既に得意なフレームワークがある領域は積極的にその知識を借り、自分たちが得意とする「価値の創出に関わるプラクティス」と「価値の創出に関連する汎用的、または開発や運用に関わる繋ぎのプラクティス」部分に特化したフレームワークとなって、それ以外の部分は自分たちで定義しない、という方向性に切り替えました。
こちらは、第3回でより深く語ります。
3.分割、または統合したプラクティスの背景と理由
大きく3つの領域のプラクティスに分けたことによりあることが明確になりました。それは、価値の提供に重きを置いたときに重視すべき項目です。
プラクティスにおいて、より詳細に定義したり優先順位をつけることが可能になったということです。
これはもう実際に見たほうが早いです。
「リリース管理及び展開管理プロセス」は、、、
- サービスマネジメントプラクティスの「リリース管理」
(かつ、移行の計画立案及び支援プロセスの一部を吸収) - 技術的マネジメントプラクティスの「展開管理」
「サービス資産管理及び構成管理プロセス」は、、、
- サービスマネジメントプラクティスの「サービス構成管理」
- サービスマネジメントプラクティスの「IT資産管理」
「技術管理機能」は、、、
- 一般的マネジメントプラクティスの「アーキテクチャ管理」
- 技術的マネジメントプラクティスの「ソフトウェア開発及び管理」
(尚、アプリケーション管理機能と統合) - 技術的マネジメントプラクティスの「インフラストラクチャ及びプラットフォーム管理」
(尚、IT運用管理機能と統合)
「サービスレベル管理プロセス」は、、、
- サービスマネジメントプラクティスの「サービスレベル管理」
- 一般的マネジメントプラクティスの「測定及び報告」
このように分割、または統合しました。
これらの変化は全てユーザへの価値提供に重きを置いた結果、今の時代にそぐわないプロセスや機能を統廃合した結果です。
こちらは、第4回でより深く語ります。
4.名前が変わっちゃったプラクティスの背景と理由
ユーザへの価値提供に重きを置いた際、やることが純増したり、スコープが拡大したプラクティスがこちらです。名前がそぐわなくなったわけです。
こちらも、百聞は一見に如かずということで。。
- 需要管理が、サービスマネジメントプラクティスの「事業分析」に
- デザインコーディネーションが、サービスマネジメントプラクティスの「サービスデザイン」に
- キャパシティ管理が、サービスマネジメントプラクティスの「キャパシティおよびパフォーマンス管理」に
- 変更管理がサービスマネジメントプラクティスの「変更実現」に
- イベント管理が、サービスマネジメントプラクティスの「モニタリングおよびイベント管理」に
- 要求実現がサービスマネジメントプラクティスの「サービス要求管理」に
- ITサービス継続性管理がサービスマネジメントプラクティスの「サービス継続性管理」に
というように、内容をアップデートしたため、名が体を表すように変更されたものも多数あります。
こちらは第5回でより深く語ります。
さて、本日はさわりだけですが。改めて学ぶとこれは深い。一つずつ丁寧に自分も学びながらアウトプットをブラッシュアップしてまいります。どうぞよろしくお願い申し上げます。
