主题 6.6 — 供应商与服务集成管理（SIAM）

在一个由数十家供应商拼凑而成的卫生与照护资产中，你的患者和临床医生实际体验到的服务，只和供应商之间的接缝一样好——因此必须有人拥有没有任何单一合同描述过的端到端整体。

为什么这在卫生与照护中至关重要#

没有一家现代 NHS 信托机构或整合照护系统（ICS）只运行在一家供应商上。一个单一的临床工作流程——一次变成门诊预约、一封信、一份检查结果和一张处方的全科医生转诊——可能会穿越来自一家供应商的电子病历、来自另一家的集成引擎、来自第三家的托管平台、一个网络提供商、一项国家脊柱服务，以及由一个你从未谋面的第四方运行的托管服务台。每一部分的合同可能都是完善的。而患者所获得的服务，却生活在它们之间的缝隙里。

这是商业关系中运行和运营的一面，也是价值要么被实现、要么被悄悄失去的地方。采购和商业团队（参见主题 6.3——采购与商业事务）买得好、授出合同、移交一份已签署的协议；接下来数年发生的事情——供应商是否合作还是相互指责，一次中断是在一小时内修复还是拖延一周，你能否曾经离开——是供应商与服务集成管理的工作。做错了，这个失败就不是抽象的。一个悄悄丢失结果的病理接口、一份显示过时过敏信息的共享照护记录、一个在交接时把临床医生锁在外面的身份验证服务：这些都是从集成问题开始的患者安全事件（参见主题 1.6——临床安全与风险管理）。

利害关系被这个行业的三个特征所加剧。公共资金要求所购买的成果就是所交付的成果，服务信用和价值被积极追求，而不是被搁置不用。数据保护、临床安全和网络安全的法定责任必须流经整个供应链，包括你没有选择的分包商（参见主题 1.7——信息治理、数据保护与网络安全）。而关键服务集中到少数几家大型供应商身上，意味着一家供应商的勒索软件事件、破产，或产能失败，就能使整个地区下线。把供应商当作一个项目组合来管理——而不是一次一份合同——现在是一项韧性责任，而不是一项行政责任。

核心概念#

服务集成与管理（Service integration and management，SIAM）是一种协调多个服务提供者并将其整合以向业务方交付单一、端到端服务的管理方法。它之所以成为一门纪律，正是因为机构从单一主承包商转向了多方来源运营模式，然后才发现仍然需要有人让各个部分作为一个整体运作。SIAM 不是你购买的一个产品；它是一种有明确角色、流程和治理的运营模式。权威参考是 Scopism 的《SIAM 知识体系（SIAM Body of Knowledge）》，它与 ITIL 以及更广泛的 IT 服务管理（IT service management）（ITSM）实践并存，而不是取代它们。

一个 SIAM 模型有三层。客户方，或保留组织，保留那些永远不能外包的问责：战略、需求、架构、商业所有权，以及对患者的最终照护责任。服务集成商是这一层——一个内部团队、一个外部供应商，或一种混合形式——协调各提供者，拥有诸如重大事件管理这样的跨领域流程，并持有端到端的视图。服务提供者，常常被组织成服务塔（托管、终端用户计算、临床应用、网络），各自交付一个明确的部分。这些是 SIAM 的专业术语，而不是百科全书条目，因此这里用通俗语言命名它们，并以 SIAM 知识体系为依据。

在这之下是商业机制。外包（Outsourcing）及其数据和流程变体业务流程外包（Business process outsourcing）描述的是把工作委托给一个外部提供者；托管服务（Managed services）描述的是代表你持续地、以订阅方式运营系统。绩效由一份服务水平协议（Service-level agreement）（SLA）——一项可衡量的、通常具有合同约束力的承诺——来治理，越来越多地由一份体验水平协议（XLA）来补充，它衡量的是用户实际体验到的成果，而不是供应商方便达成的组件指标。XLA 还没有一个成熟的百科全书条目；把它当作一种新兴实践，而不是一个标准。

