ITILをゼロから導入するなら、サービス資産・構成管理（SACM）を最前線で活躍させるでしょう。これは、ITIL V3における他のすべてのプロセスおよびサービスライフサイクルフェーズを網羅する数少ないプロセスの一つです。効率的なSACMがなければ、残りのプロセスの有効性は深刻な危機に瀕するでしょう。
サービス資産および構成管理の概要
SACM は、共通プラットフォーム上で動作する 2 つのプロセス (資産管理と構成管理) の組み合わせですが、これらは個別のプロセスとして処理できます。
資産管理は、所有権の変更、物理的な移動、委託、廃止、処分などのサービス資産の物流を扱います。
構成管理は、サービスの設計アーキテクチャと密接に連携します。構成アイテム（CI）間の関係を描き出すことで、インシデントの解決、変更やリリースの追跡、問題の根本原因の特定、技術サービスカタログの作成に不可欠な役割を果たします。
構成管理は他のプロセス、特にサービス運用プロセスと依存関係にあるため、まず構成管理を実装することが理にかなっています。これは、安定したITサービス管理環境を構築するための基盤となります。
構成管理計画（CMP）
以前、サービスマネジメントプランについて説明しました。これはサービスのあらゆる側面を網羅した文書で、サービスの実装前に作成されます。同様に、構成管理を効果的に実行するためにも、プロセスを導入する前に計画が必要です。
構成マネージャーは構成管理プロセスを所有し、計画の草案作成にも責任を負います。
CMP の基本的なコンポーネントは次のとおりです。
1. スコープ– スコープを定めずに計画を開始してはいけません。自分の範囲を把握することが重要です。CMPの場合、組織には数百ものサービスがあり、そのうち数十のサービスを担当している可能性があります。この計画の対象となるサービスと対象外のサービスを書き留めておきましょう。多くの人が暗黙的に記述されていると感じていますが、すべてを文書化しておくことをお勧めします。2
. 参照– 構成管理者は、サービスアーキテクト、サービスオーナー、チームマネージャーなど、スコープ内のサービスについて知見のあるほぼすべての人から情報を取得します。収集されたデータは、構成管理データベース（CMDB）にまとめられ、検証され、再構築されます。
データソースの妥当性を確保し、正当な所有者を明確にするために、サービスに対するデータソースをリストアップした参照セクションが必要です。これにより、構成管理者は疑問が生じた場合に、適切なソースを特定しやすくなります。私なら、さらに一歩進んで、受信したデータとメールを計画書に添付します。
3. CI の命名法– すべてのサービスアセット、つまり CI には、一意の識別子が必要です。サーバーの場合は、SRV123 のような識別子でも、単に 123 のような識別子でも構いません。どちらも役に立ちますが、どちらが効果的でしょうか？後者の場合、CI 名を見て、どのテクノロジーに該当するかを大まかに推測できるでしょうか？いいえ。CI の名前は、一目見ただけで、その CI の種類、場所、複雑さ、その他の属性など、大体の情報がわかるようにするのが理にかなっています。
実装中に、私はCIに次のように名前を付けました。
<CI の種類 – サーバー、ルーターなど>-<場所>-<複雑さ>-<実行シーケンス>
したがって、ルータには RTR-LOC-L3-12345 のようなものが存在します。
サービスデスクのような、能力レベルが最も低いチームは、独自に意思決定を行うことができます。上記の例では、CIをルーターとしてデコードし、特定の場所に設置してL3サポートチームに処理させることも容易に可能です。つまり、L3チームが問題解決に直接関与することで、実質的にシステム停止は最小限に抑えられ、いくつかの機能エスカレーションも回避できます。
同僚のコンサルタントが一歩先に進み、CIにそれを所有するチーム名をハードコードしました。私が唯一反対したのは、別のチームが所有権を引き継いだ場合、つまり組織再編のシナリオでCI名がどうなるかということでした。彼らはCIに最初から名前を付け直すことになるでしょうか？
4. ベースライン– CMDBの定期的なベースライン設定は、少なくとも1年前からスケジュールする必要があります。ベースラインとは、将来的に差分を比較するための基準となるものです。
多くの組織では、クリスマスとイースターの2回の変更凍結を実施しています。変更凍結期間中にベースラインを取得し、必要に応じて分析を行うのが適切だと私は考えています。
5. 変更管理– 構成管理は変更管理プロセスと密接に関連しています。有効な変更チケットがなければ、構成情報（CI）に変更を加えることはできません（もちろん、変更はできません）。つまり、変更管理はCMDB上の構成情報（CI）への変更を管理するのです。
CMPは、変更管理プロセスが構成管理プロセスとどのように連携するかを規定する必要があります。また、変更活動のどの時点で構成管理プロセスが呼び出されるかについても規定する必要があります。
6. 検証と監査– CIデータの正確性は極めて重要です。正確性を維持するためには、複数の検証と監査が必要です。
検証プロセスは構成管理者によって定期的に実行され、主にツールベースで行われます。最新のツールは、CIデータの検証に役立つレポートを提供できます。例えば、すべてのCIに10個のフィールドがある場合、CMDBツールは、完全に入力されていないCIのレポートを取得できます。また、CI1がCI2の親であると宣言しているにもかかわらず、CI2がCI1の子であると宣言していない場合、これは不一致として記録され、構成管理者が使用できるレポートの1つに反映されます。
一方、監査は通常、構成管理者またはそのチームメンバー以外の担当者によって実行されます。監査では、一定数のCIがサンプルとして抽出され、実際の値とランダムに比較されます。
SRV-DC1-L2-234 が監査対象になるとします。監査担当者はまず、この CI がサーバーであるかどうか、そして CMDB に記録されている通り、データセンター DC1 のラック 121 に配置されているかどうかを確認します。また、データベースに記録されている通り、サーバーに Windows 2003 が搭載されているか、2GB の RAM が搭載されているかなど、その他の属性も確認します。
調査結果に基づいて監査レポートが作成され、構成マネージャーは、不一致の程度 (ある場合) に応じて重大なまたは軽微な非準拠 (NC) を受け取ります。
まあ、これが監査の仕組みですが、監査をどのくらいの頻度で実施する必要があるか、誰が実施するか、どの程度の不遵守で重大なタグが設定されるか、 重大な NC が突きつけられた場合に構成マネージャーがどのような措置を講じるかなど、監査のあらゆる側面が CMP に記録される必要があります。
結論
私にとって、この 6 つのセクションがすべてであり、導入、目的、役割と責任、定義、トレーニングなどの残りのセクションは単にページを埋めるためのものであり、各自の判断で行う必要があります。
プロセスを徹底的に検討し、プロセス計画がプロセスが本来果たすべき役割を果たしているかを視覚化することが重要です。KPI要件、そして最も重要な顧客要件を満たしていますか？
私の提案についてご質問がありましたら、お気軽にお声をかけてください。喜んでお手伝いさせていただきます！
