ITR （Issue to Resolution ），从问题到解决。

这里的Issue指的并不是问题，大多数是 trouble 或者 problem 之类的，但是为什么我们用 issue这个词呢？因为 issue 具体指的是一些重要的议题、以及争论的问题。

 

ITR系统实际上要解决的不是一个客户投诉的事情，它是要解决客户的需求或者服务请求。

比如客户买了你的设备，他在用设备的过程中，突然想起来这个地方是不是应该有一个什么样的功能，或者说这样的操作是不是更好，可以通过流程给企业一个反馈。他也可以和我们的厂家一起去提出这样的要求，如果要进行网络升级，可以请厂家的工程师帮他升级。

 

很多企业把客户的服务请求和投诉混淆起来，这就很难关注问题处理以后价值的提炼，通过流程可以挖掘客户的一些线索或机会点，把一些问题化解为新产品或者新功能，这需要三大业务流之间互通。

 

 

一、ITR服务流程体系的四大模块

 

ITR 和IPD、LTC三者称之为一级流程，而ITR流程体系的四大模块则称之为二级流程。

 

第一个模块：管理技术服务请求。比如客户有什么样的技术问题，提出要求后，我们就帮助他去解决，可能是设备有故障需要我们解决等等。

第二个模块：管理非技术服务请求。比如华为提供的很多培训服务都属于这块，需要安排具体的场地、老师，这不是由技术部门实现的，而是由一些管理部门实现的。

第三个模块：管理备件服务交付。并非每个企业都需要，比如有的公司就只有产品和软件，不存在备件一说。

第四个模块：管理客户投诉。由三个小模块组成：服务/投诉请求受理、服务请求/投诉处理和服务请求/投诉关闭。

 

管理客户投诉是一个相对独立的东西，如何才能管理好客户的这些问题呢？

这里就涉及到SLA和OLA这两个协议了。

 

SLA （Service Level Agreement） 服务等级协议，即企业对客户的服务承诺。

比如受理的时间、解决的时间、服务的质量标准，比如宾馆里的标准就是客房保持整洁、及时打扫，还有服务部门、服务人员的配置、备件的要求，都属于服务质量的一个部分。

 

OLA （Operation Level Agreement ）操作级别协议，即在企业内部，为了达成对客户的SLA，各个部门以及设备分别使用的时间、质量标准，还有一些配置。

比如要完成某个设备的维修，可能需要两个部门及一台设备来达成。

 

部门A需要1小时 5 分钟，部门B需要1个小时，用1台设备去运行和修复，总共需要2小时5 分钟，这是内部的OLA，那要去看SLA。假设对客户的承诺是一个半小时，现在 OLA 是2小时 5 分钟，显然不能达成 SLA 的要求。

因此通过 SLA 倒逼内部 OLA 的效率提升，才能够达成面向客户的SLA。
SLA 是这个行业的一些惯例制定的，但是又不能完全按照行业的惯例，比如企业希望能够通过服务来打动客户，就需要把 SLA 做的比本行业的其他企业好一些，突出一些特别的优势，比如海底捞的SLA就比同行要好很多，带来了许多生意。

 

当客户的问题进入ITR系统以后，每一个问题都会有一个问题单，无论是企业的内部还是客户，都可以凭借问题单查询问题处理的状态，回溯问题处理的整个过程。

问题单在每个环节都有既定的时间要求和质量要求，这就是OLA。需要在流程中去定义，也是考核点，作为角色绩效管理的一个部分，那么流程的 IT 化也会使得问题的处理过程更加迅捷，也可以跟踪和追溯。

 

 

二、ITR流程体系组织的三线要求

 

ITR 流程体系组织分为三层：一线、二线、三线。每一层每一线对员工的要求不同，

 

一线的要求：工程师，有一定的技术能力，能够解决常见的一些问题。同时也可以在技术专家的指导下解决一些疑难的问题，或者执行技术专家提供的一些技术方案。

二线的要求：专家级别，技术比较全面，能够打通各个相关的专业领域，而且经验比较丰富，能够去指导并且协助一线工程师解决疑难的问题。

三线的要求：属于研发体系，又是相对独立于开发的一条主线，它专注于产品的维护，解决产品的缺陷、质量等相关问题。

 

当二线专家无法通过常规手段去解决问题的时候，问题就会上升到三线团队，三线团队必须要给解决方案，它可能是一种临时的解决方案，但也会有长久的解决方案。

三层人员分别隶属于不同的职能部门，一线比较接近客户，一般是区域的维护团队，二线一般在总部，三线隶属于研发，怎样才能把这三个不同属性的团队链接起来，并提高效率？这要通过流程和绩效的管理。比如现在的流程很明确，当一线工程师遇到不能解决的问题，就会通过某一个渠道升级到二级专家，这是流程上的一些规定。

如果只有流程没有管理规则，就会出现以下两个问题：

 

第一个问题：一线工程师会不会看到有一点问题就往上交？

管理上有一个991规则：90% 的问题一定要在一线解决，只有 10% 往二线提交。二线的这 10% 里的 90% 也必须在二线解决，只有最后的 10% 向研发提交。

如果最终的结果优于991，就可以考虑减少二线、三线人员的数量。降下来的成本可以用来提高一线队伍的待遇。如果三条线或者某一条线达不到标准，就要从两个方面追溯

1、员工的技术能力和问题处理能力是不是达标，如果培训还不能达标，就考虑调整岗位。

2、产品的质量是否达标，产品的可维护性是否达标，要从产品开发的角度去回溯。

 

第二个问题：二线专家接不接这个问题？

二线专家必须要去接这个问题，因为规则里面会有这些要求。

ITR 流程不是凭空而来的，它是基于企业发展的战略，把企业服务业务流程的优化实践给固化下来，并且通过 IT 进行承载，通过管理 OLA 实现对客户服务的承诺，也就是 SLA 的达成。ITR 本身不是部门的概念，它是流程的概念， 贯穿了服务和研发。