从关键技术自研到系统交付的组织转变

JED 2026年1月 Alexander Orellano访谈深读

一家强调内部研发的技术企业，为什么同时倡导开放架构，又与外部公司建立新的合作？如果把“自己做”理解为所有东西都关在内部，这几种主张似乎互相冲突。读完JED对Alexander Orellano的访谈，可以发现，它们涉及的是不同层次的能力与责任。

这篇2026年1月刊出的访谈，重点并非某台设备的性能，而是Rohde & Schwarz如何把信号与电磁技术积累，转化为可交付、可扩展并能长期支持的系统。[1] 本文沿着研发组织、制造和生命周期展开，区分受访者的战略主张与编辑的工程管理解读。

从一家公司的访谈中可以读出什么

原刊16—17页以JED提问、AO回答的形式呈现访谈，没有另列采访者署名。刊中介绍，Orellano于2023年9月加入Rohde & Schwarz，担任技术系统执行副总裁，此前在thyssenkrupp Marine Systems任首席运营官。这里保留的是本期提供的身份与经历，不把历史介绍当作任何时候的现任职务查询。

原刊介绍公司当时由测试与测量、技术系统、网络与网络安全三个部门组成。Orellano强调自己所在的企业首先是一家技术公司，其专长来自信号、电磁学与数据分析。这种自我定位解释了他为什么反复讨论跨业务积累，而不是只列举某一种防务应用的产品。

垂直整合强调的是关键知识的掌握

Orellano把垂直整合视为公司的重要特点，称内部覆盖设计、开发、集成、交付与支持等环节。值得注意的是，他随即限定了“关键”的含义：那些决定性能与差异化的技术和组件，并非一般通用品。这个限定比“完全自研”一类口号更有解释力。

因此，不能从访谈推导出公司不购买任何外部器件，也不能凭一句内部掌握关键技术，就确认全部供应链在任何条件下都不受外部影响。受访者要强调的是，对决定产品特性的知识具有较深的控制能力。通用物料供应与关键技术依赖属于不同的问题。

他回顾自己在潜艇与造船行业的经验时说，过去习惯通过外部伙伴优化价值链，加入公司后重新认识了内部能力的作用。这是个人管理经历中的观点变化，不是对所有行业外包模式的否定。不同产品的技术边界、产量和支持责任不同，组织方式也不必得到同一个答案。

编辑理解，掌握关键知识的实际价值，体现在遇到问题时能否解释原因、判断改动影响并决定下一步。若内部人员只知道如何采购和装配，却不了解关键部分为什么这样设计，后续改变往往仍要等待其他组织提供答案。内部能力可以减少某些等待，但不会自动消除所有协调成本。

反过来，更多自研也意味着企业要承担持续维护这部分知识的责任。工具、试验、人员和版本资料都需要投入，不能在首次产品交付后停止。访谈反复强调研发投资，与这种责任是一致的；它没有给出完整成本比较，因而不宜据此宣布垂直整合在任何规模下都更经济。

研发按技术组织之后仍要有人对系统负责

图1 编辑整理的责任关系。技术积累、应用集成与交付支持各有关注点，需要相互衔接；图中没有复原公司内部汇报层级。

这篇访谈最具体的组织信息，是2024年7月的一项调整。按Orellano的说法，公司此前围绕广播、电子情报和战术通信等应用领域设置各自研发团队，后来改为围绕核心技术聚合研发，让同一项专长更容易跨领域使用。时间点来自受访者，不是本文另行调查得出的组织变更记录。

他将其放在Evolve转型之下，并提到四个横向技术集群、应用分部、研发与销售之间的矩阵组织。原刊并未给出四个集群的名称或完整组织图，因此不能为了把图画得更像正式架构，就自行填入四个听起来合理的技术部门。

英文回答还解释了asset-based systems：由业务应用单元交付、围绕自身技术构建的系统。这里的asset应结合上下文理解为已有技术与产品能力，不能望文生义地把它解释为金融资产管理，也不能把“资产化”当作访谈提出的新商业计价模式。

共享技术团队的好处，是不同项目有机会使用同一套积累。但编辑认为，复用并不意味着应用责任可以一并取消。某项能力在哪些条件下已验证、换到新环境还需证明什么，仍然需要具体项目给出答案。共用部分减少重复劳动，差异部分则要求明确负责者。

