通知短信+运营短信,5秒速达,支持群发助手一键发送🚀高效触达和通知客户 广告
### 3.4.1事件管理 有的人会把helpdesk和事件管理分开,但实际运作过程中,他们是一体的,UserRequest和incident密不可分。前面已经提到了,不过事件和请求还是有一定区别的,先看下生命周期 ![](https://box.kancloud.cn/527c9fa8a83d6327366965ebd1f1f1e5_1149x351.png) >[info]事件一般都是需要直接处理的,服务台确认事件后会尽快分配到处理人进行处理。 * 事件对紧急度更为关注 * 事件可以升级为问题(不能马上解决) * 事件的关联性极高,一个事件可能会引发多个事件 * 事件对CI的关注度比较高,注重影响范围 事件的创建和流转都和服务器请求一样,所以其他的就不用说了。 附事件管理流程图: ![](https://box.kancloud.cn/479753cb77108de9e5bd8148f2dae34b_1002x641.png) #### 3.4.2 服务管理 >[info]服务管理是服务台最重要的部分,服务的配置决定了服务台是否可以正常运作,服务分类是否合理,是否覆盖业务需要。所以服务管理这块的工作基本是交有服务经理或者专职主管团队来负责配置的,相对来说也比较复杂,对IT服务要有一定的认识,对ITIL等有所了解。不过就算你不知道也没太大关系,只想用这个软件的话,我来告诉你。 ### 3.4.3 服务的分类和设计 >[warning]这里要了解一个概念,在itop里面有三层架构 1. 第一层,Service family 服务族:这是最大的分类,一般来说表示一个方向性的,或者一种服务合同范围,比如:桌面服务、销售渠道服务 2. 第二层,Service,服务:这个是代表一套服务,比如:企业邮箱服务、crm系统售后服务,可以直接明确的让人看懂这个服务是做什么,或者负责什么范围 3. 第三层, Service subcategorie:这个是什么呢,这其实才是我们传统说的具体服务项,指一个具体的可操作项目,比如,开通企业邮箱、crm帐号被锁问题,这个必须是唯一有针对性的,用户选择到这个服务项后会很肯定的知道自己就是要做这件事情。 我上面说的分类方式不一定适合所有环境,在设计这个服务三层架构的时候一定要想好,我们现在提供什么服务,以后还可能提供什么服务,会不会冲突或者无法分辨。而且你要考虑到合同,因为合同是和服务签订的,不是服务项,也不是服务族,换句话说,服务是人群针对性的,虽然可以签两份合同给到两个人群,但请你想清楚怎么样才是最合理的。 ![](https://box.kancloud.cn/64338bf35616d26f15d75943e2814520_516x110.png) 比如我这里的分类,其实并不太好,服务族分类软件和服务请求,其实软件里面部分也属于服务,用户直接看到的肯定是服务,对服务族没体现到价值。 ### 3.4.4 合同和交互模式 >[warning]这里默认指用户合同customer contract,对于供应商合同我们用得不是很多,交互模式其实一种关系设定,这个在前面服务台原理的时候简单介绍过,这里再稍微详细一点说明一下。 首先是合同:创建一个customer contract 有几个重要的属性需要说明 >[success]* Customer:当前创建的合同是针对谁的,向谁提供服务的,这是一个organization对象,只有在这个组织下的人员才能享受这个合同包含的服务。 >* Service:服务,每个合同必须包含有最少一个服务,注意,是服务Service不是服务项,也不是服务族 >* Provider:提供方,也是organization,表示提供本合同涉及的所有服务的组织 别小看了这个,如果不正确设置,到时候服务团队可能无法设置,通常来说这是一个部门,比如IT部门。 有了这三大件,就不影响功能使用了,还有一个不影响使用但很重要的东西SLA,针对每一个服务,都需要一个SLA对应。这也是ITIL最基本的要求,关于SLA的计算后面单独说 >[info]接下来是交互模式,其实交互模式非常简单,就两个重要列表 >* contacts 联系人:这里的联系人其实是指负责人,也就是交互模式对应到合同后的处理问题的人,在itop里面很多地方联系人都可以理解为当前实体的负责人。当然了,针对交互模式这里通常是负责处理问题的服务团队,一线、二线、三线工程师,你可以给他们定义角色 >* customers 客户,顾名思义,这里是指向谁提供服务,具体是我们的用户,很容易理解。 有了这两个其属性,交互模式也就明白了,我们的合同和交互模式配置好,基本就可以发布服务出去了。