本文由长河、陈贺、傅盛原创，张翼、王岩校对。

“快”“准”“全”是ITIL事件单的填写过程的三的要点。“准”和“全”以3C（Clear清晰，Concise简明，Complete全面）的方式，帮助我们将文档准确化。其中“全”也就是“完整性”，是指文档必须充分包含故障的相关信息，让即使不熟悉事件的IT服务人员亦能从中找到所需信息，快速开始排障而无须从头再来。文档准确化的最大好处是，能让服务台坐席、桌面工程师、专家团队、服务第三方等对目前发生的故障有一致的认识，从而加速TTR。

上文已经介绍了如何“快”“准”，本问将回答如何做到“全”。

做到“全”的诀窍如下：

• 借器：提供详尽的填写模板，在工具开发时保证操作的方便性和严谨性。如，限定关键字格式；在某些关键环节，如“申请结单”环节，借助工具自动检查填写的字段值是否符合限定条件；直接在字段空白处预留一些内容，如：故障的主题可以设为：【部门】【类型】【地点】【事件】。这类模板一开始可以先“僵化”应用，在后期惠顾和评审时，适时作出调整；
• 借势：获取高层领导的支持，严格要求按照事件单填写规范执行；该点同样可提升事件单的“准”；
• 借标：
  

• 在关闭故障单环节进行严格把关，对于填写不完整的事件单可以退回，要求填写完整；若多次退回，则事件经理需及时介入，做好仲裁以及处理，以免导致处理超时；
• 定期对事件单进行回顾和评审，将事件单填写合格情况与绩效挂钩；
• 就事件单填写需要达到的管理目标对工程师进行培训，争取工程师对事件单填写规范的理解和认同。
  

   4.不借道：对未填单而受理的故障不纳入工作量考核，直接影响相关人员绩效。这个在多渠道IT服务台中尤为常见，例如不少服务台坐席在接到来自微信或者QQ群的报障，往往由于渠道之间数据接口没有打通——微信或者QQ和ITSM没有接口，服务台坐席为了省事直接进行处理而不填写事件单；又如有些运维工程师接到用户电话后直接处理故障而未进行任何记录；这些行为需要严格禁止。

   5.受控：对事件单填写质量的具有控制和保证措施。控制环节——事件单关闭前由服务台审核是否按照要求填写完整，否则退回重写，并且重写的时间计算入处理时间中。保障环节——提供足够培训，保证事件单录入者明白填写的要求；考核环节——对事件单被退回次数进行考核计入绩效。

IT运维管理社区原创文章，禁止任何形式的转载，侵权必究！

本文由长河、陈贺、傅盛原创，张翼、王岩校对。

“快”“准”“全”是ITIL事件单的填写过程的三的要点。“准”和“全”以3C（Clear清晰，Concise简明，Complete全面）的方式，帮助我们将文档准确化。其中“全”也就是“完整性”，是指文档必须充分包含故障的相关信息，让即使不熟悉事件的IT服务人员亦能从中找到所需信息，快速开始排障而无须从头再来。文档准确化的最大好处是，能让服务台坐席、桌面工程师、专家团队、服务第三方等对目前发生的故障有一致的认识，从而加速TTR。

上文已经介绍了如何“快”“准”，本问将回答如何做到“全”。

做到“全”的诀窍如下：

• 借器：提供详尽的填写模板，在工具开发时保证操作的方便性和严谨性。如，限定关键字格式；在某些关键环节，如“申请结单”环节，借助工具自动检查填写的字段值是否符合限定条件；直接在字段空白处预留一些内容，如：故障的主题可以设为：【部门】【类型】【地点】【事件】。这类模板一开始可以先“僵化”应用，在后期惠顾和评审时，适时作出调整；
• 借势：获取高层领导的支持，严格要求按照事件单填写规范执行；该点同样可提升事件单的“准”；
• 借标：
  

• 在关闭故障单环节进行严格把关，对于填写不完整的事件单可以退回，要求填写完整；若多次退回，则事件经理需及时介入，做好仲裁以及处理，以免导致处理超时；
• 定期对事件单进行回顾和评审，将事件单填写合格情况与绩效挂钩；
• 就事件单填写需要达到的管理目标对工程师进行培训，争取工程师对事件单填写规范的理解和认同。
  

   4.不借道：对未填单而受理的故障不纳入工作量考核，直接影响相关人员绩效。这个在多渠道IT服务台中尤为常见，例如不少服务台坐席在接到来自微信或者QQ群的报障，往往由于渠道之间数据接口没有打通——微信或者QQ和ITSM没有接口，服务台坐席为了省事直接进行处理而不填写事件单；又如有些运维工程师接到用户电话后直接处理故障而未进行任何记录；这些行为需要严格禁止。

   5.受控：对事件单填写质量的具有控制和保证措施。控制环节——事件单关闭前由服务台审核是否按照要求填写完整，否则退回重写，并且重写的时间计算入处理时间中。保障环节——提供足够培训，保证事件单录入者明白填写的要求；考核环节——对事件单被退回次数进行考核计入绩效。

IT运维管理社区原创文章，禁止任何形式的转载，侵权必究！