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

1、.：.；ERP胜利率为0景象从详细实施层面分析实施分为这几个阶段：1字典预备，系统参数配置2客户化3运用培训4做报表做运转监控5晋级更新版本这几部分都挺费时间。为什么？1字典预备，系统参数配置没有字典预备和系统参数配置阐明。一个新人就被一个人扔到客户处去独立完成全过程。整个客户这么大的投资这么多人这么重要的流程改制都把命运系在了这一个人的身上，不失败才怪。配的字典和参数有问题，系统就是出错误，甚至有些功能都做不了，最后不得不把整个工程全都推翻，字典重做处理方法：有详细的字典预备和系统参数配置阐明FAQ数据库深化了解业务进展实施培训支持人员考试由于涉及到导客户的老数据，由于格式，信息内容都不同，

2、需求个性化做一些导表工具和数据初始化工具和数据校验工具2客户化很多客户化其实不是客户有特殊需求，而是以下问题：A软件不适用，闭门造车，软件商又不情愿大量修正，用户当然不会用不情愿用相互僵持不给软件款。处理方法：业务专家，模拟竞争对手，模拟本公司的上一代版本，上网找资料，做一家试用客户B由于没有从咨询高度教育引导客户，使客户随意变动软件，引起难以稳定。而且没有一致口径管理用户提交上来的BUG和需求列表，每个程序员都可以接了用户，想也没想通用性和影响性，为了应付如今这个客户就改了，最后程序越来越不好改。开发员不担任任，编码随意也不测试，工程经理管理不严，BUG百出，出了一个改一个，不出也不论处理方

3、法：需求咨询专家洗脑，在实施的全过程，工程中的每个人都要给用户灌输并且表现这种思想，表现出我们是最正确的我们是最先进的我们是专家他们是落后的。需求建立BUG提交和支持BBS，与公司的SAWIN衔接在一同。根据BUG和需求来安排人力，进度，方案，考核程序员，监控任务质量。需求有工程经理，严厉监控程序员，不能让他们对质量不担任任为了好跟踪BUG，需求有业务逻辑BUG的日志跟踪，能跟踪到每个界面的每个控件的操作和发向数据库的SQL为了好跟踪BUG，需求有技术BUG的日志跟踪C软件商把各家用户的需求功能都混合在了一同，一是使代码BUG百出，二是使BUG不好找，三是使代码客户化不好修正，四是使功能复杂用

4、户不会用，五是运用户觉得功能本人用不上要求裁减下去反而裁减不下去了由于大家各写一块，通用的功能却各写各的，一个一样的BUG需求修正各自的程序，没修正到的地方就有问题处理方法：界面数据业务分别，一个修正，先有工程经理总控是该单独写代码还是交给公共基类来做。有人统筹开发通用基类个性化的功能单独做出来不要在原有代码单元进展修正，把共用的放在共用单元，个性的各放各处D由于数据库设计没有分为摘要表，细目表，月汇总表，年汇总表，冷数据表，热数据表，没有用VIEW，SP，JOB，字段类型不思索用简单类型，引起性能问题采用大量新技术，新技术有BUG，问题难以处理处理方法：尽量不采用新技术新开发方法。数据库设计

5、应该重点之重点。尽量把在数据库上做文章能写VIEW，SP，JOB完成的就不写代码。这样性能高，功能也好修正。直到数据库的功能优势都发扬出来了再在中间层写东西，把通用的功能，如平安，如存储，如数据校验，如流程走向，如复杂数据计算判别都写在中间层。把中间层的优势都发扬完了，再写客户端的界面控制，报表，字典维护界面E有些功能比较复杂，应该分成两步或多步来做的，都做在了一同，引起功能异常复杂，不仅不会用，而且BUG多难稳定更不会用处理方法：尽量隐藏功能，使每个界面都不复杂。F真正的客户化的内容大量做报表，这样看，那样看，条件也不同。所以需求一个好的报表设计器，好的报表条件设计器。南方的用户要求尽量程序

6、简单，自动化运转，所以我们拼命在裁减功能。北方的用户要求尽量程序处处控制，所以我们拼命在加功能，引起了矛盾。处理方法：报表设计器，报表条件设计器需求音讯提示效力使业务自动化平安需求限制到一个界面上的一个字段。各家用户对界面上能看见什么字段，每个字段有什么限制，某个下拉字段能下拉出什么记录，假设录入有问题提示话都有不同需求定制3培训有了上述的根底。还需求有正规的运用培训手册，正规的培训方案，对用户数，用户素质，时间长短与时间安排，计算机室人员配合，次数，场地设备，PPT，DOC都有要求。4做报表做运转监控由于有了良好的报表设计器和监控日志，任务轻松了许多。5晋级更新版本每次的界面修正，数据库配置表构造VIEW，SP，JOB的修正，中间层的修正，INI的修正，都要记录下来日志，并且做成数据库SCRIPT脚本，按时间先后一并更新结尾：炒概念，雇佣枪手相互吐口水，上法庭，做平台，打技术牌，搞高层论坛都没有戏。大话，岁数大就冒充专家，不可操作性的大方向指点，媒体记者为了吃饭乱发表趋势报告和什么真知灼见，都处理不了问题。关键在于有