MES 不是一个部署完就不需要再开发的软件，特别是在精密加工行业，例如半导体。在工艺不断进步的时候，一个可以配合工艺改良，生产效率提升的 MES 才是一个企业成功的关键。当然，成熟的产品，已经可以提供很多现成的功能，但只适合一些需要快速投入生产，跟着领头羊的快速跟进者（也就是行业所说的 FastFollower），要是想要和头部企业进行竞争，那就要走一条不一样的道路，不能只是墨守成规。

MES 的开发是一个很有意思的课题，首先第一个要探讨的问题是，把业务逻辑写在客户端还是服务端 ？

首先差别到底是什么 ？

那为什么还有人在客户端写业务逻辑呢 ？

当年 FactoryWork 2.X 至 3.X的开发，服务端的代码是用 C 写的，但客户端则是用 VB6 写的。当时就有两个派系，欧美日系都是用 C 来开发的，而亚洲派系则是用 VB6  把业务逻辑写到客户端中。亚洲工厂往往比欧美工厂更快速的上线，因为 VB6 做为 RAD （Rapid Application Development，快速应用程式开发工具，低代码的祖先)是一个最佳的工具，WinForm 到今天依然阴魂不散的在 .NET 世界持续着。但是在实现复杂的逻辑和联动上，客户端的代码是很糟糕的，时常会出现物件的状态在没有做完业务逻辑之前就改变了。

还有一个更现实的原因就是服务端的代码不好除错（Debug），要一个不懂 Unix 的人去用 xdb ，我估计会要他老命。就算是现代不用 Unix 的 MES，例如Camstar，CM 等，要做 Remote Debuging 也不是一件容易的事（把 Visual Studio 挂到一个 Process 上），很多年轻的工程师是很难去接受的。

近年来，大部分客户端都是用 HTML5 + JavaScript/TypeScript 去实现的，这样其实让客户端的代码更加难写（说实话，网页端真心做不了太复杂的业务逻辑）。

一般上实施 MES 要有两组人，一组人做客户端（HTML5），一组人做业务逻辑 （Jave/Python/C#）。

这也是当年 FactoryWork 的用户，很多亚洲用户只用 VB6 的原因，不需要两组人，一组可以了 （其实我觉得是被系统整合商带偏的，VB6 的开发便宜，可以多赚一些）。

不管如何，MES 的开发和 EAP 有很大的关系。EAP 需要用到 MES 的不同接口才能代替人为的操作，把手动的事变自动了。

这里要探讨一下第二个问题，什么是好的 MES 接口 ？

早期的 MES 接口都是客制化的，例如 FactoryWork 用了著名的 MBX （或是 DMBX），部分用了 TibcoRV。通常客户一定要使用厂商提供的 DLL，才能和 MES 进行沟通。一直到 WebService 开始流行的时候，大家才能够直接送 XML 格式的资料去和 MES 进行沟通。但实际上，直接用 WebAPI 去和 MES 沟通的其实是很少的，没有人会花时间去建一个 50 个元素的 Json （Json 恶梦，其中 80%的元素是 Null），依然需要厂商提供库（.js, .DLL 等）。

以下是一些典型的 MES 接口的应用(如LoadMaterial和 CreateRecipe).

LoadMaterial：

复杂的接口

简单的接口

CreateRecipe：

复杂的接口

简单的接口

大家可以注意到好用的 MES 接口，一行就完成了，但是不好的 MES 接口需要客户写一堆的代码。在如今这个 “家家都有低代码平台“ 的年代，这更是一个很重要的选型考量指标。别意外，依然有厂商提供很难用的接口和使用方式。

我们一直在思考，如何提高开发人员的效率和操作准确率，其中，不断优化接口是我们努力的方向之一。

部分图片来源网络，如有侵权，联系删除。