From version < 16.1 >
edited by superadmin
on 2024/04/03, 12:52
To version < 17.1 >
edited by superadmin
on 2024/04/03, 12:55
< >
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -33,7 +33,6 @@
33 33  * 实践:为执行工作或实现目标而设计的一组组织资源。
34 34  * 持续改进:在各个级别进行的经常性的组织活动,以确保组织的绩效不断满足利益相关者的期望。ITIL 4通过ITIL持续改进模型支持持续改进。
35 35  
36 -
37 37  SVS的目的是通过使用和管理产品和服务,确保组织与所有利益相关者不断共同创造价值。SVS的结构如图4.1所示。图的左侧显示了从内部和外部来源向SVS馈送的机会和需求。右侧显示了为组织,其客户和其他利益相关者创造的价值。
38 38  
39 39  (% style="text-align:center" %)
... ... @@ -171,7 +171,6 @@
171 171  * 建立程序,整合管理计划外中断(事件),确定优先排序,并调查失败的原因
172 172  * 必要时分离管理服务的记录系统(如配置管理数据库)与软件开发团队使用的“参与系统”(如协作工具)之间的交互处理。
173 173  
174 -
175 175  DevOps方法建立在敏捷软件开发和服务管理技术基础之上,强调软件开发和技术运营之间的紧密协作。利用高度自动化来解放专业技术人员的时间,使他们能够专注于增值活动,DevOps能够在软件产品的可操作性、可靠性和可维护性等方面照亮前进方向,从而帮助服务管理。DevOps从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动,使产品和服务团队保持一致的目标,使用相同的方法。
176 176  
177 177  
... ... @@ -183,7 +183,6 @@
183 183  * 倡导“系统观”,强调企业治理、服务团队、软件开发和技术操作之间的紧密协作。
184 184  
185 185  
186 -
187 187  === **4.3.1  聚焦价值** ===
188 188  
189 189  
... ... @@ -237,13 +237,11 @@
237 237  * 消费者使用服务的原因
238 238  * 这些服务可以帮助他们做什么
239 239  
240 -
241 241  服务如何帮助他们实现目标
242 242  
243 243  * 服务消费者的成本/财务影响的作用
244 244  * 服务消费者所面临的风险。
245 245  
246 -
247 247  价值可以有多种形式,例如提高生产率、减少负面影响、降低成本、开拓新市场的能力或更好的竞争地位。服务消费者的价值:
248 248  
249 249  * 由他们自己的需求定义
... ... @@ -250,7 +250,6 @@
250 250  * 是通过支持预期结果和优化服务消费者的成本和风险来实现的
251 251  * 随时间推移和不同情况而变化
252 252  
253 -
254 254  ==== **4.3.1.3  客户体验** ====
255 255  
256 256  
... ... @@ -375,7 +375,6 @@
375 375  * 要认识到,有时当前状态下没有什么东西可以重用。无论重用、再利用、循环利用和升级换代是多么的理想,但有时候实现期望结果的唯一方法就是完全重新开始。然而,应该指出的是,这样的情况非常罕见。
376 376  
377 377  
378 -
379 379  === **​​​​​​​4.3.3  基于反馈迭代推进** ===
380 380  
381 381  
... ... @@ -421,7 +421,6 @@
421 421  * 能够更早发现并响应故障
422 422  * 整体质量提升。
423 423  
424 -
425 425  在一项活动的参与者之间建立适当的反馈回路,可以使他们更好地了解他们的工作来自何处,他们的产出去向何方,以及他们的行动和产出如何影响结果,这反过来又使他们能够做出更好的决策。
426 426  
427 427  
... ... @@ -450,7 +450,6 @@
450 450  
451 451  
452 452  
453 -
454 454  === **​​​​​​​4.3.4**  ​​​​​​​**协作和提升可视化程度** ===
455 455  
456 456  
... ... @@ -493,6 +493,8 @@
493 493  * 内部和外部供应商相互协作,审查共享流程,确定优化和可能的自动化的机会。
494 494  
495 495  
487 +
488 +
496 496  ==== **​​​​​​​4.3.4.2**  **沟通促进改进** ====
497 497  
498 498  
... ... @@ -517,7 +517,6 @@
517 517  * 识别瓶颈,以及过剩的产能。
518 518  * 揭开浪费的面纱
519 519  
520 -
521 521  必须让各级利益相关者参与进来,并满足他们的需求。各级领导也应在与他人沟通的过程中提供与改进工作有关的合适的信息。总之,这些行动将有助于强化正在做的事情,为什么要做,以及这些工作如何与组织的既定愿景、使命、目标和目的关联起来的。确定此类消息传递的类型、方法和频率是与沟通相关的核心活动之一。
522 522  
523 523  
... ... @@ -542,7 +542,6 @@
542 542  
543 543  
544 544  
545 -
546 546  === **​​​​​​​4.3.5  通盘思考和工作** ===
547 547  
548 548  
... ... @@ -634,6 +634,7 @@
634 634  在设计、管理或操作实践时,要注意相互矛盾的目标。例如,组织的管理层可能希望收集大量数据来做出决策,而完成记录的人可能希望流程简单,不需要输入那么多数据。通过应用这一原则和其他指导原则,该组织应就其竞争目标之间的平衡达成一致。这个例子,意味着服务应该只生成真正为决策过程提供价值的数据,记录应尽可能简化和自动化,以实现价值最大化并减少非增值工作。
635 635  
636 636  
628 +
637 637  ==== **​​​​​​​4.3.6.3**  **实施原则** ====
638 638  
639 639  
... ... @@ -649,7 +649,6 @@
649 649  
650 650  
651 651  
652 -
653 653  === **​​​​​​​4.3.7 ** **优化和自动化** ===
654 654  
655 655  
... ... @@ -666,6 +666,7 @@
666 666  ==== **​​​​​​​4.3.7.1 ** **通往优化之路** ====
667 667  
668 668  
660 +
669 669  优化实践和服务的方法有很多。ITIL中描述的概念和实践,特别是持续改进的实践,以及测量和报告的实践(参见第5.1.2和5.1.5节),对于这项工作至关重要。组织用于改进和优化绩效的具体实践可以借鉴ITIL、精益、DevOps、看板和其他来源的指南。无论具体技术如何,优化的路径都遵循以下高层次的步骤:
670 670  
671 671  * **理解提出优化方案的背景并达成一致:**这包括认同组织的总体愿景和目标。
... ... @@ -676,6 +676,7 @@
676 676  * **持续监控优化的影响:**这将有助于识别改进工作方法的机会。
677 677  
678 678  
671 +
679 679  ==== ​​​​​​​**4.3.7.2**  **利用自动化** ====
680 680  
681 681  
... ... @@ -716,7 +716,6 @@
716 716  
717 717  
718 718  
719 -
720 720  === **​​​​​​​4.3.8  原则的相互作用** ===
721 721  
722 722  
... ... @@ -773,7 +773,6 @@
773 773  
774 774  
775 775  
776 -
777 777  == **4.5  服务价值链** ==
778 778  
779 779  
... ... @@ -803,6 +803,7 @@
803 803  * **交付和支持**
804 804  
805 805  
797 +
806 806  这些活动代表组织在创造价值时所采取的步骤。每项活动都将输入转化为输出。这些输入可能是来自价值链外部的需求或其他活动的输出。所有活动都是相互关联的,每项活动都会接收触发,并触发下一步行动。
807 807  
808 808  
... ... @@ -817,6 +817,7 @@
817 817  * 通过改进启动和管理各层级的改进
818 818  
819 819  
812 +
820 820  为了执行某项任务或响应特定情况,组织创建服务价值流。这些服务价值流是活动和实践的特定组合,每一服务价值流都是针对特定场景而设计的。价值流一经设计,就应不断改进。
821 821  
822 822  
... ... @@ -833,6 +833,8 @@
833 833  * 发布和部署
834 834  * 支持。
835 835  
829 +
830 +
836 836  虽然高层级的步骤是通用的,但不同的产品和客户需要不同的工作流。例如:
837 837  
838 838  * 为新客户开发新应用程序,就从初始契动(售前)开始,然后进行业务分析、原型设计、拟定协议、开发、测试,最终发布和支持。
... ... @@ -840,6 +840,8 @@
840 840  * 修复现场应用程序中的错误,则可能会在支持中启动,接着回滚到先前的稳定版本(发布),然后转到开发、测试和发布补丁程序。
841 841  * 使用新的或现有的应用程序进行实验,以扩展目标受众,可以从创新规划和原型设计开始,然后继续开发,最终到有限的一组用户试用版本,以测试他们对所做变更的看法。
842 842  
838 +
839 +
843 843  这些是价值流的例子:它们以各种方式将实践和价值链活动结合起来,以改进产品和服务,增加消费者和组织的潜在价值。
844 844  
845 845  
... ... @@ -860,7 +860,6 @@
860 860  * 在每次迭代结束时向利益相关者展示一份可工作的软件(至少是最小可行)
861 861  
862 862  
863 -
864 864  如果得到成功应用,敏捷软件开发可以快速响应服务消费者不断变化的需求。但是,在许多组织中,敏捷软件开发并未带来预期的收益,这通常是由于在服务生命周期的其他阶段缺乏敏捷方法。这种分立的敏捷性对组织来说没有多大意义,因为价值链的整体表现取决于最慢的部分。应当对服务价值链应用整体性的方法,以确保服务提供商在整个服务生命周期内都是敏捷的。这意味着服务管理所有维度和服务价值链的所有活动都具有着敏捷性这一品质。
865 865  
866 866  
... ... @@ -908,6 +908,7 @@
908 908  * 有关新的和变更的产品与服务的知识和信息,他们来自于设计和转换活动,以及获取/构建活动。
909 909  
910 910  
907 +
911 911  这项活动的主要输出是:
912 912  
913 913  * 战略、战术和运营计划
... ... @@ -917,7 +917,6 @@
917 917  * 提供给契动活动的产品和服务组合
918 918  * 提供给契动活动的合同和协议要求。
919 919  
920 -
921 921  === **​​​​​​​4.5.2 ** **改进** ===
922 922  
923 923  
... ... @@ -936,6 +936,7 @@
936 936  * 来自于契动活动的有关第三方服务组件的知识和信息。
937 937  
938 938  
935 +
939 939  该价值链活动的关键输出是:
940 940  
941 941  * 对所有价值链活动的改进举措
... ... @@ -945,6 +945,8 @@
945 945  * 为设计和转换活动提供的服务绩效信息。
946 946  
947 947  
945 +
946 +
948 948  === **​​​​​​​4.5.3  ​​​​​​​契动** ===
949 949  
950 950  
... ... @@ -972,6 +972,7 @@
972 972  * 来自于改进活动的改进状态报告。
973 973  
974 974  
974 +
975 975  该价值链活动的关键产出是:
976 976  
977 977  * 提供给计划活动的综合性的要求和机会
... ... @@ -984,6 +984,8 @@
984 984  * 提供给为客户的服务绩效报告。
985 985  
986 986  
987 +
988 +
987 987  === ​​​​​​​**4.5.4  设计和转换** ===
988 988  
989 989  
... ... @@ -1007,6 +1007,7 @@
1007 1007  * 契动活动提供的与外部和内部供应商及合作伙伴签订的合同和协议。
1008 1008  
1009 1009  
1012 +
1010 1010  这项活动的主要输出是:
1011 1011  
1012 1012  * 提供给获取/构建活动的需求和规格说明
... ... @@ -1016,6 +1016,8 @@
1016 1016  * 提供给改进活动的绩效信息和改进机会。
1017 1017  
1018 1018  
1022 +
1023 +
1019 1019  === **​​​​​​​4.5.5 ** ​​​​​​​**获取/构建** ===
1020 1020  
1021 1021  
... ... @@ -1038,7 +1038,6 @@
1038 1038  * 有关新的和变更的产品和服务的知识和信息,它们来自于设计和转换活动
1039 1039  * 来自于契动活动的有关第三方服务组件的知识和信息。
1040 1040  
1041 -
1042 1042  这项活动的主要输出是:
1043 1043  
1044 1044  * 提供给交付和支持活动的服务组件
... ... @@ -1048,6 +1048,8 @@
1048 1048  * 提供给改进活动的绩效信息和改进机会。
1049 1049  
1050 1050  
1055 +
1056 +
1051 1051  === **​​​​​​​4.5.6**  **交付和支持** ===
1052 1052  
1053 1053  
... ... @@ -1095,6 +1095,7 @@
1095 1095  * 持续改进实践,它支持组织日常改进工作。
1096 1096  
1097 1097  
1104 +
1098 1098  ITIL持续改进模型可用作支持改进举措的高阶指南。该模型的使用将提高ITSM举措成功的可能性,聚焦客户价值,并确保改进工作能够与组织的愿景相联系。该模型支持以迭代的方式进行改进,将工作划分为可管理的部分,具有可以逐步实现的单一的目标。
1099 1099  
1100 1100  
... ... @@ -1143,6 +1143,7 @@
1143 1143  * 需要为计划中的改进建立高层次的愿景。
1144 1144  
1145 1145  
1153 +
1146 1146  这一步骤内的工作应当确保:
1147 1147  
1148 1148  * 已经理解了高层次的方向
... ... @@ -1152,6 +1152,7 @@
1152 1152  * 负责实施改进的人员或团队在实现组织愿景方面方面的角色是明确的。
1153 1153  
1154 1154  
1163 +
1155 1155  如果跳过此步骤,则改进可能只是针对所涉及的人员或团队的优化,而不是对整个组织的优化,或者改进的重点独独落在非增值活动上。
1156 1156  
1157 1157  
... ... @@ -1319,13 +1319,17 @@
1319 1319  
1320 1320  如果改进已达到预期的价值,那么该举措的重点就应转移到推广这些成功经验和巩固引入的所有新方法上。这是为了确保进展不会丢失,并为下一次改进建立支持和势头。
1321 1321  
1331 +
1322 1322  应该使用组织变革管理和知识管理实践,将变革融入组织当中,并确保改进和改变的行为不会有反弹回潮的风险。领导者和管理者应该帮助团队将新的工作方法真正融入到日常工作中,并将新的行为制度化。
1323 1323  
1334 +
1324 1324  如果没有实现改进的预期结果,则需要向利益相关方说明举措失败的原因。这需要对改进进行全面分析,记录并交流经验教训。这应该包括,根据收集的经验,在下一次迭代中可以采取的不同做法的描述。无论当前迭代的结果如何,透明度对于未来的工作都很重要。
1325 1325  
1337 +
1326 1326  如果跳过此步骤,那么改进可能仍然是孤芳自赏的举措,任何进展都可能随着时间的推移而消失。今后的改进也可能很难获得支持,也难以将持续改进融入组织文化当中。
1327 1327  
1328 1328  
1341 +
1329 1329  (% class="box" %)
1330 1330  (((
1331 1331  **ITIL的故事:我们如何保持这种势头?**
... ... @@ -1364,16 +1364,21 @@
1364 1364  |Did we get there?|✔| | |✔|✔| |
1365 1365  |How do we keep the momentum going?|✔| | |✔|✔| |✔
1366 1366  
1380 +
1367 1367  **持续改进和约束理论:**
1368 1368  
1369 1369  在日新月异的商业环境中,一个企业能否快速变革,无论是对外部因素的反应,还是对市场的颠覆,都能决定企业的失败与成功。
1370 1370  
1385 +
1371 1371  在规划改进时,关键是把重点放在最优先的工作上。根据约束理论(ToC),价值链中最薄弱的环节决定了系统的流量和吞吐量。必须尽可能提升最薄弱的环节(有时会暴露出新的最薄弱环节),价值链中的所有其他步骤都必须围绕它来组织。
1372 1372  
1388 +
1373 1373  使用价值流映射可以确定价值流的最弱环节。这是一种精益实践,它检查流动,量化其浪费(例如,延迟),并在此过程中确定其最薄弱的环节。如果最薄弱的环节是信息系统的开发,那么应用敏捷原则和实践可以提高功能开发的质量和速度。这包括业务和IT之间的关键性互动,在这种互动中,定义了所需的功能和非功能性需求。有助于此的ITIL 4实践主要包括软件开发和管理、业务分析和关系管理等。
1374 1374  
1391 +
1375 1375  如果最薄弱的环节是部署的速度和可靠性,那么使用DevOps的原则、技术实践和工具就可以起到显着的作用。与此相关的ITIL 4实践包括部署管理、发布管理和组织变革管理。
1376 1376  
1394 +
1377 1377  最后,如果最薄弱的环节是IT服务的交付和支持,那么可以使用IT运营实践和工具,例如ITIL 4实践中的事件管理、问题管理、服务台以及基础架构和平台管理等。
1378 1378  
1379 1379  
深圳市艾拓先锋企业管理咨询有限公司