【客户案例】家乐福的 Jira Service Desk 落地实践发表时间：2020-06-30 14:13 作者简介 本文作者是来自苏宁家乐福中国 IT 部门的PMO Head：黄翔。 他上个月跟大家分享了《苏宁家乐福使用 Jira 搭建统一管理平台》的经验，这次他和大家分享他们通过 Jira Service Desk 来管理 IT 服务的一些过程以及他总结的 Jira Service Desk 和 Jira Software 运用上的一些区别。希望能够给到同样在传统企业IT部门的小伙伴们一些参考，互相交流学习。
为什么使用 Jira Service Desk？ 我们团队和项目的背景以及所面临的问题和挑战在我之前的文章：《客户案例 | 苏宁家乐福使用 Jira 搭建统一管理平台》 一文中有过介绍，想了解的小伙伴可以跳转过去阅读。 和大多数首次使用 Atlassian 产品的用户一样，我们首先购买和使用的是认知度最高的 Jira Software，我们想通过 Jira 搭建公司的统一的项目管理和任务管理的平台，用法更多集中在从项目的维度出发，将不同的项目进行分类，再根据不同项目类型来用类似瀑布式项目管理模式结合敏捷 Scrum 的模式在 Jira 上进行项目任务的管理。 而对于传统企业的 IT 部门而言，应用和项目只是其中的一部分工作。在 IT 服务管理方面我们想根据 ITIL 的框架来搭建 IT 服务相关的一系列流程、其中包括：IT Service Mangement、Incident Management、Problem Management等。 由于我们之前已经有了专门的事件管理工具，但那个工具的问题是不太具备扩展性进行服务管理和其他几个模块的能力延伸，所以我们把视线放到了用 Jira Service Desk 上。 选择 Jira ServiceDesk 对我们的好处显而易见：如果同时使用 Jira Software 和 Jira Service Desk，那么运维和开发相关的一些内容就被天然打通了，处理运维问题的支持团队甚至能看到这个问题是由哪个版本的哪个开发任务造成的，而谁来解决和负责这个任务。但理想总是比较美好的，我们碰到的实际问题是由于外部供应商开发居多，而真正的开发过程的任务管理和测试管理都是在他们各自的平台完成的。要强制要求供应商使用我们统一的平台是一个办法，但也需要大量人力配合和时间。所以第一步我们还是采取分而治之的方式。 Service Request 的设计 通过初步的服务梳理，我们根据实际的工作组将IT服务分为以下几个大类：
这里我们在 Jira ServiceDesk 中通常有两种处理办法， 一是只创建一个整体的 Service 项目把这些相关的 Request Type 通过分组放好，为每一种类型的 Request Type 定义各自的工作流来满足要求。二是针对每个大的工作组单独创建项目，项目内可以更加细致的定义子类的 Request Type 和不同的工作流。在评估了当前各组的工作实际情况后，我们认为单是 Infrastructure 里面就会有很多不同的 Request Type，那样的话我们需要定义很多不同的 Issue Type，太细的维度对于管理起来也很复杂。所以我们选择了分别创建4个 Service Project 的形式。 虽然是4个不同的项目，但是 Jira Service Desk 提供一个统一 Portal 入口的功能。这样就实现了前台的用户看到的只是4个父级的菜单，而后台人员都是登陆各自的项目进行运维操作，使得后期的管理工作也容易了很多。
Jira Service Desk 与 Jira Software 的不同 通过与同行业的朋友们交流之后，我们了解到也有一些用户在没有使用Jira Service Desk的条件下，通过使用Jira Software基于本身自定义的 Issue type, Customize field, Screen 以及很灵活的 Workflow 等，也能实现基本的表单提交和工作流审批功能。 那么我从两个软件都是实际使用者的角度，来分享它们之间的不同和侧重吧，或者更突出的讲讲 Jira Service Desk 基于 Jira Software 之上有哪些非常棒的新特性： 1. Jira Service Desk 提供默认的 IT Service Desk模板：在选择创建一个Service Desk 类型的项目时，我们能看到 Jira 提供一个 IT Service Desk 的项目类型。如果你不知道都有哪些 IT Service 你应该提供服务的话那从这里开始也是一个不错的选择。
可以看到创建之后就已经有了很多默认的 Requests，如果有不需要使用的，简单隐藏起来或者删掉就好了，十分方便！
2. 访问权限：我们知道 Jira Software 是按照用户数量来计算 license 的，而 Jira Service Desk 则是按照服务的座席数来计费的，因此经济实惠很多！我们 Jira Service Desk 的使用者包括了企业内部的所有员工，很多场景下是不需要他们占用 Jira 的用户数，但同时允许他们提交 Request 或 Ticket。 Jira Service Desk 项目支持不同的客户权限类型。我们可以灵活的配置不同的项目，哪些是对于全网路开放的，哪些是对全企业开放的，还有哪些是需要一定 Jira 权限账号才能使用的。 因此，我们只需要购买50个 Jira Service Desk 的坐席，就可以服务于800左右的用户，非常经济实惠！
3. 通过邮件就能开单：用户端提交 ticket 非常简单，甚至不用登陆服务页面，而是直接通过发邮件的形式开单，通过邮件接收到工单更新的回馈以及用户满意度调查的邮件。这样用户无需登陆页面就可以通过邮件实现对于工单的简单处理，非常简便，深受业务部门的欢迎。
4. 节点审批：这个是购买了 Jira Service Desk 之后对于工作流引擎的一个加强。可以针对节点进行更加便捷的审批人或审批组的配置。
5. 自动处理 Ticket：我们知道很多请求服务单是需要提出人来关闭的，但往往他们在事情得到解决后并不会主动再打开系统去关闭 Ticket。那么我们就可以通过这个 Automation 的功能定义一些当触发了特定条件就会自动更新 ticket 的操作了。默认系统就提供了这个标准的三个工作日已解决的工单自动关闭的规则，你要做的就是启用他就可以了。
其他经验
|
