Changes for page 通用管理实践 - 28 持续改进

Last modified by superadmin on 2024/12/25, 15:36

From version < 13.1 >

edited by superadmin
on 2021/02/19, 18:11

To version < 9.1 >

edited by superadmin
on 2021/02/19, 18:03

< >

Change comment: 上传新附件1613729010836-627.png

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -1,4
          +1,16 @@
++(% class="jumbotron" %)
++(((
++(% class="container" %)
++(((
++=   =
++
++
++
++
++
++)))
++)))
  需要下载 **ITIL 4 持续改进实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“持续改进”即可。
@@ -36,7
          +36,6 @@
  * 对本实践的合作伙伴和供应商的考虑
--
  == **1.1 ITIL 4资格认证计划** ==
  本文档中的部分内容可作为以下教学大纲的一部分以供检查：
@@ -87,7
          +87,7 @@
  所有改进计划都需要从组织愿景中展开。如果任何改进对实现愿景没有贡献，哪怕是很小的贡献都没有，那么这种改变可能就是不必要的或无效的。
--* **定义：日程业务BAU**
++* **定义：日程业务[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml2876\wps23.png]] BAU**
  通常可重复执行的常规任务，可以由具有适当技术或技能的人员执行，而不必作为项目进行管理。
@@ -108,6
          +108,7 @@
  * 产品和服务所有者
  * 服务交付的供应商和合作伙伴
++
  * **定义：反馈回路**
  一个活动的输出被用作新输入的一部分。在运作良好的组织中，反馈将沿着价值链积极收集和处理。
@@ -161,664
          +161,4 @@
  表2.1 其他实践指南中描述的与持续改进实践相关的活动
