Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
robert_shi
Explorer
0 Kudos
822

原文链接:http://www.saphana.com/community/blogs/blog/2012/02/23/making-the-move-to-hana

“能够在现场与信息使用客户直接交流,对我来说是一件动力十足的事情,能够设身处地从他们的角度了解问题。这种感觉非常棒,虽然有的时候会令人非常尴尬,但是你可以回来并解决这些问题。无论系统是多么的优秀,我们总能克服困难找到新的方法去强化这些流程。这令人兴奋,因为我们的目标不应该只是跟上技术革新的步伐,而应该引领技术的发展。技术本身不是导致差异的原因。任何企业想要做到最好,就要把注意力集中在他们的客户身上——他们的信息消费者,通过执行并交付给客户他们所期望的结果,并且做得比其他公司更好。”

当讨论数据仓库迁移战略的时候,CFO们总会有这样的问题:“好的,我明白了HANA的好处。但是请告诉我,HANA项目究竟要多久?什么是“0风险”、最安全的实施方法?有那些风险?需要淘汰哪些内容?我已经有了BW Accelerator,我还能从这次投资中获得什么好处?值得吗?”

我们会发现在同一时刻,商业决策者们会提出各种各样的问题。这与我们BW和BWA的实施有什么不同?你如何保证这会满足我们的期望?这与我们最近两次BI实施有什么不一样,因为我们没有由此获得有价值的结果?你推荐最好的实施方法是什么?这次我们能够获得什么呢?我们要怎么做才能帮助实施并得到更好的实施结果?

这里涵盖了超过50%BI实施项目所关心的问题。现在的BI项目无法达到用户的期望,这与平台无关。为了达到预期,IT一直引入各种新的技术。结果却是商业用户与IT都对各种BI的BVA(商业获得值)表示怀疑。这是很多企业所面临的问题。当旧的数据仓库开始溢出,或者严重阻碍了企业成长的时候,新的或BI迁移项目的优先级就会很高。旧的BI系统总会突然奔溃。我们已经遇到很多类似的情况,当负载达到80%至90%,查询时间会从几秒钟变成几分钟,有时是几小时。

出色、关键、简洁的BI实施项目绝不简单,除非能够在做实施计划的时候将业务逻辑牢记于心,将新的技术进行优化,并将其作为迁移的重要部分。许多公司成功地将Oracle迁移至BW,BW至Teradata,等等,但是很多迁移都没有达到商业上的预期——他们无法达到实施之前所期望的结果。有人称之为“IT上的成功,业务上的失败”。我们必须扣心自问,究竟是平台的原因还是流程的问题。为了找出真正的原因,我们必须把注意力集中在失败之上,这是我们需要避免的。每个人都和我们谈论成功,在实施BI项目的过程,我们只知道那些成功因素,同时重复地犯着失败项目的错误。最终结果 = 又一个BI项目失败的开始。

为什么有的BI项目失败了,有的却成功了?


主要原因常常可以归结为——过分侧重于CFO的衡量标准,如成本、时间和任务——98%的BI项目达到这些标准,但忽视了BI的项目管理。同时,很少,甚至没有关注业务期望——只有在上线之后我们才会发现这个问题。随便看一下BI项目的阶段报告,我们总能看到成本、时间和任务的图表。找一下BVA图表,你无需惊讶地发现根本没有纳入到现有的项目管理体系内。在HANA中,这是不可缺的元素。业务的参与对整个项目的商业成功至关重要。但是,如果只是为了实施一个技术解决方案,忽略业务预期,这个项目可能不是必须的。

看得见的成本降低与看不见的稳定性


降低成本是所有BI项目的根本需求。要想一直达到这个目标就需要应用科学的BI原则,并引入两个新的元素来加强现有的项目管理方法论。用外行人的说法就是“一次性做对”。首先,要重新定义BI项目的成功元素。第二,要引入内部“业务价值负责人”的角色,如安排专人每周跟踪“是否达到商业预期”并出报表,就和成本、任务和时间报表一样。第三,为你的“BI商业价值架构”引荐一名白金咨询师,他能够了解业务,并将技术作为实现业务期望的工具。任何BI项目,包括BI迁移项目,应该能够明显降低商务成本,同时具有稳定的性能,能够适应灵活的业务改变和技术需要。必须将所有的战术开发与商业战略目标一致,而不是假设目标,或为业务目标做技术假设,需要业务干系人的直接参与。


