1、 第 1 页 HP Consulting Confidential HP IT 系统运维管理流程构建方法 本文档包含准备及组织与客户有关人员进行研讨并最终为客户构建IT 系统运维流程方法的详细论述 ， 基于 HP 的 IT Service Management（ ITSM） 咨询 方法论 。 而进行此类研讨则确保了运维流程设计的准确性，并保证所设计流程能够顺利地在 IT 部门内得以实施。 1.0 简介 在新的 IT 系统得以成功的应用之前， IT 部门内必须完成针对新的业务系统环境的运行管理流程的设计。为了正确地设计相应的流程，在客户现场进行的相关研讨会将是获取客户相应需求的重要手段。 有效地
2、控制此类研讨会的时间长度是确保与会人员集中精力的重要手段。由客户相关领导在会前强调 此类会议重要性的讲话通常会确保与会者对会议给予高度重视。 本文档分两部分： 1. 研讨会中用于设计运行维护管理流程的方法 第 2 页 HP Consulting Confidential 2. 研讨会的成果 （逻辑运行维护管理流程图，工作流程描述，物理运行维护管理流程图，运行管理工作流程指导） 2.0 运维流程的设计 2.1 研讨会前期的准备 每一个项目都是由不同的各个阶段组成的，在实质性的运行维护管理流程设计工作进行之前，一个前期的准备工作是必不可少的。在本项目中，前期的准备工作应包括： 1. 创建用于“最佳
3、成功范例”研讨所用文档 2. 将流程设计及实施过程中的“策略性关键决策 问题”列表 3. 组织客户相应员工进行 ITSM 相关培训，以期使他们在运行管理流程实施前对 ITSM 流程有基本的认识。 4. 将需进行的研讨会日期进行列表，同时确定 HP 及客户双方应参加研讨会的人员名单。有些项目相关人员会参加多个研讨会。 2.2 研讨会的具体内容 要进行的研讨会应被划成两个阶段： 逻辑设计阶段： 第一部分： 回答策略性关键决策问题 讨论 ITIL 最佳成功范例 第二部分： 设计逻辑运行维护管理流程 物理设计阶段： 第 3 页 HP Consulting Confidential 第一部分： 设计物理
4、运行维护管理流程 第二部分： 创建运行 管理工作流程指导 研讨会阶段性工作的结果将在本文档中的第三部分给予详细的解释。为了成功地完成本阶段工作，每一次研讨会的进度需要被严格地监控。在进行本阶段工作时， 80/20 规则应被广泛采纳，即在运行管理流程的开发和设计过程中，当一个设计方案或答案已经被 80%的参加讨论人员认可，则我们可以认为该方案或答案已满足要求而不需进一步改进。运行管理流程的设计过程可以通过一些开放式的讨论来进行。在讨论的过程中，所有参加讨论的人员可以将其想法罗列出来，而后由讨论的组织者将它们分别按逻辑分组归类。 如果在研讨的过程中 出现了在一定时间内无法解决的问题，应由组织者将其
5、记录在案。对于上述的每一个问题，应由一个研讨参加者负责于第二天给出相应的答案或解释。在此再次强调，研讨的时间控制是本步骤中非常重要的一个环节。研讨会结束后，应产生出如下的结果： 运行维护管理流程的任务范围 图形化的逻辑运行维护管理流程 图形化的物理运行维护管理流程 物理运行维护管理流程中每一步的详细说明 针对应用“ ITIL 最佳成功范例”研讨的答案 针对于策略性关键决策问题研讨的答案 运行维护管理各流程间的依赖关系 工作职责描述 第 4 页 HP Consulting Confidential 无法解决问题文档 本文档的下 一部分将针对以上各项内容做具体的描述 第 5 页 HP Consul
6、ting Confidential 运行维护管理流程的任务范围 必须对 每一个 运行维护管理流程提供相应的任务范围描述。本文档为客户管理人员了每一个流程所涉及工作范围的清晰描述，并为每一名与流程执行相关的员工充分了解各流程的作用提供了学习的依据。 图形化的逻辑运行维护管理流程 逻辑运行维护管理流程描述了每一个流程从开始至结束所包含的每一个步骤及所牵涉的客户相关工作人员。同时包涵与流程相关的其它各方面因素。 逻辑运行维护管理流程对所需流程的一个高层次的描述。本流程中的每一步骤代表或可以被分解为若干个物 理运行维护管理流程。相关逻辑运行维护管理流程请参见“附录一 “。 图形化的物理运行维护管理流程
7、 物理运行维护管理流程详细地描述了流程从起始至结束的每一步。具体物理运行维护管理流程需根据研讨会讨论结果结合客户大集中的实际情况进行客户化设计 。 物理运行维护管理流程的详细说明 物理运行维护管理流程的详细说明包含了如何执行各流程中每一个步骤的说明。例如，本说明中应包含对需使用工具所进行的每一步操作的说明。对各步骤的描述方法应采用统一、标准的语言格式。同时应建立对本文档的审核流程。例如，对每一个流程的说明文档， 在其被最终采用以前应被至少三名员工审核。每一次审核应着重于不同的角度，例如，技术上的正确性、功能上的正确性、及文档总体上的正确性。 第 6 页 HP Consulting Confid
8、ential 针对应用“ ITIL 最佳成功范例”的答案 一个相对独立的文档罗列出 ITIL 所总结出的“ 最佳成功范例”。研讨会后一个非常重要的文档即哪些成功范例可以被客户所采纳。本文档亦会描述哪些设计好的流程与 ITIL 提供的成功范例所不符，及造成该种局面的特殊原因。特别需要说明的是，所有设计好的逻辑及物理流程均需考虑其与 ITIL 最佳成功范例的一致性。从另一个角度，最佳成功范例亦可为各种流程设计 的合理性提供具有建设性的建议及依据。 有关 ITIL 最佳成功范例的详细信息请参见 “附录 二 “ 针对于策略性关键决策问题的答案 在研讨会后生成的另一个至关重要的文档既“ 针对于策略性关键
9、决策问题的答案”。 具体策略性关键决策问题，请参见 “附录三 “ 运行维护管理各流程间的依赖关系 在 运行维护管理流程的设计过程中，不可避免的会造成有些流程间会产生依赖关系。次类依赖关系应当被文档化，特别是当相应的流程是由客户内不同的部门设计的时候。作为本咨询服务中一个可选的项目， HP 会为客户提供次文档。 工作职责描述 第 7 页 HP Consulting Confidential 每一个在工作流程中涉及到的客户内部的工作岗位都必须有工作 职责描述。具体由ITIL 建议的各种工作职责描述，请参见 “附录四 “ 无法解决问题文档 在研讨会后，不可避免的会存在一些悬而未决的问题，为了避免在此
10、类问题上过多纠缠导致整个项目计划被拖延，需要将该类问题在于记录在案。 第 8 页 HP Consulting Confidential 2.3 研讨会中各种角色 一个研讨会需要 HP 及客户相关人员参加，在讨论过程中每一个人应担负不同的角色。典型的五种被定义如下： 1. IT 运维管理咨询顾问 每一个研讨会的领导者， IT 运维管理咨询顾问 需从总体上把握研讨会的进度，在某些情况 下为研讨会的讨论结果作出最终决定，同时对研讨会的最终结果负责 2. 业务专家 业务专家需由客户 IT 部门中负债相应流程执行的人员担任。该员工需具有与要建立的流程相关的专业知识。例如，帮助台的经理应作为建立突发事件管
11、理流程的主要成员。 3. 咨询顾问 咨询顾问应具有设计的流程相关的专业知识及相关的工作经验。如果在流程运行过程中应用到工具，则该专家应具备使用该工具的专业知识。技术专家应在流程设计起到决定性的作用。 4. 会务 会务的主要责任在于确保相关于各种流程讨论的研讨会能够按计划得以进行，为了成功地完成任务，该人 应对要设计的流程相关的业务领域具第 9 页 HP Consulting Confidential 有充分的专业知识。同时会务应负责准备研讨会所需要的各种设施（会议室、白板、投影仪等）。 5. 会议记录员 会议记录员负责记录各研讨会的讨论成果，如运行维护管理流程图、讨论中无法解决的问题、及 流程
12、各步骤的详细说明等，并最终为客户提供与所设计流程相关的全部文档资料。鉴于以上要求，会议记录员应掌握IT 运维管理流程设计的基础知识，并能够熟练使用 MS-Word、 MS-Excel、及一种流程图设计工具（如 Visio 或 ABC-flowchart）。 第 10 页 HP Consulting Confidential 在各种讨论的过程中应尽量保证相对较少 的参加人数，同时保证所作出的结论是在经过充分的讨论、论证后得以通过。要充分重视各研讨会的时间安排及会前计划的制定。在各研讨会进行的过程中， 要充分利用 80/20 规则和 无法解决问题文档来确认研讨会的顺利进行，并确其保按进度完成。 2
13、.4 研讨会后期的工作 在各研讨会进行的过程中，各工作流程详细描述文档会被指派给相关人员负责但并不会有充裕的时间进行细化及整理归档。上述工作应留待研讨会后完成。 检查各研讨会所总结出的流程及结果并确保其一致性和连贯性同样非常重要，因为很多流程所产生的结果通常会被其它相关流程作为创 建初期必须考虑的因素。 第 11 页 HP Consulting Confidential 附录一 逻辑运行维护管理流程设计 本文档通过提供逻辑流程的示例流程 , 用于帮助客户设计适应 ”大集中 ”信息化需要的逻辑流程 . 这些示例流程可以被用于和客户信息化领导部门讨论特定运维流程的设计 . 通过收集客户对一系列策略
14、性关键决策问题与针对 IT 部门的 ”最佳成功范例 ”的探讨的结果 , 可以作为逻辑流程的信息输入 . 同时 , 在逻辑流程的设计阶段 , 对于客户现有组织机构中存在的流程也必须加以分析 . 在这之后 , 示例的逻辑流程可以被有选择地特定地应用 . 下述示例流程图中的编号可以根据需要 更改 . 图中的一些链接连至 IT服务管理模型中的其他流程 , 共同构成一个统一的整体 . 100 开头 : 配置管理流程组 200 开头 : 突发事件管理流程组 300 开头 : 问题管理流程组 400 开头 : 变更管理流程组 500 开头 : 服务级别管理流程组 流程的工作流中应用到以下符号： = 工具 =
15、 流程 = 决策 = 联接点 第 12 页 HP Consulting Confidential 第 13 页 HP Consulting Confidential 事件请求管理示例 管理层请求者(自动处理)请求者(人工处理)帮助台员工支持专家200.1事件初始化200.2事件辨识提供信息是请求类事件吗?200.3收集信息,事件注册200.4尝试达到满意帮助台的员工满意吗?200.7返回与请求者沟通200.5分配给其他支持队伍200.6收到事件 可以接受吗?是否请求者满意吗?200.8关闭事件是否否是第1页否是第 14 页 HP Consulting Confidential 200.9事件监
16、测管理层违反协议吗?升级200.4尝试达到满意满意吗?200.7返回与请求者沟通200.5分配给其他支持队伍请求者满意吗?200.8关闭事件否是是否第2页是否请求者(自动处理)请求者(人工处理)支持专家帮助台员工第 15 页 HP Consulting Confidential 应急事件管理示例 管理层工作组员工200.1事件初始化200.3收集信息,注册事件200.4尝试去解决满意吗?200.10自动触发事件200.7返回与帮助台沟通200.5分配给其他支持队伍200.6事件接收事件可接收吗?请求者满意吗?200.8事件结束YesNo否是第1页否是工作组员工后台支持队伍的工作组员工系统/应用
17、管理工具平台第 16 页 HP Consulting Confidential 200.9事件监测管理层超出协议范围?升级200.4尝试解决 满意吗?200.7返回与帮助台沟通200.5分配给其他支持队伍帮助台满意吗?200.8事件结束否是是否第2页是否事件请求(自动处理)请求者(人工处理)支持专家(工作组中 )工作组/帮助台员工第 17 页 HP Consulting Confidential 问题管理流程示例 工作组中的支持专家问题管理经理其他支持组织能够在本部门中发现根本原因?问题解决专家能够制订出解决方案?是来自400.7否是300.2创建问题事件300.1参考接收工单列表信息300.
18、3列表更新并返回发送者300.4应急事件与统计数据的分析是合法的问题吗?否300.2创建问题事件300.5问题优先级划分300.8收集信息300.9制订解决方案300.11问题关闭300.10沟通解决了吗?Yes否转至400.2Yes300.7问题接收300.7问题接收300.6分配给其他支持队伍No第 18 页 HP Consulting Confidential 变更管理流程示例 批准?变更请求者变更操作者变更管理经理满意吗? 是是否继续?400.3计划与建立400.4测试400.5进度规划与沟通400.6实施否是否撤消? 否转100.3400.1变更申请400.2授权400.8结束400
19、.7回顾审批转100.3转100.3400.1变更注册变更顾问委员会(CAB)变更实施者第 19 页 HP Consulting Confidential 配置管理流程示例 配置管理经理 100.1配置管理数据库(CMDB)策略的审核与更新100.4报告生成标准100.5评估流程帮助台(允许情况下)转自400.4转自400.4配置管理员网络/系统运维经理转自200.?100.2监控与检验CMDB100.3控制与维护CMDB第 20 页 HP Consulting Confidential 服务级别管理流程示例 (业务部门)管理层服务级别管理( SLM)经理业务上客户服务提供者500.2服务提供
20、内容的更新,维护与共享建议被批准吗?500.1定义针对新服务的服务级别基线500.3建议相应的变更以改善服务500.7生成服务报告,并与业务部门共享结果500.8针对既定的服务级别与需求的变动回顾审核实际服务结果500.4变更实施500.5升级流程是需要改变某些服务项目吗?500.6提供服务,监控与衡量是否需要变更吗?是否否第 21 页 HP Consulting Confidential 附录二 最佳成功范例 ITIL 的最佳成功范例可以被应用于建立 IT 运行维护管理所需要的各个流程。在客户建立运行维护管理流程的过程中充分应用本文档中所提供的最佳成功范例将是非常重 要的一个步骤。 帮助台管
21、理最佳成功范例 范例 # 101 突发事件管理流程的控制者在企业中的级别应足够高 范例 # 102 除 “SLA“中规定的内容，任何 IT 部门要解决的问题不应绕过帮助台来解决 范例 # 103 所有需解决的突发事件要通过帮助台向 IT 部门提交 , 由服务供应商提供针对应用及技术方面的支持 范例 # 104 所有最终用户的服务请求应由统一的系统记录在案 ,并由该系统负责 IT 部门内的工作分派，纪效跟踪，问题升级管理，和质量管理 范例 # 105 帮助台所使用的系统工具应能够将问题管理 、变更管理、及配置管理紧密结合在一起 范例 # 106 帮助台应包涵对问题处理进行跟踪及监控的流程 第 2
22、2 页 HP Consulting Confidential 范例 # 107 帮助台的员工应尽最大可能在一线解决用户的问题(80%的问题应在帮助台得以解决 ) 范例 # 108 对所有问题的解决方法应在帮助台所使用的系统工具中存档 范例 # 109 应采用配置管理数据库 范例 # 110 应及时向提交问题的最终用户通报问题的处理情况 .通过主动式服务所处理问题的进度和情况也应由帮助台员工与最终用户进行沟通 范例 # 111 帮助台应作为 IT 与业务部门沟通问题处 理情况 ,系统变更状态 ,系统可用性等情况的接口 范例 # 112 必须建立一个针对 IT 运行维护管理的问题升级处理流程 范例
23、 # 113 变更的状态 ,时间 ,及突发事件造成后果的严重程度应被综合的考虑以决定是否采用问题升级处理流程 范例 # 114 可以采用电子化手段与客户进行问题处理情况的初步沟通 范例 # 115 帮助台应全面了解 IT 内部变更的情况 ,包括近期完成的变更及变更计划的安排 第 23 页 HP Consulting Confidential 范例 # 116 帮助台有责任通知最终用户变更的计划及变更实施的详细情况 范例 # 117 IT 部门内部资源的分配 应基于突发事件对日常业务运作的影响程度 范例 # 118 应确定最终用户对突发事件解决方案的满意程度 范例 # 119 在帮助台工作的员工
24、应具有良好的与人沟通的能力 范例 # 120 在帮助台工作的员工应具有支持多种操作系统平台的经验 (HP-UX, NT, Windows95,etc.) 范例 # 121 在条件允许的情况下，帮助台系统工具应能够自动地接收系统监测工具提供的警告信息 范例 # 122 帮助台应具备识别已知问题的能力，及完善的与问题管理功能衔接的接口 范例 # 123 完整的描述当 前 IT 为其它部门所提供的服务、服务级别、产品、流程的文档 范例 # 124 当帮助台的经理不在岗位时，应有相应人员代理执行其职责 范例 # 125 应建为所有最终用户服务的电子信息布告栏 第 24 页 HP Consulting
25、Confidential 范例 # 126 应根据配置管理数据库建立完整的系统配置及网络分布图 范例 # 127 应为帮助台员工建立突发事件归类准则 问题管理最佳成功范例 范例 # 201 ITIL 强烈推荐 IT 部门应用电子化的问题管理工具 范例 # 202 为了有效地支持 IT 与业务部门之间的服务级别协议应具有完善的问题升级处理流程 范例 # 203 针对造成 IT 系统的每一个问题，应找到其根本原因 范例 # 204 应记录，利用，及分析所发生问题的历史记录并将相关信息存档 范例 # 205 对每一个已发生问题的解决方案应记录在案 范例 # 206 应将发生的问题归类并找出造成各种问
26、题的根本原因 范例 # 207 在问题升级管理流程中应规定何时将问题处理情况通报给最终用户 范例 # 208 针对问题的解决方法应在争得最终用户同意的前提下实施，在需要时与变更管理流程紧密结合 第 25 页 HP Consulting Confidential 范例 # 209 应分析当前存在问题量，以此为依据估 计 IT 部门内所需人力资源 范例 # 210 应将问题分类，并为各类问题定义代码 配置管理 最佳成功范例 范例 # 301 鉴于配置管理的重要性，建议由 CIO 或 IT 经理直接做配置管理流程的负责人 范例 # 302 配置管理数据库中信息的详细程度应取决于维持当前信息所需费用的
27、多少 范例 # 303 配置管理数据库应与资产管理系统和变更管理系统紧密地结合在一起使用 范例 # 304 针对所有需要管理的资产应定义配置规则，使配置管理数据库能够为变更管理提供良好的基础 范例 # 305 配置管 理数据库将为所有 IT 运行及维护管理流程提供所需信息，特别是针对问题和变更管理流程 范例 # 306 所有配置的变更应在获得授权的前提下得以实施，同时必须保证具体实施由指定的专人负责 第 26 页 HP Consulting Confidential 范例 # 307 IT 部门内所有的物理设备及软件的清单必须保存于一个数据库管理系统中 范例 # 308 应设计确认物理设备序列
28、号的流程 变更管理 最佳成功范例 范例 # 401 IT 部门内应指定级别足够高的相应人员负责变更管理。作为 IT 部门内变更的管理者，该经理应负责制订变更计划，监督变更实施等工作 范例 # 402 IT 部门内应具有单一的变更管理功能，负责控制 IT 运行及维护过程中会发生的变化 范例 # 403 变更管理和问题管理应从工具和流程两个层面紧密地结合在一起 范例 # 404 配置管理应能够帮助确定与 IT 基础结构中与产生变化CI相关的其他部分 范例 # 405 任何 IT 所接受的变更需求应交变更管理控制小组讨论并确定其实施计划 范例 # 406 在一个变更得以实施之后，配置管理流程应负责更
29、新配置管理数据库 第 27 页 HP Consulting Confidential 范例 # 407 变更管理者应确保帮助台能清楚、及时地获得所有 IT运行及维护过程中所涉 及到的于变更相关的信息 范例 # 408 除特殊的紧急情况外，任何与解决软件问题相关的变更应提交正式的变更需求 范例 # 409 所有与 IT 运行及维护相关的变更均应在得到变更管理者授权的前提下才可实施 范例 # 410 所有变更的需求都应在提交给变更管理控制小组审核前被授予相应的优先级 范例 # 411 企业的 IT 部门应承担全部与变更管理相关的责任，包括 IT 部门内已外包的部分 范例 # 412 企业内应成立变
30、更管理控制小组 范例 # 413 变更管理控制小组应包括所有 IT 部门内的负责人，及需 IT 支持的业务部门的负责人（或由其指定的代表） 范例 # 414 变更需求的受理和实施应受到配置管理系统的严格控制 范例 # 415 对 IT 部门的变更带给其它业务部门造成影响的评估应充分利用配置管理所提供的信息 范例 # 416 变更流程的批准及相关工作进度安排应及时与有关部门及人员进行沟通 第 28 页 HP Consulting Confidential 范例 # 417 在安排变更计划时应充分利用配置管理数据库，及历史变更记录 范例 # 418 作为存档资料，变更历史记录应与问题管理，配置管理
31、及突发事件管理（帮助台）紧密地结合在一起使用 范例 # 419 变更实施后的分析及分析后产生的变更管理报告应被视为改进变更管理流程的重要工具 范例 # 420 应根据企业的具体需求每周或每月向负责变更实施的员工及受变更影响的最终用户通报被批准实施的变更请求及计划实施的项目 范例 # 421 变更管理的负责人应负责定期组织变更管理控制小组会议 范例 # 422 初少数紧急特例，任何变更在发生在生产系统环境前都要经过测试 范例 # 423 应为需进行的测试提供所需的测试环境 范例 # 424 任何变更在发生在生产系统环境之前都需要得到变更管理者的授 权 范例 # 425 应为帮助台员工在新的软件投
32、入使用前提供相关的培训 范例 # 426 应设计单独的处理紧急变更需求，但应尽量把此类需求控制在最小的范围内 第 29 页 HP Consulting Confidential 范例 # 427 应选用适当的软件来支持和管理变更管理流程 第 30 页 HP Consulting Confidential 服务级别管理 最佳成功范例 范例 # 500 服务级别负责人应负责 IT 部门内服务级别的计划和实施 范例 # 501 服务级别管理应负责协调 IT 与其它业务部门的关系 范例 # 502 与客户的服务级别协议的建立主要依赖于对 IT 系统可用性 ,系统能力 ,及发生意外可能性的精确分析 . 范例 # 503 服务级别协议中应包括帮助台为最终用户提供的服务级别 范例 # 504 服务级别管理的负责人应坚持以服务级别协议为准则 ,尽量将对服务质量的影响减少到最低 范例 # 505 服务级别管理的负责人应参加评估变更对服务质量产生的影响 (分别包括计划变更阶段的影响和变更实施阶段的影响 ). 范例 #506 应将服务级别管理的目的 ,好处 ,及需求及时地与最终用户进行沟通 范例 # 507 在全面考虑不同级别业务需求的前提下 , IT 部门为用户提供服务的优先级应被提前定义好
