目录
服务目录的作用
服务目录常见的应用场景
服务目录是否必须有
服务目录的视图分类
用户视图
客户视图
服务提供者视图
服务目录的分类原则
为什么要分类
服务目录的分类方法
服务目录划分的颗粒度把握
服务详情
服务目录包括:服务目录、服务详情两大部分
服务目录的作用
服务目录是IT部门用于为所有服务和服务供给提供统一信息的单一来源并确保供相关用户可以访问。服务目录可以清晰的告知内部、外部的客户我提供什么服务。比如:桌面维护、ERP服务、E-Mail服务、打印机维护服务等。
服务目录中服务分类通常分为:例行操作、响应支持、优化改善、调研评估四大类
服务目录列表样式
服务目录常见的应用场景
- 用户在向IT部门提出服务请求时,可以通过服务目录的用户视图快速找到其想要请求的服务入口,包括服务内容、服务时效、服务负责人、服务时间、服务流程、服务前置条件等信息,以便于能够对服务有一个基本的了解和预期。
- 用于向外部参观者、顾问或各级领导展示IT部门业务开展的范围,一般通过服务目录大纲可以展示。
- 用于IT部门的新员工了解某个服务的基本情况,包括使用的技术、安全要求、可能风险、服务设计的性能和容量等,以便接收服务或者对服务进行优化。
此时的服务可能是某个业务系统。
一般是通过服务目录的服务者提供视图来了解。 - 用于外部顾问快速了解IT部门的业务开展情况。
如果IT部门使用了外部顾问来对IT部门的某方面的业务进行优化时,可以通过服务目录快速了解IT部门的业务情况。
服务目录是否必须有
不一定,在实际中服务目录的存在形式有很多种,比如事件管理的分类、服务请求分类、问题分类、变更分类等。而本身事件管理、服务请求管理、问题管理、变更管理就是一种服务目录的分类。因此,在实际的项目或ITIL4的落地过程中,如果没有服务目录的明确的应用场景,那么可以先从业务入手,逐步积累服务目录。比如:我们先做事件管理实践、服务请求管理,通过事件的分类、服务请求的分类来逐步的积累服务目录的内容。
服务目录的视图分类
用户视图
提供有关服务和服务供应的信息,从用户角度包含相应的详细信息。例如,服务描述、先决条件、请求服务的规程、服务级别协议、技术和渠道使用情况,以及有关服务支持信息。所有这些信息都应根据用户状态和服务权利进行筛选。
客户视图
从业务角度提供信息,包含约定的服务水平、财务数据、服务绩效和度量、合同要求等信息。此视图可能包括描述客户可用的服务和服务级别的服务提供。需要对客户视图进行筛选,以仅反映与客户和/或客户团体相关的服务和服务提供。新客户和现有客户的视图在服务的详细信息和范围中有所不同。
服务提供者视图
提供服务交付中使用的技术、安全、风险和流程相关信息。这包括使用服务的技术需求、技术解决方案详细信息,安全需求、潜在风险和可能的缓解措施,有关服务的事件和问题信息,等等。根据服务提供者的团队的需要,通常为他们定义多个视图。例如,供应商经理和业务分析人员可能需要不同的服务详细信息。这种裁剪可以通过创建不同的预设视图或为内部目录用户提供灵活的设置来实现。
服务目录的分类原则
为什么要分类
- 为了方便用户查找 IT对外提供的服务可能会很多,用户必须要要从众多的IT服务中方便的选择自己需要的服务内容。
- 方便进行任务分配 在实际的服务提供中,多个IT服务是被一个或一组IT人员来支持,通过分类方便进行任务的分配
- 方便穷举IT服务 在项目实施过程中,往往需要通过重新梳理IT服务,通过IT服务的分类,可以方便穷举IT部门提供的服务,避免遗漏
- 方便统计 很多时候是需要对服务进行统计和度量,通过分类可以比较方便的统计某些数据,进行相关决策
服务目录的分类方法
- 按照用户群体划分 不同的用户群体对IT服务需求的内容是不同的,这种方面可以更加面向用户。
比如通用服务(基础服务)、财务相关、生成相关、运营相关等 - 按照IT职能划分,比如 桌面问题、网络问题、应用问题
- 按照用户遇到的问题领域划分, 有点类似于按照IT职能,但用户必须能够清楚其发生了什么
- 扁平化模式 这种模式往往结合AI客户, 不会给出用户具体的分类目录,而是通过AI的方式通过关键字来直接获取用户的可能问题。
服务目录划分的颗粒度把握
按照客户体验优先原则,客户目录针对用户的展现不能太过细化,按照“Don't make me think”的体验设计原则,用户仅需要选择一级分类和描述故障现象即可,因此需要通过视图的方式降低用户的选择过程。
服务详情
服务目录好比“菜单”,服务详述好比“菜谱”,餐馆的顾客们可能不需要知道每道菜是如何制作的,而IT运维服务项目的客户们需要知道我们这道“菜”有哪些内容,实现哪些目标,交付哪些成果。 服务详述是对服务列表中每项服务内容的详细表述,我们需要用客户能够看得懂的语言介绍服务的目标、内容、交付成果等