首先解释第（2）点：BI不一定昂贵，至少可以很便宜地起步；Excel提供的多维透视功能其实是BI中使用最多的一种场景，而且非常实用。很多IT圈内的人看不起Excel，很多BI的厂商（如BO（SAP）、Cognos（IBM）、Hyperion（Oracle）、MicroStrategy、Oracle、IBM，大概除了微软）在国内介绍其产品优势或客户困扰时，都会举Excel的例子：如大量的Excel文件、版本管理难、数据不一致（客户需要唯一的事实）、Excel中数据手工录入、数据容量小（2010以前的版本）等。很多甲方的人员初始一想，对呀，确实有这些问题，被厂商或解决方案供应商打动了。可是别急着被打动，因为他们都没有主动告诉你一个事实，就是所有主流的BI厂商都一定提供一个用Excel做前端来连接它们后端产品做分析的功能。这是客户的需要，很多的数据分析师（Power User）需要这个功能，这说明上述的困扰不是Excel本身的问题，是他们使用Excel的方法错了。为了实现单一事实的目的，完全不用手工录入数据，直接利用Excel的外部数据功能从后台的数据库或数据仓库中抓取数据，然后利用数据透视表来做多维度分析。我2000年在微软做销售的时候，每周review meeting上大家使用的MS Sales系统就是用SQL Server的Analystic service做的，后台每周定期从SAP系统中将订单数据导入DW，全球所有销售、业务管理人员、财务人员都可以用一个前台程序来选择自己的视角、层次、范围，然后导出数据到你自己的Excel文件中。不过大家使用最多的是预先设定好的几个Excel模板，如国家数据文件，大家review的时候离线打开这个文件，直接就是数据透视表，选择自己需要的视角、层次，看到的数据一致，数据量也不大，以中国为例，能够钻取到详单数据的文件也就几十M大小。

另外，如果有一些数据没有专门的业务系统，同时又希望多人能够Web化录入和分析，也可以简单地设计一个在线的表格系统，比如利用sharepoint service中的List或者Excel Service。我自己开公司的时候，有一个业务是做ITIL培训，同时教客户如何快速地做一个简化版的ITIL helpdesk系统，算是培训的一个添头。该ITIL系统仅花了我半天时间，利用Infopath的电子表单功能，来记录服务请求case，然后存放到WSS（windows sharepoint service）中的form library中，实现团队共享协作，跟踪处理的全过程。将form
library中的全部记录导出到Excel，用数据透视表来做多维分析，为管理层提供实时的监控和决策支持。Sharepoint service方便了多人用Web的方式录入数据，而form library实际上是一个List，从BI角度讲就是一个事实表，而该表的属性字段其实就是维度表，一个最简化的星型模型。后来在另一个客户那里，用类似的技术做了一个简化版的CRM，其实就是销售漏斗的管理，每个销售自己录入leads，然后用Excel透视表做漏斗分析。

上述场景的描述证明了我们可以用Excel搭一个便宜而又足够使用的BI系统。下面再针对原文《什么样的企业该使用BI》的摘录来一一分析：

l “根据数据量的多少来决定是否要使用BI系统：企业的数据量越大，那么BI系统对企业的帮助也就越大；利用一个Excel表格基本上就可以搞定了，这么一点数据量来利用BI系统分析，那是一种浪费。杀鸡焉用牛刀。”首先，上面的（2）分析过了，这种观点主要是基于BI系统很贵这个前提得出的，如果前提不成立，结论也不成立。其次，数据的价值和数据的多少是没有因果联系的。

