20150618 MONICAZHANG

续上

4.2.4        发布管理

在现有服务环境中，没有正式的发布管理流程，但具备一些发布管理流程所要求的活动。组织中在一些制度中，对软件和硬件的发布有些零散的说明。但基本不具备测试环境，有时开发环境、测试环境甚至生产环境相互重叠。      ITSS认证

当前天津市电力公司的管理层和运维人员都意识到发布管理规范化的重要性，希望通过发布管理流程的咨询，为企业建立一套良好的发布机制，有效的控制和协调业务部门、维护部门和开发厂商的协作关系，以便提高IT系统的维护和管理水平。

根据对流程评估的九个纬度，下图量化地反映了现有流程状态以及经过本期项目后双方共同努力改进的目标。

图 4‑36 发布管理评估及改进建议

根据上图，以下将总结和陈述对发布管理流程各纬度的主要发现和改进建议：           

表格 4‑2 发布管理主要发现及改进建议

纬度	主要发现	改进建议
基础条件	ž  有一定发布管理活动，但没有形成可重复的管理机制 ž  企业内部存在变更管理，但没有和发布具体关联 ž  存在零散管理制度，简单说明发布政策	ž  通过流程研讨，进行总体发布管理流程定义，形成共识共知的发布管理流程文档 ž  发布管理流程设计后，考虑与变更管理流程的交互                ITSS培训 ž  未来实践中，明确和用户之间达成一致的发布政策（Policy）
管理目的	ž  没有足够的资源和时间为发布进行建设、测试和实施	ž  加强发布管理目的、意义的宣传。指定发布流程经理，加强软硬件发布的控制
流程能力	ž  没有定义和文档化相关角色和职责来执行发布管理中的不同活动 ž  发布流程不完善，没有形成完整的发布操作过程 ž  发布实施完毕后，配置管理数据库（CMDB）不能及时更新以反映新增或变化的发布内容	ž  识别和区分关键业务功能，对于服务可用的标准与业务部门达成共识 ž  在未来实践中，严格遵循定义流程进一步规范发布管理活动 ž  流程中加强发布管理和配置管理信息交互的控制
内部支持	ž  软件发布没有在一个可监控的、安全的、有流程确保的发布管理中进行 ž  软件主拷贝零散存放	ž  根据ITIL理念，结合现有活动，梳理流程各环节的输入输出关系，制定规范化管理流程 ž  未来实践中，尽可能形成统一的软件库，根据企业能力再逐步实现硬件库          ITIL培训
流程产出	ž  没有正式的发布命名和编号规则 ž  有发布计划和回退计划 ž  有测试计划、验收规范和测试结果	ž  未来实践中，详细讨论并制定发布命名和编号规则 ž  加强发布计划和测试计划的规范性
质量控制	ž  发布流程不完善，因此也没有形成严格的质量控制机制	ž  建立流程的KPI指标，持续优化改进 ž  在可能的情况下，利用相关工具配合流程的实现
管理信息	ž  发布流程不完善，因此也没有形成严格的管理信息	ž  参照ITIL最佳实践，规范发布管理报告
外部集成	ž  事件管理流程运行较好，对有效保证发布系统的故障处理，缩短服务中断时间起到重要作用 ž  配置管理范围过大，导致维护资源难以保证，数据更新无法保证，CMDB数据的价值无法释放 ž  变更管理的范围过大，审批环节及流程效率不高 ž  尚未形成服务级别管理	ž  巩固事件管理流程，优化工具 ž  梳理配置管理，协同完成对发布管理的辅助作用 ž  强化变更管理，提高对发布请求的控制 ž  发布管理需要和其他流程紧密配合，共同完成对服务可用性的设计、监控及保障；在咨询的设计阶段将详细讨论可用性管理流程及事件管理、配置管理、变更管理、服务级别管理等流程的关系及集成接口              ISO20000培训
客户界面	ž  某公司对标体系中有客户满意度的要求 ž  已关注到客户的满意度，但尚未形成一个机制	ž  客户满意度调查应形成一个机制，但在企业文化下不拘泥于形式

