首先，信息系统的建设缺乏全局的规划；

        所谓缺乏全局的规划（Overall Planning）。是指在信息系统的建设时，没有从整个企业甚至是整个产业链的角度去考虑信息的可用性、可获得性、可扩展性，上系统只管实现本部门、本业务领域或者本组织的局部的业务流程自动化问题。由于没有全局的战略，所以当系统建成后，跨领域的沟通和整合成为一道难题，首先也是最常遇到的问题是跨领域的业务数据没有关联性，无法提供全局的视角；另一种问题是主业务数据的不一致性，即大量重复的主业务数据存在不同的系统中，但是这些关键业务数据又存在一定的差异性，这也就是常见的业务语言不一致问题。对于已经建成的系统，解决这两个问题不仅成本相当高而且风险非常大，对系统本身的改造几乎是牵一发而动全身的——风险难以估量，于是各种各样的人工处理成为主流的解决方案，采用最多的是电子表格和Access，当然也有采用自动化的ETL工具做后台整合的，但是都是些头痛医头脚痛医脚的权益之计，一方面效果差治标不治本，数据质量没有保证，另一方面IT的工作量大幅增加，IT员工的劳动强度和职业发展成反比。举个简单的例子，某跨国体育用品公司，在早期实施的ERP系统中没有从全局的角度去规划系统的能力，没有深入的考虑完整的上下游产业链对业务信息整合的需求，而只是以业务流程为核心去驱动系统的设计建造，虽然初期的ERP系统本身设计的完善而稳定但是功能更多的是用于实现财务流程自动化和企业内部的订单处理、库存管理自动化，而连接上游供应商的产品计划和采购管理，连接下游分销商的订单管理，连接第三方物流的物流管理都没有作为企业管理的核心模块而被考虑实施。其结果是每个相应的分管业务部门各自为政，自成一体，IT被迫去开发大量的Excel/Access应用和外挂系统来整合整个产业链条上各个环节的信息，而这些外围接口系统的维护成为最令IT头痛的问题，可以说90％以上的支持工作都是在解决这些外挂系统的问题（ERP本身几乎没有任何问题和系统变更请求），而这些外挂系统的问题又主要源自于系统之间数据定义不一致。更大的灾难还在于IT部门没有办法提供全局的一致的数据用于决策支持，面对来自管理层的报表需求IT部门只能投入大量的精力去按订单生产，就算有所谓的数据仓库，其用途也像大垃圾桶，各种不同质的数据被想方设法的糅合在一起，不仅数据质量无法保证，数据模型无法建立，而且新产生的大量的ETL批处理程序的维护，数据监控和清理的工作量也成为IT部门不能承受之重，也难怪业务部门戏言Analyst就是做表格的，IT就是倒数据的。好在公司总部已经意识到问题所在（这里得佩服一下美国鬼子在IT领域的实力），用真正整合产业链的SCM系统将公司的业务从水平和垂直两个方向整合到一个一致的平台中，这一整合的更大意义在于信息的集成将整个产业链变成了打着自己Logo的虚拟企业——所有OEM公司，所有批发商代理商都变成了公司的一部分，成为公司降低成本牟取利润的工具，成为公司风险的最大分担者。

        其次，信息系统的建设缺乏长期的规划

        所谓缺乏长期的规划（Long Term Planning），就是不能从发展的角度去进行系统设计，通俗一点说就是目光短浅。任何一个好的信息系统都必须具有高度的灵活性和可扩展性，应该对可以预见到的业务和组织的变化和发展提供支持能力,所谓有容乃大——可以这样讲，一个真正的好的信息系统的容量应该只受限于其所依赖的硬件平台的容量。如果是一个僵硬的死板的系统，那么当变化来临时，IT部门要么选择投入大量的资金去升级系统，要么就是只有用人海战术来实现体系外的最大的灵活性。两种办法都是有百害而无一利，不要认为被迫的升级系统能给IT带来什么机会和价值，中断正常业务的风险，丢失历史数据的风险，数据整合的风险都是不得不面对的难题；人海战术就更不可取了，IT和业务部门都疲于奔命，尤其是人工整合中面临的控制风险，信息错误风险对业务的危害程度都非常严重，而IT本身也会在这种状况中失去同僚及管理层的信任和尊重，越做越没地位，越做越没价值，越做越没前途（我觉得这就是为什么最近IT 服务管理的理念甚嚣尘上的原因，IT犯了错误就发明个新理念来试图修正错误，显得IT永远是走在创新的风口浪尖的先锋）。再举个例子，某跨国公司在中国分公司硬是在一个九十年代中期设计的销售人员管理系统上做了一套基于Web的销售管理门户，而与之对应的国情是公司的销售代表每年以上百人的速度增长，员工流动率又据高不下，公司的产品线也一年一个样三年大变样（这是咱们国情，发展中国家嘛），而销售团队的组织结构根据产品线的变化不断调整，可是系统的设计者包括后来的实施者估计根本没来过我们的伟大祖国，而没有从这个行业的特点和中国的国情出发去考虑业务需求，用僵化的思维去设计解决方案，结果就是系统满足不了业务的变化，用户抱怨系统功能不行、消极使用系统，管理层抱怨无法通过系统获得有效的信息，结果是IT成为被投诉中心用户基础搞得相当差。由于没有长远的对变化的应对规划，系统中的数据很难在纵向提供可供对比的历史信息——IT们连最后一根稻草都没有抓住。

        综上所述，问题的核心都是数据，且不谈其对企业的影响，对IT本身而言，以上的问题已经将IT的从业人员打入了苦力的行列，而且还得时刻准备着背黑锅。

        那么作为企业IT，我们该怎样自救呢？办法很简单，我们要从问题中来又到问题中去，从根本上来寻求解决方案。相信看了前面的分析，大家应该可以达成共识即一切问题的源头都是“数据”，所以要解决这些问题我们只有以数据为核心来进行信息系统的建设，把数据放到核心的地位来看待，一切架构和设计以及战略规划都围绕着这个核心来进行。我们在此提出一个概念——数据规划（Data Strategy），用这四个字来概括以数据为核心的信息系统建设。所谓规划必是全局的和长期的，有不同意见者请参考我国的第十一个“五年规划”一词。本文所提出的数据规划概念包括紧密联系的两个部分——数据治理和商业智能，两个部门相辅相成，互为依赖。下面我们就来详细谈谈数据规划的这两个部分。

        一， 数据治理
        所谓数据治理也就是Data Governance，现在谈IT治理（IT Governance）的挺多，此处我也借用一下流行词汇包装一下概念以吸引眼球。数据治理其实是一种体系，是一个关注于信息系统执行层面的体系，这一体系的目的是整合IT与业务部门的知识和专家意见，通过一个类似于监督委员会的虚拟组织对企业的信息化建设进行全方位的监管，这一组织的基础是企业高层的授权和业务部门与IT部门的建设性合作。从范围来讲，数据治理涵盖了从前端事务处理系统，后端业务数据库到终端的数据分析，从源头到终端再回到源头形成一个闭环负反馈系统（控制理论中趋稳的系统）。从目的来讲，数据治理就是要对数据的获取、处理、使用进行监管（监管就是我们在执行层面对信息系统的负反馈），而监管的职能主要通过以下五个方面的执行力来保证——发现、监督、控制、沟通、整合。

