日期：2022-01-15

“创业与守成孰难？”房玄龄曰：“草昧之初，与群雄并起角力而后臣之，创业难矣！”魏徵对曰：“自古帝王，莫不得之于艰难，失之于安逸，守成难矣！”上曰：“玄龄与吾共取天下，出百死，得一生，故知创业之难，征与吾共安天下，常恐骄奢生于富贵，祸乱生于所忽，故知守成之难，然创业之难，既已往矣；守成之难，方当与诸公慎之。”玄龄等拜曰：“陛下及此言，四海之福也。” -- 《资治通鉴·唐纪》

 

文章开篇引用了《资治通鉴·唐纪》里一段话，所想表达的是：导入MES系统不亚于创业。一个企业花费了巨资，组织大量人员参与，花费数月时间将MES系统成功导入，后期维护又是一个长期投入的过程。前面两篇文章已系统性分析了项目导入过程中管控要点、风险评估和导入方法，按照规划和目标有效落地，最终在工厂内部全面导入使用，顺其自然地进入使用期和维护期，接下来我们想分享给大家的内容是MES系统成功上线后如何维护？

 

“打江山容易，守江山难”，如何维护？怎样维护？为何要维护？维护工作量是不是如MES厂商吹嘘那般“我家的系统不需要维护，就算要维护那也是非常简单的”？

在讲解我们的维护经验之前，我先分享一下我在甲方作为MES实施顾问那段经历。2007年我跳槽到FL***X公司（美资企业，电子代工业），主要工作任务就是MES实施，当时我负责了五个项目，分别是法国Alcatel、以色列AudioCode、美国USR、美国Macafree、日本NEC。回顾这五个项目，实施过程中我个人感受是：赶，维护期给我感觉就是：琐碎。白班夜班时时刻刻都需要有人跟踪生产，修复BUG、培训新入职人员、数据维护、协助客户等等，其中涉及到人员有开发工程师、PE工程师、PMC工程师、仓管等等，中间有一个环节出现问题就会影响到整个团队推进节奏，比如当时我们的功能开发是由美国总部负责，用户提需求，实施顾问负责梳理需求，然后提交到美国IT总部，由于衔接的环节点太多，然后又有地域差异、文化差异，本来计划三天完成的任务，被活生生地延误了一个月，每次开会时实施顾问就变成批斗的“活靶子”，其根本原因就是：用户缺少自主权。

 

维护阶段所需关注要素有以下几点

 

要求一：团队建设

甲方有必要组建一支专业MES团队，主要任务就是日常维护工作，整理各种需求，帮助用户部门处理一些业务层面上的问题，确保WMS、MES等系统不会影响工厂正常运作，确保生产数据时效性、有效性、准确性，为企业战略规划提供可支撑数据依据，辅助工厂管理者领导。

团队核心成员：开发工程师、实施顾问、测试工程师、数据库维护专家。

要求二：人才储备

基于团队基础上，人才储备是非常有意义的一件事情，可确保MES团队生命力旺盛，从而能够更好服务工厂，针对不同岗位的人员储备的方式，我们更侧重于内部培养，老人带新人的方式，正如我们这个团队，是我们的前辈手把手教会了我们，在职业习惯、专业素养、技术特点、行业背景等方面系统化、正规化的培养。

经验之谈：建议实施顾问培养从老开发人员里挖掘培养，因为在实施过程中实施顾问与开发人员通常是对立面的，在推进项目过程中彼此互相解读、执行存有偏差，所以两者之间理解、消化过程是非常痛苦的，需要不停地调整。如果实施顾问懂得开发原理，则梳理需求时能够换位思考，并且能够制定出利于双方的可行性方案。所以我们公司在实施顾问培养这方面主要是从开发团队里挖掘人才，考核标准：逻辑思维能力、数学思维能力、表达能力、五年以上开放经验。

要求三：培训机制

无论在甲方还是在乙方，培训这份工作一直都没停歇过，针对不同项目、不同用户撰写了大量的培训资料，如员工操作手册、后台维护操作手册、二次开发手册等等，涉及到内容包罗万象。

面对一线用户：我们必须用最通俗易懂的文字将操作核心传达到位，关键点：易操作，傻瓜式；

面对维护人员：根据个人员部门特性，撰写有针对性培训操作资料，必须与其自身工作紧密相关，方便维护人员新增、修改、查询等日常基本操作，数据的导入导出便利操作；

面对二开人员：提供功能设计文档、数据字典、部分源码开源，培训二开人员解读MES产品框架设计思想和原理，遵循产品二次开发设计方法，对于拓展、调整等工作的训练和实施。

要求四：文档机制

从前期项目导入过程中所有文旦备案开始，到日常维护工作中所有操作都必须文档备案，如新增字段文档、新增功能文档、源代码备份文档、操作手册文档、权限手册文档、日志备份手册文档等等，必须一一备案，方便工作中任务交接和复盘追溯。

要求五：产品设计

在我看来关于维护工作能够做到怎样一个深度？主要取决于产品设计，一是产品底层框架设计，二是业务层可配置性设计。目前市面上几乎所有MES系统都自称可维护性灵活，并不需要乙方来支持，但实际情况并非如此，甲方在日后使用过程中维护工作（BUG修复、功能拓展、定制开发等等）都是离不开乙方，当然如果站在商家利益角度去考量，这不是非常过分的要求，收服务费提供售后服务，几乎绝大多数行业都是如此。

任何一事物都存有两面性，此刻我是站在甲方角度去考量这个问题，主要表达的观点是：我甲方可以花钱找你乙方提供售后服务，但这个不是必选项，甲方可以自己动手解决维护工作（BUG修复、功能拓展、定制开发等等），这个主动权应该是在我甲方手里，而非被你乙方给捆绑了，让甲方动弹不得。

首先谈谈产品底层框架设计，目前绝大多数MES厂家的产品设计就是两层：方法层和数据层，在方法层里包含了大量的定制开发，嵌套嵌套在嵌套，不知道封装了多少层，做过开发的人都知道，嵌套太多封装太多，时间一长了连自己都不知道哪是哪，直接蒙圈状态，查询代码极其浪费时间，时间就是人工成本和费用，所以根本没办法开放给到甲方开放人员，如果源码全部开放了，等于就是把乙方底裤给脱光了。

产品思维必须改变，有些MES厂家开始采用微服务的设计理念，通俗点解释就是化整为零，把产品核心封装好，至于与甲方需求相关的功能层的业务逻辑代码完全可以开放给甲方，这样甲方就不可能被乙方给“要挟”，甲方自由度和自主权就非常大了。

 

最后谈谈关于业务层可配置性设计，产品研发负责人必须要有规划、统筹思想，要将一些碎片式、零散式需求一点一滴收集起来，然后规划好范畴并设计出原型，功能迭代机制必须科学，在使用过程中需求肯定会越来越多，功能迭代是每个甲方、乙方开发人员绕不过去的一道关卡。

结束语

维护工作不能完全指望乙方，乙方不是万能的，站在商业角度，乙方就是为了赚钱，这个道理不过分。所以甲方在使用时维护工作必须由甲方自己承担起来，在我所遇到一些MES系统使用非常好的企业里都有自己独立的维护团队，哪怕这个团队只有一个人。当然作为乙方，除了从商业角度思考维护问题以外，还是应该要有一定的企业良心，能够包容尽可包容，此番话并非道德绑架，全看个人对人性和企业的理解了。

谢谢！！！