4.2.5        服务级别管理

在现有服务环境中，总体上看在某些层面上对服务级别管理有一定的关注。

目前在科技信息部内部已经进行了一些服务级别管理方面的活动，如与应用系统开发商签订了维护合同（MA ），例如在OA维护合同中规定了必要的服务目标、服务内容、服务期限、解决故障时间、服务支持时间、响应时间等UC和SLA中必须的要素。

在IT服务面向的客户方面，科技信息部对不同服务面向的 有清晰的识别和了解。比如OA面向用户群和优先级的考虑，客户端维护方面服务台清楚地了解维护范围内的 和相关办公地点。                   ITSS体系

在客户端维护服务方面，启动了服务台受理报障并尽快解决，同时在客户端硬件方面，签订维护合同，硬件故障直接联系维护商修理。

根据对流程评估的九个纬度，下图量化地反映了现有流程状态以及经过本期项目后双方共同努力改进的目标。

图 4‑37 服务级别管理评估与改进

根据上图，以下将总结和陈述对服务级别管理流程各纬度的主要发现和改进建议：

表格 4‑3 服务级别管理主要发现及改进建议

纬度	主要发现	改进建议
基础条件	ž  在部门内部有一定服务级别管理相关活动，比如签订客户端硬件维护合同，使该类问题能够得到服务商的快速支持与解决，保障客户端服务质量	ž  通过流程设计研讨，进行总体服务级别管理流程定义，形成共识共知的服务级别管理流程文档 ž  在未来实践中，遵循流程规定进一步规范服务级别管理活动              ITSS软件
	ž  对不同服务面向的 有清晰的识别和了解。 ž  没有识别和定义服务的属性，比如服务支持时间、	ž  进行服务梳理，对服务进行详细、明晰的定义属性识别 ž  明确业务部门和客户的服务需求，对不同服务区分不同的服务级别目标
管理目的	ž  服务级别管理的目的与好处已经得到了宣传，目前在科技信息部内部对服务级别管理方面的概念和方法论已经有了清晰认识，从管理思想上有利于服务级别管理流程的建立与运转 ž  没有合适的数据支持服务级别的决策。在运维层面缺乏有效的监控工具或未有效利用，无法为服务级别的决策提供合适的数据基础，比如系统、网络的可用性	ž  加强系统、网络故障管理和性能管理，建立可用性管理流程与容量管理流程和相关活动，为服务级别管理流程提供必要的数据支持                               ITSS团购
流程能力	ž  没有在部门内部指定专人负责服务级别管理相关活动。 ž  部门内对服务缺少整体认识，没有统一的，描述清楚的服务目录	ž  指定服务级别管理流程经理，并授权全面负责设计、管理、协调服务级别管理活动，全面关注天津市电力公司的IT服务质量整体提高并组织资源对服务级别管理流程持续改进和优化 ž  在部门范围内建立全面、清晰的服务目录，使全体运维人员对部门提供的服务有整体、详细的了解
	ž  与运维服务商间有维护合同（MA），没有与客户签订的或得到承认的SLA	ž  科技信息部目前提供的IT服务并不是以商业运作模式为基础的，与客户间的量化服务级别协议（SLA）并不是很迫切的需求，但仍然可以借鉴服务级别管理过程中的运作级别协议（OLA）和支持合同（UC）。量化管理与企业内IT服务提供相关的组织和外部服务提供组织对科技信息部IT服务的支持，以提高整体服务质量
	ž  “重建设，轻运维”，缺乏对现有服务的监控和回顾机制，每月的例行分析会以汇报项目为主，运维方面的分析与回顾做的不多	ž  进行服务级别管理改进计划设计，由服务级别经理牵头定期回顾并与其他流程（如可用性、事件）相结合进行服务质量监控。         ITSS工具
