20150605MONICAZHANG

续上

3.3流程执行原则

3.2.7流程常规原则

所有在流程范围内发生的事件，都应该被完整准确的记录下来，记录的信息应足够详细，包括用户的信息、事件的症状、详细的解决方案等。ITSS考试

事件处理过程中，在需要寻求厂商的情况下，要遵循下述原则：

-根据事件处理的实际需要，由三线联系相关厂商处理事件。

-在供应商参与解决事件的过程中，事件的当前责任人仍为相应的三线人员。

所有支持人员必须优先处理优先级较高的事件。ITSS团购

对于接入服务台的事件（包括故障/服务请求/咨询），首次接听电话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件的责任人，确保该事件得到有效的跟踪、解决，并将解决结果反馈给用户。

每月定期产生事件管理报表，分析服务质量，对重大事件、多次重复发生的事件或者利用变通方法解决的事件。

3.2.8责任制原则

责任制原则用来确保每个事件在任何时段都有适当的人员负责。

由监控系统发现的事件，对故障进行识别并在系统中记录的服务台人员是该事件的责任人，确保事件得到有效的跟踪与解决，并负责事件单的关闭。ITSS团购

由用户电话上报的事件，首次接听电话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭。

采用首问负责制，由事件的首接受理人或者创建人负责客户可能的查询。

事件被服务台人员转至二线或三线后，承接人员则成为该事件的当前责任人，分派方（做出分派或是转派的人员）有责任通知被分派的技术人员并要求他接受或是拒绝此事件单。服务台人员仍然是事件的整体负责人，有义务对事件处理状态进行监控，并及时反馈给用户，保证用户可以随时了解事件的处理状况。

3.2.9事件分派原则

事件分派原则是确保事件被分派到合适的服务支持团队来解决的重要原则。ITSS软件

服务台/一线人员根据事件发生的地点和具体情况在一线、二线、三线之间进行任务分派。一般的，如果能够通过远程解决的故障，分配给一线，选择本人或其他服务人员为处理人。如果需要现场解决的故障，分配给二线，需要专业人员才能解决的，分配给三线。

二线支持人员在规定时间内无法解决问题，原则上就根据事件分类分派给相应的信息部三线支持人员。

当信息部的三线运维人员在规定时间内无法解决后，可联系开发商来共同解决问题。如果处理时间超时，则需要按照升级原则将事件升级。

3.2.10事件重分派原则

二线支持接到服务台分派的事件后，如果该事件不属于本人支持范围或者自身能力无法处理，则注明事件原因，返回服务台重新分派。三线人员则直接注明原因，将事件返回服务台重新分派。

为提高事件解决效率，应当尽量减少事件单重分派的几率。事件单的重分派次数不应该超过3次。若超过3次，则升级给事件经理。ITSS体系

3.2.11重复/复发事件原则

重复事件

如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的。为此重复的事件创建新的事件单，标注此单为“重复”并与原始事件单相关联。原始事件将被标注为“主事件”。

复发事件

如果报告的事件与已经关闭的事件相同，该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时，应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。

3.2.12代转交原则ISO20000培训

代转交是指在用户绕过服务台直接找到运维人员进行事件报障和提出服务请求时，运维人员可以代替用户向服务台进行事件报障和提出服务请求的原则。

同一工程师对同一用户的事件报障和服务请求最多仅能代转交3次。超出3次代转交发生时，运维工程师可以委婉的拒绝代转交行为。

每次代转交发生时服务工程师应对用户进行服务台联系方式、使用方法的宣贯。

代转交制度根据实际情况应在系统上线后3-6个月内废止。

3.2.13巡检原则

巡检包括终端设备巡视检查和统计、网络机房巡视检查、监控室及IDC机房清洁。

每半年进行终端设备巡视检查和统计工作

每季度进行网络机房巡视检查

每半月进行监控室及IDC机房清洁

3.2.14事件关闭原则

事件单的关闭必须由服务台对应支持人员完成，但是事件经理可以超越此规则，其他人无权关闭事件单。二、三线支持人员确定解决方案并解决事件后，必须把事件返回到服务台。

事件单的用户可以直接要求关闭此事件单，例如：误报、错报事件。关闭事件单的具体操作由事件对应的服务台支持人员负责。

服务台人员关闭事件前，一般需获得客户对解决方案的确认和反馈。

