Changes for page 04 ITIL服务价值系统
Last modified by superadmin on 2025/01/13, 16:37
Summary
Details
- 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