第一个文档是 “服务工单质量监及工作量统计表”，包含服务工单质量监控评审记录表、工单工作量统计表、工作任务明细三张表，如下所示：

第二个文档是“技术人员考核表”，按照工作负荷、工作任务、工作质量、工作技能、工作态度与责任感、协调性、纪律性七个方面进行考核。如下：

两个文档可以从SkyDrive下载：

服务工单质量监及工作量统计表：

技术人员考核表：

配置管理员是配置管理流程中主要工作承担者，其职责为：通过手工或自动化操作增加及更改配置项，保证所负责的关键CI的关键属性、关键CI间的关键关系完整、准确。实际工作中由各专业技术人员分别担任配置管理员，维护各自所管的设备或应用。配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。也就是说实际过程中配置管理员数量会是1+个。

配置管理和其他流程关联原则

• 配置管理和变更管理的关联
  • 变更主管在变更计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明
  • 变更实施完后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系
  • 对于风险等级为高和重大的变更，CAB中应该包括配置经理，以确保对CMDB的适当控制
  • CI应与变更记录建立关联，从而对CI的变化情况进行记录
• 和事件管理、问题管理的关联
  • CI应与事件记录、问题记录建立关联，从而确保对CI维护工作的统计和分析

从配置管理和其他流程关联关系来看，配置变更主要由变更管理流程发起，也就是需要提供“配置变更申请”功能给变更流程作为流程接入点，但是在实际中配置管理员需要对CMDB中数据准确性负责，然而在事件流程、问题流程或者其他流程过程中发现CMDB中记录的CI实例值更实际情况不符合（例如：CMDB中记录Sever1连接Switch1的23端口，但实际却是连接Switch2的3端口），这种情况怎么办呢？发起变更流程？工程师没有变更任何东西呀。这种情况下应该做出CI例外报告（HP这样的翻译实在不好），就设计了一个功能专门用于报告CI不可用的情况。

两个功能设计如下：

• 不可用CI报告：用于其他流程运维人员提交CMDB中记录有误的情况，用于辅助配置管理员收集错误的CI。配置管理员在收到不可用CI报告时需进一步核实CI情况，以便修改CMDB数据或者发起配置变更申请。
• 配置变更申请：为“CMDB控制和维护”子流程正常入口，用于变更流程或者配置管理员发起CI修改流程

在查看BMC Remedy IT Service Management功能之后，发现BMC中有一个“创建CI不可用性”的功能，名称好近似呀。不过BMC定义：CI 不可用性是指 CI 的实际宕机时间。您可以记录因某事件导致的意外情况引起的 CI 不可用性。看来在引入ITILV3后续流程后需要重新对不可用CI报告重新命名，以免误会。

• 第1步：识别CMDB实施组成员，定义角色和职责；
• 第2步：进行实施组CMDB知识培训；
• 第3步：Review，并就CMDB实施目标、任务达成一致；
• 第4步：Review，定义并沟通CMDB实施后预期收益；
• 第5步：制定实施计划，并进行项目SWOT分析、ROI分析、财务分析；
• 第6步：Review，并识别管理上的需求；
• 第7步：Review，并选择可实现的CMDB最佳实践方法；
• 第8步：识别潜在的问题，并提出解决办法；
• 第9步：识别资产和存货管理要求；
• 第10步：定义CMDB支撑的服务目录要求；
• 第11步：定义其他ITIL流程对CMDB的要求；
• 第12步：定义CI层次，建立IT设施模型
• 第13步：定义CI之间的关系
• 第14步：定义CI的属性
• 第15步：设计IT模型蓝图
• 第16步：选择实现CMDB的技术（产品选型）
• 第17步：计算并提出ROI
• 第18步：确定项目范围并制定扩充计划
• 第19步：构建CMDB
• 第20步：选择自动化CMDB工具或定义数据来源
• 第21步：填充CMDB数据
• 第22步：创建CI生命周期管理流程
• 第23步：建立配套的配置管理流程
• 第24步：对CMDB用户和配置管理角色进行使用、管理培训
• 第25步：识别指标并保持指标计算
• 第26步：建立可持续性服务改进程序

当然，实际步骤需要由项目经理根据实施单位的情况制定。