迈向HANA：如何避免IT成功而业务失败

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

　　当讨论数据仓库迁移战略的时候，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更关注业务所有和职责，而非过去的信息传递应用程序。