Polarion舍与得——主机厂与供应商的ASPICE博弈
来源 | 汽车ECU开发，汽车电子与软件
知圈 | 详聊polarion对Aspice16个过程域的梳理及开箱即用模版请见文章最后。
要不要求ASPICE？这是个问题
主机厂
拿到供应商提交上来的软件和100%通过率的测试报告，才跑几个功能就发现一堆明显的bug，发生甚么事了？难道是打开的方式不对？还是双方对“测试通过率”这个概念的理解不同？——既然理解不同就用行业里大家都懂的语言ASPICE沟通吧，“SYS.2系统需求里的验证准则是怎么定义的”、“SYS.5系统合规性测试中测试策略的要求都满足了么”……
供应商
小伙伴们通宵加班总算是在期限之内把软件交付给主机厂，就连频繁变更的需求都实现了，这下金主爸爸总该满意了吧。纳尼！？这封火药味十足的邮件在challenge什么？ASPICE？我们在合同里承诺过么？想要马儿跑就得给马儿吃草，系统需求和软件需求要分开、各种追溯性得建立链接、评审checklist都得用上……要做ASPICE都是实打实的工作量啊！销售，客户既然提到了ASPICE，我们是不是该向他们多收点钱啊？
主机厂
还要加钱？确定验证准则保证可测试性不是需求人员的本分么？保证所有功能在目标环境下正常运行不是开发人员的基本职责么？就算你们自己搞了ASPICE，找了技术背景不如自己靠着精通流程赚钱的咨询公司来评估，最终搞出那一堆文档真的能提升产品质量么？是，合同里是没有写ASPICE，但IATF16949总得认吧，最新版本里明确了嵌入式开发需要配套的软件评估方法和质量保证流程，不用ASPICE的话，用的是哪一套呢？那家狼性文化的供应商过的就是ASPICE，还是三级！人家还用架构师来担当SQA来保证质量，你们的SQA有多少年开发经验？为啥别人能做到你们做不到？
供应商
这是纯属站着说话不腰疼，如果这合理的话，甲方的软件团队自己能做到么？己所不欲勿施于人，不是每家公司都适合狼性文化，这社会已经够卷了，还让不让年轻人留点希望了？！
……
以上关于主机厂与供应商的ASPICE博弈场景纯属虚构，做铺垫之用。现实中，甲方的主机厂与乙方供应商的博弈，在压力达到一定阈值的情况下甚至可能会陷入无休止的彼此指责之中，而这，恰恰与敏捷价值观之一的"客户合作高于合同谈判（Customer collaboration over contract negotiation）"背道而驰，这样的场景即使敏捷方法论大行其道各种工具链完整部署的今天依旧时有发生。那么在现实情况下，主机厂应当如何以ASPICE为依据提出要求才能最大程度的保证开发质量呢？而供应商，又应当以什么样的态度和投入来在满足主机厂的相关要求的同时确保交付呢？
这里从个人的观察，从产品、流程和技术三个维度，整理出以下三点思考，期望能对相关的行业同仁提供参考，或者抛砖引玉得到更精辟的见解：
-
产品维度：结果导向，统一准则
-
流程维度：质量驱动，迭代改进
-
技术维度：打通工具，实时协同
后续会从这三点出发，结合实例进行说明。
为啥要做ASPICE？
展开实施层面的讨论之前，还是让我们先弄清一个问题——为啥要做ASPICE？
省钱！省钱！还是为了省钱！
这也许和我们的感受相悖，做ASPICE需要投入更多的人力、产生更多的工作产品、花更多的钱，和省钱有啥子关系？不拐弯抹角，让我们直接打开ASPICE官方培训机构INTACS在Provisional Assessor官方培训资料里关于Motivation（驱动力、动机）的那两页PPT，看看官方是怎么说的——
在这一页里给出了统计数据，为了纠正一个典型的错误，在不同阶段所需消耗的成本，可见越在后面的阶段，成本越是成几何级数上升，最终得出结论：因此，应当在流程尽可能早的时候把缺陷修复掉！那么如何实现呢？让我们看看下一页：
翻译一下就是：
如果能做到
-
更早地发现缺陷
那么能实现
-
更少的系统性错误留在产品中
-
更精确的计划和估算
-
更可预测的组织绩效
-
更可重用的财富和知识/经验
-
更低的成本
通过重用国际化的流程经验，避免问题，实现这个（achieve this）。这里的this是单数而非复数，很明显指向上述一系列推导后果中的最后一项——更低的成本，说人话就是两个字——省钱！当然，这里的“省”的范围并不局限于单个项目，例如有可能在平台项目的前期预备中投入了大量人力物力却为后续的多机种项目节约了前期开发的成本，或是前期保证了文档的完整性可以大大降低未来人员离职后的系统维护成本等等，这就要根据具体情况具体分析了，会在后续的系列中讨论。回顾历史，在ISO9001刚刚成为行业标准还未普及之时，处境也许也和今天的ASPICE相似，当年的人也许也会问出“为啥要做ISO9001”“多出这些文档有什么意义”“没有这套标准我们照样能做好甚至做的更好”“哪里能省钱或者带来价值了”，而历史发展到ISO9001成为行业标准的今天，这类的问题都已经有了答案。日光之下无新事，也许，不久的将来，ASPICE中的问题都也会找到相似的答案。
这页PPT的最终目的是解释ASPICE的驱动力动机，于是就导出了标题中所说的为了达成这一美好的愿景我们需要更好的流程，然后就继续介绍ASPICE，展开培训的课程。当然如果是卖工具的，完全可以把process（流程）改成tools（工具），毫无违和感，因业务需要而异。（最后一句纯属个人理解）
这样看来，关于实施ASPICE，不要忘记初心——你，真的能省钱么？
关于“为啥要做ASPICE”讨论就到此为止，后面将要提到的“结果导向，统一准则”中的“结果”、“质量驱动，迭代改进”的“中驱动”，“打通工具，实时协同”中的“协同”，也都是是围绕这个Motivation服务的。
结果导向，统一准则
功能驱动开发下的品控三板斧
作为主机厂要验收供应商的成果物，checklist（检查表）是必不可少的验收标准，然而不同于硬件质量的精密严谨且已经发展多年相对成熟，软件质量的复杂多变带来了很多挑战。有的时候，完全按照checklist填写非但不一定能检查出问题反而或浪费实践（尤其当checklist是由“何不食肉糜”的理论专家定义出来的时候），后续根据新的问题添加了检查项却又导致不必要的工序影响交付工期。因而，以双方都能达成统一标准的“结果导向”进行实施非常重要，从形式上是要按照常规操作填满checklist，而操作层面上却要更加关注我们共通在乎的“结果导向”——产品质量。
十多年的软件质量职业经历中，见过不少checklist，检查项也是从几条到上千条不等，逐条确认固然必不可少，但只有建立自己的理解框架“把书读薄”才能提纲挈领地理解其中的精义。个人整理出来的框架是以下三条的“品控三板斧”，即：
-
做完了吗？
-
验过了吗？
-
改掉了吗？
如果用这个框架理解ASPICE，那么的三个问题又能对应各自不同的过程域。
例如“做完了吗”对应系统和软件过程域的左侧SYS.1-3、SWE.1-3，按层级拓展为类似如下的检查项，括号里的内容列举启发式的一些问题，仅供参考：
-
需求挖掘做完了吗？（除了客户需求，行业标准和相关法规考虑了吗？）
-
系统需求分析做完了吗？
-
功能性需求做完了吗？（跟甲方功能列表每一项都对得上吗？）
-
非功能性需求做完了吗？（系统工程师了解什么是非功能性需求吗？）
-
验证准则做完了吗？（测试人员能按照准则写用例吗）
-
-
系统架构设计做完了吗？（EA图里的接口都定义了吗？）
-
软件需求分析做完了吗？（真的做了还是把系统需求拷贝下来应付了事？）
-
软件架构设计做完了吗？（时序图是不是只写了启/停/睡/醒，没做维护？）
-
软件详细设计和单元构建做完了吗？（详细设计真的覆盖每个函数了吗？）
……
相应的，“验过了吗”对应系统和软件过程域的左侧SYS.4-5、SWE.4-6，按层级拓展为：
-
软件单元验证都验过了吗？
-
代码评审验过了吗？（Gerrit上的评审记录留下了吗？）
-
静态代码标准验过了吗？（按MISRA标准跑出的结果分析了吗？）
-
单元验证验过了吗？（语句覆盖率和分支覆盖率都100%了吗？）
-
-
软件集成和集成测试都验过了吗？（每个模块的接口都验证了吗？）
-
软件合格性测试都验过了吗？（是对应独立的软件需求而非系统需求写的吗？）
-
系统集成和集成测试都验过了吗？（能覆盖所有软硬件接口通信吗？）
-
系统合格性测试都验过了吗？（能覆盖所有的甲方功能列表吗？）
……
而“改掉了吗”则对应SUP支持内过程域过程域：
-
流程不符合项都改掉了吗？（SUP.1.BP5: 确保不符合项的解决。）
-
配置项的不合规都改掉了吗？（SUP.8.BP7：报告配置状态。）
-
高严重等级的缺陷都改掉了吗？（SUP.9.BP8: 跟踪问题直至关闭。）
-
需求变更都改掉了吗？（SUP.10.BP7: 跟踪变更请求直至关闭。）
……
仅仅列个框架，就能“文思泉涌”地写出一堆的检查项，然而在落地层面上真的可行么？尤其在产品快速迭代的市场环境下，即使再完善的checklist如果没有相应的资源和时间，最终下场也必然只是“形式主义”——开发人员复制粘贴“Pass（通过）”了事，别扯什么德国的严谨、日本的工匠、美国的专业——全世界都是一样的，缺钱缺时间的情况下品控流程肯定会打折扣。
那么有什么方式可以让品控流程真的做到提高产品质量呢？Jeff De Luca 给出的回答是 “功能驱动开发“，Feature-driven development (FDD)。
在 1997 年新加坡一家大型银行为期 15 个月、50 人的软件开发项目中，Jeff De Luca设计出了Feature-driven development (FDD)的方法论，聚焦于功能（Feature），主要包含一组五个流程，涵盖了整体模型的开发和功能的列出、规划、设计和构建。时至今日，FDD已经与Scrum、XP一样，成为敏捷的核心方法论之一。
也就是说，作为开发的甲乙双方，主机厂与供应商的聚焦点都应当在功能（Feature），在有限的时间内，把精力集中在Feature列表的计划、设计和构建上，双方对每个功能的DoD（完成的定义Definition of Done）明确定义且达成一致作为双方的共识。在定义DoD时，基于品控三板斧“做完了吗”“验过了吗”“改掉了吗”的框架，参考ASPICE中的原则可以定义出双方开发团队都认可的checklist作为验收准则。注意，该checklist不但乙方，甲方的开发团队也应当充分理解并在实践中使用。而需求分层、建立追溯等ASPICE相关要求的任务则在DoD明确的上，可以放在后续的迭代中细化。
总之，从产品的维度出发，主机厂与供应商在ASPICE的实施上结果导向、统一准则，双方只有把聚焦放在功能列表之上，对“做完了吗”“验过了吗”“改掉了吗”这三个问题都能达成共识进行功能驱动的开发，才能使ASPICE的落地对产品质量的提升提供价值。
质量驱动，迭代改进
质量驱动架构
在汽车中软件占比不断提升的今天，“软件定义汽车”早已成为共识，那么用什么来保证软件质量？行业或制定新的标准如针对网络安全的ISO21434、或IATF16949，对软件质量在特定领域提出了更严格、更具体的管控要求。
那诸多针对特定领域的行业标准如何融合落地？
ASPICE就成了兵家必争之地：功能安全需要它的追溯、信息安全需要它的设计、IATF16949需要它的体系，虽然实际落地考虑成本都有各自的算盘，但各家在口头上对ASPICE实施这件事上就没有谁会直截了当的说“不”。
ASPICE如此厚重如何在快速迭代的短周期开发中落地？
毕竟ASPICE在流程层面只提到了做什么，至于“怎么做则是由各企业的流程体系中定义的。为了满足快速开发快速迭代，那么“Agile”的开发方式自然就提上议事日程了，用敏捷的方式落地ASPICE，应该可以事半功倍吧？
用敏捷的方式如何落地ASPICE呢？
哪些过程域和实践可以裁剪、任务的优先级如何设定、如何在裁剪之后仍然能满足质量要求、工具链应当如何选取如何配置如何使用、取舍之下主机厂和供应商在哪些方面可以达成共识……，这一系列的问题并没有因为采取了敏捷得到解决，如果没有合适的方法论和扎实的落地能力，最终看到的也许只是一地鸡毛，什么敏捷，还不如按照原来的做法呢，至少还省掉了白折腾的时间。
有什么方法不白折腾就能部署一套适用的流程么？
很多厂商在一顿折腾后又回到了原点，没有丰富实践和方法论的流程咨询，别说ASPICE和敏捷，任何的流程改进都是空谈。而这也是当年为什么华为要斥巨资请IBM进行流程咨询，最终形成了以IPD为代表的一套体系流程实现组织的持续发展。
咨询公司靠谱么？
实际上并不是所有的厂商都如华为有如此财力、魄力引入咨询公司的流程体系自我革新，况且外来的流程体系还有“水土不服”的风险。咨询公司在流程体系方面固然可能很专业，但毕竟是外人，对本组织的技术细节和业务发展理解有限，就算有了深入理解合同期满也不再负责。因而即使请了咨询公司，内部也需要一个团队负责流程落地的责任。例如埃森哲针对汽车电子的开发，结合敏捷、ASPICE、功能安全、信息安全等标准和方法论定制出来AutoScrum，在流程部署上倒是面面俱到。
公司内部如何建立部署流程的咨询团队呢？
内部咨询团队不单要熟悉流程体系，而且也需要对本组织的技术细节和业务发展有深入理解，确保不是“纸上谈兵”，毕竟应付客户已经不易，再给工程师团队头上加个“大爷”（如下图），那比起“白折腾”更受不了。事实上，相对于重新建立一个团队，不如优化已有的团队——软件质量团队是最好的人选，首先他们得天独厚的熟悉流程体系、对具体的项目和工程团队的各个角色（项目经理、产品经理、架构师、程序员、测试组）都会每天打交道、因监管需要有权限查看各个项目资料，而且本来就是“大爷”之一了的QA经理，最关键的，是要让这个团队转型成为一个可以驱动组织变革的咨询性团队。
质量驱动，迭代改进
从价值观到方法论
阻力与困境
当质量人员聚在一起分享ASPICE推行的心得时，不可避免地会提及来自工程团队的各种阻力——
“客户合同里都没要求ASPICE，我们凭什么要做？”
“最近有人离职资源不足，老板让我们集中精力先把东西做出来。”
“最近实在太忙全员每天都在加班，等过段时间好些了一定把流程文档都给你补上！”
……
怎么办？看到晚上灯火通明办公室里加班的小伙伴们确实心下不忍，再加上工程团队或委婉拖延或强势拒绝的说辞，也不自觉地会怀疑自己的价值——
“我这样努力地推行的ASPICE真的有意义么？”
“如果真的有意义为什么大家会这样抵触？”
“既然大家都不想做为什么公司还要推行？”
事实上，作为质量人员面临各样的推诿拒绝是家常便饭，每个人也都有自己的应对之策，身处这类困境时作为个体的质量人员如何回归专业进一步树立对自己定位的信心，往往才是能“走下去”的关键。个人在十多年的软件质量工作中，在面对此类困境应用比较多的思维框架是ISO9001的7大质量管理原则。
理论与实践
ISO9001的7大质量管理原则列表如下，应当是每个质量人员都能达成的共识，也是我们非常熟悉的理论，而是否能将框架内化到质量思维中，则是只有经历过实际质量工作的困境才能深刻体会到的。
在软件质量领域，ASPICE在公司里的落地，本质上是属于“过程方法”，也就是7大质量管理原则的第4个，质量人员在思考为什么组织定义的过程方法为什么没能贯彻下去的时候，不可忽略的前提是“前三个原则”落实的怎样了？
1.客户为中心
2.领导力
3.全员参与
在7大原则中，这前3项原则处在价值观层的层面，而后4项原则属于方法论的范畴，而前3项的价值观，则是决定包含“过程方法”在内的后4项原则的方法论能够落实的前提。
如果“客户为中心”只是停留在销售对甲方的服务，关于代码质量、流程监管等的条款项目工程团队选择性忽略只顾着拿到需求往下做，那别提ASPICE，简单的确保测试覆盖率100%都得打折扣；
如果“领导力”中的总监们对ASPICE缺乏基本常识，把这个针对具体项目特定过程域的评估当成公司的认证进行宣传，那么让他们投入资源在项目中落地规范的难度可想而知 ；
如果“全员参与”达成的共识是流程文档都是给质量团队做的，那么应付式文档只能是常态。
所以，当一个过程方法推行的时候，如果遇到的主要阻力是关于“要不要做”的各种推诿拒绝，那么很明显是价值观层面出了问题；而如果遇到的主要阻力是“该怎么做”的各种具体难度，那么就应当在方法论上进行提升，将理论落地实践做好。
那么，如何判断一个组织对过程方法的推行是不是“动真格的”呢？根据个人经验，只要看看这个组织对质量团队的定位就知道了。
质量驱动，迭代改进
软件质量团队的定位之争
第一次听到ASPICE，是2008年在日本参加培训时一位同事进行的知识分享，当时对这个与CMMI很相似但是更加契合汽车电子开发的流程体系印象非常深刻。于是问了培训者一个问题，“我们会在开发过程中遵循ASPICE的方法么？“然而得到的回复是——”还不行，ASPICE还没有成为行业共识的标准，目前软件开发还是按照CMMI来做“。
时间一晃来到2022，历时将近14年之后的今天，汽车电子行业已经发生了天翻地覆的变化，而ASPICE也正在逐渐成为行业共识的标准。不知不觉中，焦点已经从“要不要做“变成了”怎么做“。
为了落地必须进行自上而下的推行，以及全员参与的落地，而ASPICE本身只定义了”What（做什么）”，关于解决“How（怎么做）“的定义符合组织实际的过程方法的问题，则需要一个专业团队来负责牵头。在大多数的组织里，软件质量团队就当仁不让地被分配成了这个牵头的角色，因而这个角色的定位也就代表了企业对于ASPICE推行的态度和成熟度。这并没有对错之分，而是根据实际情况所做的定制，而在这定位的过程中最关键的是回答以下两个问题——
-
归属：工程开发部门or独立质量部门？
-
路线：流程、产品or技术？
归属决定了这个团队的汇报对象和负责部门，而路线则决定了招什么人和做什么事。
归属之争
有人可能很自然地回答，有什么好争的，软件质量团队当然归属于独立的质量部门，若质量不独立则监管不给力。就像自己的代码自己测总找不出问题一样，如果监管流程的质量部门都归属工程团队了，发现了重大缺陷真的有权限叫停么？
也有人说，从知识体系和工作内容看软件质量团队都应当归属工程部门，脱离软件开发实践活动的质量人员就是个外行，最多能看看文档版本格式对不对，根本起不到发现实际问题的作用。
双方各执一词，而这也并不是一个非黑即白的问题，要回答这个问题，需要分别先看看质量部门与工程部门的组成。
先来看看质量部门。
汽车电子开发是一个复杂的系统工程，即使在质量部门内部，根据服务对象的差异、所处流程的不同，相关成员的知识体系和工作内容都有可能天差地别——
-
面向下游供应商的SQE（供应商质量工程师 Supplier Quality Engineer）
-
面向软件的SWQE（软件质量工程师 Software Quality Engineer）
-
面向项目的CAQE（客户前期质量工程师 Customer Advanced Quality Engineer）
-
面向产线的PQE（产品质量工程师 Product Quality Engineer）
-
面向上游客户的CQE（客户质量工程师 Customer Quality Engineer）
-
面向终端用户的WQE（质保质量工程师 Warranty Quality Engineer）
……
诚然，没有独立的授权，软件质量团队很难推行一套流程或者叫停一个行动，但确实也存在知识能力维度的局限。ASPICE的各个过程域无论是系统架构的搭建、软件中CICD的各种指标、测试覆盖率的确认、项目管理的协调等等，作为软件质量人员进行相关的检查都需要相当专业的知识，而这却又因为知识体系的差异不是其他质量团队可以提供的。
反观工程团队，从ASPICE过程域的分工看，项目经理PM负责MAN的管理类过程域，系统团队负责SYS相关PA、软件团队负责SWE相关、SUP/ACQ过程域除了SUP.1归属软件质量则由各部门协商出人负责，各司其职如有未定事项则有PM拍板。这样在知识维度上确实可以做到互补，同一个团队的软件质量人员可以更好与工程团队配合。但是，在这之下的一个问题是，质量人员的话语权能有多少呢？交付优先的原则之下，别说ASPICE就连交付前的release audit也很难保证独立性。
两难之下如何取舍，个人的观点是依据组织的实际情况进行规划。
对初创公司而言，质量管理注重的是“快”，更多关注快速响应而非完善步骤，多数情况下软件质量可能依附于工程部门存在。从流程模板编写、到审计流程评审代码、到搭建CI环境配置管理、到收集度量生成报告……有可能一个人就搞定，哪会像在大公司里那样“这块不归我管”，不懂就马上学上手干。当下国内造车新势力可能会比较适用该种情况。
公司中期突破瓶颈之时，质量管理的重心在“广”，随着业务的铺开各种技术难度之大涉猎之广，唯有依靠团队的力量才能突破瓶颈。质量人员不可能成为所有领域的技术专家，而要把控质量必须依靠数据指标，此时关注工程参数过于流程指标，而工程参数也需要抓到重点否则流于形式反而成为负担。此时，兼具技术能力和质量理论的专业团队就必须成型，而且要求相对的独立性，谋求转型的各大OEM、Tier1当属此类情况。
公司长期发展的远景规划中，质量管理则更加注重“稳”。例如当年华为斥巨资请IBM为其做流程咨询完善管理体制，是在其规模效应形成而关注长期发展之时所做的，此时质量部在完善流程体系之下独立运行可按部就班。“大企业病”可能会带来流程冗余的弊端引发工程人员的吐槽，质量人员也有可能因此怀疑自己的价值。因此“稳”就是非常可贵的品质，在坚持原则的同时需要保持一定的灵活性，这是有一定难度的。在该种情况下，质量部门无疑应当是作为独立且强势的部门存在的。
路线之辩
归属明确了，那要招什么人，做什么事呢？
如果你说要找个架构师到质量团队来验证质量，结果checklist的检查项全都是琐碎的确认文档格式、评审记录之类，那不是大材小用么？
一般情况下，软件质量团队的路线有三种：技术、产品、流程。个人观点也是根据实际情况进行区分——
初创公司，或者刚开始部署ASPICE的组织，应当重在技术路线。流程的部署是依赖工具链的，把时间花在填EXCEL做PPT上，不如踏踏实实的把工具链部署好——让程序员通过Jenkins中每天更新的dashboard看到自己注入的warning及时修改；让需求人员通过JIRA / Polarion同步各个功能的细节；让架构师的Enterprise Architect中使用的图例都符合规范……Linux操作系统的创始人Linus Torvalds有一句话“Talk is cheap. Show me the code”（空谈容易，给我代码！）。纵然不用自己写代码，质量人员对应该维持与代码的零距离状态。
中期转型公司则可以走产品路线，将质量需求作为Stakeholder Requirement的一部分写进product backlog里并且明确DoD，然后实打实地把它实现出来。
至于稳定的企业里质量部门当然是流程路线，无论工具链开发流程都已经相对成熟，就只需要专职的质量人员定期审计、培训、评估等等例行公事即可，当然，到了这个时候行业也走向稳定乃至下行了吧。
个人认为，在当下ASPICE标准本身还不完善行业趋势风起云涌之际，无论什么企业，都应当把姿态放低将自己作为一家初创公司带着好奇心走技术路线，认认真真把工具链落实好才是正道。
可以的话，老板们多花点钱招些有技术背景的质量人员吧。
打通工具，实时协同
从物理现象引申到团队合作，无论是产业链、供应链、工具链……任何的链条都适用于这个理论，链条上的最弱一环将可能导致满盘皆输的结局，这也是为什么“卡脖子”的策略能奏效的原因。
如果把主机厂和供应商当做供应链两端主体，那么在软件比重不断提升的今天，链接双方的环节的状态是怎么样的呢？也许是SQE收集到的乙方进度报告质量度量等的PPT，也许是工程团队的验收报告测试结果的EXCEL，又或许是DRE针对各种问题收到的分析报告……是的，这些都是根据流程定义的非常有意义的内容，但为什么总有缺了什么的感觉。甚至当主机厂收到了供应商最详尽的ASPICE评估报告，所有关键过程域都是三级，对于产品质量还是没底。
事实上，以上列举的报告、结果、评估，都是事后的滞后指标，而没有事前或实时的先导指标。
由于缺少实时性，双方的协同不可避免的会出现滞后，而这非常有可能引发链条的断裂风险，例如重大缺陷无法按时修复、物料不足等等等等，那么如何应对这个问题呢？
以色列学者伊利雅胡·高德拉特基于链条的原理曾提出限制理论，主张一个复杂的系统隐含着简单化。即使在任何时间，一个复杂的系统可能是由成千上万人和一系列设备所组成。但是只有非常少的变数或只有一个，称为限制，它会限制（或阻碍）此系统达到更高的目标。作为解决方法，以下是TOC的五步聚焦法的图例。
TOC应用比较广泛的是在机器工业领域，针对的也是流水线上的各个环节，切换到软件开发领域，流水线就成了工具链——项目管理的Jira、需求的Polarion、设计的EA、开发的Matlab、编译的Jenkins、测试的CANOE……而不是Office的PPT、Excel。
如果主机厂和供应商的链接是基于工具链进行互动，如双方PM针对Jira上的一个story跟踪状态、双方需求人员基于同一个Polarion里的工作项进行评审、双方程序员看到的是同一个Jenkins发出来的代码状态dashboard进行修复……是不是可以省掉修饰PPT排版、调整Excel格式、各种邮件飞来飞去的内耗呢？
——理想很丰满，现实很骨感。且不说双方的工具链是否统一、信息安全条例是否允许、领导层是否可以达成互信，就算万一真的排除了一切障碍真的达到了这样的互通，出了问题是不是能坐在一起共同解决而不是互相甩锅，还是个问号。
当然，这也许只是发展的问题，很多改革都是倒逼的，软件工程比起已经发展多年的机械工程还只属于发展的初期，现在我们看到的许多问题随着时间的发展用后世的眼光看也许根本不是问题，到时候“打通工具，实时协同”也许就是基本操作了，至于双方达成共识的依据是ASPICE或是其他的标准，那就交给时间来回答了。