说说ITSM项目实战那些事儿（三）

上篇我们深入探讨了SLA设计的重要性，现在，让我们进一步挖掘服务目录设计的精髓，掌握服务实施的实战技巧，并且领略服务优化的艺术。这是我们的最终篇章，毫无保留，全是干货，让你满载而归。

服务目录
ITSM的目的是让服务成为明星，让服务类型隐身。服务目录设计，就像是一块试金石，老鸟新手一眼便知。目录设计得当，项目成功就相当于迈进了一大步。
传统ITIL理论太宽泛，落地难，咱们得改良。每个服务得有个固定的团队和SLA，不然服务就成了摆设，要么没人管，要么没期限。

服务目录里的细节也得抠：

• 服务负责人：一旦服务SLA报警或评价低，他们得第一个知道。

• 服务范围：公共的，全局都用；专属的，特定人群专享。

• 服务类型：各种服务分门别类，比如请求、故障、事件等，每种都有典型例子，一看就明白。

服务类型	描述	典型
请求	日常小事，如PC修修、密码重置	PC故障,邮件申请,密码重置
故障	系统不灵了，得修	OA故障,ERP报修
事件	监控报警，得人工介入	监控告警处理
问题	大难题，找根本的解决方案	ERP性能优化
变更	生产环境动手术，硬件换换、软件调调	服务器硬盘更换
发布	新东西上线，软件更新、硬件部署	新系统上线
任务	工单的协同任务或者个人任务	个人事务
安全	应急处理，网络安全、病毒斗士	网络安全响应，病毒处理
需求	业务新想法，产品经理最爱	CRM新需求

记住，这分类不是死规定，根据自家情况调整。

• 服务属性：各种属性定清楚，比如关联的配置、应用系统、交付方式，还有图标和描述，方便识别和服务。

服务设计技巧

• 服务名称
  名字得通俗，比如“电脑出毛病”，别整“业务问题”这种云里雾里的。描述要详细，减少误会。

正面示例	反面示例
服务名称:PC故障；服务描述:主要面向个人电脑用户的一般故障,例如配件故障,网络中断等问题	服务名称:业务问题；服务描述:无

• 服务范围
  别太大，比如“所有系统”，这样职责不清；也别太细，“导航栏错位”之类的，工单会爆棚。公共服务用公共，专属服务要管好。

• 服务自动化
  自动分配工单，自动关闭超时未处理的，低评分自动警告服务台，减少人为干预。

• 多渠道接入
  网站、电话、APP、微信、钉钉…年轻人爱啥来啥，传统用户就多照顾电话。

• 统一入口
  服务目录是起点，用户只看目录，系统自动匹配服务类型和流程。

• 服务团队层级
  一层团队别超10人，2到7人正好，多级设计能支持更多工程师。

服务名称	一线支持服务团队	二线支持服务团队	三线支持服务团队
PC故障	L1TA	L2TA	L3TA
PC故障	L1TA,L1TB,L1TC	L2TA,L2TB	L3TA

服务实施：从蓝图到现实

• 服务合同：ITILv4的精髓，得靠服务合同体现，这是服务关系的桥梁。
• 供应商合同：跟供应商的协议要盯紧，维保信息得跟上，别到时候掉链子。
• 服务配置：初始化设置，邮件、呼叫中心这些基础设施得准备好。
• 动态调整：牛气的功能！网页上就能调整服务参数，随时适应变化，服务经理随时掌控大局。

服务运营：日常运维的规矩

• 工单管理
  核心流程，别每个服务都从头造轮子，拿个模板，微调一下，马上能用。

  节点	节点内容
  新建	权限审核
  审批	是否审批，简单/复杂
  分发	自由抢单还是空闲优先,满意度高优先,或者按工单分发规则进行指派
  处理	一线–>二线–>三线
  评价	是否自动评价,评价过低是否需要人工干预
  关闭	是否自动关闭还是需要回访,是否需要转知识库

• 巡检管理
  日常的巡逻，设备和检查指标得配对，能自动抓取数据就更赞了。

• 告警管理
  海量告警要过滤，转成事件工单，处理进度实时同步给监控系统。

• 考核管理
  既要硬数据，也要软反馈，自定义评分，公平又全面。

服务优化：持续向前的动力

• 服务报告：从不同角度分析数据，用户满不满意，SLA达没达标，总结经验教训。
• 持续改进：找出弱点，对症下药，不断进化，服务越来越强。

这一波实操分享就到这里，售后服务嘛，涉及到技术支持和新需求开发，因情况而异，就不细讲了。咱们的实战攻略到此结束，希望能帮到你！