BW项目经验分享——项目后评价的重要性 - Bill Yu的专栏 - CSDN博客

袁先生具有较强的数据库操作能力，丰富的BW模块和ABAP模块实施经验。其深刻理解SAP技术本质，以客户需求为核心高效制定解决方案，并全程参于实施数据仓库、数据模型的建立及增强、Query及WAD设计、程序性能调优、数据传输、周边系统集成接口、系统增强等专案。         在此项目后的评价系统中，为了保证将来系统的可扩展性，我们将在系统中将需要的所有数据都抽取到BW数据中心，以此作为项目后评价的中心数据源，当专家对一个项目或者项目包进行评价的时候，其评价的依据都从BW中产生，并展示到项目评分界面。这样设计的优点是，即使将来评价依据的数据来源发生变更，对项目后评价系统没有致命的影响，只需要对BW的数据源和抽取规则进行变更后即可，便于将来系统的扩展。       该项目评价体系数据库采用ORACLE进行设计，界面采用Web Dynpro进行开发，展示和评价指标由BW进行设计，评价指标大部分都来自PS或者ORCLE数据源。对于这种开发和BW并存的项目，和我们平常在纯BW项目中碰到问题有点区别，这些问题能更好地触动我们在面对项目时所采用的思维方式及问题解决的能力。 关于流程       对于已实施过BW的公司，在进行后期深化的时候，流程是非常重要的，每个过程都必须有严格的流程把关，不然很可能后续InfoObject的增强和相应的转换或者数据源的改动而影响到前期的模型和报表。       这一点对于养成从头开始惯性思维的BW顾问来说，一开始可能会有点不习惯，因为从头开始的BW系统像一张白纸一样，任由顾问挥洒，但对于其后续功能增强来说顾忌就较多。我们一开始从账号、权限、对象名、对象存放的位置、数据库的连接、权限改动、报表发布、报表挂接目录等等，几乎每一个过程都需要提交一个工作联系单，由上级部门和维护组同事审核过了之后才能开始工作。其实，一开始对于这一块我是很抵触的，而且这一点也影响到了我们的项目进度，后来维护组的同事对我说：流程化的东西确实很麻烦，但这对系统规范操作和后续维护来讲都是非常必要的过程。       的确，我们做项目不是以完成此项目就万事大吉；其次，要从项目整体来考虑，包括后续维护的简易性和方便性，所以这里还是希望我们的顾问在进行项目规划的时候可以从整体考虑，完善项目流程和文档。 关于项目       对于开发和BW并存的项目，有时候如果项目经理在某方面经验丰富，他可能会偏重于那方面。同样，此项目的项目经理偏重在后台数据库和开发，所以项目一开始项目经理会明显对开发的工作提更多的建议，但对BW来说，这就处于一个配合的角色，这点对于项目吻合性来说不是非常有利。自从BW组的工作由我负责后，我们BW组的讨论结果都会以邮件或者共同交流的方式提交给项目经理，然后一起头脑风暴，确定项目的方向。这样做的目的是，为了防止项目出现数据库这样设计，模型按照另外一套思路走的危险；或者数据的勾稽关系无法进行沟通，数据库视图错误的等问题。为了保证模型和ORACLE数据库逻辑的吻合性，最后数据库视图由我这边根据ORACLE表的逻辑进行开发，然后提交开发组同事确认逻辑，这样就保证了BW抽取的外围数据库字段的准确性。 关于与客户沟通       从以往的一些项目经验来看，做技术出生的顾问很多时候都是用技术上可是实现就是“是”，反之就是“否”的思维方式，因为计算机语言本身就是“1”和“0”的组合。这样就会导致客户在提出一个需求的时候，我们有些顾问一看技术上不可行，直接就说“这个是无法实现的”。而站在客户的角度来说，若得不到详细的解释，还是不知道为什么不行。他们可能会产生以下的想法，是不是顾问偷懒，不愿意给他们实现某个功能；或者顾问能力不行，推搪系统无法解决。久而久之，当客户有需求的时候，就不再会向我们的顾问咨询了，二是直接报告他们的领导，然后领导找PMO，这样对项目的进度和我们项目组的形象都会产生负面的影响。这时候就要求我们所有的顾问，在面对客户某个需求的时候，即使技术上实现不了，也要耐心地给客户解释不能实现的原因，对此我们有哪些可替代的方法。虽然，这样可能会在前期解释中较烦琐，但当你为客户详细讲解很几次后，客户就会对你产生信任感，这会为你以后的工作打开方便之门。 关于问题的解决        我们就评价依据是否由BW提供来进行头脑风暴时，BW报表能否可带URL进行灵活的传值就关系到此项目的大体方向。由于项目的构架方向要在一周之后提交客户方进行审核，留给我们BW组去解决URL带参数传值的时间只有两三天，当时我接到此任务的时候在网上苦寻无果，最后通过查看英文的Library进行相关尝试，最终在晚上9点左右拿下了这个问题。由于太累，当时反而没有什么特别兴奋感，只是觉得如释重负，因为项目组明天可以确定放下，并以此方向继续做下去了。       后来，我们BW组在共同的努力下，解决了很多技术问题，包括如何通过ORACLE数据库自动生成BW Hierarchy、如何完成自动算分、ICP等等。 关于跳出思维怪圈        在ORACLE自动生成Hierarchy的技术方案中，需要使用到“Open Hub Destination”，在处理链中用信息轮辐（InfoSpoken）将ORACLE的数据源开放到BW服务器上的某个目录中，然后通过平面文件生成Hierarchy，实现Hierarchy的自动更新。然而，该方案在进行对象传输的时候会记录BW服务器的系统标示，对于开发机、测试机、生产机来说，三者的系统标示都是不一样的，但是手工改动处理链中的系统标示从权限上来讲是不允许的。当时，我们在解决如何自动改变服务器系统标示上花了很多时间，同时也咨询了SAP的一些专家，几乎都于事无补，最后灵光一现，问题迎刃而解，我们为何不通过ABAP程序直接将数据写到服务器中的某个地方呢？这样便于理解，也便于维护。关于加班        这也许是作为SAP从业者最基本的职业道德，也是这一行永远都无法逃避的话题。作为SAP顾问，很多似乎已经把加班当成了一种习惯。这次项目要在6月中旬上线，可由于客户方流程方面的问题，系统账号在4月底才申请下来，所以留给我们的工作时间短，任务大。幸好前期模型和蓝图已经设计完成，但是这也无法挽救我们的五一假期。当时我的身体也不争气，五一假期后就开始感冒发烧，而恰巧赶上“猪流”大流行，于是我不得不去医院做详细检查。还好最后安然归队，有惊无险，而我们项目组成员“期盼”因我而全体隔离，好好休息休息的梦想也随之破灭。当然，在8小时工作时间内完成当天工作，保证项目进度。是我们所有顾问的梦想。 关于BO        最后要提一点的是通过BO进行界面展示的一些体会，Business Objects将其三大主流产品（Web Intelligence、Crystal Report、Xcelsius）在多维分析报表、格式化报表、绩效图表方面做了明确的定位和区分。我们很多习惯使用BW Business Explorer套件的顾问会觉得WAD用起来更方便，而BO的报表发布必须采用BOE的平台可能较前者麻烦。其实在界面展示方面，BO有其特有的优点和价值，很多时候对于工具的使用都有个习惯的过程，但我们清楚的知道，BO和BW的整合方向肯定不可能被WAD去取代Crystal Report，所以对新的工具，我们更多的的时候应该怀着接受的态度去促使其人性化地运用。 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/bxy5511/archive/2010/08/23/5832991.aspx