通过电子化方式所开展的用户确认（邮件、电子问卷调查），在指定时间内，用户没有作出反馈时，事件可按默认方式自动进行关闭。ITSS培训

关闭事件时，根据实际解决情况填写事件的结束代码。

已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单，并标识为复发事件。

3.2.15事件升级原则

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关管理人员，引起足够的重视，协助提供合适的资源，从而快速找到解决事件的方案。

紧急事件

紧急事件是指对业务或用户的影响极大或影响面非常大的事件。

升级标准：优先级为紧急。

处理流程：

立即将情况同时通知给相关管理员、事件经理、信息部主任、信息部专责：E-mail、电话、短信等方式通知；

必要的话，事件经理跟相关人员召开一个有关此事件的正式会议，参加人员包括：信息部主任、一线支持、二线支持、三线支持，来讨论此事件的解决方案；

未能及时解决的问题。

升级标准：超过解决期限但尚未解决的问题。ITSS认证

处理流程：

将情况同时通知给事件经理（由信息部主任担任）：E-mail、电话、短信等方式通知；

必要的话，事件经理跟相关人员召开一个有关此问题的正式会议，参加人员包括：事件经理、相关技术运维人员等来讨论该事件的具体情况。

3.2.16事件状态转化原则

当三线支持人员填写厂商信息时，事件单的状态为“厂商处理中”。

当三线支持人员在厂商信息单上填写解决时，事件单的状态转化为“三线处理中”。

其他转化依据事件状态的相关定义描述。

3.2.17交互单使用原则

服务台接听报障电话时，系统通过CTI接口可自动弹出交互单界面，交互单显示报障人相关信息（姓名、座机、手机、部门、职位）。服务台可由交互单转成事件单，完成事件登记过程。

事件解决之后，需要进行客户确认工作，通过交互单进行满意度调查。

3.2.18事件引发问题管理原则

事件管理流程在产生事件单之后的任一阶段均可以由一线，三线人员触发问题管理流程。ITIL培训

待续:http://www.ITILxf.com/thread-48899-1-1.html

本帖关键字：ITSSISO20000

20150605MONICAZHANG

续上

3.3流程执行原则

3.2.7流程常规原则

所有在流程范围内发生的事件，都应该被完整准确的记录下来，记录的信息应足够详细，包括用户的信息、事件的症状、详细的解决方案等。ITSS考试

事件处理过程中，在需要寻求厂商的情况下，要遵循下述原则：

-根据事件处理的实际需要，由三线联系相关厂商处理事件。

-在供应商参与解决事件的过程中，事件的当前责任人仍为相应的三线人员。

所有支持人员必须优先处理优先级较高的事件。ITSS团购

对于接入服务台的事件（包括故障/服务请求/咨询），首次接听电话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件的责任人，确保该事件得到有效的跟踪、解决，并将解决结果反馈给用户。

每月定期产生事件管理报表，分析服务质量，对重大事件、多次重复发生的事件或者利用变通方法解决的事件。

3.2.8责任制原则

责任制原则用来确保每个事件在任何时段都有适当的人员负责。

由监控系统发现的事件，对故障进行识别并在系统中记录的服务台人员是该事件的责任人，确保事件得到有效的跟踪与解决，并负责事件单的关闭。ITSS团购

由用户电话上报的事件，首次接听电话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭。

采用首问负责制，由事件的首接受理人或者创建人负责客户可能的查询。

事件被服务台人员转至二线或三线后，承接人员则成为该事件的当前责任人，分派方（做出分派或是转派的人员）有责任通知被分派的技术人员并要求他接受或是拒绝此事件单。服务台人员仍然是事件的整体负责人，有义务对事件处理状态进行监控，并及时反馈给用户，保证用户可以随时了解事件的处理状况。

3.2.9事件分派原则

事件分派原则是确保事件被分派到合适的服务支持团队来解决的重要原则。ITSS软件

服务台/一线人员根据事件发生的地点和具体情况在一线、二线、三线之间进行任务分派。一般的，如果能够通过远程解决的故障，分配给一线，选择本人或其他服务人员为处理人。如果需要现场解决的故障，分配给二线，需要专业人员才能解决的，分配给三线。

二线支持人员在规定时间内无法解决问题，原则上就根据事件分类分派给相应的信息部三线支持人员。

当信息部的三线运维人员在规定时间内无法解决后，可联系开发商来共同解决问题。如果处理时间超时，则需要按照升级原则将事件升级。