两个风险概念构成了本主题的框架。第三方管理（Third-party management）是监督外部提供者、以及至关重要的、它们自身分包商——深藏在供应链（Supply chain）中的第四方——的纪律。供应链风险管理（Supply chain risk management）应对通过那条链传播的失败，而借自银行业的术语集中度风险（Concentration risk）则捕捉了过度依赖单一供应商、平台或地区的危险。管理这些，正是防止一个方便的采购决定变成一个系统性脆弱点的关键。最后，避免供应商锁定（Vendor lock-in）和推动持续改进（Continual improvement process），是防止一项实时服务僵化的两项前瞻性责任。

最佳实践#

1. 指明端到端服务的问责所有者，而不仅仅是每份合同的所有者。 多方来源的决定性失败，是每个人都拥有一个方框，却没有人拥有它们之间的箭头。建立一个保留组织角色——常常是一位服务集成负责人或一个供应商管理办公室——对用户所体验到的整个临床或业务服务负责，拥有召集供应商和进行仲裁的权力。这位所有者持有端到端的 SLA，即使没有任何单一供应商能做到，也是董事会能够询问"为什么转诊系统宕机了六个小时？"并得到一个答案、而不是一轮互相推诿的那个人。

2. 有意识地选择并设计 SIAM 模型，然后把它写进合同。 及早决定服务集成商是内部的、外部的，还是混合的，并诚实地面对取舍：一个内部集成商保留控制权和知识，但要求稀缺的能力；一个外部集成商买来成熟度，但增加了一层需要治理的东西，如果它同时也运行一座服务塔，还会带来潜在的利益冲突。定义各服务塔、集成商拥有的跨领域流程，以及每个提供者的协作义务。至关重要的是，这些义务必须出现在每个提供者的合同中——合作的义务、参加集成商重大事件桥接会议的义务、共享数据的义务——因为一个供应商在运行时只会做它在中标时被购买去做的事（参见主题 6.3——采购与商业事务）。

3. 对你的供应商进行分类，把你的注意力花在重要的地方。 不是每一个供应商都值得同样的治理；把一个通用型许可证经销商当作一个战略性 EPR 伙伴来对待，会浪费精力，使重要的关系陷入资源匮乏。使用诸如 Kraljic 矩阵（Kraljic matrix）这样的分类模型，依据业务关键性和市场难度将供应商分为战略型、杠杆型、瓶颈型和通用型类别，并使治理节奏与分类相匹配——为战略伙伴举行季度高管业务审查，对通用型供应商进行轻触式绩效监测。这也是你把保证、关系投入和退出规划集中在那几家失败会真正造成伤害的供应商身上的方式。

4. 管理成果和体验，而不仅仅是组件指标。 一个供应商资产可能达到每一项单独的 SLA——99.9% 的服务器正常运行时间、在目标时间内关闭的工单——而临床医生实际的一天却很糟糕，路径端到端都是破损的。用体验水平协议和反映患者及员工实际体验的端到端衡量指标来补充组件 SLA，并警惕"西瓜式"报告：外表绿色、内里红色。在一项指标能被操纵达成的地方（关闭并重新打开工单、重新分类严重程度），重新设计它，使供应商的激励与你真正想要的成果对齐。

5. 在所有供应商之间运行一个统一的集成事件和问题流程。 当一次事件跨越多家供应商时，"旋转椅"问题——每家供应商都坚持故障在别处、而服务持续中断——是多方来源中最具破坏性的单一模式。给服务集成商宣布重大事件、把每一个相关提供者拉到一个桥接会议上、并且无论哪个供应商的组件出了问题都推动解决的权力，配以一条无过错的"先修复、后追责"规则。这反映了你的服务管理职能已经运行的内部 ITIL 纪律（参见主题 3.8——服务管理与实时运营），并将其扩展到合同边界之外，使一条供应链在危机中表现得像一个运营团队。

