由于我本人的项目经验在DRP项目中会比较多一些，而且所谈及的问题也是在DRP项目中碰到的，当然，也许我说的这个问题不只只是在DRP项目中，包括像ERP、PDM、KM等项目中都会碰上，但我还是会结合DRP项目中的实际问题来说。同时，由于本人所在的角度是甲方的角度，因此，DRP项目的周期对于甲方来说不只只是项目调研、实施、培训，还会包括整个DRP系统的应用、部署、维护直到系统结束使用的DRP系统的整个使用周期。

　　DRP项目进行到后期，一般的企业都会担心一个问题：“顾问走了之后，我们怎么办？”。

　　因为如果实施顾问在现场的话，感觉都不会出什么问题，就算有问题，顾问也解决掉了。但一旦顾问离场，DRP系统交由企业的IT部门负责运行与维护的时候，感觉问题就出的比较多了。这些问题可能会包括系统故障增多、系统运行速度减慢、软件需求得不到响应、数据不准，等等。也因为这些原因业务部门也在应用了一段时间之后感觉系统不好用了，特别是数据不准的情况经常出现，使得报表也不准了，久而久之，业务部门感觉DRP系统的价值也越来越低了，而这样造成的直接后果就是DRP系统的使用效果打折，经常会听到业务部门在抱怨：“这是什么破系统嘛，出来的数据都不准!”。把数据问题与DRP系统逻辑问题相混淆，从而有可能对DRP系统本身引发了怀疑，导致DRP系统的使用周期因为数据不准而大大缩短。

　　一、“数据事故”引发的数据治理思考

　　套用一句老话：“ERP是三分软件、七分实施、十分努力、十二分数据、百分百的领导支持”。

　　其实笔者一直在实施DRP项目的过程中，都有碰到多或多或少的数据问题，但应该都是小问题，所影响的范围也不大，或者通过DRP系统的一些异常处理功能也就能够解决的，例如：退货单出现的退货价格不准确的问题，只要对这张单据进行废除重做就好了，直到笔者碰到两次重大的“数据事故”，才对DRP项目的数据治理工作引发了重视与思考。

　　第一件事情是由于产品中心对新产品定价错误引发的“数据事故”。

　　一直以来，新产品的定价是由产品中心会同财务、销售、计划等部门一起制定的，而且制定的是产品的零售价，然后根据零售价的折率分别倒推定制分销价、出厂价、采购价，而采购价也是一个基准价，也就是说，产品的采购必须低于这个价格，否则的话公司是不会批准对这款产品进行投产的。

　　在年度某季度新产品定价时，公司各部门定制出了当季产品的各种价格，并已经在系统中进行实施，但随之而来的是，发现在市场对于当季产品的价格反映是偏高，而且代理商也认为当季产品的分销价格(即代理商进货价)太高，所以公司决定对该款产品进行重新定价。随之而来的就是要求DRP系统中对所有业务环节中的价格进行调整，包括对已经配送到分公司、代理商的产品进行重新调价，对已经配送到直营店，在仓库中未销售的产品进行价格调整。

　　这一次的调整由于影响极大，导致公司各业务部门不得不集中人马加班对数据进行调整，而且调整结束之后，在下月的系统过账中发现财务报表总是有些出入，才发现数据调整有问题，有些调过来了，有些没有调整过来，有些调整的时候产品已经销售出去了，有的产品是退货的，但成本却没有改过来，总之是乱的一团麻，使得该月的财务报表不得不在财务部门的要求下，各业务部门签字核定是由于操作不当引起的数据统计问题。本次问题其实是一个业务规范性的问题，或者是系统强壮型问题，如果业务够规范，不会出现这种在产品进行销售时更改产品成本的问题，或者系统足够强壮，能够对数据变更做出及时处理，这次事故应该也是能够避免的。

　　第二件事是由于分公司内部管理、控制不到位及流程缺失导致的“数据事故”。

　　记得当时还在外面开会，被财务总监电话催回公司，说是公司领导要求我今天准备一下，明天去华中大区出差，因为当地分公司的本月的财务、系统数据都有严重问题，估计账实不符情况严重，需要过去核查一下问题到底出在哪里。第二天，当公司的财务、计划、IT三部门人员到达华中大区所在地时，开始安排了对本大区所有的库存盘点的工作，首先是对直营店进行盘点，全部由总部人员进行监督，经过五个晚上的盘点之后，再用了四天时间对大区的库房进行盘点，结果发现：直营店的手工账务与DRP系统中的数据不符情况严重，而直营店的手工账务与实际库存情况相差无几，直营店也较好地执行了失货赔偿制度。

　　而DRP系统中的数据与实际库存严重不符的原因在于：大区的仓库管理人员、数据员都没有及时将直营店的退货、销售、调拨单据进行处理，以致直营店数据失真。同时对大区的库存盘点时发现：大区的库存结构不合理，库存过大，直营店的过季产品处理不及时，数据员没有对仓库数据进行及时分析及利用。同时，大区的财务人员也没有根据DRP系统中的数据进行财务数据核对，以至于仓库、数据、财务的工作脱节，形成了大区库房管理工作出现了失控。

　　这次事故经过审核之后，上报到公司领导，下定决心对相关责任人进行了处罚，而也是在这次“数据事故”之后引发了笔者对于如何进行DRP系统“数据治理”的思考。