ITIL事件的TTO和TTR是什么？他们应如何制定？（ITIL先锋论坛原创）

boy

: P$ P, w: @7 d3 G: w0 f3 X

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

# }( U2 A9 Y6 `0 T# A* X6 D- {) e4 I

TTO（time to own )指从创建工单到指派完工单所用的时间。

# d; L) o, z+ D

TTR（time to resolve）亦称解决时间（Resolution Time），指从创建工单到工单申请完成所用的时间，其帮助IT服务组织追踪解决客户事件的平均时间。

在SLA中会定义不同类型服务对不同客户的TTO和TTR的要求。

6 p- k" r% j8 G, ~/ |; D# f  Z6 j

在SLT中，规定了不同的服务的不同优先级具有不同的基础TTO。即时相同的服务针对不同顾客时也可以有不同的基础TTO。基础TTO是一个IT服务组织较容易能达到的标准，顾客可以要求提高标准，但需要支付更昂贵的费用——因为该IT服务组织提供了增值服务。总之，IT服务组织应在自身IT服务能力的范围内，针对客户需要而确定基础TTO。通过服务、优先级、顾客这三个变量的组合，制定最终TTO。

精确地获得TTO数值难度不低。理论上TTO是工程师收到工单并响应用户的时点，但该时点难以准确采集，所以多数情况我们以工单被分配到具体工程师的时间点来计算，但我们应认识到这实际上并不准确。值得一提的是，在分配过程中，首次分配正确的工单百分比（首次分配正确率）也与TTO有较强相关性。还存在一种情况，若派单给一位工程师，但该工程师反馈派错单，则服务台需要回收后再进行转派。此时，TTO的计算不应被触发，应以最后成功派单为准。

0 \; B( O. K! X( S6 B# l# \

TTR的制定需要考虑两个方面：

• 计算时长必须扣除非工作时段，例如当ITIL事件或请求单被挂起后，继续消耗的时间不能计入TTR的耗时中，直到工单重新释放；
  0 P& K" W1 u$ n* V3 `

8 C- E7 z6 ^* S9 E

• “事件从解决到获得用户确认”这段时间，IT服务团队难以主动掌控，这需要耗费不少时间，很可能由于用户的原因，导致该时间过长。如果最终该用户已确认事件被解决，则TTR的结束时间点可采用服务工程师申请关闭流程的节点事件。但如果用户确认该事件未得到妥善解决，则事件单需要有人跟进，TTR继续计时，直到用户最终满意并确认的时点为止，该时点作为TTR的结束时间点。也需要制定一条规则应对如下场景：若事件被关闭后却出现事件复发等情况，需要重新打开的事件，继续进行处理时，TTR如何计算？我们可以安排服务台在该事件被真正解决后，再手工进行TTR的调整。
  

- X$ M3 j3 r* N* r$ M9 i2 s

从下图可知，TTR与顾客满意度成反比的。组织和顾客对TTO的要求是一致的：“快”！IT服务组织希望尽快解决从而节省成本并维持顾客满意度，顾客则希望自己能尽快回到工作状态中。

图 1-4、TTR与客户满意度关系示意图

TTO以及TTR的提升，可以从以下几个方面着手：

• 制定与事件解决相关的作业指导书（SOP）：为常见事件提供作业指导书；
  $ s8 d, I' E2 a

( f. o  E/ ~% g8 B% f1 L5 ^

• 提供标准化的维护人员资源：包括硬件维护工具、软件测试与维护工具、建立相关应用软件服务器（确保运维工程师能及时获得必要的与服务对象匹配的应用软件的副本）；
  

• 应用移动工具：如采用移动APP、微信客户端、短信通知等手段，协助运维工程师及时获得及处理事件单；了解维护对象的状况；向服务台汇报事件处理进度；获取对应作业指导书；向服务台申请事件关闭；
  

8 g2 F' V. r. ^8 R* ^; M) j

• 完善知识库：经过知识的累积（包括已知错误、作业指导书等），及时为服务台以及运维工程师提供指导。
  

/ k. z" T$ c! w3 i6 w  b* c

ITIL先锋论坛原创文章，禁止任何形式的转载，侵权必究！
( Q* d- [+ r+ B+ l- [
; h- m" N' o9 ]! j. ^