内部支持	ž  服务级别管理流程和活动不完善，没有相互连贯形成统一的服务级别管理	ž  在部门内部通过服务级别管理流程的建立，结合现有活动，梳理流程各环节的关系。
流程产出	ž  服务及其相关组件没有明确的定义和记录	ž  进行服务识别和分析，将关键服务组件要识别为配置项（CI），详细记录在CMDB中
	ž  没有定期的服务报告	ž  形成的定期回顾服务质量机制，提交服务质量报告。
质量控制	ž  服务级别管理流程不完善，没有形成严格的质量控制机制 ž  目前有可以支持服务级别管理的工具	ž  建立流程的KPI指标，持续优化改进 ž  在可行的情况下，利用相关工具配合流程的实现
管理信息	ž  无服务级别或服务性能方面的分析报告或趋势报告	ž  加强与事件管理、可用性管理的结合，加强服务级别指标分析与监控。
外部集成	ž  事件管理流程运行较好，对有效保证较好的可用性，缩短服务中断时间起到重要作用 ž  配置管理目前大而全，但关键信息收集不全，数据更新无法保证 ž  变更管理的范围过大，审批环节及流程效率不高 ž	ž  服务级别管理目标应当与相关服务在服务台工具中事件和问题处理目标（比如解决期限）相吻合 ž  梳理配置管理，重点关注关键服务组件，将服务目录作为CMDB的一部分进行集成维护 ž  强化变更管理，在变更审批时评估其对服务级别的潜在影响 ž  服务级别管理需要和其他流程紧密配合，共同完成对服务级别的设计、监控及保障；在咨询的设计阶段将详细讨论服务级别管理流程及事件管理、配置管理、问题管理、变更管理、容量管理、可用性管理等流程的关系及集成接口         ITSS考试
客户界面	ž  某公司对标体系中有客户满意度的要求 ž  尚未主动监控用户满意趋势和进行客户满意度调查	ž  客户满意度调查应形成一个机制，定期进行客户满意度调查分析，找出服务方面的优势与薄弱环节

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

本帖关键字：ITSS ISO20000

20150618 MONICAZHANG

续上

4.2.4        发布管理

在现有服务环境中，没有正式的发布管理流程，但具备一些发布管理流程所要求的活动。组织中在一些制度中，对软件和硬件的发布有些零散的说明。但基本不具备测试环境，有时开发环境、测试环境甚至生产环境相互重叠。      ITSS认证

当前天津市电力公司的管理层和运维人员都意识到发布管理规范化的重要性，希望通过发布管理流程的咨询，为企业建立一套良好的发布机制，有效的控制和协调业务部门、维护部门和开发厂商的协作关系，以便提高IT系统的维护和管理水平。

根据对流程评估的九个纬度，下图量化地反映了现有流程状态以及经过本期项目后双方共同努力改进的目标。

图 4‑36 发布管理评估及改进建议

根据上图，以下将总结和陈述对发布管理流程各纬度的主要发现和改进建议：           

表格 4‑2 发布管理主要发现及改进建议

