解决IT服务请求的困惑

来源：泛普软件

IT服务，我们都在讨论的是IT对外服务。服务请求也是针对客户或者是用户。服务台主管问了一个问题：一线工程师的疑难问题是否也要通过服务台汇报？我们讨论了一会。目前要求任何对外的联系都由服务台受理，然后转接。现在遇到2个问题：

1、服务请求没有将工程师的要求纳入，工程师遇到配件不合格或者配件带错的情况究竟是给服务台打电话寻求帮助，还是越过服务台直接给任务调度（负责分配任务和调度人手）打电话寻求帮助？

2、如果将工程师的要求也纳入服务请求，作为内部的服务请求同样走服务台受理、转接的流程，那么会存在效率上的问题。

这里涉及到的问题可以分两个方面来看：一个是服务请求的识别；一个是局部的效率和整体的效率平衡。讨论这些话题不能脱离具体的背景：服务台人数不足，没有合适的计算机工具支持。

服务请求的识别不存在困难，以前没有更深入地考虑过，现在可以将此事拿出来具体分类并设计出具体的处理流程。最大的问题是如何平衡局部的效率和整体的效率之间关系。没有工具支持，靠人工来协调的确是慢了很多，而且不易跟踪。从服务台的角度看，他们关心的是事件的过程跟踪和结果，对于细节的资源问题如何处理并不是他们的职责和需要考虑的内容。他们起到的作用仅仅是将工程师的要求转接到相应的岗位去处理。如果让他们受理工程师的要求是否超出工作职责范围？因为工程师的要求属于事件的一个过程细节。

从现有的条件看，我是倾向于工程师的关键要求直接联系任务调度，这就需要对要求进行分类识别。不能所有的要求都提交到任务管理那里，也不能所有要求都汇报到服务台。这样，对于关键要求可以做到直接提交，及时反馈。非关键要求还是要走服务台的正常流程，以保证流程管理的完整。

在手工工作方式下，某些局部流程的确会带来更高的效率，但是从流程管理的角度考虑，还是要强调整体流程的概念，灌输局部的快可能会影响到整体效率的思想，学会整体的思考方式。(amt)

发布：2007-04-23 10:44 编辑：泛普软件 · xiaona [打印此页] [关闭]

解决IT服务请求的困惑

泛普郑州OA快博其他应用