20151118  淡然

续上

3.3              实施ITIL流程改进

流程是指按照一个既定的目标组织起来的一组逻辑上相关的活动。一个流程是将输入转化为输出的一组活动，我们可以通过质量特征和标准来比较每个流程的输入和输出，并提供该流程目标实现情况方面的信息。具体流程设计时，我们会从流程概述、流程范围、流程制定策略和流程详述四个方面来开展流程设计。                                           ITSS考试

本期项目中，我们将实施8大流程，同时，我们也对其他的流程进行了规划，根据第2章制定的流程改进点，这里按照各个流程进行了分类汇总如下：

3.3.1      故障管理流程改进方案

编号	实施阶段	现状	应对条款	改进建议	优先级
IM1	本期实施	服务台关闭事件不够及时，工程师未按规范要求操作单据状态，无法正确反映故障管理流程的KPI实际情况	故障管理	制定规范要求工程师准确记录事件处理状态，及时挂起事件，以便于收集正确的事件处理时长；语音平台需传送主叫号和通话时长；优化工单关闭操作规范	中
IM2	本期实施	服务台工作人员没有完全遵照既定的问答脚本和统一礼貌用语回答用户的问题。	故障管理	优化服务台管理规范、问答脚本、规范用语等	低
IM3	本期实施	服务台查询配置库的操作不够便利，无法实时对用户信息与资产信息进行核对	故障管理	SM平台开发功能，让服务台登记事件时可即时查询用户、资产和配置信息	中
IM4	本期实施	故障管理中用户已有基本的分级方式，但无事件影响度、紧急度等优先级分类的准则	故障管理 ISO20000 8.2 事件分类与分级依据《项目作业书》	结合SLA制定事件分类、分级原则	高
IM5	本期实施	未及时完工的事件可能会被忽略或者不能及时升级	故障管理	开发和设置系统自动超时告警、升级功能	中
IM6	本期实施	服务台未将咨询来电记录下来，导致很多来电无法跟踪，影响服务台绩效指标和整体服务质量	故障管理	在未来的工具中，将咨询类的来电也做为事件或服务请求登记在案	中
IM7	本期实施	服务台即将升级的语音平台与即将上线的 SM管理平台的服务台功能部分重叠	故障管理	与外包商协商开发接口，协调操作功能整合。由于需要把所有流程关联起来，如服务台界面和事件，服务台界面和变更、服务台界面和请求等，语音平台自带的所有ITSM流程相关的功能都应该集成到 SM管理平台上                     ITSS认证	中
IM8	本期实施	事件管理没有与监控系统接口，无法记录监控报警类事件	故障管理	考虑开发事件管理与监控系统的接口（监控系统需开放接口），将监控系统传过来的信息自动登记为事件。	中
IM9	本期实施	服务台没有文档化的供应商联络制度	故障管理	建立成文的供应商联络制度，区分保内、保外操作规范	中
IM10	本期实施	由于工具功能限制，事件管理流程KPI指标还有待完善	故障管理 ISO20000 8.2 IM6重大事件需要单独进行分析与报告	完善绩效指标：一线解决率、SLA达标率、接通等待时长、通过web提交的请求、及时响应率、首次正确派单率、事件平均解决时间、事件满意度评分、事故总数、通过监控产生的事件百分比	中
IM11	本期实施	应用维护工作尚未建立有效的事件管理机制	故障管理 ISO20000 8.2 所有事件都通过事件管理程序处理	在事件管理机制中考虑应用维护工作	中
IM12	本期实施	新应用系统在暂管期间，无法监管升级给项目团队的事件单	故障管理 ISO20000 8.2 所有事件都通过事件管理程序处理	服务台监控事件单的状态，并及时通报状态和关闭事件	低

3.3.2      问题管理流程改进方案

