CMDBはITサービス運用に大変重要であることは前回お話ししました。

また、CMDBはどうやらITシステムを直接的に運用管理しているチームだけの課題にしてはいけないこともご理解いただけたかと思います。

ITリソースは確かに管理するのはシステム管理側かも知れませんが、現代において組織内のITリソースの状態の影響は、社内外すべての関係者におよぶものになっているのではないでしょうか。

したがってCMDBの整備はITシステム管理部門だけの課題ではなく、全組織横断的な課題になるべきですが、だからこそ上手くいかない事もあります。

CMDBのメリットは理解しているのに、そこから価値を得られないという状態になるのです。ではその要因はなんなのでしょうか。

用途が限定されてしまった

組織横断で一元化されるはずのCMDBですが、扱う情報の多くはITリソースに関する物であるため、IT部門の一部だけで検討し決算する可能性はあります。

このような場合、予算が限られたり、ニーズが限定的になって偏ったりします。

結果として、柔軟性のないテーブル構造のデータベースを作成してしまったり、資産のリポジトリに過ぎないCMDBツールを採用してしまう、といった現象が起こります。このようにして作られたもの、敢えてインベントリと呼びますが、は、検討した部門だけが利用するようカスタマイズされてしまい、いざ他の用途に使おうと思っても上手くいかず、全社的には単なるコストとしてしか見られなくなってしまいます。

正確ではない

組織横断で一元化されるCMDBには正確性が求められます。

いざ参照したときに、その情報が古かったとか間違えていたとか必要な情報が入っていないとなると、どうでしょうか。

そのようなデータを元に行われた作業は、時に重大な間違いを誘発します。

それでなくてもあれを見てもしょうがないと思われてしまえば使われなくなっていきます。

正確で最新の状態を反映していることが求められますが、これを維持していくことは特に主導のプロセスが介在するとなかなかに難しい課題でもあります。

一元化に対する過度な期待

CMDBはITリソース情報の信頼できる唯一の情報源として存在しますが、すべてのデータがここになければいけないというわけではありません。

矛盾しているようですが、ありとあらゆるデータを載せる事を前提にすると、単一の業務にだけ必要な特別なデータのためにそのほか多くの業務が阻害されることもあります。

例えばそのような必ずしも必要の無いデータが集まらないためにいつまでも利用開始が出来ないとか、その情報を入れるために実施した拡張の為にその他の連携するデータとの整合性がとれないとか。

CMDBをどのように使うのか、どのようなビジネスプロセスで必要とされるのかを考慮し、それらをサポートする有益で重要なデータが何かを定義することも重要です。

使われなくなってもニーズがあるとなると、別の断片が生まれます。そうしてまたプロセスが分断し、情報のサイロ化が起こるでしょう。こうなってしまうとデジタルによる変革は難しくなってしまいます。

ですから、一見遠回りに見えるかも知れませんが、これらの問題に陥らない方法をとり、着実に進めていく必要があるのです。

次の回からそれぞれについてより掘り下げてみたいと思います。