本文描述填充过程的任务3到任务4：

任务3 映射CI和数据源
现在拿出您的CI清单，并把每一类CI与具有相关信息的数据源映射起来。一个简单的电子数据表格，像图17.2一样的就足够了。有更复杂数据需求的大一点的企业可能需要多个数据页或者通过CI分类来连接到不同的数据页。

这项工作的最终目标不仅是识别用以填充CMDB数据源，而且还识别了流程和平台的接触点，有些平台对数据填充是有影响的。这项工作也是至关重要，用来定义数据调和规则，定义数据优先度，这些会在下面的步骤，任务7“建立调和规则”中用的。
工具映射如下图17.2所示，包括了每一个CI类，相关的属性，相关的关系数据，和数据源。
图17.2 Ci和数据源之间的对照关系图样例
您可能会发现一些s数据源之间的重叠，特别是CI库存清单的属性数据。这些数据通常包括唯一物理特性和CI的地点的说明 ，例如：型号、序列号、地点和所有者。此信息可能被存储在其他多个地方，它们也可用于CI数据填充的来源和日常维护的来源。
多种的资产和库存清单数据来源可能包括如下：

• 审计（资产清单或者配置发现数据库；无代理和有代理方式）
• 资产管理系统
• 采购系统和许可证管理
• 财会系统（采购或者收货）
• 合同管理系统
• 变更管理系统
• 其他财务应用和系统

任务4 访问数据源环境
为了确保数据质量，你应该访问所有的数据源环境，而不仅仅只是CMDB，还包括连接工具和相关技术，要逐一访问查看每一个数据源。在这里，“进来的是垃圾，出去的就是垃圾”这个俗语是适用的。CMDB项目的成功可能依赖于对系统或者基础架构的更新，以适应网络流量和数据量，还依赖于确保每一个数据源的数据质量。

当你规划CMDB数据填充的时候，要自问这样几个问题，是有关外部映射数据源质量的：

• 现在那些信息在那里、怎样被存储的？ –数据库、电子表格、Word文档？
• 当前环境中有没有审计（发现）工具、软件分发、配置管理或者采购系统，用来自动的跟踪和存储这些信息？ 或者数据时被手工地收集和更新的？
• 这些系统是基于开放标准还是私有技术的？
• 这些系统的厂商有没有标准化的工具？或者CMDB厂商？
• 需要被继承的数据源的物理位置在那里？
• 在CMDB和数据源之间，通讯的方式是双向的还是单向的？

还要考虑有关映射数据源性能相关的问题：

• 就当前的数据源来说，现实的性能、容量和可靠性是怎样的？
• 系统上当前的活动状况怎样？
• 活动用户数
• 其他并发继承此数据源的工具
• 备份、病毒扫描、报表或者数据挖掘的日程
• 审计工具（配置发现或者库存清单）扫描或者排队日程
• 其他任何将影响性能的事情
• 硬件和当前环境是不是能完全满足今后数据迁移所需要的附加工作量和空间需求？以及满足对于以后的日常数据同步？有没有对今后几年里增长率有做过计算？
• 是不是需要考虑要满足什么约束或者特殊权限？
• 厂商是否在与他们数据库集成方面有建议的最佳实践？（使用热备的生产机来降低作业压力）
• CMDB周边的数据集和连接技术是什么？
• 网络环境中物理的限制（带宽、距离等）是否会有影响？
• 当前的版本是多少？在以后的六个月或者一年里是否有升级的计划？有哪些好处？
• 为当前的解决方案是否得到了足够的资料来负责架构、排错以及连接系统的维护？

通过尽早的回答这些问题，就可以避免后续可能出现的性能问题，那些问题会影响项目的成功。如果数据源不太可靠，而且数据质量和性能方面是有问题的，这个时候，可以回到这些数据的关键利益相关者那里，与他们讨论，并确定这是否会影响到使用方面的关键需求。如果没有，需要把这部分数据需求从CMDB项目计划的第一阶段中展示放弃。这里最重要的是第一阶段的合理部署，实施结果能够获得用户全面的适应。然而，如果这些数据依然是比较关键的需求，那么需要与数据所有者，和收益者各方进行沟通，并引起各方的高度重视，共同确定一个解决方案。

Related posts:

1. 规划CMDB数据填充-002
2. 规划CMDB数据填充-001
3. 21世纪最缺的是什么？

本文描述填充过程的任务1到任务2：

