Last modified by superadmin on 2024/04/03, 16:11
From version < 29.1 >
edited by superadmin
on 2021/12/21, 19:43
To version < 32.1 >
edited by superadmin
on 2021/12/21, 19:44
< >
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -1,3 +1,6 @@
1 +{{box cssClass="floatinginfobox" title="**Contents**"}}
2 +{{toc/}}
3 +{{/box}}
1 1  = 4. 创建、交付和支持服务的价值流 =
2 2  
3 3  本章节提供了有关如何：
... ... @@ -30,7 +30,6 @@
30 30  ** 一个要求团队成员访问产品或服务的请求
31 31  ** 一个要求新的基础设施能力以保留产品或服务正常运行的请求。
32 32  
33 -===== =====
34 34  
35 35  === 4.1.1 ITIL 服务价值流的结构 ===
36 36  
... ... @@ -666,4 +666,293 @@
666 666  此价值流描述了七个关键步骤（如图4.6所示）：
667 667  
668 668  (% style="text-align:center" %)
669 -[[image:1640086580821-299.png]]
671 +[[image:1640086600961-518.png]]
672 +
673 +图4.6实时服务的还原
674 +
675 +
676 +1. 确认并登记用户查询（参与）
677 +1. 调查查询，将其重新分类为事件，然后尝试修复它（交付和支持）
678 +1. 从专家团队处获取修复程序（获取/构建）
679 +1. 部署修复程序（设计和过渡）
680 +1. 验证事件是否已解决（交付和支持）
681 +1. 征集用户反馈（参与）
682 +1. 识别整体系统改进机会（改进）
683 +
684 +该价值流在步骤2分支。如果成功解决此问题的初始尝试成功，那么价值就在无须后续活动的情况下恢复了。从步骤2到价值的虚线代表这种情况。
685 +
686 +在步骤5之后，价值得到恢复，价值流就可以结束了，还可以进一步开展如步骤6和7所述的活动，请求并处理客户反馈。例如，组织通常要求从随机的客户样本中获取反馈。
687 +
688 +
689 +步骤1：确认并登记用户查询
690 +
691 +
692 +(% style="text-align:center" %)
693 +[[image:1640086651454-800.png]]
694 +
695 +
696 +价值流中的第一步是与客户或用户进行互动，以识别和确认需求，并记录有关查询的详细信息。在此阶段，用户联系只是查询，9因为尚未对其进行分类并识别为事件。
697 +
698 +通常有助于此步骤的做法包括：
699 +
700 +* **服务目录管理 **提供优化登记查询所需的信息，技能，工具和其他资源。
701 +* **服务台** 提供所需的技能，工具和其他资源，以允许客户或用户联系服务支持，并使客户支持专员能够与联系人产生共情，管理与客户或用户的沟通方式，获取及传递有关预期解决时间的信息
702 +
703 +
704 +步骤2：调查查询，将其重新分类为事件，然后尝试将其修复
705 +
706 +(% style="text-align:center" %)
707 +[[image:1640086667359-861.png]]
708 +
709 +
710 +记录查询时，训练有素的支持专员或等效自动化程序（例如聊天机器人）可以将查询识别为事件并将其重新分类，从而启动脚本或标准过程以对记录进行相应分类。由于组织的过程和工具的不同，也可能会创建一个链接到初始查询的新事件记录
711 +
712 +登记用户发起的事件后，通常会尝试快速识别其性质并应用已知的解决方案。
713 +
714 +支持专员通常遵循允许他们尝试一个或多个修复程序的活动的脚本或工作流。如果这些修复程序之一将服务恢复到正常状态，则价值恢复，价值流就可以结束。如果所有这些修复程序均不起作用，则可以将问题上报至专家角色，以开展进一步调查。
715 +
716 +通常有助于此步骤的做法包括：
717 +
718 +* **事件管理** 提供了登记事件所需的技能，工具和其他资源，以及有关可能需要多长时间解决的信息。
719 +* **知识管理** 提供查找技术信息和权变措施所需的技能，工具和其他资源，这些信息可以帮助调查，诊断和解决事件。
720 +* **监控和事态管理** 提供对监视工具和日志的访问，以帮助调查和诊断事件。
721 +* **服务配置管理 **通过提供相关配置项的信息来协助事件的调查和诊断。
722 +* **服务台 **提供使支持专员能够与客户或用户产生共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
723 +* **服务级别管理** 提供可用于评估事件影响和规划服务恢复的信息。
724 +
725 +调查和诊断通常是一项高度技术性的活动。但是，还应注意非技术因素（例如环境或经济因素），以下是可能的示例：
726 +
727 +* 网络中断的原因，是风暴影响了本地电缆或卫星连接。
728 +* 流媒体服务中止服务的原因，是客户或用户的信用卡被银行拒付。
729 +
730 +
731 +步骤3：从专家团队处获取修复程序
732 +
733 +(% style="text-align:center" %)
734 +[[image:1640086683901-189.png]]
735 +
736 +在此步骤中，由于最初尝试恢复服务失败，因此该事件将上报专家团队，或要求参考专家团队意见。在不同的情况下，专家团队的介入可能会以不同方式发生，其中一些方式可能涉及控制权的移交。例如：
737 +
738 +* 支持专员可以在供应商网站上查找补丁。但是，事件的控制权不会因此移交给供应商。
739 +* 支持专员向供应商发起事件。对用户事件的控制权并不移交，而是创建由供应商管理的并行事件工单。
740 +* 支持专员将事件上报给内部工程团队。事件的控制权将随之移交给工程团队。
741 +* 支持专员要求外包的工程团队提供修复程序。这可能会或可能不会涉及将事件的控制权交给工程团队。
742 +
743 +该修复程序也可以是容易获得的东西，例如公开可用的补丁或升级。在某些情况下，修复程序可能要操作物理设备，例如更换有故障的硬盘驱动器。通常，在处理自定义应用程序或硬件时，必须先构建修复程序，然后才能进行部署。
744 +
745 +通常有助于此步骤的做法包括：
746 +
747 +* **事件管理 **提供了更新事件记录所需的技能，工具和其他资源，其中包含构建和测试此修复程序所必需的活动的详细信息。
748 +* **基础设施和平台管理 **根据事件的性质，提供构建或配置故障基础设施或平台的修复程序所需的技能，工具和其他资源。
749 +* **知识管理 **提供所需的技能，工具和其他资源，以查找可以帮助调查和诊断事件的技术信息，并使用有关修复的信息更新现有的知识记录。
750 +* **服务配置管理 **提供创建修复程序时更新服务配置记录所需的技能，工具和其他资源。
751 +* **服务台 **提供使支持专员能够与客户或用户产生共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
752 +* **服务财务管理 **根据修复程序的性质，可能需要为解决事件所需的资源或服务组件向合作伙伴或供应商付款。
753 +* **服务验证和测试 **提供技能，工具和其他资源，以测试修复程序并确认它可以解决此事件，且符合所有相关的政策和标准。
754 +* **软件开发和管理 **根据事件的性质，提供构建或配置故障软件的修复程序所需的技能，工具和其他资源。
755 +* **供应商管理 **根据事件的性质，提供同协助构建修复程序的关键供应商进行交互所需的技能，工具和其他资源。
756 +
757 +
758 +步骤4：部署修复程序
759 +
760 +(% style="text-align:center" %)
761 +[[image:1640086717418-292.png]]
762 +
763 +获得了修复程序，并通过测试及验证后，可以将其部署到用户或生产环境。部署可以采用多种形式。例如：
764 +
765 +* 使用CI / CD 流水线在整个生产环境中分发修复程序
766 +* 将硬件组件（例如新硬盘）交付给数据中心，随后在该中心进行配置
767 +* 将硬件组件（例如新笔记本电脑）交付给最终用户办公室，由本地IT支持人员进行配置
768 +* 远程登录用户的PC以从网络驱动器安装补丁。
769 +
770 +通常有助于此步骤的做法包括：
771 +
772 +* **部署管理 **提供将修复程序部署到用户或生产环境所需的技能，工具和其他资源。
773 +* **事件管理 **提供了更新事件记录所需的技能，工具和其他资源，以及部署修复程序所需活动的详细信息。
774 +* **基础设施和平台管理 **根据事件的性质，提供配置和打包要部署的修复程序所需的技能，工具和其他资源。
775 +* **知识管理 **提供了使用有关修复程序的信息更新现有知识记录所需的技能，工具和其他资源。
776 +* **服务配置管理 **提供了在部署修复程序时更新服务配置记录所需的技能，工具和其他资源。
777 +* **服务台 **提供使支持代理能够使用共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
778 +* **服务财务管理 **根据部署的性质，可能需要向合作伙伴或供应商付款。
779 +* **软件开发和管理 **根据修复程序的性质，提供配置和打包用于部署的修复程序所需的技能，工具和其他资源。
780 +* **供应商管理 **根据事件的性质，提供与能够协助配置和打包待部署的修复程序的关键供应商进行交互所需的技能，工具和其他资源。
781 +
782 +
783 +步骤5：验证事件是否已解决
784 +
785 +(% style="text-align:center" %)
786 +[[image:1640086733771-156.png]]
787 +
788 +部署修复程序后，下一步是验证事件是否已解决。此步骤与价值流中先前的步骤1和2十分相似，因为它涉及支持专员与用户开展沟通和共情。
789 +
790 +如ITIL Foundation中所述，价值是对事物的利益，有用性或重要性的感知。在此模型中，用户和组织对价值的感知是不同的。例如：
791 +
792 +* 用户可能将一系列现象视为价值流失，包括恢复服务所花费的时间，相关的生产力损失，生产力损失造成的挫败感，等待服务恢复时可能出现的任何其他问题或复杂情况， IT支持期间的服务体验和服务的可靠性等。而有效地消除价值流失被认为是有价值的。
793 +* IT支持专员可能依据与用户及专家团队合作的经验，与各个小组进行交互所花费的时间以及更新相关记录等来计算价值。
794 +* 专家团队可能会依据与IT支持专员或用户合作的经验，创建和部署修复程序以及更新相关记录的复杂性来计算价值。
795 +
796 +而且，即使事件在技术层面上解决了，用户也可能需要其他帮助。例如：
797 +
798 +* 有人告知服务已恢复
799 +* 重新赋予服务的访问权和使用权
800 +* 解决由于该事件引起的任何未决或额外问题。
801 +
802 +因此，建议您与用户进行核对，以确保价值值已经令人满意地恢复了。这有助于增加IT支持与用户之间的共情，增进双方长期信任。
803 +
804 +当受影响的产品或服务以最佳水平运行时，可以认为该事件已解决。换句话说，价值流失已得到纠正。
805 +
806 +[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wps66BC.tmp.png]]为了区分事件的解决和结束，许多IT支持工具通过以下方式将状态分配给事件记录：
807 +
808 +* 解决事件意味着已解决了潜在的技术问题。
809 +* 结束事件意味着修复程序和相关的价值恢复已经得到用户确认。
810 +* 解决或关闭事件的过程是事件管理实践的基础设计的一部分，随后被价值流引用。在本节中，通常是指解决事件。
811 +
812 +通常有助于此步骤的做法包括：
813 +
814 +* **事件管理 **提供根据用户交互详情更新（解决或关闭）事件记录所需的技能，工具和其他资源。
815 +* **知识管理 **提供根据修复程序和价值恢复相关信息来更新现有知识记录所需的技能，工具和其他资源。
816 +* **服务配置管理 **提供解决事件后更新服务配置记录所需的技能，工具和其他资源。其概述可用于填写表4.2中提供的价值流步骤模板。
817 +* **服务台 **提供使支持专员能够产生共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
818 +* **服务级别管理 **提供信息以评估恢复/已达到的服务水平，以及恢复的及时性。
819 +
820 +
821 +步骤6：征集用户反馈
822 +
823 +(% style="text-align:center" %)
824 +[[image:1640086752260-712.png]]
825 +
826 +解决事件后，许多组织征求用户反馈，以便确定服务、与用户通信的方式、解决事件的过程或关键做法等的改进机会。通常，将其与价值流中涉及的其他角色（例如，IT支持专员和技术专家）的反馈相补充会很有用。
827 +
828 +无论是提供反馈还是收集反馈，重要的是要通过探索如何做得更好来保持积极的态度，而不是专注于出了问题的地方。在讨论事件的历史及其影响时，通常很难区分情绪和自我。可能还需要识别并过滤掉可能会影响反馈的环境，个人或专业因素，例如：
829 +
830 +* 担心生病的孩子的父母在分享反馈意见时可能会过分消极。
831 +* 担心即将裁员的IT支持专员可能不会专注于日常工作。
832 +* 刚刚大赚一笔的业务开发经理可能更友善，并且对IT支持问题较为宽容。
833 +
834 +用户与IT支持人员之间越来越多的共情和信任可以帮助改进进行沟通并减少偏差的影响。反馈可以通过多种方式收集，但最终应存储在集中的位置，以帮助分析和管理报告。
835 +
836 +通常有助于此步骤的做法包括：
837 +
838 +* **持续改进 **提供收集用户反馈所需的技能，工具和其他资源。
839 +* **基础设施和平台管理** 根据事件的性质和解决事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。
840 +* **服务台 **提供使支持专员能够产生共情并管理与各利益干系人的沟通渠道所需的技能，工具和其他资源。
841 +* **软件开发和管理** 根据事件的性质和解决该事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。
842 +* **供应商管理** 根据事件的性质和解决事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。
843 +
844 +
845 +步骤7:识别整体系统改进机会
846 +
847 +(% style="text-align:center" %)
848 +[[image:1640086851980-614.png]]
849 +
850 +收集到所有相关利益干系人的反馈后，可以将其单独或与其他信息进行分析，例如有关服务，服务提供者，服务消费者组织，外部约束等的历史数据。可以依此识别整体系统的改进机会。例如：
851 +
852 +* 服务提供者组织，或更一般而言，是SVS及其组件
853 +* 价值流以及相关的步骤，动作和任务
854 +* 与用户，合作伙伴，供应商和其他利益干系人的关系
855 +* 定义与感知价值的方式。
856 +
857 +识别的任何改进都应记录在服务提供商的持续改进登记册中，从而为服务提供商组织和提供者的SVS都能创造价值。写入登记册后，改进机会将优先于SVS中的其他工作。
858 +
859 +通常有助于此步骤的做法包括：
860 +
861 +* **持续改进 **提供识别改进SVS及其组件的机会所需的技能，工具和其他资源；识别改进收集和分析反馈方式的机会；识别改进服务的方式，并将其记录在持续改进登记册中。
862 +* **部署管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
863 +* **事件管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
864 +* **基础设施和平台管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
865 +* **知识管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
866 +* **监控和事态管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
867 +* **问题管理 **提供技能，工具和其他资源，以调查并减轻事件的可能原因。
868 +* **风险管理 **提供技能，工具和其他资源，以管理由于事件或修复而引发的新风险或现有风险的变化。
869 +* **服务配置管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
870 +* **服务台 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
871 +* **服务财务管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
872 +* **服务验证和测试 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
873 +* **服务级别管理 **提供登记并评估服务改进提案所需的信息，工具和技能。
874 +* **软件开发和管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
875 +* **供应商管理 **提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
876 +
877 +
878 +**[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wps820C.tmp.jpg]]ITIL 故事: 用于创建、交付和支持的模型价值流**
879 +
880 +[[image:1640086890026-742.png||height="53" width="41"]]**雷尼:**//有多种识别，创建和记录价值流的技术。//
881 +
882 +[[image:1640086905382-916.png||height="51" width="37"]]**索尔马兹: **//最初，我们使用物理看板板通过便签纸记录了我们的价值流。随着试点工作的进展和增长，我们创建了一个电子看板，以便我们可以在两个项目地点之间共享它，并调整我们的价值流。//
883 +
884 +[[image:1640086890026-742.png||height="53" width="41"]]**雷尼: **//由于这是一项新提案，因此我们的价值流包含许多未知数。我们决定采用最小可行产品方法，使我们能够增量地开展服务适配，在自行车租赁过程的每个阶段测试客户的需求，了解如何根据指标衡量绩效并评估结果。//
885 +
886 +[[image:1640086939974-916.png||height="51" width="36"]]**弗朗西斯:**//在说明价值流时，我们结合了来自试点客户的反馈，并利用了艾克苏服务组合中的现有价值流。在创建用于实现新功能的价值流时，我们使用了ITIL模板。我们将不断调整我们的价值流，使它们与客户不断变化的需求保持一致。//
887 +
888 +[[image:1640086890026-742.png||height="53" width="41"]]**雷尼:**//在可视化价值流之后，我们能够识别我们需要投入新服务的额外资源。例如，我们发现迫切需要能够快速轻松地取回废弃或损坏的自行车，以帮助服务顺利运行。//
889 +
890 +
891 +== 4.3 使用价值流来定义最小可行实践 ==
892 +
893 +前文描述的价值流设计和文档编制技术有助于服务提供商了解工作性质和从需求到价值的流动，以及组织资源和实践为实现这种流动所做的贡献。
894 +
895 +同样的技术也可以用于定义从对组织或利益干系人并允许学习和持续改进的实践中所需的最小贡献集。
896 +
897 +例如，如果假定第4.2节中讨论的两个价值流模型是服务提供者组织中的唯一价值流，则可以使用表4.4的模板合并实践贡献。
898 +
899 +
900 +表格 4.4 最小可行实践贡献
901 +
902 +|**实践名称**|
903 +|贡献|目的（价值流步骤）
904 +
905 +因此，例如，服务配置管理可以根据需要合并贡献，如表4.5所示。
906 +
907 +
908 +表格 4.5 服务配置管理的最小可行实践贡献示例
909 +
910 +|**服务配置管理实践**|
911 +|贡献|目的（进入价值流1或2）*
912 +|提供有关当前操作服务和配置项的信息，以及在构建服务组件时更新服务配置记录的技能、工具和其他资源|构建，配置或购买服务组件（价值流1中的步骤4）
913 +|提供有关当前运行的服务和相关配置项的信息|决定是否投资新服务（价值流1中的步骤2）
914 +|提供有关当前运行的服务和配置项的信息，以及在构建服务组件时更新服务配置记录的技能，工具和其他资源|部署服务组件以准备启动（价值流1中的步骤5）
915 +|提供技能，工具和其他资源，以在部署修复程序时更新服务配置记录|部署修复程序（值流2中的步骤4）
916 +|提供有关当前运行的服务和相关配置项的信息|设计和架构师提供新服务以满足客户需求（价值流1中的步骤3）
917 +|提供识别改进实践机会并将其记录在持续改进登记册中所需的技能，工具和其他资源|识别整体系统改进机会（价值流2中的步骤7）
918 +|通过提供有关配置项的信息来协助调查和诊断事件|调查查询，将其重新分类为事件，然后尝试将其修复（值流2中的步骤2）
919 +|提供有关当前运行的服务和相关配置项的信息|了解并记录服务要求
920 +|提供有关当前实时服务和服务组件的信息，以在描述需求时提供背景|确认并记录服务需求（价值流1中的步骤1）
921 +|提供解决事件后更新服务配置记录的技能，工具和其他资源|验证事件是否已解决（值流2中的步骤5）
922 +
923 +~* 价值流1（开发新服务）在第4.2.1节中；价值流2（恢复现有服务）在第4.2.2节中
924 +
925 +
926 +因此，如果在特定功能或技能集的缺失方面面临挑战，那么符合逻辑的响应是调查哪个价值流步骤需要哪些贡献，可能走向如下两种后续之一：
927 +
928 +* 放弃构建功能或技能集的要求
929 +* 记录新的价值流，或修改现有的价值流，以确认对新功能的需求。
930 +
931 +在上面的示例中，如果高级经理质疑服务配置管理实践所有者为何不支持对IT领域进行定期审核以识别未记录的配置项，则可能导致以下结果之一：
932 +
933 +* 相互同意不需要该功能。
934 +* 标识新的或迄今未记录的价值流，其中定期审核配置项。
935 +
936 +采用最小可行实践方法将帮助组织避免对组织不需要的技能，工具，流程和其他资源进行投资。有助于：
937 +
938 +* 降低业务的总拥有成本（TCO）
939 +* 增加服务配置管理的投资回报。
940 +
941 +
942 +|(((
943 +**ITIL 故事: 使用价值流来定义最小可行方法**
944 +
945 +[[image:1640087028260-207.png||height="52" width="42"]]**雷尼: **//定义34种ITIL做法所需的最小贡献集将很有用，它将对组织或利益干系人有利。例如，我们当前的支持服务旨在提供路边援助；但是，这并不延伸到我们的客户可能希望探索的山间小道。对于最初的城市自行车车队，我们可以采用当前的做法，但是如果我们将服务组合扩展到包括山地车租赁在内，那么我们还需要扩展支持能力。//
946 +)))
947 +
948 +
949 +
950 +== 4.4 总结 ==
951 +
952 +价值流是服务价值链中的一段旅程的阐述方式，表达了工作如何在组织中创建，增强或支持与服务消费者共同创造价值的产品和服务时如何在组织中流动。价值流和流程是服务管理的维度之一，描述了从需求共同创造价值所需的步骤，动作和任务。
953 +
954 +价值流与其上下文环境紧密关联，体现了组织的控制范围和影响，以及场景或需求类型。价值流的粒度代表沟通工作流的需要。价值流可以是线性流动的或迭代循环的。模式的选择体现工作应该如何流动的愿望，也可以体现工作如何在整个组织中流动。
955 +
956 +在某些情况下，价值流也可以跨多个组织级联。例如，跨组织价值流中的一个步骤可能是其中一个参与组织的整个价值流。
957 +
958 +在价值流、步骤、行动或任务中，组织可以识别组织的实践需要提供的贡献（人员、工具、信息、过程等）。这些信息可用于优化服务价值体系及其组件。
959 +
960 +
深圳市艾拓先锋企业管理咨询有限公司