【原创】工程变更业务流程

工程变更请求可以从任何部门提出。
由设计部门自己提出的，是它自己发现错误或有待改进的情况。
而多数变更请求都是由销售、采购、服务、质量管理、生产等业务部门提出的。很多人认为变更请求是由设计部门提出的，其实这不符合实际情况。
由上面的业务流程图还可以看出，如果销售、采购、服务、质量管理、生产等业务部门不能使用PDM 的功能，ECR 的建立业务只能在设计部门完成，这个 PDM 是有缺陷的。
  
很多企业把 PDM 功能局限在设计部门。试想，生产等业务部门发现产品设计工艺有问题，怎么提出修改要求？他们只能打电话和设计部门联系。设计部门完成了修改，怎么通知业务部门完成工程变更导致的后续业务？
业务部门提出工程变更的合理的业务流程应该是从 ERP/PDM 系统中建立 ECR，然后在 ERP/PDM集成系统中由设计工艺部门完成 ECO。然后再由有关业务部门完成 ECO 的发布。
而 ECO 发布之后，还要导致完成很多业务操作的要求，也有必要使用工作流。
  
值得注意的是，上面的业务流程图并没有涉及 PDM/ERP 的具体实现方案。它是个原理性质的示意图。而采用具体软件实现的 PDM/ERP 系统，就可能在实现上述业务流程的功能上有很大区别。

有点儿PLM的原创概念的摸样，
不过国内能见到的PLM系统更多是用新的开发工具包装老的做的并不怎么样的PDM，
你老兄最好自己开发一套系统卖得了

grangran_2000 wrote:
有点儿PLM的原创概念的摸样，  
  不过国内能见到的PLM系统更多是用新的开发工具包装老的做的并不怎么样的PDM，  
  你老兄最好自己开发一套系统卖得了

老兄说的话有点让人费解！！
我支持zhizhi斑竹的观点，在我公司我也是这样划分流程的！我将流程分为三个阶段，首先是内、外部信息反馈（主要是由于响应时间和级别不同，对于用户或供应商提出的外部信息反馈有一定的时间限制，要求在几个工作日内完成等。内部信息反馈可由任何部门提出！），经过提出信息反馈部门领导同意后启动变更请求，确定受影响范围，更改方式，更改部门，实施部门等，需要经过小组评审才能通过。最后在工程变更中具体实施更改并跟踪和总结！

自己开发并非没有可能。很早以前就搞过。只是考虑开发出一个软件和形成软件商品不同，后者需要很大的市场投入，眼下条件不具备。

支持，更改是最麻烦的事，要涉及到许多部门及许多系统，是系统集成中的一个重要内容。

老兄说的话有点让人费解！！  
我支持zhizhi斑竹的观点，在我公司我也是这样划分流程的！我将流程分为三个阶段，首先是内、外部信息反馈（主要是由于响应时间和级别不同，对于用户或供应商提出的外部信息反馈有一定的时间限制，要求在几个工作日内完成等。内部信息反馈可由任何部门提出！），经过提出信息反馈部门领导同意后启动变更请求，确定受影响范围，更改方式，更改部门，实施部门等，需要经过小组评审才能通过。最后在工程变更中具体实施更改并跟踪和总结！
  
解释一下：
楼主的观点我很赞同
在PLM的概念中是包含了该部分的，但见到的国内PLM软件产品以为各种原因没做到而已
现实应用中是否更改通常都是有工程人员触发，虽然需求来自不同业务部门
造成两次审批流程对工程人员显得有些增加工作量

mwd121：
归公司已经实施了相关产品吗？如果是的话，在国内至少算是领先那部分的了
能否详细介绍一下

推动PDM的发展。同行们
加入我的QQ： 1 3 4 7 5 2 9 7

上述业务流程已经在我们的软件中很好的实现了,在我们实施的某一家电子企业,ECR的提出不仅仅局限于企业内部个业务部门,而且已经扩张到供应链的各个企业.

zhizhi wrote:
自己开发并非没有可能。很早以前就搞过。只是考虑开发出一个软件和形成软件商品不同，后者需要很大的市场投入，眼下条件不具备。

  
本来其他软件已经实现的功能就没有必要自己再来一遍。只能说这是中国国内部分工程师自己的心态。比如说用算盘完成原子弹实验设计工作只能被当做某种极其特殊的年代才能发生的事情，在科学技术发展上没有什么作用，虽然这让人为之动容。国内的很多都是重复研究，就是如西方人说得：“重新发明轮子”（REINVENT THE WHEEL）。