3.2.10事件重分派原则

二线支持接到服务台分派的事件后，如果该事件不属于本人支持范围或者自身能力无法处理，则注明事件原因，返回服务台重新分派。三线人员则直接注明原因，将事件返回服务台重新分派。

为提高事件解决效率，应当尽量减少事件单重分派的几率。事件单的重分派次数不应该超过3次。若超过3次，则升级给事件经理。ITSS体系

3.2.11重复/复发事件原则

重复事件

如果被报告的事件与某个已经创建且尚未解决的事件单症状相同，则该事件被认为是重复的。为此重复的事件创建新的事件单，标注此单为“重复”并与原始事件单相关联。原始事件将被标注为“主事件”。

复发事件

如果报告的事件与已经关闭的事件相同，该事件被认为是“复发”的事件单。这意味着为了解决事件而采取的解决措施失败了。此时，应当创建一个新的事件单，复制原始事件单的内容，并说明这是复发的事件。

3.2.12代转交原则ISO20000培训

代转交是指在用户绕过服务台直接找到运维人员进行事件报障和提出服务请求时，运维人员可以代替用户向服务台进行事件报障和提出服务请求的原则。

同一工程师对同一用户的事件报障和服务请求最多仅能代转交3次。超出3次代转交发生时，运维工程师可以委婉的拒绝代转交行为。

每次代转交发生时服务工程师应对用户进行服务台联系方式、使用方法的宣贯。

代转交制度根据实际情况应在系统上线后3-6个月内废止。

3.2.13巡检原则

巡检包括终端设备巡视检查和统计、网络机房巡视检查、监控室及IDC机房清洁。

每半年进行终端设备巡视检查和统计工作

每季度进行网络机房巡视检查

每半月进行监控室及IDC机房清洁

3.2.14事件关闭原则

事件单的关闭必须由服务台对应支持人员完成，但是事件经理可以超越此规则，其他人无权关闭事件单。二、三线支持人员确定解决方案并解决事件后，必须把事件返回到服务台。

事件单的用户可以直接要求关闭此事件单，例如：误报、错报事件。关闭事件单的具体操作由事件对应的服务台支持人员负责。

服务台人员关闭事件前，一般需获得客户对解决方案的确认和反馈。

通过电子化方式所开展的用户确认（邮件、电子问卷调查），在指定时间内，用户没有作出反馈时，事件可按默认方式自动进行关闭。ITSS培训

关闭事件时，根据实际解决情况填写事件的结束代码。

已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单，并标识为复发事件。

3.2.15事件升级原则

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关管理人员，引起足够的重视，协助提供合适的资源，从而快速找到解决事件的方案。

紧急事件

紧急事件是指对业务或用户的影响极大或影响面非常大的事件。

升级标准：优先级为紧急。

处理流程：

立即将情况同时通知给相关管理员、事件经理、信息部主任、信息部专责：E-mail、电话、短信等方式通知；

必要的话，事件经理跟相关人员召开一个有关此事件的正式会议，参加人员包括：信息部主任、一线支持、二线支持、三线支持，来讨论此事件的解决方案；

未能及时解决的问题。

升级标准：超过解决期限但尚未解决的问题。ITSS认证

处理流程：

将情况同时通知给事件经理（由信息部主任担任）：E-mail、电话、短信等方式通知；

必要的话，事件经理跟相关人员召开一个有关此问题的正式会议，参加人员包括：事件经理、相关技术运维人员等来讨论该事件的具体情况。

3.2.16事件状态转化原则

当三线支持人员填写厂商信息时，事件单的状态为“厂商处理中”。

当三线支持人员在厂商信息单上填写解决时，事件单的状态转化为“三线处理中”。

其他转化依据事件状态的相关定义描述。

3.2.17交互单使用原则

服务台接听报障电话时，系统通过CTI接口可自动弹出交互单界面，交互单显示报障人相关信息（姓名、座机、手机、部门、职位）。服务台可由交互单转成事件单，完成事件登记过程。

事件解决之后，需要进行客户确认工作，通过交互单进行满意度调查。

3.2.18事件引发问题管理原则

事件管理流程在产生事件单之后的任一阶段均可以由一线，三线人员触发问题管理流程。ITIL培训

待续:http://www.ITILxf.com/thread-48899-1-1.html

本帖关键字：ITSSISO20000