l “创建不久的企业不适宜采用BI系统：由于没有历史数据，新企业无法进行前后的纵向对比分析；新企业还处在发展的阶段，一个中小型的BI系统项目的成本也在二十万上下。如果系统规划比较大的话，成本会更高。这个资金的压力，有可能会给新创企业的发展带来负面的影响；新办企业的管理团队不怎么稳定，因为各种原因，BI系统的关键用户流失之后，BI项目也可能会走下坡路。”没有数据，所以不上BI系统，这是很常见的一种观点，初听似乎很有道理，其实不然。（一）关于历史数据，首先，为什么一定要以年度为跨度来前后对比呢？季度、月度、周为什么不可以呢？这种低跨度的数据不是很容易取得吗？而且年度跨度对于大多数的管理决策需求场景来说，是难以忍受的，太长了。其次，同比、环比仅仅是一种分析的方法，而且更多的时候是给外人看或用来表功的。BI应用中最常见的一种场景其实是多维透视、钻取、切片，时髦的说法就是商业洞察。《宝洁的飞行驾驶舱》一文中描述的就是这种场景，微软年度的国家GM被鲍尔默Scrum也是这样的场景。（二）资金压力的问题，同样是基于BI太贵的前提，（2）解释过了。（三）管理团队不稳定，关键用户流失的问题不是BI项目独有的问题，用于更基础的业务系统（如ERP、财务）上也同样是一个风险因素。其实，越是上层的系统，通用性越强，和具体的管理者的管理风格关联程度不大，管理的视角和理论是九九归一的，大不了是增加一种新的视角。

l “BI系统是保健品而不是药品：企业如果现在遇到一些难题，如交货不及时等问题，上一个BI系统并不能够解决问题。一些售前咨询顾问将BI系统说的是无所不能、药到病除。这基本上是扯淡；BI系统是用来帮助企业管理者查找问题的原因。原因找到后该采取什么样的措施，还是需要管理者来设计、员工去执行。如对于交货不及时的问题，BI系统可以根据历史数据分析出造成这个问题的主要环节在哪里。在生产环节还是在采购环节？具体的原因找到之后，管理者在对症下药，去解决问题。”这段话的描述是有问题的。首先，它承认了BI系统能够发现问题的根源，让管理者对症下药，这已经是非常有价值了，医生治病首先要找到发病的根源，这么重要的一步为什么还要将其归为可有可无的保健品一类呢？其次，任何IT系统目前都不可能代替人来做决策，类似自动补货这种场景也是基于预先设置好的算法，还是总结了人的智慧结晶，所以也不能用这一点来苛求BI。最后，BI系统为CXO提供了业务洞察的能力，帮助他们科学决策，是管理层真正想要的那个“洞”，其底层的业务系统如ERP其实是钻头，客户买钻头的最终目的是要那个洞，所以BI绝不是保健品。

分析了原文之后，事实上还没有证明本人的观点“无论什么样的企业都应该上BI；什么样的应用系统中都应该有BI的模块，至少要有BI的思想。”下面来一一阐述：

以终为始。BI系统的需求调研最重要的是了解高层的管理需求，理解其管理的视角和理念，然后可以层层推导其对下层业务系统的要求，并在下层业务系统需求分析的时候提供决策、权衡的依据或判断准则。这样的观点可以同样适用于业务系统中的报表子系统需求，所以我的一个经验是调研业务系统需求时，首先调研各级管理者对报表子系统的需求，通过报表系统的需求来理解其背后的管理思想和视角，了解管理者对不同点的重视程度和价值大小，未来在分析业务系统其他部分的需求时，时刻不忘用报表需求这把尺子来衡量是否可以实现、是否方便实现、成本如何、难度如何、需要增加一些什么属性字段。

