ERP项目验收-给自已一杆标尺

ERP项目验收-给自已一杆标尺

【 专稿】公司规模越来越大，从最初的一个人担当技术支持，也逐渐发展到五个人了，IT部门也顺理成章的被独立出来。小章因为技术出色，办事又有条理，便被任命为IT主管。小章上任后，总经理下放的第一件任务便是企业信息化进程要排上议事日程，为了让公司内部的工作更加的条理化，在管理上更上一个台阶，上ERP被排在了第一件。

在经历选型、实施、验收之后，小章松了口气，以为非常圆满的完成了上任后第一件最漂亮的工作。但事实却恰恰相反，内部的一些办事流程依然是老样子，一些比小章资格要老的员工更是我行我素。ERP只是成了服务器以及各个客户端电脑中的一个摆设。项目的验收报告也签了，和ERP厂商双方都盖了章了，按理说应该项目很圆满才对，为什么造成了这样的局面呢？这里且不说在实施上出了什么问题，最后的验收工作很明显也没有做到位，没有给自己一个明确的验收标准，自然实施结束后没有对应的标准进行参照，结果是软件安装完了，可以成功运行，就算是合格验收了。

其实ERP项目的验收工作远非这样简单，如果说项目实施是软件厂商和本企业双方的工作，那么项目验收绝对就是企业内部的事。在验收过程中，项目算是成功上线，和软件提供商签订验收报告之前，绝对要进行很好的评估，严格参照曾建立好的验收标准，也就是说项目验收，要给自己一杆标尺，有了标尺的参照，验收工作自然更加完美。

一、项目该何时验收

因为ERP针对企业来说是一项非常大的项目，所以基本上很少企业内部能在ERP项目的各个流程上有十足的经验，因此制定一个验收的时间标准也很重要。

通常情况下，如果只是购买软件厂商的标准产品，项目实施顾问都会制定一个实施时间表，其中包括服务器端以及客户端软件安装的时间计划等。等软件安装工作完成后，一般运行一、两个星期后有些实施顾问便会要求项目验收，如果这时验收的话，是肯定看不到项目效果的，即使觉得项目验收不合格，往往也说不出所以然，在这种朦胧的状态签订了报告后，便预示着项目结束，后续的便剩下服务的商谈，而实际的验收效果则看不到。

从笔者所经历过的经验来看，ERP系统至少需要运行一个月后才可以验收，毕竟一个月才能是一个小的系统周期，如果小的周期都没有跑顺，就更别说一年这样的大周期了。另外根据模块的多少，系统涉及部门人员的多少，在验收时间上还需要更多考量，如果能做到系统平稳运行两个月，财务模块报表无差错，再做验收则更好。

另外对于有二次开发模块的项目验收，一定要将标准模块与二次开发项目的验收进行分开。因为二次开发的为全新的模块，同普通软件一样，也应有个“公测”除Bug阶段，应该在平稳运行三至四个月后再做验收，这样保证了有足够的时间去让系统经历尽可能多的情况，也便于让用户找出尽可能多的Bug。

这里至所以强调一个验收的时间，因为大部分情况下，系统验收结束后，软件厂商都是按验收报告上签订的时间来提供一年的技术支持，一年时间一过便需要付费进行技术支持了。让系统试运行时间长一点，也是从另一方面为我们争取免费技术支持的时间。

${PageNumber}

二、项目该验收什么

既然ERP项目的验收不是服务器端、客户端安装结束就完事，那整个ERP项目验收的内容应该是哪些呢？有着怎样的标准呢？这些“标尺”都严重影响我们的项目是“真”成功还是“假”成功，所以这里的标尺很重要。

1.项目文档

任何企业的项目实施都不会一帆风顺，每次遇到问题实施顾问都会备案，并采取相应的措施或提供相应的解决方案，以及本企业内部各部门在项目实施过程中的配合程度，提供的相关支持等。特别是在项目实施过程中，举行的项目进度会议，会议记录也很重要，因为会议记录往往包含着实施顾问对整个项目的指导性建议以及本企业内部在实施过程中所遇到的问题，问题的解决进度。等等这些实施顾问一般都会整理成文档，而这些文档对于我们企业自身来说也是相当宝贵的，小点说，可以从这些文档中管窥整个项目的实施过程，大点说，可以为企业后续的信息化进程提供更多的参照，避免犯重复的错误，少走弯路。

2.执行情况

执行情况相对来说是一个无形的东西，很多企业上ERP到最后，变成了财务部门信息化，其他部门的系统都成了一个花架子。之所以出现这样的情况是因为财务的报表相对来说比较容易突现出其工作情况，其他部门可能仍旧采用老旧的办公方式。这里验收执行情况的标准也可以说是在验收企业内部管理水平的提升，因为信息化本身的重要意义就在于通过软件的标准化进一步规范企业的作业流程，一方面提高作业效率，另一方面提升企业员工的总体管理水平。

当然这里企业最高领导人的重视也是很重要的一方面，比如在实施阶段就切实强调所有业务必须从系统走，传统的手工形式不承认，时间久了，大家习惯了，规范也就养成了。所以各个部门是不是真的用上了ERP，发挥了ERP的作用，也是我们考量的目的，而不仅仅是程序菜单中多了一项而已。

${PageNumber}

3.二次开发项目的附属物

同标准版程序不一样的是，二次开发项目的后续维护会更麻烦，特别是软件提供商那边发生人事变动后，经过几年，当时的开发人员离职后，程序再有什么问题，解决起来估计就非常麻烦了，所以在二次开发项目的验收上得更加注意。

除了前面第一点提的最基本的项目文档外，一定要让软件提供商提供项目开发的整个框架、软件架构模型，其中也包括数据库结构，特别是核心配置表间的一些关系以及源代码。当然这里提的这些东西可能都需要在签订合同之前商谈的，如果前面没有谈到这个问题，在验收时强调一下也未尝不可，本着互惠互利的精神，软件提供商都愿意配合的。并且这些相关资料要保存好，以便在后续使用过程中出现问题时，企业内部的IT部门员工可以从这些文档中寻找相关信息，对解决问题有很大作用。

4.系统性能

这里的系统性能一般是针对二次开发项目的一个验收项目，因为对于系统的标准版本来说，一般软件厂商都经过了很严格的测试，并且经过绝大多数客户的验证，在系统性能方面一般不会有太大的问题，否则软件厂商的项目肯定也开展不起来。

二次开发的项目无论是对软件厂商还是对企业内部来说，都是一个全新的软件，既然是新的软件，Bug在所难免，但一些基本的性能要满足要求，比如在多用户并发操作，以及大批量数据运行的过程中，系统是否有严重的性能瓶颈，这些需要通过和一线的系统操作员工进行沟通，进而了解系统的性能方面的问题。

三、小结

项目验收是看似简单，但操作复杂的工作，因为项目验收无固定统一的标准。在验收的过程中，项目文档的验收往往也是一个难点，一方面因为系统本身的功能、性能等方面导致容易弱化这方面的重要性。另外就是项目文档也没有一个统一的验收标准，如果要求不严，很容易被“蒙混”过关。

ERP往往都是企业信息化中的“领头羊”，ERP系统上好了，运行流畅了，为企业的全面信息化工作可以起到推波助澜的作用，ERP失败了，将会让企业落入信息化太难或者不好的怪圈，并最终影响企业的管理水平。因此在项目验收的过程中，一方面是验收ERP的功能、性能、系统动作情况，另一方面就是验收项目实施过程中的经验，为后续的信息化工作打下基础。