服务交付ITSS过程

2015-07-08 14:56

20150708 淡然

项目

检查点

检查记录

检查结果

管理层要求

建立服务管理体系的策略、目标和计划

符合

ITSS培训

定义服务管理组织，制定管理成员协调各种服务管理活动

符合

定义并提供必要的资源

符合

管理服务管理组织和服务的风险

符合

定期进行管理评审，以持续改进

符合

能力、意识和培训

定义服务管理各种角色、职责和所需技能

符合

制定员工培训计划、维护培训清单

符合

定期回顾员工的资格能力和培训需求

符合

服务管理体系的计划和实施

定义审核的规则、标准、频率和方法

符合

定义服务管理的范围

符合

定义服务管理的目标

符合

如何识别并处理服务管理中的风险？

符合

记录管理评审结果并就重大不符合项与相关方沟通

符合

定义服务质量改进计划，制定服务改进方针

符合

定义改进活动的角色和职责

符合

制定必要的改进活动

符合

流程

要求

检查记录

检查结果

服务级别管理

根据IT部提供的服务来制定服务目录以及服务级别、服务团队方面的说明

符合

定义SLA来记录和管理约定的服务，包括服务提供的范围、目标、工作量、OLA和UC

符合

与供应商协商必要的支持服务、考核条款并签订合同来进行管理

符合

任何服务项的变更和SLA的变更必须走变更管理程序进行审批

符合

服务级别协议（SLAs）应处于变更管理过程的控制之下。

符合

通过必要的手段监控SLA指标的实现情况，并出具监控报告

符合

任何SLA的违反必须被报告并在评审之后改进，并在服务改进计划中记录

符合

服务报告

为各个流程制定相应的服务报告，每一服务报告应清晰阐明其目的、制定人、阅读者以及数据来源。

符合

服务报告至少应该包括如下内容：

符合

a) 服务级别目标与实际运行绩效之间的差距；

符合

b) 不符合项和问题报告；

符合

c) 数量统计、资源使用率等工作量特性

符合

d) 重大事件事后报告

符合

e) 趋势分析信息

符合

f) 客户满意度分析

符合

服务连续性及可用性管理

制定服务可用性和连续性计划，并每年度进行评审和回顾

符合

当业务环境发生重大变更时，应重新测试可用性及服务连续性计划。

符合

服务可用性和连续性计划的变更产生的影响应该走变更管理流程进行控制

符合

采用一定的手段或者工具测量和记录可用性

符合

对计划外的不可用采取预防和修正措施

符合

即使正常的办公访问被阻止时，也必须确保服务连续性计划、
通讯录（联系人清单）和配置管理数据库的可用性

符合

应依据业务需求对服务连续性计划进行测试。

符合

应记录所有的连续性测试。对于测试失败，应当记录在行动计划中。

符合

IT服务预算及核算管理

应为下列活动建立清晰的策略和程序：

符合

a) 为所有的组件（包括IT 资产、管理费用、外部提供的服务、人员、维保和许可证）制定预算并进行核算；

符合

b) 服务的间接成本的摊销和分配

符合

c) 有效的财务控制和授权。

符合

应制定详细的成本预算表

符合

对预算进行监控并进行报告

符合

应计算服务变更的成本的，服务变更成本的批准必须通过变更管理程序

符合

能力管理

制定和维护能力计划

符合

应确定监控服务能力、协调服务绩效和提供充足能力所需的方法、程序和技术，包括：

符合

a)当前的预期的能力及性能需求

符合

b) 识别时间界线、阀值和服务升级更新的成本

符合

c) 评价预期的服务升级、变更请求、新技术和方法对能力造成的影响；

符合

d) 预测外部变更的影响，比如立法

符合

e) 能力预测分析所需的数据和流程。

符合

信息安全管理

管理层应该建立信息安全政策，并与相关方进行交流和推广

符合

采取必要的安全控制措施，管理访问系统或者服务的风险

符合

对于外部组织对信息系统和服务的访问，应根据安全需求制订正式协议

符合

在实施变更前，应对控制发生变更的影响进行评估。

符合

汇报和记录安全事件，确保可以调查所有的安全事故并采取管理措施。

符合

制订机制，量化和监控安全事件和故障的类型、数量和影响

符合

应记录该过程所确定的改进措施，提供服务改进计划。

符合

流程

要求

检查记录

检查结果

业务关系管理

识别并记录服务的利益相关者和客户。

符合

服务提供商和客户应每年至少进行一次服务评审，来讨论服务范围、服务级别协议、合同或业务需求的任何变更，并按约定的定期召开中间会议来讨论绩效、成绩、问题和改进计划。这些会议应形成书面的会议记录。

符合

如果出现合同变更，那么适当时在这些会议上应讨论服务级别协议变更的问题。这些变更应遵循变更管理流程。

符合

建立投诉处理程序，定义投诉渠道和受理人

符合

制定投诉的记录、调查、响应、报告并正式关闭等处理过程

符合

建立投诉的升级机制，以处理非常规渠道的投诉

符合

建立客户满意度调查程序并定期报告客户满意度

符合

任命客户关系管理过程的负责人

符合

供应商管理

为每一供应商指定合同管理者和联系人。

符合

在支持合同中协定和记录供应商所提供服务的要求、范围和级别以及沟通过程

符合

与供应商签订的服务级别协议应与业务的服务级别协议保持一致。

符合

