配置管理的项目可以从 CMDB 的建设开始，也可以从配置管理的流程建设开始。我在一些配置管理的项目中发现了一些用户容易犯的错误有很多。先说说配置管理，做 ITSM 的项目，往往 CMDB 的建设，或者配置管理流程大多不会非常重视，往往作为一种辅助性的环节在项目中得到实施。例如 ITSM 项目一上来就做服务台，然后是变更管理流程和其他流程；在一些后续的资产管理的项目中 CMDB 的到重视并建设。其实配置管理流程和 CMDB 是 ITSM 项目中非常重要的一环，它建设的效果对整体效果有乘法放大的效果。CMDB 的主要功能我认为有两点：
- 提供唯一、精确的配置信息库，让所有IT团队的人都明确IT管理配置项范围，有了它所有人都起码能清楚“我管理的东西是什么有哪些？”。都说ITIL的语言是IT管理的共同语言，那么配置信息就是这个语言的主语和宾语；从这里可以看到，如果我们没有这样一个准确的配置信息库，我们彼此之间的沟通会出现多大的误解和迷惑。我在用户现场做项目的时间比较多，耳闻目睹很多沟通障碍；这些障碍不是沟通方式和技术造成的，而是大家没有能从一开始就说清楚“谈论的CI对象到底是什么”
- 实现一定程度上的业务影响分析。往往都是有IT部门牵头做CMDB，后期也主要是IT部门用。有效的业务影响分析能力，可以彻底提高事件管理的有效性。一般用户可能会有一个集中Event Console，从这个console中事件一般是以生成的时间先后顺序查看和处理的。最差的事件管理方式就是这种“先进先出”的处理应对方式。如果你能说清楚，发生事件的对象（配置项）对业务系统的影响程度，那么你就能够做到按照这些事件的优先级别来处理；事件的优先级就是该事件对业务系统所造成的影响的严重程度。需要做到业务影响分析，就必须做业务模型梳理。每一个业务服务和业务流程也是配置项，IT的人也需要能理解业务。
下面列出一些常见错误，这些错误发生在企业做ITSM项目的前后都有可能，不过多是在实施ITSM项目之前，或者上CMDB工具之前，或者过程中。1）目标不明确，实施结果无法衡量 Goal所谓目标不明确，并不是说没有目标，而是说：目标定的不太合理。不合理的原因有一下几种：目标过大、目标过于模糊、过于教条、拘泥于ITIL的书本、和实际的工作联系不紧密、没有衡量和控制的方式。在一定的项目时间周期内，总结之前配置管理的问题，作出一个切实可行的配置管理数据库建立目标应该不难，主要以使用为主，不要拘泥于细节。2）配置项信息混乱，信息结构无序 Scope这里的“信息结构”是说CMDB的CI配置项信息查看应该是立体的有结构的很直观的数据信息。在访谈的过程中，有些用户在讨论过程中认为配置项组成的信息结构应该是网状的。其实现实中的IT基础架构组件的确是以网状的形式相关联的，这种想法非常实际。不过人们都太偏重IT了，遗忘了IT部门的最终使命“为企业交付各种业务服务”。业务服务就是CMDB数据金字塔的顶端部分。从IT部门提供的业务服务开始来梳理和建立CMDB配置库是一种“自顶向下”有效方式，是IT部门做CMDB配置管理过程中，与业务部门沟通的“翻译机”。自顶向下的方式需要业务部门的配合，或者IT部门内有精通业务的强人。通过这种方式做出了的CMDB，CI之间的构成方式，从宏观上看：屏幕的投影是树根型的，立体的看是金字塔形的，业务系统模型是树根的根部，是金字塔的顶端部分。微观上看，局部可能是网状的，或者是星型的。没有业务服务作为头部，很难说出CMDB的scope究竟是多大，很难说清楚哪些CI可能会在CMDB中出现。3）配置信息随意堆积，纠缠于过多的CI属性 Level每一个CI都可能具有非常多的属性，成功选择的标准是：够用就好，精简是王。很多用户都存在的误区就是“复杂比简单好，越复杂越放心”；大多数用户在项目初期的需求整理的时候都觉得，需求提的越全面，越好，越保险。这种心情是可以理解的，毕竟ITSM项目的周期和投入通常都是非常多的。不过对于配置管理来说却，万万不能有这种想法；否则，CMDB的维护和审计的工作量将非常巨大。一个信息量过载的CMDB，就是一个不可用的配置库。一个只有10个属性的CI和有50个属性的CI展现在你面前的时候；你找到你所关心的信息花的时间上看，前者是后者的1/5时间。属性一定要精简，特别是CMDB从零开始的用户。在设计的初期一定预留属性扩展的可能性。4）疏于配置信息的准确性和实时性 ** update**CMDB一旦建立了之后，所有用户一定要对CMDB使用起来，要为CMDB提供反馈。最终使用配置信息的人，如果发现信息不准确，需要及时报告配置经理。配置经理需要及时维护。配置经理最重要的职责是，确保每一个大小变更实施完毕之后对要对相关CI做更新。你可以没有正规的变更流程系统去跑变更单，不过我所看到的是很多企业即使没有实施ITSM项目，其实他们手工变更单的流程跑的有板有眼，一点都不差。美中不足的是，变更后的结果没有地方更新和反馈。而CMDB就是这样一个变更结果反馈和汇集的目的地。在大家都频繁使用CMDB，并且每一个大小变更都更新CMDB的完美情况下，CMDB中的信息会随之时间的流逝，愈来愈精确，愈来愈完善。5）拘泥于工具的功能，忽略了最终目标 Tool我看到的最多的工具是MS Excel，也有使用自开发系统的，可有自开发系统最终丁不住在转向商业工具的 :( 无论何种工具，假如在一个正确的事实和使用的策略下，我觉得都是可以获得CMDB建设的成功的。一个好的工具还是有必要的。在选择一个成品工具或者开发一个CMDB工具时，需要考虑工具的几个方面。工具应该参考或者借鉴某种国际标准，这里的标准是指某种通用模型标准 Common Data Model (CDM)，例如DTMF的 Common Information Model (CIM),或者WMI等。好的工具需要能和其他ITSM流程紧密结合，特别是事件管理、问题管理和配置管理者三个流程。如果这三个流程是建立在某种工具平台之上的，那么CMDB的信息最好能无缝的整合的流程的处理过程中。