Orellano强调清晰职责、标准化系统工程流程以及端到端负责，恰好回应了这一风险。矩阵图本身不能确保协作顺利：一个项目需要改变共用组件时，谁判断对其他项目的影响，谁维护后续版本，仍需在实际流程中落实。这里是对组织主张的工程管理展开，不是对公司内部运行状况的断言。

从广播积累到规模化制造的两种复用

受访者举出的技术例子，是广播业务积累的高功率放大器知识可以增强其他领域的能力。这个例子说明知识可以跨应用流动，并不表示原广播产品原封不动地装进另一套系统就能满足全部要求。原刊没有给出具体器件型号、改装路径或性能结果。

编辑理解，复用的对象可以是设计经验、工艺能力、试验方法或问题处理知识，而不必总是一块完全相同的硬件。若只用“同一个零件用了几次”衡量复用，就可能忽略这些不容易出现在物料表中的积累。相应地，声称共享知识，也需要能够说明新项目实际减少了什么重复工作。

英文原刊17页还有一段容易被忽略的回答：测试与测量部门习惯于比防务业务更大的生产规模，其面向规模化生产的优化，可以成为技术系统部门的资源。此前中文译稿没有保留这一整段，本文回到英文原刊补足。它把讨论从研发共享推进到了制造能力共享。

这两种复用并不相同。技术复用关心已有知识能否解决新问题，制造能力复用关心怎样稳定、重复地做出产品。一个样机已经验证某项功能，不代表生产安排已经可以支持更多交付；具备大批量生产经验，也不代表每种新系统都能立即达到相同产量。

访谈没有公布由此次组织调整带来的产量增幅、交期缩短或质量统计。因此，合适的结论是公司希望利用跨业务积累改善系统交付，而不是已经证明所有项目都获得同样收益。若以后评估这种转型，研发复用与制造交付应分别寻找证据，不能用一个宽泛的效率词概括。

十年以上的支持承诺需要怎样理解

Orellano提到，硬件可能每十年或十五年更新一次，客户则依赖企业提供覆盖完整生命周期的支持。这句话说的是他观察到的更新与支持关系，不是每个型号都具有同样寿命的技术保证，也不是客户可以无条件获得某个固定年限服务的合同条款。

从编辑角度看，长期支持首先要求组织保留理解原有设计的能力。器件、工具和人员都会变化，后来接手的人需要知道产品为何作出某种选择、哪些问题曾经出现、哪些更改会影响已有版本。仅保留最后一份图纸，往往不足以说明全部设计理由。

其次，持续演进与维持既有用户之间存在协调任务。新版本可以增加能力，但已经部署的系统可能依赖旧接口或特定配置。如何说明变更影响、安排兼容验证并交付维护资料，决定了软件更新究竟减少了用户负担，还是把更多理解成本转移给用户。

受访者认为深厚内部能力能够支持长期保障，这是可以理解的商业逻辑；但他关于只有这类公司才能真正保证支持的强烈措辞，仍是企业观点。合作伙伴体系也可能提供长期服务，最终应比较具体安排与履约记录。不能用组织形式本身替代对结果的检查。

软件定义与开放架构仍然离不开工程边界

图2 编辑绘制的三个问题。关键能力的内部掌握、系统接口的开放与合作伙伴提供的专长可以并存，不能只凭其中一项判断其余两项。

对行业未来的回答中，Orellano主张从硬件中心转向软件定义和数据驱动，并强调开放架构、人工智能与机器学习。他将这种变化与开发方式、政府和产业协作、软件及数据科学人才放在一起讨论，说明自己期待的是工作方式的变化，而不仅是给既有设备增加一个软件标签。

软件可以让部分功能更容易更新，却不能把所有物理约束一并消除。编辑在这里所说的边界很普通：可用硬件、接口和验证条件仍限定了什么改变能够被支持。文章没有给出可无限适应任何输入的具体实现，所以不能把愿景式表述写成已经具备的无条件能力。

开放架构也不等于所有内部知识都必须公开。企业可以保留核心设计，同时为外部连接提供明确的接口约定；反之，即使某些组件来自外部，整个系统也未必容易替换或扩展。垂直整合讨论能力放在哪里，开放架构讨论边界怎样连接，二者不天然构成反义词。

