此图是根据个人经验总结出的一个BI通用流程，适用于报表方案，多维分析方案，但不适用于数据挖掘的方案。

　　BI项目关键资源：业务专家，BI开发人员，业务开发人员。

　　业务专家的参与有助于提高需求的准确性，BI开发人员主要负责BI过程相关资源的组织和管理，业务开发人员配合BI开发人员确认数据及业务的相关工作。

　　下面对这个开发流程做一个解释：

　　首先，从报表下手可以很容易的掌握用户所关注的东西，结合业务系统以及数据结构可以有助于对主题有个大体的印象，同事对一些用户比较关注的维度和度量才能有个概念。

　　但是理解业务是个需要经验和理解能力的过程，不同行业都会有不同的特点，所以这里需求人员和业务专家的参与就比较重要。另外同样也不可忽视掉包括项目相关的文档的重要性。

　　前四个步骤要求一定是有BI经验人参与的。这样看过报表以及系统后，对主题，度量维度等才能有个大体的规划。试想如果连主题，度量维度都不清楚为何物，那么此处根本无法进行，包括后续的维度建模。

　　闲话：相对国内的BI来说，报表是很容易获得的，因为大多数项目都是上BI之前，先把用户手头上的报表给解决了——即使你不想要用户也会塞给你，是啊，一大堆报表看上去挺头疼的，管它呢，还是看看能发觉出什么先吧。

　　模型验证，根据已建立的维度模型验证是否能满足所有的报表需求。同上，此步骤必须要有BI经验的人做。如果模型满足不了统计的要求则重新建模。这里是需要一个反复迭代的过程，每次迭代的结果都要沉淀下来并且形成文档。

　　反向确认数据仓库结构，手动或者系统自动均可，自动生成来说SQLServer从2005就已经支持了，不过为了命名规范，还是手动来生成数据仓库比较有必要。

　　分析数据来源及SSIS开发。最好是由相关模块的开发人员参与，因为开发人员是对数据结构比较了解的，并且有SQL功底，而且还掌握业务。这一步的目的是填充数据仓库。可能需要适当SSIS培训。不过，这一步公认是最耗时的。同时，不是所有的统计项就是能从业务那边解释的了的，比如某些统计概念，可能在业务系统从来就没出现过，但是通过基本数据组合都可以计算出来。所以类似概念，确认计算公式等就需要BI人员承担起需求的工作去确认。

　　同时，BI人员需要与业务开发人员协同制作开发数据增量的方案，以配合SSIS的开发。还有一种比较好的方法就是开发人员写SQL然后BI人员用BI的方法将其整合到方案中，总之方法很灵活，关键的就是跟开发人员的沟通。

　　SSAS开发，生成多维数据集，确认分区，增量等操作，建议这里一定要符合SSAS的规范，命名约定等，这样会给后续工作减少很多麻烦。

　　SSRS等其它开发。这一步需要参与的人员可以灵活来定，因为是需要一定的MDX经验，而且有可能需要对团队进行报表开发培训。需要指出的一点是，即使到目前的SQLServer版本，用Cube作为SSRS的数据源开发报表还不是很舒服，相关问题有时间会详细阐述，同时也希望有些问题能在下一个版本的SQLServer中解决。

　　数据验证，等同于测试的过程，观察统计出的数据是否有异常，比如通过单个SQL查询的方式对报表数据进行验证。如果出险问题，根据问题的实际情况再去确认是哪个环节出的问题。

　　最后生产环境的部署，没什么好说的了，注意管理好SSRS的报表资源就OK了，比如为了避免相互覆盖，我们可以要求报表开发人员不使用共享数据源等。

　　此方案还可扩展为SSAS支持的多维分析项目，相信之前通过对报表等的分析各大主题已经成型了，所以完全可以直接把Cube拿过来用。相信多维分析的方式会吸引住客户的眼球。前台分析工具很多，再次不一一做介绍。

　　至于是否可以继续在此基础上扩展数据挖掘的经验，aspnetx认为，这里会有资源可以继承，但是能否满足数据挖掘的需求不好说，所以还得根据具体需要解决的问题来出发。

　　此外，aspnetx总结的BI项目中四大“最”：

　　最关键的部分：维度建模，这里准确与否将决定整个项目的成败，这里也最需要经验。

　　最有难度的部分：主题确认。对于业务复杂的系统来说，这是一个需要时间的过程，而且需要反复迭代。

　　最累人的部分:SSIS开发。SQL脚本工作比较多，很累人，而且也需要耐心。

　　最需要的支持：客户最高领导，记住一定要是说话好使的，遇到问题能当机立断的，否则会死得很惨。

　　这个方案可能在不同人想法里不太一样，最常见的是认为应该先对报表进行分析，完后再针对报表内容直接分析数据来源，然后根据数据来源结果决定如何建模。个人不建议这样的方法，这样的分析工作会变得很繁琐而且重复劳动多，当然可以先对需要统计的东西汇总然后再一项一项的分析，但是你不认为按照维度建模的方式去分析是一个更好的汇总吗。

　　总之，仁者见仁，智者见智。还请各位高人提出更好的实施意见。