举个类比的例子，大家如果有家庭装修的经验，都知道装修有硬装和软装先后两个步骤。从实施步骤来说是先硬装修后软装潢，不过很多人在软装潢阶段会发现，遗憾一个个地暴露出来，如电源插座少了或安排的位置不合适（电视机挡不住）；或者插座的高度限制了家具的选择；或者墙纸的颜色、花纹和沙发不好协调等等。碰到这些问题，只好妥协选择次优的解决方案，对于一个舒适生活的家以及代价不菲的装修来说，总是一个遗憾。为什么会发生这些遗憾呢？其实考虑问题的顺序很重要，我们装修一个家，最终目的是为了获得一个生活舒适的家，在设计阶段，我们是先考虑软装潢后考虑硬装修的。我们生活的需要决定了软装璜的要求，而软装潢的要求又进一步影响硬装修的要求。现在生活水平高了，很多人在装修前，会选择专业的装潢公司做装修设计，大多都会要求画效果图（颜色、光影、风格等各种搭配）、结构图（具体的尺寸及摆放），同时在确定装修方案前，会去逛各种家具店、布艺店，确定未来家具的颜色搭配，家具尺寸，以决定对硬装修的要求或影响。在软装璜设计阶段考虑的越仔细，未来发生的遗憾会越少。以客厅的电视背景墙为例，电源插座和各种管线埋管属于硬装，电视机、电视柜属于软装。买插座的时候是买全二眼还是二三眼的呢？买几个呢？埋管的出口在多高的位置呢？这些硬装的需求如何决定呢？其实它取决于你软装是如何设计的。如果你的液晶电视是挂墙的，插座的位置、埋管出口的位置就必须事先考虑好，因为要考虑电视是否遮得住，空间是否方便插插头，电视下沿离电视柜有多高。如果电视是有底座的，这些方面的顾虑就可以少些。插座买什么眼的呢？买几个呢？本人在这方面就吃过亏，以为通用性好，所以买的都是二三眼的插座；算算电视机、DVD、机顶盒，所以买了4个插座，为未来的音响还留了扩展余地。可没想到，后来发现所有的电器都是两眼的，二三眼的插座都浪费了一个口；机顶盒由于换高清和点播的功能，多了一个“猫”要电源插座，后来电信的IPTV又多了一个盒子，还有游戏机都要电源，4个插座不够了，只好拉拖线板。早知如此，干嘛费劲装那么多插座，即费钱还要预先规划好，直接一个插座带拖线板，即便宜还灵活，适应未来变化。耳熟吗？类似的场景是否在您的IT领域中发生过呢？如果将软装比作BI，硬装比作底层业务系统，现在大家明白我说的“无论什么样的应用系统中都应该有BI的模块，至少要有BI的思想”是什么意思了吧，硬装在软装前实施，但软装要在硬装前设计，至少要考虑好。

上述家庭装修的例子用类比的方法解释了为什么要以终为始，用BI的需求来推导对底层业务系统的要求。再举几个IT的例子来更有代入感地解释为什么要先考虑BI系统（哪怕不实施），然后才设计业务系统。

案例（1）：我曾经为一家台资银行作过一次BI解决方案的培训，培训结束后的讨论过程中发现当他们在大陆开出位于陆家嘴的第一家分行时，由于没有考虑未来的BI分析（从地域或国家维度来分析业务），结果只用一个属性来表明地域，结果随着新分行的开设，必须修改数据库结构，增加表示地域层次的字段并人工补全该数据，才能基于地域层次来分析业务。这种BI的视角、下钻的需求决定了下层业务系统中必须有该属性字段，且每一个详单数据都要有该字段的值。

案例（2）：一家design house型制造业中型公司，生产全部外包，所以没上ERP，有财务系统和BPM系统（如费用审批、报销、立项申请、出差申请、请假等）。因为控股股东是政府的投资公司，所以比较容易拿到一些政府基金和科研项目，如小巨人等。政府基金到结项的时候要审计资金使用情况，如是否达到了企业自身配套资金的比例，资金是否使用完，是否按照报批预算的类别和比例使用的资金。没用完的资金要返还政府，当然没人愿意将落袋的钱再掏出来。一笔开支也最好能挂多个项目，哪怕政府规定是要专款专用。所以每次到了要审计的时候，负责研发和政府项目申请的总师办总要去求财务，因为要做账满足政府审计的要求，而财务系统中根本就没有这样的信息，还要根据政府的各种要求去做平，所以CFO和其手下要花大量的时间去调账，工作量很大，非常不乐意配合。小巨人项目调一次，科委的项目调一次、经信委的项目还要调一次，抱怨之大是可想而知的。政府的基金项目对于企业来说就是纯利，没人会因为麻烦而放弃，操作的人却怨声载道，如何调和这种矛盾呢？其实从BI的角度来说，各种政府基金项目就是多了一种统计的视角，这种需求决定了我们在每一笔费用中要增加一个字段来表明是否属于某种项目，在该企业小型的财务系统中做不到这一点，尤其是将一个费用同时归属多个项目。但对于BPM系统来说，只要在费用审批的流程中多加几个checkbox，然后和财务系统连接，不但不需要再录入一次凭证，还可以将凭证号返回给BPM系统，将费用审批的数据导入一个Excel后，一筛选就可以完成政府审计的要求。该例子同样因为BI的维度视角决定了BPM系统新增加的字段，以及关联的凭证号流程及两个系统的接口需求。

