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

ERP成功率为0现象从具体实施层面剖析实施分为这几个阶段：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脚本，按时间先后一并更新结尾：炒概念，雇佣枪手互相吐口水，上法庭，做平台，打技术牌，搞高层论坛都没有戏。大话，岁数大就冒充专家，不可操作性的大方向指导，媒体记者为了吃饭乱发表趋势报告和什么真知灼见，都解决不了问题。关键在于有