Last modified by superadmin on 2024/04/03, 18:59
From version < 12.1 >
edited by superadmin
on 2021/12/11, 21:13
To version < 13.1 >
edited by superadmin
on 2021/12/11, 21:14
< >
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -312,24 +312,465 @@
312 312  [[image:1639218161001-613.png]]
313 313  
314 314  (% style="width:1061px" %)
315 -|(% style="width:89px" %) |(% style="width:264px" %)**基本关系**|(% style="width:408px" %)**合作关系**|(% style="width:299px" %)**服务合作伙伴**
316 -|(% style="width:89px" %)典型焦点|(% style="width:264px" %)支持与效率|(% style="width:408px" %)改进与效果|(% style="width:299px" %)创新与成长
317 -|(% style="width:89px" %)关系中典型的组织级别|(% style="width:264px" %)运营|(% style="width:408px" %)运营和战术|(% style="width:299px" %)运营，战术和战略
318 -|(% style="width:89px" %)关系的典型水平成熟度|(% style="width:264px" %)发起人或赞助人, 接单者|(% style="width:408px" %)服务供应商，值得信赖的顾问|(% style="width:299px" %)战略合作伙伴
319 -|(% style="width:89px" %)典型的服务类型|(% style="width:264px" %)商业现货服务，开箱即用的服务，高度标准化的商品服务或商品供应|(% style="width:408px" %)必须配置或定制以满足服务消费者需求|(% style="width:299px" %)具有独特价值主张自定义或定制服务
320 -|(% style="width:89px" %)协议的典型类型|(% style="width:264px" %)标准合同，SLA和基于经验的协议，主要针对大众市场|(% style="width:408px" %)高级SLA，基于体验的协议或基于成果的协议|(% style="width:299px" %)(((
315 +|(% style="width:122px" %) |(% style="width:229px" %)**基本关系**|(% style="width:348px" %)**合作关系**|(% style="width:358px" %)**服务合作伙伴**
316 +|(% style="width:122px" %)典型焦点|(% style="width:229px" %)支持与效率|(% style="width:348px" %)改进与效果|(% style="width:358px" %)创新与成长
317 +|(% style="width:122px" %)关系中典型的组织级别|(% style="width:229px" %)运营|(% style="width:348px" %)运营和战术|(% style="width:358px" %)运营，战术和战略
318 +|(% style="width:122px" %)关系的典型水平成熟度|(% style="width:229px" %)发起人或赞助人, 接单者|(% style="width:348px" %)服务供应商，值得信赖的顾问|(% style="width:358px" %)战略合作伙伴
319 +|(% style="width:122px" %)典型的服务类型|(% style="width:229px" %)商业现货服务，开箱即用的服务，高度标准化的商品服务或商品供应|(% style="width:348px" %)必须配置或定制以满足服务消费者需求|(% style="width:358px" %)具有独特价值主张自定义或定制服务
320 +|(% style="width:122px" %)协议的典型类型|(% style="width:229px" %)标准合同，SLA和基于经验的协议，主要针对大众市场|(% style="width:348px" %)高级SLA，基于体验的协议或基于成果的协议|(% style="width:358px" %)(((
321 321  定制合同，基于成果的协议或无协议。
322 322  
323 323  敏捷环境中、实验和假设测试。
324 324  )))
325 -|(% style="width:89px" %)例子|(% style="width:264px" %)(((
325 +|(% style="width:122px" %)例子|(% style="width:229px" %)(((
326 326  正如服务供应商所期望的那样，服务消费者非常清楚地表达他们的期望。
327 327  
328 328  例如，向独立的外部服务消费者的广泛群体提供标准化服务。移动运营商、宽带服务供应商和运输公司通常采用这种方式。
329 -)))|(% style="width:408px" %)根据服务供应商和服务消费者之间的关系，服务供应商可能难以完全理解服务消费者希望实现的结果。在某些情况下，他们会共同定义所需的结果。例如，内部IT或人事部门的客户关系经理会定期与客户交谈并讨论他们的需求和期望。|(% style="width:299px" %)(((
329 +)))|(% style="width:348px" %)根据服务供应商和服务消费者之间的关系，服务供应商可能难以完全理解服务消费者希望实现的结果。在某些情况下，他们会共同定义所需的结果。例如，内部IT或人事部门的客户关系经理会定期与客户交谈并讨论他们的需求和期望。|(% style="width:358px" %)(((
330 330  基于已根据客户指定要求计划和构建的服务提供和产品的服务。
331 331  
332 332  服务消费者和服务供应商在共享团队中共同创建生产的敏捷产品开发。
333 333  )))
334 334  
335 -
335 + 基于组织定义的战略，一种类型的关系可能比其他类型的关系更受欢迎。
336 +
337 +
338 +==== 7.3.2.2 基本关系 ====
339 +
340 +在IT和服务管理中，硬件供应的合同是这些安排中最直接的：成本设定、交付时间的协商、功用和功效的明确表达，并且很容易根据合同的预期报告性能。这种关系几乎没有歧义。货品要么按时交付并按预期执行，要么没有。如果没有达到预期，将会有合同要求和处罚措施规定补救行动。
341 +
342 +
343 +==== 7.3.2.3 合作关系 ====
344 +
345 +服务交付合同（例如平台（或技术）即服务）允许进行解释，因此在各方之间会产生误解。重要的是要了解各方对价值的定义，一个伙伴的责任在哪里终止，另一伙伴的责任在哪里开始，以及购买了什么级别的服务。
346 +
347 +例如，组织是否在平台上购买了专有租赁，或者是以共享服务的形式购买的？如果接受了共享租用安排，则组织将无法命令中断窗口或坚持更改共享基础设施组件，因为任何更改都需要使平台上的所有租户受益，或者至少没有负面的影响。
348 +
349 +组织是否同意“黑匣子”服务？如果是这样，则供应商必须提供满足合同要求的服务，但不需要详细说明那些可能具有商业敏感性的基础架构。合作伙伴有责任确保服务满足合同要求，但无需解释如何实现。
350 +
351 +
352 +==== 7.3.2.4 服务合作伙伴关系 ====
353 +
354 +在这种类型的服务关系中，合作伙伴双方都有共同的目标，并将共同努力为客户交付价值。员工入职就是一个很好的例子，IT、人力资源和设施应进行协调以向新员工提供高效的体验。
355 +
356 +这种协调具有挑战性。实际上，每个组织中都有许多事例表明未实现目标时会发生什么。例如，如果HR未将正确的信息提交给IT，则可能无法及时交付所需的硬件和软件。这种类型的流程的适当自动化将解决许多这类问题。
357 +
358 +
359 +==== 7.3.2.5 建立跨组织边界的有效接口 ====
360 +
361 +伙伴关系，无论是内部的还是外部的，都必须具有可以跨越内部和外部边界的完善有效的接口。沟通渠道必须开放，并为定期讨论和补救问题提供机会。
362 +
363 +包括明确的升级通道和联系点的协作流程对于维持健康的工作关系至关重要。这些流程应该很简单；如果很复杂，则很可能会被规避。在未及早建立沟通渠道的环境中，任何人都没有意识到发生了什么之前，关系可能会遭受无法挽回的损害。良好的沟通和在困难的情况下从不推卸责任是解决问题的最佳方法。
364 +
365 +
366 +==== 7.3.2.6 服务集成和管理 ====
367 +
368 +使用服务集成和管理方法来管理具有多个合作伙伴和供应商的复杂生态系统是一种日益普遍和有效的方法，其中建立了独立的服务集成商功能。服务集成旨在协调内部和外部服务供应商，以为组织及其客户提供具有凝聚力的服务。
369 +
370 +服务集成有四种主要模型。它们是：
371 +
372 +**● 将组织保留为服务集成和管理**  组织管理所有供应商，并自行协调服务集成和管理功能。
373 +
374 +**● 单个供应商**     供应商提供所有服务以及服务集成和管理功能。
375 +
376 +**● 服务守护者**     除了管理其他供应商外，供应商还提供服务集成和管理功能和一个或多个交付功能。
377 +
378 +**● 独立的服务集成商**       供应商提供服务集成和管理功能并管理其他供应商，即使该供应商未向组织提供任何服务。
379 +
380 +服务集成不是实践，但是它借鉴了其他几种实践来提供职能，其目的是最大程度地减少多源方法固有的风险。
381 +
382 +为了考虑服务集成，组织应该评估其内部技能和组织成熟度，以及他们将管理的环境复杂性。
383 +
384 +图片7.2显示了服务集成模型的基本轮廓。
385 +
386 +(% style="text-align:center" %)
387 +[[image:1639227400393-817.png]]
388 +
389 +图片7.2 服务集成模型
390 +
391 +
392 +[[image:1639227418795-695.png]]
393 +
394 +
395 +=== 7.3.3 SVS中的价值流和流程 ===
396 +
397 +通过使用价值流来组织和改进服务管理的工作。这些构造定义了做什么以及如何做，并根据需要和情况进行了适当的调整。
398 +
399 +组织应该检查他们如何执行工作，并映射他们可以识别的所有价值流。这将使他们能够分析其当前状态，并确定工作流和非增值活动（即浪费）的任何障碍。应消除浪费的活动以提高生产效率。
400 +
401 +
402 +==== 7.3.3.1 聚焦价值流 ====
403 +
404 +价值流是向客户交付价值的工具。价值流包含将价值添加到服务价值链中正在处理的工作单元中的步骤，以将任何需求或机会转化有价值的结果。每个步骤均以定义的方式执行，并使用一种或多种实践。
405 +
406 +ITIL，尤其是“ 聚焦价值”的指导原则，旨在不断改善每个步骤的执行方式，无论是单独执行还是作为一系列要优化的步骤。当工作执行不正确或未创建所需的价值时，原因很可能是价值流的问题造成的。
407 +
408 +关注价值流提供了一种方法，可以识别出对特定价值流中涉及的工作流和实践的可能改进。这结合了精益的流程优化和消除浪费的方法，并带有“聚焦价值” “通盘思考和工作”和“基于反馈迭代推进”之类的指导原则。
409 +
410 +
411 +==== 7.3.3.2 价值流和实践之间的关系 ====
412 +
413 +许多服务管理指南，包括适用的ISO标准，都是面向流程的。流程是组织成功的基础，而作为四个维度一部分反映了这一点。流程支持通过价值流进行价值共创，但不应关注单一的流程或以流程本身为最终目标。
414 +
415 +但是，如果组织花太多时间专注于流程，则它对其产品和服务或为其客户创造价值就不能给予适当的关注了。ITIL 4注重价值流，以价值为导向。
416 +
417 +组织必须发展并保持向服务消费者提供服务的能力；这项努力得到了ITIL实践的支持。例如，当组织需要发展和维护其理解IT资产的能力时，它会将重点放在开发IT资产管理实践上，从而解决所有服务管理四个维度的问题。
418 +
419 +(% style="text-align:center" %)
420 +[[image:1639227473841-365.png]]
421 +
422 +图片7.3 价值流与实践之间的关系
423 +
424 +
425 +服务供应商使用价值链活动作为定义其价值流的构建块。随着每个价值流的实现，相关的实践也对其有所贡献。有些参与价值流的活动，其他的则通过提供信息来支持价值流中的决策做出贡献。图片7.3显示了价值流和相关实践之间的关系。
426 +
427 +价值流组织了为客户创建价值的过程，实践是组织将其特定资源应用于任务的方式。
428 +
429 +
430 +==== 7.3.3.3 价值流和流程之间的关系 ====
431 +
432 +价值流和流程不是一回事，但是它们有很多共同点。价值流和流程都与活动和工作流有关：它们帮助组织了解发生了什么以及如何发生。价值流图记录关键信息和资源在整个工作流中的移动，并说明可能在何处发现潜在的浪费。尽管并非每个组织都以图形方式记录其流程，但也可以映射流程。流程和价值流都定义了活动、输入和输出。
433 +
434 +价值流和流程之间的主要区别在于它们的重点和用法。这些差异可能是很细微的，但却是很重要的。几乎所有将输入转化为输出的相互关联的活动都可以视为一个流程。但是，价值流主要侧重于从需求或机会到价值的活动流（例如，从用户致电地板公司并询问如何重新装修木地板到用户的木地板已经完成重新装修为止的活动流，肯定是价值流）。例如公司在每月结束时生成当月财务报表的活动，则将其视为价值流就不合适了。每月进行财务计算的工作是流程。
435 +
436 +价值流图和流程文档的使用方式也非常不同。价值流图通常以视觉方式呈现，并用于整体查看端到端工作流，显示如何改进或消除单个步骤以及如何改进步骤之间的区域。
437 +
438 +流程图或其他流程文档通常更适合查找有关每个步骤执行方式的问题，但这有时会导致局部优化，而不是整体改进。
439 +
440 +
441 +==== 7.3.3.4 设计工作流 ====
442 +
443 +在为流程或价值流设计工作流时，需要回答的问题包括：
444 +
445 +● 什么会导致工作开始？
446 +
447 +● 创建定义的输出或结果需要什么信息，而无论是从外部利益干系人还是从内部获得？这些信息什么时候可用？信息将采用哪种格式？
448 +
449 +● 为了实现所需的输出，需要执行哪些步骤？哪些步骤可以并行执行，哪些步骤具有先决步骤、活动或子流程？每个步骤需要多长时间？
450 +
451 +● 工作流创建了哪些制品？
452 +
453 +● 每个步骤为服务供应商、服务消费者或其他利益干系人创造了什么价值？
454 +
455 +● 流程或价值流必须遵循哪些策略？
456 +
457 +● 将对工作流的哪些方面进行度量？数据将如何格式化、存储和使用？
458 +
459 +
460 +==== 7.3.3.5 高效设计的注意事项 ====
461 +
462 +流程设计通常借助于模板和工具包，这些模板和工具包可以在管理文献中找到，由顾问和培训师提供，或者由供应商以开箱即用的工具功能记录下来。这些通常是不断改进SVS及其资源的良好起点。此类文献应该根据服务组织的需求进行评估，调整文献或功能的机会或要求，以便可以尽快被识别和实施。
463 +
464 +已定义的工作方式指南对于意外或不可预测的事件可能会很有用；例如，如果团队的主要工具不再可用，该团队将如何记录事件？
465 +
466 +可以为任何工作流和活动定义几个重要的指标度量。这些在表7.4中概述，并在图片7.4中显示。
467 +
468 +表7.4工作流程指标度量
469 +
470 +|**术语**|**描述**
471 +|节点周期|完成离散工作单元，将输入转换为输出所需的时间。例如，如果需要五分钟来填写新的事件表单，那么节点周期就是五分钟。
472 +|等待时间|工作开始之前，离散工作单元在队列中等待的时间。例如，如果事件工单在开始工作前平均等待了四个小时，则等待时间为四个小时。
473 +|前置时间|节点周期和等待时间的总和。前置时间表示完成一个离散工作单元所需的总时间，从它进入流程队列到流程结束。
474 +|流程队列|等待流程操作的离散工作单元的数量。
475 +|在制品（WIP）|正在操作但尚未完成的离散工作单元的数量。
476 +|吞吐量|工作进出系统的速率。
477 +
478 +这些指标度量源自利特尔定律，有关更多信息，请参见运营管理或排队理论文献。利特尔定律可以简单地表示为：
479 +
480 +在制品= 吞吐量× 前置时间
481 +
482 +
483 +(% style="text-align:center" %)
484 +[[image:1639227556812-796.png]]
485 +
486 +图片7.4 流程时序
487 +
488 +在设计流程时，利特尔定律建议考虑以下注意事项：
489 +
490 +● 工作转换的次数应最小化。传输创建队列，队列会增加等待时间，从而增加了前置时间。这可以通过增加自动化程度、培训人员或重组团队来实现。
491 +
492 +● 吞吐量尤其是在外部事件和触发器的情况下通常不受服务供应商的控制，但可以使用数学和统计模型对其进行估算。
493 +
494 +● 等待时间可以表示为节点周期的职能。对于新的工作单元，它是节点周期乘系统中的工作单元。
495 +
496 +● 根据工作的性质，可以假定节点周期是固定的。
497 +
498 +● 为了稳定节点周期，可能有必要限制WIP。这是看板的前提，它能在吞吐量可预测的环境中良好工作。
499 +
500 +
501 +==== 7.3.3.6 约束理论 ====
502 +
503 +约束理论提供了另一种查看流程进度并确定瓶颈在哪里约束价值的方法。该理论指出，“任何系统的吞吐量都是由一个约束决定的”。增加流程的价值依赖于识别和消除这些关键约束。
504 +
505 +Eliyahu M. Goldratt（1984）描述了应用此理论的五个步骤：
506 +
507 +● 确定流程的约束。
508 +
509 +● 确定如何最好地利用流程的约束。
510 +
511 +● 使其他所有内容服从上述决定。
512 +
513 +● 评估流程的约束。
514 +
515 +● 消除约束并重新评估流程。
516 +
517 +
518 +==== 7.3.3.7 管理工作的看板技术 ====
519 +
520 +那些难以监督、确定优先级和管理工作的人常常发现看板很有用。人们在计划工作时可能会遇到困难，因为他们无法可视化所涉及的步骤。看板通过促进流程工作流的完全可视化来解决此问题。板面分为多个流程阶段，工作项（看板卡）放在上面，并随着阶段的进进展而移动。看板用于：
521 +
522 +● 可视化流程并将信息传递给团队
523 +
524 +● 限制在制品的数量
525 +
526 +● 管理和度量工作流。
527 +
528 +看板既简单又没有风险。它不需要对当前的流程进行任何更改，可以很好地扩展，并且不会产生额外的成本。图7.5显示了一个看板的示例。
529 +
530 +尝试看板方法的最简单方法是在白板上创建一个简单的看板，并将写在卡片（或便签）上的任务放在上面。看板卡应包含任务的名称，截止日期，完整性定义和指定的执行者。通常使用彩色卡片来指示特定类型的任务。
531 +
532 +设置在制品限制的目的是确保在一定时间内完成最大数量的任务。在制品限制可促进重点，消除浪费的多任务处理，并更容易发现瓶颈。
533 +
534 +
535 +(% style="text-align:center" %)
536 +[[image:1639227612623-124.png]]
537 +
538 +图片7.5 看板的示例
539 +
540 +改编自Mitchell（2012）：知识共享CC0 1.0通用公众域奉献的看板示例。
541 +
542 +
543 +
544 +(% style="text-align:center" %)
545 +[[image:1639227653882-224.png]]
546 +
547 +
548 +=== 7.3.4 SVS中的信息和技术 ===
549 +
550 +SVS的吞吐量，即从需求转变到价值的能力, 可以被技术决策和相关信息的管理所增强或限制。对最佳技术的渴望和大量可用的技术解决方案常常导致工具链断开。在计划如何精简该工具链时，至关重要的是要考虑信息技术的当前状态和需求，以及其他三个方面的信息和需求。组织不以这种方式考虑所有四个方面，可能会有很高比例的重叠技术，而这些技术的开发能力不足。应该利用治理和控件来防止断裂的工具链发展或恶化。
551 +
552 +选择和实施工具是一项投资。一旦采用了一项技术，就必须建立维护并最大化其收益的机制。实施一项新技术将会引入新的价值流进行管理。通常，一项技术不能应用于多个项目时，技术变得闲置无用，成为孤立的和/或已过时的解决方案。
553 +
554 +表7.5概述了组织可以利用的各种技术。
555 +
556 +表7.5可用技术
557 +
558 +(% style="width:995px" %)
559 +|(% style="width:93px" %)机器人|(% style="width:900px" %)(((
560 +机器人可用于模拟人类通过屏幕和应用程序执行的活动，以一致且可预测的方式捕获，解释和处理流程事务，触发响应以及创建和操作数据。
561 +
562 +这些机器人通常成本较低，易于实施。它们不需要对现有系统重新开发，也不需要在现有系统内进行复杂的集成。潜在的好处是显而易见的，因为它们允许以经济高效的方式实施一致、可靠和可预测的流程。一致性可以减少关键流程中的错误，增加收入，并提高客户服务和保留率。
563 +
564 +通常，机器人流程自动化技术有以下三种类型：
565 +
566 +● 流程自动化 这关注于依赖结构化数据的自动化任务，例如电子表格。
567 +
568 +● 增强和智能的流程自动化 此功能主要在非结构化数据作为输入的情况下进行；例如电子邮件和文档。这种类型的自动化可以从经验中学习，并将知识应用于流程的不同要求。
569 +
570 +● 认知平台 他们可以理解客户的查询并执行以前需要人工干预的任务。
571 +)))
572 +|(% style="width:93px" %)人工智能|(% style="width:900px" %)(((
573 +认知技术越来越多的应用在服务生命周期所有阶段的自动化，并为客户和为他们提供服务的人们增强服务体验。它在相关和支持领域也越来越普遍，例如软件开发和运营。
574 +
575 +尽管人工智能技术已经存在了数十年，但新一代基于云的工具已经显著提高了人们对它的关注和使用。供应商现在提供了许多AI工具作为公有云服务。这极大地提高了人工智能工具的可访问性，解决方案以前可能需要复杂技术和大量财务支出，现在可以按需供应，成本可能更低。
576 +)))
577 +|(% style="width:93px" %)AIOps平台|(% style="width:900px" %)(((
578 +在IT运维领域中结合了大数据、分析和机器学习的实践。
579 +
580 +与其让孤立的团队各自监控基础设施的各个部分，不如将所有重要的监控数据集中在一个地方，并利用机器学习来识别模式和检测异常。这可以帮助IT部门更快地识别和解决事件，并在潜在故障发生之前发现它们。它还可以用于自动化处理常规任务。
581 +
582 +AIOps旨在将人工智能引入IT运营，以应对基础设施持续发展中的现代趋势所带来的挑战，例如软件定义系统的增长。这些新技术的影响，例如，基础设施重新配置和改造的速度加快需要更多的自动化和动态的管理技术，这可能会对数字化服务产生重大影响。
583 +
584 +AIOps利用数据平台和机器学习，收集观察性数据（例如事件、日志文件和操作指标度量）和参与数据（例如客户请求和服务台工单）。它通过对该数据应用认知或算法处理来得出洞察力。
585 +
586 +这些洞察力可用于驱动部分或全部范围的通用输出，例如：
587 +
588 +● 问题检测和预测，帮助服务组织更快地对事件做出响应
589 +
590 +● 主动进行系统维护和调整，从而减少了人工和潜在错误。
591 +
592 +● 阈值分析，可以更准确地了解系统的正常运维范围。
593 +
594 +一些组织还开始在IT运维以外使用AIOps，以向业务经理提供有关IT对业务影响的实时洞察，从而使他们随时了解最新情况，并使能够根据相关的数据做出决策。
595 +)))
596 +|(% style="width:93px" %)机器学习|(% style="width:900px" %)(((
597 +AI的一种应用形式。它基于系统响应数据原则，并且随着系统不断接触到更多的数据时，相应地调整它们的操作和输出。在使用机器学习作为服务基础的情况下，这本质上意味着它成为决策的基础，而不是由人工服务设计者创建的指令所定义的路径。
598 +
599 +随着随着任务复杂性的增加，将机器学习映射到该任务变得更加困难。机器学习通常最适合解决特定问题。例如，它可以有效地用于在支持记录上做出有关数据分类的决策。
600 +)))
601 +|(% style="width:93px" %)集成工具集|(% style="width:900px" %)(((
602 +这些工具集可自动执行记录和工作流管理，并充当参与和通讯工具。许多旨在支持服务管理的整体信息模型。这些工具集中的大多数都是为自动化ITIL 服务管理实践而设计的，并且它们也在不断发展以采用新技术。
603 +
604 +这些工具集最常用的功能是记录系统和参与系统。这些用于针对业务和技术基础设施的项目和领域（包括人员、IT、部门），服务和职能领域提出、分类、划分优先级、升级和解决问题、请求和变更。这还包括对交付和实现、批准、升级和消费期望的实时管理，以及库存、财务和生命周期管理的其他管理功能。这些工具集的价值在于管理工作量的实时动态能力，可以管理从小而简单到大而复杂的工作量，并提供有关性能、趋势、改进、成本和风险的报告和业务分析。此外，工具集还提供有关工作交付和“ 服务”资产和资源管理的责任和审计跟踪。规模和声誉各异的组织以某种形式使用这些工具集来优化常规记录保存，并展示了一定程度的责任心、一致性和控制力。但是，大多数组织仅使用工具集中的基本功能（事件管理、服务级别管理、库存管理），而忽略了跨流程进行多功能集成的机会。因此，很少利用工具集提供的端到端价值流集成的机会。但是，随着新的挑战和机遇的出现，对使用此功能和集成的需求也越来越大。
605 +)))
606 +
607 +本节的其余部分将回顾服务管理套件和新兴技术的价值，以及确保它们交付的信息具有可扩展性，满足利益干系人的需求并向他们交付价值的重要性。
608 +
609 +
610 +7.3.4.1 服务管理工具套件
611 +
612 +服务管理工具套件是一个包含多个应用程序的平台，通常从IT和服务管理扩展到人力资源、财务和设施部门以及运营业务，并最终成为为客户创造价值所需的其他能力。价值流和价值链贯穿多个ITIL实践，要求信息是可用的和可共享的。如果有多个系统来管理这项工作，那么集成可以减少系统之间切换所花费的时间。
613 +
614 +例如，IT资产通常是通过服务管理工具套件中的服务请求目录来申请的。但是，这些目录很少与采购系统连接。取而代之的是，有人手动将来自服务管理套件的信息输入到采购系统中。这会影响生产效率，准确性和资产的交付时间。
615 +
616 +
617 +**关键信息**
618 +
619 +重要的是，工具应支持这些实践，而不是命令他们。但是，可能有必要在工具和/或实践中做出一些折衷。如果需要折衷，则重要的是评估工具定制对于与实践一致是否至关重要或实践修改是否可以接受。
620 +
621 +应始终避免对开箱即用的产品进行广泛的定制。定制可能会限制升级的可能性，将供应商从支持义务中释放出来，并降低对核心功能的外部培训的价值。
622 +
623 +
624 +对服务管理工具套件的评估应该首先了解组织的独特需求。需要定义解决方案的短期和长期目标。所需工具的类型取决于对IT服务的业务需求，并在某种程度上取决于组织的规模。
625 +
626 +评估活动包括：
627 +
628 +● 确定需要，包括：
629 +
630 +● 短期和长期目标
631 +
632 +● 职能型需要
633 +
634 +● 非职能型需要
635 +
636 +● 通过以下方式确定候选人：
637 +
638 +● 评审组织的当前工具清单，以了解什么是适当的并定义任何差距
639 +
640 +● 评审市场调研，例如用于ITSM套件的Gartner魔力象限和Forrester Wave方法论
641 +
642 +● 在行业活动和用户组中与客户建立联系
643 +
644 +● 按重要性对需要进行排名；例如，通过使用MoSCoW方法
645 +
646 +● 通过以下方式评估选项：
647 +
648 +● 安排产品演示
649 +
650 +● 验证可以满足100％的强制性需要
651 +
652 +● 拜访其他客户并致电推荐人
653 +
654 +● 候选名单的选择依据：
655 +
656 +● 删除任何不符合强制性要求的产品
657 +
658 +● 请求提案，从而了解许可、订阅和维护的费用
659 +
660 +● 评分/排名，考虑是否：
661 +
662 +● 价值或概念的证明是必要的
663 +
664 +● 一个选项可以满足所有职能型和非职能型需求的80％或更高
665 +
666 +● 一个支持短期和长期目标的选项
667 +
668 +● 选择。
669 +
670 +
671 +一些评估注意事项包括：
672 +
673 +● 可维护性
674 +
675 +● 易于实施和持续的管理
676 +
677 +● 数据的结构和报告能力
678 +
679 +● 集成能力和接口
680 +
681 +● 多租户或其他域分离选项
682 +
683 +● 开放标准，社区开发
684 +
685 +● 易访问性需求
686 +
687 +● 移动性和浏览器支持
688 +
689 +● 数据备份，控制和安全
690 +
691 +● 可扩展性
692 +
693 +● 安全和访问控制
694 +
695 +● 补订和升级节奏
696 +
697 +● 可用性
698 +
699 +● 平台基础架构，操作系统等
700 +
701 +● 支持程序和可用性
702 +
703 +● 培训选择
704 +
705 +● 许可模型
706 +
707 +● 供应商策略、图像、财务、参考等。
708 +
709 +可以通过已定义的供应商管理实践来获得评估供应商的工具。
710 +
711 +
712 +==== 7.3.4.2 开发新兴技术的好处 ====
713 +
714 +有几种补充系统和工具，可以用来帮助增强服务管理套件的功能。不采用这些新兴技术的组织可能会被抛在后面。
715 +
716 +然而，认识到从这些投资中获得价值所需的技能和时间是很重要的。一些组织采用了太多的新工具，无意间消耗了资源。通常，采用工具来提高效率，但是大多数工具都需要资源来维护。因此，需要全面的商业论证来证明其合理性。
717 +
718 +无论是云计算、移动自带设备（BYOD）、认知计算解决方案、监控和报告，还是自动化和测试，IT运营部门都有责任及时经济高效地采用和调整这些不断变化的解决方案。
719 +
720 +最近数字化设备的数量和类型大量增加，导致了出现新型的在线社区和服务，这些在线社区和服务反过来又改变了业务和社交互动的工作方式。例如，智能手机和平板设备启用了新的移动商业模式，而该模式在十年前是不存在的。云服务是业务和IT运营的新模式，用于交付实时或近实时信息以及对服务的访问。人工智能和机器学习很快将再次给IT带来革命性的变化。
721 +
722 +工作流自动化呈指数级增长。所有新技术代表着新机遇。
723 +
724 +
725 +==== 7.3.4.3 建立信息模型 ====
726 +
727 +所有组织都有现有的信息模型。了解它们是什么、它们的来源以及如何维护它们是任何IT和服务管理实施的关键部分。信息模型包含有关数据模型之间关系的信息。
728 +
729 +
730 +**定义：信息模型**
731 +
732 +与分类法和数据与其他数据的关系有关的信息结构，需要以有意义且具有代表性的方式呈现和共享内容。
733 +
734 +
735 +商业IT和服务管理信息系统还将具有需要填充的数据和信息的预定义分类。信息建模是任何实施的基础，并且需要作为持续改进的一部分进行重新审视。
736 +
737 +组织的数据模型需要映射到IT和服务管理系统的数据模型。这种映射需要了解工具组织的本机方式并将其数据从一个表关联到另一个表。
738 +
739 +作为映射练习的一部分，并且在加载任何数据之前，重要的是通过询问以下内容来评估是否应使用数据：
740 +
741 +● 数据是否有明确的来源？什么或谁提供了此信息？
742 +
743 +● 必须整合多少个来源？是否有一个团队可以汇总和规范化来自这些来源的数据？
744 +
745 +● 数据是最新的吗？
746 +
747 +● 数据如何维护？
748 +
749 +● 数据当前稳定吗？经常变更吗？
750 +
751 +理想情况下，所需的信息可以从聚合和规范化数据的中心点获取。各个工具集都需要此核心信息；当需要更改时，代理降低了复杂性，并增加了信息的完整性。在可能的情况下，应该限制使用此数据所需的集成数量，以最大程度地减少各种系统升级期间对变更的管理和测试。
752 +
753 +重要的是避免在由外部源控制的IT和服务管理系统中手动更新数据。例如，如果用户的信息在系统中不正确，则应指导他们在确定的源系统中更新其信息。这样做可以安排自动更新，以几乎实时地维护此数据。如果允许手动更新，自动化将覆盖它们。通过自动更新源系统中的信息，可以最大程度地减少管理和维护的工作量。
754 +
755 +对数据的需求提出疑问可以帮助提高效率。例如，如果组织正在经历重大转型，则应评估对数据持续输入的需求。在填充数据并将其与其他数据关联之后，很难在不影响信息报告连续性的情况下进行更改。数据可以始终映射并保存卸载，直到识别出额外需求。
756 +
757 +在定义数据需求时，定义并记住目标是很重要的。为了帮助确定数据需求可以提出以下问题：
758 +
759 +● 信息如何组织和呈现？
760 +
761 +● 理想情况下，应该如何组织数据？
762 +
763 +● 信息是否传达给组织中的各个单位（团队，部门，领导者等）？
764 +
765 +● 模型是否准确并能反映当前的环境？
766 +
767 +● 是否需要合并，整理和分析来自其他工具集的数据？
768 +
769 +基础数据的更改可能非常昂贵。例如，假设一家公司对事件、问题、请求、配置项、变更、可用性和监控使用了自定义类别。该公司将发现很难比较和关联记录类型之间的数据。相反，应该利用共享的分类模型。例如，应该在定义了业务服务和IT服务的情况下生成服务目录。此信息将在配置管理数据库（CMDB）中建模，然后可以对服务建模应用程序和基础结构。该模型可用于可视化服务和组件的可用性。可以分析成本和服务的稳定性，因为可以通过共享分类模型轻松识别相关的事件、变更和问题。从自定义类别开始的公司将不得不做大量的工作来标准化分类。如此之多，以至于有些组织发现，从一个新的系统开始远比比修改他们现有的系统更容易。
770 +
771 +[[image:1639228426310-882.png]]
772 +
773 +
774 +== 7.4 总结 ==
775 +
776 +如果组织真正致力于采用一种专注于服务、价值和结果的工作方式，则它必须相应地设计其SVS。通过利用ITIL 指导原则并与组织的治理和战略保持一致，组织应该开发和配置其资源以支持价值共创。面向服务并保持这种定位本质上是具有挑战性的，但付出大量的努力是值得的。
深圳市艾拓先锋企业管理咨询有限公司