案例（3）：某大型IT集成企业规定销售负责签单，考核合同额，关系他们的Commission；实施团队负责项目管理，按照合同节点开发票给客户，考核Revenue收入（权责发生制），关系他们的奖金；财务部门按照合同约定的账期负责收入入账和催款，关系公司的现金流和资金风险；如果再加上CRM系统中尚未close的Leads金额，一共有4种广义的收入定义，如果不能预先定义好，大家数据对不上，互相推诿扯皮，鸡同鸭讲，没有唯一的事实数据就是常见的场景和必然结果。BI的多维度、多层次、多阶段视角就涵盖了这种多阶段的场景，底层业务系统中要详细记录所有的状态变化，未来才可以按照阶段分析。从Leadsà合同额àRevenueà现金流，每一阶段都是不同业务部门的主要关注点，涉及了各自的利益和责任，同时又互相衔接，每一指标是后续指标的先导指标，有重要的警示和预测作用，高层管理者即需要能看到每一种数据（树木），也要能全面看到互相关联的所有数据（森林），这样就不会犯很多业务系统上线后，高层管理者普遍感觉“只见树木不见森林”的怪相。另外，主数据MDM管理普遍被CIO提升到一个非常重要的高度，其实其针对的一个主要场景就是不同IT系统中数据定义的口径不一致问题。不过现实中很多MDM项目是由BI项目或多系统综合报表需求引起，立项的时候，很多IT系统已经上线了，属于亡羊补牢的阶段，大多采用增加一层映射的手段来解决，需要大量且复杂的数据处理过程。如果时刻将BI的精神记在心中，在设计任何业务系统的时候，就可以避免这种未来会发生的问题。

最后，拉一把大旗，为自己的论点增加一点背书。忘了是Gartner、IDC、SAP、还是国内的媒体说的，现在的BI进入了操作型BI、实时BI的时代。怎么能做到呢？就是无论什么样的企业、无论什么样的应用系统中都应该有BI的模块，至少要有BI的思想，无论你是用集中还是分散的BI系统来实现的。

Ps：本文多次“鼓吹”了Excel的数据透视表，虽然在微软工作过，但本文并不是为微软的BI解决方案来摇旗呐喊。而且大家仔细回味一下我描述的案例场景（如ITIL的help desk或者销售漏斗分析），会发现还是要一些开发过程的，或者要一些手工的处理过程来连接整个流程，也没有权限的控制，从某种角度来说，更像一个POC。但这么做是有很大好处的，无论是甲方的IT部门还是乙方，都可以用这种方式，用几乎零CapEx来搭建一个BI系统，让业务部门直观地体验到BI，也试用起来，这时候无所谓的立项或即使立项也金额很小，很同意得到批准。业务部门在使用的过程中来感受需要哪些视角（维度）、层次、阶段，需要统一哪些主数据，在哪些场景下使用，有什么业务价值，底层的业务系统需要哪些改造或数据处理，需要哪些配合的管理流程或定期的业务分析会议，风险在哪里，难度在哪里，工作量大的地方在哪里，业务部门需要配合的变化在哪里。搞清楚上述的各个方面，我以前一篇文章《立项前CIO要想清楚什么》中介绍的价值、风险、回报衡量、多久见到结果这4个方面就能够得到业务部门和IT的一致认知。而且这时候，业务部门往往会追着IT，告诉你这就是我想要的，能否更完善一点，使用更方便一点，这时候CIO无需用求人的口吻，“站直了”拿出你的立项报告，告诉他们完善的成本是多少，买些什么产品来完善BI系统。根据钱的多少、业务的需求、实际的IT系统现状来决策采用哪家的产品最合适（当然，本人的观点是：除了少数极端苛刻的情况，所有的主流BI产品都可以，只要你前面描述的homework做好了）。