编号	实施阶段	现状	应对条款	改进建议	优先级
PM1	本期实施	暂无文档化的问题管理流程，使用交班会形式来进行基础性的问题管理活动	问题管理 ISO20000 8.3 流程综述：记录识别所有的问题	建立问题管理流程，确定流程接口人制度，确定四个团队的问题入口方式：开发团队、网络团队、应用管理团队、桌面维护团队	高
PM2	本期实施	目前的问题流程除与事件管理流程有接口外，和其他流程尚无接口	问题管理	与知识库、配置、变更管理流程集成	高
PM3	本期实施	通过日常监控和巡查措施，建立了初步的主动问题识别机制，尚不能很好地预防问题的发生	5.3.1流程综述：记录识别所有的问题	加强与日常运维等流程的融合，建立主动问题识别规范	中
PM4	本期实施	具有初步的事件升级问题的机制，及时性和准确性还有待提高	问题管理	改进事件升级问题的机制	中
PM5	本期实施	目前对问题无任何分类和分级机制，造成问题解决安排上不合理，重大和紧急类问题不能得到优先处理	问题管理 ISO20000 8.3 流程综述：问题要记录、分类解决和关闭	对问题进行分类和分级梳理，考虑与事件管理的分类和分级方法保持一致	中
PM6	本期实施	尚无问题关闭和变更实施后评审制度，造成问题实施效果没有得到应有的回顾	问题管理 ISO20000 8.3 PM12：问题处理情况每月进行分析	建立问题关闭流程，建立RFC实施后评审制度                      ITSS培训	中
PM7	本期实施	对于某个事件可能由未知的原因导致的，多个部门涉及到需要各自找问题根源，但没有相关协同工作机制，可能会造成互相推诿	问题管理	这类事件即时升级为问题，并在安排一个主要团队负责该问题时，系统同时派生一个或多个协查问题工单给其他团队，便于多个团队协同工作。进一步，可以考虑成立运维管理办公室，专门负责跨部门跨项目的协调问题	低
PM8	本期实施	目前问题流程无KPI指标	问题管理 ISO20000 8.3 PM12：问题处理情况每月进行分析	绩效指标和报表：问题解决率、已关闭的问题数量、问题流程提交RFC的数量、开放问题的平均数量、问题解决时长、未解决关闭的时间百分比、前5名问题类别、主动问题占比

待续http://ITIL-foundation.cn/thread-53221-1-1.html

本帖关键字：ITSS

20151118  淡然

续上

3.3              实施ITIL流程改进

流程是指按照一个既定的目标组织起来的一组逻辑上相关的活动。一个流程是将输入转化为输出的一组活动，我们可以通过质量特征和标准来比较每个流程的输入和输出，并提供该流程目标实现情况方面的信息。具体流程设计时，我们会从流程概述、流程范围、流程制定策略和流程详述四个方面来开展流程设计。                                           ITSS考试

本期项目中，我们将实施8大流程，同时，我们也对其他的流程进行了规划，根据第2章制定的流程改进点，这里按照各个流程进行了分类汇总如下：

3.3.1      故障管理流程改进方案

