20150720    淡然

续上

1.9    向支持部门提供信息

问题管理提供有关识别的问题、知名错误和发出的变更请求的信息。这些信息可以是随机的或周期性的。这些信息和报告经常是为了在管理中监控问题管理流程的质量。然而，提供给业务和IT管理的报告也有助于组织内的决策支持。除此之外，报告也可以传递给其它流程和服务台。                                             ITSS培训

1.9.1    提供管理信息

管理信息应该使了解组织花费在调查、诊断和解决问题及知名错误上的努力和资源。除此，了解到问题处理的进展和结果也是很重要的。度量方式必要仔细地选择，只有通过仔细和有目的的度量才能形成关于流程质量的意见。

1.9.2    将信息分级

临时措施、永久修正或关于解决进展的简要信息应该分级给报告问题的人。这些信息也必须分级给其它客户，因为影响许多人的问题可能仅由一个人报告。

传播这些信息是服务台的基本任务。问题管理应该为此向服务台提供充分的信息和支持。通过将这些信息输入到既有的服务管理工具和数据库，问题管理能够发布相应的信息给服务台和支持部门。

为了有效地传播信息，问题管理流程应该访问配置管理信息，诸如，谁在使用什么，什么时候使用，他们处在什么位置，加上所有必要的联系人明细。问题管理要求的某些明细能够从事故管理流程的电话记录中的获得，然而，对于问题管理，在问题出现前，使用约定的联系地图和正式的沟通渠道经常是更有效果。这种类型的信息也经常在协商（或重协商）SLA的时候获得。另一个来源是日常服务回顾，它是服务水平管理的一部分。

1.10       度量


通过维护来自事故控制和问题/错误控制的信息，从而可能得到表示服务质量和流程效率的度量标准。

1.10.1   问题/错误控制报告

关于这方面的管理信息包括：

v       提出的RFC的数量以及这些RFC在涉及到的服务的可用性和可靠性方面的影响；

v       根据问题类型划分，每个部门或厂商花费在调查和诊断上的时间；

v       在根本问题被关闭或知名错误被确认前，事故发生的数量和影响；

v       在问题管理中，被动的支持效果与计划的支持效果的比率；                           ITSS认证

v       解决问题的资源规划：

u      人

u      其它使用的资源

u      成本（相对于预算）

v       所采取行动的简单描述

关于IT基础架构中不牢固的组件的信息、违背与业务协定的服务水平的信息以及与厂商定的服务水平信息都涉及到可用性管理。问题出现的频度和持续时间是相对于服务水平的效率的度量标准。要求的信息包括：

v       根据以下方面划分的问题和错误的数量：

u      状态

u      服务

u      影响

u      分类

u      用户组

v       关闭问题上花费的全部时间；

v       重大问题花费的时间；

v       从产生问题记录开始，到关闭问题或确认知名错误，花费的平均时间和最长时间，可以根据影响代码和支持组（包括提供商）划分；

v       任何临时解决行动；

v       重大问题期望的解决时间；

定期审计

流程要求要求对所有操作和过程进行定期审计。审计的目的是确认问题管理和支持小组执行了预定义的过程。审计应该分析主要的问题回顾，检查：

v       根据协定的计划产生和分析报告；

v       具有代表性的事故例子，校验相关的问题已经被正确地识别和记录；

v       具有代表性的问题例子，校验问题被正确诊断，而且是在规定的时期内；

v       具有代表性的知名错误的例子，校验知名错误已经被授权的对配置的变更所清除，并且在规定的时期内；

v       升级的限制被坚持执行；

v       文档被正确地维护－由问题管理职员更新，被接收的人执行；

v       管理报告有规律地生成，并且有明确的目的；

v       对于趋势分析表明的迹象，采取了防止措施；

v       职员培训记录。

1.10.2   度量的要点

下面是有关度量的要点：

v       在制定规范期间，为流程定义想要达到的效果的度量。计划在问题管理运营开始的时候使用它们作为控制，以评估效果，并客观地估计趋势。如果可能的话，提前或都在运营开始的前几周设置实际的目标。如果可能，还可以从当前支持活动中获得统计数据，作为设置目标的基础。这些有助于以后鉴定引入问题管理后所增加的益处；

v       不要设置不可衡量的目标；

v       当购买支持工具时，在产品评估和系统设计阶段，拿相应的度量来估计，尽量获得能够提供必要统计的工具；

v       对于关键效果标准，开发生产报表的过程。问题管理应该有规律地（如一月一次）将实际达到的效果与所有设置的目标比较回顾。记录每次回顾的结果，以用于审计。如果目标必须降低，要确认原因是目标太高，而实际运营太差。问题管理运营中的任何不足应该被回溯，使之在源头恢复正常；

v       规划设立正式的流程效果和效率的回顾，特别注意客户的需求。确保运营中的流程能够满足所有支持需求；

v       规划逐步设置更困难的目标，这要与引入问题管理流程预期的益处一起考虑；

v       监视成功的问题管理系统对职员工作量的影响，经验表明有效的流程，特别是再加上有效的变更管理和发布质量控制，迅速地降低了事故和问题的影响范围。事故数量的降低，以及由此来的支持请求的减少，导致了职员人数的下降。新的应用和新的用户会增加问题和事故，因此，问题管理应该被告知任何影响工作量的预期的变更，以便做出规划，这不仅关系到职员水平和职员数量，而且关系到其它资源，如数据库和其它IT能力；

v       有时候要在另外的揭示了问题的服务管理流程中执行审计，确保相关的详细信息传递到问题管理，以进行必要的纠正行动。                                     ITSS考试

待续：http://www.ITILxf.com/thread-51768-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^

20150720    淡然

续上

1.9    向支持部门提供信息

问题管理提供有关识别的问题、知名错误和发出的变更请求的信息。这些信息可以是随机的或周期性的。这些信息和报告经常是为了在管理中监控问题管理流程的质量。然而，提供给业务和IT管理的报告也有助于组织内的决策支持。除此之外，报告也可以传递给其它流程和服务台。                                             ITSS培训

1.9.1    提供管理信息

管理信息应该使了解组织花费在调查、诊断和解决问题及知名错误上的努力和资源。除此，了解到问题处理的进展和结果也是很重要的。度量方式必要仔细地选择，只有通过仔细和有目的的度量才能形成关于流程质量的意见。

1.9.2    将信息分级

临时措施、永久修正或关于解决进展的简要信息应该分级给报告问题的人。这些信息也必须分级给其它客户，因为影响许多人的问题可能仅由一个人报告。

传播这些信息是服务台的基本任务。问题管理应该为此向服务台提供充分的信息和支持。通过将这些信息输入到既有的服务管理工具和数据库，问题管理能够发布相应的信息给服务台和支持部门。

为了有效地传播信息，问题管理流程应该访问配置管理信息，诸如，谁在使用什么，什么时候使用，他们处在什么位置，加上所有必要的联系人明细。问题管理要求的某些明细能够从事故管理流程的电话记录中的获得，然而，对于问题管理，在问题出现前，使用约定的联系地图和正式的沟通渠道经常是更有效果。这种类型的信息也经常在协商（或重协商）SLA的时候获得。另一个来源是日常服务回顾，它是服务水平管理的一部分。

1.10       度量


通过维护来自事故控制和问题/错误控制的信息，从而可能得到表示服务质量和流程效率的度量标准。

1.10.1   问题/错误控制报告

关于这方面的管理信息包括：

v       提出的RFC的数量以及这些RFC在涉及到的服务的可用性和可靠性方面的影响；

v       根据问题类型划分，每个部门或厂商花费在调查和诊断上的时间；

v       在根本问题被关闭或知名错误被确认前，事故发生的数量和影响；

v       在问题管理中，被动的支持效果与计划的支持效果的比率；                           ITSS认证

v       解决问题的资源规划：

u      人

u      其它使用的资源

u      成本（相对于预算）

v       所采取行动的简单描述

关于IT基础架构中不牢固的组件的信息、违背与业务协定的服务水平的信息以及与厂商定的服务水平信息都涉及到可用性管理。问题出现的频度和持续时间是相对于服务水平的效率的度量标准。要求的信息包括：

v       根据以下方面划分的问题和错误的数量：

u      状态

u      服务

u      影响

u      分类

u      用户组

v       关闭问题上花费的全部时间；

v       重大问题花费的时间；

v       从产生问题记录开始，到关闭问题或确认知名错误，花费的平均时间和最长时间，可以根据影响代码和支持组（包括提供商）划分；

v       任何临时解决行动；

v       重大问题期望的解决时间；

定期审计

流程要求要求对所有操作和过程进行定期审计。审计的目的是确认问题管理和支持小组执行了预定义的过程。审计应该分析主要的问题回顾，检查：

v       根据协定的计划产生和分析报告；

v       具有代表性的事故例子，校验相关的问题已经被正确地识别和记录；

v       具有代表性的问题例子，校验问题被正确诊断，而且是在规定的时期内；

v       具有代表性的知名错误的例子，校验知名错误已经被授权的对配置的变更所清除，并且在规定的时期内；

v       升级的限制被坚持执行；

v       文档被正确地维护－由问题管理职员更新，被接收的人执行；

v       管理报告有规律地生成，并且有明确的目的；

v       对于趋势分析表明的迹象，采取了防止措施；

v       职员培训记录。

1.10.2   度量的要点

下面是有关度量的要点：

v       在制定规范期间，为流程定义想要达到的效果的度量。计划在问题管理运营开始的时候使用它们作为控制，以评估效果，并客观地估计趋势。如果可能的话，提前或都在运营开始的前几周设置实际的目标。如果可能，还可以从当前支持活动中获得统计数据，作为设置目标的基础。这些有助于以后鉴定引入问题管理后所增加的益处；

v       不要设置不可衡量的目标；

v       当购买支持工具时，在产品评估和系统设计阶段，拿相应的度量来估计，尽量获得能够提供必要统计的工具；

v       对于关键效果标准，开发生产报表的过程。问题管理应该有规律地（如一月一次）将实际达到的效果与所有设置的目标比较回顾。记录每次回顾的结果，以用于审计。如果目标必须降低，要确认原因是目标太高，而实际运营太差。问题管理运营中的任何不足应该被回溯，使之在源头恢复正常；

v       规划设立正式的流程效果和效率的回顾，特别注意客户的需求。确保运营中的流程能够满足所有支持需求；

v       规划逐步设置更困难的目标，这要与引入问题管理流程预期的益处一起考虑；

v       监视成功的问题管理系统对职员工作量的影响，经验表明有效的流程，特别是再加上有效的变更管理和发布质量控制，迅速地降低了事故和问题的影响范围。事故数量的降低，以及由此来的支持请求的减少，导致了职员人数的下降。新的应用和新的用户会增加问题和事故，因此，问题管理应该被告知任何影响工作量的预期的变更，以便做出规划，这不仅关系到职员水平和职员数量，而且关系到其它资源，如数据库和其它IT能力；

v       有时候要在另外的揭示了问题的服务管理流程中执行审计，确保相关的详细信息传递到问题管理，以进行必要的纠正行动。                                     ITSS考试

待续：http://www.ITILxf.com/thread-51768-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^