--== **2.4 实践成功因素** ==
--
--
--* **定义：实践成功因素**
--
--是实践实现其目标的必备的复杂功能的组成部分。
--
--实践成功因素（PSF）不仅仅是一个任务或一个活动，它包括服务管理四个维度的全部组成部分。不同的实践，PSF的活动和资源属性可能不同，但是它们一起确保实践是有效的。
--
--持续改进实践包括以下PSF：
--
--* 建立并维护有效的持续改进方法
--* 确保整个组织的改进高效和有效的进行
--
--=== **2.4.1 建立并维护有效的持续改进方法** ===
--
--
--**2.4.1.1 持续改进模型**
--
--ITIL 持续改进模型提供了支持改进计划的高级指导。使用此模型会增加改进倡议成功的可能性。模型专注于客户价值，并将改进工作与组织愿景链接在一起。
--
--该模型促进了改进的迭代方法。工作被分为可管理的几部分，分别定义了可以逐步实现的目标。使用模型时，重要的是要使用逻辑和常识。这些步骤不必以线性方式执行，并且可能有必要在各个点重新评估并返回到先前的步骤。
--
--图片2.1显示了ITIL 持续改进模型。
--
--(% style="text-align:center" %)
--[[image:1613728811426-586.png]]
--
--
--图2.1 ITIL持续改进模型
--
--
--**2.4.1.2 复杂环境中的持续改进**
--
--复杂环境中的大规模改进通常会带来重大改变。使用项目管理实践而不是BAU（日常业务）来定义一个改进计划应该被交付的范围是很重要的。
--
--尽管ITIL 持续改进模型倡导的方法是通用的，并且适用于任何的改进对象，但对于组织而言，使方法及其措施适应其特定的环境仍很重要。例如，在非常明显的挑战性的项目中考虑典型时间框架非常重要。
--
--在复杂环境中运行的组织（例如，商业IT服务提供商）可能需要追求长期和短期改进目标。这样的服务提供者应该建立一个灵活的持续改进框架，允许管理人员根据环境的变化在战术之间进行切换。在许多可度量的改进战术中，复杂的组织可能同时采用两种战术：
--
--* 丰田·卡塔（Toyota Kata）是迈克·罗瑟（Mike Rother）所写的书，它讨论并推广了用于迭代改进的科学思维和行为技术的原理。Rother推出了改进型Kata和教练型Kata：这些例程旨在培养和习惯读者的有益思维方式，以促进其在控制范围内的改进。Rother的改进型Kata例程可帮助从业人员避免基于偏见和过去的经验进行假设。取而代之的是，从业人员审慎而刻意地思考挑战和机遇，从而采取迭代，度量和有效的行动。
--
--* OODA（观察，判断，决策，行动）循环是一种可操作的决策技术框架，源于军事作战方法。OODA循环旨在非常短期内，并且可以连续运行，直到一个紧急危险被消除为止。
--这种方法展示了敏捷可以战胜力量。第二个O“判断”是该技术的核心。它提出了一个相互关联的知识领域（传统，遗产，过往经验，新信息，分析和综合）的系统，变革推动者可以迅速利用这些知识领域来得出结论。这些结论反过来又有助于决策。
--
--组织的设计可以使复杂环境中的变更推动者具有自治性，并可以合理地选择采取哪种路径进行其特定的持续改进旅程。考虑无法改进的危险，是内在的还是需要长期的管理努力，这一点至关重要。
--
--
--**2.4.1.3 嵌入组织**
--
--持续改进的文化：
--
--● 鼓励干系人提出建议并支持改进
--
--● 鼓励干系人表达他们的需求，需要和关注点并承担风险
--
--● 认识到完美主义通常是自欺欺人的，并阻碍了及时的改进
--
--● 认为持续改进是日常工作的一个活动
--
--● 庆祝成功的改进
--
--● 鼓励快速反馈循环
--
--● 促进从失败中学习，而不是责备的文化。
--
--为了在组织中嵌入这些价值并使持续改进实践成功，至关重要的是：高层管理者需要致力于发展一个持续改进的文化。
--
--
--**2.4.1.4 促进持续学习**
--
--应该始终使用ITIL 持续改进模型的第6步（是否已经达成？）来获取从改进项目中学到的经验教训。
--
--成功的改进项目应该回顾已经取得的积极成果，包括计划和未预料到的结果。如果改进的预期结果没有实现，或者以一种不同于计划的方式实现了，那么应该审查计划，并告知干系人失败的原因。这就需要对改进计划进行彻底的分析，记录并交流所汲取的经验教训。该文档应说明根据经验收集到的在下一次迭代中哪些可以以不同的方式完成的描述。
--
--在可能的情况下，应在整个计划实施过程中保留经验教训日志。然后应审查此日志，生成经验教训报告。经验教训报告应用于以后的类似改进项目。无论当前迭代的结果如何，透明度对于将来的工作都很重要。
--
--如果跳过步骤6，则改进可能会保持孤立状态，随着时间的流逝，独立的计划和进度可能会丢失。要获得对将来的改进计划的支持并在组织的文化中嵌入持续改进可能也很困难。重要的是要记住，应该创建并维护一个无指责的环境，在这个环境中，失败是安全的，并且主要关注点不是在指责人，而是在吸取教训。
--
--
--=== **2.4.2 确保整个组织的改进高效和有效的进行** ===
--
--
--**2.4.2.1 抓住机会**
--
--持续改进实践支持所有其他实践，产品和服务的改进。它是SVS的核心组件，并且必须嵌入所有其他服务管理实践中。识别出的机会数量可以用作度量指标来评估持续改进实践在组织中的建立情况。
--
--
--**2.4.2.2 优先次序**
--
--优先级准则必须透明并且公正地应用于所有改进计划。当优先级被质疑或无法明确评估时，应将该改进计划升级给治理委员会以进行进一步讨论。
--
--尽管所有商定的成果都将有助于达到期望的状态，但某些成果将比其他成果更为关键。为了达到这些结果，必须按一定顺序实施改进。有些成果将需要大量的投资，而另一些成果可能需要最少的成本和工作量即可实现。可以优先考虑低成本，低工作量的改进计划，以实现组织的价值的快速增加。
--
--
--**2.4.2.3 所有权**
--
--特定服务，产品或实践价值流的所有者负责管理相关的连续改进计划。这些人应以身作则，展示和重申改进活动的价值。
--
--持续改进实践所有者负责管理持续改进实践。此人确保组织的其他成员具备识别，评估，资助，执行和评估持续改进活动的成果所需的知识、技能和工具。
--
--
--**2.4.2.4 资源**
--
--相互协作，带来成就的方式需要信息、理解和信任。工作成果应有目共睹。应该避免隐藏的议程。信息应尽可能共享。当人们意识到正在发生的事情以及原因时，他们将更愿意提供帮助。
--
--当改进活动发生在只有一小部分人了解细节的情况下时，各种假设和谣言就会占据上风。当员工们开始猜测发生了什么变化以及它们可能如何变化时，对变化的抵制可能会增加。
--
--通过短暂的迭代来快速，明显地交付价值，可以增强用户从已完成的工作中获得的价值，这反过来又对交付它的团队产生了激励和奖励。
--
--
--**2.4.2.5 资助改进计划**
--
--任一个业务案例应该阐明采取服务或流程改进计划的原因。应尽可能提供数据以及与开展改进计划的成本和预期收益相关的证据，注意是：
--
--● SVS重新设计的活动通常更复杂，因此比最初预期的成本更高。
--
--● 组织变更影响通常被低估了。
--
--● 改变的实践通常需要改变能力和工具，从而进一步增加成本。
--
--在开发某一业务案例时，重点不应局限于投资的潜在回报率，还应关注于改进计划将带给组织及其客户（价值投资）的业务价值。这是因为仅衡量投资回报率无法体现服务改进的真实价值。如果一个组织选择只关注于投资的潜在回报率，则许多潜在的好处将不会被披露或审查。这可能会导致有价值的计划被拒绝，或者错误地认为某些计划失败了。
--
--毫无疑问，大多数业务高管都希望获得投资回报。重要的是要认识到，对改进的投资及其收益可能会根据组织的客户基础，规模和成熟度而有所不同。收益将跨越现有的组织边界，只有用户/客户和服务提供者经理才能在协作中获得真正的收益。因此，重点应该是与干系人合作，开发特定于业务和服务-提供者的指标，这些指标将业务价值指标与服务提供者的贡献联系起来。换句话说，改进是如何为组织增加价值的？
--
--业务价值度量的示例是：
--
--● 上市时间
--
--● 客户保留
--
--● 市场份额。
--
--服务提供者的贡献可以通过以下方式获取：
--
--● 获得敏捷性
--
--● 管理知识
--
--● 增强知识
--
--● 降低成本
--
--● 减少风险。
--
--服务提供者应该首先定义每个改进将贡献的业务价值的类型。
--
--如果一项投资经过精心构思，可靠交付了成果，则可以随着时间的流逝节省成本。因此，选择正确的投资并确保其交付很重要。为某改进计划引入一项业务案例时，重要的是要帮助主管人员了解该计划的业务价值。当业务的变化带来最大收益时，大多数管理人员过分强调价值的技术和工具。重要的是要解决人和实践将如何从“现状”状态变为“将来”状态。
--
--在业务案例开发中，考虑由于不进行改进活动而丢失价值的情况也很重要。在某些情况下，不采取行动将严重影响服务消费者和服务提供者；改进的价值可能是保留的价值，而不是增加价值。
--
--可以帮助证明投资回报率的一种优秀实践是为一个试点项目申请资金，这是一个范围有限的短期项目，但它代表了一个大规模的计划，短期项目的结果将有助于证明大规模的计划是可行的。
--
--开发业务案例时，重要的是要确保明确定义了成功的标准及其度量（包括时间表）。
--
--
--**2.4.2.6 评价**
--
--当一个改进机会被确认时，应评估当前状态，以便可以在“我们从哪里开始”的背景中度量和理解所做出的任何改进。
--
--定量指标可用于度量服务和方法的实际效能。定性指标可用于衡量策略，项目组合以及与其他方面的关系。
--
--
--== **2.5 关键指标** ==
--
--应该在每个实践所贡献的价值流的背景内评估ITIL实践的效果和绩效。与任何其他绩效工具一样，实践的绩效只能在该项目的背景内评估。但是，工具在设计和质量上可能会有很大差异，这些差异定义了根据其用途使用工具的潜力或能力。度量和报告实践中可以找到关于度量、关键指标（KPI）和其他技术的进一步指导。
--
--理想情况下，持续改进是根据改进活动对SVS产生的价值的影响来度量的。这可能很难量化，因为：
--
--● SVS中的价值是系统内部复杂交互的结果。
--
--● 许多改进可能同时发生。可能无法区分一个改进的影响与另一个改进的影响。
--
--● 改进的实施与价值的实现之间通常会存在很大的延迟。
--
--如果持续改进实践采用敏捷方法，则度量价值会更容易，因为在这种情况下，干系人会在每个迭代边界处确认价值的创建。当将产品所有权分配给客户或服务提供者组织中最接近客户的人员时，这种影响更加明显。
--
--有效的度量标准将识别组织的哪些领域正在交付持续改进项目。将持续改进实践本身包括在“持续改进项目管理”度量标准中非常重要。
--
--其他度量标准与持续改进的组织成就有关，旨在识别尚未交付的改进或试图交付太大改进的服务，产品或实践。这些指标有助于确定哪些团队或干系人需要持续改进经理的额外关注。
--
--持续改进实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。
--
--表2.2 实践成功因素的关键指标实例
--
--
--
--
------
--
--= **3  价值流和流程** =
--
--
--== **3.1  价值流贡献** ==
--
--持续改进实践的独特之处在于，它为其他所有实践和价值流的每个组件的价值都有贡献。重要的是要记住，价值流永远不会由单个实践形成。持续改进实践与其他实践相结合，可以为服务消费者提供高质量服务。持续改进实践不应孤立看待：它是所有其他实践的关键组成部分。
--
--图3.1中显示了持续改进实践对服务价值链的贡献
--
--(% style="text-align:center" %)
--[[image:1613728933318-559.png]]
--
--图3.1持续改进实践对价值链活动贡献的热力图
--
--
--== **3.2 流程** ==
--
--每个实践可能包括实现其目的所必需的一个或多个流程和活动。
--
--* **定义：流程**
--
--将一组相互关联或相互作用的输入转换为输出的活动。流程接受一个或多个定义的输入，并将它们转换为输出。流程定义这些活动的顺序及其依赖关系。
--
--持续改进实践活动形成了一个流程：
--
--* 持续改进项目的管理
--
--持续改进实践还包括一组将实践嵌入到组织的活动。
--
--
--=== **3.2.1 持续改进项目的管理** ===
--
--此流程包括表3.1中列出的活动，并将输入转换为输出。
--
--
--表3.1持续改进项目管理的输入、活动和组织规划流程的输出
--
--|关键输入|活动|关键输出
--|(((
--组织的愿景、使命和目标
--
--事后评审结果
--
--问题结果
--
--基准指标
--
--实践目标和成就指标
--
--客户满意度指标
--
--SLM实践评审
--
--用户或客户反馈
--
--评估报告
--
--审计报告
--
--改进记录
--
--改进登记表（CIR）
--)))|(((
--识别和记录改进机会
--
--评估、确定优先级和审批改进项目
--
--规划改进项目
--
--改进项目实施
--
--度量和评估改进成果
--)))|(((
--改进记录
--
--更新改进登记表
--
--起草业务论证
--
--审批的业务论证
--
--改进计划
--
--绩效评估
--
--项目变更记录
--
--度量更新
--
--经验教训
--)))
--
--图3.2显示了该流程的工作流程图
--
--(% style="text-align:center" %)
--[[image:1613729010836-627.png]]
--
--
--图3.2持续改进项目管理流程的工作流程图
--
--
--表3.2提供了流程活动的示例
--
--|(% style="width:280px" %)活动|(% style="width:813px" %)描述
--|(% style="width:280px" %)识别和记录改进机会|(% style="width:813px" %)获取改进的点子是每个人的责任，并且是发展持续改进文化的关键部分。最初的点子不需要详述。这是了解当前状态和期望的将来状态的对话的起点。此活动的关键步骤是将改进想法记录在CIR中，并为其分配了唯一的引用编号。
--|(% style="width:280px" %)评估，确定优先级和批准改进机会|(% style="width:813px" %)(((
--改进成果可以在许多领域对价值产生积极影响。通常，它们将节省时间或节省成本，增强用户体验，减少风险，改进文化或达到合规性的要求。
--
--在敏捷方法论中，评审和完成提出的想法称为管理待办项(backlog)。CIR也可以作为待办项进行管理。
--
--在确定CIR项目的优先级后（应定期进行），必须确保为最重要的改进项目提供资金和资源。应该使用某一业务论证来证明该改进计划进行投资的理由。
--
--当需要资源开始使用改进活动时，与预算负责人进行适当的沟通非常重要，例如，通过参考投资回报率，明确定义的业务成果以及组织的愿景。
--
--业务案例中所需的细节取决于改进项目的规模，而不是所使用的项目方法。大型项目需要采用正式的项目管理或变更支持方法和技术才能实现。
--
--精益画布是一种可用于创建商业论证的方法，以确保为小型项目获得资金。精益画布建议提供一个单页的业务模型，该模型将一个构想分解为一组基本元素，并简明的呈现出来。这些元素是：
--
--● 关于改进的问题陈述
--
--● 建议的改进举措（可能带有选项）
--
--● 改进对象的关键指标
--
--● 价值主张
--
--● 建议选项的不公平优势
--
--● 客户细分
--
--● 价值的交付渠道
--
--● 成本结构
--
--● 增加的收益或收入预测。
--
--也有其他替代模型，但一般的想法是在资源投入之前主动进行尽职调查以及获得认可。
--)))
--|(% style="width:280px" %)规划改进项目|(% style="width:813px" %)规划批准的改进项目的，与项目、变更或其他类似规模的工作的规划相同。业务论证应根据优先级包含基本资源和时间表规划。为改进计划制定一个优先级尺度非常有用，它将团队和资源与其他类型的工作的优先级保持一致。
--|(% style="width:280px" %)推进改进项目的实施|(% style="width:813px" %)无论是使用瀑布模型还是敏捷模型来实施一项计划，都必须将较大的项目计划划分为较小的任务。然后根据计划和所使用的方法来实施改进。
--|(% style="width:280px" %)度量和评估改进成果|(% style="width:813px" %)(((
--改进或一组改进项目完成并准备好交付后，应向干系人展示，以证明和验证价值共创。
--
--必须在每次迭代中确认价值共创，以通过将结果与商定的成功因素和KPI进行比较来度量从原始状态到商定的期望状态的进度。如果未完全实现预期结果，则应在后续的迭代中确定差距以及有限处理。每个改进计划都应记录所吸取的经验教训。
--)))
--
--表3.2持续改进项目管理流程的活动
--
--
--//注：反馈是持续改进实践的基本要素。建立正式和非正式的多个反馈渠道非常重要。并非所有反馈都会触发对改进计划的更改，但是必须尊重和评审所有反馈。由于反馈而做出的决策应转发给反馈发起者。如果反馈被忽略或未被确认，将来将更难获得反馈。应当将提供更多改进机会的反馈添加到CIR并确定优先级。//
--
--
--=== **3.2.2 将持续改进实践嵌入组织** ===
--
--这套活动的关键成果是确保持续改进实践是一种组织规范。这涉及采用各种敏捷行为，概念和技术。
--
--
--该流程包括表3.3中列出的活动，并将输入转换为输出
--
--(% style="width:928px" %)
--|(% style="width:514px" %)关键输入|(% style="width:206px" %)活动|(% style="width:204px" %)关键输出
--|(% style="width:514px" %)(((
--OCM实践
--
--框架、方法、标准、哲学和知识体系，例如ITIL、精益、敏捷、DevOps、CMMI、六西格玛和COBIT
--)))|(% style="width:206px" %)(((
--融入组织文化
--
--确定相关和有价值的原则
--
--知识共享和能力提升
--)))|(% style="width:204px" %)(((
--文化变更
--
--采取最能满足组织的最佳实践
--
--)))
--
--表3.3持续改进实践嵌入组织的输入、活动和输出
--
--
--表3.4提供了活动的示例
--
--|(% style="width:196px" %)活动|(% style="width:897px" %)描述
--|(% style="width:196px" %)融入组织文化|(% style="width:897px" %)(((
--当需要行为变革时，高级管理人员很重要。高级管理人员必须是表率和榜样；如果他们不采用这种做法，其他人也不会采用。
--
--高级管理人员应确保对员工因遵守规定而给予奖励。对于持续改进，这意味着正在持续的监控，分析，审查，报告，标识和实施计划。
--
--有必要确保更新工作说明，员工的目的和目标考虑服务管理的职责，并且总体期望包括持续改进活动。
--)))
--|(% style="width:196px" %)确定相关和有价值的原则|(% style="width:897px" %)(((
--成功的持续改进实践依赖于几个关键原则：
--
--* 专注于进行渐进式改进，大的改进具有较高的风险，并且需要更长的时间才能展现结果。
--* 从错误中吸取教训，一些项目不会达到计划的结果。
--* 在整个组织中鼓励提出想法，在大型组织中，许多成功的计划都来源于一些运营级别的员工。
--* 度量，没有度量就不可能知道改进的努力取得了成功。
--)))
--|(% style="width:196px" %)知识共享和能力提升|(% style="width:897px" %)(((
--知识共享是持续改进实践成功的关键。在知识共享不是常态的文化中，成功的改进可能会受到限制，新的概念通常会局限在某些个人或团队，而不是在组织范围内共享。
--
--在一个将知识视为个人资产而不是组织能力的组织中，将非常难于从持续改进中获益。高级管理层必须促进知识共享。
--)))
--
--表3.4 将持续改进实践嵌入组织流程的活动
--
--
--改进的项目可能来自各种途径。SVS内的几乎任何人都可以识别SVS的任何组件潜在的改进点。服务提供者有时会制定标准，以限制可能提出改进建议的人，但最好是尽可能鼓励做出贡献。
--
--各种记录系统可能是改进建议的来源，通过自动的接口或者人工审查的方式提取数据。这些系统包括问题记录、风险登记、和流程绩效记录。
--
--在定义了产品负责人角色的组织中，改进建议应首先提交给相关产品的产品负责人。然后，产品负责人可以过滤和调整建议，并将他们添加到CIR中。
--
--
--
------
--
--= **4  组织和人员** =
--
--
--== **4.1 角色、能力和责任** ==
--
--实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
--
--流程和活动的背景中描述了角色。每个角色都具有基于表4.1所示的模型的能力类型。
--
--|能力编码|能力类型（活动和技能）
--|L|**领导Leader**决策、授权、监督其他活动，提供激励和动力，并评估结果
--|А|**管理员Administrator**分配任务并确定优先级，保存记录，持续报告，并启动基本改进
--|C|**协调者/沟通者Coordnator/Communicator**协调多方，维护利益相关者之间的沟通，并开展宣传活动
--|М|**方法和技术专家Methodsandtechniquesexpert**设计和实施工作技巧、文件化步骤、流程咨询、工作分析和持续改进
--|Т|**技术专家Technical expert** 提供技术（IT）专业知识并执行基于专业知识的任务
--
--表4.1能力类型及编码
--
--
--表4.2列出了持续改进实践活动中可能涉及的角色示例，以及相关的能力类型和特定技能。
--
--|(% style="width:129px" %)能力编码|(% style="width:965px" %)说明
--|(% style="width:129px" %)L|(% style="width:965px" %)**领导Leader** 这个角色侧重于领导力技能和权威，与此角色相关的活动包括决策、授权、监督其他活动、激励和鼓励、以及对成果的评估。
--|(% style="width:129px" %)A|(% style="width:965px" %)**管理员Administrator**这个角色侧重于行政管理技能，与此角色相关的活动包括任务分配和确定优先级，记录，持续的汇报和基本的改进计划。
--|(% style="width:129px" %)C|(% style="width:965px" %)**协调者/沟通者Coordnator/Communicator**这个角色侧重于沟通和协调的能力。与此角色相关的活动包括多方协调、干系人之间的沟通以及展开宣传活动。
--|(% style="width:129px" %)M|(% style="width:965px" %)**方法和技术专家Methodsandtechniquesexpert**这个角色侧重于咨询技能和工作技能的专业知识。与此角色相关的活动包括工作技术的设计和实施、程序文档化、过程咨询、工作分析和持续改进。
--|(% style="width:129px" %)T|(% style="width:965px" %)**技术专家Technical expert**这个角色侧重于提供技术（IT）专业知识和基于专业知识的任务。
--
--表4.2可能参与持续改进实践活动中的角色的例子，以及相关的能力类型和技能
--
--
--表4.3续改进实践活动的角色示例
--
--
--== **4.2  组织架构和团队** ==
--
--
--=== **4.2.1  持续改进团队** ===
--
--服务提供者不太可能维护专门的致力于持续改进实践的团队。团队应负责改进他们自己，如何与其他内部团队互动，以及如何与外部供应商、合作伙伴和客户互动。
--
--然而，服务提供者可以引入持续改进协调员或者变更记录（CIR）管理员角色。当实施持续改进框架时，服务提供者可能会将这个角色交给有领导技能的人。根据组织的规模和嵌入持续改进活动的策略，这可能是一个全职职位。随着整个组织团队的熟练程度的提高，服务提供者可能会淘汰角色或使其成为兼职人员。
--
--
--=== **4.2.2 持续改进团队的构建** ===
--
--团队的一些属性或方面有助于增强改进的能力，包括多元性和能够安全失败的环境。
--
--
--**4.2.2.1 多元性**
--
--关于多元性对团队绩效的影响研究尚无定论。一些研究表明，社会上同质的团队与社会多元文化的团队之间存在显着差异。其他研究未能重现这些结果。一些研究表明，当经验丰富的专家与经验较少的成员组成的团队，将会带来好处。但是，很难说服其他成员为团队配备缺乏经验的成员。缺乏关于多元性变化对团队的影响的信息。
--
--直接的经济利益只是影响团队人员配备的一个方面。其他因素包括：
--
--● 组织对社会的道德责任
--
--● 员工的专业性发展
--
--● 团队的长期稳定性和持久性
--
--● 避免群体思维和类似的组织偏见的价值。
--
--根据人员的类别和类型进行思考可能会阻碍建立一个有凝聚力和表现良好的团队。没有选择“正确”人员的公式。相反，团队经理应该专注于培养信任和尊重并认可独特的个人贡献的技术。
--
--
--**4.2.2.2可以安全的失败的环境**
--
--增量的，迭代的改进技术依赖于团队进行实验的意愿。它们使改进经常会在小范围内失败，从而限制了大规模失败的可能性，减少了失败的潜在影响，并提高了团队从失败中恢复的难度。
--
--团队应该将失败视为学习的机会：必须避免责备的文化。从小的失败中吸取教训，提高整体能力，比从不吸取教训要好。从成功的实验中获得好处，比从一开始就没有尝试过要好。
--
--因此，团队需要无责备的环境，在该环境中即使失败也是安全的。这些环境促进了通常所说的“心理安全”，并且依赖团队成员和管理者之间的尊重和信任。
--
--
--
------
--
--= **5  信息和技术** =
--
--
--== **5.1 信息交换** ==
--
--
--=== **5.1.1 信息对象和输入输出** ===
--
--有关改进的建议通常含糊且无法衡量。例如，经理可能说服务必须更快地交付。这样的表述既无激励，也不能付诸行动。改进建议的结构应符合以下要求：
--
--● 了解应该解决什么问题
--
--● 了解改进的潜在价值
--
--● 知道工作的一般范围
--
--● 认识其他干系人
--
--● 了解关键约束条件
--
--● 可以衡量改进是否成功
--
--
--=== **5.1.2 持续改进登记表** ===
--
--CIR是用于跟踪和管理持续改进的改进记录的完整列表。在敏捷方法中，CIR称为产品待办项。
--
--CIR可以是服务管理系统的一个集成部分，也可以是改进记录的独立数据库。
--
--
--=== **5.1.3 改进记录** ===
--
--每个改进记录中包含的细节程度取决于它捕获的需求规格说明的程度。
--
--
--表3.4中显示了改进点记录的数据字段的示例，并且实际上CIR的结构也是如此。
--
--|(% style="width:184px" %)字段|(% style="width:910px" %)描述
--|(% style="width:184px" %)改进标识符|(% style="width:910px" %)在整个服务提供者组织中有效的唯一标识符
--|(% style="width:184px" %)改进名称|(% style="width:910px" %)改进的简短描述性标题
--|(% style="width:184px" %)改进请求者或来源|(% style="width:910px" %)这可以是任何干系人，包括外部客户或供应商
--|(% style="width:184px" %)受影响的配置项|(% style="width:910px" %)服务、生产或实践有待改进
--|(% style="width:184px" %)改进负责人|(% style="width:910px" %)负责改进和计划实施的人员，改进计划的责任不应在团队之间共享
--|(% style="width:184px" %)紧急度|(% style="width:910px" %)说明改进的效果将在什么时间范围内产生开始被认识，可以用简单的高中低来表示紧急度
--|(% style="width:184px" %)状态|(% style="width:910px" %)标识改进计划的当前位置的术语
--|(% style="width:184px" %)成本|(% style="width:910px" %)可确定待办事项的优先级和比较计划的指示性值。尽管成本在登记和计划之后尚不明确，但应包含直接和间接的投入，时间和资源，可简单用高中低来表示。
--|(% style="width:184px" %)价值或利益声明|(% style="width:910px" %)从服务提供者和使用者的角度定义最终输出
--|(% style="width:184px" %)改进计划|(% style="width:910px" %)(((
--对解决问题的方法的高级描述
--
--采用敏捷工作方式的组织有时会为计划添加已定义作为验收标准
--
--计划可以包括实施中涉及的团队和实践。
--)))
--
--表3.4 改进记录的示例数据字段
--
--
--== **5.2 自动化与工具** ==
--
--尽管人工智能取得了巨大的进步，但持续改进本质上是人类的手动实践。今天的持续改进实践中几乎没有可以自动化的，但是有很多工具可以支持持续改进的各个阶段。这些总结在表5.1中。
--
--|活动|自动化手段|关键功能|对实践效果的影响
--|识别和记录改进|CIR|自助记录|中
--|改进评估、确定优先级、审批|(((
--度量和报表工具
--
--统计分析工具
--)))|提供基线建立当前状态|中
--|规划改进、实施改进|电子看板|(((
--所有任务的状态可见性
--
--防止不必要的中断
--)))|高
--| |自动化测试|有自动化的潜力，尤其是分阶段部署；自动化测试工具；自动化的开发和部署管道|高
--|度量和评估改进结果|(((
--度量和报表工具
--
--统计分析工具
--)))|提供基线建立当前状态|中
--
--表5.1持续改进活动自动化解决方案
--
--
--
------
--
--= **6 合作伙伴和供应商** =
--
--仅使用组织自己的资源提供的服务很少。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL®Foundation的2.4节：服务关系的ITIL 4版中的模型）。服务设计，架构管理和供应商管理的ITIL实践中介绍了由支持服务引入的关系和依赖性。
--
--合作伙伴和供应商必须包含在持续改进计划中。应鼓励合作伙伴向CIR提交建议。同样，服务消费者组织应该能够提出对服务提供商的改进建议。开放的沟通和学习意愿有助于构建共同价值共创的关系。
--
--在敏捷环境中，客户和供应商需要合作以实现最佳结果。组织的目标是快速，有效的持续改进。他们通常会试图与合作伙伴和供应商达成紧密的合作协议，消除沟通，协作和决策制定方面的正式官僚障碍（有关更多信息，请参见供应商管理实践指南）。
--
--
--== **6.1 供应链中的持续改进** ==
--
--所有改进陈述都包含要解决的问题的描述。但是，某些问题没有明显的解决方案。
--
--例如，如果供应商提供低质量货品或服务，则客户有以下几种选择：
--
--● 接受货品或服务，并在该级别的质量上与他们合作
--
--● 变更供应商
--
--● 构建服务提供者的价值流，以检测和纠正或消除缺陷
--
--● 与货品的供应商合作，改进货品的质量或提供的服务进行协作，以及消费者如何使用它们。
--
--接受较差的质量产品或服务会放弃持续改进的原则。更换供应商可能会提高质量，但这并不总是一种选择。货品的地理位置，价格或可用性和服务等许多因素会限制供应商的选择。在现有价值流中添加处理质量问题的步骤可能会导致价值服务更高，但是代价是敏捷性较低，交货时间更长且成本更高。
--
--供应商和消费者可以通过以下方式合作改进供应链：
--
--● 识别不必要的且可以删除的消费者要求
--
--● 调整产品规格
--
--● 分离服务提供者的价值流，然后将某些活动重新分配给供应商（或消费者）
--
--● 调整交货节奏和批次大小
--
--
--== **6.2 持续改进中合作伙伴和供应商的作用** ==
--
--除了识别和实施改进项目，供应商和合作伙伴还可以提供支持持续改进实践的专业服务。表6.1给出了这些服务的示例。
--
--|ITIL 持续改进模型步骤|服务
--|1.我们现在处于什么位置|独立评估当前状态
--|2.我们要达到什么状态|分析潜在的改进并提供有关最佳实践的建议
--|3.我们如何达成|辅导和规划服务
--|4.采取行动|承包专业技能
--|5.是否达成|独立评估新状态
--|6.保持发展势头|参与双方的定期讨论和规划的改进
--
--表6.1 持续改进中供应商和合作伙伴的作用
--
--
--
------
--
--= **7  重要提醒** =
--
--实践指南的大部分内容应视为组织在建立和培养自己的实践时可能考虑领域的建议。实践指南是组织可能考虑的事情目录，而不是答案列表。使用ITIL实践指南的内容时，组织应始终遵循ITIL指导原则：
--
--* 聚焦价值
--* 从你所处的地方开始
--* 基于反馈迭代推进
--* 协作和提升可视化程度
--* 通盘思考和工作
--* 保持简单实用
--* 优化和自动化
--
--关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
--
--
--
------
--
--= **8  致谢** =
--
--AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
--
--
--== **8.1  作者** ==
--
--RomanJouravlev, Laura Little, Kirstie Magowan, Konstantin Naryzhny,.
--
--
--== **8.2  审稿人** ==
--
--Xavier Idrovo, Vernon Lloyd.
--
--

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司