随着越来越多的BVA驱动的资源投入到数据仓库,它的能力就会变得越强,直到最终达到转折点。现代BI技术大大提高了信息传递能力,提供了不同成本的选择趋势。HANA也不例外。但是,在使用HANA替代产品的时候,我们不能忘记Gartner的一句话“超过50%的BI项目在起步的时候就失败了”——失败的项目是由于使用旧的、技术上的BI实施原则,成功的项目是获得了科学的BVA方法论带来的杠杆效应。迁移至HANA能够获得战略上的成本降低,前提是按照专业的、计划好的实施方法。

既得效益与持续改进


HANA与大多数BI项目相比,在于“快速、技术层面和草率”与“缓慢,BVA驱动并满足业务需求”的区别。HANA的BI项目能够为商业用户提供即得效益,同时符合公司的长期战略。可以同时追求两者。一些短期的效益,如在部署HANA的同时部署基于HANA的“业务功能”。第一步可以是财务的“COPA”分析功能,物业的智能电表分析功能“SMA”,人事管理上的战略人力资源计划“SWP”,等等。第二步,当实现这些功能之后,可以对其进行提升。第三步,可以用HANA替换掉现有的BW Accelerator系统。SAP称之为“三轮摩托车挎斗”方法,我们称之为“安全HANA过度实施方法”——目的在于“0风险”。第四步,在未来完全丢弃BW数据库,让ECC和BW共同运行在一个数据库上——最融洽的HANA方法。每个实施HANA的用户需要牢记这个战略目标,那么当前进行的开发都能符合这个统一的标准,实现预期的未来。

业务改进 & 基础成熟度


业务是客户购买BI的最终目的。业务并不只是客户,它们同样也是判断BI是否达到目标的依据。尽早让业务负责人加入并持续参加BI项目是十分重要的,例如,每周一次,以可控的方式进行。在最近的一次BI项目中,按照BVA方针进行评分,我们达到了罕见的102%高分。大多数业务干系人想要看到数据仓库能够有明显的提升,但大多数期望都已经过时了。现在的执行官们总是想要么“实现这些报表”,要么“如果没有坏,就不要试着去修”。但是,类似于HANA和Accelerated Explorer所带来的技术革新需要执行官们抛弃旧观念。通过参加BVA培训,可以使他们成为现代BI执行官,理解新技术所带来的前所未有的能力与局限。从BW ETL转变到数据库转型是重要的一步,为了充分高效地使用新技术,执行官们必须了解这些简单的技术变化。

全局集成 —— SPOT分析


SPOT是指“真理的单点性”。通过全局分析,它能够建立或毁灭一个企业。我们最近为一家全球性的制造业巨头做了一次4个BW、16个Business Object、4个Oracle数据仓库的全局集成审计,并将其视为一个全局信息传递的远景。这与他们传统的、习惯了的、以数据仓库为中心的方式完全不同。数据仓库方式中,每个数据仓库都是独立的。在FEDW(联合数据仓库)中,所有的数据仓库都被全局信息用户消费——如业务集中。每个数据仓库成为了复杂的BI机器中的一个齿轮。在上面的例子中,我们能够将4个BW集成到一个FEDW实例中去,16个Busines Objects集成到两个实例中,一个用于高度机密的研发和配方,另一个用于其他商务处理,Business Object作为全公司的业务分析的简单语义层。在第一步中,公司实现了他们的口号“一个企业,一个真理”,现在他们想要加快查询速度,来维护在全球的竞争力。这家公司最近启动了HANA实施,首先集中于财务,第一步是COPA。

可行的HANA实施路线图


HANA如同其他的BI项目,需要业务与IT的共同确定目标,而业务将起主要作用。我们经常在第一次与客户见面的时候,他们已经有了预先的需求,经过几天的讨论,我们可以将实施HANA的真正商业价值划分出来。预先的需求一般都是:客户想要把ECC已有报表都实现一遍——我们马上意识到这是一种浪费。R/3的用户希望将他们的ABAP报表在BW环境下在复制一遍,这已是一个错误。在HANA中我们建议客户不要再犯这样的错误。原因在于这些关键干系人没有将他们的意识从报表转移到分析,没有转移到信息学,他们没有理解新的BI技术,他们的能力有限。关键不是在于出报表,而是在于在正确的时间,使用正确的速度,基于正确的信息提升决策能力。这是HANA的目标——只有这次速度飞快。

HANA使我们进入了信息消费管理的领域,而不是创建了一个数据仓库。业务介入是成功的关键。这里引用一下Gartner在2010年所说的“没有业务的商务智能,BI是死的”。HANA更关注业务所有和职责,而非过去的信息传递应用程序。