任务1  再次回顾CMDB范围
现在进行现实检验。你能否确实交付在第2阶段即“定义需求和创建IT服务模型蓝图”中定义的CI范围涉及的相关数据？你在CI数据一旦交付以后，能否有足够的资源来维护整个系统和所有数据？这些都是重要的问题，因为您所选择的CMDB解决方案，可能很容易地就超越了您需要的范围，超出了你可以能容易维护的程度。

在规划CMDB数据填充时，您的思想应该是“少即是多“。先学会走再跑。让CMDB的首次推广得到充分验证后在考虑扩大范围。您需要帮助保持 CMDB的团队和CMDB数据用户的积极性。同时避免项目范围的蔓延，否则可能破坏的实施的效果，以及用户对新的解决方案的接受度。

请谨记这样几个考虑因素，从而来帮助您始终专注于那些核心需求上，并能对关键的限制作出反应：

* 成本 – 每个人都必须面对业务现实，包括预算和费用的现实。因此，在您的CMDB项目预算范围里，对主要需求排列优先级。如果出现新的想法，那么也只是在新的预算来下了以后才考虑。
* 时间 — 您可能需要在给定的时间内实施CMDB，来使您企业在此方面的业务需求得到满足，如 Sarbanes-Oxley 法规，或支持一个非常关键的新流程。当您计划了CI数据填充的顺序后（后面介绍的这一步），不仅要对CI数据排优先级，而且还要明确时间的限制。
* 实用性 – 如果没有足够的资源用来实施和维持CMDB，以满足CMDB要求，那么您可能需要缩小实施范围，以便您可以在您实际有限的资源里运作项目。你还可以考虑分两个阶段进行实施，把非关键的要求放到第二个阶段中。
* 外部强加的优先事项 – 有些业务的运作，例如企业治理、数据保护和信息自由，可能会影响您既定的优先次序。您可以通过分阶段实施CMDB数据填充来减少外部因素的影响。如果你没有从一开始就计划足够的时间来达成最后期限，那么你可以尝试投入更多的资源来克服时间上的限制。然而，还要意识到，以后你要申请更多的资源，没有资源的保证，你可能无法充分管理好项目。
* 所有权 – 有时IT资产的负责人并不属于IT组织。如果资产所有者决定不参与的CMDB，这会严重限制了CI数据内容的提供。您可以提供CMDB部分功能的有限的访问给他们，用来消除他们顾虑，并参与进来。
* 地区 – 地理区域上的边界，可能会限制建立企业范围的CMDB。由于地理或行政上可能的边界，我们可能听过“最好再也不要从总部传来这样神经质数据库方案”。最好预防这种情况的办法是，尽可能早的让所有地区的相关人员参与到CMDB项目里来。
* 组织架构 – 很多企业把IT划分成为清晰地、各自为政的独立部门，通过这种方式来对CMDB里的不同范围负责。例如：通信部门的人可能是一个单独的组织结构，他们可能拒绝参与到项目中来，因为他们觉得这超出了他们的控制范围。这时候就要让其他的IT组织参与其中，让每个人都知道谁是项目负责人。

当你计划你的CMDB数据填充的时候，越能专注于关键受益人的需求，就越能够达成项目的业务目标，就越能让您的项目顺利。您需要就已经确定的 CMDB范围，与所有的利益方沟通它可能的影响和效果。收集他们的反馈，并对有必要方面做进一步讨论。

任务2 识别CI
使用在第15步即“设计IT服务模型蓝图”中设计的IT服务模型蓝图为基础，来生成用于CMDB数据填充的CI以及相关属性和关系数据的清单。这个清单的细节应该到数据字段级别，以便，你能够识别并且映射一个或者多个数据源到特定的CI数据。
例如，如果你把一个实际的服务器CI的属性和关系数据都列出清单，你就可以找出一些现有的能提供属性数据的数据源，可能包括库存管理的数据库和发现或者网络管理工具。但是另外一些数据字段可能没有现成的数据源。你将在第18步“选择自动化CMDB数据填充工具”中用到以上差距分析。或者您可能决定使用手工的方式来填充和更新这个字段，这里还需要仔细的考虑到数据的负责人，和在21步“建立CI生命周期管理流程”中需要支持的流程。
至此，你需要专注于用来满足项目目标的要求。在步骤11到14，你定义了与其他流程的结合点，明确的CI需求。专注于那些能直接对流程收益人产生直接影响的CI数据。

Related posts:

