色々なユーザー企業の相談を受けると、多くのユーザー企業で一部の CMDBが塩漬けコースをたどるパターンが明らかに見受けられる。
CMDBのベンダーに「IT資産管理もできますよ」とそそのかされて導入してはみたものの、実際にデータセンターなどのソフトウェアライセンスの管理を行おうとすると、ユーザーの負担が大きく、維持ができないのが大きな原因だ。
では、なぜ、このような塩漬けコースのパターンができたのかを少し考えてみよう。
そもそも、IT環境のCI（構成アイテム）はITIL のサービス資産という定義から考えると非常に膨大だ。実際に今まで管理対象としてきたハードから、ソフトウェア、ソフトウェアのコンポーネント、契約やドキュメント、購入情報などの金額（コスト）や人的能力、社内保有プロセスなど、ITサービスを構成する CI は数知れない。
ソフトウェアをとっても、ソフトウェアメーカーとの使用許諾契約によりライセンスされる製品、社内開発製品としてのコンポーネントの管理、OSSなど性質や管理メトリックスが異なるソフトウェアが存在する。
構成管理のためのCMDB は、これらすべてを対象にCI として設計し管理することは可能だが、目的によって、必要となるテーブルや管理項目が異なり、ライブラリを参照して管理することが効率化を図るためには必須となる対象 CI などもあり、最初の計画段階で、対象 CI のこれらの性質から契約や条件を考慮した管理メトリックスを定義し、そのメトリックスを管理するために必要十分な自動化のためのテーブルやライブラリを準備するための工数を計算したうえで、どのようなシステムで自動化するかを検討することが大切だ。
なんでもできる CMDB は、必要となるテーブルの定義やライブラリの自社開発、あるいは、これらを使用したレポートや、CI 間の紐づけ処理や突合、整合化、BIA など機能を考えると、ほぼ自社開発ソフトのような取り組みが要求される場合も少なくない。
そんなことになると、結局のところCMDBの維持に数億円という投資が必要となりかねない。
これが、塩漬けコースへのパターンとなっている。
CMDB は、複数あって統合されればよい。
つまり、特化型のCMDB として目的にあったシステムをCMS （構成管理システム）を構成するCMDBとして標準化されたインターフェースで連携できるようなシステムであれば、そのほうがよほど効率的だ。
ソフトウェアライセンスを対象とした特化型のCMDB は Flexera、Snow、Aspera など欧米ではGartner もSLO（Software License Optimization：ソフトウェアライセンス最適化）のツールとして識別している。
ここで重要なのは、これらのSLO（特化型CMDBであるべきツール、つまり、CMDB間連携を可能として、特化分野におけるアドバンテージを提供していること）ツールの対象CIスコープと、汎用CMDBのスコープをすり合わせ、その分界点においてサービスの構成分野を識別、定義し、連携することで２つのツールを統合することを念頭に導入をすすめるべきである。