ITSS落地——虚拟资源的一些事（推荐阅读）

文章不短，但认真看下来必有收获！...

专栏傅师傅

ITIL,PRINCE2,DEVOPS,BCS,ITSS等均叶公好龙，不一而足。善搬运，痴收集，松鼠症候群晚期。

小赵是X公司ITSS体系落地的负责人，而老李则是小赵请来的高参。小赵现正为两件事头痛，老李被召唤过来排忧解难。

“老李啊，咱们公司的情况你也是知道的，为了通过ITSS的成熟度三级，算下血本了。培训也学了，咨询也请了，工具也买了，这些预算本来有的，花了也就算了。怎么你还强调要弄个服务台？我还得再请人啊，咱可真没预算了。“

“小赵，别急。先和你说个事……“

原来，昨天在公积金中心驻场的项目里，用户综合部的小高正做季度数据分析。突然OA报错，导致数据无法上传。小高通过通讯录找到X公司驻场的工程师小达，让他来排障。小达听得出小高这事很急，于是放下手头正在调试的路由器赶到现场。但遗憾的是，到了现场后小达才发现这个不是他擅长的网络问题，估计问题是出在OA上。小达连忙打电话向同样驻场的小尚和小白求助。小尚此时正在执行一项常规变更，爱莫能助。而小白是负责ORACLE的，对OA也是一筹莫展。于是小达只好硬着头皮继续去摸索着怎么排除这个OA故障，最后熬到下班前，小尚才过来救了火。

”小赵，你从这能不能感受到咱们运维服务的窘况？“

“的确是有点。小高和小达这么做，都有点乱点鸳鸯谱的感觉。大家的时间都浪费了。小高没法及时提交数据分析，而小达的路由器调试也耽搁了。“

“没错。在IT服务过程中，掌握用户和客户各方面的信息，对提高IT服务质量非常重要。用户的请求、客户的咨询这类信息要怎样才能迅捷高效地向咱们传递呢？服务台就充当了这样的一扇门户，成为咱们和用户之间的单一联系点。确保用户在适当的时间内找到适当的支持人员，帮助解决他们的问题或请求。“

“服务台看来有点坐镇军中，运筹帷幄的样子。的确设一个也无妨，老赵，那我安排小达把公积金中心的服务台兼了就行。“

“咱们服务台的组建形式上可以粗略地分为虚拟和实体两种。按虚拟的方式做，小达电话接障，在即将应用的工具上启动事件流程，给自己分派工单，做完之后自己回访自己关闭。按实体做，就要在公司本部设专人的服务台，接收所有运维项目的请求。通过服务台接障，开单，进行运维资源的调配并跟进，完成客户回访后关闭事件。“

”对，对。就小达做了就行！让小达成为’运维达人‘！“

”且慢，这个咱们还得从长计议。ITSS在三级中对服务台要求有三个方面。第一：得有，所以相关制度、流程、操作手册，用户评价记录等得具备；第二：得正常运作；第三：得被有效管理。考核要和评价记录产生的流程、主要内容、评价结果挂钩。并且服务台的工作还需要被抽检。咱们公积金项目就五杆枪，每天的工单有一百多张。仅仅是对所有工单做回访这一项工作，你觉得小达忙得过来吗？而且，在工作压力之下，既是裁判又是运动员运维的同事，会不会将接到的单先挂起不跟进，或者不回访直接关闭事件呢？“

“老赵你说的也在理，这么操作，咱们运维的质量就无法得到有效的保障。客户的体验也无法得到提升。那咱们就必须得实打实了？“

“服务台建立后就不单纯是对事件的记录，而是对其经手的事件的态势进行全程的监控，有始也有终地让服务支持流程成为一个完整的闭环。其中所指的事件不单纯是普通的事件，还有服务请求，信息安全事件，以及二级中提及的应急事件等。我记得你很喜欢练太极。杨澄甫先生《太极拳练习谈》中提过：‘两腿宜分虚实，起落犹如猫行。’在这就派得上用场。“

“老赵，没想到你也是练家子。嘿嘿，这虚实和服务台怎么扯上关系了？ “

”太极拳在行拳走架中，始终分清虚实，在虚实的转换中完成整套拳法。ITSS落地时，强调适宜性和有效性，有怎么样的内外服务需求，就得有怎么样的服务能力动态匹配。服务台的虚和实，也可参考太极拳的套路。咱们公司根据实际情况，转换自身的重心位置——确认自身当前定位，使支撑身体重量的两腿——落地的措施，做到‘全实’、‘全虚’、‘实中有虚’、‘虚中有实’。在四级的时候，条件不成熟，人手不足，可以只考虑‘有没有’，先以虚拟服务台维持基本服务质量，跑跑流程。而在三级，咱们面对的服务需求已经大大改变了，对服务质量提出了更高的要求，就需要专人专岗，实打实地将事件进行有效的管理和跟进。而到业务更繁盛的时期，咱们开始同时管理几个大型驻场项目时，那么在这些驻场项目再分别组建分支型虚拟服务台，毕竟驻场的同事更了解驻场用户的业务以及系统，可以自主处理跟进驻场的服务跟踪和管理，并服从公司本部的服务台指派和管理，这就是’实中有虚‘。“

