本文是在2003年写的一点心得。不过现在来看还是有启发意义的，虽然笔法有些稚嫩实施分为这几个阶段：

　　1字典准备，系统参数配置

　　2客户化

　　3使用培训

　　4做报表做运行监控

　　5升级更新版本

　　这几部分都挺费时间。为什么?

　　1 、字典准备，系统参数配置

　　没有字典准备和系统参数配置说明。一个新人就被一个人扔到客户处去独立完成全过程。整个客户这么大的投资这么多人这么重要的流程改制都把命运系在了这一个人的身上，不失败才怪。配的字典和参数有问题，系统就是出错误，甚至有些功能都做不了，最后不得不把整个工程全都推翻，字典重做。

　　解决方法：有详细的字典准备和系统参数配置说明。

　　FAQ数据库

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

　　由于涉及到导客户的老数据，由于格式，信息内容都不同，需要个性化做一些导表工具和数据初始化工具和数据校验工具

　　2、客户化

　　很多客户化其实不是客户有特殊需求，而是以下问题：

　　A 软件不实用，闭门造车，软件商又不愿意大量修改，用户当然不会用不愿意用互相僵持不给软件款。

　　解决方法：业务专家，模仿竞争对手，模仿本公司的上一代版本，上网找资料，做一家试用客户

　　B 由于没有从咨询高度教育引导客户，使客户随意变动软件，引起难以稳定。而且没有统一口径管理用户提交上来的BUG和需求列表，每个程序员都可以接了用户电话，想也没想通用性和影响性，为了应付现在这个客户就改了，最后程序越来越不好改。开发员不负责任，编码随意也不测试，项目经理管理不严，BUG百出，出了一个改一个，不出也不管。

　　解决方法：需要咨询专家洗脑，在实施的全过程，工程中的每个人都要给用户灌输并且表现这种思想，表现出我们是最正确的我们是最先进的我们是专家你们是落后的。

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

　　需要有项目经理，严格监控程序员，不能让他们对质量不负责任。为了好跟踪BUG，需要有业务逻辑BUG的日志跟踪，能跟踪到每个界面的每个控件的操作和发向数据库的SQL。为了好跟踪BUG，需要有技术BUG的日志跟踪。