从和价格方面说说
北京永洪科技
其他答案（共1个回答）
永洪商智科技有限公司不错！
国产的商业智能软件方面，Kingbase Smartbi是国内较为全面，拿得出手的BI工具，是由丰富的BI产品研发经验的广州思迈特开发的。用友BQ貌似也不错，不...
Smartbi发展自原东南融通的bioffice，也算国内bi工具的元老了，功能比较全面。帆软是专业的报表工具，中国式报表做的不错，听说开始往BI方向发展，开始...
国内软件有广州思迈特公司产的Kingbase Smartbi，用于财务管理领域的用友软件和金蝶软件开发的BI工具等等，国外的有IBM的Cognos
这里我比较推...
既然想做虚拟充值了，那就要找个好的上家。
我做充值的时间也不长，但是自己已经总结出一套快生信誉，招揽客户的好方法，只要你虚心学习，脚踏实地，一定可以有相当可...
1、第1话：云霄飞车杀人事件
2、第49话：外交官杀人事件（下集）
3、第162话：空中的密室·工藤新一首次推理
4、第190话：危命的复活——第三个选择
答: 附加说明是可以选择的，选中附加说明，然后右边会出现一个按钮，点上就可以弹出一个选择框，可以新增，如果需要填写手写说明的话，可以使用摘要
答: “沉浸”是指人可以完全融入其中：各地的参与者通过网络聚集在同一个虚拟空间里，既可以随意漫游，又可以相互沟通，还可以与虚拟环境交互，使之发生改变
答: 重新安装网络游戏，网络游戏的程序或者驱动出了问题。
如果安装后还是有问题，应该考虑操作系统的驱动：如DX 等。也可能是操作系统本身。
大家还关注
Copyright &
Corporation, All Rights Reserved
确定举报此问题
举报原因(必选)：
广告或垃圾信息
激进时政或意识形态话题
不雅词句或人身攻击
侵犯他人隐私
其它违法和不良信息
报告，这不是个问题
报告原因(必选)：
这不是个问题
这个问题分类似乎错了
这个不是我熟悉的地区成功实施BI项目的几大要素
我的图书馆
成功实施BI项目的几大要素
接前文，，文章解释了BI元素框架（BI Component Framework）里的基础部分（Foundation），现在由下及上继续聊。首先还是先温习一下前面的架构图：数据搬来了，工具选好了，实施就能成功？前面我解释了大多数以技术为主导的IT部门做不好BI项目。如果说那些关键点是一个公司始终都要注意的，那么在实现部分（Enablement），我要提醒几个特别的风险点。首先是业务部分或者管理层的过度期待（over expectation）。随着BI项目的推进，我相信很多以前没有听说过商业智能的人会多多少少地去网络了解这个新事物。IT有一个特点，那就是“坏事不出门，好事传千里”。现在的很多商业智能厂商会出很多神乎其神的宣传和各种如科幻片一样的图表分析。因此很多没有项目基础和实际经验的人容易对BI产生幻觉，认为只要公司拥有这样的系统，就好似有了一个超级大脑来保驾护航。或者认为BI同excel一般灵活，随便改一下公式就可以看到结果。其实懂行的知道，BI的成功7成在于业务，3成在于技术。如今的BI只要稳定，自助，以及对数据分析技术以及大数据有良好的性能支撑，其他就看业务分析员如何驾驭工具和运用分析逻辑了。（这里笔者常参与帆软FineBI的项目实施，类同于Tableau，都是值得考虑的BI产品）其次是IT或者BI实施团队的过度承诺（over promising）。相对于传统的商业系统，BI算是一个新生事物，因此很多公司的实施团队经验有限，容易乐观地估计项目的结果。例如当项目组在基础阶段发现底层数据的质量高于预期时，便容易乐观地认为项目时间会大大缩短，或者过早地保证实现某种高级分析。BI项目的铺垫一般都很长，业务用户只有等技术人员把分析结果投影到幕布上时才能真正看到问题的所在。在这个阶段因为数据或者模型缺陷而把BI应用推倒重来的案例比比皆是。因此过早或过度地承诺可能会在后期给实施团队带来巨大的压力，建议在选型BI时要考虑乙方的项目实施能力和业务经验。再次是用户需求变更（user requirement changes）。因为BI属于新事物，很多业务用户在初期的需求收集阶段无法给出准确的意见，只有等看到演示（demo）时才大致明白BI是什么东西，并且会随着应用的完善而不断地提出修改意见。此外BI用户通常包含部门经理和一般业务人员。不同级别的人对公司业务的侧重点会有不同，因此BI团队经常要面对完全对立的修改意见。如何控制好用户意见和修改原则是BI团队要早早考虑的问题。最后是项目范围蔓延（scope creep）。基于国内项目的特点和从我个人的经验，没有一个交付的BI应用是完全按照设计文档来实施的。不是因为我们没有能力做好设计，而是当用户看到A功能后会立刻要求B功能，甚至提出C功能的预想。对于一般业务人员提出的新需求我们可以找些不明觉厉的理由来拒绝，但是面对管理层，我们可能会失去话语权（BI项目碰到高级经理的机会要远大于其他项目）。因此BI团队要按照项目实施方法论和自身的特点尽早做出调整。BI框架之实现部分（Enablement）不知道大家是否注意到实现部分的三层顺序。为什么分析会放在报表之后哪？其原因就是防止过度期待和过度承诺而最终导致大家不欢而散。通常BI项目会在后期碰到各种各样无法预先准备的问题，例如数据无法打通，模型设计缺陷，维度交叉造成的错误，或者无法达成某种分析结果等。此外BI应用是基于业务流程和数据的，IT测试人员仅能够检查计算结果是否准确，但无法判断分析图表是否符合业务要求，数据结果是否有商业意义等。这些功能上的测试必须在后期业务人员的配合下才能完成，也就是UAT。因此实施团队如果过早地承诺分析功能，那么将来等用户提出质疑的时候，我们很难判断这是数据的问题，逻辑理解的问题，模型的问题，还是前端代码的问题。如果在时间压力下开发人员开始补丁叠补丁，那么离恶梦就不远了。因此强烈建议BI项目先从简单的报表（reporting）开始！一张报表看似简单，实际上我们可以发现底层数据的问题，数据仓库和模型问题，系统性能如何，工程师是否合格，业务和算法的理解是否到位等等。公司报表一般都有固定的格式和业务流程，因此报表开发不会招致大量的用户需求变更和范围变更。快速实现报表自动化还可以拉近BI项目组和业务人员的关系，并增强管理层的满意度（buy in）。FineBI业务分析表除了报表，范围小、用户少、需求明确的任务也可以作为我们初期的着力点。例如单一产品MTD， QTD， YTD， YoY的销售数据汇总，一些简单的目标达成率等。简单任务完成之后，我们可以逐步加入例如竞品数据，然后就可以和业务部门坐下来制定一些相对复杂的分析功能了。前端自助分析报表是测试数据质量和理解业务的好机会。当报表完成之后，BI团队和业务人员可以继续挑战复杂灵活分析（analysis）。复杂分析的范围千变万化，有的是把PPT图表自动化，有的是根据业务经验提出更优化的分析（可能需要外部业务专家的介入）。BI团队可以和业务人员坐在一起共同研究和讨论分析方法，并当场向用户演示开发结果。BI团队也可以依赖自有经验和业务专家的能力，先内部设计，开发，然后再向业务人员演示，并收集意见。从我目前的项目经验来看，效率最高的方法是和专家顾问初步制定设计方案，简单开发之后再和业务用户确认。大数据（big data）是时下流行的概念。很多公司的高层可能会要求实施团队直接完成大数据项目。但是我认为直接从零到大数据的跳跃基本是自讨苦吃，除非公司有富有意义的海量数据，拓展的兴趣，和富有经验的实施人员和用户。因此我是在报表和复杂分析完成之后才建议公司去尝试探讨大数据项目。但请记住，大部分的公司在现阶段是不需要上马大数据项目的！请做好充分的调查和选型之后再考虑是否做这样的投资。如果报表和分析都一帆风顺，那么恭喜您，可以开始挑战目前BI行业里的最高难度：预测分析（prediction）。预测什么哪？如果您负责销售，那么BI可以预测未来的市场空间和合理的销售目标。如果您从事投资，那么BI可以预测公司未来的现金流甚至估值。目前受限于预测的复杂程度，绝大多数公司还是通过线下的方式，使用excel模拟多种参数，然后反复论证，最终敲定某业务的预测值或者目标值。因此牛牛爸到目前为止还没有这类项目的成功案例。我的经历更多是相对简单的情景（scenario）分析。所谓情景分析，就是在现有数据的基础上，通过手动或自动调整某些参数而达到检查其他指标的目的。例如我们可以通过调整工厂里某个环节的生产率来计算产品在未来市场可能的占有情况。无论是公司的一般业务人员还是高层，情景分析的用户参与度最高，得到的反馈也最丰富。作为实施者，能看到BI工具在实打实地帮助业务部门制定公司战略，心里还是很满足的。从工业角度而非学术角度，我认为预测分析和人工智能（artificial intelligence）在某种意义上存在交叉。人工智能既然是通过计算机来帮助和扩展人类的智能，那么通过对现有数据的分析和挖掘，然后做出对公司最优化的建议无疑就是最高等级的预测分析。当然AI不仅限于此，例如我们可以通过它来更高效地收集数据，通过它来建立业务模型，甚至通过它来编写算法程序等。这个话题目前还太遥远，因此我就不多介绍了。BI框架之贯穿始终的要素基础和实现部分的元素都可以在某个时间单独拿出来考虑，而接下来的三个要素我认为是BI项目成败的关键，要贯穿始终。团队配合我所说的团队包含小大两个范围：BI实施团队和公司。BI实施团队一般会包括项目经理（PM），业务专家（domain expert），商业分析师（business analyst），架构师（architect），开发人员（developer），数据处理人员（data analyst），测试人员（tester）等。一个BI项目团队的配合情况决定了这个项目的时间和质量。例如数据人员没有弄清楚某个数据的清洗规则，那么后期的开发人员就要花费大量时间去检查和修改程序。如果架构师，业务专家和商业分析师不能完全理解对方，甚至误解，那么后期的模型将会异常地难用，甚至作废。作为BI项目经理，最大的挑战是统筹协调项目组和业务人员之间的关系。只有和业务人员以及管理层建立充分的信任，BI团队才有可能顺利地获取用户需求，后期合理的修改意见，和最终的验收。之前我们提到很多部门视数据为私有财产，如果贡献给BI项目，那么别的部门很可能也会拿到这些数据。各部门之间有时也会互相推诿分析结果。如何打破公司内部的各种壁垒，使得各个团队之间能够互相配合，发现问题的时候能够心平气和地坐下来分析成因，便成了公司掌舵人和BI团队的当务之急。在项目启动初期，公司高层就应该意识到BI的重要性，并通过命令或授权等方式打通项目组可能会遇到的各种障碍。另一方面，BI经理也应该随着项目的推进，逐步建立和提高开发人员和业务人员之间的信任，并使双方进入良性循环。如果在实施阶段业务和技术双方的配合度能达到最高，那么所开发出来的产品就最为有效，公司也能从中获得最大的投资收益。如果双方的信任被打破，逐渐进入恶性循环，那BI应用最终可能会沦为少数人的数据采集工具而已。数据管控和质量国内做项目就不得不先强调人，因为人最难协调，出的问题也最多。但是在国外的行业总结里，数据管控和质量永远是放在第一位的。数据管控考虑的是数据的所有权，更新频率，访问权限，数据安全，风险，数据的敏感度等等。您可能要问我为什么在项目初期，而不放在数据建模的时候才考虑管控。在初期当业务部门还心存戒心的时候，如果我们能够明确提出数据所有权和将来的访问权限，那直接获取全部数据的可能性会非常高（避免了高层出面）。如果在当初没有确定各部门的数据所有权和义务，等BI上线，实施团队解散之后，我们会尴尬地发现一个新的荒草地又诞生了（想想您的公司有多少无人认领的荒废系统？）。此外，站在工作的角度，如果BI的所有权不属于本业务部门，但是要求业务人员在忙碌之余还要去维护系统内的数据，然后分析的结果供其他部门使用，凭什么？！如果在项目初期没有解决此类问题，那么积累到后期就会非常麻烦。数据质量就不用多解释了，基本的道理大家都懂。数据质量不仅存在于单个数据本身，也存在于多种数据整合之后是否能达到预期的效果。有两个环节可以提高数据质量。一个是同过ETL过程，在抽取和转化阶段根据业务定义好数据的清洗规则（data rules），例如如果一家经销商当月上报的汽车销售数据是一亿台，那我们很直观的就知道这是个“脏数据”。另一个提高的地方在数据仓库层面。我们可以根据存储规则或某些工具对数据进行预先处理，例如把销售MTD和YTD的数值先计算好之后再存入数据仓库，这样的话架构师就可以构建更有针对性的模型。垃圾进，垃圾出（rubbish in，rubbish out）！如果您不从源头控制好数据质量，不在乎这个事情，那么等错误的结果给公司造成损失的时候则为时晚矣。工作流程和文化的改变牛牛爸遇到过很多类似的尴尬要求：经理看到BI后说这个好，然后要求下面员工把最新的截图放到PPT里然后发给他看。您已经拥有访问权限了，为什么不自己直接查看哪？当我们调研用户需求时，很多业务人员会信誓旦旦地问BI页面能不能做的和现有PPT一样。现在很多BI工具，例如Tableau，可以把界面做的非常灵活。您为什不在下次会议上直接把BI图表投出来，而还在手工制作那些滞后的片子哪？这里又给BI团队带来了新的挑战：从一开始就应该慢慢地引导用户转变思维，并最终带领公司在工作上和文化上做出革新。其实想通过一个程序就改变公司的做事风格，说起来容易，做起来太难。在过去实施SAP这种大型的瀑布式BI项目时，用户往往要等很久才能看到BI应用。由于高昂的顾问费用，很多用户基本上看几次就正式接收了，完全没有一个过度的过程。好在现在的工具都支持敏捷开发，我们可以快速地理解用户需求，建模，拉图表，设权限，然后交付给用户试用。我们会引导用户在实战中使用这些工具，这样拿到的反馈和修改意见也最有意义。工作思维的转化需要一个漫长的过程。但愿在不久的将来大家会习惯这种新的工作方式。两种实施策略框架介绍完了，基本上都是我的经验理论，您要是实战的话可能没有什么帮助。因此接下来我会介绍两种BI项目实施方法论。第一种是由上而下（Top-Down）的项目实施方法。第二种是由下而上（Bottom-Up）的方法。由上而下首先关注的是某一个部门或者团队的BI解决方案。其目的是解决数据相对简单，范围清晰的业务经理（business unit manager）的分析任务。由下而上一般由IT部门牵头，先从公司的系统和数据着手，分析清楚之后再建立统一的BI平台，然后在平台之上搭建适合各部门的应用。我会在下篇文章继续介绍由上而下的实施方法。
馆藏&26283
TA的最新馆藏
喜欢该文的人也喜欢Java开发有钱途和BI开发有钱途 - ITeye问答
最近BI比较火，就找了个BI开发的职位。
四年Java开发的经验，管理软件的开发。
薪资和现在几乎没什么变化，多了一点点，可以忽略不计。
咨询了一下，发现新公司的BI开发就是使用Cognos或者BO这样的商业BI工具做一个项目，
突然感觉和现在做的Java开发不一样了。
Java开发什么都是自己做，BI开发就是有点像使用工具。
突然有点迷惘了，不知道Java开发和BI开发哪个更有前途。
当然，学精了，哪个都有前途。我就是不知道，哪个大方向更好一些。
就是害怕BI开发说白了类似于一个Cognos/BO工具的实施人员，从不写代码，配置配置软件就完事了。
BI开发是我想象中的这样吗？
很负责任的告诉你，是的！
国内大部分公司的BI都是在为大公司的产品做实施
而BI的最大困难，其实的确是实施。
数据仓库的建立，是起决定作用的。
当然，假如想开发BI产品。 去IBM吧。。。。
个人认为，对于BI实施人员当然也有前途，其实主要是看你的兴趣所在
已解决问题
未解决问题业务人员不造如何提出BI需求，老板不重视BI项目怎么办
业务人员不造如何提出BI需求，老板不重视BI项目怎么办
ps：该文章是在天善问答社区看到一篇经验分享帖，感觉不错，借此分享给行业伙伴们
问题来自天善智能社区&，正好上一个礼拜有一个朋友在微信中问过我类似的问题，但是一直没有回复这个朋友，正好一并回复。
这位朋友的问题和这个差不多，大概背景是：目前公司对于 BI 项目也有了投入，BI 团队有两个人，主要是使用一些开源的 ETL
工具从不同的数据源中抽取数据并产生部分报表提供给业务人员。困惑就是：第一，业务人员不知道如何提出需求？
没有需求就意味着拿到的数据不知道如何分析。第二，BI 团队希望扩大，比如按每个业务部门配一个 BI 支持，即扩大 BI
团队以提供对不同业务部门的业务支持。但是老板在此时是不同意的，因为没有足够的理由来说服老板增加对 BI 团队的投入。
这两个问题可能是所有甲方 BI 团队会遇到的问题，本文刨去对 BI
官方的定义如何可以帮助决策者如何如何如何有价值，在此我来谈谈我个人在经历过一些项目的想法。
业务人员不懂得如何提出 BI 需求怎么办？
这种情况通常发生在一些从来没有上过 BI 系统或者刚上 BI 系统的甲方企业中，业务人员对于 BI 的认识非常模糊，不清楚 BI
系统到底在哪些方面能够帮助到他们。稍微好一点的情况是业务人员请求 IT 部门将需要的数据导出到 Excel，然后业务人员自己通过
加工数据、汇总和制作成图表作为他们日常工作的日报表、周报表或者月报表，这些报表通过开会或者邮件的形式展示向上级展示或者汇报。当然也有那种连
电子表格都没有的，还是传统的采用纸质打印的报表。这种报表通常是直接来自于业务系统的查询界面，格式全部定制化好，通用性很强但是分析深度不够。
除去这两个因素来说，另外还需要注意的是：不是每一个业务人员都懂得自己要什么数据的，一方面可能是业务人员自身的业务经验积累的不够，二是业务人员自身对待工作的态度可能也不够积极，不觉得上了这个
BI 系统就会对他们的工作效率有什么改变。
考虑到以上这几种因素，我们的切入点应该是什么？ 非常简单 ——
解决现有报表和潜在的对他们来说比较重要的报表，在这个环节省掉他们要花费的时间和精力。
第一步，收集和整理他们现在工作当中所用到的频率比较高的那些报表，通过这些报表了解他们现在重点聚焦的是那些业务和重点数据。思考在这个环节中，哪些数据是可以直接加工的，而哪些是需要他们大量计算和汇总然后才能得到的图表。赢得客户很重要的一个信任点就在这个环节，假设有些数据图表是经过多个环节计算然后调整最后出现一份比较干净的数据继而汇总成图表，这个过程通常情况下可能是每天一次、每周一次，每次30分钟到1个小时并且还容易出错。但是通过
系统，这种深加工的报表是完全可以把业务人员解放出来的，工作效率的提高与数据准确性的风险转移，通常情况下业务人员还是非常乐意看到这样的
BI 系统上线的。这种 BI 需求并不是由业务人员直接提出，而是先要解决现有的重点业务需求。
第二步，除了现有的报表需求之外，需要与业务人员共同沟通重点的业务过程和报表。在这个过程中，重点研究的是引导业务人员构思他们之前曾经想关注的业务数据或者
指标，但是可能是因为这种数据加工过于复杂他们自己就放弃了，但是现在可以尝试把这部分的业务给引导出来一起讨论。这个过程不仅仅是帮助业务人员梳理和准备他们的需求，也是
需求分析人员快速熟悉和深入业务场景的很好的一个机会。在这个阶段可以落实一些具体的报表分析原型让业务人员来确定并提出新的改进意见，通常情况下在这个环节是可以挖掘到很多有价值的信息的。
所以简单总结，第一步是针对现有报表进行业务范围确认，第二步是基于现有重点业务进行重点延伸。有了这两个阶段，完全就可以先划分项目的实施边界，把已经确定的需求实施落地，这样既可以满足他们的现有业务，也可以满足一些重点业务关注的点就可以了。除非我们的需求分析人员本身就是这个业务领域的解决方案专家，对于这个业务领域的
BI 需求已经了解的非常透彻并且已经有很多的项目案例落地。
BI 项目的开展是一个迭代的、需求驱动的项目过程。BI
项目可大可小，可以规划的很庞大，也可以规划的很聚焦。我个人认为解决好了前面两个步骤基本上 BI 项目就已经有了一个很好的开端：
1. 解决了现有业务人员重点关注的数据报表，不仅对他们现有的工作没有影响，并且提升了他们的工作效率。
解决了业务人员曾经想关注的数据但一直没有做到的问题，不仅拓宽了他们基于数据对业务的判断视角，并且也增加了在老板面前加分的机会。
所以，一个好的 BI 项目开端应该充分站在业务人员的角度去思考，我们到底能帮助到他们，成就他们什么？
最后再来回答业务人员不懂得如何提出业务需求怎么办？
至此，有了上面这两个阶段，已经足够解决大部分重点的业务需求问题。通过这种方式可以促使业务人员对 BI
系统重视起来，我们已经给了他们一个很良好的引导。当他们每天在逐步适应 BI
系统上的报表数据分析之后，一旦有任何的数据变更需求、分需求第一个想到的自然是 BI
团队，不用我们特别去引导他们自己都会知道需要什么数据需要什么分析的角度。所以到时面临的不是业务人员不知道如何提出业务需求的问题，转而会痛苦这些需求提出来了
BI 团队有没有那么多资源支持的到，数据质量、清洗规则、需求细节等反复确认修改和实施过程了。
在 BI 项目初期阻力最大的需求分析和调研的过程以及梳理业务人员对 BI 项目的正确认识的过程。在项目初期，不乏业务人员对 BI
项目不重视、配合程度不高的问题。但是一旦前几阶段任务完成 BI 项目上线，业务MM逐步认识到 BI系统的价值之后，也不乏经常跑到 BI
项目组里面撒个娇请求支持，比如新上几个报表或者在自己动手做报表的时候遇到问题寻求一下技术支持。
如何说服老板增加对 BI 团队的投入
任何投入都是需要成本的，如何说服老板增加对 BI 团队的投入其实重点是让老板看到 BI
到底在公司给企业带来了多大的价值。当然，价值可以是有形的，也可以是无形的。对 BI
的投入很明显是属于无形的，不像销售或者其它投资就可以马上用数字来衡量投入和产出比。
那么如何来增加 BI 的有形价值呢？用户，即 BI 系统的使用者。虽然我们对 BI
的定义很广泛，既有数据仓库也提到了数据挖掘，决策分析等等。但是 BI 实际上最终与用户发生关联联系的就是报表数据。也就是说 BI
系统的用户绝大部分就是报表用户，报表用户的数量变化和级别变化就是 BI 系统最有形的价值。
可以想象一下，这样的一组数据变化：
在 2013年，某 BI 项目系统的报表用户数量涉及到了 3 个部门的30位用户，4/5的用户均为普通业务人员，1/5的用户为
Team Lead，平台总共有 100 张报表，总报表执行次数为 1200 次。
在 2015年，某 BI 项目系统的报表用户数量涉及到了 12 个部门的 300位用户，5/6的用户均为普通业务人员，1/6的用户为
Team Lead 和部门经理，平台总共有 2000 张报表，总报表执行次数为 12000次。
在 2013年，后台数据仓库 ETL 包总共运行时间是 1 个小时，在2015年，ETL 总共运行时间是 6个小时。
这组数据说明了什么问题？ 非常明显可以看得出自从 BI 系统从2013年上线之后，基于 BI
平台的用户人数在不断倍增，从最开始的3个部门扩展到12个业务部门，用户群体从最初的业务人员扩展到高层用户。在很多情况下，我们无法使用直观的数字来判断什么样的一个
BI 平台是一个成功的，到底给我们企业带来了哪些盈利和工作流程的改善，但是我们却可以通过 BI
平台上的使用用户、使用面和覆盖程度做出判断。当越来越多的用户在工作过程中愈来愈依赖 BI
系统，自己制作越来越多的报表来解决实际业务数据分析问题，覆盖人群从最开始的几个部门逐步覆盖全公司所有部门，基本用户从普通业务人员扩展到
Team Lead 和高层包括移动端用户的增长，报表执行次数...。
所以一个 BI 系统的价值是使用者赋予的，用户的依赖性越大使用程度越高说明 BI
系统的价值就越大，因为没有人会帮时间浪费在一个无助于业务提升的系统之中。我们经常在讲 BI
系统到底对用户有什么价值，对于业务有什么价值，数据分析对于业务有什么样的价值，这些基本的道理大家都懂，但是如果能够辅助上面的这些监控数据让业务人员替我们发出声音不更好吗？
讲几个实际小案例：
第一个，某客户公司通过项目外包的形式完成了几期 BI
项目然后上线运行，各个部门的用户每日该看报表的还是看从来都没有觉得有什么问题。偶然一次月末月初要出大量的报表汇总的时候，BI 系统
ETL 部分由于源数据系统出现异常数据导致 ETL
数据仓库报错终止，新的统计数据迟迟不能发布，导致整个公司各个部门在月初总结例会无法开展，由于自身没有专业的 BI 团队维护这个 BUG
的修复花费了大量的时间和精力才得以解决。
第二个，某客户公司最初刚上 BI 项目的时候，BI 项目组还得不到重视，业务人员也不是非常重视，连基本的需求都提不出来。BI
系统上线之后，业务人员越来越依赖新的 BI 系统，逐步放弃了以前手工作业的方式。到后来 BI 项目组资源严重不够，业务组 MM
经常跑到 BI 项目组撒娇求支持。
第三个，某客户公司一个部门的自定义 Ad-hoc 报表开发达到了近 1200 张，BI
项目组给各个部门业务人员提供技术培训让其掌握基本的报表开发技能，BI
项目组只负责基础的数据仓库搭建和维护。后来共10余个部门200多位业务人员自行开发了共计 2000 余张报表，报表使用人数从最初的
30多人达到 200 余人。
需求在这里，BI 系统只要解决了用户的问题，只会越来越受到重视。
在新的产品采购有限的情况下，在业务需求在源源不断的被提出的情况下，BI
团队的工作量在持续增长，势必会影响一些业务需求的实现。当业务人员的需求得不到满足和及时响应，这些矛盾一定会被提出，新的资源计划一定也会被提出。该采购新的产品工具就采购新的产品工具，该增加人力资源就增加人力资源，BI
团队的角色不是催促高层下决定，而是应该摆出事实数据和实际工作量的变化让高层看到这种投入的必要性，把决定留给他们。
再来简单总结如何说服老板增加对BI团队的投入？
第一，服务好已有的用户，真正的让他们认识到 BI
的价值，真正的为他们创造价值。（什么多维分析、探索式分析、分析方法等自行与用户填充）
第二，监控好所有的基础数据，BI
平台用户增长数量、报表的使用频率、常用报表和非常用报表使用频率、数据量增长趋势、业务数据源表数量增长趋势、用户级别变化趋势..等等，这些基础数据就能凸显
BI 平台的价值高低。
第三，摆工作量、当前实际工作量，在饱和状态下可以完成的最大工作量；当前任务预估所需要的工作量；未来工作预估的工作量。这些都可以根据业务部门的支持需求来衡量，工作量大了支持力度自然就不够，不够自然就需要投入和产品改善。
对于这个问题“业务人员不知道如何提出 BI 需求，老板不重视 BI
项目怎么办？”相信每个人都有每个人的处理方式与手段，上述的一些观点和看法是站在一个甲方人员的角度来考虑这个问题的。对于第一个问题，我觉得还是相对比较容易解决。对于第二个问题，因人而异，有的老板就可以非常重视投入；有的老板也非常重视，但是凡事就需要有一个明确的说法和条理，这种对于
BI 价值的思考过程其实也是非常有价值的。换个角度，从实际项目中与业务人员互动的过程中其实也可以看到 BI 系统的不可替代。如果一个
BI 项目上线之后可轻易代替甚至完全忽略不用，只能说是项目的失败，而不是 BI 的失败。BI
系统价值有高低，仅在于如何引导，如何用产品 + 业务 + 分析经验 + 指导决策发挥的更好一些，而我们要做的就是这个推手而已。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}