1. 规划CMDB数据填充-003
2. 规划CMDB数据填充-001
3. CMDB Value Points 价值点

挑战2：决策成本大
特别是银行等金融企业，安全性要求特别高。安全风险方面的建议往往是最重要的，他们的建议对配置采集工具的实施具有决定性意义。在各方都充分理解了配置采集工具的架构和安全性之后，就是拍板定夺了。这种逐级的审批和决策是需要较长的周期。

挑战3：前导时间成本太大
在前导时间里，可能还没有部署正式的ADDM采集服务器。在这个阶段里，要配置网络，让以后的采集服务器能够处于能够扫描到所有目标服务器设备。还可能需要在每台服务器上配置相关的准备工作，主要是坚持主机的操作系统的账户、采集协议和安全配置等是否满足配置采集工具的要求。这写工作是一个群众性运动，需要让所有的系统管理员配合。此项工作的设计人员设备多，最好能尽早的开始。

挑战4：用户的期望太大
用户对配置工具的期望主要是集中在深度和细度方面。其实这也不为过，只是在实施的过程中，最好还能把发现工具的一下特有的功能和特殊推广给用户。如软件和硬件的EOL信息，一些开合即用的报表和图形化展示功能，全文搜索等等功能其实都可以给客户带去意想不到的价值 。

No related posts.

21世纪最缺的是人才，在ITIL项目中更是重要。特别是CMDB项目，项目团队人员构成是呈金字塔型。

最顶端的人是Project Executive Board“项目执行委员会”，简称PEB，它就像是一个公司董事会；它对CMDB项目的目标、预算、工期、项目变更等负责。PEB人员数量应愈少愈好，不过下面的个角色也是缺一不可。首先，要请至少一个C level的人加入，比如数据中心的CIO。其次，关键利益干系人，它们是CMDB的价值的主要承载者，叫好和批评项目成果的都会是它们。然后是CMS/CMDB系统的负责人，它们对CMDB的规划、维护和之后的发展最重要。最后是项目实施资源的主要提供方领导，说白了他就是出人出力的部门，今后项目的执行和实施都靠他们。所以PEB的人数在4人左右。他们是相关部门的领导。我在最近的项目实施中，也遇到了几个问题，需要去找客户的老板来拍，也就是找到PEB的人决策。其实之前也听到其他同事在项目过程中，曾经感慨道“客户的领导还真辛苦，大事小情都需要替下面做决策，他们的脑袋真禁拍！”。国内的管理者的确挺辛苦的，毕竟所带领的团队都还比较的年轻，这也是国内IT管理的成熟度低的一个体现。

金字塔下面的人就是都是我们的天天加班、做牛做马的辛劳工作的实施人员了。没有规矩不能成方圆，实施团队的技术素质和构成、团队沟通等都是至关重要的。对项目的质量，项目工期都有非常重要的影响。金字塔下面的兄弟姐妹都是一条船上的人，大家要互相配合才能完成项目的各项工作；在这个过程中没有一个船老大也是不行的，船老大就是项目经理。对CMDB的项目经理的要求可不低，重要有以下几点：

• Planning skills
• IT service management background
• Previous involvement in building a database
• ITIL Manager’s certification
• Ability to make decisions
• Capabilities to motivate staff
• Ability to blend a team
• Strength of character to lead a team
• Capacity to present results and status of project to sponsors and stakeholders
• Self-motivation
• Ability to communicate instructions to the project team (from step by step to build a cmdb)

项目实施工程应该具备很多的必要素质。CMDB产品是一个复杂的应用系统，必须有人对它的技术细节非常熟悉，包括应用安装、配置和客户化。这个技能应该是核心中的核心，对产品利用的好，就能减少二次开发的工作量，就能最大发挥产品的原本功能，从而规避项目风险。产品的二次开发技能也是另一个必要因素，这是由于中国用户的特点决定的，对于任何一个大型的ITSM项目，国内没有不对产品做二次开发的。程序开发技能也很重要，Java/JSP开发人员是必须的，他们还需要懂得html、xml、sql等技术。如果能在有操作系统和数据库专家就在好不过了，在系统出现性能故障，系统需要全面备份和恢复的时候，数据库专家和系统专家的参与能让事情经行的更高效，更快，不至于由于系统不可用导致的窝工。系统能更安全，能更放心的使用和开发。下面的一些技能是充分条件，包括ITIL认证、ITSM流程的知识背景和项目经验。