6. 把合同和绩效管理变成一门积极的、有证据支撑的纪律。 签署后被丢进抽屉的合同，是被放弃的金钱和杠杆。依据 SLA 举行结构化的绩效审查，跟踪并真正申领应得的服务信用，维护一份共享的风险和问题登记册，并保留一份在续约或纠纷时会有影响的、可审计的绩效记录。服务信用不是重点——它们是一种信号和一个杠杆；一段成熟的关系会利用持续的绩效不足来触发改进计划，并最终触发退出，而不仅仅是落实一笔小额返款（参见主题 6.4——治理与保证）。

7. 将临床安全、数据保护和网络责任一路流传到供应链底端。 你的法定责任不会止步于你的主供应商；它们必须触及托管数据的分包商，以及产品内部的开源库。要求依据相关标准流传临床安全责任、数据处理条款，以及与 NCSC 供应链指导对齐的网络控制措施，并要求对第四方的可见性，从而使你知道链条中真正的参与者是谁。明确评估集中度风险——如果你三项关键服务都位于同一个超大规模云提供商区域或同一个托管服务提供商之上，一次单一失败就会变成一次区域性中断，而缓解措施是一个董事会必须自觉做出的决定（参见主题 3.9——业务连续性与灾难恢复）。

8. 在你迫切需要退出之前就规划好退出。 确保你离开能力的最便宜的时机是在你签约之前；在你最需要它的那一刻，你所有的杠杆都已经没有了。为每一家关键供应商维护一份实时的退出计划，涵盖以开放、有文档记录的格式提取数据、知识转移、过渡支持义务，以及你在其他地方重新部署所需要的资产和许可证。真正的可移植性是被证明的，而不是被承诺的——测试你能否导出你的数据并在别处重新部署它，因为一份关于你以专有转储形式获得数据的合同权利，与能够使用它并不是一回事（参见主题 4.0——技术架构、云与遗留系统，关于在实践中避免供应商锁定（Vendor lock-in））。

与团队讨论的问题#

1. 当一次事件在凌晨两点跨越三家供应商时，谁有权让它们都像一个团队一样行动——每份合同都要求他们响应这个召唤吗？ 这很重要，因为旋转椅式失败不是一个技术缺口，而是一个权威缺口：供应商在捍卫自己的 SLA、转移责任时表现得理性，只有一个拥有合同支持的指定集成商能够推翻那种理性。诚实地辩论今天你的机构中是否存在这样一个角色，它是拥有真正的权威、还是仅仅是召集和恳求，以及你的提供者合同是否真正要求在共享的重大事件桥接会议上合作，还是仅仅鼓励它。考虑最困难的案例——一个跨越国家服务、托管提供商和应用供应商的故障，在最初一个小时里根本原因是真正模糊不清的。看看你是否运行一条无过错的"先恢复、后追责"规则，还是解决方案在商业团队争论责任归属时陷入停滞。一个好的答案会指明问责的集成商，指出强制合作的合同条款，并能描述一次近期的、这个模型确实发挥作用的跨供应商事件——或者坦率地承认上一次它没有发挥作用。

2. 我们真正无法承受突然失去的供应商有哪些——如果它们在某天早上失败了，我们实际上会怎么做？ 这迫使那场采购便利往往会掩埋的集中度风险对话：资产积累了对少数几个战略伙伴和一小撮平台的依赖，而总体的暴露程度很少被绘制出来，直到一次事件将其揭示出来。讨论哪些供应商是一项临床服务的单点故障，这种依赖是合同性的、技术性的，还是基于知识的，以及真正的风险深入第四方链条有多深——那个次级处理者、离岸支持团队、那一个超大规模云区域。诚实地权衡这个取舍：整合能带来效率、集成和更好的定价，而多样化则以成本换来韧性，正确的答案是一次有意识的董事会选择，而不是过去采购的一次意外。考虑你为这些供应商制定的退出和连续性计划是经过测试的，还是仅仅被写下来，以及如果一个供应商下周破产，你能否提取并重新托管你的数据。一个诚实的答案会区分你管理的供应商，与那几个其失败是一次生存事件的供应商，并展示后者的剩余风险已在正确的层面被有意识地接受。

