前一段时间帮朋友要来这两个文档给他参考，该公司的IT运维部门的流程规范性还是比较好，有关工作量统计文档和考核文档都是比较齐全的，分享出来给大家参考参考。
第一个文档是 “服务工单质量监及工作量统计表”，包含服务工单质量监控评审记录表、工单工作量统计表、工作任务明细三张表，如下所示：
第二个文档是“技术人员考核表”，按照工作负荷、工作任务、工作质量、工作技能、工作态度与责任感、协调性、纪律性七个方面进行考核。如下：
两个文档可以从SkyDrive下载：
服务工单质量监及工作量统计表：
技术人员考核表：
去年做的省公司IT服务流程中设计了了一个“不可用CI”报告的功能，同时配置管理流程里面针对配置变更有“配置变更申请”功能，同事对这两个功能不能理解。因为在实际开发过程中，开发人员将“不可用CI”报告的功能最后操作定义成了直接更新CMDB，不需要走流程，而将“配置变更申请”功能需要走“CMDB控制和维护”流程。同事的疑问不可用CI是否会破坏流程性及用户误操作。我的意见是这两个功能都不可缺失。
配置管理员是配置管理流程中主要工作承担者，其职责为：通过手工或自动化操作增加及更改配置项，保证所负责的关键CI的关键属性、关键CI间的关键关系完整、准确。实际工作中由各专业技术人员分别担任配置管理员，维护各自所管的设备或应用。配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。也就是说实际过程中配置管理员数量会是1+个。
从配置管理和其他流程关联关系来看，配置变更主要由变更管理流程发起，也就是需要提供“配置变更申请”功能给变更流程作为流程接入点，但是在实际中配置管理员需要对CMDB中数据准确性负责，然而在事件流程、问题流程或者其他流程过程中发现CMDB中记录的CI实例值更实际情况不符合（例如：CMDB中记录Sever1连接Switch1的23端口，但实际却是连接Switch2的3端口），这种情况怎么办呢？发起变更流程？工程师没有变更任何东西呀。这种情况下应该做出CI例外报告（HP这样的翻译实在不好），就设计了一个功能专门用于报告CI不可用的情况。
两个功能设计如下：
在查看BMC Remedy IT Service Management功能之后，发现BMC中有一个“创建CI不可用性”的功能，名称好近似呀。不过BMC定义：CI 不可用性是指 CI 的实际宕机时间。您可以记录因某事件导致的意外情况引起的 CI 不可用性。看来在引入ITILV3后续流程后需要重新对不可用CI报告重新命名，以免误会。
最近工作都是围绕ITIL和ITSM展开的，需要做一些记录。CMDB（配置管理数据库）实施过程相当复杂，为此参考了别人的实施过程对实施任务进行了分解：
当然，实际步骤需要由项目经理根据实施单位的情况制定。
Dominic 
