5.3 流程要素管理
本节主要阐述流程如何在实际 IT 服务项目中应用，流程如何进行测量、流程的关键绩效指标（Key Performance Index，简称 KPI）如何定义、流程操作执行成功的关键点。
5.3.1 概 述
流程/规程/流程管理
流程指为达到某个目的或目标，而以确定的方式执行或发生的一个或一系列有规律的行动或活动。
规程也称为标准作业程序（Standard Operation Procedure，简称 SOP），指将某一事件的标准操作步骤和要求以统一的格式描述出来，用来指导和规范日常的工作。简单说规程可理解为“规则+流程”。
流程是较为宽泛的概念，描述层级相对较高，而 SOP 是流程的细化和落地，除约定了活动执行的方式和顺序，更突出强调了各个活动的具体标准、执行条件、执行规范等。SOP 的精髓是将细节进行量化，即对某一程序中的关键控制点进行细化和量化。一套好 SOP 是确保产品或服务质量的必要条件。SOP 不仅仅是一套技术性范本，它更重要的涵盖了管理思想、管理理念和管理手段。
流程管理指为了使流程活动更有效，对流程采取的测量、考核、计划与控制措施。
客户 IT 服务需求是通过一个个流程及相关活动实现的，流程要素是 IT 服务需求实现的保障，流程活动的贯穿使服务更加轨道化、标准化、规范化，进而服务产出更加标准、稳定。流程的产出是由客户需求决定的，流程产出是否符合约定的客户服务目标，表明流程是否有效，流程投入的多少，表明了流程的工作效率。
流程管理模型
流程通常定义了活动、关系以及顺序、产出标准等信息，如图 5.1所示，它包括以下特性：
- 有明确的目标：流程存在的原因是为了交付特定的结果，结果必须具有独立性和可计量性，如可统计客户支持事件的个数；
- 具有可重复性：流程不是一次性，流程通常为解决具有重复性特征的服务需求而定义，这样可以确保流程持续性的应用效用发挥；
- 具有可衡量性：流程除了可依据交付目标衡量外，还可以根据管理控制需求对流程活动的成本、质量、持续时间进行衡量，除此之外，流程还可以对重复性事件进行统计衡量与评估，如各活动以及跨活动持续的平均时间，活动执行的时间方差，流程在特定时间段内的产出率等；
- 有明确的服务提供者和服务对象：流程是为最终客户服务的，没有客户的流程是没有意义的，是对服务组织资源的浪费。流程在为最终客户服务的同时，其每一个活动都有自身的客户，活动的客户可能是 IT 服务团队成员，也可能是最终客户，在一定程度上，活动是未进行更细致展开的子流程；
- 是对特定事件的响应：虽然一个流程可能是持续性的或重复性的，但其都有相应的驱动原因，如客户对平台稳定性的要求等；
- 本身的执行需要相应的信息输入：包括流程执行结果的反馈以及既有的知识、操作规程、数据信息等。
5.3.2 流程识别和定义
流程作为 ITSS 的核心要素之一，与其它要素相比具有一定的独特性，多数情况下流程不是显性的，通常看不见、摸不着，甚至说不清、道不明。但在面向客户的服务过程中是实实在在存在的，为了交付特定的 IT 需求，如未明确定义和说明具体流程，服务组织、第三方、客户之间通常会 “滋生”出相应的流程去实现交付目标。
流程及流程管理的优劣直接关系服务效率和效益。未明确识别定义的流程，在服务实践中难以标准化，服务质量难以把控，也无法准确的衡量。因此，需要对流程进行识别和明确定义。
目 标
流程识别和定义的目标主要包括：
- 流程符合可行性、适用性；
- 流程稳定，可重复使用；
- 流程符合效率要求；
- 流程符合效益要求；
- 流程可被监控和管理；
- 流程可追溯、审计；
- 流程可被衡量和评价。
活 动
识别客户服务内容、范围、目标、管理要求
流程最终是为交付合格的服务结果，流程的识别和定义首先要围绕客户服务内容、范围、目标、管理要求而展开。
识别需要的流程及流程目标
常用流程包括需求管理、事件管理、问题管理、变更管理、发布管理等管理流程。不同的服务协议需要配套不同的流程来实现。在具体 IT 服务项目中，应选择合适的流程服务去实现相应的目标。如客户协议中仅需要提供电话方式给予远程技术支持，则只需要建立配套的事件管理流程即可。选择合适的流程，同时要识别出合适的流程衡量标准，这些标准一般在服务协议中也有着明确的定义，如热线接通率、热线解决周期、满意度等。
定义角色和职责
对应选择的流程，定义相应的角色，如服务台支持工程师、现场工程师、二线支持专家、后台工程师等，并对各个角色的职责进行详细的职责描述。
识别流程的活动，定义活动的相互关系、顺序、活动目标、活动的资源限制及管理要求
在实践中，应根据客户管理要求以及服务协议的不同而进行细致的定义，包括识别流程需要的活动、各流程需要的输入输出目标、活动间的关系以及执行顺序。其中涉及与客户互动的活动环节，需要参考客户的意见来共同定义。
定义相关活动详细操作规程及衡量标准
流程活动的定义是相对高级别的操作汇总，为保障流程活动的目标达成，需要选择和定义更加细致的操作规程，如服务器系统安装操作规程、服务器重启作业操作规程等。具体操作规程依据服务实践中对风险的管理和接受要求来定义，如在无相关操作规程描述的情况下，风险仍在可控范围，则无需对所有场景都制定出严格的操作规程。最佳的服务实践是靠行为模式文化引导，而不是严格的流程和制度，所有的流程都细化到 SOP 是不经济的，也是不可取的。
定义流程的表单及信息记录保存要求
流程定义应包括详细描述流程各活动的信息记录，一方面标准化流程的输入、输出及处理，另一方面确保流程具有可追溯性和可审计性；
定义流程评价、评估及改进机制
对流程的评价衡量可结合服务协议约定的报告周期进行。但流程定义后，在服务实践中会因客户需求变化、流程本身设计等原因引发流程不再适用，需要对流程进行重新评估和改进。流程本身需要一定的稳定性，因此评估和改进周期可以半年或一年为周期进行一次；
参考示例
A 公司为解决日常大量的重复性客户桌面支持问题，将桌面支持服务外包给了 B 服务商。B 在服务实践中，建立了统一标准的 IT服务台，经与客户的磨合沟通，确立了如图 5.2所示三级客户支持体系：
B 公司分别就服务台工程师，二线专家、厂商定义了其角色及职责描述，其中服务台工程师职责定义为：
- 服务呼叫的接受、记录、跟踪和优先级排序；
- 已注册呼叫或投诉的处理状态跟进；
- 及时通知用户事件或请求的状态和处理进展；
- 对用户的请求做出评估，尝试解决或者将其指派给合适的人加以解决，保持服务级别；
- 监控客户支持事件并进行事件处理的升级管理全过程须满足服务协议的要求，才能根据此升级管理全过程来管理用户需求，包括记录、处理、结束和检查；
- 根据实际情况，就服务级别的任何变动及时与用户沟通；
- 与二线人员和第三方支持组织进行合作；
- 服务总结，为服务水平的改进提供参考和建议；
- 为问题管理提供相关的事件信息；
- 安排用户/服务台培训计划；
- 在获得用户的确认后关闭客户支持事件。
在操作规程方面，对服务台工程师设定了以下要求：
支持前：
- 应了解需要支持的内容、支持时间要求、SLA、之前的支持情况以及遗留问题，并与需方确认；
- 如果工作较为复杂或者存在风险，应提前做好预案经过审核后再实施；
- 应确保支持所需的工作条件满足安全、稳定和可用的要求。
支持过程中：
- 应严格按照服务台客户用语规范要求；
- 应按照约定的时间要求提供远程支持；
- 应与需方保持沟通；
- 应严格遵守需方的管理制度；
- 应根据交付实施的安全要求提供远程支持服务；
- 应只完成确认的工作内容；
- 如果遇到无法解决的问题或需方提出额外要求，应及时通知上级获取支持，得到授权后再做处理。
结束支持前：
- 应就遗留问题的处理建议和需方达成共识；
- 应做必要的安全检查，如清除临时账号、避免数据未授权拷贝等；
- 应在获得需方许可后才能结束远程支持工作。
结束支持后：
- 应调查交付服务的规范情况；
- 应调查交付服务的客户满意度；
- 应更新交付服务记录；
- 应就遗留问题寻找解决方案，跟踪解决。
客户支持服务表单及信息记录至少包括以下信息：
- 事件单据号、事件状态；
- 创建人信息：创建人、创建时间、登录帐号；
- 申请人信息：申请人、申请人邮箱、联系电话、所在公司、服务级别、办公工位；
- 事件总体信息：事件标题、事件描述、事件来源、事件重要程度、事件紧急程度、解决方案、事件解决人、解决时间、解决方式；
- 事件处理历史信息：转移人、处理人、诊断及补充信息、所采取的支持及操作、开始时间、解决时间。
5.3.3 流程KPI设计
目 的
通过 KPI 的设计、实现对流程及其活动的监控及衡量，进而保障流程目标的达成，流程 KPI设计的目标包括：
- 通过分层细化流程 KPI，确保流程可管理性、可衡量性；
- 控制风险，消除因未明确定义而引发的潜在风险；
- 对流程进行定期评价与衡量，改进调整 KPI 设计，保持流程的有效性。
原 则
流程 KPI 指标应符合 SMART 原则，参见 4.2.4章节。
活 动（流程 KPI 设计方法）
流程 KPI 设计通常采用如下流程：
（1）确定流程 KPI指标
通常在与客户的服务协议中已有明确的指标说明，在服务实践中，服务团队为了保障服务质量，自身会补充设置更多关联性的 KPI指标，这些指标未写进服务协议中，但对服务协议各项目标的达成起到了实际的操作级保障，可以采用下图所示的层层分解法进行 KPI 指标设计。
- 定义整体流程 KPI：可直接将服务协议中的指标作为流程的 KPI 指标进行转换定义，如服务协议中的工作时间、客户满意度、解决周期、稳定率等；
- 定义各流程角色 KPI：如定义一线问题解决率、一线错误转移的事件比率、一线未解决 30 分钟内实现转移比例等；
- 定义活动及子流程 KPI：同角色 KPI设计，为更有效的保障最终客户服务协议目标的达成， 需要在各活动风险点设定相应的 KPI 指标，以确保各环节的风险在可控的范围内；针对活动的指标可定义为：LINUX 系统装机周期<3 小时；设备送外修时间<1 周等。
（2）明确 KPI计算方法
KPI 指标的计算方法应明确定义，避免产生争议。如客户满意度计算中，客户未填写反馈信息的服务事件是否纳入统计中，是否列入满意范围等；再例如客户投诉的界定，是否拨打投诉电话都界定为投诉，是否给予申述机会等。
（3）明确 KPI信息来源
KPI 考核指标的衡量，需要获得供需双方共同信任的信息来源，如满意度来自于系统平台的客户满意度反馈，故障解决周期基于系统的时间记录等。
（4）定义 KPI考核周期
依据 SMART 原则，指标的订立要有明确的时间期限说明，时间期限也即 KPI 考核周期，不同流程 KPI，考核周期不同，日常监控管理要求越高，统计数量级大，考核的频度要求越高，如热线平均解决周期可以周为单位进行考核；反之，日常监控管理要求低，且数量级很小，KPI 考核周期相对设置较长，如对投诉，可以季度为单位。
（5）定义流程 KPI评价、评估及改进机制
按协议约定的报告周期对流程 KPI 进行评价与评估。在服务实践中会因客户需求变化、流程KPI 本身设计、流程各级活动及子流程的管理控制要求不同等原因引发流程 KPI 设计的调整，需要对流程 KPI进行重新评估和改进。
参考实例
VIP 客户：指经A 公司正式发文任命的总裁、高级副总裁、副总裁、助理总裁人员； 重要客户：指经A 公司正式发文任命的总经理、副总经理、总监人员；
普通客户：不属于VIP 及重要客户的A 公司正式员工。
5.3.4 流程监控考核
流程一旦定义完成，需要在控制管理下才能正常发挥作用，处于良好控制下的流程，可以持续产生效用，可管理性也更强。没有控制的流程，会流于形式，形同虚设，无法真正的发挥效用。
目 标
- 确保流程执行的规范性、有效性，进而确保服务质量的达成；
- 及时发现流程执行中的问题，采取应对及改进措施；
- 对流程本身进行评估，持续改进优化流程。
活 动
流程监控考核的主要活动，包括：
流程监控
监控流程的执行，并及时采取干预应对措施，在办公流程电子化的今天，IT 服务流程 KPI 通常设定到电子流程中，如数据中心核心交换机报警信息在 5分钟内仍无人打开处理，将自动短信升级通告到上级主管。
流程审计
通过事后审计的方式也可加强 IT 服务流程执行的约束力，如对于核心应用故障处理流程，可按照核心应用故障处理流程中约定，面向业务方应用管理员调研、查阅故障处理报告、应用系统日志、邮件及网络发文日志等了解是否严格执行了处理流程。
流程 KPI考核
可通过对单一事件或一定周期内事件处理进行综合统计分析，以便确认 KPI 指标是否达成，如服务协议约定事件解决周期<4小时，但每月有 3个事件解决周期可超过 4小时，但最长不能超过 8 小时，通过对当月所有事件的统计分析，可考察整体流程目标是否达成。
5.3.5 流程的优化改进
流程管理应采用 PDCA 持续改进过程，具体流程改进内容，可参见第 6章。
************************************************************* 返回到首页 《ITSS认证IT服务项目经理培训教材》_试用版连载http://ITIL-foundation.cn/thread-36762-1-1.htmlITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员（People）、流程[1]（Process）、技术（Technology）和资源（Resource），简称PPTR、规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision），简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群：21542747
| 
转播
分享
淘帖
()