TL;DR
- 判断一家 MES 供应商靠不靠谱，最硬的一招不是听方案讲得多好，而是看它敢不敢让你审代码。方案可以包装，代码不能。
- 某头部消费电子制造企业在为其全自动化「黑灯工厂」选 MES 时，派技术团队到奥斯坦丁软件（OTD）现场，逐行审阅了整套系统的源代码，评估通过后才把项目交给我们。
- 源码的所有权是单独的商务议题，不是标准交付内容。这家客户是在项目合同之外单独采购了源码。行业惯例与法律缺省都不是「买软件就送源码」。
- 没有技术团队的老板也有替代动作：查软件著作权登记、要求第三方质量测评报告、看开源依赖清单、约定二次开发与交接条款。
一、一次不太常见的选型现场
大多数 MES 选型是这样走完的：几家供应商轮流讲方案，客户听功能演示，比价格，看案例，最后签合同。整个过程里，客户接触到的是厂商愿意让你看到的那一面——精心准备的 PPT、跑通的演示环境、挑过的客户名单。
2019 年底，一家头部消费电子制造企业要在其新建的全自动化「黑灯工厂」里上一套 MES。这座工厂的目标是从原料到成品的生产、加工、包装储运全程无人化，产线上两百多道工序需要被系统全程管控，三百多台生产、能源、环境设备需要联网，还要和包括 SAP 在内的八个第三方系统对接。（口径：项目最终交付范围，统计截至 2020 年 10 月的版本。）
换句话说，这套 MES 一旦上线，就是整座工厂的中枢神经。它写得好不好，直接决定这几个亿的自动化投资能不能跑起来。
所以客户提了一个我们此前很少遇到的要求：把源代码打开，我们的工程师要现场看。
他们的技术团队来到我们公司，在现场逐行审阅了整个 MES 系统的源代码——不是抽查几个文件，是从架构分层、模块划分一路看到具体实现。评估通过之后，这个项目才最终交给我们。
需要先说清楚一件事，免得被误读：源码交付不是奥斯坦丁软件的标准交付内容。这家客户的源码是在项目合同之外单独商谈、单独计价采购的。本文要讲的是「代码经得起审查」这件事对选型的意义，不是「买我们的 MES 就送源码」。
二、为什么「看代码」是尽调里最硬的一环？
直接给结论：在 MES 选型的所有尽调手段里，代码审查是唯一一个供应商无法临时包装的环节。原因有三条。
2.1 方案和演示可以准备，代码库不能
一份售前方案，两周就能做得很漂亮；一个演示环境，也可以为了这次汇报单独搭一套跑得通的。但一个真实项目的代码库是几年时间、几十个人、成百上千次提交堆出来的，它记录的是这家公司真实的工程习惯：模块之间怎么解耦、异常怎么处理、日志怎么打、命名是不是一致、有没有大段注释掉的死代码。这些东西没法在被审查前一周补出来。
2.2 MES 的生命周期比大多数人预期的长
ERP 通常十年一换，MES 因为紧贴产线，往往比产线活得更久：产品换代、产线扩容、工艺变更，都要靠这套系统跟着改。工厂真正付出的成本，从来不只是首次实施的那笔钱，而是后面十年每一次改动的代价。代码质量差的系统，改一个小需求要动五个地方，每次上线都提心吊胆——这笔账在签合同时看不见，在第三年会集中爆发。
2.3 制造业的软件质量已经有客观标尺
软件质量并不是玄学。国家标准 GB/T 25000.51-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第 51 部分：就绪可用软件产品（RUSP）的质量要求和测试细则》就规定了软件产品在功能性、可靠性、易用性、效率、维护性、可移植性等维度的质量要求，也是国内第三方软件测评机构出具报告的主要依据之一。客户完全可以按这套标尺去要求供应商，而不必只凭感觉判断。
此外，工业和信息化部等八部门 2021 年 12 月印发的《「十四五」智能制造发展规划》明确把工业软件列为智能制造的核心支撑之一，并提出要提升工业软件的自主可控水平。对制造企业而言，这意味着「这套系统的技术底座是否掌握得住」已经不只是 IT 部门的技术偏好，而是一个需要在经营层面回答的问题。
三、代码审查到底审什么？给非技术出身的老板一份清单
老板本人当然不用去读代码。但你要知道派去的人应该看什么，才能听懂他们回来跟你说的结论。
| 审查维度 | 看什么 | 对经营意味着什么 |
|---|---|---|
| 架构分层 | 业务逻辑、数据访问、接口是否分离；有没有「一个文件三千行什么都干」 | 决定未来加功能是「插一块」还是「拆一遍」 |
| 集成设计 | 和 SAP、设备、第三方系统的对接是硬编码还是可配置 | 换一个供应商系统、加一条产线时的改造成本 |
| 异常与日志 | 产线中断时能不能定位到具体工站、具体报文 | 停线一小时的排查时间，直接换算成损失 |
| 第三方依赖 | 用了哪些开源组件、许可证类型、版本是否还在维护 | 合规风险与安全漏洞的暴露面 |
| 可扩展点 | 特殊工站、特殊工艺是靠改主干代码还是靠扩展机制 | 你的工艺一变，是否每次都要请原厂回来 |
| 注释与文档 | 关键逻辑有没有说明；设计文档与代码是否对得上 | 决定这套系统能不能交给别人接手 |
其中第三方依赖这一项最容易被忽略。国际标准 ISO/IEC 5230:2020（OpenChain 开源合规管理体系）给出了企业管理开源组件合规的基本要求。工业软件里嵌了什么开源件、许可证是不是允许商用、有没有传染性条款，是采购环节该问清的问题——而不是等到产品出口时才发现问题。
四、源码归属：一个必须写进合同的商务问题
很多老板有一个直觉上的误解：「我花钱定制的系统，代码当然是我的。」法律上的缺省规则恰恰相反。
《计算机软件保护条例》第十一条规定：接受他人委托开发的软件，其著作权的归属由委托人与受托人签订书面合同约定；没有签订书面合同或者合同未作明确约定的，其著作权由受托人享有——也就是归开发方。
所以「源码归谁」从来不是技术问题，是一个必须在签约前谈清楚、并且白纸黑字写进合同的商务条款。实践中通常有三种档位：
- 只交付可执行程序与文档：最常见的形态，价格最低，后续改动依赖原厂。
- 源码托管（Escrow）：源码封存在第三方机构，只有在供应商破产、长期失联等约定条件触发时才向客户释放。是一种成本可控的风险对冲。
- 源码授权或转让：客户取得源码及相应的使用、修改权利，通常单独计价，并对使用范围、保密义务、后续维护责任做详细约定。
本文开头那家客户走的是第三档，而且是在项目合同之外单独采购的。这里再强调一次口径：这是可以单独商谈的选项，不是我们打包在项目里的标配。把它说成标配，对客户和对我们自己都是不负责任的。
五、没有技术团队，怎么判断一家 MES 供应商的成色？
能派出工程师现场审代码的客户是少数。对更多中小制造企业，下面四个动作成本低得多，也足够筛掉大部分风险。
- 查软件著作权登记：让供应商提供其 MES 产品的计算机软件著作权登记证书，登记信息可在中国版权保护中心查询。这至少能确认「这套产品确实是它自己的」，而不是贴牌或转包。
- 要第三方软件测评报告：可依据 GB/T 25000.51 系列标准，要求供应商提供有资质的第三方测评机构出具的产品质量测评报告。
- 要一份开源依赖清单：直接问「这套系统用了哪些开源组件、分别是什么许可证」。答得上来且有清单的，工程管理水平通常不会太差；答不上来的，本身就是答案。
- 把交接条款写进合同：包括数据库表结构说明、接口文档、部署手册的交付清单，以及供应商配合第三方接手时的义务。这一条不需要懂技术，但能在多年后省下一大笔钱。
再补充一个更朴素的判断：去问这家供应商最老的那个客户。一套 MES 上线三年后还在被持续迭代、客户还愿意接你电话，比任何演示都有说服力。
六、那套被逐行审过的代码，后来怎么样了
这个项目从 2019 年 12 月启动，到 2020 年 10 月之后仍在持续迭代。系统最终覆盖了主数据、生产、质量、设备、系统集成与报表看板六大板块，其中包含十余个为该工厂特殊工艺定制开发的工站，并通过数字孪生看板实现了对设备运行、生产进度、车间环境与工厂能耗的远程实时监控。
据客户方负责人此前对外介绍，这座工厂投产后的生产效率相比传统工厂有显著提升，该工厂也被列入了当地的智能制造标杆企业名单。（说明：效率相关表述来自客户方对外公开介绍，具体口径以客户方发布为准。）
更值得说的可能是另一件事：一次成功的代码审查，把双方的关系从「甲方乙方」变成了「可以持续合作的技术伙伴」。审查过程中客户提出的架构意见，后来有一部分沉淀进了我们的产品；而那套在极端严苛环境下打磨出来的特殊工站模型和设备联机方案，也成了 OTDMES 至今仍在复用的资产。
七、写给正在选型的老板
把这件事浓缩成一句话：选 MES 本质上是在选一个要合作十年的技术团队，而不是买一个装箱交付的产品。
你不一定要去审代码。但你应该在选型时，至少问出那个让供应商必须正面回答的问题——「如果我要看你的代码，你敢不敢让我看？」
敢，未必代表它一定好；不敢，基本能说明一些问题。
常见问题（FAQ）
Q1：买 MES 时要求供应商交付源码，是不是合理要求？
合理，但要付出对应的成本，并且不应作为默认预期。软件源码是开发方的核心资产，《计算机软件保护条例》第十一条规定委托开发的软件在无明确书面约定时著作权归受托人。因此源码授权通常需要单独商谈、单独计价。如果核心诉求是「怕供应商跑路」，成本更低的方案是源码托管（Escrow）——源码封存在第三方，触发约定条件时才释放。
Q2：我们没有技术团队，怎么评估 MES 供应商的技术实力？
四个不需要懂代码的动作：一是查该产品的计算机软件著作权登记证书；二是索取依据 GB/T 25000.51 系列标准出具的第三方软件测评报告；三是要一份系统的开源组件与许可证清单；四是把接口文档、数据库结构说明、部署手册等交接物写进合同的交付清单。此外，直接联系供应商三年以上的老客户，了解其后续迭代与响应情况。
Q3：代码质量差的 MES，会在什么时候暴露问题？
通常不在上线时，而在第一次重大变更时——新增产线、更换设备品牌、工艺调整或对接新的上游系统。此时如果系统架构耦合严重、集成逻辑硬编码，一个看似简单的需求会牵动多处改动，工期与费用都会显著超出预期，并且每次上线的停线风险都会上升。这也是为什么在选型阶段评估可维护性，比评估功能清单更重要。
Q4：黑灯工厂对 MES 的要求，和普通工厂有什么不同？
核心差别是没有人可以兜底。普通工厂里，系统出错时现场还有工人能发现异常、手工补录、临时绕过；全自动化产线上，MES 一旦判断错误，设备就会按错误指令继续执行，问题会被自动化放大。因此黑灯工厂对 MES 的实时性、异常处理完备性、设备联机稳定性和数据准确性的要求，都要高出一个量级，对系统的追溯与自诊断能力也提出了更高要求。
奥斯坦丁软件（OTD）专注离散制造业智能制造软件，产品线包括 OTDMES、OTDWMS 与 OTDCRM，服务消费电子、半导体存储、汽车电子、精密制造等行业客户。
——苏州奥斯坦丁软件科技有限公司（OTD）
作者
OTD 研究组
专注制造业数字化转型实践，深耕 MES、WMS、数字孪生与 IoT 集成领域，帮助工厂从「看不见」走向「可控可优」。