From version < 21.1
edited by superadmin
on 2024/10/28, 04:34
To version < 18.1 >
edited by superadmin
on 2024/10/28, 12:31
<
Change comment: 上传新附件1730089903777-351.png

Summary

Details

Icon Page properties
Content
... ... @@ -64,12 +64,12 @@
64 64  
65 65  = 2. 事件管理流程介绍 =
66 66  
67 -== 2.1 流程目的 ==
67 +== 2.1 流程目的 ==
68 68  
69 69  事件管理流程是负责解决IT服务的突发事件的运维流程。它的目的是尽快恢复被中断或受到影响的IT服务,所以事件管理的特点往往是以解决表征现象为目的,而不在于查找根本原因。
70 70  
71 71  
72 -== 2.2 流程主要内容 ==
72 +== 2.2 流程主要内容 ==
73 73  
74 74  事件管理流程着眼于快速解决IT环境中的突发事件,并降低其对业务的影响度,流程内容如下:
75 75  
... ... @@ -91,7 +91,7 @@
91 91  结束   如果确认已解决,关闭记录,更新文档。
92 92  
93 93  
94 -== 2.3 业务价值 ==
94 +== 2.3 业务价值 ==
95 95  
96 96  事件管理流程将在多方面对XX所技术运维中心的IT服务产生积极作用,具体表现在:
97 97  
... ... @@ -99,12 +99,7 @@
99 99  * 提高客户满意度 – 事件管理流程通过记录和管理事件的集成系统来提供有效服务。同时,也提供了服务供应者和使用者的沟通渠道,加强了技术运维中心和用户之间的双向认同。
100 100  * 集中化事件数据 – 通过事件管理流程来统一收集事件数据,这些数据被其他流程所使用,如问题管理流程将分析这些数据以确定事件的根本原因,并确定纠正措施以消除再次发生的可能性。
101 101  
102 -(% class="wikigeneratedid" %)
103 -= =
104 104  
105 -(% class="wikigeneratedid" %)
106 -= =
107 -
108 108  = 3. IT服务模式 =
109 109  
110 110  XX所的IT服务支撑工作由所内运维人员、XX公司和外部厂商、服务商共同承担,按照职责和技能划分为服务台、一线、二线、三线的层级支撑结构,服务台作为面向用户的统一入口,主要负责事件的受理和分派;一、二、三线支持由所内技术人员和外部支持人员组成,负责解决事件。IT服务模式如下图所示:
... ... @@ -116,7 +116,7 @@
116 116  
117 117  = 4. 事件管理的策略与原则 =
118 118  
119 -== 4.1 常规原则 ==
114 +== 4.1 常规原则 ==
120 120  
121 121  1. 服务台是IT部门向IT用户提供的单一联系点,(通过电话、邮件等)对事件进行集中响应;
122 122  1. 任何IT事件都必须执行事件管理流程。服务台提交事件单,所有事件或服务请求及其解决方案,都要记录在IT服务管理平台中;
... ... @@ -123,18 +123,14 @@
123 123  1. 服务台是事件处理过程的监督人,负责跟踪事件的处理,确保事件能按时解决;
124 124  1. 定义服务台、一线支持、二线支持、三线支持人员,并落实到人员,使IT支持人员明确自己的角色和相关的责任,流程能够得到正确的执行,保证服务的质量,使IT人员变成服务人员。
125 125  
126 -(% class="wikigeneratedid" %)
127 -== ==
128 128  
129 -== 4.2 沟通原则 ==
122 +== 4.2 沟通原则 ==
130 130  
131 131  1. 事件管理流程将就任何已知的或可能的事件的相关情况与受到影响的用户进行沟通。在事件解决过程中,服务台应及时向最终用户通报事件的处理情况,使用户了解事件的解决状态;
132 132  1. 对于已知或计划内的服务中断要及时准确的提前通知所有受影响的部门和用户。
133 133  
134 -(% class="wikigeneratedid" %)
135 -== ==
136 136  
137 -== 4.3 事件升级原则 ==
128 +== 4.3 事件升级原则 ==
138 138  
139 139  为了确保重要事件的及时解决,应严格执行定事件升级流程。制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导,引起更多的重视,提供合适的资源,从而快速找到事件的解决方案。
140 140  
... ... @@ -141,18 +141,14 @@
141 141  1. 服务台、一线、二线支持应及时将不能解决的事件升级到其后一级的支持人员,若未及时升级,事件经理应及时介入,负责协调升级处理;
142 142  1. 各支持人员应及时响应和处理分配到本组或自己的事件单,如果超出规定的响应时限和解决时限,系统应将事件信息通报事件经理,事件经理负责协调资源,并督促事件能够及时响应和处理。
143 143  
144 -(% class="wikigeneratedid" %)
145 -== ==
146 146  
147 -== 4.4 事件关闭原则 ==
136 +== 4.4 事件关闭原则 ==
148 148  
149 149  1. 事件的关闭遵循谁开单谁关闭的原则;(由IT用户申报的事件单,关闭必须由服务台完成)
150 150  1. 紧急程度较低的事件可设定自动关闭时间,在解决一段时间后由系统自动关闭。
151 151  
152 -(% class="wikigeneratedid" %)
153 -== ==
154 154  
155 -== 4.5 定期回顾原则 ==
142 +== 4.5 定期回顾原则 ==
156 156  
157 157  建立定期的服务回顾和检查制度。
158 158  
... ... @@ -159,10 +159,8 @@
159 159  1. 回顾本周期内的故障记录,分析是否需要提出问题;
160 160  1. 回顾正在进行中的故障(查看故障处理记录,工作日志、处理状态等等),分析是否存在优先级较高的待解决的故障,需要协调解决。
161 161  
162 -(% class="wikigeneratedid" %)
163 -== ==
164 164  
165 -== 4.6 流程关联原则 ==
150 +== 4.6 流程关联原则 ==
166 166  
167 167  * 和问题管理流程的关系
168 168  
... ... @@ -185,7 +185,7 @@
185 185  事件流程查询知识库知识信息,为事件处理提供支持。
186 186  
187 187  
188 -== 4.7 紧急事件处理原则 ==
173 +== 4.7 紧急事件处理原则 ==
189 189  
190 190  当发生事件优先级为特大或者重大的事件后,服务台应立即通知事件经理,由事件经理通知相关领导共同协调相关资源,启动紧急事件流程(参见《XX商品交易所信息系统应急处置报告流程》),待事件处理完毕后再由事件处理人登陆系统补录事件信息。
191 191  
... ... @@ -216,10 +216,8 @@
216 216  1. 理解业务对于事件管理的需求;
217 217  1. 良好的沟通技能,能够取得公司高层的支持,获得所需资源。
218 218  
219 -(% class="wikigeneratedid" %)
220 -== ==
221 221  
222 -== 5.2 事件经理 ==
205 +== 5.2 事件经理 ==
223 223  
224 224  事件经理负责事件解决过程中的协调和监控,事件升级的判断以及具体执行。
225 225  
... ... @@ -239,10 +239,8 @@
239 239  1. 较强的口头表达能力和客户沟通技巧;
240 240  1. 处理纠纷的能力。
241 241  
242 -(% class="wikigeneratedid" %)
243 -== ==
244 244  
245 -== 5.3 服务台 ==
226 +== 5.3 服务台 ==
246 246  
247 247  服务台人员负责接收所有事件,对事件进行初步处理,不能处理的事件分派到合适的一线支持或者二线支持人员。
248 248  
... ... @@ -262,10 +262,8 @@
262 262  1. 一定的技术能力;
263 263  1. 较强的沟通能力。
264 264  
265 -(% class="wikigeneratedid" %)
266 -== ==
267 267  
268 -== 5.4 一线支持 ==
247 +== 5.4 一线支持 ==
269 269  
270 270  一线支持人员负责对服务台分派的事件进行分析,提出解决方案,并在必要时提供现场支持。
271 271  
... ... @@ -284,10 +284,8 @@
284 284  1. 较强的技术能力;
285 285  1. 较强的分析能力。
286 286  
287 -(% class="wikigeneratedid" %)
288 -== ==
289 289  
290 -== 5.5 二线支持 ==
267 +== 5.5 二线支持 ==
291 291  
292 292  二线支持人员是技术领域的专家。处理一线支持人员无法解决的事件,实施解决方案。
293 293  
... ... @@ -306,10 +306,8 @@
306 306  1. 资深技术背景和技术能力;
307 307  1. 较强的分析能力。
308 308  
309 -(% class="wikigeneratedid" %)
310 -== ==
311 311  
312 -== 5.6 三线支持 ==
287 +== 5.6 三线支持 ==
313 313  
314 314  对于XX所运维中心来说,三线支持主要是XX公司和外部厂商,在事件处理流程中,由一线或二线支持专家,来协调三线人员协助处理事件。
315 315  
... ... @@ -319,6 +319,7 @@
319 319  1. 在规定的时间内解决事件;
320 320  1. 负责协调厂商、开发商内部资源;
321 321  
297 +
322 322  技能要求:
323 323  
324 324  1. 熟悉术平台和技术环境;
... ... @@ -327,9 +327,10 @@
327 327  
328 328  
329 329  
306 +
330 330  = 6. 技术平台相关代码定义 =
331 331  
332 -== 6.1 事件单信息项 ==
309 +== 6.1 事件单信息项 ==
333 333  
334 334  
335 335  |**编号**|**属性**|**说明**
... ... @@ -364,6 +364,7 @@
364 364  |29|响应时间目标|
365 365  
366 366  
344 +
367 367  == 6.2 任务单信息项 ==
368 368  
369 369  维护任务单包含如下信息项:
... ... @@ -387,10 +387,8 @@
387 387  |16|配置项|相关配置项
388 388  |17|相关|与事件、问题、变更之间的关联
389 389  
390 -(% class="wikigeneratedid" %)
391 -== ==
392 392  
393 -== 6.3 事件分类 ==
369 +== 6.3 事件分类 ==
394 394  
395 395  对事件进行分类,主要目的在于方便各个事件处理组之间的信息沟通,为事件的诊断和处理提供信息,并产生相关的管理信息报表,从而达到优化提高IT服务质量,提高事件处理效率的目标。
396 396  
... ... @@ -451,7 +451,7 @@
451 451  |电源
452 452  |网络
453 453  |(% rowspan="2" %)其它
454 -|
430 +|
455 455  |(% rowspan="4" %)软件类|操作系统
456 456  |交易软件
457 457  |管理软件
... ... @@ -463,11 +463,12 @@
463 463  |管理软件
464 464  
465 465  
442 +
466 466  == 6.4 影响度、优先级 ==
467 467  
468 468  通过事件的“影响程度”来评估每个事件的“优先级”。
469 469  
470 -* **优先级**
447 +1. **优先级**
471 471  
472 472  |**编号**|**代码**|**解释**
473 473  |1|P1|特大事件
... ... @@ -476,6 +476,7 @@
476 476  |4|P4|普通事件
477 477  |5|P5|次要事件
478 478  
456 +
479 479  * **影响程度**
480 480  
481 481  |**编号**|**事件级别**|**影响程度**
... ... @@ -539,10 +539,8 @@
539 539  * 服务请求。
540 540  )))
541 541  
542 -(% class="wikigeneratedid" %)
543 -== ==
544 544  
545 -== 6.5 优先级和解决时限 ==
521 +== 6.5 优先级和解决时限 ==
546 546  
547 547  对于不同的事件优先级,事件处理的解决时限要求和响应时限要求不同。
548 548  
... ... @@ -553,6 +553,7 @@
553 553  |4|P4|24个小时|2小时
554 554  |5|P5|48个小时|4小时
555 555  
532 +
556 556  **解决时限的定义**:事件单的实际完成时间(状态为已解决) - 事件单的分派时间(状态为处理中)。
557 557  
558 558  **响应时限的定义**:事件单的响应时间(状态处理中)- 事件单的创建时间(状态为已分派)。
... ... @@ -559,7 +559,7 @@
559 559  
560 560  == ==
561 561  
562 -== 6.6 事件通告路径 ==
539 +== 6.6 事件通告路径 ==
563 563  
564 564  对于特大和重大的事件,需要及时通告事件经理。如果该事件的响应或解决超过了时限,需要通告事件经理,同时也要根据具体情况通告给其他相关管理人员。具体定义如下表:
565 565  
... ... @@ -603,10 +603,8 @@
603 603  * 次要事件超过48小时未解决立即通知事件经理、技术负责人、相关主岗
604 604  )))
605 605  
606 -(% class="wikigeneratedid" %)
607 -== ==
608 608  
609 -== 6.7 事件状态 ==
584 +== 6.7 事件状态 ==
610 610  
611 611  |**编号**|**代码**|**描述**
612 612  |1|已登记|新开事件记录或事件已创建
... ... @@ -615,10 +615,8 @@
615 615  |4|已解决|事件已解决
616 616  |5|关闭|事件已关闭
617 617  
618 -(% class="wikigeneratedid" %)
619 -== ==
620 620  
621 -== 6.8 事件结束代码 ==
594 +== 6.8 事件结束代码 ==
622 622  
623 623  |**编号**|(% colspan="2" %)**代码**|**描述**
624 624  |1.|服务台解决|服务台解决|由服务台维护解决
... ... @@ -634,10 +634,8 @@
634 634  |7.|(% colspan="2" %)误报|属于误报事件
635 635  |8.|(% colspan="2" %)拒绝|事件被拒绝
636 636  
637 -(% class="wikigeneratedid" %)
638 -== ==
639 639  
640 -== 6.9 事件来源 ==
611 +== 6.9 事件来源 ==
641 641  
642 642  |**编号**|**代码**|**备注**
643 643  |1.|电话|服务台通过客户电话创建的
... ... @@ -647,10 +647,8 @@
647 647  |5|短信|短信报警
648 648  |6|Web自助提交|通过web自助方式提交
649 649  
650 -(% class="wikigeneratedid" %)
651 -== ==
652 652  
653 -== 6.10 事件支持满意度 ==
622 +== 6.10 事件支持满意度 ==
654 654  
655 655  |**编号**|**代码**|**备注**
656 656  |1|非常好|用户非常满意
... ... @@ -721,7 +721,7 @@
721 721  
722 722  = 8. 事件管理流程详细设计 =
723 723  
724 -== 8.1 (100.1)事件记录和分类 ==
693 +== 8.1 (100.1)事件记录和分类 ==
725 725  
726 726  
727 727  (% style="text-align:center" %)
... ... @@ -770,232 +770,11 @@
770 770  1. 其它优先级否,转100.2初始支持
771 771  )))
772 772  
773 -(% class="wikigeneratedid" %)
774 -== ==
775 775  
776 -== 8.2 (100.2)初始事件支持 ==
743 +== 8.2 (100.2)初始事件支持 ==
777 777  
778 778  (% style="text-align:center" %)
779 779  [[image:1730085324548-652.png]]
780 780  
781 -流程描述如下:
782 782  
783 -(% style="text-align:center" %)
784 -[[image:1730085467371-585.png]]
785 -
786 -
787 -
788 -== 8.3** **(100.3)(100.4) 一、二线尝试解决 ==
789 -
790 -(% style="text-align:center" %)
791 -[[image:图片5.jpg]]
792 -
793 -流程描述如下:
794 -
795 -
796 -(% style="text-align:center" %)
797 -[[image:1730085584472-457.png]]
798 -
799 -(% style="text-align:center" %)
800 -[[image:1730085602257-876.png]]
801 -
802 -
803 -
804 -== 8.4 (100.3.5) 子任务分派 ==
805 -
806 -=== 8.4.1 (100.3.5.1)分派任务子单 ===
807 -
808 -(% style="text-align:center" %)
809 -[[image:1730085640233-794.png]]
810 -
811 -
812 -具体描述如下:
813 -
814 -|**序号**|**步骤名称**|**责任人**|**物理流程描述**
815 -|100.3.5.1.1|创建子任务单|一或二线支持|根据事件的信息描述,判断需要拆分成几个任务子单。
816 -|100.3.5.1.2|填写子单信息|一或二线支持|创建任务子单,补充或者填写子单信息,设置分派组和分派人信息。
817 -|100.3.5.1.3|保存子单|一或二线支持|保存子单信息。
818 -| |继续创建子任务?|一或二线支持|(((
819 -判断该是否需要继续添加子单,
820 -
821 -如果是转100.3.5.1.1继续创建任务子单;
822 -
823 -否则转100.3.5.1.4;
824 -)))
825 -|100.3.5.1.4|保存主单|一或二线支持|保存主单信息。
826 -
827 -
828 -=== 8.4.2** **(100.3.5.2)任务处理 ===
829 -
830 -(% style="text-align:center" %)
831 -[[image:1730085687648-477.png]]
832 -
833 -
834 -具体描述如下:
835 -
836 -|**序号**|**步骤名称**|**责任人**|**物理流程描述**
837 -|100.3.5.2.1|尝试找出解决方案|一或二线支持|根据事件的信息描述,分析事件的原因,并尝试找出解决方案,并做相关处理
838 -|100.3.5.2.2|记录解决方案|一或二线支持|将成功的解决方案和结束代码记录在系统中,并更改任务单状态为“已解决”。
839 -
840 -
841 -=== 8.4.3 (100.3.5.3)关闭任务单 ===
842 -
843 -(% style="text-align:center" %)
844 -[[image:1730085716434-195.png]]
845 -
846 -
847 -具体描述如下:
848 -
849 -|**序号**|**步骤名称**|**责任人**|**物理流程描述**
850 -|100.3.5.3.1|更新任务单|一或二线支持|更新任务单,包括解决方案,确认情况,用户反馈等。确保信息的完整性。
851 -|100.3.5.3.2|选择结束代码|一或二线支持|根据具体情况选择相应任务结束代码(同事件结束代码)
852 -|100.3.5.3.3|关闭子任务|一或二线支持|任务单关闭后,系统自动发送通知给主单处理人,告知任务单处理情况。
853 -| |所有任务单都完成?|一或二线支持|(((
854 -如果事件主单的分单人是自己,查看所有的子单是否都已经完成,并对任务完成情况进行填写。
855 -
856 -1. 如果是,则转到100.6,记录事件解决方案
857 -1. 如果否,则转到100.3.5.3.4等待其他任务完成
858 -)))
859 -|100.3.5.3.4|等待其他任务|一或二线支持|等待其他主单相同的子任务单完成
860 -
861 -
862 -== 8.5 (100.5)三线尝试解决 ==
863 -
864 -(% style="text-align:center" %)
865 -[[image:1730085754013-340.png]]
866 -
867 -
868 -流程描述如下:
869 -
870 -(% style="text-align:center" %)
871 -[[image:1730085820301-323.png]]
872 -
873 -== ==
874 -
875 -== 8.6 (100.6)记录解决方案细节 ==
876 -
877 -(% style="text-align:center" %)
878 -[[image:1730085868612-445.png]]
879 -
880 -
881 -
882 -流程描述如下:
883 -
884 -(% style="text-align:center" %)
885 -[[image:1730089877241-496.png]]
886 -
887 -
888 -
889 -== 8.7 (100.7)关闭事件 ==
890 -
891 -(% style="text-align:center" %)
892 -[[image:1730089903777-351.png]]
893 -
894 -
895 -流程描述如下:
896 -
897 -|**序号**|**步骤名称**|(% style="width:89px" %)**责任人**|(% style="width:93px" %)**输入**|**输出**|**说明**
898 -| |监控系统自动告警?|(% style="width:89px" %)服务台|(% style="width:93px" %)事件记录|事件记录|(((
899 -服务台判断是否是监控系统自动产生的告警;
900 -
901 -1. 是,转100.7.1更新事件状态
902 -1. 否,转100.7.2与用户处确认事件解决
903 -)))
904 -|100.7.1|更新事件状态及结束代码,关闭事件|(% style="width:89px" %)服务台|(% style="width:93px" %)已解决的事件记录|关闭的事件|更新事件记录,状态为“关闭”,结束代码根据实际处理结果或用户反馈确定;如果是由监控生成的事件,由系统自动关闭。
905 -|100.7.2|确认事件解决|(% style="width:89px" %)服务台|(% style="width:93px" %)用户反馈|反馈结果|从事件请求人处确认所提供的解决方案是否有效
906 -| |是否解决?|(% style="width:89px" %)服务台|(% style="width:93px" %) | |(((
907 -判断是否解决方案是否有效?
908 -
909 -1. 是,转100.7.1
910 -1. 否,转100.7.3重开单处理
911 -)))
912 -|100.7.3|重开单处理|(% style="width:89px" %)服务台|(% style="width:93px" %)未解决的事件记录|新的事件记录|(((
913 -服务台将该事件单的结束代码置为“未解决”,关闭保存;
914 -
915 -对事件进行重开单操作,分配到原处理人员处理,新事件单状态“已分派”
916 -
917 -注:服务台应该和原处理人员沟通事件的确认结果和后续的处理方式
918 -)))
919 -
920 -
921 -== 8.8 (100.8)事件处理监控 ==
922 -
923 -(% style="text-align:center" %)
924 -[[image:1730089946753-338.png]]
925 -
926 -流程描述如下:
927 -
928 -|**序号**|**步骤名称**|(% style="width:86px" %)**责任人**|(% style="width:146px" %)**输入**|(% style="width:93px" %)**输出**|(% style="width:824px" %)**说明**
929 -|100.8.1|事件队列的监控|(% style="width:86px" %)事件经理|(% style="width:146px" %)(((
930 -当前打开的事件单
931 -
932 -服务管理平台的超时告警
933 -)))|(% style="width:93px" %) |(% style="width:824px" %)(((
934 -事件经理可以从以下途径获取事件处理的信息
935 -
936 -1. 服务台系统自动发送的告警通知
937 -1. 查询服务台系统的当前处理中的事件列表
938 -)))
939 -| |需要介入吗?|(% style="width:86px" %)事件经理|(% style="width:146px" %) |(% style="width:93px" %) |(% style="width:824px" %)(((
940 -事件经理根据处理时限和该事件对业务的影响程度,判断是否需要及时介入,帮助协调资源解决
941 -
942 -1. 需要介入,转100.8.2
943 -1. 不需要,则继续监控
944 -)))
945 -|100.8.2|召集资源协商解决|(% style="width:86px" %)事件经理|(% style="width:146px" %)(((
946 -告警事件
947 -
948 -支持人员的电话通知
949 -)))|(% style="width:93px" %)解决方案|(% style="width:824px" %)由于处理不及时而可能导致用户满意度下降的事件或疑难事件,事件经理负责召集相应二线专家,共同商讨并制定解决方案,并实施解决方案
950 -| |可以解决吗?|(% style="width:86px" %)事件经理|(% style="width:146px" %) |(% style="width:93px" %) |(% style="width:824px" %)(((
951 -1. 如果解决,转100.7关闭事件
952 -1. 无法解决,转100.8.3升级到管理层解决
953 -)))
954 -|100.8.3|升级到管理层解决|(% style="width:86px" %)事件经理|(% style="width:146px" %)升级的事件记录|(% style="width:93px" %)解决方案|(% style="width:824px" %)事件经理负责将升级事件通报到管理层,通过高层寻求更多的资源介入,共同商讨和制定解决方案
955 -
956 -
957 -
958 -= 9. 事件管理流程关键指标 =
959 -
960 -为了控制流程的质量,必须为流程设置衡量指标。通过对指标的分析,可以有效地对流程的运行情况进行监控和改进。
961 -
962 -
963 -|**序号**|**衡量指标**|**作用**
964 -|1|服务台受理事件总数|考察统计周期内服务台受理的事件总量,用来衡量总工作量
965 -|2|事件成功关闭的数量/比率|考察统计周期内事件成功结束数量,衡量事件质量,如果比率过高需要事件经理重点关注
966 -|3|超时的事件数量/百分比|考察统计周期内事件超时结束数量,衡量事件质量,如果比率过高需要事件经理重点关注
967 -|4|平均解决时间|考察统计周期内事件平均解决时间,衡量事件质量,如果平均时间过高需要事件经理重点关注
968 -|5|服务台解决率|考察统计周期内服务台解决率,衡量事件质量,应当提高服务台解决率
969 -|6|重复事件数量|考察统计周期内重复事件数量,应当降低重复事件数量
970 -|7|超时未解决的事件数量|统计周期内超过预定解决时间未解决的事件数量,应当降低超时未解决事件数量
971 -|8|个人事件总数|考察周期内具体工程师处理事件的数量
972 -|9|个人超时未解决的事件数量|统计周期内具体工程师超过预定解决时间未解决的事件数量
973 -|10|具体类别事件发生总数|统计周期内具体类别事件的发生总数
974 -
975 -
976 -
977 -= 10. 流程持续改进机制 =
978 -
979 -(% style="text-align:center" %)
980 -[[image:1730090015278-258.png]]
981 -
982 -
983 -运维流程必须经过持续地调整和优化,才能满足不断变化的业务及服务要求。流程的持续改进的具体方法,可以参考上述流程持续改进模型。
984 -
985 -* **评估及改进研讨**
986 -** 根据设定的ITSM基准线对流程的原则与目标、流程责任与授权、管理目标达成情况、与其他流程的关联及相关流程工具等方面进行评估;
987 -** 根据评估结果,通过研讨,发现已在或潜在的差距和风险,并针对这些差距和风险提出改进建议。根据改进建议的实施成本、风险和耗时等因素,对改进建议进行优先级别排序;
988 -** 改进原因还可能来自于日常服务管理工作中发现的不足;
989 -** 生成评估结果及改进建议方案。
990 -* **制定流程改进计划**
991 -** 分析改进建议的相关性,并进行有效合理的分类和组合;
992 -** 针对不同的改进建议组制定具体的改进计划,将具体的改进计划分解成更详细的改进任务和动作,定义改进时间点、责任人、改进成功条件等;
993 -* **实施具体的改进活动**
994 -** 根据改进计划的要求,实施具体的流程改进活动;
995 -** 跟踪改进活动,及时更新改进计划,并上报改进活动进展及成果;
996 -* **根据业务及服务变化,进行定期评估**
997 -** 根据业务及服务的变化,对事件管理流程进行相关性评估,以满足业务和服务需求;
998 -** 除业务及服务变化可触发流程评估外,流程负责人还应定期组织对管理流程的评估和改进;
999 -** 定期生成流程改进报告(如季度或半年度)。
1000 -
1001 1001  
Icon 1730089946753-338.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -58.7 KB
Content Icon
Icon 1730090015278-258.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -104.3 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司