5. 设定工作优先级和管理供应商
5.1 为什么我们要对工作优先级排序?
只要工作需求超出了在预期时间内能完成的产能，就会出现排队的情况。在理想情况下，组织的需求没有任何变化，并且拥有满足需求所需的适当质量和数量的资源。但现实里，组织经常需要应对产能固定但对服务的需求不断变化的问题。这种不平衡会产生排队或积压，所以要对这些工作项进行优先级排序。
优先级排序通常是一项与支持和软件开发工作相关的活动（例如，对事件记录进行优先级排序或对冲刺待办事项集合进行优先级排序），但它其实被广泛使用。
5.1.1 按工单管理工作
一张工单(ticket)是一份工作记录。在广泛采用数字系统之前，纸质表格是常见的通信媒介，位于工作流程的中心。这些表单通常用尺子，钢笔和打字机制作，复印分发，手工填写，并按照办文流程中放置在下一位雇员的物理收文盘中。尽管数据可能已经在某个时候输入进了电子系统，但是纸制单据本身就是数据（以及对数据的响应）发展的载体。
商业IT系统的出现和基于计算机的工作的规范化意味着用于信息捕获和传输的媒体发生了根本性的变化，但这并没有改变基本的工单流转过程。纸质表单上的数据字段成为由软件应用程序控制的数据库表。数据字段集合以熟悉的方式排列成表格，这些表格通过屏幕显示给用户。换言之，软件用户界面与纸质表单相呼应。
由于多种原因，数字表单是对有形表单系统的重大改进。数据传输是即时的，取代了公司内部信函通过实体邮政系统的耗时投递。通过控制输入字段内容，可以使数据更加一致。按钮和其他控件改善了自动化程度，并为用户提供了更好的引导。然而，设计的主要驱动因素可以说是数据本身：用户体验并非最初的考虑因素。
一段时间以来，包括IT服务管理在内的客户服务行业围绕表单上的数据操作以及这些表单在不同任务列表的流动，设计了支持结构和工作流实践。常见的负面影响包括：
- 酒店登记手续涉及前台员工冗长的打字时间
- 电话支持专员不得不在填写电子表单时暂停对话
- 客户被要求在若干表格中输入相同的详细信息，因为他们的特定要求需要各自的表格。
就像过去纸制表单常常被堆积在文件收纳箱中一样，电子表单通常会堆积在作业队列中。精益生产（支持敏捷和DevOps的工业理念）的核心原则之一，是作业队列的出现代表工作流的中断。精益，敏捷和DevOps非常注重于减少在制品数量的累积。因此，许多IT专业人员对队列都持否定态度。
必须认识到，工单代表一个离散的工作单元，以及预期寿命内的当前状态。忙碌的服务提供商同时执行许多任务和活动，因此记录和跟踪其工作的手段是至关重要的。没有这些手段，出现混乱状况、发生数据和信息丢失以及缺乏问责制的风险就很高；这些都会对组织的风险管理和总体治理产生重大影响。
因此，工单很重要。它们能用于划分优先级，将给定任务的当前状态传达给应该知道的人，并实现高价值行为。即便在工作完成之后，归档的工单记录仍然可以作为管理和分析报告的数据源提供其价值。
尽管如此，围绕工单累积的用户体验和行为可能会引起麻烦。工单本身不会导致排队：队列不是工单的基本属性。相反，队列现象是组织分配人员和其他资源来管理工单的结果。
最近，服务提供商实现从简单的表单数字化向更加明快的界面转变，淡化数据处理感。尽管系统仍进行数据的输入和记录保存，但这些以人性化方式呈现的工作内容和关联数据的新界面极大地增强了用户体验。
有效的服务设计不需要避免或消除工单，但确实需要工单的存在不会对用户体验产生显著影响。设计思维原则至关重要，它鼓励服务设计人员关注利益干系人的具体挑战并确定以用户为中心的解决方案。
5.1.2 优先级排序和需求管理
为了价值共创，同时最大限度地降低因未满足需求和闲置产能而产生的成本和风险，有必要对创建、交付和支持服务的工作进行优先级排序（图5.1）。因此，优先级排序是组织风险管理实践中的一种技术。
图5.1 需求变化及其对产能的影响
在较高层次上，如果需求产生时有闲置产能，那么就不需要对工作进行优先级排序；这项工作可以立即开始。但是，当需求超出产能时，组织可以选择管理需求，以实现队列最小化，从而避免对工作进行优先级排序。例如：
- 通过以下方式减少价值需求量的变化：
- 使用基于工作量的定价机制（例如，前十个服务请求的费率低于后十个）
- 使用基于需求发生时间的定价机制（例如，餐厅提供每周夜间服务折扣）
- 使用基于质量的定价机制（例如，商务舱机票的价格是经济舱机票的三倍）
- 改变客户对完成工作所需时长的期望（例如，上午11点后提出的请求将在下一个工作日完成）
- 减少纳入价值流或步骤的需求数量变化（例如，仅允许员工每季度提交一个更改其福利的请求）
- 增加在给定的时间内可以满足的需求数量；例如，通过：
- 使用自动化加速艰苦工作（以线性方式扩展的常见和重复性任务）的处理
- 增加团队规模或团队数量，以便并行完成更多工作
- 降低增加产能的成本或减少产能的成本；例如，通过：
- 使用弹性云平台迅速增加或减少可用的算力；
- 将人员配备需求外包给专业服务组织
- 使用左移技术转移需求或阻止需求被创造；例如，通过：
- 使用自助式知识库，使用户无需专业技能即可解决常见问题
- 使用与开发工具集成的自动化测试，减少部署前对单独的测试和验证资源的需求。
上述列举着重介绍了用于管理需求的常用方法，但是根据环境和复杂性，可能有更适用的。
5.1.3 如何确定工作的优先级
工作的优先级排序可以在不同的粒度级别上进行，对更广泛的系统有不同的影响，对用户或客户体验也有不同程度的影响。例如：
- 在价值流级别进行的优先级排序增加了管理用户或客户期望的需要，以保持他们的参与并定期提供状态更新。这是因为，从他们的角度来看，价值的实现正在被推迟。
- 在价值流步骤、行动或任务级别进行的优先级排序可能会在工作流程中产生约束。在价值流中等待稍后使用的资源可能持续闲置，或者在价值流的较早阶段可能会形成工作的累积（队列或待办事项列表）。这种现象通常称为“创建瓶颈”或“创建约束”。
优先级应该尽可能地由数据驱动，而不是情感驱动，并且它应该考虑影响需求和工作流的所有可用信息。
有许多不同的技术可以对工作进行优先级排序，以最小化队列和等待时间。这些技术可大致分为以下几类：
- 资源可用性或质量 优先级取决于完成工作所需资源的可用性。例如，如果一个基础设施支持团队有一名网络专家，每个网络支持案例都分配给他，那么只要网络专家被占用，团队就应该优先处理与网络无关的案例。
- 当前工作量负载 优先级由资源的当前工作量负载决定，前提是资源之间的质量没有差异或工作项的大小没有变化。例如，支持中心自动化可能会将来电或聊天分配给当前未与用户联系的支持专员，或分配给工作负荷较轻的专员。
- 存续时间 优先级由工作项的存续时间决定；例如：
- 先进先出 执行最早排入的等待项。
- 后进先出 执行最新排入的等待项。
- 持续时间 优先级由完成工作项所需的时间决定；例如，通过：
- 最快速项目优先 执行可以最快完成的项目
- 最耗时项目优先 执行需要最多时间的项目。
- 经济或财务因素 优先级由工作项目的货币收益和成本决定。例如，一个仅能够处理一个工作项目的组织可能会优先考虑那些经济收益最高的项目，例如那些收入最多，财务影响最大或投资回报最高的项目。
- 经济处罚 优先处理受经济处罚的工作项目，例如可减少监管罚款的合规性项目。
- 需求的来源或类型 优先处理有权获得更直接关注的工作项，如组织CIO的请求。通常，组织会设立多种服务级别协议（并相应定价）；例如，技术供应商和支持服务提供商可能会实现一个分级合作系统，在该系统中，银牌客户的优先级高于铜牌客户。
- 分流 优先级是由紧急程度决定的，它基于对延迟可能造成的影响的评估。例如，医生会优先治疗骨折而不是感冒。只有在解决了更紧急的需求时才考虑不太紧急的需求。组织应该用程序来补充这项技术，以确保低优先级工作不会无人值守。例如，当某些截止日期或阈值临近时，支持组织通常会提高开放支持问题的优先级。
重要的是要注意，优先级排序技术是特定于环境的。适用于一种环境或工作类型的技术可能不适用于另一种环境或工作类型。同时，将一组简单的共同目标应用在所有类型的工作的优先级排序上是很有用的。例如，以下各项的优先级排序：
- 持续改进机会 其优先级可以通过与其他项目相同的方式来确定，例如使用ROI估算。
- 事件 其优先级可以通过与开发待办事项列表项相同的方式确定（例如，使用经济效益/惩罚性估算）。
多种优先级排列技术同时运用也是很常见的。例如：
- 在延迟成本方法11中，优先排序考虑了时间推移的经济影响或惩罚。
- 在加权最短作业优先（WSJF）12方法中，优先排序考虑了延迟成本和工作持续时间。
一种常见的优先事件技术是考虑影响（经济因素）和紧迫性（时间因素）。应定期或随着更多工作进入系统而修订工作优先级；这种修订允许动态重新分配资源以管理队列。
5.1.4 全功能团队
全功能团队13是一种管理工作的方法，即各类专家或利益干系人在一个项目上共同工作，直到明显地表现出谁最有资格继续工作为止，这时其他人可以自由地转换到其他项目上14。
全功能团队是专家资源分层组织结构的替代方案，在全功能团队种，工作不断升级，直到各自达到适当的能力和权限级别。被全功能团队解决的分层结构的缺陷包括：
- 每层都有其自己的工作项队列，这会影响：
- 在制品总数
- 找到合适的专家来完成工作所需的时间
- 工作在不同层级间分配，可以从较低层分配到较高层，也可以反之。根据定义，升级工作的团队不具备完成工作的适当技能。这也可能意味着升级工作的团队可能没有收集到或者可能误解了完成工作所需的信息，这可能导致工作项被退回或升级到错误的组。例如，服务台专员可能会把用户无法打印文档的投诉判定为打印机故障，而实际上可能是网络中断导致的。
- 容易解决的案件可能会升级到更高的级别，从而导致那些本应该将精力集中在更困难的问题上的专家工作负荷过重。
- 全功能团队通过以下方法解决这些缺陷：
建立具有动态和灵活结构的跨职能、自组织的单体团队，以应对即将到来的工作
- 在很大程度上依赖团队内部和外部利益干系人之间的良好沟通与协作
- 专注于避免发生工作排队现象
- 鼓励所有团队成员发展和分享技能和经验
组织通常将全功能团队技术与适用于分层组织结构的技术混合使用。例如：
- 将工作项分配到某一个人，直到完成，即使该工作可以由全功能团队中的其他人来完成
- 在专家分层组中使用全功能团队来减少每个分层中的不良行为。
由于全功能团队具有自组织特性，无须确定明确的类别或类型。然而，也有来自真实组织的一些实例，包括：
- 调度型全功能团队 每天都会频繁地开会，审查新的工作，选择快速完成的项目，并验证是否为需要继续分配的工作做了准确的记录。
- 待办事项型全功能团队 根据产品或服务专家的需要，当需要其他专家组成员的输入时，定期或临时召集组建，从而避免了在团队和队列之间重新分配工作项时的延误。
- 随时支援全功能团队 团队种的专家要么持续可用，要么持续监控其他团队的活动，以便确定是否以及何时参与。
采用全功能团队方式可能面临挑战，可能需要审查并重新调整组织的许多做法，以支持新的工作方式。组织变革管理实践有助于平稳过渡，并通过管理变革中人的因素来确保获得持久的收益。常见的挑战包括：
- 有理由认为工作成本会增加，如果在工作流程的早期介入高技能的工作人员，可能会发生这种情况
- 从基于个人贡献的绩效评估模型（在动态和自组织的团队中，这通常很难描述或量化）转变为团队贡献，团队贡献可以在产出或结果层面进行监控
- 接受形成成功全功能团队所需的流动性和高度的协作
- 确保个人贡献者不会打扰讨论或主导决策过程
- 确保高层管理者的支持，以放松或暂停对僵化或约定俗成的流程、资金和政策的遵守。
如果工作（和工作流）的度量和报告显示收益大于预期或实际成本（例如减少了开发工作的完成时间），则可以减少这些担忧。
5.1.5 左移
左移是一个来自软件测试界的术语，现在也广泛应用在与IT和服务管理的其他领域。左移使得工作发生在更接近其源头的位置。价值流设计原则指出，高度相互依赖的任务应该组合起来，而不是作为一系列专门任务来执行。左移是改善工作流程，工作效率和有效性的综合方法，通过将工作交付移交给最佳团队或人员，缩短交货时间，解决时间，客户满意度和效率。在开发环境中，左移意味着将错误修复活动移至生命周期中较早的构建和测试团队。在支持环境中，则是将维修或解决问题的活动从更高级别的技术团队转移到一线通才团队。
在软件开发生命周期中，左移方法更为常见，第一步是收集需求，然后进行设计，开发，测试和支持。将左移方法应用于软件开发过程，需要在生命周期的早期进行测试。将软件测试放在更靠近收集需求的位置，可以减少在投产阶段发现的缺陷数量。因此，将显著降低解决这些缺陷的成本。研究表明，在生产过程中发现的缺陷修复成本远远高于在设计阶段发现的缺陷。
左移方法适用于许多管理实践，包括发布管理，部署管理，服务验证和测试，服务请求管理以及服务台。它提高了工作质量和执行速度，并减少了返工需要和成本。左移方法需要更多的知识和技能，因为实践者（或在某些情况下，用户）需要执行更广泛的任务。这还可能带来员工满意度的提高（除非额外的任务太具有挑战性，在这种情况下可能会对招聘产生影响）。将这些收益与拥有匹配人员能力的成本进行比较，就可以确定投资左移方法是否合理。
左移方法适用的场景并不局限在服务提供商内部。如果消费者有意愿并且能够获得必要的能力并承担执行任务的责任，也可以将任务转移到服务消费者。
在“左移”一词起源的软件测试中，测试不是在开发软件代码之后作为单独的任务组织的。相反，，从测试需求和设计开始，测试是作为软件开发的每个步骤的一个组成部分进行的。其中暗含了从测试人员到测试工作的转变。测试不再由测试专家执行，而是由多种实践角色执行。测试专家的角色转向确保其他人能够开展测试工作。
同样，信息安全也可以通过将信息安全任务嵌入到开发和运营的日常工作中来实现左移。这与将这些职责交给专业的信息安全官的传统方法形成了对比，信息安全官负责控制产品和服务是否符合要求。这通常被称为DevSecOps。
表格 5.1 建立左移方法
| 步骤 | 活动 |
| 识别左移的机会和目标 | 从多种渠道审查数据，包括：
|
| 明确改进的成本和收益 | 需要数据来支持商业案例并通过以下方式传达期望：
|
| 设定目标 | 根据工作类型和目标定义新的目标。例如：
|
| 设置改进点计划 | 活动包括：
|
| 随反馈不断进步 | 此步骤可以包括服务管理中的任意四个维度。例如：
|
| 审查结果 |
定期或在计划结束时，重要的是：
|
相同的原则可以应用于其他领域，例如：
- 可以重新组织一线，二线和三线支持的任务划分，以便一线服务人员能够管理更具挑战性的呼叫。
- 变更批准判断可以由博学的开发人员来决定，而不是由独立的变更咨询委员会来决定。
该方法包括审查反馈和测量，以评估当前的工作流，然后调整工作的组织和交付方式：将测试移近编码，在可能的情况下实现自动化，并将支持活动移近客户。
对于客户反馈意见差、项目频繁中断，并且需要缩短服务交付解决时间的组织，左移可以解决这些问题。表5.1概述了构建左移方法的关键步骤。
如果做得好，左移方法可以带来以下改进：
- 解决时间的缩短，可以提高消费者的生产效率，进而增加客户满意度
- 中断次数的减少，可以增加已完成的项目数
- 提供的自助服务界面，可以简化大量服务请求，并为常见故障提供相关且准确的解决方案，从而降低了每次事件的成本
- 团队成员可以执行的任务种类有所增加，从而提升了员工满意度和留任率
ITIL 故事:为什么我们需要对工作进行优先级排序？
因杜:我一直在为自行车租赁服务开发在线支付应用程序。但是，我还需要进行另一项工作。我需要业务部门的指导，告诉我应该优先考虑哪项计划
亨利: 目前，业务和监管要求超出了我们的能力，影响了我们完成工作的产能；我们根本无法满足当前的需求。在线支付应用程序的开发很重要，但是因杜的另一个计划能将我们的财务流程与政府监管的变化结合起来。必须优先考虑这一点，以确保公司不违反监管要求
雷尼: W我们可以举行全员会议来尝试找到解决产能问题的方案。全功能团队是一种很棒的解决问题的技术，它使一群人聚在一起，共同研究如何解决问题。
弗朗西斯:由于对电动自行车在线服务的需求持续增长，我没有足够的时间来管理客户的预订以及为我们的车队进行维修、保养和采购新自行车。我们越早获得在线支付应用程序越好。客户将能够自助服务，这意味着他们可以在线付费，从而释放了我的产能。
艾丽斯: 我在租车部门的团队可以在迅速为自行车提供手动预订流程。这将有助于释放Francis的产能，直到因杜完成在线支付应用程序为止。但是，我的团队无法无限期地进行这项工作，因为这很可能会影响我们维持汽车租赁客户获得当前高标准服务的能力。
5.2 商务和采购方面的考虑
服务提供者可以选择自己创建服务组件，或者从合作伙伴或供应商处获取。
重要的是要记住：
- 合作伙伴(partner)是向消费者提供产品和服务并与其消费者密切合作以实现共同目标和目的的组织。
- 供应商(supplier)是一个向消费者提供产品和服务，但与消费者没有共同目标的组织。
- “提供方(Vendor)”是一个通用术语，通常用于描述向客户销售产品或服务的任何组织。从服务消费者的角度来看，提供方可以是合作伙伴或供应商，也可以与服务消费者没有直接的服务关系。提供方还可以在某些领域成为合作伙伴，而在其他领域成为供应商，例如：
- 云服务提供方可以为消费者提供基础架构服务，但也可以与该消费者合作实施工具，使消费者能最大限度地利用这些服务。
- 客户服务提供方可以向消费者提供熟练的人员、工具和其他资源，但也可以与消费者合作进行营销活动，突出其客户服务的质量。
本节提出通用术语“服务组件（service components）”，可以涵盖人员、工具、信息或用于创建、交付或支持产品和服务的任何其他类型资源。本节提出术语“组织”来泛指服务的购买者或消费者，使用术语“提供方”来泛指服务的提供者。
组织仅使用其现有资源来创建产品和服务的情况越来越少，于是组织经常不得不决定是构建还是购买服务组件。这些决定应以数据和事实为依据，而不要依靠情绪、传言或未经证实的报道。为了应对日益复杂的决策，许多组织，特别是大型企业采用了正式的采购策略，其中考虑了以下因素：
- 组织当前和未来的采购需求
- 采购服务组件的当前成本和预估的未来成本（通常考虑总体拥有成本）
- 生态系统中的资源稀缺性
- 生态系统内竞争、供应商和客户的影响阻碍新供应商出现的壁垒，以及防止现有供应商倒闭的措施
- 从多家供应商处采购组件的成本和风险
这些考虑因素用于形成采购策略，以及关于如何采购每种类型的服务组件的相关计划和模型。
5.2.1 “建造与购买”的考虑
认识到以下因素引起的偏差或压力很重要：
- 熟悉工具的先前版本或工具供应商的产品和服务
- 在没有确认环境15差异的情况下，使用关于产品和服务的先前经验
- 强烈希望使用新工具或技能而仅因为它们是新的
- 供应商的积极销售战术
- 降低成本的压力，通常以质量为代价
使用现有资源构建服务组件在以下情况下效果更好：
- 服务组件严重依赖于组织及其业务的知识
- 客户对个性化产品、服务或体验的需求很高
- 生态系统是不稳定或随时随地变化的（例如，当客户在竞争对手之间切换时面临很少或没有成本时，提供方的业务模式正在快速变化，或产品或服务的使用不断发展16时）
- 服务组件在大众市场很少被采用
- 以对标准和政策的合规性为重中之重
- 服务供应商正在有计划地或通过收购或转换而迅速增长，这可能导致需求不一致或频繁变化。
在以下情况下，从合作伙伴和供应商那里购买（或以其他方式获得）服务组件很有效：
- 内部资源稀缺或在其他区域利用率很高
- 创建，操作和维护组件所需的技能或能力是高度专业化的，并且需要花费很多时间来构建（例如，大多数组织不制造自己的计算设备）
- 产品和服务的构建流程不成熟，需要开发和实施
- 组件或服务高度商品化
- 对服务组件的需求较低或有较大波动（例如季节性需求或罕见事态触发的需求）
- 服务组件不是策略品牌的核心，也不是服务提供者的竞争优势
- 创建服务组件是可预测且重复的工作
- 生态系统是稳定的，通常不会波动。
5.2.1.1 商品化
随着采用的技术不断增多，通常需要通过更高级的工具来更有效地管理技术17。例如：
- 随着数据中心的使用越来越普遍，以及计算能力的提高，出现了用于管理虚拟基础架构的虚拟化工具。
- 随着算力和存储成本的下降以及虚拟化工具的成熟，云计算模型（基础架构即服务）应运而生。
- 随着云计算模型的成熟，出现了其他云服务模型，例如平台即服务，软件即服务以及最近的功能即服务。
这意味着在考虑是否构建或购买服务组件时，重要的是要考虑当前的“商品化”水平和持续的行业趋势来促使该组件商品化。
这意味着，当考虑是否建立或购买服务组件时，重要的是考虑当前该组件的“商品化”水平和该组件正在进行的商品化的行业趋势。
5.2.1.2 定义服务组件的要求
在定义需求时，组织应反映所有相关利益干系人的需求。因此，对服务组件的要求应涵盖广泛的主题，并且不应局限于用户提出的具体功能需求。其他利益干系人可能提出的要求包括：
- 组件的可维护性和可支持性
- 提供方资源的地理位置
- 组织与提供方之间的文化契合
- 服务消耗成本（例如，内部所需的技能以及一段时间内的资金外流18）
- 与组织的业务，技术和信息架构保持一致
- 提供方的品牌和公众形象
- 提供方的可替代性
定义需求的常用方法是关注产品的技术（功能和非功能）特征或服务的技术质量。但是，通常最好使用结果来定义需求。例如，技术要求：
- 当描述为结果要求时，“使用电子邮件”可以用“与用户沟通”来表达
- 当描述为结果要求时，“提供签入和签出代码” 可以用“提供版本控制代码”来表达
定义服务组件需求的一项关键挑战是确定哪些功能是必不可少的，哪些功能仅仅是有益的。例如，在定义以下需求时：
- 事件管理工具，组织可能认为与公司电子邮件系统的集成是必不可少的，而与手机短信或文本消息系统的集成则仅仅是有益的
- 代码存储库工具，“签出”和“签入”的需求可能被认为是必不可少的，而在代码已更改时发送通知的功能可能被认为仅仅是有益的
- 定义需求并确定其优先级通常是一项复杂而费神的工作。MoSCoW方法是用于管理需求的一种简单的优先级排序技术。它依赖于所有相关利益干系人之间的合作，通常是磋商。因此，它允许利益干系人明确商定优先级顺序
MoSCoW的缩写代表：
- 必须（Must）具备的需求对成功至关重要
- 应该（Should）具备的需求对成功很重要，但不是必需的
- 可以（Could）具备的需求是合乎需要的，但不是重要或必要的
- 不需要（Won’t）需求对于成功是不必需的、不适当的或非关键的
该方法涵盖了不会被交付的需求。这很有用，因为列表通常填充了不必要的需求，例如无人需要的报告。这些需求增加了成本，却没有增加价值。
5.2.1.3 选择合适的供应商
在寻找供应商时，组织通常会公布服务或服务组件的需求，并邀请潜在的合作伙伴和供应商做出回应。根据需求或上下文，此活动可描述为：
- 报价请求单（RFQ），当定义了需求并确定优先级，同时组织需要以下信息时，可以使用此技术：
- 供应商如何满足要求
- 满足已公布的需求可能需要的成本
- 征求建议书（RFP），当问题或挑战陈述已明确表述，但服务组件的确切要求或规范不明确或可能更改时，使用此技术。供应商需要提供建议或可行的解决方案，明确收益、成果以及成本。
- 信息请求单（RFI），当需求不明确或不完整且需要外部协助来完善或添加需求时，可使用此技术，RFI之后通常是RFQ或RFP。
在某些情况下，组织在寻找合适的供应商时，可以让内部IT团队作为供应商参与进来。这种方法允许组织将内部IT与外部组织进行比较。但是，如果发生这种情况，重要的是：
- 认识到关系的差异，并确保不会将同事视为供应商
- 了解到内部IT运营模式与更广泛的组织具有相同的特征、优势、劣势、机会和威胁
- 在通常成本较高的内部资源与有共享知识和目标的更广泛组织的资源之间取得平衡。
理想情况下，供应商应反映组织的愿景、使命、道德和原则，从而最大程度地减少连个团队之间的摩擦和分歧。在许多情况下，供应商可以看作是组织品牌的延申。在整个选择过程中考虑并记住这一点至关重要。
ITIL 故事: “构建和采购”注意事项
弗朗西斯:我们的目标是每辆自行车都应该安全，可靠和舒适。自行车不一定要很快，但必须要有适应性。电动自行车必须具有良好的行驶距离，并且充电站必须尽可能地标准化。
我们考虑过自己生产自行车，但是由于时间太长、成本高得令人望而却步，我们购买了现成的自行车，以最大限度地降低成本，并确保自行车可供试驾。在出租之前，我已经做好了准备。
我们使用现成的GPS装置，该装置易于采购但是仅具有非常基本的功能。我们不希望使用第三方供应商的免费应用程序来收集数据，以防软件被撤消或供应商修改成本模型。我们计划开发自己的GPS地图软件。
5.2.2 采购模型和选择
采购模型是整体采购策略的组成部分。它描述了以下主题：
- 组织将在何种条件下采购服务组件或特定类型的组件
- 供应商的角色和职责
- 组织对提供方资源需求（满足情况）的监管程度
- 供应商评估准则，例如
- 服务水平、功用和保证
- 地理覆盖
- 交付时间
- 通用管理策略，例如：
- 付款条件
- 使用首选供应商和例外管理流程
- 使用RFI、RFQ或RFP技术
- 与供应商合作时的标准条款和条件
- 财务管理策略，例如：
- 服务组件付款的资本化
- 可接受的价格范围或定价模型
- 纳税申报
一个组织可能有许多采购模型，这些模型反映了以下因素：
- 业务线
- 预算责任制
- 服务组件的类型（例如，可能有一个模型用于资源承包商，一个模型用于采购计算设备，另一个模型用于采购基础设施，等等）
- 报告，审计和合规性需求。
选择特定的采购模型能够反映组织在管理、报告、审计上的准则，并确保在整个服务供应链中遵守组织的愿景、使命、道德和价值观。在每个业务条线上，模型的差异将对谁负责和谁执行产生重大影响。
特常见的采购模型包括：
- 内包：利用组织的现有资源来创建、交付和支持服务组件
- 外包：组织将交付特定输出、成果、功能或整个产品或服务的责任转移给供应商，例如：
- 使用本地数据中心供应商提供计算和存储资源
- 通过中介机构寻找公开职位的候选人或寻找承包商
外包模式可以根据供应商或其资源的位置进一步细分。在描述许多技术供应商或云计算服务提供商（基础设施即服务、软件即服务等）时，这种分类可能不适用，因为供应商资源的物理位置并不总是公开的。供应商位置分为三类：
- 在岸 供应商在同一国家/地区。
- 近岸 供应商位于不同的国家或大陆，但是时区差异很小（例如，英国组织使用欧洲大陆的供应商）。
- 离岸 供应商位于不同的国家或大陆，通常距离组织有几个时区（例如，美国组织使用印度的供应商）。
在外包工作时，将工作转移到供应商后剩余的组织资源称为“被保留组织”
ITIL 故事: 采购模型和选择
弗朗西斯:虽然我们本可以在网上买到更便宜的自行车，但我还是有意识地从当地一家自行车商店采购自行车。这种采购模型有助于确保实现我们的目标。购买前，我可以检查自行车的可靠性和安全性。该商店提供当日服务，这意味着如果需求持续增长，我可以迅速扩大我们的车队。我们还将与合作伙伴签订服务合同，以应对任何故障或安全问题方面的问题。
5.2.3 外包注意事项
许多组织决定将工作外包以降低短期运营成本，结果却发现自己受到了限制，无法改变业务模式，或者长期支出增加。
随着时间的推移，外包也可能导致更高的成本，因为组织可能必须承担更高的成本来扩大服务范围和管理可交付成果的质量。如果将工作发送到海外，也可能会产生差旅费。
对外包采取全面的做法有助于减少这些负面影响的可能性。必须考虑：
- 保留可能发送到海外的知识和技能是否重要
- 将工作转移到海外时会对企业风险管理产生什么影响：由此减轻，加剧或产生了哪些风险？
- 行业或工作范围是否支持外包
- 组织与供应商之间的文化或语言差异
- 外包工作时是否会增加以及将增加多少管理费用
ITIL 故事: 外包注意事项
索尔马兹:我们已向七个供应商发布了开发GPS地图软件的报价请求单（RFQ）。
因杜: 响应我们RFQ的供应商来自本地和全球。供应商的位置不是我们竞争性审查过程中的一个考虑因素，在我们的评估过程中，离岸供应商也没有处于不利地位。
亨利:当外包诸如软件开发之类的服务时，供应商的位置并不像其他服务那样重要，因为我们可以把测试和发布代码过程虚拟化。对于其他服务，例如现场支持，位置是一个显而易见的考虑因素。
因杜:我们确实必须考虑外包应用程序开发会带来哪些额外的管理开销和风险。重要的是，我们要对这些情况进行监控，以确保开发的成本和时间不会超过预期水平。
5.2.4 服务集成和管理
服务集成和管理是指组织在价值流中管理和集成多个供应商的方法。这对外包服务和供应商来说是一个新的挑战，以前，多个第三方供应商的端到端所有权和协调是由一个实体管理的。
可以使用不同的模型提供服务集成和管理，尽管外包产品和服务的交付由单个实体管理而不管供应商的数量如何的基本概念保持不变。
5.2.4.1 服务集成和管理模型
这个部分有四个主要模型（图5.2）。组织必须依据自己的情况考虑最佳模型，以便转变到更加协调的服务-供应商关系：由于多种因素，服务集成和管理的重要性日益提高：
- 保留服务集成，被保留组织管理所有供应商，并协调服务集成和管理功能本身
- 单一供应商，一个供应商提供所有服务以及服务集成和管理功能。
- 服务监管者，除了提供服务集成和管理功能，以及一个或多个交付功能之外，还管理其他供应商。
- 服务集成作为服务，由供应商提供服务集成和管理功能并管理所有其他供应商，即使该供应商未向组织提供任何服务。
由于多种因素，服务集成和管理的重要性日益提高：
- 供应商越来越专注于细分市场，这导致与单一的典型组织合作的供应商数量增加。
- 某些类型的服务组件的商品化意味着可以定期将供应商替换为其他供应商，以获取更好的定价或服务体验。
- 技术产品和服务的复杂性不断增加，意味着需要借助多个供应商来支持组织。
- 当一个组织选择一种服务集成和管理方法时，应将该方法视为战略决策，并将服务集成和管理合同与单个供应商合同分开进行招标。还需要一个明确的组织结构，以及适当的治理和管理模式。
图 5.2 服务集成模型
5.2.4.2 服务集成和管理注意事项
在决定是否采用集成服务和管理方法时，重要的是要考虑：
- 组织是否成熟并且有足够的能力在这样的模型中运行或工作
- 适用于衡量和激励的指标：
- 服务交付质量
- 需要多个供应商协调和协作的成果质量
- 供应商之间的透明度、协调和协作以及服务集成和管理功能
- 使用多个供应商时如何设计和度量服务级别协议的变化
- 服务级别协议将如何影响不同供应商的表现
- 如何激励供应商以使其与组织绩效保持一致（如果他们选择不这样做，将受到惩罚）
- 哪些供应商选择标准适用于此方法
- 服务是由单一供应商提供还是需要多个供应商协作提供
- 服务集成和管理的结果将如何改变服务管理实践，包括：
- 知识管理
- 事件管理
- 服务台
- 问题管理
- 变更管理
- 服务请求
ITIL 故事: 服务集成和管理
索尔马兹: 艾克苏与世界各地的众多合作伙伴合作。一些服务由全球合作伙伴提供；例如，我们的IT网络基础设施。其他服务，如我们的电动自行车故障排查服务，是专门针对蒙特勒分公司和我们的自行车租赁服务。为了支持我们的产品和服务，我们有责任有效协调和整合不同第三方所做的工作。
雷尼: 我们将为租用的自行车提供的服务之一是，如果自行车发生故障，我们将提供免费接送服务。为了使它有效运转，我们需要在IT网络（其提供方位于美国）、支持中心（从其在印度的办事处提供电话支持）、蒙特勒的故障小组（受理这些电话业务）和当地的拖车合作伙伴（负责收集自行车）之间进行协调。这些组织中的每一个对于服务的有效性都至关重要。我们需要确保供应商的地点、语言、时区和工作方式的任何差异都得到妥善管理，以便该服务可以平稳运行。
索尔马兹: 目前，艾克苏负责协调我们的供应商，使其成为“保留的服务集成商”。随着服务在其他地方的增长和扩展，我们将重新审视我们的服务集成模型，以确保它仍然适用。
5.3 总结
组织很少能够平衡好产能和需求，这导致工作排队或积压，从而增加了客户、用户和其他利益干系人不满意的风险。为了降低这种风险，组织通过各种各样的技术来管理需求或对各种类型的需求进行优先级排序。
组织在使用这些技术时应谨慎对待，并应用系统性思考和工作的指导原则，来评估这些技术对组织其他部分、客户、利益干系人，甚至对从需求到价值流的影响。
组织也可以求助于外部合作伙伴和供应商，以获得额外的能力，甚至转移交付输出、成果、职能或整个服务的责任。随着合作伙伴和供应商数量的增加，指导和协调外部活动的管理开销可能会急剧增加，通常需要专用的资源来集成、管理外部供应商，并使其与组织的产品和服务保持一致。