真正需要追问的是边界是否清楚：交换的数据含义是否一致，版本变化是否得到说明，接入另一部分之后由谁验证整体结果。这些是编辑解释，不是原刊已宣布采用某项具体开放标准。访谈没有列出接口标准清单，因此本文也不替它补上未经说明的合规标签。

受访者提出，传感器融合、AI/ML和开放架构可能是未来十年的重要变化。这里应保留“未来十年”的预测属性。把多种来源的信息放到同一幅显示图上，与确认这些信息对应同一个对象并具有一致可信度，是不同层次的问题；软件给出的综合结果仍需要数据与验证依据。

TRUMPF合作说明了自研与协作可以并存

访谈最后谈到未来五年的市场需求，把反无人机列为增长方向，并介绍与TRUMPF的合作。2025年10月22日双方公布的官方新闻稿确认了这一合作及其研发目标。[2] 日期早于本期，能够为访谈中的“最近宣布”提供明确的时间参照。

这份公告说的是结合双方专长开发和提供方案，不能单凭宣布合作，就认定某种完整系统已经完成验收或规模部署。本文只用公告核对合作关系和当时阶段，不引入本期之后的产品发布，也不把企业关于精度和附带影响的描述当作独立测试结论。

从组织视角看，这个例子与前面的垂直整合并不冲突。一家公司能够内部掌握若干决定产品特性的技术，同时在超出自身专长的部分寻找伙伴。关键在于怎样确定合作边界和共同交付责任，而不是给所有内部或外部工作作同一种价值判断。

原刊提到RF“暗”无人机，这是访谈特定讨论中的描述，不能泛化为任何方式都不可观察。本文关注能力互补和项目阶段，不据此推导方案能够覆盖所有情况。

更快的采购需要更明确的结果定义

Orellano还批评传统采购过程过于规定具体做法，难以跟上技术变化，建议更多关注速度、适应性与结果。这里包含一个值得单独讨论的转变：如果需求不再把每一步技术选择都写死，供应方就可能获得更多实现空间；但客户也需要更清楚地说明希望得到什么，以及怎样确认已经得到。

编辑理解，关注结果不意味着省去验证，也不意味着只看演示速度。一次演示、可以重复生产的版本和长期可支持的系统，分别回答不同问题。采购方若只缩短文件处理时间，却没有明确交付状态，双方仍可能对“已经完成”产生不同理解。这一分析只讨论项目管理，不评判某种具体采购程序。

访谈把这种转变与软件人才、政府和产业协作一起提出，说明流程与能力需要同时变化。团队若缺少理解软件版本和数据变化的人员，即使协议允许更快更新，也未必能够及时审查更新的影响。反过来，专业团队已经能够解释改变，仍需要组织给予明确的决定责任，才能让交流转化为实际交付。

评估转型最终要回到可观察的交付结果

将整篇访谈串起来，可以看到一个连续的组织问题：关键知识怎样积累，怎样被不同应用使用，又怎样经制造与支持工作交给客户。Orellano的回答把研发、业务和文化连接在一起，这比单独宣布增加AI或采用软件定义更具体，但离验证转型效果仍有一段距离。

对一般技术企业而言，可以从不同层次寻找结果。研发侧看共用能力是否减少重复解释和重复验证；交付侧看项目是否更容易获得需要的版本、生产和支持资源；用户侧看系统变化后是否仍能理解并使用已有功能。这些是编辑提出的观察方向，并非公司已经公布的绩效指标。

同样，缩短某个内部步骤不一定缩短整体交付。如果研发决策更快，问题却集中到集成、制造或后续维护，用户感受到的改善可能有限。受访者所强调的端到端负责，只有贯穿到这些环节，才可能让局部技术优势转化为稳定的系统价值。

这篇访谈值得保留的启发，是把讨论对象从单件产品扩展到产生和支持产品的组织。自研、开放与合作都可以成为方法，但需要各自明确的边界和证据。读者不必先接受所有市场判断，仍然可以从中提出一个扎实的问题：当需求发生变化时，谁能够理解变化、承担决定，并持续完成交付。

资料来源与说明

[1] JED Interview: Alexander Orellano. JED, January 2026, pp.16–17。受访者观点与刊内背景，未另署采访者姓名。

[2] Rohde & Schwarz与TRUMPF合作官方新闻稿，2025年10月22日。仅核对日期与研发阶段。

两幅图及标注的管理分析为编辑整理，非公司组织图或产品测评。