化妆品行业的一个MES系统案例（三）

项目的主要需求如下：

　　　　(1) 管理产品的配方（物料BOM）

　　　　(2) 管理产品的生产工艺（最终要将工艺参数下发到设备PLC自动执行）

　　　　(3) 根据生产工单集合产品配方生成称量任务（其实领料之后的成料过程，这个行业对物料的精准度相对比较高一点，医药食品行业更高）, 这里的称量不是简单领料单，领料单是前置过程。

　　　　(4) 电子秤直接称量物料，确保物料的精准，有些物料精度要求 0.01g 范围。

　　　　(5) 称量的物料投入到设备中生成，要防止物料投错。

　　　　(6) 称量成品的产出，计算产出率。

　 以上的需求其实很简单，要求就三点。 但是细化起来工作还是听多的，我个人大致将这个项目功能区分了如下：

　　　　(1) 基础资料： 成品管理，半成品管理，原料管理，供应商管理，客户管理，计量单位管理

　　　　(2) 工艺配方： 设备管理，工序管理，产线管理，班组管理，配方版本，配方升级，工艺管理

　　　　(3) 生产管理：生产工单，排产任务，生产计划，生产排班，生产施工单，称量任务，返工管理

以上罗列的功能点是系统中比较重要的功能点，其他辅助新的功能就没有过多的提及，总之以上功能都是为了核心三要素。其中程序涉及到几部分：

　　　　(1) 系统所有服务API 程序： 所有的客户端程序都连接到这个API服务程序

　　　　(2) PC端BS版本系统：BS端系统可以直接人工走完整个设定的业务流程

　　　　(3) 称量客户端： 用于连接电子秤读取电子秤的称量数据，并且和系统对接

　　　　(4) 打印客户端： 系统中的打印分为单据打印，单据打印直接在BS系统中打印，如果涉及到标签的打印使用CS客户端，CS客户端可以和BS端交互。

　　　　(4) PDA 投料： PDA用于称量之后的复核，投料过程中物料的复核。

　　　　(5) PLC程序：本人不是特别懂PLC，用于大型设备电气化设备控制，包括纯水系统，污水处理，CIP清洗系统，原料罐，配料罐，乳化锅，各种管道阀门电机控制等。

　　　　(6) 对接PLC控制客户端： 用于将配方工艺参数下发到PLC上

　　　　(7) 设备监控程序：用于读取设备运行的参数信息

其实软件功能都好理解，从以上罗列的一些问题来看，其实对于做软件也是没有什么的，开发起来应该也不难。 真正有点难度的应该是设备的控制。对于很多开发人员来说，这种项目功能点其实是非常明确的，只要了解业务什么都可以做，其实真的是想当然。有了之前 吉特仓储管理系统 项目经验，我后面再也不会有这种想法，只要有技术什么项目都可以做。 到目前为止我是非常反感这种想法的，这个也是我我曾经的领导和我在思想上的差别，所以我们最终是走不到一起，他认为只要有技术造航母也是没有问题的。我却不认同这样的观念，一个项目的成败技术只能占到一部分因素，其中业务流程很重要，技术服务什么样的业务也都是有选择性的。

　　最初我并不了解这个行业，自从开始决定做这个事情之后，我首先要做的就是了解这个行业，于是参加各种化妆品展会，去接触各种做物联网项目的人员，去了解生产制造行业的特点，了解化妆品生产的主要过程。 其实渠道很多，在前几个月我参加了好几次化妆品行业的展会，各种工业设备展会，买过好一些关于化妆品生产的相关书籍阅读，了解化妆品成分中原料等相关特性，基本的生产流程。其实为了快速能够做项目这些只需要简单了解一下就可以，需要有一个直接感性的认识即可。  不过有一本书对我的启发很重要《BOM物料管理》 ，这本书是日本人写的，但是翻译的很烂，细心阅读还是能够给你很多的启发。

软件产品设计到开发，其实很快就完成了。其实也算不上完成，因为很多功能没有开发，但是基础的功能点，业务点都是串起来了，但是离实施使用还是有很大的差距，这也是我不得不面临的问题。其实好几次客户催促我都是这样应城别人的，我说软件已经开发好了，你们能不能用起来呢？你觉得你们自己能够将业务梳理起来，管理能够约束起来，那我软件就可以上，你们就可以用。其实这是一个双方协商和争取的过程，软件直接上肯定是用不起来的，除了软件的bug再就是业务流程的不匹配，再加上客户自己本身对这种事情没有太多的概念，这样就会出现一个叠加区可以为自己争取更多的开发时间。