纬度	主要发现	改进建议
基础条件	ž  有一定发布管理活动，但没有形成可重复的管理机制 ž  企业内部存在变更管理，但没有和发布具体关联 ž  存在零散管理制度，简单说明发布政策	ž  通过流程研讨，进行总体发布管理流程定义，形成共识共知的发布管理流程文档 ž  发布管理流程设计后，考虑与变更管理流程的交互                ITSS培训 ž  未来实践中，明确和用户之间达成一致的发布政策（Policy）
管理目的	ž  没有足够的资源和时间为发布进行建设、测试和实施	ž  加强发布管理目的、意义的宣传。指定发布流程经理，加强软硬件发布的控制
流程能力	ž  没有定义和文档化相关角色和职责来执行发布管理中的不同活动 ž  发布流程不完善，没有形成完整的发布操作过程 ž  发布实施完毕后，配置管理数据库（CMDB）不能及时更新以反映新增或变化的发布内容	ž  识别和区分关键业务功能，对于服务可用的标准与业务部门达成共识 ž  在未来实践中，严格遵循定义流程进一步规范发布管理活动 ž  流程中加强发布管理和配置管理信息交互的控制
内部支持	ž  软件发布没有在一个可监控的、安全的、有流程确保的发布管理中进行 ž  软件主拷贝零散存放	ž  根据ITIL理念，结合现有活动，梳理流程各环节的输入输出关系，制定规范化管理流程 ž  未来实践中，尽可能形成统一的软件库，根据企业能力再逐步实现硬件库          ITIL培训
流程产出	ž  没有正式的发布命名和编号规则 ž  有发布计划和回退计划 ž  有测试计划、验收规范和测试结果	ž  未来实践中，详细讨论并制定发布命名和编号规则 ž  加强发布计划和测试计划的规范性
质量控制	ž  发布流程不完善，因此也没有形成严格的质量控制机制	ž  建立流程的KPI指标，持续优化改进 ž  在可能的情况下，利用相关工具配合流程的实现
管理信息	ž  发布流程不完善，因此也没有形成严格的管理信息	ž  参照ITIL最佳实践，规范发布管理报告
外部集成	ž  事件管理流程运行较好，对有效保证发布系统的故障处理，缩短服务中断时间起到重要作用 ž  配置管理范围过大，导致维护资源难以保证，数据更新无法保证，CMDB数据的价值无法释放 ž  变更管理的范围过大，审批环节及流程效率不高 ž  尚未形成服务级别管理	ž  巩固事件管理流程，优化工具 ž  梳理配置管理，协同完成对发布管理的辅助作用 ž  强化变更管理，提高对发布请求的控制 ž  发布管理需要和其他流程紧密配合，共同完成对服务可用性的设计、监控及保障；在咨询的设计阶段将详细讨论可用性管理流程及事件管理、配置管理、变更管理、服务级别管理等流程的关系及集成接口              ISO20000培训
客户界面	ž  某公司对标体系中有客户满意度的要求 ž  已关注到客户的满意度，但尚未形成一个机制	ž  客户满意度调查应形成一个机制，但在企业文化下不拘泥于形式

4.2.5        服务级别管理

在现有服务环境中，总体上看在某些层面上对服务级别管理有一定的关注。

目前在科技信息部内部已经进行了一些服务级别管理方面的活动，如与应用系统开发商签订了维护合同（MA ），例如在OA维护合同中规定了必要的服务目标、服务内容、服务期限、解决故障时间、服务支持时间、响应时间等UC和SLA中必须的要素。

在IT服务面向的客户方面，科技信息部对不同服务面向的 有清晰的识别和了解。比如OA面向用户群和优先级的考虑，客户端维护方面服务台清楚地了解维护范围内的 和相关办公地点。                   ITSS体系

在客户端维护服务方面，启动了服务台受理报障并尽快解决，同时在客户端硬件方面，签订维护合同，硬件故障直接联系维护商修理。

根据对流程评估的九个纬度，下图量化地反映了现有流程状态以及经过本期项目后双方共同努力改进的目标。

图 4‑37 服务级别管理评估与改进

根据上图，以下将总结和陈述对服务级别管理流程各纬度的主要发现和改进建议：

表格 4‑3 服务级别管理主要发现及改进建议

纬度	主要发现	改进建议
基础条件	ž  在部门内部有一定服务级别管理相关活动，比如签订客户端硬件维护合同，使该类问题能够得到服务商的快速支持与解决，保障客户端服务质量	ž  通过流程设计研讨，进行总体服务级别管理流程定义，形成共识共知的服务级别管理流程文档 ž  在未来实践中，遵循流程规定进一步规范服务级别管理活动              ITSS软件
	ž  对不同服务面向的 有清晰的识别和了解。 ž  没有识别和定义服务的属性，比如服务支持时间、	ž  进行服务梳理，对服务进行详细、明晰的定义属性识别 ž  明确业务部门和客户的服务需求，对不同服务区分不同的服务级别目标
