Changes for page 第7章开发服务价值系统

Last modified by superadmin on 2024/04/03, 18:59

From version < 20.1 >

edited by superadmin
on 2022/01/07, 14:21

To version < 23.1

edited by superadmin
on 2024/04/03, 18:59

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)
Attachments (0 modified, 1 added, 0 removed)
- 1641536617924-170.png

Details

Page properties

Content

@@ -3,17
          +3,22 @@
  [[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC8%E7%AB%A0%20%E6%8A%8A%E5%AE%83%E4%BB%AC%E9%9B%86%E6%88%90%E8%B5%B7%E6%9D%A5/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC6%E7%AB%A0%20%E6%B2%9F%E9%80%9A%E5%92%8C%E7%BB%84%E7%BB%87%E5%8F%98%E9%9D%A9%E7%AE%A1%E7%90%86/]]
--{{box cssClass="floatinginfobox" title="**Contents**"}}
++{{box cssClass="floatinginfobox" title="
++
++**Contents**"}}
  {{toc/}}
  {{/box}}
  = 第7章 开发服务价值系统 =
++
  本章将讨论开发SVS，并强调从面向服务的环境到面向技术的环境的四维模型差异之处。
++
  == 7.1 采用指导原则 ==
++
  尽管用于指导、计划和改进的基本概念和方法在任何组织中都是相同的，但是它们的关注点和驱动因素取决于组织采用的价值和原则。成功的服务提供商确保聚焦价值遍及每个级别的所有三个活动。
  指导、计划和改进应该：
@@ -39,11
          +39,18 @@
  [[image:1639217790652-566.png]]
++(% class="wikigeneratedid" %)
++==   ==
++
++(% class="wikigeneratedid" %)
++==   ==
++
  == 7.2 服务管理卓越中心 ==
  === 7.2.1 服务管理战略的战术落地 ===
++
  服务管理是一组专门的组织功能，用于以服务形式为客户创造价值。因此，面向服务的组织需要定义战略以发展其专业组织能力，然后以适当的战术进行部署。
  根据驱动组织的愿景和使命的因素，可以通过许多方式完成指导、计划和改进服务管理。战略管理实践通过分析环境、确定约束条件、同意并建立共享的观点以及将战略转化为战术来帮助确定那些因素。
@@ -59,8
          +59,10 @@
  在本章中，我们将讨论重要的注意事项以及开发SVS的相关方法。记住“从你所处的地方开始”的指导性原则是很重要的：转变为面向服务的组织是一个渐进、复杂而值得的努力，组织应该利用其现有的结构和资源，而不是从零开始。
++
  === 7.2.2 ITIL 服务价值链作为运营模式 ===
++
  服务价值链是用于服务管理的灵活运营模式，允许将六个价值链活动（计划、改进、契动、设计和转换、获取或构建、交付和支持）创造性地组合到价值流中。服务价值链突出显示了价值共同创建中涉及的那些活动，以便了解组织的控制和指导下的功能。价值流中的每一个活动都可以利用不同实践组合的能力，具体取决于背景。
  尝试创建统一的运营模式产生了通常面向过程的方法，但这些在面向应用时却失败了。ITIL不是面向过程的：它在策略上解决了价值的问题。这使得基于需求的组织可以采用和适应管理的做法来创建独特的价值流。
@@ -72,6
          +72,7 @@
  一些实践可能在组织内制度化，可能包括专门的资源、团队和组织结构；也可能包括共享资源和团队，没有正式的结构。无论哪种方式，都应该确定负责对重要实践持续进行开发及其在整个组织的个人或团体。这些人和团体可以组成一个称为服务管理办公室的团队。
++
  **定义：服务管理办公室（SMO）**
  充当服务管理卓越中心的小组或部门，以确保组织的开发和应用管理实践始终如一。
@@ -101,13
          +101,22 @@
  [[image:1639217885243-941.png]]
++(% class="wikigeneratedid" %)
++==   ==
++
++(% class="wikigeneratedid" %)
++==   ==
++
  == 7.3 SVS中的服务管理四维模型 ==
++
  组织开发的系统允许他们高效运作并将职能集中在他们定义的使命上。服务管理环境日益增加的复杂性要求IT服务供应商也必须这样做。如果组织的SVS是在考虑到这四个维度的情况下开发的，则将使它能够高水平地执行当前的活动，能对快速的变更做出适当的响应，并在必要时进行实质性的转换。
++
  === 7.3.1 SVS中的组织和人员 ===
++
  服务供应商组织经常与其他组织互动。组织和人员维度可确保将这些人为因素整合到SVS中时，对组织的使命做出适当的贡献。
  组织的愿景、使命、战略和目标一旦定义后，就会出现支持整体组织意图的结构、流程和角色。这些结构和有经验的员工与信息和技术交互，参与价值流和流程，并以合作伙伴和供应商的形式与其他组织和人员合作。
@@ -115,8
          +115,10 @@
  确定组织的模型后，应将容量和劳动力的能力映射到该组织上。人员是任何SVS的关键要素且对于建立和培养所需的以服务为导向的文化是必不可少的。领导者在传达组织的指导和计划方面起着重要的作用，以便每个人都能理解并为自己所做的贡献感到自豪。
++
  ==== 7.3.1.1 不同组织结构的影响 ====
++
  项目开始时的一个重要的早期决定是如何将人员分组，以交付和改进产品和服务。现代思想提出组织结构是新兴的和自治的：具有共同目标的自然成果。然而，并非所有团队都能以这种方式进行自组织。
  可以采用几种组织结构。有些结构是分层的；其他类似网络或矩阵型。许多组织根据员工的专业活动、技能、专业知识和资源将其分为几组。尽管很常见，但是这种方法会导致竖井式的团队，他们对其他团队做什么或如何做的知之甚少。依赖于跨职能工作的结构可以帮助团队保持对他们负责的产品和/或服务的共同关注，但是它们也可能使全面的产品组合概述难以产生，并可能导致重复的工作，甚至重复的服务。
@@ -124,6
          +124,7 @@
  选择支持SVS的组织结构时，考虑诸如类型、规模、专业化和控制范围等因素是很重要的。至关重要的是组织需要确定哪种因素最能支持其产品和服务。精益技术应与持续改进实践相结合，以评估成功因素，并了解价值链和相关价值流的要求，以减少浪费。
++
  ==== 7.3.1.2 角色与工作 ====
@@ -145,17
          +145,20 @@
  角色很少能清晰地映射到工作上。组织有责任决定任务如何分配、分发及管理方式，以确保生产出高质量的产品和服务。
++
  ==== 7.3.1.3 RACI职能矩阵和责任分配 ====
++
  职责分配矩阵（或RACI图表）是用于识别和记录角色和职责的工具，如表7.1所述。
  表7.1 RACI职能矩阵图表的角色及描述
--|**缩写**|**权威**|**描述**
--|R|谁执行|担任此角色的人员执行活动。每个活动可能有不止一个负责人。
--|A|谁审批|此角色的人员是最终决策者，并对活动的的成果负责。
--|C|咨询谁|此角色中的人员根据其对活动的或其对未来项目的潜在影响的专业知识提供意见。
--|I|知会谁|此角色中的人员会定期更新有关活动的信息，但无需更多参与。
++(% style="width:484px" %)
++|(% style="width:74px" %)**缩写**|(% style="width:89px" %)**权威**|(% style="width:320px" %)**描述**
++|(% style="width:74px" %)R|(% style="width:89px" %)谁执行|(% style="width:320px" %)担任此角色的人员执行活动。每个活动可能有不止一个负责人。
++|(% style="width:74px" %)A|(% style="width:89px" %)谁审批|(% style="width:320px" %)此角色的人员是最终决策者，并对活动的的成果负责。
++|(% style="width:74px" %)C|(% style="width:89px" %)咨询谁|(% style="width:320px" %)此角色中的人员根据其对活动的或其对未来项目的潜在影响的专业知识提供意见。
++|(% style="width:74px" %)I|(% style="width:89px" %)知会谁|(% style="width:320px" %)此角色中的人员会定期更新有关活动的信息，但无需更多参与。
  RACI职能矩阵图表提供了一种紧凑、简明、直接的方法来跟踪谁在做什么，从而实现快速、自信的决策。无论组织是否倾向于利用RACI职能矩阵图表或其他方法，都不要缺失角色的分配，尤其是负责任的角色，以留给机会或延迟决策。
@@ -162,8
          +162,10 @@
  在SVS中，责任分配尤其重要。在一个复杂的组织中如果没有明确地为其主要活动和服务分配责任，那么可能会忽略问题，并且质量会受到影响。
++
  ==== 7.3.1.4 服务所有权 ====
++
  服务供应商组织对确保正确管理和改善其服务具有浓厚的兴趣。有些组织可能会选择为其产品组合中的每个服务分配一个所有者，但每一个组织都应该为其最重要的服务分配所有者。确定是否应为服务分配所有者的一种方法是，根据以下因素考虑其重要性：
  ● 有多少客户使用服务
@@ -185,18
          +185,21 @@
  所有者不仅应为自己拥有的服务负责，而且还应被赋予足够的权限以使他们真正有所作为。在没有相称权限的情况下，为某人分配责任将不会产生预期的结果。
++
  ==== 7.3.1.5 角色和能力 ====
++
  角色的结构和命名因组织而异，并且在ITIL中定义的角色不是强制性的。ITIL 实践指南使用基于表7.2中所示模型的能力概要文件来描述每个角色。
  表7.2能力代码与类型
--|**能力代码**|**能力简介（活动与技能）**
--|L|Leader领导：决策、授权、监督其他活动，提供激励和动力，并评估结果。
--|A|Administrator管理员：分配任务并确定优先级、保存记录、持续报告，并启动基本改进。
--|C|Coordnator协调者/沟通者：协调多方，维护利益相关者之间的沟通，并开展宣传活动。
--|M|Methods and techniques expert方法和技术专家：设计和实施工作技巧，文件化步骤，流程咨询、工作分析和持续改进。
--|T|Technical expert技术专家：提供技术（IT）专业知识并执行基于专家经验的作业。
++(% style="width:410px" %)
++|(% style="width:92px" %)**能力代码**|(% style="width:316px" %)**能力简介（活动与技能）**
++|(% style="width:92px" %)L|(% style="width:316px" %)Leader领导：决策、授权、监督其他活动，提供激励和动力，并评估结果。
++|(% style="width:92px" %)A|(% style="width:316px" %)Administrator管理员：分配任务并确定优先级、保存记录、持续报告，并启动基本改进。
++|(% style="width:92px" %)C|(% style="width:316px" %)Coordnator协调者/沟通者：协调多方，维护利益相关者之间的沟通，并开展宣传活动。
++|(% style="width:92px" %)M|(% style="width:316px" %)Methods and techniques expert方法和技术专家：设计和实施工作技巧，文件化步骤，流程咨询、工作分析和持续改进。
++|(% style="width:92px" %)T|(% style="width:316px" %)Technical expert技术专家：提供技术（IT）专业知识并执行基于专家经验的作业。
  成功执行活动需要综合能力。但是，对于一项活动某些能力比其他能力更为重要。能力在能力代码中的位置说明了其相对重要性。例如，在CAT的能力概要中，沟通和协调技能非常重要，管理技能有些重要，而技术知识对所描述的活动有用，但不那么重要。
@@ -230,8
          +230,10 @@
  **● 发展创新**   即使在内部服务管理组织里，企业和企业家的思维方式正日益成为一种要求。这种思维方式对于确定新的工作方式，提供服务和解决问题是必要的，可能涉及运用新技术，创造性思维或客户交互。
++
  ==== 7.3.1.6 建立跨越价值链的有效接口 ====
++
  在整个服务价值链和价值流中，人们可以在协作和协调工作中做出最大贡献。在建立参与价值链活动的组织和人员之间的接口时，“ 协作和提升可视化程度”和“ 通盘思考和工作”的指导原则很重要。
  在组织和人员的背景中，与沟通和OCM有关的原理、方法和技术有助于开始建立接口。价值链和各自的价值流应进行检查，考虑这些接口如何能使人们能够一起工作。重要的是要确保每个人都在适当的时间访问相关的知识、信息和人员。随着时间的推移，协作和合作的最大障碍得以消除，组织将不得不更加仔细地检查其价值流图以发现改进之处。
@@ -257,8
          +257,10 @@
  **● 注意权衡**      在大多数情况下，有几种方法可以完成任务。重要的是要权衡每种方法的优点和缺点，以及它们的影响如何在整个系统中传播。
++
  ==== 7.3.1.7 服务供应商文化 ====
++
  文化可以描述为一群人共享的一套价值观，包括对人们应该如何行事、想法、信念和实践的期望。所有组织都有文化，文化使人类的行为可预测。
  组织文化的重要性经常被大大低估。要了解组织的文化及其对服务管理的准备情况，请务必提出以下问题：
@@ -293,15
          +293,22 @@
  [[image:1639218088734-110.png]]
++
++(% class="wikigeneratedid" %)
++===   ===
++
  === 7.3.2 SVS中的合作伙伴和供应商 ===
++
  与关键合作伙伴和供应商的关系应包含共同创造价值的概念。组织及其供应商都应该希望对方成功。为此，这段关系对双方都必须有价值。
  服务供应商应仔细考虑如何以及何时向合作伙伴或供应商申请契动，并应在提供服务的同时努力管理与供应商的关系。
++
  ==== 7.3.2.1 与供应商和合作伙伴的服务关系 ====
++
  在服务关系中，组织将扮演服务供应商或服务消费者的角色。这两个角色不是唯一的：组织通常在随时提供，也在随时使用许多服务。图片7.1中显示了组织在角色之间使用转换的方式。
  (% style="text-align:center" %)
@@ -317,40
          +317,26 @@
  表7.3三种原型服务关系类型
--(% style="text-align:center" %)
--[[image:1639218161001-613.png]]
++[[image:1639218161001-613.png||style="float:left"]]
--(% style="width:886px" %)
--|(% style="width:109px" %) |(% style="width:241px" %)**基本关系**|(% style="width:268px" %)**合作关系**|(% style="width:265px" %)**服务合作伙伴**
--|(% style="width:109px" %)典型焦点|(% style="width:241px" %)支持与效率|(% style="width:268px" %)改进与效果|(% style="width:265px" %)创新与成长
--|(% style="width:109px" %)关系中典型的组织级别|(% style="width:241px" %)运营|(% style="width:268px" %)运营和战术|(% style="width:265px" %)运营，战术和战略
--|(% style="width:109px" %)关系的典型水平成熟度|(% style="width:241px" %)发起人或赞助人, 接单者|(% style="width:268px" %)服务供应商，值得信赖的顾问|(% style="width:265px" %)战略合作伙伴
--|(% style="width:109px" %)典型的服务类型|(% style="width:241px" %)商业现货服务，开箱即用的服务，高度标准化的商品服务或商品供应|(% style="width:268px" %)必须配置或定制以满足服务消费者需求|(% style="width:265px" %)具有独特价值主张自定义或定制服务
--|(% style="width:109px" %)协议的典型类型|(% style="width:241px" %)标准合同，SLA和基于经验的协议，主要针对大众市场|(% style="width:268px" %)高级SLA，基于体验的协议或基于成果的协议|(% style="width:265px" %)(((
--定制合同，基于成果的协议或无协议。
++[[image:1641536617924-170.png]]
--敏捷环境中、实验和假设测试。
--)))
--|(% style="width:109px" %)例子|(% style="width:241px" %)(((
--正如服务供应商所期望的那样，服务消费者非常清楚地表达他们的期望。
--
--例如，向独立的外部服务消费者的广泛群体提供标准化服务。移动运营商、宽带服务供应商和运输公司通常采用这种方式。
--)))|(% style="width:268px" %)根据服务供应商和服务消费者之间的关系，服务供应商可能难以完全理解服务消费者希望实现的结果。在某些情况下，他们会共同定义所需的结果。例如，内部IT或人事部门的客户关系经理会定期与客户交谈并讨论他们的需求和期望。|(% style="width:265px" %)(((
--基于已根据客户指定要求计划和构建的服务提供和产品的服务。
--
--服务消费者和服务供应商在共享团队中共同创建生产的敏捷产品开发。
--)))
--
   基于组织定义的战略，一种类型的关系可能比其他类型的关系更受欢迎。
++(% class="wikigeneratedid" %)
++====   ====
++
  ==== 7.3.2.2 基本关系 ====
++
  在IT和服务管理中，硬件供应的合同是这些安排中最直接的：成本设定、交付时间的协商、功用和功效的明确表达，并且很容易根据合同的预期报告性能。这种关系几乎没有歧义。货品要么按时交付并按预期执行，要么没有。如果没有达到预期，将会有合同要求和处罚措施规定补救行动。
++
  ==== 7.3.2.3 合作关系 ====
++
  服务交付合同（例如平台（或技术）即服务）允许进行解释，因此在各方之间会产生误解。重要的是要了解各方对价值的定义，一个伙伴的责任在哪里终止，另一伙伴的责任在哪里开始，以及购买了什么级别的服务。
  例如，组织是否在平台上购买了专有租赁，或者是以共享服务的形式购买的？如果接受了共享租用安排，则组织将无法命令中断窗口或坚持更改共享基础设施组件，因为任何更改都需要使平台上的所有租户受益，或者至少没有负面的影响。
@@ -358,22
          +358,28 @@
  组织是否同意“黑匣子”服务？如果是这样，则供应商必须提供满足合同要求的服务，但不需要详细说明那些可能具有商业敏感性的基础架构。合作伙伴有责任确保服务满足合同要求，但无需解释如何实现。
++
  ==== 7.3.2.4 服务合作伙伴关系 ====
++
  在这种类型的服务关系中，合作伙伴双方都有共同的目标，并将共同努力为客户交付价值。员工入职就是一个很好的例子，IT、人力资源和设施应进行协调以向新员工提供高效的体验。
  这种协调具有挑战性。实际上，每个组织中都有许多事例表明未实现目标时会发生什么。例如，如果HR未将正确的信息提交给IT，则可能无法及时交付所需的硬件和软件。这种类型的流程的适当自动化将解决许多这类问题。
++
  ==== 7.3.2.5 建立跨组织边界的有效接口 ====
++
  伙伴关系，无论是内部的还是外部的，都必须具有可以跨越内部和外部边界的完善有效的接口。沟通渠道必须开放，并为定期讨论和补救问题提供机会。
  包括明确的升级通道和联系点的协作流程对于维持健康的工作关系至关重要。这些流程应该很简单；如果很复杂，则很可能会被规避。在未及早建立沟通渠道的环境中，任何人都没有意识到发生了什么之前，关系可能会遭受无法挽回的损害。良好的沟通和在困难的情况下从不推卸责任是解决问题的最佳方法。
++
  ==== 7.3.2.6 服务集成和管理 ====
++
  使用服务集成和管理方法来管理具有多个合作伙伴和供应商的复杂生态系统是一种日益普遍和有效的方法，其中建立了独立的服务集成商功能。服务集成旨在协调内部和外部服务供应商，以为组织及其客户提供具有凝聚力的服务。
  服务集成有四种主要模型。它们是：
@@ -401,15
          +401,19 @@
  [[image:1639227418795-695.png]]
++
  === 7.3.3 SVS中的价值流和流程 ===
++
  通过使用价值流来组织和改进服务管理的工作。这些构造定义了做什么以及如何做，并根据需要和情况进行了适当的调整。
  组织应该检查他们如何执行工作，并映射他们可以识别的所有价值流。这将使他们能够分析其当前状态，并确定工作流和非增值活动（即浪费）的任何障碍。应消除浪费的活动以提高生产效率。
++
  ==== 7.3.3.1 聚焦价值流 ====
++
  价值流是向客户交付价值的工具。价值流包含将价值添加到服务价值链中正在处理的工作单元中的步骤，以将任何需求或机会转化有价值的结果。每个步骤均以定义的方式执行，并使用一种或多种实践。
  ITIL，尤其是“ 聚焦价值”的指导原则，旨在不断改善每个步骤的执行方式，无论是单独执行还是作为一系列要优化的步骤。当工作执行不正确或未创建所需的价值时，原因很可能是价值流的问题造成的。
@@ -417,8
          +417,10 @@
  关注价值流提供了一种方法，可以识别出对特定价值流中涉及的工作流和实践的可能改进。这结合了精益的流程优化和消除浪费的方法，并带有“聚焦价值” “通盘思考和工作”和“基于反馈迭代推进”之类的指导原则。
++
  ==== 7.3.3.2 价值流和实践之间的关系 ====
++
  许多服务管理指南，包括适用的ISO标准，都是面向流程的。流程是组织成功的基础，而作为四个维度一部分反映了这一点。流程支持通过价值流进行价值共创，但不应关注单一的流程或以流程本身为最终目标。
  但是，如果组织花太多时间专注于流程，则它对其产品和服务或为其客户创造价值就不能给予适当的关注了。ITIL 4注重价值流，以价值为导向。
@@ -436,8
          +436,10 @@
  价值流组织了为客户创建价值的过程，实践是组织将其特定资源应用于任务的方式。
++
  ==== 7.3.3.3 价值流和流程之间的关系 ====
++
  价值流和流程不是一回事，但是它们有很多共同点。价值流和流程都与活动和工作流有关：它们帮助组织了解发生了什么以及如何发生。价值流图记录关键信息和资源在整个工作流中的移动，并说明可能在何处发现潜在的浪费。尽管并非每个组织都以图形方式记录其流程，但也可以映射流程。流程和价值流都定义了活动、输入和输出。
  价值流和流程之间的主要区别在于它们的重点和用法。这些差异可能是很细微的，但却是很重要的。几乎所有将输入转化为输出的相互关联的活动都可以视为一个流程。但是，价值流主要侧重于从需求或机会到价值的活动流（例如，从用户致电地板公司并询问如何重新装修木地板到用户的木地板已经完成重新装修为止的活动流，肯定是价值流）。例如公司在每月结束时生成当月财务报表的活动，则将其视为价值流就不合适了。每月进行财务计算的工作是流程。
@@ -447,8
          +447,10 @@
  流程图或其他流程文档通常更适合查找有关每个步骤执行方式的问题，但这有时会导致局部优化，而不是整体改进。
++
  ==== 7.3.3.4 设计工作流 ====
++
  在为流程或价值流设计工作流时，需要回答的问题包括：
  ● 什么会导致工作开始？
@@ -466,8
          +466,10 @@
  ● 将对工作流的哪些方面进行度量？数据将如何格式化、存储和使用？
++
  ==== 7.3.3.5 高效设计的注意事项 ====
++
  流程设计通常借助于模板和工具包，这些模板和工具包可以在管理文献中找到，由顾问和培训师提供，或者由供应商以开箱即用的工具功能记录下来。这些通常是不断改进SVS及其资源的良好起点。此类文献应该根据服务组织的需求进行评估，调整文献或功能的机会或要求，以便可以尽快被识别和实施。
  已定义的工作方式指南对于意外或不可预测的事件可能会很有用；例如，如果团队的主要工具不再可用，该团队将如何记录事件？
@@ -507,8
          +507,10 @@
  ● 为了稳定节点周期，可能有必要限制WIP。这是看板的前提，它能在吞吐量可预测的环境中良好工作。
++
  ==== 7.3.3.6 约束理论 ====
++
  约束理论提供了另一种查看流程进度并确定瓶颈在哪里约束价值的方法。该理论指出，“任何系统的吞吐量都是由一个约束决定的”。增加流程的价值依赖于识别和消除这些关键约束。
  Eliyahu M. Goldratt（1984）描述了应用此理论的五个步骤：
@@ -524,8
          +524,10 @@
  ● 消除约束并重新评估流程。
++
  ==== 7.3.3.7 管理工作的看板技术 ====
++
  那些难以监督、确定优先级和管理工作的人常常发现看板很有用。人们在计划工作时可能会遇到困难，因为他们无法可视化所涉及的步骤。看板通过促进流程工作流的完全可视化来解决此问题。板面分为多个流程阶段，工作项（看板卡）放在上面，并随着阶段的进进展而移动。看板用于：
  ● 可视化流程并将信息传递给团队
@@ -554,8
          +554,15 @@
  [[image:1639227653882-224.png]]
++(% class="wikigeneratedid" %)
++===   ===
++
++(% class="wikigeneratedid" %)
++===   ===
++
  === 7.3.4 SVS中的信息和技术 ===
++
  SVS的吞吐量，即从需求转变到价值的能力, 可以被技术决策和相关信息的管理所增强或限制。对最佳技术的渴望和大量可用的技术解决方案常常导致工具链断开。在计划如何精简该工具链时，至关重要的是要考虑信息技术的当前状态和需求，以及其他三个方面的信息和需求。组织不以这种方式考虑所有四个方面，可能会有很高比例的重叠技术，而这些技术的开发能力不足。应该利用治理和控件来防止断裂的工具链发展或恶化。
  选择和实施工具是一项投资。一旦采用了一项技术，就必须建立维护并最大化其收益的机制。实施一项新技术将会引入新的价值流进行管理。通常，一项技术不能应用于多个项目时，技术变得闲置无用，成为孤立的和/或已过时的解决方案。
@@ -616,8
          +616,10 @@
  本节的其余部分将回顾服务管理套件和新兴技术的价值，以及确保它们交付的信息具有可扩展性，满足利益干系人的需求并向他们交付价值的重要性。
++
  ==== 7.3.4.1 服务管理工具套件 ====
++
  服务管理工具套件是一个包含多个应用程序的平台，通常从IT和服务管理扩展到人力资源、财务和设施部门以及运营业务，并最终成为为客户创造价值所需的其他能力。价值流和价值链贯穿多个ITIL实践，要求信息是可用的和可共享的。如果有多个系统来管理这项工作，那么集成可以减少系统之间切换所花费的时间。
  例如，IT资产通常是通过服务管理工具套件中的服务请求目录来申请的。但是，这些目录很少与采购系统连接。取而代之的是，有人手动将来自服务管理套件的信息输入到采购系统中。这会影响生产效率，准确性和资产的交付时间。
@@ -718,8
          +718,10 @@
  可以通过已定义的供应商管理实践来获得评估供应商的工具。
++
  ==== 7.3.4.2 开发新兴技术的好处 ====
++
  有几种补充系统和工具，可以用来帮助增强服务管理套件的功能。不采用这些新兴技术的组织可能会被抛在后面。
  然而，认识到从这些投资中获得价值所需的技能和时间是很重要的。一些组织采用了太多的新工具，无意间消耗了资源。通常，采用工具来提高效率，但是大多数工具都需要资源来维护。因此，需要全面的商业论证来证明其合理性。
@@ -731,8
          +731,10 @@
  工作流自动化呈指数级增长。所有新技术代表着新机遇。
++
  ==== 7.3.4.3 建立信息模型 ====
++
  所有组织都有现有的信息模型。了解它们是什么、它们的来源以及如何维护它们是任何IT和服务管理实施的关键部分。信息模型包含有关数据模型之间关系的信息。
@@ -780,8
          +780,13 @@
  [[image:1639228426310-882.png]]
++
++(% class="wikigeneratedid" %)
++==   ==
++
  == 7.4 总结 ==
++
  如果组织真正致力于采用一种专注于服务、价值和结果的工作方式，则它必须相应地设计其SVS。通过利用ITIL 指导原则并与组织的治理和战略保持一致，组织应该开发和配置其资源以支持价值共创。面向服务并保持这种定位本质上是具有挑战性的，但付出大量的努力是值得的。

1641536617924-170.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+96.4 KB

Content

粤ICP备17056641号

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

Changes for page 第7章 开发服务价值系统

Summary

Details

Changes for page 第7章开发服务价值系统