编号	实施阶段	现状	应对条款	改进建议	优先级
IM1	本期实施	服务台关闭事件不够及时，工程师未按规范要求操作单据状态，无法正确反映故障管理流程的KPI实际情况	故障管理	制定规范要求工程师准确记录事件处理状态，及时挂起事件，以便于收集正确的事件处理时长；语音平台需传送主叫号和通话时长；优化工单关闭操作规范	中
IM2	本期实施	服务台工作人员没有完全遵照既定的问答脚本和统一礼貌用语回答用户的问题。	故障管理	优化服务台管理规范、问答脚本、规范用语等	低
IM3	本期实施	服务台查询配置库的操作不够便利，无法实时对用户信息与资产信息进行核对	故障管理	SM平台开发功能，让服务台登记事件时可即时查询用户、资产和配置信息	中
IM4	本期实施	故障管理中用户已有基本的分级方式，但无事件影响度、紧急度等优先级分类的准则	故障管理 ISO20000 8.2 事件分类与分级依据《项目作业书》	结合SLA制定事件分类、分级原则	高
IM5	本期实施	未及时完工的事件可能会被忽略或者不能及时升级	故障管理	开发和设置系统自动超时告警、升级功能	中
IM6	本期实施	服务台未将咨询来电记录下来，导致很多来电无法跟踪，影响服务台绩效指标和整体服务质量	故障管理	在未来的工具中，将咨询类的来电也做为事件或服务请求登记在案	中
IM7	本期实施	服务台即将升级的语音平台与即将上线的 SM管理平台的服务台功能部分重叠	故障管理	与外包商协商开发接口，协调操作功能整合。由于需要把所有流程关联起来，如服务台界面和事件，服务台界面和变更、服务台界面和请求等，语音平台自带的所有ITSM流程相关的功能都应该集成到 SM管理平台上                     ITSS认证	中
IM8	本期实施	事件管理没有与监控系统接口，无法记录监控报警类事件	故障管理	考虑开发事件管理与监控系统的接口（监控系统需开放接口），将监控系统传过来的信息自动登记为事件。	中
IM9	本期实施	服务台没有文档化的供应商联络制度	故障管理	建立成文的供应商联络制度，区分保内、保外操作规范	中
IM10	本期实施	由于工具功能限制，事件管理流程KPI指标还有待完善	故障管理 ISO20000 8.2 IM6重大事件需要单独进行分析与报告	完善绩效指标：一线解决率、SLA达标率、接通等待时长、通过web提交的请求、及时响应率、首次正确派单率、事件平均解决时间、事件满意度评分、事故总数、通过监控产生的事件百分比	中
IM11	本期实施	应用维护工作尚未建立有效的事件管理机制	故障管理 ISO20000 8.2 所有事件都通过事件管理程序处理	在事件管理机制中考虑应用维护工作	中
IM12	本期实施	新应用系统在暂管期间，无法监管升级给项目团队的事件单	故障管理 ISO20000 8.2 所有事件都通过事件管理程序处理	服务台监控事件单的状态，并及时通报状态和关闭事件	低

3.3.2      问题管理流程改进方案

编号	实施阶段	现状	应对条款	改进建议	优先级
PM1	本期实施	暂无文档化的问题管理流程，使用交班会形式来进行基础性的问题管理活动	问题管理 ISO20000 8.3 流程综述：记录识别所有的问题	建立问题管理流程，确定流程接口人制度，确定四个团队的问题入口方式：开发团队、网络团队、应用管理团队、桌面维护团队	高
PM2	本期实施	目前的问题流程除与事件管理流程有接口外，和其他流程尚无接口	问题管理	与知识库、配置、变更管理流程集成	高
PM3	本期实施	通过日常监控和巡查措施，建立了初步的主动问题识别机制，尚不能很好地预防问题的发生	5.3.1流程综述：记录识别所有的问题	加强与日常运维等流程的融合，建立主动问题识别规范	中
PM4	本期实施	具有初步的事件升级问题的机制，及时性和准确性还有待提高	问题管理	改进事件升级问题的机制	中
PM5	本期实施	目前对问题无任何分类和分级机制，造成问题解决安排上不合理，重大和紧急类问题不能得到优先处理	问题管理 ISO20000 8.3 流程综述：问题要记录、分类解决和关闭	对问题进行分类和分级梳理，考虑与事件管理的分类和分级方法保持一致	中
PM6	本期实施	尚无问题关闭和变更实施后评审制度，造成问题实施效果没有得到应有的回顾	问题管理 ISO20000 8.3 PM12：问题处理情况每月进行分析	建立问题关闭流程，建立RFC实施后评审制度                      ITSS培训	中
PM7	本期实施	对于某个事件可能由未知的原因导致的，多个部门涉及到需要各自找问题根源，但没有相关协同工作机制，可能会造成互相推诿	问题管理	这类事件即时升级为问题，并在安排一个主要团队负责该问题时，系统同时派生一个或多个协查问题工单给其他团队，便于多个团队协同工作。进一步，可以考虑成立运维管理办公室，专门负责跨部门跨项目的协调问题	低
PM8	本期实施	目前问题流程无KPI指标	问题管理 ISO20000 8.3 PM12：问题处理情况每月进行分析	绩效指标和报表：问题解决率、已关闭的问题数量、问题流程提交RFC的数量、开放问题的平均数量、问题解决时长、未解决关闭的时间百分比、前5名问题类别、主动问题占比

待续http://ITIL-foundation.cn/thread-53221-1-1.html

本帖关键字：ITSS