图-1. 数据治理

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

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

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

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

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

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

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

        数据治理是个内涵广泛的基础工作，它的实现是建立在高级管理层的支持，关键用户的认可和参与的基础之上的。数据治理从数据产生的源头到其被加工处理后呈现给用户的终端这样一个完整的信息链的每个环节去控制数据的质量和IT服务的质量，对IT部门来说它既是挑战更是机会。如何获得高层支持，如何将业务部门纳入体系都是棘手的问题，但是无论外部环境如何，IT都可以首先从自身做起，改进思维、能力、知识和服务模式，变被动为主动，完善信息系统自身的“数据能力”，吸引基础较好的用户从有限的业务领域逐步建立数据治理结构，由点带面。

        综上所述，数据治理是如此重要的体系，它是一切有效的数据服务（Data Service）的基础，只有建立了一定的数据治理体系，我们才能进入到真正的商业智能时代：

        二， 商业智能
        商业智能是数据服务的目标、产出，也是IT的价值所在，对于大型公司来说，尤其是跨国公司，商业智能就是核心竞争力！没有商业智能的信息系统，就像一个没有反馈的开环控制系统，是不能实现真正意义上的流程自动化的，充其量也就是个会计电算化，仓储电算化的工具而已。商业智能是一种向参与企业运作管理的各个层面提供具有时效性的分类或汇总业务信息的能力，它不只是要实现向中高层管理者提供报表这样的简单任务，它的目标用户应该是所有参与者，它提供的是分析能力而不是简单的数字。这种能力是建立在高质量的业务数据、有针对性的数据模型和高性能的数据处理平台这三点之上的。

        高质量的业务数据是通过我们前面提到的“数据治理”来保障的，同时商业智能也向数据治理提供反馈信息用以对异常和错误进行监控。所以说“数据治理”和“商业智能”二者相辅相成。

        有针对性的数据模型是商业智能中的核心竞争力，也是最有价值的任务。因为要使业务部门能够获得商业智能所提供的分析能力，那么商业智能系统就必须向业务部门提供针对该领域而设计的数据模型，这是一种按照业务语言描述的数据模型，其设计是以解决特定业务问题为目标。专业化设计的数据模型，有以下几大好处：1. 易于商业智能系统的推广，因为使用了业务语言来建立数据模型，所以对用户来说很容易上手，既显得用户友好（User Friendly）又降低了培训难度。2. 将业务问题划分成清晰的模块，既有利于业务用户有针对性的分析，又有利于IT的支持和维护（Trouble shooting，Debug）。3. 被模块化封装的数据，有利于模型的重用，减少IT的支持工作负荷。和传统的用户提需求，IT做表相比，只有实现了数据模型才实现了真正意义上的商业智能，因为传统情况下，用户并没有参与任何数据分析，其得到的都是满足其要求格式的最终报表，而IT部门反而越俎代庖成为真正的分析业务数据的人员，这样的分工完全违背了业务部门和IT部门的本身职能，一方面会使得业务部门养尊处优，不能也不愿及时发现细节的业务问题；一方面又使得IT部门这一业务外行承担本身所不专业的业务数据分析工作，而不是将精力放在如何建立业务数据模型这样的核心任务上。其后果就是，无论是业务部门还是IT部门从业人员的素质都不断下降，企业的智能管理基本是空谈，领导拍脑袋的经验主义大行其道。

        高性能的数据处理平台其实就是高性能的数据仓库（Data Warehouse），其体现的是IT的基础架构的水平。同设计传统的联机事务处理（OLTP）系统一样，我们设计任何一个数据仓库时都必须考虑以下四点：性能（Capability），可扩展性（Scalability），可用性（Availability），灵活性（Flexibility）。

        1. 性能就是系统的可量化的能力指标，比如能同时进行多少个进程的运算，进行一条复杂查询需要多少时间等等。性能既包括硬件平台的性能，也包括数据仓库所能提供的查询的性能。前者较好估算和设计，但是后者就需要非常高超的数据库设计技巧和丰富的经验了，同样一个查询，糟糕的设计可能会耗费用户小时级的等待时间，而出色的设计可能只需要数分钟就能将查询结果呈现给用户。性能是一个非常影响用户感受的指标，很多用户尤其是高层用户往往会因为多等了几分钟而谢绝再亲自使用分析工具。

        2. 可扩展性就是系统对未来的发展的支持能力，这一点对数据仓库来说尤为重要，因为数据仓库是和企业的成长一起成长的，数据量是逐年递增，用户量，查询量也很可能快速增长，要想把商业智能做成一种IT Service那么我们就必须在设计系统时考虑好未来的扩展，一个良好设计的数据仓库应该仅使硬件平台的容量成为系统的扩张瓶颈，也就是只要通过硬件的升级就能将数据仓库的容量提升。要实现这一设计思想还是需要很多技巧和经验的，比如模块化的数据分割，使用硬件平台的虚拟技术等等。这里我想举个扩展性差的例子，某公司亚太区的ERP系统数据库由6个国家或地区共享，该平台通过划分不同的实例（Instance）来区分不同的国家，但是随着时间的流逝，有一天突然数据库满了，6个国家都忙起来清理数据，可是过不久又满了，毕竟清理是有限的，如此这般如同绑在一根绳上的蚂蚱哪怕只有一个国家超标那么其他五个国家都跟着倒霉，其实想想这个问题也好解决，用逻辑卷管理器将各个国家的实例划分到不同的逻辑卷上，那么互补干扰，而且扩展磁盘空间只是加块磁盘再简单的将卷容量调整一下而对应用系统是完全是透明的，更大的好处是可以方便计费和成本核算。

        3. 可用性是从时间指标上来衡量系统的能力，首先是系统在线的时间7×24或者5×8，这是在设计数据仓库一开始就必须确定的；其次是系统能够以什么样的频率提供信息，每天更新、每周更新、抑或是每月更新。频率问题是所有数据仓库的用户最关心的问题，也是必须综合数据源业务系统的能力和实际的业务需求来确定的。要实现上述可用性，我们需要用设计良好的ETL流程来保证按时保质的更新数据，这里就牵涉到了如何设计好Night Batch的课题，这是每个数据仓库项目都要慎重考虑的，市场上的ETL工具有很多，但是要用好工具则必须设计出完善的Night Batch。
