搜索
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的日常运维工作的规范化，主要包括规范的问题管理（TroubleManagement），周期性审计(PeriodicReview)。前者是为了文档化各种系统问题和缺陷，以及相应的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系统中数据问题按模块分别分析。该分析表格如下：采购订货分销直营门店价格仓储物流存在YYYYYYY合法性YYYYYYY一贯性YYYNNNY整全性NYYYNYY准确性NNNNNNN关联性YYYYYNN时间性NYNNNNN以上各模块中，达到相应的数据素质目标即为Y，否则为N。经过对DRP系统中的各个模块的数据素质调查发现：数据治理主要针对的是数据的准确性、时间性、关联性。进一步对数据事故的原因分析，发现数据出问题往往是因为对数据的应用不够充分。比如物流配送，根据销售和库存信息来做，首先销售的信息，每天系统里面的销售信息和银行回款对比，有没有差异，没有差异就是对的。第二，配送是根据系统去配。慢慢的精细化，以前可能是粗放的，现在是一个环节套一个环节，根据这个系统来做，慢慢数据就会越来越准确。百分之百的准确不可能，当然也没有必要，因为随便一个环节都有可能出现串码。但如果业务部门发现DRP系统不管用，但DRP使用者就会用自己秘密地使用自己“更方便更可靠的工作流程/做法”。而管理层认为既然没有发生什么不妥，也就睁一只眼，闭一只眼。其实，任何绕道DRP系统的工作流程/做法都会产生DRP数据流之外的“数据暗流”。这种“数据暗流”会削弱企业对流程的控制，损害企业对流程的管理和进一步优化，自然DRP系统的数据准确性就更差了。那么，我们又怎样保证及时数据更新和避免绕道DRP的秘密的“更方便更可靠的工作流程/做法”呢?解决方案原则上很简单：持续提高数据准确率，定期维护订单修订等系统参数，以确保DRP产生的数据流与实际运作相符，通过基于DRP的工作流程的改进，禁止任何绕道DRP的行为。同时，借鉴了业内同行的“数据事故”分析方法，可以得到如下的因果图：!--[if!vml]--!--[endif]--针对上述发现的各种原因，经过进一步的统计与分析，发现主要的问题在审核流程缺失，KPI指标设定不完善、考核与处罚机制没有执行、指定时间内的数据不到位、业务不熟悉、操作不当上。相反，由于系统原因造成的DRP数据错误很少。而像流程原因导致数据错误出现的次数只占20%，但由于流程原因出现的数据错误影响程度最大。而像操作不当、指定时间内的数据不到位的情况出现较频繁，但对数据