Skip to Content

原文链接: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更关注业务所有和职责,而非过去的信息传递应用程序。

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply