由 superadmin 于 2024/10/15, 16:43 最后修改
从版本< 9.1
由superadmin编辑
在2024/10/15, 16:43上
到版本
由superadmin编辑
在2024/10/13, 16:53上
<
修改评论 该版本没有评论

Summary

Details

Icon Page properties
标题
... ... @@ -1,1 +1,1 @@
1 -23 某科技公司ITIL问题管理流程方案
1 +23 某科技公司问题管理流程方案
Content
... ... @@ -24,6 +24,7 @@
24 24  1. 来自配置管理数据库的详细配置信息
25 25  1. 任何定义的临时措施（来自事故管理）
26 26  
27 +
27 27  问题管理的主要活动包括：
28 28  
29 29  1. 问题控制
... ... @@ -33,6 +33,7 @@
33 33  1. 从问题管理数据中获得管理信息
34 34  1. 完成主要问题的评估
35 35  
37 +
36 36  问题管理流程的输出：
37 37  
38 38  1. 知名错误
... ... @@ -48,7 +48,6 @@
48 48  
49 49  在事故的早期阶段，能够得到相应的而且容易应用的建议，对于组织有效地解决事故的能力来说，这是最重要的。服务台接收到的事故，对于支持员工很少是初见的或是神秘的。相似地，处于二线或三线的支持员工中的专家也已经解决了许多困难和原始事故和问题。花费在这些解决方案上的资源的最好使用方式就是将它制作成文档，这样一线的员工就可以应用它们了。
50 50  
51 -
52 52  问题管理流程试图降低影响业务的事故和问题的数量及危害，因此，问题管理的部分职责是确保以前的信息被记录在档，这样对一线及其它二线支持员工就已经是准备好可用的了。它不是简单地记录文档的问题，它要求：
53 53  
54 54  1. 信息应该建立索引，以便根据来自新事故的简单的线索就能容易地查找；
... ... @@ -63,6 +63,7 @@
63 63  1. 训练员工使用信息，理解可用信息的深度和作用，以及怎样访问和理解信息，在提供反馈方面，信息的相关性和易于使用；
64 64  1. 存贮信息的知识库－典型地基于集成的服务管理工具，使得在登录后或者在事故处理流程的初始分析阶段就能使用知识。
65 65  
67 +
66 66  一般地使用“专家系统”软件来发挥问题管理流程的作用。然而，重要的是包括专家知识，让使用系统的员工根据反馈来更新：
67 67  
68 68  1. 被识别的问题和知名错误；
... ... @@ -94,10 +94,8 @@
94 94  
95 95  问题控制流程很相似于，且高度依赖于事故控制流程的质量。事故控制重点在于解决事故，提供临时措施，对特定的事故临时修复。如果对于一个或一组事故，识别出了问题，可用的临时措施和临时修复应该由问题控制流程记录在问题记录中。问题控制流程也对问题建议最佳的可用临时措施。
96 96  
97 -
98 98  因为问题控制关注于阻止事故的重复发生，因此流程的方法应该被仔细地管理和规划。管理和规划的程度要高于事故控制，因为它的目标只是尽快地恢复正常的服务。优先权应该分配组那些可能引起严重业务中断的问题的解决。
99 99  
100 -
101 101  在事故控制中的活动包括：
102 102  
103 103  1. 问题识别和记录；
... ... @@ -221,8 +221,9 @@
221 221  1. 问题的分类－根据对业务的影响；
222 222  1. 问题的调查和诊断。
223 223  
224 -[[image:1728809269856-411.png]]
225 225  
225 +[[image:1728809269856-411.png]]
226 +
226 226  当检测到根本原因时，就开始错误控制流程。
227 227  
228 228  
... ... @@ -264,6 +264,7 @@
264 264  1. 紧急程度
265 265  1. 优先级
266 266  
268 +
267 267  问题被归类到相关的组或域（例如硬件、软件、支持软件以及相应的其它种类）。这些组能够与机构的职责匹配，或者以用户和客户为基础归类，是将问题分配给支持职员的基础。附录A给出一个简单但对问题归类有效的结构。
268 268  
269 269  新问题的识别应该在受其影响的对象（也就是它对业务的影响）分析之后。登记在CMDB中的IT基础架构中的组件间的关系有助于判断问题的影响。
... ... @@ -282,11 +282,13 @@
282 282  1. 计划推迟解决的可能性；
283 283  1. 对业务未来影响的意识，如支持月末处理的设备需求。
284 284  
287 +
285 285  每个事故、问题和变更将都会对业务服务和紧急程度有影响：
286 286  
287 287  1. 影响－描述了业务受到破坏的可能；
288 288  1. 紧急程度－表明了可用来转移或降低影响的时间。
289 289  
293 +
290 290  * **要点**
291 291  
292 292  **在最早的时机为所有问题分配影响代码。当这项工作完成后，重要的是在详细调查开始前，使所有问题归属到被管理的职员分配流程。被分配的人负责问题的解决，成为协调问题解决活动的中心。根据影响计划工作量，重要问题要立即引起注意。对低影响的问题可以允许超出特定的时间限制。**
... ... @@ -447,6 +447,7 @@
447 447  1. 特定类型或某个配置项重复出现的问题；
448 448  1. 客户对培训的需求或对更好文档的需求；
449 449  
454 +
450 450  事故和问题的分类，以及积极的分析可以揭露趋势，识别出需要进一步调查的特定（或潜在）的问题区域。例如，分析可能指出与最近安装的客户－服务器系统相关的事故是个问题区域，对客户业务的负面影响增长最快。
451 451  
452 452  
... ... @@ -472,6 +472,7 @@
472 472  1. 解决事故的持续时间和相关的成本
473 473  1. 业务成本－这可能是所有因素中最重要的
474 474  
480 +
475 475  这个方法避免将精力集中放在这样一组事故上，相对而言数量较大，而对提供的服务水平没有较高的影响；相反地，将精力放在调查一小组而更有益的事故上，它可能对组织的业务有很高的影响。
476 476  
477 477  
... ... @@ -551,6 +551,7 @@
551 551  1*. 成本（相对于预算）
552 552  1. 所采取行动的简单描述
553 553  
560 +
554 554  关于IT基础架构中不牢固的组件的信息、违背与业务协定的服务水平的信息以及与厂商定的服务水平信息都涉及到可用性管理。问题出现的频度和持续时间是相对于服务水平的效率的度量标准。要求的信息包括：
555 555  
556 556  1. 根据以下方面划分的问题和错误的数量：
... ... @@ -565,6 +565,7 @@
565 565  1. 任何临时解决行动；
566 566  1. 重大问题期望的解决时间；
567 567  
575 +
568 568  定期审计
569 569  
570 570  流程要求要求对所有操作和过程进行定期审计。审计的目的是确认问题管理和支持小组执行了预定义的过程。审计应该分析主要的问题回顾，检查：
... ... @@ -635,6 +635,7 @@
635 635  1. 对未解决的问题/知名错误，向事故管理职员建议与之相关事故的最佳的可用临时措施；
636 636  1. 帮助处理主要事故，识别根本原因；
637 637  
646 +
638 638  * **主动责任**
639 639  
640 640  1. 识别趋势和潜在的问题源（通过回顾事故和问题分析）；
... ... @@ -660,6 +660,7 @@
660 660  1. 测试最可能的原因
661 661  1. 核实真正的原因
662 662  
672 +
663 663  根据时间和可用的信息，这些阶段实现的规模可大可小。即使在只有有限的信息可用，或者时间压力很大，采取结构化的方法来分析问题，提高成功的机会也是值得的。
664 664  
665 665  
深圳市艾拓先锋企业管理咨询有限公司