“说的好像很有道理，不过’虚中有实‘呢？我想不到是怎么一个场景了。”

“小李，这个场景啊，就得看咱们服务台发展的趋势了。今后服务水平提升后，为了提高一线解决率，提升平均事件解决的事件，减少技术类请求的平均答复时间，服务台应该怎么进化呢？服务台需要从呼叫中心或者非技能型/呼叫记录型，向技能型甚至专家型的服务台演进。这类强有力的服务台，可以摆脱“接口”的职能，化身为“以客户为中心，以流程为导向”的服务窗口，为客户提供更全面的服务体验。为了达成这个美好的远景，往往需要从驻场项目的服务台中抽取实战经验丰富的骨干精英，到本部服务台提供直接技术支持。这可以说是’虚中有实‘了。”

“老赵，这算给你绕过去了。我还有件烦事，得和你说说。就是关于ITSS所要求的备品备件库。你看公积金的项目，咱们承担着客户核心路由器和存储的维护，SLA也提及了这类故障在24小时内解决。咱不可能各买一台设备做备机，就这么放在公积金中心吧。项目一年才40多万，连主要模块都买不起。算盘怎么打都亏啊。还有另一个房管所的应用系统运维项目，咱们是纯软件运维，你说怎么做备品备件库？会不会一旦没有，在审核的时候，就给一票否决了？”

“巧了，备品备件库和服务台一样，都是ITSS中提及的资源，而且也和虚、实搭上了关系。三级强调的是备件库信息全、准、真；规范制度适宜；备件可用。却并没有强调备品备件库必须是自建的。”

”备品备件库如果不是自建，那么就只能是客户自己买备品备件，其所有权是客户的？“

“其实还有一种情形，就是备品备件是由第三方提供的。这种就属于虚拟备品备件库。你刚才说的两种就属于实体。“

”我懂了，下来你又要说‘全实’、‘全虚’、‘实中有虚’、‘虚中有实’。在条件不成熟，人手不足，可以只考虑‘有没有’，备品备件库可以采用‘全虚‘的方式，直接由第三方提供，就和咱们公积金中心项目一样，‘没有枪没有炮，第三方给咱们包’！’全实‘的可以在资金允许的情况下搭建。‘实中有虚‘可以是一个实体备品备件库，为好几个项目所虚拟共用。不过‘虚中有实’我又想不到了……”

“你说的很对！‘虚中有实’可以是：少用或者不容易坏或者价值高的就以虚拟方式让第三方准备着，有的备品备件容易坏或者价值低的就以实体形式存在。再提提备品备件库咱们实施的一些要点。第一：虚拟备品备件库因为管理方不是咱们公司，所以当要采用这种方式时，必须要注意SLA。例如咱们给客户承诺的是24小时恢复。那么咱们和第三方就备品备件签订的SLA就必须小于24小时。第二就是要准备备品备件的测试环境——这个环境可以和技术里提及的研发环境，变更提及的测试环境是一致。并且保留备品备件测试的记录。这类记录当备品备件库是公司或者客户管辖的时候还好说，但是一旦是虚拟方式，就很容易被忽略。在制定备件管理规范的时候，需要对备品备件的抽检设置频度和比例，这个频度对实体或者虚拟都应一视同仁。重要的备件建议抽检频度高-全检，其余的备件建议抽检频度低-抽检。通过这类测试检查确保备件的可用率。第三备品备件到货后咱们也常常会忽略验收这个环节。之前这方面都没有做记录，送过来就直接放在仓库了。”

“那房管所的项目，还要建备品备件库吗？”

“设备都不需要咱们维护的纯软件项目，备品备件库自然就是真正的‘虚’了,没有存在的必要！董英杰前辈在《太极虚实之解释》中说过：‘如欲上右脚，则用意将身躯重心微移至左腿立实，右腿重力既移去后变为虚，即能轻便活动，提起迈步。’就如在服务台和备品备件库这两个资源点上，虚实既对立又统一，在一定条件/场景下还能互相转化。当咱们ITSS体系的落地时，做到不随意忽视条款，也不盲目迎合条款。这样才能‘提起迈步，轻便活动’。”

本来来自微信公众号 “盛装吾步”