3. 我们衡量的是我们的临床医生和患者所体验到的东西，还是仅仅是我们的供应商容易报告为绿色的东西？ 这个问题揭示了组件 SLA 和真实成果之间的缺口，即使每一个仪表板都是绿色的，多方来源服务也会在这里悄悄地令人失望。探讨"西瓜式"报告藏在你资产中的什么地方——那些单独达标却加起来变成一条破损路径的指标、通过要求用户重试而关闭的工单、在没有任何临床医生触碰的服务器上测量的正常运行时间。辩论你是否有任何真正的端到端或体验水平衡量指标、谁拥有它们，以及供应商是否被激励去追求你想要的成果，还是一个他们能够操纵的代理指标。考虑更丰富的、基于体验的衡量需要花钱和精力，并可能被那些信用依赖于旧指标的供应商所争议这一张力。一个有力的答案能指出至少一项反映用户现实的端到端衡量指标，解释它如何在各供应商之间被治理，并坦诚说明当前的 SLA 在哪些地方奖励了错误的行为，需要在下一个中断点重新谈判。

4. 谁应该运行我们的集成层——一个内部团队、一个外部供应商，还是一种混合形式——我们是否诚实地面对了那个选择所产生的利益冲突？ 服务集成商本身的自建或外购决定，常常是默认做出的，而不是有意识做出的，它塑造了随之而来的每一段关系。辩论真实的权衡：一个内部集成商把知识和控制权保留在保留组织内部，但要求稀缺、昂贵的能力，一家信托机构可能无法持有这些能力；一个外部集成商能够快速买来成熟度和工具，但增加了一层需要治理的东西，如果那同一个供应商也运行一座服务塔、实际上是在给自己批改作业，问题就会变得非常严重。考虑中间情形——一种混合模式，保留组织拥有问责和仲裁权，一个伙伴提供运营机制——以及你的机构是否有商业和技术上的资深地位去指导一个集成商、而不是被它牵着走。诚实地看看集成知识今天实际存在于何处，以及如果那个集成商的合同结束，你的端到端视图会发生什么。一个诚实的答案会指明谁在做集成，解释为什么这个模式是为你的情境选择的、而不是继承下来的，并能指出防止一个同时交付服务的集成商给自己打分的保障措施。

5. 我们对临床安全、数据保护和网络安全的法定责任，是否真的触及了深藏在链条中的第四方——还是止步于我们签约的主供应商？ 这很重要，因为对一次患者安全或数据泄露事件的问责不会跟随合同；即使故障发生在三层之下、在一个你从未选择过的次级处理者或离岸支持团队中，它也仍然留在保留组织身上。探讨你的流传条款是否真实且经过测试——依据相关标准的临床安全责任、数据处理条款和网络控制措施是否真正以合同形式强加于分包商，以及你是否对那些分包商是谁有任何可见性。讨论主供应商抵制以商业敏感为由暴露其供应链的张力，而你无法评估一个你看不见的风险，要求第四方透明可能会拖慢采购并缩小市场。考虑一个具体的失败——产品内部的开源库、托管分包商、第三方分析工具——以及那里发生的一次事件会发现你的义务是可执行的，还是仅仅是有抱负性质的。一个有力的答案会展示流传是被写明、有证据、偶尔被审计的，而不是被假设的，并能指明可见性目前在链条中哪个地方消失。

