如何购买BI系统.doc

引言相对于关系型数据库，编程语言，文本处理，图像显示系统，商业智能产品之间的差别更大，从而导致在选择BI时的更大困惑，不同于普通的软件产品，IT人员和最终用户都不能够单独做出最好的BI选择。也就是说，BI系统的评估需要用户和IT人员的共同努力。然而，在许多公司中，IT人员和最终用户没有共同语言，在交流上存在着障碍。即使他们试图一起工作，但是他们总是有着不同的观点。结果，我们经常看到公司做出奇怪的产品选择决定。选择错误的工具会导致严重的后果：l 最差的情况是项目完全失败，所有软件开发和服务费付诸东流，期望的商业利润不能实现，损失高达数百万。l 典型的情况是，项目的部分功能可以使用，开发方认为这是成功案例。这种情况很普遍，而且比第一种情形更糟的是，更换这个失败的系统较难，从而造成更长的潜在收益的损失l 一些项目具有在整个企业部署的雄心，但却从来没有超越最开始的部门应用。他们可以给最开始的用户带来收益，但是却不能给项目的下一阶段提供帮组，避免再次重新选型。l 决策小组可能被供应商夸夸其谈的宣讲误导，结果采用了十分昂贵的方案来解决一个简单的问题，虽然可用，但是花费的成本比一个更适合的方案高出很多倍。记住，虽然我们给出了选择正确的BI的建议，但是这只是BI成功实施的第一步。基于证据的选择似乎每个BI产品都声称他们是高效的、创新的、高可用的并被广泛使用的。BI survey对Bi产品从以下几个方面的八个方面进行了调查：节省成本，改善用户满意度，较高的收益，更好的决策，改善的报表。对是否进行BI产品选择的调查发现,对多个产品进行评估的公司获得了较大的收益，而对单一产品进行评估的公司的收益较小，而那些不做产品选择的公司的收益是最小的。因此，一个正式的多产品的评估过程可以提高项目的成功度。如上图所示，在选择BI产品时，产品因素比商业因素更重要，特别是快速查询性能、易用性、是否可以处理大规模用户请求。评估需求在了解产品能做什么之前，不要和供应商会谈。l 尝试预测最终用户需要什么而不是听他们说他们要什么，也是说你需要理解他们的工作内容，工作能力，了解什么样的产品能帮助他们提高效率l 与最终用户一起工作，包括项目定义阶段、产品选择阶段和实施阶段l 不要期望最终用户能列出他们的具体需求，也不要强迫他们预测每一种可能性(你最后得到的是一个不可能的列表)l 在理解商务需求前不要致力于存储和体系结构l 不要使用过于雄心的BI交易中的闲置软件如果对公司来说，BI是新生事物，可能有些事情很难办，因此更好的做法可能是先上一个小规模的项目，使用一个简单的面向用户的工具来获得相关经验。这样他们就能更好的定义需求了。记住购买BI应该是商业驱动的：这就意味着对每一个项目，你都应该有一个清晰的相关联的目标，有具体的收益，至少有个大概的回报率。仅仅简单的说更好的信息和更多的报表对于一个项目来说是不够的。在项目前后，你应该确定可量化的收益(财政或人力)；如果这点做不到，那么就很难知道谁应该使用这个系统，如何确定需求，以及确定什么样的成本是合理的。总之，如果不能给用户切实可行的信息帮助他们更好更准确的完成工作，再华丽的报表也是没有用的。在建立一个大项目的正式的候选名单之前，你应该调查一下以下问题：l 输入数据的规模，包括现在的和将来的(需要花点时间来研究)l 数据的时变性，即数据随着时间变化的情况(一些产品不能处理高度变化的数据和元数据)。l 应用的类型：零售/市场分析， CRM， 预算/计划， 业绩管理，平衡计分卡，质量分析，财政，财务报告与整合l 关键属性：回写，分配计算，精确的货币转换，打印报表质量，电子表格接口，复杂的业务逻辑，维度灵活性，统计，计划和预测（包括如果。怎么样？）l 整合：其他相关的系统，如E-mail，ABM，数据仓库，数据挖掘和ERPl 用户的数量和位置：影响体系结构，安全性和成本。l 用户角色：高级管理人员，财务，市场，HR，销售，生产，工程师等。l 当前用户和开发者的技能：Excel, VB, JavaScript, Java, J2EE, SQL, ETL, EIS, Web,立方体设计等。l 谁来做实施和维护：外界顾问，内部IT员工还是最终用户。l 服务器平台：NT, Unix, AS/400, Linux但是不要坚持候选产品毕业运行在现在仍然使用的将被淘汰的平台上。l 客户端PC和浏览器标准： l 部署结构：可上网的独立运行的PC，告诉客户端/服务器，内部局域网，外部网以及互联网。国际化部署：多货币支持，多语言操作，数据共享，本地支持，许可证发放问题，跨时区更新Windows，网络带宽l 预算：软件，硬件，服务，通信不要沉迷：过度的强调需求和不重视需求一样不好。例如，许多简单的报表产品对于许多应用都是用，而不能仅仅因为一个不必要的高级功能需求而将他们排除在外。完成这些分析之后，就可以通过详细的产品评估和相关背景分析来确定满足商业需求的候选产品列表。要保证你列表中的各种产品彼此相近。如果列表中有一些很小的公司，也不要太不安。事实上，如果列表只包含最大的最好的公司，列表是不平衡的，因为这些公司统治着BI领域的某些领域，不出手那些可直接比较的产品。另外一个很重要的技巧是当你有了候选列表，你应该重点关注核心需求。邀请销售商最好的技术人员来进行深度的面条，直接挑战他们要求他们详细的描述如何解决某个具体的问题。显然，购买者应该有足够的知识知道应该关注哪一个主题，知道回答中哪些可能是在撒谎。利用这种方法你可以很快的剔除不合格的销售商。好的候选列表最重要的一点是所有的产品够能胜任，因此即使选择最好的销售人员，也不要紧了。然而，如果你的候选列表是半随机的(很多购买者都是这样的)，那么选择最好的销售员的产品可能就很危险了。然而，记住销售技巧会误导你。警惕带有倾向的建议：有很多的免费的BI产品的建议，但是很多是来自有偏向性的地方：l 媒体更喜欢写那些积极的公司，即可以提供案例研究和采访机会的公司。l 硬件厂商推荐那些在他们平台上运行的产品l 数据库厂商更推荐他们自己的BI产品l 咨询公司更喜欢推荐他们能提供服务的产品，或者有他们的合作者。BI调查发现由那些大的通用性的咨询公司实施的项目比那些小的但是专做BI咨询公司成功度更低。l 最终用户喜欢和以前用过的产品相关的产品，即使它们不是最适合当前项目的。l 工业界分析员受厂商影响，他们更关注生产商公司而不是产品。l ERP厂商希望推荐他们的BI插件和报表工具，一般来说成功率比独立的专门的BI厂商要低。对BI来说，单一公司标准是不是好主意？产品选择成本不低，因此一个倾向是选择一个较好的产品集，不仅仅在即将开展的项目中还包括未来几年所有的项目。这种做法是很危险的。尽管看起来相似(尤其是在Web上)，BI产品还是有着非常不同的架构和功能。没有产品在所有的方面都很擅长；大多数只能做一小部分事情。例如，一些可以处理非常大的数据卷，但是在较小的数据卷没有竞争力，因为它们比较慢，不灵活的，和专为小应用设计的轻量级产品比起来功能少一些。另外一些产品可以处理大量并发用户，但对小组织就不理想了。一些有很好的Web功能，但却不适合独立使用。还有的可以处理多用户更新数据，但对报表应用就不理想了。但是有一点所有的产品都有的，那就是他们都是业界领导者，产品都是具有伸缩性的。另外的因素是不是所有的用户都有同样的天分和需求。许多用户需要的一般比预定义的Web报表多一点，可能就是需要一些下钻功能和链接。其他一些需要从预定义的报表开始，进行一些有意义的和规则的修改(这意味着一个灵活的c/s架构更好些)。他们也会自己做一些探索工作，比如和同事分享新的分析。一些能力强的用户可能想建立自己的模型并使用一些高级的统计功能；一个浏览接口对他们来说是不够的。还有一大群的被动用户，他们只是在有相关或者有意思的值得看一看的事情时，想收到报表或者通知(通过邮件或其他方式)，而除此之外不会使用系统。用一个产品和接口是很难满足所有用户的要求的。如果你尝试选择一个单一的BI产品作为公司标准，许多用户会得不到满意的服务。甚至如果你被说服买了比项目所需更多的许可证，那将会阻止你尝试新的软件，不管它是不是管用。购买者通常会错误的假定同一个厂商的多个产品是很好集成的，其实不然。你仍然需要评估他。即使你有了一个公司标准，新的产品也会通过某种关系从后门中溜进来。设立一个长期的标准的坏处是你可能错过下一代的更快更多功能易容性更好或者更便宜的技术。不同于强迫使用一个单独的产品，对IT组而言，一个更好的办法是在一个小范围内选择适合较多应用的BI产品集。采用该方法，可以获得额外的支持，更简单的数据集成，更好的可用技巧，可能还有更低的软件价格。但是如果用户觉得没有一项产品可以满足一个新的商业应用，这样也不会被禁止选择另外一个产品；总耗资，IT部门的最终目的是帮组公司完成商业目标，而不是加强IT政策。招标需求怎样才不用做这些很多大公司有一套标准的官僚的缓慢的软件购买流程。但这些标准是为那些大的从开始就明确特点的系统，并不适用于BI系统。该过程的一个关键步骤是编写沉重的招标文档，有时也被称为需求方案说明书(RFI或RFP). 这些文档包含着数十个设置数百个问题，其中包含了在之前购买不同软件时重复利用的样板问题， 还有一些由方案选择委员会提出来的以证明他们是清醒的半新的问题，还有一些是受欢迎的提供商的销售团队”帮助委员会理解问题”提出来的。文档编写的很匆忙，问题往往互有交集或者彼此冲突。典型的招标文档包含着一个很长的功能需求列表，即使没有人实际确认过他们是否是最适合用来解决商业问题的。事实上，聪明的销售人员在这里就有大有用武之地，他们会巧妙的将他们产品能够提供而竞争对手不能提供的功能加进去。有一些性能要求是由老的产品产生的，试图克服一些在新产品中不会出现的缺点，换句话说，这些性能要求根本不需要。对一个现代产品而言，如果满足这些性能要求反而是一个可疑的地方。类似地，如果新的产品能以另外一种方式满足业务需求，那么过于关注产品的特性和体系结构就不明智了。与拥有一个小心选择的候选者列表不同，招标文件往往会被发给太多的提供商，他们中间很多人知道他们获胜的几率很小。一些勇敢的人可能会拒绝参加招标，一些会尝试干扰整个过程，增加新的问题，或者绕过招标选择项目组。招标选择项目组试图理性的完成选择过程，试图为每一个性能要求打分，决定哪些性能是必须要求的，而另外一些是希望有的。这些对生产厂商是不公开的，但那时有经验的销售商的投标专家知道怎么回答。比如，大多数提供商会说每一个性能要求都是可以满足的，而丝毫不提要实现它需要很大人力的低效的不可维护的编程才能做到。当然，购买者并不清楚这些，他只想知道这些功能能否有效方便的使用。然后所有的项目被打分，计算最终结果。然而有个时候一匹黑马可能闯了进来，这时候公司政治开始发生作用，一些希望有的功能被调整为必须的，或者相反，总之为了将不受欢迎的厂家踢出去。最后，开始试用一个或多个产品。不可避免的，受欢迎的公司在使用中会得到更多的宽容，并最终得到一些作弊的机会。最终，在耗费了购买者和厂商几个月的时间和代价之后，最开始喜欢的产品经常被选择了，然而，这其实在第一天就可以做到的。传统的招标文档并不适合BI，更加恰当的过程应该是：l 理解需求，如之前描述的那样。l 产生一个初始的最多四个候选者，并在沟通中了解他们是否明白业务需求，是否可靠(看一些详细的实例并访问一些之前的用户)l 在这阶段(不是在最后阶段)，提出的业务条款需要获得领先的一个或两个厂商的同意。l 在不多于两家厂商实施技术性验证测试，其目的不是为了开发原型，而是测试对提供商来说可能有问题的业务需求。l 最终选择的应该是具有最好的业务条款，并能证明他们可以满足需求的厂商。 不需要学术化的招标文档，相反地，预选择文档应该关注业务需求而不是产品的功能。 干扰因素Distractions在整个过程中会有很多事情把从真正要解决的问题吸引过去，所以要记住始终保持控制。销售人员很有技巧，经常会把你带到他们擅长但是却与你无关的领域。不管他们对你多有帮助和专业，记住他们的首要目标是达到销售目的而不是帮助你。并且一些最好的销售人员看起来跟不不虚伪、讨厌。BI Surveys调查显示在产品选择中销售技巧占有很重要的地位。降低干扰风险的方法是成立一个业务人员和技术人员共同组成的选择小组，因为他们很少会被同一件事情所深深打动。BI评估不应该交给专业的软件评论者，因为他们虽然毕生都在评价一个个不同应用的产品，但是他们很少理解BI应用的业务需求。厂商的规模很多购买者倾向于大的厂家，因为他们会觉得大厂商不会在将来几年消失。这可能是正确的，但是这并不意味着他们就是最好的BI工具提供商。 我们一直发现中小规模提供商的客户比那些巨型厂商的客户更加快乐。原因主要是与叫较小的但更专业的公司相比，BI业务对这些大公司来说不是那么重要，因此，当问题出现时，小的厂商经常能够更加辛苦的工作来解决问题。更糟糕的是，对大厂商而言，BI产品的长期健康实际上具有较少的确定性，而对专业公司来说，他们的将来完全取决于BI是否成功。大公司的执行官们可能与分析应用没有关系，他们的BI策略可能是非常不协调的，更多是执行官的临时起意。在像IBM，Microsoft， Oracle， SAS 和SAP这样的公司里，你很难找到高级执行官或者市场，支持，预售人员很了解BI。这些巨人们都范过一些专业BI公司不会犯的致命错误。一个问题是在大公司里，那些BI专家发现自己很难提升自己，要么离开公司要么转向一般的管理工作。所以，如果你买一个大公司的产品，你可能发现当初给你留下深刻印象的人已经走了。收购小的BI厂商的大公司们似乎在2到3年会丢失大多数重要人物（因此，你不应该更偏爱一个财大气粗的购买了小BI厂商的公司）。结果，从小厂商购买BI产品最大的风险是他们可能被大公司收购。大公司有时会声明他们花了巨额自己在研发上，但是我们没有发现巨大的投入就带来了产品的创新和可用性。事实上，一般是小的团队而不是大的开发组织作出革命性的创新，这是因为大公司往往忙于如何整合收购的产品，平台支持和官僚工作中。有一点是毫无疑问的，小的专业公司是对市场需求反映最快，产品进步最快的。他们的产品发布是在很好理解客户需求的基础上作出的。非常大的公司的研发周期很长，很多的新特性最后一般与他们自己的与BI不相关的产品有关，而这些特性BI用户可能根本不需要。当然不是每个小厂商都是成功的，所以你需要对他们的竞争力和管理方式做一番调研，有些小厂商可能关注的是如何把公司卖给大的投资者。和关键的执行官见面可能让你知道他们是长期在第一线工作，还是写写书，卖卖产品。一些厂商说他们有多年的实际经验，但可能他们的大多数有经验的员工已经离职了，或者在一些年轻的公司工作。更重要的是给你做支持的人可能用这个产品也没有几年，甚至就比你多会那么一点。支持人员可能需要应付很多不同类型的产品，设置比你还不了解你正在使用的产品。The BI Survey 8 向用户调查他们使用的产品情况,可以发现小公司的得分领先于大公司Before getting too impressed by the claims, ask to see the full customer list, and you choose whom you want to meet (and never in the vendors presence). 大厂商会在他们的网站上列出很多他们的用户，然而，其中许多并不是当前的用户。在收到他们宣传影响之前，向他们要用户的完整清单，然后你可以选择一个在厂商不在的情形下和他面谈。更好的方法是自己找到参考网站，确定最终用户是否满意他们的产品。本质上讲，选择最适合你的产品而不用关注厂商本身。技术问题技术上的问题很容让产品选择摇摆不定，IT人员可能不能理解业务需求，从而更强调熟悉的技术，而业务人员不了解技术框架可能被销售人员所左右，认为一些不需要的功能更加重要。平台选择是一个干扰因素。为了使用陈旧的平台而可能拒绝信的技术。事实上，目前很多厂家提出了基于64位机器的产品，因为那样更快，那么你就不应该坚持使用32位平台上的产品。虽然Windows平台没有想Unix/IBM平坦那么稳定，但是对BI产品而言，他更加适合。只有最大规模的销售分析系统或者大规模的互联网发布系统需要昂贵的高端Unix系统。软件市场非常繁荣，你可以找到很多的相关的低价产品，可以帮你来侃价。根据BI Suvey的调查，80%的BI项目使用的是Windows平台。许多方案有一个误区那就是他们实现假定了他们要的是一个关系型OLAP(ROLAP)，而不考虑专门的多维OLAP(MOLAP)或者混合模式(HOLAP)。这是不正确的，因为即使ROLAP存储在关系型数据库中，但是它们也是有复杂的模型，而且不能和其他产品的模型通用。OLAP的有用形式是提供一个良好支持的开放的API。而这就是ROLAP的弱点，没有开放的API。一般的说，可能只有1%的应用需要纯的ROLAP，5%左右的ROLAP可以工作的很好，剩下的部分则需要MOLAP或者HOLAP。性能是重要的因素，因为它决定了系统能多快的响应用户(这一点在用户满意度占有重要的地位)，而且决定了需要什么样能力的服务器。性能差的系统需要更好的硬件支持。但是判断产品的性能并不容易。所有的厂商都会说他们的产品是最快的，对此最好的办法是访问用户的网站，看看终端用户体会到的性能，当厂商辩解说今天有点忙平常不会有这么慢的，你千万不要吃惊。确定你自己看到终端用户获得的性能，确认输入数据的规模，和并发用户的负载。一般来说，最开始的设计数据规模都是夸大的，注意当确认数据规模时，记住数据爆炸的作用。不要被宣称的集成性和开放性所影响，几乎所有的BI工具都能很好的连接到关系数据库或者数据仓库，如果你有一个很好的ETL工具，那么你就可以访问到数据。BI工具也很容易整合的标准的Portal。不容易的事情是将多个BI工具整合在一起。例如，数据存在某个OLAP服务器上，其他厂商的BI工具访问起来就比较困难。不要受时髦的词语的影响。厂商在宣扬他们产品时往往使用很多时髦词，但这和他们的产品是不是真正好用没有关系。不要受将来版本的影响。厂商会宣传他们的下一个版本会更好更快。但你如果期望将来的版本，那么你应该考虑所有候选者的将来版本情况，同时你要做好厂商新产品的发布会被推迟几个月，或者某些功能不在下一个版本中实现。厂商往往会留下一个演示版本，但是这可能运行于一个小的演示数据集上，只有一个用户在使用，在本机上访问，没有网络延迟。因此，最好的办法是去一个已经在使用的、实际的生产环境中和最终用户了解真实的情况，他们碰到的情况将是你即将碰到的。Be sure to find out not only how well it works now, but how long it took to develop, how much consulting it took, and how satisfied the end-users are. If possible, find out if they purchased significantly more seats than they have managed to deploy.确认你不仅仅知道现有的项目运行的多么好，还要了解，项目用了多长时间开发，需要多少咨询帮助，终端用户有多满意。如果可能，看看他们是不是买了多余他们实际需要的用户数(seats).访问参考网站财力问题记住BI的软件许可证购买费只占项目总费用很少的一部分。实施和硬件费用比许可证费用要多，甚至长期支持、维护和管理费用更多。通过问下面的问题，确定你能理解一些复杂的报价模型：l 是否可以并发用户许可证，还是只能按每用户付费？l 是否需要付费购买运行版本？l Web用户的费用如何？l 当软件升级时是否要额外付费？l 许可证备份和开发服务器是否需要付费？l 是否为Unix，RISC，多核或者64位服务器版本支付额外的费用？l 链接某个特定的数据源或者数据库需不需要附加费？l 是不是需要买一个产品集，其中包含着并不需要的组件？如果你仅仅因为便宜就买了一个不适合的产品，你因为它更高的服务、管理、硬件成本最终可能付出较高的TCO TOC（整体拥有成本）是一种用来提供消费者或企业经理人在作采购时，评估某项IT产品的效益，以及直接、间接成本的算法。最后所呈现的数据可反应加入各种因素后的实际采购成本。,，并且获得低水平的收益。当你计算TCO时，记住问类似下面的