管理目的	ž  服务级别管理的目的与好处已经得到了宣传，目前在科技信息部内部对服务级别管理方面的概念和方法论已经有了清晰认识，从管理思想上有利于服务级别管理流程的建立与运转 ž  没有合适的数据支持服务级别的决策。在运维层面缺乏有效的监控工具或未有效利用，无法为服务级别的决策提供合适的数据基础，比如系统、网络的可用性	ž  加强系统、网络故障管理和性能管理，建立可用性管理流程与容量管理流程和相关活动，为服务级别管理流程提供必要的数据支持                               ITSS团购
流程能力	ž  没有在部门内部指定专人负责服务级别管理相关活动。 ž  部门内对服务缺少整体认识，没有统一的，描述清楚的服务目录	ž  指定服务级别管理流程经理，并授权全面负责设计、管理、协调服务级别管理活动，全面关注天津市电力公司的IT服务质量整体提高并组织资源对服务级别管理流程持续改进和优化 ž  在部门范围内建立全面、清晰的服务目录，使全体运维人员对部门提供的服务有整体、详细的了解
	ž  与运维服务商间有维护合同（MA），没有与客户签订的或得到承认的SLA	ž  科技信息部目前提供的IT服务并不是以商业运作模式为基础的，与客户间的量化服务级别协议（SLA）并不是很迫切的需求，但仍然可以借鉴服务级别管理过程中的运作级别协议（OLA）和支持合同（UC）。量化管理与企业内IT服务提供相关的组织和外部服务提供组织对科技信息部IT服务的支持，以提高整体服务质量
	ž  “重建设，轻运维”，缺乏对现有服务的监控和回顾机制，每月的例行分析会以汇报项目为主，运维方面的分析与回顾做的不多	ž  进行服务级别管理改进计划设计，由服务级别经理牵头定期回顾并与其他流程（如可用性、事件）相结合进行服务质量监控。         ITSS工具
内部支持	ž  服务级别管理流程和活动不完善，没有相互连贯形成统一的服务级别管理	ž  在部门内部通过服务级别管理流程的建立，结合现有活动，梳理流程各环节的关系。
流程产出	ž  服务及其相关组件没有明确的定义和记录	ž  进行服务识别和分析，将关键服务组件要识别为配置项（CI），详细记录在CMDB中
	ž  没有定期的服务报告	ž  形成的定期回顾服务质量机制，提交服务质量报告。
质量控制	ž  服务级别管理流程不完善，没有形成严格的质量控制机制 ž  目前有可以支持服务级别管理的工具	ž  建立流程的KPI指标，持续优化改进 ž  在可行的情况下，利用相关工具配合流程的实现
管理信息	ž  无服务级别或服务性能方面的分析报告或趋势报告	ž  加强与事件管理、可用性管理的结合，加强服务级别指标分析与监控。
外部集成	ž  事件管理流程运行较好，对有效保证较好的可用性，缩短服务中断时间起到重要作用 ž  配置管理目前大而全，但关键信息收集不全，数据更新无法保证 ž  变更管理的范围过大，审批环节及流程效率不高 ž	ž  服务级别管理目标应当与相关服务在服务台工具中事件和问题处理目标（比如解决期限）相吻合 ž  梳理配置管理，重点关注关键服务组件，将服务目录作为CMDB的一部分进行集成维护 ž  强化变更管理，在变更审批时评估其对服务级别的潜在影响 ž  服务级别管理需要和其他流程紧密配合，共同完成对服务级别的设计、监控及保障；在咨询的设计阶段将详细讨论服务级别管理流程及事件管理、配置管理、问题管理、变更管理、容量管理、可用性管理等流程的关系及集成接口         ITSS考试
客户界面	ž  某公司对标体系中有客户满意度的要求 ž  尚未主动监控用户满意趋势和进行客户满意度调查	ž  客户满意度调查应形成一个机制，定期进行客户满意度调查分析，找出服务方面的优势与薄弱环节

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

本帖关键字：ITSS ISO20000