6. 合同一旦签署，谁在积极管理它——申领信用、推动改进，并让供应商对我们所购买的价值负责——而不是把它归档在抽屉里？ 多方来源中决定性的流失发生在中标之后，当采购部门的注意力转移，而没有人拥有价值被实现或悄悄流失的那些运行和运营年份。辩论你是否依据 SLA 举行结构化的绩效审查，你是否真正跟踪并申领你应得的服务信用，以及持续的绩效不足是触发一份改进计划，还是被简单地吸收了。考虑追讨信用可能会使一段你所依赖的关系变酸这一张力，而一种成熟的方法把信用当作改进的信号和杠杆、而不是一笔要落实的返款——但供应商很快会学会哪些客户从不检查。看看你是否维护一份在续约或纠纷时会有影响的、可审计的绩效记录，以及持续改进是一项合同期望，还是一次偶尔的恩惠。一个诚实的答案会描述谁拥有每一段战略关系，指出一个有证据支撑的绩效管理改变了供应商行为的近期案例，并坦率地承认合同在哪些地方无人管理、价值正在逐年流失。

实践中：一个卫生与照护案例#

Northmoor 整合照护系统运行着与其规模相符的典型数字资产：来自一家主要供应商的托管电子病历、来自另一家的共享照护记录平台、来自一位专家的集成引擎和接口层、来自 NHS England 的国家服务、来自一个网络提供商的连接，以及由一个系统集成商运营的托管服务台，其一线支持本身又被分包到离岸。每份合同都是在过去十年里分别采购的，每一份都有自己的 SLA，直到最近，每一份都由不同理事部门的不同经理管理。

问题在一个周一宣布了自己的存在。临床医生报告说，全科医生转诊到达急症信托机构时缺少附件，有时会延迟数小时。EPR 供应商报告 100% 的正常运行时间，并关闭了工单。集成供应商说它的引擎正在传递它收到的每一条消息。共享照护记录供应商说了同样的话。网络提供商显示没有故障。每个供应商都是绿色的；转诊路径正处于从琥珀色到红色的边缘；没有人拥有各个方框之间的箭头。九天里，患者一直在等待，工单不断被弹来弹去。

Northmoor 的回应是在保留组织内部建立一个服务集成职能，由一位供应商与服务管理主管领导，配有一个小团队，至关重要的是，获得了董事会授权的权力。他们首先对资产进行分类——EPR、共享照护记录和集成供应商被指定为战略型，网络提供商为瓶颈型供应商，许可证经销商为通用型——并设定一个与之匹配的治理节奏。然后，他们在每份战略合同的下一个中断条款到来时，重写附在其后的运营时间表，加入在三十分钟内加入集成商重大事件桥接会议、并在要求时共享诊断数据的义务。一项端到端的"转诊完整且按时送达"衡量指标被定义，并与组件 SLA 一起报告，由集成商拥有，而不是任何单一供应商。

六个月后迎来了考验，当时结果消息开始悄悄失败。这一次，集成商在一小时内宣布了一次重大事件，将所有三家战略供应商加上网络提供商召集到一个无过错规则下的桥接会议上，推动他们端到端地追踪这条消息。根本原因原来是集成供应商部署的一次字符编码变更，EPR 无法解析它——一个恰好存在于任何单一供应商都无法看到的接缝中的故障。它在四小时内被修复，一份联合问题记录捕获了这次修复，一笔服务信用被申领并重新投资于一套共享的回归测试套件。与此同时，该 ICS 悄悄注意到，所有三家战略供应商都托管在同一个云区域，将这项集中度风险记录在董事会保证框架上，并委托进行了一次经过测试的数据提取演练，这样如果它有朝一日需要迁移，可移植性就是被证明的，而不是被承诺的。

行业视角#

初创企业#