应清楚规定主供应商与分包方之间的角色、接口及关系。主供应商应确保分包方满足合同要求的过程。

符合

建立合同或正式协议的评审过程。评审每年至少进行一次，以确保合同仍能继续满足业务需求和合同要求。适当时，合同或服务级别协议的变更应紧随评审之后或在其他所需的时间。

符合

应建立解决合同争议和纠纷的程序。

符合

应建立程序以管理供应商服务的预期结果、提前终结，或将服务移交第三方。

符合

ITSS认证

根据服务级别目标来监视和评审业绩，应记录在这一过程中确定出的改进措施并作为服务改进计划的输入。

符合

流程

要求

检查记录

检查结果

事件管理

应记录所有的事件。

符合

采用一定的规程来管理事件的影响。

符合

定义事件的记录、优先级、业务影响、分类、更新、升级、解决和正式关闭等方面的程序。

符合

通知客户其提交的事件或服务请求处理进展，当不能达到约定的服务级别或无法完成约定的行为时应提前警告客户。

没有提前警告客户

不符合

确保事件管理所涉及的所有人员应都可以访问相关的信息，如已知错误、问题解决方案和配置管理数据库。

符合

定义重大事件的范围和处理流程

符合

问题管理

所有确认的问题应当予以记录。

符合

建立事件管理与问题管理流程之间的接口

符合

采用程序来识别事件或问题的影响、并使影响最小化或避免发生

符合

定义问题的记录、分类、更新、调整、解决和关闭方面的程序。

符合

应采取预防措施，以减少潜在的问题，例如对事故的数量和类型的趋势分析。

符合

对那些为纠正潜在问题原因而需要/产生的变更，应当提交给变更管理流程处理。

符合

应当对问题解决方案进行监控、评审，并对其有效性进行评估和报告

符合

问题管理必须保证事件管理能及时获取最新的已知错误和纠正性措施方面的信息

符合

对于问题管理流程中确认的改进行为，应当予以记录并投入计划，从而改进服务。

符合

流程

要求

检查记录

检查结果

配置管理

应定义变更管理和配置管理的借口，比如在变更完成之后触发一个配置参数修改通知单

符合

应规定与财务资产管理过程的接口

符合

定义什么是配置项及组件

符合

应定义每个配置项需要记录哪些信息，包括CI之间的关系和为有效服务管理所需的文档

符合

配置管理必须提供对服务和基础设施可辨别组件版本的识别、控制和跟踪机制，其控制级别应足够充分以满足业务要求，应对失败风险和服务临界点

符合

配置项的变更应是可追溯的和可审计的，如软件和硬件的变更和活动。

符合

配置管理应该为变更管理流程提供信息，以衡量变更请求对服务和基础设施配置产生的影响

符合

配置控制程序应保持系统、服务和服务组件的完整性。

符合

应在发布到实际运行环境之前参考配置项的基线。

符合

数据配置项的主拷贝应控制在安全的物理或电子数据库中，并同配置记录相关联，如软件、测试产品和支持文档。

符合

所有的配置项应能被唯一的识别，并记录在CMDB（配置管理数据库）中。应严格控制对CMDB 的升级访问。应主动管理并验证CMDB，以确保CMDB 的可靠性和准确性。对那些需要这些信息的人员，CMDB应提供配置项的状态和版本、位置、相关的变更和问题以及相关的文档。

符合

配置审计程序应包括记录偏差、发起纠正措施，报告结果。

符合

变更管理

应明确规定服务和基础设施变更的范围

符合

应记录并分类所有的变更请求，如紧急、危急、重大和轻微等。

符合

变更请求应该评估其风险、影响和业务收益

符合

变更管理流程应该包括一旦变更失败时进行复原和补救的方法

符合

变更应该被评审和批准，并在受控方式下实施

符合

所有变更应该在实施后检查是否成功并回顾变更实施的措施

符合

建立紧急变更的策略和程序，并控制紧急变更的授权和实施。

符合

已计划好的变更日期（变更窗口）应作为制定变更和发布时间表的基础。时间表应包括批准实施的所有变更以及建议实施日期的详细信息，这些信息应与相关方沟通。

符合

变更记录应该被定期分析，以发现频发变更的类型、趋势和其他相关信息。变更分析的结论和结果应该被记录

符合

变更管理流程识别的改进行动应该被记录并作为服务改进计划的输

符合

流程

要求

检查记录

检查结果

发布管理

记录并协商确定发布策略，规定发布的频率和类型

符合

根据业务来计划服务、系统、软件和硬件的发布

符合

上线计划需要经过相关方的协商和批准

符合

上线流程中包括一旦失败时的发布备份或补救（回退）方法

符合

发布计划应记录发布的日期，以及交付物。

符合

发布计划应参考相关的变更请求、已知的错误和问题。

符合

建立发布管理与事件管理流程的接口，发布管理流程应当传递适当的信息给事件管理流程。

符合

进行变更请求的评估时要考虑变更对发布计划的影响

符合

应制定紧急发布流程并定义紧急发布流程与紧急变更流程的接口

符合

应该建立一个可控的可接受的测试环境，并在分发之前对所有发布进行测试。

符合

应对发布的成功或失败进行衡量。衡量指标包括：发布后一段时间与该发布相关的事件多少、评估发布对业务、IT运行和支持人员的影响等

符合

ITSS考试

发布成败的衡量结果应作为服务改进计划的一个输入

符合

本帖关键字：ITSS