DRP（分销资源计划）系统实施顾问走后，系统问题越来越多，尤其是数据不准的情况经常出现，使得报表也不准了。业务部门抱怨：“这是什么破系统，出来的数据都不准。”接下来的两则严重的数据事故引发了一场数据治理的大战。

    事故一：新品定价错误搞得一团乱

    Ａ是一家经营服装的公司，为做好分销渠道的管理，上了ＤＲＰ（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ，分销资源计划）系统。然而，由于产品中心对新产品定价错误引发了一起严重的数据事故。一直以来，新产品的定价是由产品中心会同财务、销售、计划等部门一起制定的，而且制定的是产品的零售价，然后根据零售价的折率分别倒推定制分销价、出厂价、采购价，而采购价也是一个基准价，也就是说，产品的采购必须低于这个价格，否则的话公司是不会批准对这款产品进行投产的。在年度某季度新产品定价时，公司各部门定制出了当季产品的各种价格，并已经在系统中进行实施，但随之而来的是，发现在市场对于当季产品的价格反映是偏高，而且代理商也认为当季产品的分销价格，即代理商进货价太高，所以公司决定对该款产品进行重新定价。随之而来的就是要求ＤＲＰ系统中对所有业务环节中的价格进行调整，包括对已经配送到分公司、代理商的产品进行重新调价，对已经配送到直营店，在仓库中未销售的产品进行价格调整。这一次的调整由于影响极大，导致公司各业务部门不得不集中人马加班对数据进行调整，而且调整结束之后，在下月的系统过账中发现财务报表总是有些出入，才发现数据调整有问题，有些调过来了，有些没有调整过来，有些调整的时候产品已经销售出去了，有的产品是退货的，但成本却没有改过来，总之是一团乱麻，使该月的财务报表不得不在财务部门的要求下，各业务部门签字核定是由于操作不当引起的数据统计问题。本次问题其实是一个业务规范性的问题，或者是系统强壮型问题，如果业务够规范，不会出现这种在产品进行销售时更改产品成本的问题，或者系统足够强壮，能够对数据变更做出及时处理，这次事故应该也能够避免。

    事故二：流程管理不到位引起局面失控

    第二件事是由于分公司内部管理、控制不到位及流程缺失导致的数据事故。Ａ公司ＣＩＯ去华中大区出差，因为当地分公司的当月的财务、系统数据都有严重问题，估计账实不符情况严重，需要过去核查一下问题到底出在哪里。第二天，当公司的财务、计划、ＩＴ三部门人员到达华中大区，开始安排对本大区所有的库存盘点的工作。首先是对直营店进行盘点，全部由总部人员进行监督，经过五个晚上的盘点之后，又用了四天时间对大区的库房进行盘点，发现直营店的手工账务与ＤＲＰ系统中的数据不符情况严重，而直营店的手工账务与实际库存情况相差无几，直营店也较好地执行了失货赔偿制度。而ＤＲＰ系统中的数据与实际库存严重不符的原因在于：大区的仓库管理人员、数据员都没有及时将直营店的退货、销售、调拨单据进行处理，以致直营店数据失真；同时对大区的库存盘点时发现，大区的库存结构不合理，库存过大，直营店的过季产品处理不及时，数据员没有对仓库数据进行及时分析及利用。同时，大区的财务人员也没有根据ＤＲＰ系统中的数据进行财务数据核对，以至于仓库、数据、财务的工作脱节，形成了大区库房管理工作出现了失控。

    这两则事故引发了笔者对于如何进行ＤＲＰ系统“数据治理”的思考。

    如同ERP一样，DRP也是三分软件、七分实施、十分努力、十二分数据、百分之百的领导支持。

    数据问题降低系统价值

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

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

    治理需要全过程

    项目小组总结之后，通过查找相关资料发现：数据治理其实是一种体系，是一个关注于信息系统执行层面的体系，这一体系的目的是整合IT与业务部门的知识和意见，通过一个类似于监督委员会或项目小组的虚拟组织对企业的信息化建设进行全方位的监管，这一组织的基础是企业高层的授权和业务部门与IT部门的建设性合作。从范围来讲，数据治理涵盖了从前端事务处理系统、后端业务数据库到终端的数据分析，从源头到终端再回到源头形成一个闭环负反馈系统（控制理论中趋稳的系统）。从目的来讲，数据治理就是要对数据的获取、处理、使用进行监管（监管就是我们在执行层面对信息系统的负反馈），而监管的职能主要通过以下五个方面的执行力来保证——发现、监督、控制、沟通、整合。

    1.发现：即发现问题和差异（Issues && Gaps），这是监管的基本职能。我们一定要在萌芽阶段发现问题和差异，并将其扼杀。那么如何去发现呢？

    对于待建或在建的系统，要建立专家审核制度，所谓专家包括技术专家和业务专家，如果本组织不具备条件则可以邀请第三方的顾问来参与系统数据的架构和设计决策，但根本原则是专家必须是相关领域的专业人士。

    已建成使用的系统，其关键是IT的日常运维工作的规范化，主要包括规范的问题管理（Trouble Management），周期性审核（Periodic Review）。前者是为了文档化各种系统问题和缺陷，以及相应的IT判断和响应；后者是为了及时对系统的问题和缺陷做出归纳总结，找出规律，从根本上解决问题。

    2. 监督：即持续地保持对业务数据健康状况的跟踪。监督主要通过周期性的数据分析来完成，市场上也有很多自动化的工具可以帮助用户方便地对数据的健康状况进行分析。与发现不同的是，监督是主动地去发掘问题，而且在发现问题后立即采取行动去修正它。

    3. 控制：即掌握信息系统建设的决策权。任何信息系统的建设、更新升级、大型变更都必须通过数据治理项目小组的审批，极端情况下甚至可以考虑任何数据变更都必须审批。集中化控制的好处是，首先，可以集中技术和业务相关领域专家的意见；其次，可以限制执行层面的IT人员和业务人员的随意性、不严谨性；再次，向监管层提供了从全局和长远的角度看系统的机会。

    4. 交流：即沟通，是跨部门、跨领域的沟通。对传统IT的最大挑战就是跨组织、跨领域的沟通，而数据治理委员会这样一个跨越了IT部门和业务部门的虚拟组织，通过建立例行的交流机制，保证了信息在整个组织范围内的透明，这种透明性保证了所有参与者的步调一致性，从而保证了业务数据的一致性。交流渗透在前面所述的几点数据治理活动中，是它们成功的保障。

    5. 整合：这是我们的目标，同时也是解决之道，主要抓住三个方面的整合——信息的整合、资源的整合、能力的整合。通过信息的整合把分散的业务数据整合到一个一致的没有歧义的体系中来；通过资源的整合把企业IT资源集中调配；通过能力的整合，将平台的运算能力、业务数据处理能力集中管理，建立一种集中服务的模式，既提高了硬件利用率、人员工作效率，又利于IT对各业务部门服务的成本核算。

    谨防数据暗流

    为了解决数据事故问题，笔者协调财务、计划、销售、IT等部门成立了专门的数据治理项目小组。

    Gartner研究显示，良莠不齐的客户数据可造成重大损失，包括流失客户，以及由处理直销邮件不善和错过销售机会所造成的浪费等。现时很多企业亦发现劣质数据不仅打击销售及市场推广，更会波及最具策略性的业务活动。后勤部门的运作，例如制定预算、生产及分销也会受到影响。

    解决劣质数据问题不只是一个IT的问题。虽然IT有助于将之改善，但企业管理才是关键所在，例如企业文化对数据素质就有很大的影响力。

    数据素质涵盖存在性、合法性、一贯性、完整性、准确性、关联性、时间性等各个方面。针对以上数据的素质，再结合DRP系统中的相关模块，对DRP系统中数据问题按模块分别分析。该分析表格如表1所示。

    表中各模块中，达到相应的数据素质目标即为Y，否则为N。经过对DRP系统中各个模块的数据素质调查发现：数据治理主要针对的是数据的准确性、时间性、关联性。进一步对数据事故的原因进行分析，发现数据出问题往往是因为对数据的应用不够充分。比如物流配送，根据销售和库存信息来做，首先是销售的信息，每天系统里面的销售信息和银行回款对比，有没有差异，没有差异就是对的。第二，配送是根据系统去配，要慢慢地精细化，以前可能是粗放的，现在是一个环节套一个环节，根据这个系统来做，慢慢数据就会越来越准确。实现百分之百的准确不可能，当然也没有必要，因为随便一个环节都有可能出现串码。

    但如果业务部门发现DRP系统不管用，DRP使用者就会自己秘密地使用自己认为“更方便更可靠的工作流程/做法”，而管理层认为既然没有发生什么不妥，也就睁一只眼，闭一只眼。其实，任何绕道DRP系统的工作流程/做法都会产生DRP数据流之外的数据暗流。这种数据暗流会削弱企业对流程的控制，损害企业对流程的管理和进一步优化，自然DRP系统的数据准确性就更差了。那么，我们又怎样保证及时数据更新和避免绕道DRP的秘密的“更方便更可靠的工作流程/做法”呢?解决方案原则上很简单：持续提高数据准确率，定期维护订单修订等系统参数，以确保DRP产生的数据流与实际运作相符，通过基于DRP的工作流程的改进，禁止任何绕道DRP的行为。

    同时，借鉴了业内同行的“数据事故”分析方法，可以得到如下的因果图（如图１所示）。

    针对上述发现的各种原因，经过进一步的统计与分析，发现主要问题出在审核流程缺失、KPI指标设定不完善、考核与处罚机制没有执行、指定时间内的数据不到位、业务不熟悉、操作不当上。相反，由于系统原因造成的DRP数据错误很少。而像流程原因导致数据错误出现的次数只占20%，但流程原因出现的数据错误影响程度最大。而像操作不当、指定时间内的数据不到位的情况出现较频繁，但对数据错误的影响有限。

    全面的数据治理方案

    采用上述的数据治理理论，在经过数据事故的教训之后，发现上述数据问题，分别针对时间因素、流程、数据基础、考核机制、人员、系统制定数据治理方案，并强调方案的执行、监督、控制职能，加强各业务人员沟通，达到数据治理的目的。

    考核机制：数据治理的问题其实也是企业管理的问题，而出现问题往往是由于没有一个比较好的考核与激励机制。在数据事故当中，出了问题之后，IT人员急着去查找原因，财务部门则因为数据报表出不来而干着急，一般事故责任部门往往是数据生产部门，而不是数据消费部门。所以，没有好的考核机制，在事故出现了之后无据可依地进行处罚，会导致员工情绪极大。

    因此，我们制定了如下考核办法：每月结束，涉及到DRP系统中数据操作出现错误次数在5次（含5次）以上的，每次罚款10元，充入公司奖金池；如果每月操作零错误的，则从奖金池内奖励30元；各部门的年度KPI指标中加入DRP系统数据操作正确率，并给予一定的权重。

    人员：人员责任心不强的问题，可以由前面的考核机制来加强，而且由于数据操作涉及到部门的绩效，因此，各业务部门经理也会加强在这方面的监督；对于操作不当、业务不熟悉的情况，可以归结为培训不够。对于培训我们分为两大块：一是新员工培训，这包括老员工调职到新岗位，新员工如果需要操作DRP系统，必须经过IT部的上岗培训方可开设DRP系统账号。还有就是专场培训，这也有两类，一类是专门的计算机基础教育培训，这里会包括一些计算机基础操作、基本故障处理；另一类是公司业务流程培训，针对各个不同岗位的人员，将公司的业务流程整合起来讲，让业务人员知道自己上下游的业务流程是什么，如果有异常如何处理等。培训由人力资源部培训组与IT部共同负责，所有培训考勤、反馈、考核情况都记入员工培训档案，讲师则由IT部门、业务部门经理分别承担。如果是针对各业务经理的培训，也会请外部的流程、IT专家来担任。

    系统：系统的问题，主要通过两方面控制：一是加强测试，所有的系统升级都必须经过公司内部的程序员测试，撰写测试报告，经由IT经理审批之后方可将升级包更新到DRP系统中去。如果由于升级原因造成系统逻辑问题的数据错误，必须由程序员与IT经理分别承担责任，根据每次事故的问题严重性，每次罚款30～300元不等，同时IT部门的KPI指标中也加入系统数据事故的次数进行考核。二是对于关键服务器、网络设备的突然宕机等情况的处理，这些方案可以根据IT部门的原有处置与考核机制进行。

    数据基础：基础数据质量差，就要对数据生产部门提出需求，必须控制数据质量，完善公司数据规格说明。对于必须填写的数据，由IT部门定期出具数据质量审计报告，对数据生产部门进行考核。对于数据录入准确率低的问题，一是采用条码、扫描等技术手段来加强数据质量，二是通过加强人员责任心来保证，三是通过数据审核加强下游业务流程中对数据的审核与比对。

    流程：流程是最头痛的问题，也是处理起来最难的问题。其实业务流程管理是一个很大的话题，在这里只能说要根据企业实际情况，一点点地改进，因为流程改进是一个伤筋动骨的事情。它包括：原有流程是适合企业应用的，但现在不合适了怎么办；原来的流程是由某个部门负责的，现在职能要细化，需要分开怎么办。当然流程管理的方法和经验有很多，我们可以参考一些专业的说法。

    时间因素：时间因素主要在于企业的动作效率，也是对于员工的一个考核指标，这方面没有太大的难度，我们主要是将时间作为数据生产部门的一个指标来考核。如：计划部门必须在收到订货单的2小时之内将订货单的货配发出去；专卖店如果有DRP系统，必须在当天将销售数据传回，如果没有DRP系统，则传真数据必须在当天传回，当地办事处必须在第二天上午11：00之前将销售数据做到DRP系统中；客服部必须在12小时内将客户数据录入到DRP系统中，对于客户的礼品申请，必须在两个工作日内处理完毕，并给客户回复等。

    上述所有针对问题的解决方案都离不开执行、监督、控制与交流。在这几个环节当中，IT部门与行政部门为主要的执行主体，IT部门负责对DRP系统中的数据异常或每月数据质量出具报告，行政部门则根据IT部门的报告和数据质量方面的制度，给业务部门的KPI指标进行评定，也针对操作人员进行具体的奖罚；同时在培训这一块，由人力资源部门与IT部门负责完成。

    数据质量的影响因素

    数据事故，应该是由于数据的素质低劣造成的。调查机构Ｇａｒｔｎｅｒ称，《财富》１０００家大型企业所持有的数据，超过１／４是不准确、不完整或重复的，并预期有３／４的大型企业直到２０１０年前也不会或难以改善内部数据的素质。其实没有一家企业不受数据素质问题困扰，但就算有公司意识到问题所在，也常常会低估问题的严重性。

    数据素质会受多个因素影响而变化，包括存在性、合法性、一贯性、整全性、准确性、关联性、时间性等各个方面。存在性，即企业到底有没有某一项数据；合法性，即该项数据的数值是否符合一个可接受的范围；一贯性，是指如同一项数据不论储存在哪一个地点都有同一数值；整全性，是指数据元素与不同数据集之间关系的完整程度；准确性，即该项数据是否能够描述它应表达的东西；关联性，即该项数据能否恰当地支援业务宗旨；时间性，即该项数据是否能够及时地被反映出来。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。