Traditional businesses invest a lot in large data warehouse to capture and analyze transaction data. However, the loop of feedback is an open one. Executives make decisions based on the insights from the data and execution is a separated pipeline.

For internet-based services, the success is usually measured by its traffic volume and quality. The implication of traffic volume is scalability while that of quality is relevancy, namely whether the delivered contents are relevant to the viewers' interests. To achieve high relevancy, web sites collect a lot of user behavioral data. These raw data need to be aggregated to become knowledge that can be utilized in delivering contents.

In short, the key competence of an Internet service is to close the feedback loop and make data part of the service delivery system itself. In the meanwhile, everything in the pipeline should be able to scale up to meet large amount of requests. That is why cloud computing is so vital to an Internet company: data storage, analysis and serving should all be moved to cloud-based infrastructure so that the true value of data can be fully unleashed.

2. Create common definitions. Without common definitions, a BI implementation cannot succeed. And lack of agreement is a widespread problem in companies today. For example, finance and sales may define “gross margin” differently, which means that numbers will not match—in effect, negating the value of automation. To combat this problem, get subject matter expertise throughout lines of business from front-, middle- and back-office staff. At this stage, IT's participation should be limited to running the project management office and taking ownership of compliance and business standards and policies. Secondly, start small and choose only 10 to 20 key performance indicators and create standards and governance with them in mind.

3. Assess the current situation. You should analyze the current business intelligence stack and processes and organizational structures surrounding current BI implementations. Both IT and the business should be involved.

4. Create a plan for data storage. Many organizations begin with an isolated data mart, since it’s quick and cheap, but consider that this tactic means additional silos will need to be created as additional data storage needs arise, which can grow out of control within a few years. Something else to consider is whether to build and maintain a physical data warehouse or go with the virtual, so-called “semantic” layers to link operational systems. Traditional data warehousing means duplicating data, which means bringing in operations systems in real time will be next to impossible. You can save space with an abstract definition layer, but this is difficult to design, as is any metadata repository. Before even considering which vendors to choose, you must resolve this issue.

5. Understand what users need. The three broad classes of business intelligence users are strategic, tactical and operational. Strategic users make few decisions, but each one can have a profound effect—for example, should we close operations in Europe and open them in China. Tactical users make many decisions a week, and use both aggregate and detail-level information, and likely need updated information daily. Operational users are the front-line employees, such as call center staff. They need data within their own set of applications to execute the enormous numbers of transactions. Understanding who will use BI and for what purposes can show the type of information needed and its frequency, and help guide BI decision making.

6. Decide whether to buy or build the analytical data model. One size does not fit all. In general you may benefit from an out-of-the-box, industry-specific data model if you have a more homogeneous IT environment—such as one ERP, one CRM system. Do watch for extensibility and hierarchy flexibility. More complex enterprises may benefit from customization, although you may still want to consider beginning with an industry-standard model as a template or a set of guides (such as typical facts, dimensions and so on).

7. Consider all business intelligence components. Components that affect the success of business intelligence implementations include: metadata, data integration, data quality, data modeling, analytics, centralized metrics management, presentations (reports and dashboards), portals, collaboration, knowledge management and master data management. Be sure to define the architecture for all layers of the business intelligence stack; even though they may not be part of the BI strategy itself, they will effect the success of implementation.

8. Choose a systems integrator. Business intelligence implementations require guidance from a partner who has deep experience. Be prepared to spend $5 to $7 on services for every $1 on software, and cautions: Do not outsource the fine-tuning of business intelligence. The process requires a high degree of collaboration among end users, analysts and developers.

9. Think “actionable” and “baby steps.” Choose an end user, business analyst and developer to create a first proof of concept within a few days. Choose a few key performance indicators and build a few reports, then add new releases every few weeks.

10. Choose low-hanging fruit to start. Choose high-value, simple components to begin. For example, a sales analytics data mart may present high-value targets that also have plenty of existing models and best practices.

基础设施要好用、够用。这里着重要考虑的是总的数据量，进出流量以及增长率。换句话说，数据仓库最终要装多少数据，到底会承受怎样的输入输出压力，随着时间推移总量和输入输出的压力如何变化。通常用现成的Oracle RAC，按照OLAP来配置；也可以采用免费DBMS加中间件的方式组成系统；甚至连整个存储系统都自行构建，例如采用Hadoop。显然，Oracle搭建起来比较快，但成本相对高；后者需要相当的人力资源投入，但可以掌握实际技术，灵活性高。

原始数据清洗

主要是过滤噪音、打标签、补足缺失部分

数据导入

分布、存储、索引

数据归总

按照商业或者分析的需求计算统计值

数据仓库设计

明确商务流程

必须对具体的商务活动本身要有深入的了解和认知。

确认商务流程中的各元素和维度

理解系统中人、物、事件、活动以及之间的逻辑关系。确定如何用各种数据参数来描述每个元素和事件活动。好的数据仓库应该有一整套底层维度设计，上面的应用要尽可能地重复使用这些基本的维度定义。

确定商务流程的粒度

在怎样的宏观或者微观水平上描述这个商业流程

确定定量的事实

例如，营业额就是零售业的度量。

数据的流程总不外乎以下的步骤：搜集，清理，存储，查询，分析，理解，预测，决策，反馈。

搜集的过程看上去很直接：卖东西，就记住每一笔交易的时间和金额。其实，如果能够主动地根据对整个商业流程的理解去搜集更加丰富的数据源，那最终可以得到的“信息”也会更有价值。

清理和存储是为查询和分析提供技术支持。好的技术设施平台应该在整个流程中看上去并不显眼，但是用起来够用好用。当然这个基础设施是有成本的，技术投入和资金投入常常需要平衡。

查询是手段，更是观察问题的出发点。当一个人明确地知道该去查询什么的时候，数据就开始有了生命。查询要决定看数据的角度、维度和粒度。并且在不同的粒度上把数据的统计量计算出来。

数据的生命周期是短暂的，人们通常只关心离现在不远之前的过去和不远的之后的将来。如果搜集了海量的数据而无法及时处理分析，它们就会静静地躺在那里，除了占用存储设备，毫无价值。

分析是在查询和查询建立的中间数据上建立模型，试图解释过去、预测未来。

对于历史，需要“总结”。所谓总结就是求和、求平均、找最大最小。比如我们希望对具体的客户建立模型，他的购买历史就很重要，但是你如果把他的所有交易一一纪录下来，数据很全，却没什么用！你可以按照商品的分类求次数和金额的总和，确定他关心的分类；你可以根据时间的远近加权求平均，这样能更加细致地看到他最近的变化。最终，你需要的是一个“统计上的总结”，它可以是一组数字、或者一个公式。

在分析的基础上建立模型，就可以预测未来的表现。比如你总结到一个客户最关心电子消费类产品，你向他推荐iPhone就比口红要有效得多。而模型，就会自动地把这一套逻辑实现在你提供的服务中去。

如果你忽然发现用户中大量购买某一类商品，你的整个供应链就应该得到通知去应付新的情况。

如果你看到了趋势，但大潮流还没有到来。是应该跳下水去推波助澜，还是站在岸上静静观望，这是一个商业决策者必须做出的选择。无论是数据仓库还是DSS，能够给决策者提供嗅觉的依据是最高的价值所在。

最后，再用数据证明决策或者模型的效果；功德圆满。