CMDB项目对实施人员的要求是很高的，实施前要选合适的人；想要追求高品质的项目质量，就需要网络业内的专业的实施专家顾问、有经验的项目经理和合格的项目实施工程师。从这个角度上讲，21世纪ITSM项目最缺的可见是CMDB人才；呵呵这纯粹是我的笑谈，不过您要组建一个CMDB项目团队的话，挑选人员的时候请务必擦亮眼睛。

Related posts:

1. 规划CMDB数据填充-002
2. 手把手教您构建CMDB/CMS
3. CMDB Value Points 价值点

回忆前三个月所做的的需求分析工作，虽然各项调研和讨论工作进行的缓慢，不过细致的工作最终还是换回了令人满意的成果，起码我是这么认为。

需求分析的过程是对需求的重新整理、重新定义和梳理。项目的立项并不意味着项目目标树立的精准，项目范围控制的合理。实际需求可以在实施的初期阶段来重定义，从新分析，着觉得不是浪费时间。而且这一点对于中国用户至关重要。国内很多项目都是资金或者预算驱动的，先有需求，通过需求推到出项目的价值，在通过项目的投资回报率申报项目预算的过程在国内是很少见得。国内的项目往往是有多少钱需要花，那么大家在来看，如何把需求花到极致，达到最大的产出。这也是很多需求分析做的贪多、贪大、求全的根源，这样做的好处是在一个项目周期内就把需求实现的尽善尽美（愿望是这样），坏处是：可能导致厂商和服务商的服务成本超支，从而造成的项目质量降低，从用户角度来说一次性接受一大堆的系统功能，负担重，接受度低，同时客户满意度低，项目满意度差。

我认为较好的最佳实践还要抓项目的主要目标，抓需要实现的主要价值点，抓重点放弃那些可做可不做的功能。懂得放弃的人才懂得获得。把所有的功能需求做成能够分批、分期上线的成果；确保让系统用户能buy in每一个阶段性成果，不要奢望给用户带来革命性的提高，由于那样也意味着，你对他们当前工作方式的影响是巨大的，没有用户愿意接受巨变。

需求分析时，从技术上讲，对会议组织人要求很高。需要此人能非常熟悉CMDB项目实施的方法论，需要此人能够非常熟悉产品的各个功能点，需要引导有效的需求分析会议。在白板上尽可能多的画图，用Visio或者ppt等工具尽量多的讲解各种架构图、功能图、流程图具有事半功倍的效果。不管会议上您可能收到怎样的抱怨、抵制、反对；stakeholder的反馈将是你最宝贵的收获。没有互动和反馈的需求分析会是相当无聊和浪费时间的。切忌在大型的企业中，要慎重地计划每一次需求分析会，理由也很简单，企业组织越大，沟通的成本也越高。需求分析沟通的效率和成功完全取决于CMDB项目执行的方法论，取决于分析引导人的各种项目背景经验，还取决于对客户状况了解和上手的速度。

No related posts.

最好能通过资产管理为统一入口，来完成对CMDB中资产的生命周期管理。例如：一台服务器在到货以后，完成资产入库后，就应该在CMDB中自动创建CI，在上架部署了软件后，有配置资产自动采集工具，采集回详细配置信息后，资产状态就自动变为“部署”，当在运行维护中服务器宕机或者维护时，在资产管理中也能看到更新的信息。下面是建议的服务资产的生命周期状态:

配置项管理和资产管理的联系和区别。

Service Asset and Configuration Management (SACM) = Configuration Management + Asset Management

Configuration Management
@The Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships
@This information is managed throughout the Lifecycle of the CI

Asset Management
@Asset Management is the Process responsible for tracking and reporting the value and ownership of financial Assets throughout their Lifecycle.

Related posts:

1. ITIL V3 Study Notes (2)
2. 图书推荐《服务建模：原理与应用》
3. 看图学话，学ITIL(v2)系列 之1

说来此书有很多实用且精彩之处，相信读了英文原版的人更能有所体会。我忍不住想把其中的部分内容提前与你们探讨，这里想与你们分享如下两个内容。

