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

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

  把业务逻辑写在服务端的好处是，可以回滚（Rollback），例如同时处理20个IGBT模组（或25个晶圆）的TrackIn或EDC，如果第X个物料不成功，每一个物料都不会TrackIn。反之，写在客户端，只能一个一个的TrackIn，当第X个物料失败时，其他的处理起来就挺麻烦了。这也是一般MES都提供Dispatch Material和Dispatch Materials（有S代表多个）的原因。

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

  还有一个更现实的缘由是服务端的代码不好除错（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接口都是客制化的，例如FactoryWork用了著名的MBX（或是DMBX），部分用了TibcoRV。通常客户一定要使用厂商提供的DLL，才能和MES做沟通。一直到WebService开始流行的时候，大家才能够直接送XML格式的资料去和MES做沟通。但实际上，直接用WebAPI去和MES沟通的其实是很少的，没有人会花时间去建一个50个元素的Json（Json恶梦，其中80%的元素是Null），依然需要厂商提供库（.js,.DLL等）。

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

  我们一直在思考，如何要让研发人员的效率提高，让研发人员更不容易犯错，不断的优化接口是努力的方向之一。