目前该项目已经在四个工厂实施，但是所有的工厂都没有使用起来，但是也并不是完全没有使用，就是没有达到预期的目标，有很多地方没有衔接上，自己主要分析了一下不能达到预期目标的几个原因：

　　　　(1) 和其他系统做集成： 比如ERP，这个是我这个期间最头疼的问题，其实对接在技术上是没有任何难度的，这个对于做技术的人员来说都是小问题，在对接过程中主要出现双方步调不一致，两个供应商你想要让坐在一起协调问题这个很难很难，比协调产品经理和程序员之间的关系更难，双方都想将问题部分抛给对方，导致项目很难推进。

　　　　(2) 系统对接技术问题：系统对接问题其实是最简单的，当初我在设计此项目的时候，采用全API开放式模式就是为了方便其他系统的接入，在目前看来我有些异想天开，在和其他系统做对接的时候其他的系统根本无法对接API接口，他们必须使用数据库集成，而且应用程序要部署到和ERP同一台的服务器上，这就大大限制了系统的隔离性问题。我发布一个新版本程序还要考虑ERP等类似的系统的心情，万一服务器搞挂了整个厂区生产都要瘫痪，所以技术问题引起的项目问题着实让人头痛难以解决。

　　　　(3) 客户理不清楚自己的流程： 我可以明确的说绝大部分客户是理不清楚自己工厂内部的业务流程的，相关项目的负责人也就只能处理自己相关部门的业务，如果好一点的还能协调你处理其他部门的事情，如果不能那就只能你自己去慢慢摸索了。可能有人说客户必须要有人来负责这个事情，这个真的是理想情况，就算完全懂工厂所有业务流程的人他的级别也不肯能天天跟着你给你讲解他们工厂的业务。所以在这里一点就是：“ 你必须必比客户更加的专业(当然也很难做到)，而且你要能够梳理出客户所有的 业务流程并且将其串联起来，你是项目的管理推进者，而非客户让你干活的小弟，如果你只把自己当做一个干活的小弟这个项目基本就很难推进了”。

　　　　(4) 软件理论和实际应用的差别： 如果说是做手机APP，办公室等使用的CRM系统，OA系统等等这些还好，但是系统一旦到了应用操作层面这个事情就难办了，我给客户做了一个电子秤，从小车设计到程序开发现场安装调试，陪同使用培训等等。最初感觉是完美无缺，但是到了使用的过程中各种问题： 比如小车太重了，仓库的小姑娘推不动电子秤，电子秤的显示屏幕看不到读数，获取电子秤读数还需要去按确认按钮，扫描扫描不出来等等，网络信号屏蔽的问题，这远不是开发一个程序那么简单。

　　　　(5) 自身的能力问题： 其实最重要的还是自身的问题，自己还是没有去更深入的去了解现场情况，对业务的流程的设计还不够人性化，不够便捷，对于项目目标概念的把控还不能灵活自如，也许这里会提到什么项目管理问题，团队问题等等，在我觉得这都是在有完整的系统平台下考虑的事情，自己还是缺乏这种项目结构的组织能力，对项目完成目标设计还不够清晰，执行也不够坚决。

　　　　(6) 客户不使用无法发现问题： 这个我相信很多相关行业的人能够深有体会，我一个项目下来这种大型设备运转起来，客户不生产我永远不知道自己在控制方面出了哪些问题，设备上几千个阀门控制怎样算是正确？ 其实在理论模拟数据上可行到了实际生产过程又是另外一回事，客户不生产我们也不能无法第一时间发现问题，可能很多人说那就自己开机器自己运行。其实在设备运转的过程中缺少很多东西导致设备空运转也是没有任何意义的，比如缺少相关原料(我们一般使用水做测试)，没有工艺配方。 再就是8月份我们做车间设备调试的时候，那封闭的车间真叫一个热，客户说现在车间都没有生产起来，一个月电费都要几万，其实我内心也是比较担忧的，这种没有成效的测试只会导致资源的浪费。