【IT168技术分析】
    在过去的近一年的时间，本人开发及实施于一税务数据仓库，对于本人来说，是个机会，也是个挑战，以前从未有个此方面经验，在此，稍做些此方面总结，以下只为个人观点，如有错误，纯属必然。

   业务知识远远重于技术-当今数据仓库真正实施的是一些国家机构或些国有企业。真正估算数据仓库的效益是一件十分困难的事情，因此，对于多数私有企业来说， 不明确的软件投资往往存在很大的风险，这就决定了数据仓库的运用对于目前来说它的范围对于私人企业这一块是来是比较狭隘的。

    而对于是否该上数据仓库时，按数据质量这一层面来说，往往是一些销售系统，一些产品软件的数据质量比较高，而对于一些大型定制系统，系统本身可能就不是一 个完整可靠的系统，可能存在着很多潜在的错误，因此，在此基础上要做好数据仓库，是一个十分艰巨的任务，而在现实环境中，往往上数据仓库的就是建立在此基 础上的。存在既是道理。那么我们来分析数据仓库中存在的各种困难及如何把不成功因素降为最小。
（本人按自己所在项目及一些心得体会在此进行探讨，在此谈论的数据仓库主要针对本人经历项目-省级集中税务数据仓库）

首先：是否该上数据仓库
        对于这个问题，作为公司方来说，这个问题几乎就等于问卖东西的人我该不该买这东西。而对于甲方来说，他们上不上数据仓库无非是想在工作中多得到些有用的信 息（不排除其中有很多是面子工程），多些原系统中无法满足的查询、分析及一些能为决策提供的多方面宏观数据。因此，在项目竞标中，公司必然会说出客户需求 上数据仓库项目的N个理由及好处。项目竞标成功，那么售前人员的工作算是取的了成功，而他们所许下的很多承诺也不是他们所要做的，我做为一个项目开发及实 施人员，关注的是后者，不管怎样，项目竞标的成功才有我们要做的事。所以，上不上数据仓库已不是我们关注的，我们专注的是，最大努力做好它。

其次：数据需求编写阶段
    客户方经过前期竞标时公司方的讲解及数据仓库的一些初步了解后，此时可能在客户方的头脑中会有一种，数据仓库就是无所不能的东西，只要自己能想到的，那么 就能实现它。这是一个比较危险的暗号，在他们编写需求的时候，很有可能天马行空，闭门造车，想出很多不切实际、过细过杂的需求。需求是一项目成败的关键因 素，主要问题有已下几点：
(1),需求该由谁来撰写，现实中多数情况下是客户方，
     个人认为快速可行的方案是由公司方提出较核心的大部分需求，当然提出此需求必须在了解源数据的结构，确保需求实施中有取数的来源及取数的准确性，因此此步 骤的技术含量相当高，且对于繁杂的业务系统的分析也不可能是一时半伙就能解决的。公司方必须经过调查或其它实施中经验的总结，确保此部分需求为相对核心、 有实施意义及可实施的。而且此需求并非一成不变的，随着对业务的发展及自身认识的加深，以及各个项目中经验及教训，必须对其进行部分的取舍，以适应市场及 现状的要求。而为兼顾地方的特有的需求，由业务方提出部分需求，然后由公司及业务方共同讨论对其进行取舍，我们必须认识到，并非所有需求都能在未实施之前 确定它是否可实施，很多需求由于各种原因，只有在实施过程中才发现是不可行的、有问题的需求。

    这种由公司方提出绝大部分客户方西方结合自身特点提出小部分需求的方法，可以最大可能地保证需求的快速构建及实施过程的相对畅通（公司方提出的需求一般是 以公司实施为前提，一般为可行的方案，当然源业务系统与数据仓库都为本公司开发更容易实现）。当需求编写完成后，也并不意味着需求的定型，在以后开发的过 程中，可能是个不断修改不断完善的过程。