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完成的就不写代码。这样性能高，功能也好修改。直到数据库的功能优势都发挥出来了再在中间层写东西，把通用的功能，如安全，如存储，如数据校验，如流程走向，如复杂数据计算判断都写在中间层。把中间层的优势都发挥完了，再写客户端的界面控制，报表，字典维护界面。 

　　E 有些功能比较复杂，应该分成两步或多步来做的，都做在了一起，引起功能异常复杂，不仅不会用，而且BUG多难稳定更不会用。 

　　解决方法：尽量隐藏功能，使每个界面都不复杂。 

　　F 真正的客户化的内容 

　　大量做报表，这样看，那样看，条件也不同。所以需要一个好的报表设计器，好的报表条件设计器。南方的用户要求尽量程序简单，自动化运行，所以我们拼命在裁减功能。北方的用户要求尽量程序处处控制，所以我们拼命在加功能，引起了矛盾。 

　　解决方法：报表设计器，报表条件设计器 

　　需要消息提醒服务使业务自动化。安全需要限制到一个界面上的一个字段。各家用户对界面上能看见什么字段，每个字段有什么限制，某个下拉字段能下拉出什么记录，如果录入有问题提醒话都有不同需要定制。 

　　3、培训 

　　有了上述的基础。还需要有正规的使用培训手册，正规的培训计划，对用户数，用户素质，时间长短与时间安排，计算机室人员配合，次数，场地设备，PPT，DOC都有要求。 

　　4、做报表做运行监控 

　　由于有了良好的报表设计器和监控日志，工作轻松了许多。 

　　5、升级更新版本 

　　每次的界面修改，数据库配置表结构VIEW，SP，JOB的修改，中间层的修改，INI的修改，都要记录下来日志，并且做成数据库SCRIPT脚本，按时间先后一并更新 

　　总结 

　　我们正确的做法是： 

　　1 业务功能设计方面 
a 业务专家，模仿竞争对手，模仿本公司的上一代版本，上网找资料，做一家试用客户 

　　b 尽量隐藏功能，使每个界面都不复杂。 

　　2 架构方面 

　　a 尽量不采用新技术新开发方法。 

　　b 数据库设计应该重点之重点。尽量把在数据库上做文章能写VIEW，SP，JOB完成的就不写代码。这样性能高，功能也好修改。 

　　c 直到数据库的功能优势都发挥出来了再在中间层写东西，把通用的功能，如安全，如存储，如数据校验，如流程走向，如复杂数据计算判断都写在中间层。 

　　d 把中间层的优势都发挥完了，再写客户端的界面控制，报表，字典维护界面。 

　　e 报表设计器，报表条件设计器。 

　　f 需要消息提醒服务使业务自动化。 

　　g 安全需要限制到一个界面上的一个字段。各家用户对界面上能看见什么字段，每个字段有什么限制，某个下拉字段能下拉出什么记录，如果录入有问题提醒话都有不同需要定制。 

　　3 代码编写方面 

　　a 界面数据业务分离。 

　　b 为了好跟踪BUG，需要有业务逻辑BUG的日志跟踪，能跟踪到每个界面的每个控件的操作和发向数据库的SQL。 

　　c 为了好跟踪BUG，需要有技术BUG的日志跟踪。 

　　4 客户化方面 

　　a 需要建立BUG提交和支持BBS，与公司的SAWIN连接在一起。根据BUG和需求来安排人力，进度，计划，考核程序员，监控工作质量。 

　　b 需要有项目经理，严格监控程序员，不能让他们对质量不负责任。 

　　c 一个修改，先有项目经理总控是该单独写代码还是交给公共基类来做。有人统筹开发通用基类。 

　　d 个性化的功能单独做出来不要在原有代码单元进行修改，把共用的放在共用单元，个性的各放各处。 

　　e 每次的界面修改，数据库配置表结构VIEW，SP，JOB的修改，中间层的修改，INI的修改，都要记录下来日志，并且做成数据库SCRIPT脚本，按时间先后一并更新。 

　　5 实施培训支持方面 

　　a 需要咨询专家洗脑，工程中的每个人都要给用户洗脑。 
　b 有详细的字典准备和系统参数配置说明。 

　　c 深刻理解业务进行实施培训支持人员考试。 

　　d FAQ数据库。 

　　e 需要有正规的使用培训手册，正规的培训计划，对用户数，用户素质，时间长短与时间安排，计算机室人员配合，次数，场地设备，PPT，DOC都有要求。 

　　炒概念，雇佣枪手互相吐口水，上法庭，做平台，打技术牌，搞高层论坛都没有戏。大话，岁数大就冒充专家，不可操作性的大方向指导，媒体记者为了吃饭乱发表趋势报告和什么真知灼见，都解决不了问题。 

　　关键在于有可操作性的东西，执行下去，这才是管理的真髓，也是竞争的最厉害的一招。 

　　别相信什么管理大师和管理经典书籍，对于管理你的企业一点用也没有，也千万别按照那些象牙塔中的东西到现实中演练，小心伤了别人，也小心伤了自己。