4. 灵活性是对业务变化的支持能力，越是高速发展的领域变化越多，所以中国的企业变化都挺多的，那么如何让数据仓库（其实也包括业务系统）如何支持和包容这种变化，而不至于牺牲历史数据或者分析能力为代价呢？这就需要在设计数据仓库的底层数据结构时，充分考虑主数据（Master Data）的一致性和事务记录（Transaction Record）的时效性——事务记录应该是对事务发生时的上下文环境（Context）的快照（Snapshot），应该在其自身保存完整的事发时的上下文信息而不是通过外键的引用去间接得到相关信息。主数据虽然是可以变化的，但是对其本身我们要保证关键标识信息（Key Identifier）不可删除和修改,比如我们不要修改组织结构图中的职位代码，相互关联的主数据之间的关系可以改变，最常见的就是关系变更（Transfer），但是由于我们在事务记录中对上下文做了快照，因此这种变化是不会影响历史数据的。当然更好的办法是通过弹性域组合的方式去实现主数据的标识（Oracle ERP中大量采用的方式），这样可以实现排列组合式的灵活性。
可以说，以上四点应该是我们在进行数据仓库的设计时必须贯穿始终去考虑的，如果疏忽了任何一点，那么对未来系统的能力都是一种潜在威胁。

        在完成了上述的三方面基础工作——高质量的业务数据，有针对性的数据模型，高性能的数据处理平台——之后，我们终于可以将商业智能作为一种IT共享服务（Share Service）
提供给业务部门。通过IT共享服务的模式推广商业智能，将IT部门从繁重的重复劳动中解脱出来，使业务部门真正融入系统。

        “数据治理”和“商业智能”的结合使得建立Data Share Service的模式成为可能，而在这样的模式下，IT部门能将精力集中于解决棘手的技术问题和系统的运维，而各级业务部门通过IT提供的服务来获取商业智能的能力，IT部门就像发电厂提供源源不断的能量，而用户就像各种用电器只需要插上插头就可以获得能量。IT部门不在局限于解决某个业务领域的流程自动化问题，IT的价值可以被水平和垂直的企业各个方面所认可，IT部门还可以利用对数据服务的掌控而参与业务决策。当然这些都是美好的希望，但是从长远的角度来看，作为IT部门我们必须通过以数据为核心的策略来改进我们的系统，改进我们的服务，从而最大化我们的价值。