项目管理手记(五) DRP项目中的数据治理

项目管理手记(五)

DRP项目中的数据治理

童继龙/[email protected]

由于我本人的项目经验在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系统“数据治理”的思考。

数据治理的理论及方法

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

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

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

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

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

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

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

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

“数据事故”分析

为了解决数据事故问题，笔者协调财务、计划、销售、IT等部门成立了专门的“数据治理”项目小组。数据事故，应该是由于数据的素质低劣造成的，根据调查机构Gartner称，《财富》一千家大型企业所持有的数据，有超过四分一是不准确、不完整或重复的，并预期有四分之三的大型企业直到2010年前也不会或难以改善内部数据的素质。其实没有一家企业不受数据素质问题困扰，但就算有公司意识到问题所在，也常常会低估问题的严重性。何况，数据素质会受多个因素影响而变化。因此，要应付这种挑战，一次性的行动难以奏效，企业务必持之以恒，甚至采取能改写企业文化的行动才会有效。

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

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

数据治理，需要对数据的素质提出一个定义，笔者认为数据素质涵盖以下多方面：

<!--[if !supportLists]-->ü <!--[endif]-->存在 (即企业到底有没有某一项数据)

<!--[if !supportLists]-->ü <!--[endif]-->合法性 (即该项数据的数值是否符合一个可接受的范围)

<!--[if !supportLists]-->ü <!--[endif]-->一贯性 (例如同一项数据不论储存在哪一个地点都有同一数值)

<!--[if !supportLists]-->ü <!--[endif]-->整全性 (数据元素与不同数据集之间关系的完整程度)

<!--[if !supportLists]-->ü <!--[endif]-->准确性 (该项数据是否能够描述它应表达的东西)

<!--[if !supportLists]-->ü <!--[endif]-->关联性 (该项数据能否恰当地支援业务宗旨)

<!--[if !supportLists]-->ü <!--[endif]-->时间性 (即该项数据是否能够及时地被反应出来)

针对以上数据的素质，再结合DRP系统中的相关模块，对DRP系统中数据问题按模块分别分析。该分析表格如下：

	采购	订货	分销	直营	门店	价格	仓储物流
存在	Y	Y	Y	Y	Y	Y	Y
合法性	Y	Y	Y	Y	Y	Y	Y
一贯性	Y	Y	Y	N	N	N	Y
整全性	N	Y	Y	Y	N	Y	Y
准确性	N	N	N	N	N	N	N
关联性	Y	Y	Y	Y	Y	N	N
时间性	N	Y	N	N	N	N	N

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

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

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

<!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter" /> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0" /> <v:f eqn="sum @0 1 0" /> <v:f eqn="sum 0 0 @1" /> <v:f eqn="prod @2 1 2" /> <v:f eqn="prod @3 21600 pixelWidth" /> <v:f eqn="prod @3 21600 pixelHeight" /> <v:f eqn="sum @0 0 1" /> <v:f eqn="prod @6 1 2" /> <v:f eqn="prod @7 21600 pixelWidth" /> <v:f eqn="sum @8 21600 0" /> <v:f eqn="prod @7 21600 pixelHeight" /> <v:f eqn="sum @10 21600 0" /> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect" /> <o:lock v:ext="edit" aspectratio="t" /> </v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" style='width:468pt; height:231pt' o:ole=""> <v:imagedata src="file:///C:/DOCUME~1/Drate/LOCALS~1/Temp/msohtml1/01/clip_image001.emz" o:title="" /> </v:shape><![endif]--><!--[if !vml]--><!--[endif]--><!--[if gte mso 9]><xml> <o:OLEObject Type="Embed" ProgID="Visio.Drawing.11" ShapeID="_x0000_i1025" DrawAspect="Content" ObjectID="_1246945978"> </o:OLEObject> </xml><![endif]-->

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

数据治理方案

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

考核机制：数据治理的问题其实也是企业管理的问题，而出现问题往往是没有一个比较好的考核与激励机制。在数据事故当中，出了问题之后，IT人员急着去查找原因，财务部门则因为数据报表出不来而干着急，而往往是事故责任部门往往是数据生产部门，而不是数据消费部门。所以，没有好的考核机制，往往事故在出现了之后无据可依地进行处罚，导致员工情绪极大。因此，我们定制了如下考核办法：每月结束，涉及到DRP系统中数据操作的，出现错误次数在5次(含5次)以上的，每次罚款10元，充入公司奖金池；如果每月操作零错误的，则从奖金池内奖励30元；各部门的年度KPI指标中加入DRP系统数据操作正确率，并给予一定的权重，此举目的就是为了能够使各业务部门经理引起对DRP系统数据操作正确性的重视。

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

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

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

流程：物流是最头痛的问题，也是处理起来最难的问题，其实关于业务流程管理(BPM)是一个很大的话题，在这里呢，只能说是，根据企业实际情况，一点点的改进，因为流程改进是一个伤筋动骨的事情，包括：原有流程是合适企业应用的，但现在不合适了怎么办？原来的流程是由某个部门负责的，现在职能要细化，要分开怎么办？所以在这里就不再铺开来讲，但以后有机会进一步进行论述。

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

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

而IT部门的系统故障及错误等问题，则落实到财务部与行政部具体负责进行考核，这也就是一个监督机制，IT部门作为DRP系统的管理者，也是要被各个业务部门进行监督的。

而由于涉及到各个业务部门的各个业务环节，特别在加入了绩效考核之后，会引起业务部门对IT部门的敌视，甚至是对DRP系统的敌视，因此，所有策略的实施都需要IT经理与数据治理项目小组的负责人加强沟通。特别是要注意循序渐进，切忌要求一步到位，否则的话引起业务部门的不满与反弹，有可能事情会变的更糟糕。