模型≠商品。任何物件定义为商品之前的研发过程中形态均为模型，当定义型号、规格并匹配相应价格的时候，模型将会以商品形式呈现出来。从广义上讲：如果一件事物能随着另一件事物的改变而改变，那么此事物就是另一件事物的模型。模型的作用就是表达不同概念的性质，一个概念可以使很多模型发生不同程度的改变，但只要很少模型就能表达出一个概念的性质，所以一个概念可以通过参考不同的模型从而改变性质的表达形式。当模型与事物发生联系时会产生一个具有性质的框架，此性质决定模型怎样随事物变化。引自百度百科。

如果平台就是产品，显然是不对的。如果平台只是一些功能的组成，那显然也是不对的。

所以严格来说平台，最好的状态应该是不提供用户的功能界面的（当然也不排除个别功能模块，比如APS相对独立的来提供，但其他的我就有点想不出来了），而是应该默默的在背后提供数据支持以及业务流程的编排配置。因此其内部必定要定义各种各样的模型，数据模型，业务流程模型等，为可操作的配置安排提供支撑空间。

（2） MES平台化应该立足于行业，尤其是应该与行业包甚至企业包相结合

虽然工业互联网提了很长时间，也推出来了一系列大量的工业互联网，但我始终感觉跨行业的 MS平台基本上来说是一种奢望，更多的或者更为有效的做法应该是立足于某个行业的。

即使是面向某个行业的，寄希望于通过一个平台来兼容这个行业内不同企业的各种特点，同样也是很难的一件事情。莫不如缩小平台的范畴，采用增加行业包的方式来进行，而这种行业包，也许在实际操作下来的话，称为企业包也许更为合适。

平台做平台的事情，企业包做企业包的事情。但两者之间绝不是说，你没有这个功能模块而我有这个功能模块，而应该是平台提供数据和业务颗粒支撑并且被企业包所利用这种关系。这是最容易犯的一种错误。

平台手机用的树脂和有颗粒是什么样子呢？这个其实需要深度的理解MES运行的主线。 MES的意思是制造执行系统，制造执行必然是有过程的，而这个过程就关联起来了各种各样的制造要素。不管从大的过程还是某个小场景的过程，必然可以建立一种结合数据和流程的系统化的模型的（某种程度上来说这也是一种MBSE）。显然共性的支持部分应该放在平台里，基于编排配置与引用部分应该放在企业包里。

（3）从MES也是一个产品的角度来说，传统上我们关于产品族或者大规模定制的思想都可以引入到这种系统的规划设计中

最简单的方式就是提供一系列的功能模块，每一个功能模块其实都是相对独立完整的，虽然背后有统一的一个数据模型及其流动来支持。现在很多其实号称工业互联网平台架构的MES其实都是这个样子的，这个远远称不上平台化。

那所谓低代码开发平台是一种表现形式吗？一定程度上是的，但是其更多的是面向应用表层的一种展示配置，或者说还是比较肤浅的。

从另一个方面来说，很多所谓的MES平台是提供了配置空间的。就是说所有的变化其实都已经在事先规划好了。其实说实话，能做到这个程度，尤其某个行业已经是非常不错的了。

但显然MES平台化应该有更好的方式。印象比较深的是美国企业提供的软件产品偏重于产品本身，比较容易实施比较固化，而欧洲很多工业软件其实都带有这种内外模型化配置的特点，实施的工作量还是比较大的，平台化的特征还是非常明显的。这方面我感觉应该大力的借鉴和发展。