一家数字健康初创企业通常处于本主题的另一边——它是正在被集成的供应商，它的商业未来取决于在别人的 SIAM 模型中做一个好公民。赢得 NHS 的工作，越来越意味着要证明你会加入一次重大事件桥接会议、暴露你的次级处理者、流传临床安全和数据保护责任，并在退出时干净地归还数据，因此及早构建这些协作能力是一项竞争优势，而不是负担。在内部，一家初创企业也是关键第三方的消费者——它自己的云托管方、支付处理商和身份验证提供商——承受着真实的集中度风险，却几乎没有对比自己大得多的供应商的杠杆。能够规模化的纪律是保持依赖关系图谱的最新状态，在存在低成本切换选项的地方避免架构锁定，并对客户诚实说明你自己链条中的第四方。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院或居家照护机构、一家单点诊所——承担着与一家大型信托机构相同的临床安全、数据保护和网络安全法定责任，却在没有专职 IT 职能和很少合同杠杆的情况下管理着一堆供应商。在实践中，整套 SIAM 纪律会塌缩到一两个也在做其他工作的人身上，因此现实的做法是识别出一个临床日真正依赖的那两三家供应商——临床系统、连接性、共享记录链接——并有意识地管理这些关系，同时接受对其余部分的较轻触碰。集中度风险是尖锐且不可避免的：一个单一的诊所管理系统或一条宽带线路可能是一个彻底的单点故障，而缓解措施往往是运营性的（一个宕机程序、一个第二连接），而不是第二家供应商。退出和可移植性在这里同样重要，因为一家被锁定在专有记录中的小型提供者，能够迁移的权力更小，因此要向供应商施压询问的问题是以开放格式导出数据，以及合同结束后会发生什么。一家已过初创阶段的小型健康科技供应商面临着镜像问题：它必须满足其 NHS 客户现在所要求的合作、流传和退出义务，却没有一家更大的供应商所拥有的合规团队。

大型机构#

一家大型信托机构、一个提供者协作体，或一个 ICS，是典型的 SIAM 客户：数十家供应商、一个由历次采购组装而成的长期资产，以及没有人完全拥有其端到端行为的服务。现实的目标是一个正常运作的保留组织，配有真正的服务集成能力、供应商分类使注意力流向那少数几个战略型供应商，以及跨越合同边界发挥作用的跨领域事件和问题管理——而不是一个 SLA 完美对齐的幻想。最困难的工作是合同性和文化性的：在中断条款允许的情况下，将协作义务补装进遗留协议，并使供应商从捍卫自己的方框转向拥有其在整体中的一份责任。在这种规模上，最大的韧性收益来自绘制整个项目组合中的集中度风险，并为那几家失败会成为一次区域性事件的供应商测试退出方案。

政府#

一个国家机构——NHS England、一个权力下放的卫生部门，或一个诸如 Crown Commercial Service 这样的框架运营方——塑造着每一家信托机构管理其供应商所处的环境。它的杠杆是通过 Government Commercial Function 的 Sourcing Playbook 和标准条款设定期望，使合作、可移植性和供应链保证成为市场默认，而不是每个买家从弱势地位独自谈判的东西。政府还持有系统性视角：它能够看到——而单个信托机构无法看到——当一个单一供应商或平台已经变成整个系统的一个关键第三方时，它必须将这种集中度作为一个国家韧性事项来管理。它的职责是确保框架设计、保证制度和国家服务减少锁定和单点故障，而不是使其固化（参见主题 9.1——与地方和国家政府合作）。

常见失败模式#

• 问责真空。 每个供应商都拥有一个组件，没有人拥有端到端的服务，因此跨边界的问题无处安身。指明一位拥有真正权威的问责集成商。
• 旋转椅式事件。 供应商相互转移责任，服务持续中断，没有人被赋权使他们合作。在每份合同中强制要求一个单一的重大事件桥接会议和一条无过错的"先恢复"规则。
• 西瓜式 SLA。 每一项组件指标都是绿色的，而实际服务却是红色的；供应商依据指标报告，而不是依据成果。增加由集成商拥有的端到端和体验水平衡量指标。
• 一刀切的治理。 把一个通用型经销商和一个战略性 EPR 伙伴同等对待，会浪费精力，使重要的关系陷入资源匮乏。对供应商分类，使治理节奏与关键性相匹配。
• 抽屉里的合同。 签署之后没有人管理绩效、申领信用，或推动改进，因此价值逐年流失。运行积极的、有证据支撑的合同管理。
• 看不见的第四方。 义务被流传到主供应商就止步了，让未知的分包商持有数据或风险。要求供应链可见性并把控制流传到底端。
• 未受管理的集中度。 关键服务悄悄整合到一个供应商、平台或地区上，直到一次单一失败变成系统性事件。绘制并在董事会层面有意识地接受集中度风险。
• 理论上的退出。 一份从未被测试过的、关于你数据的合同权利不是可移植性。在你需要之前证明数据提取和重新托管。

