文档更改14 某公司IT服务管理ITIL服务台和突发事件管理流程设计分册

由 superadmin 于 2024/10/29, 10:10 最后修改

从版本 1.1 >

由superadmin编辑
在2024/10/28, 13:00上

到版本

由superadmin编辑
在2024/10/28, 13:07上

修改评论该版本没有评论

Raw
已渲染

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

标题

...	...	@@ -1,0 +1,1 @@
	1	+14 某公司IT服务管理ITIL服务台和突发事件管理流程设计分册

父

...	...	@@ -1,0 +1,1 @@
	1	+G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.事件管理.WebHome

Content

@@ -1,0
          +1,648 @@
++= **1. 文档介绍** =
++
++《服务台及事件管理流程设计》是在对IT维护管理流程进行现状评估后，结合实际情况， 共同制定的服务台建设及事件管理的流程设计文档。通过制定该设计文档，可以帮助信息中心通过建立一个综合的服务台和梯队式的IT服务架构，重新组织原有的IT运维管理工作，有效地解决IT环境的突发事件，提高IT系统和服务的质量，并为信息中心今后进一步完善事件管理提供指南。
++
++==   ==
++
++== **1.1. 文档范围** ==
++
++本文档描述了信息中心IT服务管理活动中服务台和事件管理流程的设计。
++
++服务台的设计内容包括服务台的组织建设建议，担当职能以及相关流程定义，同时包括与事件管理活动集成的接口。
++
++事件管理的流程设计部分，内容包括在信息中心实现事件管理控制的相关流程定义和部分平台实现时的代码设计。
++
++==   ==
++
++== **1.2.文档用途** ==
++
++本文档一方面作为本次ITSM项目的事件管理流程设计的交付物，另一方面也可作为进一步优化服务台，突发事件管理流程的蓝本，读者对象为与事件管理流程相关的所有技术与管理人员。
++
++本文档所描述的流程在IT服务管理中有许多作用，例举如下：
++
++1. 减小突发事件对业务的影响
++1. 最优化支持资源，提高工作效率
++1. 根据业务轻重缓急解决事件，保障有效IT运营
++1. 加强有形监控和及时反馈
++1. 提升用户满意度
++1. 提供管理信息
++
++
++== **1.3. 文档结构** ==
++
++文档内容具体如下：
++
++* 第一章 文档介绍
++
++对文档目的和内容进行简单介绍，同时描述文档中用到的ITIL中的术语。
++
++* 第二章 IT管理模式
++
++ 讨论在华星光电IT信息中心现有基础上应该建立一个什么样的IT管理模式，以适应IT服务管理的要求。
++
++* 第三章 服务台建设建议
++
++分析管理模式中的核心工具－－服务台――的组建原则，人员、工具要求，角色职责以及衡量标准。
++
++* 第四章 服务台用户交互管理流程设计
++
++描述服务台用户交互流程设计内容，如：具体流程、流程代码等。
++
++* 第五章 事件管理流程概述
++
++简单描述事件流程，明确设计目的、范围、内容以及流程政策等。
++
++* 第六章 事件管理流程设计
++
++描述事件流程设计内容，如：具体流程、流程代码等。
++
++* 第七章 事件管理流程设计
++
++描述与服务台，突发事件流程相关的报表定义。
++
++
++== **1.4. ITIL相关术语** ==
++
++下面是ITIL中相关的术语：
++
++* 帮助台：即Help Desk
++
++在ITSM中， 帮助台从根本上来说是提供了用户和IT部门的唯一接口。帮助台是面向突发事件的支持机构，其根本目的是管理、协调并尽快解决突发事件。
++
++* 服务台：即ServiceDesk
++
++服务台是更广义上的IT服务管理支持工具，它不仅包含帮助台功能（支持事件管理流程），同时也提供与其它流程的接口。
++
++* 事件管理：即 Incident Management
++
++是负责处理所有导致IT服务中断或服务质量下降的事件和用户请求的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务，而不在于查找根本原因。
++
++* 问题管理：即Problem Management
++
++是负责解决重大紧急事件或具有相同特征的一组事件的运维流程。它的目的是找出产生这些事件的根本原因，并通过永久性解决方案防止类似事件的再次发生，同时问题管理流程也通过主动式管理降低事件发生的数量。
++
++* 配置管理：即Configuration Management
++
++是负责描述、跟踪和汇报所有IT基础架构中的每一个设备或系统的信息的运维流程。这些设备和系统被称为配置元素(CI) 。每一个CI必须有效管理、跟踪和控制以支持IT服务和基础设施正常运行。
++
++* 配置管理数据库（CMDB）：即Configuration Management Database
++
++是配置管理流程中用于记录企业所有IT相关配置元素及其相互关系信息的数据库。
++
++* 变更管理：即Change Management
++
++是负责控制和管理IT相关的变更的运维流程。它的目的是使变更可能将对生产环境产生的影响和风险降到最小，从而提高IT环境的整体稳定性。
++
++* ITIL：即IT Infrastructure Library
++
++是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT服务管理标准，惠普的ITSM管理思想是以此为核心基础的。
++
++服务流程的总体构架和互相之间的关系如下：
++
++(% style="text-align:center" %)
++[[image:1730091617324-254.png]]
++
++
++= **2. IT管理模式（运维模式）** =
++
++
++通过对信息中心业务和IT现状的调研和分析，我们发现，目前运维部门的运维工作主要集中在以下一些方面：
++
++* 突发事件和请求
++包括故障申告和各种客户申请活动，此类活动的特点是，随机产生，有发起者，对处理时间和信息反馈有要求，处理不当容易影响业务质量或客户满意度下降。
++* 日常维护工作
++定期或有计划的系统维护工作，如系统备份、磁盘空间维护、日志检查等，此类活动的特点是定期进行，无发起者，对业务质量或客户满意度无影响。
++* 不定期的维护工作
++包括各种维护规范、规划、策略的制定。此类活动的特点是，不定期进行，有发起者（通常是部门领导），活动周期较长，对业务质量或客户满意度无太大影响，但对运维管理工作产生一定的影响。
++
++基于以上分析，我们建议华星光电IT信息中心采用以服务台为中心的IT管理组织模式，并且建立梯队式的技术支持与服务团队，在整合服务资源的同时，建立规范的管理流程和方法，以满足从传统的IT运维管理方式向IT服务管理方式转变的需要。
++
++
++由于服务台与事件管理流程的关联最为紧密，服务台的建设将在本设计文档中与事件管理流程一起讨论。
++
++=   =
++
++=   =
++
++= **3. 服务台建设建议** =
++
++== **3.1. 什么是服务台** ==
++
++服务台（Service Desk）在服务支持中扮演着一个极为重要的角色。完整意义上的服务台可以理解为其它IT部门和服务流程的“前台”，它可以在不需要联系特定技术人员的情况下处理大量的客户请求。对客户而言，服务台是他们与IT部门的唯一联络点，确保他们找到帮助其解决问题和请求的相关人员。
++
++服务台有时也被称作“帮助台”（Help Desk），但这两个概念的意义并不完全一样。帮助台的主要任务是记录、解决和监控IT服务运作过程中产生的问题，主要和事故管理相关联。而服务台的概念则具有更广泛的内涵，它通过提供一个集中和专职的服务联络点促进了组织业务流程与服务管理基础架构的集成。
++
++==   ==
++
++== **3.2. 服务台使命** ==
++
++服务台只是一项服务管理职能，因此，与其他服务管理流程不同，它没有严格有序的日常运作流程，而只是针对用户的请求或根据服务级别协议的要求进行一些日常运作活动。这些日常运作活动包括响应用户呼叫、为用户发布信息、客户需求管理和客户关系管理、日常运维管理、基础架构监控等：
++
++* 响应用户呼叫
++
++即对于用户发出的故障申告、服务请求、变更请求等事件进行记录和处理。这是服务台最主要的工作。
++
++* 为用户发布信息
++
++服务台是为用户提供IT服务信息的主要来源，一般可以采用布告栏、电子邮件、屏幕消息等方式为用户提供有关故障信息、故障或新增服务等方面的信息；
++
++* 客户需求管理和客户关系管理
++
++服务台不仅仅是客户请求响应中心，同时也是客户关系管理中心。因此服务提供方应采取必要的措施和使用适当的技术对服务台进行有效的管理，从而使服务台可以准确迅速的了解客户需求，改善客户体验，提高客户满意度。这些措施和技术包括结构化询问技术、详细了解客户和跟踪客户、维护客户数据库和在客户中推广服务台等；
++
++* 日常维护管理
++
++服务台可承载日常运作管理任务，包括数据备份与恢复、磁盘空间管理、用户口令管理等；
++
++* 基础架构监控
++
++利用相关工具对IT基础架构的运作情况进行监控，一旦检测到故障已经发生或即将发生，就应该立即评估这种故障对关键设备可能产生的影响，并在必要时将检测到的故障报告事故管理流程。
++
++作为事件管理的有效实现手段，服务台是一种基于日志管理来记录事件并为业务（内部或外部）提供日常支持的服务平台；同时，它通过对流程，文档和岗位责任制的管理协调，来达到尽快解决事件的目的。它专注于处理出现在信息系统中或由用户报告的事件来尽快恢复服务的可用性，并管理和维系最终用户和服务提供者之间的日常服务接口。
++
++==   ==
++
++== **3.3. 服务台角色与职责** ==
++
++=== **3.3.1. 角色和职责** ===
++
++服务台主要提供帮助台和一线职责，其职责可包括：
++
++* 一线支持与客户协调
++* 记录，跟踪服务事件
++* 事件进展的沟通（内，外）
++* 事件影响的评估
++* 分派，协调，升级事件
++* 管理服务请求
++* 客户/用户信息发布
++* 沟通变更计划
++* 提供管理信息
++
++
++根据信息中心实际情况并结合ITIL，定义如下角色：
++
++* 服务台经理
++* 服务台人员
++
++====   ====
++
++==== **3.3.1.1. 服务台经理** ====
++
++职责：
++
++* 确保服务台人员以良好专业知识和服务态度发挥服务台作用，提高用户的满意度。
++* 负责管理服务台团队，监控和统计服务台的工作量和服务质量
++* 协调和分配服务台人员日常工作，人员培训和能力建设
++* 安排服务台值班人员
++* 负责用户投诉的处理
++* 配合事件，问题，变更，服务级别等流程经理的工作
++* 制作管理报表
++
++主要技能：
++
++* 较强的口头表达能力和与客户沟通技巧
++* 处理纠纷的能力
++* 较强的领导能力
++* 深刻了解服务台职能和其他IT服务管理流程
++* 较强的组织和协调能力
++* 具备一定企业管理知识
++
++====   ====
++
++==== **3.3.1.2. 服务台人员** ====
++
++职责：
++
++* 通过与用户联系来注册交互。
++* 将用户交互与突发事件、问题、已知错误或知识文档相匹配。
++* 解决和关闭交互。
++* 请求时向用户提供状态更新。
++* 根据用户交互注册突发事件并将其分配到正确的支持组。
++* 验证支持组提供的解决方案。
++* 向用户报告解决方案并对其进行验证。
++* 监控所有注册突发事件的服务级别协议 (SLA) 目标，并在必要时升级至突发事件分析员。
++* 向所有用户通报服务中断的消息。
++
++主要技能：
++
++* 了解技术平台和技术环境
++* 熟悉事件处理流程和服务台的职责
++* 熟悉事件分类和每类派发人员
++* 快速诊断事件和分类事件的能力
++* 较强的人际沟通能力
++* 较强的提问和倾听能力
++* 良好的电话使用技巧
++* 较强的记录技巧
++
++
++== **3.4. 服务台组建原则** ==
++
++在组建服务台时，员工数量及类型决定于
++
++* 服务的期望
++* IT架构的复杂程度
++* 客户的数量，电脑使用技能，以及客户的多样性
++* 事件的数量和紧急程度
++* 事件的时间分布形态
++* 服务级别协议/承诺
++* 已有的人员技能， 流程以及工具
++
++服务台人员结构应在实际使用过程中动态调整，此原则同样适用于今后服务台发展过程中对人员结构的考察
++
++==   ==
++
++== **3.5. 服务台衡量标准** ==
++
++对于服务台服务工作的质量和绩效可以从以下指标考察：
++
++* 电话接听率，接听电话的总量/ 用户拨入电话的总量 (需要其他设备记录拨入的电话数)
++* 用户在线等待时间
++* 问题解决率 ，热线支持工程师在线解决的问题/ 总共接听的问题
++
++* 用户满意度
++
++还可以包括的一些指标包括：
++
++* 电话的记录比率(需要其他设备记录拨入的电话数)
++* 分配给突发事件分析员的服务请求
++* 服务台接到的服务请求总数
++* 优先级为最高的服务请求数量
++* 结束的服务请求 (按照关闭代码分类)
++* 超过解决期限x天仍未解决的服务请求
++* 按服务呼叫类别统计的呼叫总数
++* 事件平均解决时间（按优先级分类）
++
++==   ==
++
++== **3.6. 服务台工具的功能** ==
++
++服务台的功能可能由一个或一组工具来实现，在使用工具实现服务台时应考虑以下方面的内容:
++
++===   ===
++
++=== **3.6.1. 呼叫管理** ===
++
++在服务台电话呼叫量大，人员多的情况下（比如人均每月的电话量超过200个电话），可以考虑使用电话自动分配系统 (ACD) ， 以达到：平衡电话分配，提供电话性能报告（如电话放弃比例，电话时长等），提供呼叫队列 状态信息的目的。
++
++===   ===
++
++=== **3.6.2. 知识管理** ===
++
++通过提供知识库，能够在服务台、突发事件分析员、系统管理员及最终用户间共享一些解决问题的关键信息，这些信息可以是一些临时的解决方案，脚本，补丁的参考信息，常见问题及答案等，并且能够按标题，现象等灵活查询。
++
++===   ===
++
++=== **3.6.3. 事件处理流程支持** ===
++
++事件处理流程是服务台支持的流程，它承接呼叫管理流程，完成新的服务请求或突发事件的处理。事件处理的工具需提供接受，跟踪和控制事件的界面，这就需要工具具备整合的事件/服务请求管理，配置管理， 服务级别管理的能力，应能做到：
++
++* 对授权的用户可以访问到相应权限范围内的事件；
++* 可以记录事件的状态；
++* 可以记录事件的结果；
++* 可以提供一系列的事件状态报告， 如按照事件类别，状态等
++
++===   ===
++
++=== **3.6.4. 客户沟通管理** ===
++
++与最终用户的沟通确认是一个很有价值的主动服务手段。它可以减少服务呼叫数量，降低服务台的工作量，节省人力。如果系统能自动为用户提供事件的状态，会大大改善服务台与用户之间的沟通。
++
++===   ===
++
++=== **3.6.5. 与监控管理工具集成 ** ===
++
++服务台的事件管理工具提供与运营管理的监控工具集成的能力。
++
++监控工具可以将告警事件自动输入到事件管理工具，并生成一个事件编号，自动的事件录入过程对事件管理工具有些隐含的要求：当服务台收到告警事件，需对其进行类别划分，优先级划分以及分派给合适的工作组，同时，要认定受影响的系统服务以及通过对配置管理数据库的搜索找出相关的配置项目；服务台坐席通过队列监控自动录入的事件管理系统；当事件被坐席关闭时， 最好能在监控系统中同时关闭事件。
++
++由于网络监控工具日常发现的告警的数量较大， 为了保证服务台以及一线处理人员的工作效率， 需要 对监控工具转发到ITIL流程平台的告警进行精细的过滤。
++
++=   =
++
++=   =
++
++= **4. 服务台用户交互流程设计** =
++
++用户每次联系服务台都被记录为一次交互。用户交互管理是一个流程，用于处理用户与服务台的所有交互，这些交互通过邮件接收或直接通过服务台人员报告。交互类型可以包括用户报告的服务中断、服务请求、信息请求 (RFI) 或投诉。通过用户交互管理流程，可以轻松记录和解决简单的用户请求，并将其他请求升级为需要进一步操作的突发事件。
++
++可以将多个用户交互链接到工具中的一个突发事件记录单。用户交互管理描述了注册新突发事件或变更时服务台需要执行的所有活动。服务台人员会执行必要的步骤并搜索相关知识记录、已知错误记录和现有突发事件或变更。
++
++此流程简化了服务台活动，因此可以减少突发事件分析员的工作量。
++
++
++== **4.1. 流程代码定义** ==
++
++流程代码是服务台交互、事件管理流程不可或缺的一部分，是对服务台交互、事件管理流程关键环节的详细描述的必要准备。本章节将详细描述：信息项、分类、影响度、优先级、状态、关闭等代码，这些内容将在流程的具体描述中使用。
++
++===   ===
++
++=== **4.1.1. 信息项** ===
++
++信息项定义的是交互、事件管理流程需要的所有信息项，主要如下
++
++|**代码**|**描述**
++|ID|工单号，自动生成
++|联系人信息|本次事件报告人的联络信息，厂别
++|受理人|自动设为登记该事件的操作员
++|实际开始时间|在服务台生成事件记录的时间，系统自动记录
++|实际结束时间|在服务台事件关闭的时间，系统自动记录
++|最终期限|在事件开始处理前约定的最终解决时间
++|描述|对于整个事件内容的详细描述
++|状态|事件的状态
++|类别|从事件所属性质的角度来确定其处理流程，是突发事件，还是服务请求
++|领域|从事件所属的系统或架构来进行分类
++|子领域|从事件从属的系统或技术架构的技术类型类型来进行分类，相对于区域
++|服务名|发生问题所归属的服务
++|配置项|故障对象的标识
++|地点|事件发生地点
++|影响范围|故障影响的范围
++|紧急程度|故障需要处理的紧急程度
++|优先级|事件优先级决定了事件的解决时限和处理次序
++|分配对象|分配组和分配人员
++|解决方案描述|事件解决方案的描述
++|结束代码|根据事件结束的不同方式赋予不同的结束代码
++|活动日志|反映事件处理过程中的事件处理信息，包括人员，时间等信息
++|初步问题原因|关闭突发事件时已知的初步原因
++|问题管理备选项|该事件作为问题管理的备选项
++
++
++=== **4.1.2. 类别代码** ===
++
++根据的业务要求和管理要求，定义如下四种类型：
++
++|**序号**|**代码**|**描述**
++|1|突发事件|事件
++|2|服务请求|服务请求,如:更改密码等
++|3|投诉与建议|客户投诉
++|4|变更请求|请求变更
++
++===   ===
++
++=== **4.1.3. 领域，子领域** ===
++
++根据信息中心业务系统架构的事件，服务请求，投诉种类，故障比进一步划分为领域，子领域。领域和子领域的划分采用信息中心现有的分类：
++
++CIM:
++
++|**类型**|**领域**|**子领域**|**说明**
++|(% rowspan="7" %)突发事件|(% rowspan="7" %)CIM|AUTO|含设备问题
++|MES|
++|Report|
++|CFM|
++|OEE|
++|DEA|
++|SPC|
++|(% rowspan="7" %)服务请求|(% rowspan="7" %)CIM|AUTO|含设备问题
++|MES|
++|Report|
++|CFM|
++|OEE|
++|DEA|
++|SPC|
++|(% rowspan="7" %)投诉与建议|(% rowspan="7" %)CIM|AUTO|含设备问题
++|MES|
++|Report|
++|CFM|
++|OEE|
++|DEA|
++|SPC|
++
++Planning:
++
++|**类型**|**领域**|**子领域**|**备注**
++|(% rowspan="45" %)突发事件|(% rowspan="5" %)VDI|桌面系统问题|
++|应用程序问题|
++|客户端问题|
++|服务器端问题|
++|其它问题|
++|(% rowspan="4" %)OA|访问问题|
++|流程创建审批查阅问题|
++|信息更新问题|
++|其它问题|
++|(% rowspan="4" %)Email|outlook客户端问题|
++|exchange服务器端问题|
++|权限问题|
++|其它问题|
++|(% rowspan="5" %)网络|外网问题|
++|内网问题|
++|权限问题|
++|物理设备问题|
++|其它问题|
++|(% rowspan="4" %)共享目录|容量问题|
++|权限问题|
++|文件还原问题|
++|其它问题|
++|(% rowspan="3" %)电话系统|号码开通删除问题|
++|电话相关物理设备问题|
++|其它问题|
++|(% rowspan="3" %)PC及NB|系统问题|
++|应用程序问题|
++|硬件问题|
++|(% rowspan="3" %)外设|服务器端问题|
++|设备|
++|网络|
++|(% rowspan="3" %)KVM|转换流畅问题|
++|硬件问题|
++|其它问题|
++|(% rowspan="3" %)AD|退域|
++|加域|
++|其它问题|
++|(% rowspan="3" %)病毒|客户端问题|
++|服务器端问题|
++|其它问题|
++|SSO|NA|值班员接触不到
++|Window Server|NA|值班员接触不到
++|UNIX|NA|值班员接触不到
++|数据库|NA|值班员接触不到
++|Storage|NA|值班员接触不到
++|(% rowspan="45" %)服务请求|(% rowspan="5" %)VDI|桌面系统问题|
++|应用程序问题|
++|客户端问题|
++|服务器端问题|
++|其它问题|
++|(% rowspan="4" %)OA|访问问题|
++|流程创建审批查阅问题|
++|信息更新问题|
++|其它问题|
++|(% rowspan="4" %)Email|outlook客户端问题|
++|exchange服务器端问题|
++|权限问题|
++|其它问题|
++|(% rowspan="5" %)网络|外网问题|
++|内网问题|
++|权限问题|
++|物理设备问题|
++|其它问题|
++|(% rowspan="4" %)共享目录|容量问题|
++|权限问题|
++|文件还原问题|
++|其它问题|
++|(% rowspan="3" %)电话系统|号码开通删除问题|
++|电话相关物理设备问题|
++|其它问题|
++|(% rowspan="3" %)PC及NB|系统问题|
++|应用程序问题|
++|硬件问题|
++|(% rowspan="3" %)外设|服务器端问题|
++|设备|
++|网络|
++|(% rowspan="3" %)KVM|转换流畅问题|
++|硬件问题|
++|其它问题|
++|(% rowspan="3" %)AD|退域|
++|加域|
++|其它问题|
++|(% rowspan="3" %)病毒|客户端问题|
++|服务器端问题|
++|其它问题|
++|SSO|NA|值班员接触不到
++|Window Server|NA|值班员接触不到
++|UNIX|NA|值班员接触不到
++|数据库|NA|值班员接触不到
++|Storage|NA|值班员接触不到
++|(% rowspan="45" %)投诉与建议|(% rowspan="5" %)VDI|桌面系统问题|
++|应用程序问题|
++|客户端问题|
++|服务器端问题|
++|其它问题|
++|(% rowspan="4" %)OA|访问问题|
++|流程创建审批查阅问题|
++|信息更新问题|
++|其它问题|
++|(% rowspan="4" %)Email|outlook客户端问题|
++|exchange服务器端问题|
++|权限问题|
++|其它问题|
++|(% rowspan="5" %)网络|外网问题|
++|内网问题|
++|权限问题|
++|物理设备问题|
++|其它问题|
++|(% rowspan="4" %)共享目录|容量问题|
++|权限问题|
++|文件还原问题|
++|其它问题|
++|(% rowspan="3" %)电话系统|号码开通删除问题|
++|电话相关物理设备问题|
++|其它问题|
++|(% rowspan="3" %)PC及NB|系统问题|
++|应用程序问题|
++|硬件问题|
++|(% rowspan="3" %)外设|服务器端问题|
++|设备|
++|网络|
++|(% rowspan="3" %)KVM|转换流畅问题|
++|硬件问题|
++|其它问题|
++|(% rowspan="3" %)AD|退域|
++|加域|
++|其它问题|
++|(% rowspan="3" %)病毒|客户端问题|
++|服务器端问题|
++|其它问题|
++|SSO|NA|值班员接触不到
++|Window Server|NA|值班员接触不到
++|UNIX|NA|值班员接触不到
++|数据库|NA|值班员接触不到
++|Storage|NA|值班员接触不到
++
++
++=== **4.1.4. 影响范围代码** ===
++
++影响范围用于衡量事件所影响业务的范围。影响范围通常通过所影响的人数、关键系统数以及服务故障所造成的损失来设定。
++
++定义事件影响度等级的因素有：
++
++* 是否影响了关键应用
++* 所影响的用户范围
++* 服务失效的影响范围
++
++下表是当前定义的影响度，后续可根据实际变化进行调整。
++
++|序号|代码|描述
++|1| 公司|影响范围为全公司
++|2| 生产厂|影响范围为一个或多个厂
++|3| 产线|影响范围为一条或多条生产线
++|4| 个人|影响范围为一个或多个个人
++
++
++
++=== **4.1.5. 紧急程度代码** ===
++
++紧急程度决定事件需要处理的急迫程度。
++
++|序号|代码|描述
++|1|十分紧急|需要马上处理
++|2|紧急|需要2小时之内处理
++|3|一般|需要24小时之内处理
++|4|低|处理时间可以超过24小时
++
++===   ===
++
++=== **4.1.6. 优先级代码** ===
++
++优先级(Priority)决定了处理次序和期限。 期限可以在运行的过程中适当的调整，并且主要目的是通过升级的机制，让高层领导及时的了解在IT运维过程中发生的问题。优先级根据事件的影响度和事件的紧急度代码计算决定。算法为：优先级=[(影响范围+紧急程度)/2]. “[]”表示取整。
++
++|**序号**|**代码**|**描述**
++|1|一级|重大故障处理的优先级，用于严重影响业务应用的事故处理
++|2|二级|特殊服务事件的处理，用于紧急服务事件的处理
++|3|三级|一般故障处理的优先级，用于中等业务影响度的服务
++|4|四级|故障处理中最低的优先级，一般用于业务影响度低的服务，有时需要预约时间
++
++
++=== **4.1.7. 状态代码 ** ===
++
++状态代码表明事件所处的处理状态。
++
++缺省的状态如下：
++
++|**流程/功能**|**状态**|**说明**
++|(% rowspan="8" %)突发事件|已登记|突发事件登记后缺省状态
++|已分配|事件分配给了处理人员
++|已接受|被分配人接受了分配任务
++|已拒绝|被分配人拒绝了分配任务.
++|工作中|被分配人正在处理
++|已挂起|挂起等待客户信息，变更，厂商支持等.
++|已解决|已经解决，请求服务台与客户确认
++|已关闭|客户确认后关闭.
++|(% rowspan="4" %)服务台|已登记|交互单登记后的缺省状态
++|已升级|升级给了突发事件分析员
++|等待确认|等待客户确认解决方案
++|关闭|客户确认后关闭.
++
++注意：以上各个状态是对整个事件管理流程中可能的状态的总结，一个具体事件处理过程中，可能只是经过其中的几个状态。
++
++===   ===
++
++=== **4.1.8. 关闭代码** ===
++
++关闭代码说明了事件是在何种情况下关闭的。
++
++结合信息中心的实际，将采用如下关闭代码：
++
++|**序号**|**代码**|**描述**
++|1|超出范围|超出了信息中心支持范围
++|2|不能解决|现有条件无法解决，与客户解释后关闭
++|3|使用变通方法解决|通过临时措施解决
++|4|通过变更解决|发现了根本原因，通过变更解决
++|5|用户放弃|用户放弃
++|6|无法重现|无法重现客户报告的故障，与客户解释后同意关闭
++
++
++
++== **4.2. 服务台用户交互概要设计** ==
++
++服务台用户交互概要流程是根据华星光电IT信息中心的具体情况，结合HP ITSM的最佳经验，并通过与IT信息中心人员的共同讨论最终确定的。服务台用户交互概要流程主要从整体上描述用户交互的处理过程，不会体现具体的细节和涵盖所有的人员，但能够体现当前可能的输入和输出。
++
++
++=== **4.2.1. 流程图例说明** ===
++
++根据流程设计要求， 我们将服务台用户交互管理流程的设计标号以SO0开头，比如SO1.X.X。SO是Service Operation的缩写。
++
++===   ===
++
++=== **4.2.2. 概要流程描述** ===
++
++IT信息中心服务台用户交互管理概要流程具体如下：
++
++

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司