erp成功率0现象 从具体实施层面剖析.doc

ERP成功率0现象从具体实施层面剖析    本文是在2003年写的一点心得。不过现在来看还是有启发意义的,虽然笔法有些稚嫩实施分为这几个阶段:  1字典准备,系统参数配置  2客户化  3使用培训  4做报表做运行监控  5升级更新版本  这几部分都挺费时间。为什么?  1 、字典准备,系统参数配置没有字典准备和系统参数配置说明。一个新人就被一个人扔到客户处去独立完成全过程。整个客户这么大的投资这么多人这么重要的流程改制都把命运系在了这一个人的身上,不失败才怪。配的字典和参数有问题,系统就是出错误,甚至有些功能都做不了,最后不得不把整个工程全都推翻,字典重做。  解决方法:有详细的字典准备和系统参数配置说明。  FAQ数据库  深刻理解业务进行实施培训支持人员考试。  由于涉及到导客户的老数据,由于格式,信息内容都不同,需要个性化做一些导表工具和数据初始化工具和数据校验工具  2、客户化  很多客户化其实不是客户有特殊需求,而是以下问题:  A 软件不实用,闭门造车,软件商又不愿意大量修改,用户当然不会用不愿意用互相僵持不给软件款。  解决方法:业务专家,模仿竞争对手,模仿本公司的上一代版本,上网找资料,做一家试用客户  B 由于没有从咨询高度教育引导客户,使客户随意变动软件,引起难以稳定。而且没有统一口径管理用户提交上来的BUG和需求列表,每个程序员都可以接了用户电话,想也没想通用性和影响性,为了应付现在这个客户就改了,最后程序越来越不好改。开发员不负责任,编码随意也不测试,项目经理管理不严,BUG百出,出了一个改一个,不出也不管。  解决方法:需要咨询专家洗脑,在实施的全过程,工程中的每个人都要给用户灌输并且表现这种思想,表现出我们是最正确的我们是最先进的我们是专家你们是落后的。  需要建立BUG提交和支持BBS,与公司的SAWIN连接在一起。根据BUG和需求来安排人力,进度,计划,考核程序员,监控工作质量。  需要有项目经理,严格监控程序员,不能让他们对质量不负责任。为了好跟踪BUG,需要有业务逻辑BUG的日志跟踪,能跟踪到每个界面的每个控件的操作和发向数据库的SQL。为了好跟踪BUG,需要有技术BUG的日志跟踪。 C 软件商把各家用户的需求功能都混合在了一起,一是使代码BUG百出,二是使BUG不好找,三是使代码客户化不好修改,四是使功能复杂用户不会用,五是使用户觉得功能自己用不上要求裁减下去反而裁减不下去了。  由于大家各写一块,通用的功能却各写各的,一个相同的BUG需要修改各自的程序,没修改到的地方就有问题。  解决方法:界面数据业务分离,一个修改,先有项目经理总控是该单独写代码还是交给公共基类来做。有人统筹开发通用基类。个性化的功能单独做出来不要在原有代码单元进行修改,把共用的放在共用单元,个性的各放各处。  D 由于数据库设计没有分为摘要表,细目表,月汇总表,年汇总表,冷数据表,热数据表,没有用VIEW,SP,JOB,字段类型不考虑用简单类型,引起性能问题。采用大量新技术,新技术有BUG,问题难以解决。  解决方法:尽量不采用新技术新开发方法。数据库设计应该重点之重点。尽量把在数据库上做文章能写VIEW,SP,JOB完成的就不写代码。这样性能高,功能也好修改。直到数据库的功能优势都发挥出来了再在中间层写东西,把通用的功能,如安全,如存储