成熟度模型#

检查清单#

• 一个具名的保留组织角色对端到端服务负责，持有端到端 SLA。
• SIAM 模型——集成商、服务塔、跨领域流程——已被定义并写入供应商合同。
• 供应商依据关键性被分类，治理节奏与每个分类相匹配。
• 端到端和体验水平衡量指标补充了组件 SLA，并由集成商拥有。
• 存在一个单一的跨供应商重大事件流程，合同强制要求一条无过错的"先恢复"规则。
• 合同绩效被积极审查，服务信用被跟踪和申领，改进计划被触发。
• 临床安全、数据保护和网络责任被流传到分包商，具备第四方可见性。
• 供应商、平台和地区之间的集中度风险已被绘制，并在董事会层面被有意识地接受。
• 每一家关键供应商都有一份实时的退出计划，涵盖数据、知识和过渡支持。
• 对于关键服务，数据提取和重新托管已被测试，而不仅仅是合同上的承诺。

关键资料来源#

• Scopism ——《SIAM 知识体系（SIAM Body of Knowledge）》和《SIAM 专业知识体系（SIAM Professional Body of Knowledge）》——服务集成与管理角色、结构和流程的权威开放参考。
• AXELOS ——《ITIL 4》—— SIAM 在供应商之间扩展的事件、问题、变更和供应商管理 IT 服务管理实践。
• UK Government Commercial Function ——《Sourcing Playbook》和《Outsourcing Playbook》——关于采购、合同管理和退出的公共部门指导。
• Crown Commercial Service ——公共部门技术和托管服务采购的框架协议和标准条款。
• National Cyber Security Centre（NCSC）——《供应链安全指导（Supply chain security guidance）》——评估和管理供应商及分包商之间的网络风险。
• HM Government / Cabinet Office ——关于管理公共服务中关键第三方和集中度风险的指导。
• NHS England ——临床安全标准 DCB0129/DCB0160 以及需要流传给供应商的数据处理要求。

参考文献#

1. Service integration and management — Wikipedia — https://en.wikipedia.org/wiki/Service_integration_and_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
4. Outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Outsourcing
5. Business process outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Business_process_outsourcing
6. Managed services — Wikipedia — https://en.wikipedia.org/wiki/Managed_services
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Third-party management — Wikipedia — https://en.wikipedia.org/wiki/Third-party_management
9. Supply chain — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain
10. Supply chain risk management — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_risk_management
11. Concentration risk — Wikipedia — https://en.wikipedia.org/wiki/Concentration_risk
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Continual improvement process — Wikipedia — https://en.wikipedia.org/wiki/Continual_improvement_process
14. Kraljic matrix — Wikipedia — https://en.wikipedia.org/wiki/Kraljic_matrix
15. Scopism — SIAM Body of Knowledge — https://www.scopism.com/
16. AXELOS — ITIL 4 — https://www.axelos.com/certifications/itil-service-management
17. UK Government Commercial Function — The Sourcing Playbook — GOV.UK — https://www.gov.uk/government/publications/the-sourcing-playbook
18. National Cyber Security Centre — Supply chain security guidance — NCSC — https://www.ncsc.gov.uk/collection/supply-chain-security
19. Crown Commercial Service — GOV.UK — https://www.gov.uk/government/organisations/crown-commercial-service