制造业 ERP 10年从业小结 (不断更新中)

logi

复楼上朋友：
没有100%涵盖到所有的情况，只是处理“新”“旧”料的替换。部分替换，以及替换的优先级等没有考虑。正如我所述，这个确实是相当复杂的，但有好过没有，仅处理“新”“旧”料已经看到了很大成绩。

logi

另外我想继续续写一个新的章节，就是关于在实施当中碰到的实际问题的，目前整理的问题有以下几个，会慢慢补充。
1. 用户抗拒使用系统，觉得使用系统不但没有减少工作量，反而增加了工作量
2. 用户不断地提出更改系统的要求
3. 碰到系统确实无法处理的难点业务问题
4. 厂方管理混乱，如何推进ERP系统实施
5. 认为ERP项目是单纯的IT项目，应该由IT部门负责全盘的工作
6. ...

susan_huangyong

原帖由 logi 于 2010-2-26 18:38 发表
另外我想继续续写一个新的章节，就是关于在实施当中碰到的实际问题的，目前整理的问题有以下几个，会慢慢补充。
1. 用户抗拒使用系统，觉得使用系统不但没有减少工作量，反而增加了工作量
2. 用户不断地提出更改系统的要求
6. ...

真是说到心底里了，完全同意，深感痛苦、无奈，只恨才能不够

QIvan_lee

好文章，接触制造模块以经有一段时间了，
但好些地方理解得还不是很清楚～

moed

原帖由 logi 于 2009-4-28 22:19 发表
Part III: Alternative Part

1. 为什么会有替代料的概念？
在制造行业替代料是一个很普遍的问题。根据我的总结，出现替代料的情况至少有以下几种原因（但不限于）：
1)供应原因：供应商无法及时供应原定的物料，需要使用替代料
2)成本原因：替代料的成本与主料的成本不一致，根据市场需要决定用哪一种料
3)质量原因：替代料的质量与主料的质量不一致，根据市场需要决定用哪一种料
4)合规原因：在不同的地区，对某一物料的法规要求不一致，例如有铅无铅（RoHS）
5)清理旧料库存原因：某一旧的物料仍然可用，将旧料用完再用新料（一般在不影响产品功能的前提下）

2. 替代料处理的难点
在N年前曾在ITPUB上讨论过替代料的解决方案，但没有正解。现在看来很多的主流ERP产品仍然没有完善的解决方案。我们现在的公司是通过自己二次开发来解决的。那为什么处理替代料就那么难呢？个人认为其难点有以下几点：
1）替代关系：替代关系不仅仅是1对1的，还有多对多的，比如，我一个按钮需要配一个盖，这是一种组合（比如颜色的要求等）。那么当这个按钮有替代的时候，它的盖子也是需要一并替换的。绝大多数的ERP都处理不了这一点。
2）优先顺序：替代关系可能有多个，比如A既可由B替代，又可由C替代，等等
3）替代层迭：替代关系可能不止一层，可以有多层替代，例如A可由B替代，而B又可由C替代，等等
4）替代时机：替代时机的选择也是一个问题，有的替代是在主料没有库存的时候；有的替代是在旧料仍有库存的时候；有的替代是在主料的成本高于替代料的成本的时候；有的替代是取决于产品的销往地，例如销往欧洲的产品就必须是无铅的，但是销往非洲的仍然可以含铅，等等

3. 解决方案
在我目前的公司，我们通过自主的二次开发解决了多对多的旧新料（替代料）问题。通过设置替代料关系表，在MRP运算之后马上执行替代料计算，通过供需必须平衡的基本原则，将现有的生产工单和MRP产生的计划生产工单中的物料换成替代料（旧料），同时将采购订单和MRP产生的计划采购订单中的物料相应取消对等的数量。在这个功能上线之后至今，为公司节省了数十万美元（通过使用旧料，如果不将旧料用完，则非常可能变成呆料而必须报废）。

lida0207

原帖由 logi 于 2010-2-26 18:38 发表
另外我想继续续写一个新的章节，就是关于在实施当中碰到的实际问题的，目前整理的问题有以下几个，会慢慢补充。
1. 用户抗拒使用系统，觉得使用系统不但没有减少工作量，反而增加了工作量
2. 用户不断地提出更改系统的要求
3. 碰到系统确实无法处理的难点业务问题
4. 厂方管理混乱，如何推进ERP系统实施
5. 认为ERP项目是单纯的IT项目，应该由IT部门负责全盘的工作
6. ...

期待中

logi

Part IV: Implementation

讨论一下实施过程中的一些典型问题。
注：以下的几个问题的总结完全是基于个人经验，加上自我学习得来的一点体会，各人见仁见智，欢迎讨论。