上图还给所有CMDB用户一个清晰地CMDB功能点考察点，CMDB作为业务服务管理的核心，各个厂商其实并没有达成解决方案功能的标准和共识。通常情况下厂商提供的CMDB产品的发展和起源有以下几种情况：1）按照ITIL中对CMDB的需求和标准从无到有开发的标准CMDB产品；2）伴随变更流程或者业务影响管理而开发的CMDB功能模块；3）伴随配置自动化发现工具而开发的相应CMDB功能模块；4）应资产管理或者监控工具扩展而生的CMDB功能产品。用户在挑选CMDB产品的时候一定要明确CMDB的核心功能，除了以上功能外，其他的附加功能可能是nice to have的功能，而非必须。本图位于原版书的134页，如果您对我的翻译有建议请留言，多谢！

上表为评估一个CMDB产品厂商的综合打分评价表样例。在选择并且评测一个CMDB厂商时，需要仔细考察的产品功能共有8点。用户需要注意的是一定要搞清楚其中的每一个功能是否是由厂商的CMDB产品的相关模块所提供的，如果不是的话需要搞清楚，每个功能是否是CMDB的外围或者其他产品模块，或者二次开发实现的。如果是这样的话，这种解决方案可能不是一套集成统一的解决方案，可能出现其他附加非CMDB产品的采购，可能在实施阶段付出不必要的集成和开发费用。虽然这些潜在因素在采购和实施阶段可能是隐形出现的。征集上表中相关术语的中文翻译：Weighted ，Weighted Rating Score，Total Weighted Score。有好的建议请留言。本图位于原版书籍的141页。

Related posts:

1. 选书名
2. CMDB Value Points 价值点
3. 21世纪最缺的是什么？

给此书起一个好的名字是头等大事，目前能想到的书名如下：

Step by Step Guide to Building a CMDB 中文书名？(polls)

寻求前100名投票者，请对以上书名投票，并评论；如果您有更好的书名，欢迎推荐；请在下面留言，请正确填写邮箱，您推荐书名一旦被选用必有感谢送上。

Related posts:

1. 手把手教您构建CMDB/CMS
2. 21世纪最缺的是什么？
3. CMDB选型解密

欢迎留下一个反馈，投票或者留言都行。
[poll id="8"]

Related posts:

1. 选书名
2. CMDB选型解密
3. 21世纪最缺的是什么？

dmtf.org

当然是配置项和它们之间的关系，即：CI 和  Relationship。 那么如何规划那些类型的CI和Relationship需要保存到CMDB中呢？可以参考的数据模型是DMTF的通用信息模型，它是以面相对象的方式来描述各类CI和关系。它是一个工具用来帮你对环境中的各种物理和逻辑的CI和关系进行分类，参考这个模型选择一些有用的类（广度），然后在参考它对每个类属性的描述（粒度）。这些类的选择只是一个初步的研究，每个CMDB厂商和工具对其实施和参考的力度都不同，也需要看您具体实施的是什么工具。例如：你需要描述银行基金业务系统，你可能选择的CI类包括：客户群、业务流程、业务活动、业务服务、IT服务、应用系统、应用、软件服务器、服务器、网络、存储等；关系包括：组件、依赖和影响。CI类和关系的选择也基本上遵循够用就好的原则；而且每个类对应的CI实例都需要有人负责管理维护，需遵循，谁负责、谁维护的原则保障其属性的精确性。对于整个CMDB来说如果存在没有Onwer的CI或者关系，如果它是由自动化配置发现工具来更新的；那么它可以存在，如果不是的话，它可能根本就不该存在。所以CMDB中保存的数据不是越多，越细越好；而是够用就好，能保证更新就好。由于数据根本就不是免费的，即使国内的人力成本低，也不应该雇用一帮专职更新CMDB的人。 综上所述：我们说明了CMDB中数据选取和存放的最基本原则和方法，在CMDB产品选型过程中需要着重考察产品的数据模型本身和其管理的能力，还包括其CI和关系的扩展和定制能力；包括数据类型的支持和界面定制的程度。那么CMDB中的CI和关系有该如何展现呢？这是CMDB系统的另外一个功能：可视化。下面是一个CI和关系展示的实例供参考：
[http://media-001.yo2cdn.com/wp-content/uploads/266/26670/2009/10/s1-4-blog.swf#swf&width=320&height=320]
全屏查看或者下载Flash文件
第一代的配置展示方式是，纯数据表格方式。第二代具有一种固定格式的图形展示方式，除了那几张视图外，别的需要单独开发。下一代的具有各种视图定制功能，并且支持关系和ci的过滤等等。

Related posts:

1. Stop to build CMDB for your IT – CMS是怎样炼成的？
2. 手把手教您构建CMDB/CMS