随着客户对“个性化”的需求越来越强，许多公司都要求根据自身公司的情况定制自己的IT服务管理解决方案，尤其是自己的配置管理数据库CMDB。虽然这些公司的背景大都不同，但在决策时，他们总是在“是否购买一个现成的IT服务管理解决方案，还是自己设计一个解决方案”这样的决策上犹豫不决。为什么如此重视这个决策呢？当然首要原因是成本。虽然购买、实施并对一个商业产品进行参数调试等行为的价格都明码实价的标在标签上，除了无法预测进行ITIL/MOF实施时所要花费的咨询费用外，其它费用合计即使对一个小型的公司来说也不会少于15万美元！如此大的支出，当然会使决策者在制定决策时慎之又慎。那么，你的公司是否需要自建一个个性化配置管理数据库呢？

     现在，我们可以假象一些情景，来考虑这个问题。
 
    情景一：“我们需要自建CMDB，因为我们需要对流程进行重新设计”——WNPD公司的尴尬

    WNPD公司是一家很大的公司，他们对自己的IT服务管理流程有很多特殊的需求。但由于当前的经济问题，使他们购买一个现成的IT服务管理工具可能性不大。于是，他们的IT管理层决定自己实施MOF/ITIL，并已开始着手研究IT服务管理解决方案的实施问题，但他们的研究重点很明确的放在对文档的管理和各种配置项的选择上，而并非是工具的使用！这家公司已经安装了一个大型的软件包，包括有限的工作流能力管理软件如微软的Project软件，Exchange服务器，以及Note软件等，公司还建设了内部网，上了许多内网应用软件。IT经理很担心如果在安装各种软件时花的精力太大，可能会影响到流程设计和ITIL实施时的文档标准设计与文档管理工作，浪费大量的宝贵时间；但同时，组织还是很需要实施这些流程的，于是问题转换为如何使用最简单的工具，如Excel，Access以及Exchange等来创建自己的配置管理数据库。

    关于是否自己设计并实施适合自己的CMDB，实现个性化的IT服务管理流程的意见很多，这里各列举几个反对和赞同意见。

    赞同意见

    ·        实施速度很快，节约时间

    ·        实施的起步阶段费用较低

    ·        可以建立起与当前组织数据库的个性化连接。硬件和软件库存清单可以很快地被查询到，就像存储在系统管理解决方案中的数据那样。

    ·        在为真正的解决方案做出巨额消费前，提前掌握到IT服务管理各功能模块的需求，同时可以使用案例来支持综合IT服务管理解决方案的制定。

    反对意见

    ·        只能提供有限的功能

    ·        用户接口的质量较低

    ·        无法与系统管理工具进行集成

    ·        不充分的解决方案可能会降低管理者和用户对该项目的热情和支持

    ·        一些看似容易但却很难实现的能和特点可能会提高整个解决方案的成本

    情景二：“我们的服务太需要一个更好的配置管理数据库”NeedCMDB公司的困境

    NeedCMDB公司的帮助台软件可以存储大量的突发事件信息，而不需过多地考虑配置管理数据库中各配置项的内部联系。该公司的IT运营经理希望安装一个变更管理软件，因为他们公司大部分的问题出在基础设施变更时所引发的问题，以及软件在各种应用程序分发过程中的版本问题，这当然也包括所有软件对其支持的服务目录所带来的问题。公司内部也会产生大量重复发生的突发事件，这更使我们的IT经理坚信：只有通过有效的问题管理才能更好的解决问题。而所有这些的解决途径源于一个更好的，更适合自己的配置管理数据库！

    关于是否在该公司实施适合自己的IT服务管理解决方案的赞同意见和反对意见包括：

    赞同观点

    ·        根据记录的服务和突发事件，可以更容易的设计配置管理数据库粒度级别，这对组织是非常重要的

    ·        通过实施一个简单的软件基线库（Definite Software Library, DSL），可以更好的支持变更管理和版本管理，使我们在安装软件时更容易

    反对意见

    ·        记录所有软件应用的服务目录将会使配置管理数据库变得格外复杂，因为这种情况下，CMDB中大都包括了这些应用的所有软件组成部分

    ·        这将使变更管理以及创建一个标准变更管理数据库变得异常复杂，需要更长的时间来完成。而我们完全可以通过快速原型法来降低时间，提高速度。

     情景三：“我们的业务由我们的服务级别协议来定义”——某应用服务提供商（ASP）公司的心声

    ASP公司希望控制他们的服务级别协议SLA，以此来提高服务级别和服务质量。他们也很关注自动化软件的分发和测试。当ASP公司的管理层得到风险投资家的投资后，尽管这些钱还仅仅是一纸银行支票，他们就已迫不及待地实施一个基于运营中心且达到级别5的完整MOF模型框架。

    对于该应用服务提供商来说，反对意见和赞同意见也各占一半：

    赞同意见

    ·        他们可以将各种解决方案按照他们所希望的方式进行精确集成，集成任务可以完全使用系统管理工具来完成

    ·        他们可以产生出客户需要的用户接口，进行突发事件报告，变更请求，甚至实现在线变更等。

    ·        他们所提供的某些服务特点可以使他们的服务级别协议具有较高的可配置性，并为该公司提供了一条领先于其他应用服务提供商的途径，使该公司在众多ASP公司中脱颖而出。

     反对意见

    ·        开发一个完整的IT服务管理解决方案的过程可能是非常漫长的。这样长的时间对于一个ASP公司来说未必能够始终保持自己的领先地位，除非所付出的努力是巨大的且效果是非常显著的时，才可能保持住IT服务管理为其带来的优势。但这样往往会使组织消耗过多的资源，甚至无精力去顾及其他的项目。

    ·        对IT资源来说，在一个相当长的时间内支持同一个产品将是一项非常重的负担，最终的结果也一定是非常昂贵的代价

 
    情景四：“我们的公司虽小，但仍需要一个非常有效的工具和流程以实现公司的领先优势。自制配置管理数据库是一个不错的选择！”——小公司的观点

    小公司同样需要IT服务管理，他们同样需要信息系统来实现一个小的帮助台和突发事件管理。因为公司规模小，所以在选择IT服务管理解决方案时，就要针对小公司的特点有所侧重。对该公司来说，他们也需要IT服务管理得主要管理模块和功能（如帮助台和突发事件管理），但无需拥有大型系统管理工具。他们也在考虑变更管理和配置管理模块，以便实现对其基础设施的完全控制。

    关于小公司情况的观点包括：

 
    赞同观点

    ·        自制并实施一套方案的时间很快，因为在几周内用关键的几张表建一个Access数据库是很可能的

    ·        可以自己根据需要快速产生出适合自己情况的功能。因为组织不大，所以将发生的变化在整个组织内沟通将是很顺利的。

    反对意见

    ·        组织必须对高一级的MOF/ITIL有深入的了解，或者向一个资深的MOF/ITIL咨询顾问寻求帮助

    ·        与系统管理工具进行集成的任务将是非常困难的，这也暗示着我们集成后的CMDB数据库将仍保存着手工管理那些最长使用的重要资产的功能

    那么，现实到底有多复杂？

    作为一条总体原则来说，根据组织自身情况，自制一个ITSM/CMDB解决方案是完全可能的。但切记，在设计阶段所付出的艰辛与推广这个方案时所付出的努力将是同样多的。因为在推广一个配置管理数据库时所需的工作同样复杂，在各种繁杂工作中还包括从多维数据源中获取数据。仅这两项（创建一个CMDB数据库并收集数据信息）就需要组织付出特别多的努力。这样组织就不会有太多的精力从事MOF/ITIL的实施。因此，我们在考虑是自建还是购买一个现成的CMDB解决方案时，除考虑时间成本、资金成本外，还要考虑自制过程中将遇到的问题和困难，做好心理准备。在综合考虑各种自建的优缺点后，再作决定。（3030字）