1. 用户抗拒使用系统，觉得使用系统不但没有减少工作量，反而增加了工作量

首先上ERP系统是不是会真的增加用户工作量？从某种意义上说，是的。
1）在项目进行阶段
在上系统期间，有很多的用户也是项目成员，他们需要在处理日常工作的同时参与项目，例如负责整理基础数据，讨论/设定系统参数，制定业务流程，编写SOP，参与CRP/UAT，组织本部门用户培训等等。这些都是额外的工作，但本职工作也不能落下。

2）在系统并行阶段
系统并行，就是手工方式与系统方式同时进行，用手工的结果与系统的结果进行比对，以确定系统是正确的。例如MRP，一方面需要手工跟踪计算需要采购及生产的订单，还要在系统中进行确认和比对，如果有问题，还要进行核查。可想而知，这种工作量是非常大的。特别是这个阶段用户对系统又还不熟悉。

3）在刚上线的初期
这时候用户对系统仍然不太熟悉（尽管做了N多的培训），系统也不稳定，ERP团队的人员可能在到处救火，资源又紧张，用户的很多问题得不到及时解决，用户的工作被耽误/卡壳，无法继续进行。所以累积的工作越来越多，在短期内无法赶上，造成用户非常大的心理负担，从而产生抗拒的情绪。

4）在管理深入、精细化之后
随着管理不断深入，细化，流程变得更加完善，以前没有的流程环节，现在增加了；以前没有的数据，现在要收集要输入了；以前没有的报表，现在要做要看了。这些都会增加用户的工作量。

从以上第4点的情况可以看出，ERP系统本身就是为了完善流程，精细化管理，环环相扣的。正比如，你要做一个雕像，如果你只是要做一个毛胚，很显然你可能不需要花多大的精力，但如果你要把它雕刻成一个精品，你就需要花费非常多的时间和精力。所以实施ERP系统并不会减少工作量，而是会提高工作效率。因为电脑系统取代了很多重复的，繁杂的手工作业。以下是针对各个问题点的建议解决方案。
1）在项目启动之前应该充分告知工作量的情况，特别是对于项目成员。要求该项目成员的部门领导对该项目成员的本职工作进行适当的工作分配和安排。
2）系统并行的时间应该尽可能的短
3）反复的循环的用户培训；提高对用户问题的响应时间

[ 本帖最后由 logi 于 2010-3-18 09:51 编辑 ]

logi

2. 用户不断地提出更改系统的要求
因为目前正在负责系统实施，所以对这一点有比较深刻的体会。我主要从以下几个方面来谈一谈我的看法。

动机
首先要分析用户提出系统更改的动机。
1. 系统流程与实际运作流程不符，或者系统功能达不到运作要求而需要更改完善
2. 用户因个人使用习惯，或者跟以前使用过的系统比较而提出更改要求
3. 用户因抗拒系统推行而进行刁难，提出更改要求，以期达到推迟/拖延系统实施的目的

改变管理（Change Management）
要妥善地应对用户变更要求（Change Request），必须在公司推行改变管理。一套好的改变管理的政策和流程可以帮助使ERP的系统推行不偏离轨道。在改变管理中，必须定义：
1）改变申请的标准表格
2）改变的分类及分级，例如：一级，系统核心功能的更改；二级，一般功能增强（Enhancement）；三级，报表开发
3）谁可以提出改变申请？一般为关键用户代表，因为他们会进行初步地过滤
4）谁提出来的改变申请？越是高层提出的需求，你否定它的可能性越小（这是现实）
5）需要谁进行评估？这需要在项目组织架构中进行指定
6）需要谁批准？这需要在项目组织架构中进行指定（可以根据第2点中的分级设定不同的批准流程）
7）谁来定义优先级？这需要在项目组织架构中进行指定

完善的改变管理可以帮你：
1）对改变进行系统有效地管理
2）让用户认识到改变不是随便做的

妥协与斗争
一般来讲，在实施ERP的初期，会有一个基本的概念，例如二次开发不能超过标准功能的10%，或20%，等等。这需要公司管理高层的认知和同意。
然后需要对用户提出变更要求的动机进行分析，并逐一应对：
1. 对于真正满足不了业务需求的流程或功能，可以走正常的改变流程（申请，评估，批准，实施）
2. 强调ERP是一个标准的系统，通过培训改变用户个人习惯
3. 分析用户抗拒系统的各种原因，有针对性地解决。或者向上级管理层汇报以获得支持
4. 最后，一定不要在用户群中树立系统可以随便更改的印象。并自上而下的灌输思想，宣讲改变带来的系统升级困难，不能继续获得软件提供方的支持，以及分析改变的成本等。

[ 本帖最后由 logi 于 2010-4-28 13:37 编辑 ]

logi

3. 碰到系统确实无法处理的难点业务问题
其实在上一节关于改变管理的讨论中已经提到过这个话题。首先大家要认识到ERP系统不是万精油，肯定会有处理不了的业务问题。那如果真碰到这样的情况，该如何应对呢？

首先从业务层面来分析。无法处理的业务问题一般是新出现的业务流程，因为如果在系统选型评估时就已经知道处理不了，则用户也不会有什么期望和要求。对于新的业务流程，要分析以下几点：
1）这个业务流程是主要的业务流程吗？即这是不是占了企业主要的业务地位，从数量、金额以及市场影响，企业未来规划来看。
2）这个业务流程是暂时性的还是相对固定并将长期存在？
3）如果这个业务在系统无法处理，对企业的影响大吗？

如果以上的问题的答案是肯定的，则应该考虑寻求妥善的解决方案。如果是否定的，则可以考虑使用简化的系统流程，替代流程（workaround）或者手工流程处理。

除了从业务层面进行分析评估之外，还要考虑技术层面。

情况一：没有购买ERP的源代码，自己无法进行二次开发和修改。根本不能针对目前处理不了的业务作出修改或依赖于外部顾问公司或软件提供方。
这个主要取决于外部公司的开发能力以及报价。如果系统升级能够处理这种难点业务，应优先考虑进行升级。

情况二：自己有ERP的源代码及开发能力。
如果自己公司有开发能力，也并不代表一定要自己开发，因为还要考虑到开发的风险。如果是对现有核心流程的更改，则风险会比较大，而且也会影响到未来系统的升级，这样的修改由软件提供方或有能力的顾问公司做会好一点，而且出了问题也有后期的服务。如果一定要自己做，则需要有严格的开发管理流程。而且尽量做成独立的模块或功能。

其实技术上的处理方法，还包括购买第三方的软件系统（比如原来的系统完全不支持条码系统，那么可以考虑购买第三方的条码系统，再做两个系统之间的接口和整合），甚至重新购买新的ERP系统进行替换等。这取决于很多因素。

[ 本帖最后由 logi 于 2010-6-12 10:22 编辑 ]

logi

4. 厂方管理混乱，如何推进ERP系统实施
众所周知，ERP是一个管理项目，需要一个基本良好的管理基础。提升管理与上ERP系统是相辅相成、互相促进的。有的企业管理者会说，如果我的企业管理得好，我还要ERP干嘛？这正是中了ERP销售人员以销售打单为主、胡吹海夸承诺包治百病的毒。
但是既然已经选择了上ERP系统，责任自然落到了项目经理及实施人员的身上。这个时候再去责怪售前或者前任已经没有意义。而且很多时候不论是乙方还是甲方，项目实施都可能是经历了“几代人”的努力，到自己这一代，至于为什么上ERP系统，为什么选择这个品牌的ERP系统，都不是自己能够去左右和关心的了。对自己最重要的事，就是在乱局中杀出一条血路，让自己和团队建功立业，推进企业的ERP实施。
乱之分类：
1. 人员关系复杂、你争我斗
2. 流程七弯八拐，随意变更
3. 数据杂乱无章，零碎分散
4. 用户懵懵懂懂，自做主张

对“事”不对“人”
首先大家要知道，ERP解决不了人的问题。人的问题要项目经理应用自己的影响力去解决。如果项目经理足够强大，解决了人的问题，那上ERP将会更加顺利，也会更加成功。如果项目经理解决不了人的问题（非常正常不过的结果，特别是那些空降的项目经理），那么ERP的实施将会是一个比较长的过程，这时可以将重点转为针对人员培训、数据收集、流程整理开刀。请注意这些方面在乱的企业里面更容易出成绩。

先取“小胜”，再谋“大成”
当ERP项目进行得非常艰难的时候，要学会妥协和分步进行，温水煮青蛙，减少关键人员的抵抗。先取得一些小项目的成功，不仅让管理层看到成绩，让实施团队站稳脚跟，更是一个缓冲过程，其间可以多了解企业的实际状况和制定更有针对性的策略。

学会借力
有时候，推行ERP系统要学会借力。通常ERP系统都是全局规划，分步实施的。当上某一个模块的子项目的时候，要让这个子项目的受益人来促进项目的实施。例如，推行采购管理项目，可以让财务部门来督促推动，因为对采购的加强监管是财务的责任。

[ 本帖最后由 logi 于 2010-8-5 09:26 编辑 ]