My customer is currently implementing SAP ECC6 and we are helping him with his legacy/new data warehouse transition plan, and options.
For multiple reasons, this customer expects to rule out BW as an option for him to host his data warehouse.
We are therefore assessing different options:
Custom-built DW, using BODS and its SAP connectors to extract directly from ECC6
Custom-built DW, but using BW DSOs to extract data more easily from a relational database (so BW is just being used as a “hub”)
Rapid Marts for SAP
For the latter option, I am trying to assess the relevancy given the customer’s context (which I still largely need to determine).
Is there a general formula / threshold that helps to assess the opportunity of using Rapid Marts?
Something that would say “definitely yes”, “possibly” or “definitely no” if my customers situation is:
Difficult to put numbers on it as you have below, but some general advice.
Ignore the reporting content from a coverage perspective, the reports delivered are samples and as such you are always going to want to build more reports / dashboards. Focus on the ETL, data model and semantic layer (universe) for their fit to the customer requirements rather than the reports as these are the layer where the most work will be spent customising / adding to the solution coverage.
The Rapid Marts are very useful as a starting point and also as a methodology and approach to using Data Services in a business analytic scenario, and provide a lot of guidance as to how to approach the subject and us of DS, which if you are new to the product is invaluable.
For me one of the key things I look for is the amount of customization going on, on the source SAP sysem. If they have a lot of Z tables and Z fields then clearly these will need to be pulled through to the DW solution and as such this will determine a lot of the customization required in the ETL and semantic layers.
Chosing SAP as their ERP and being still at the early stages of its implementation, my customer is obviously convinced that the implementation will have very little customization. Also starting with a FI-CO scope reinforces this intent.
Now, where will this customer be in 5 years from now, after implementing more modules and living with their ERP is another question…
And, while BW “as a whole” is excluded by my customer themselves, I am compiling the various scenarios, pros, cons, risks, costs, etc. including:
BODS connecting to SAP ECC6
BODS connecting to SAP BW (to ECC6)
RapidMarts
The “jump start” approach of RapidMarts, helping to get contents quickly and to adapt to compressed timelines is very tempting. Now, I am trying to weigh that against longer terms considerations such as TCO, flexibility, etc.
I have found several customers in the same predicament in terms of defining a reporting landscape as they implement SAP ECC in tandem.
Below are a few items that I would consider when trying to decide on the best options
It sounds like it may be a bit late in the game but has your client considered using the Data Services Data Migration templates for the data conversion/migration effort. Currently these templates are free and if we talk ROI this is a great place to start building a case for SAP BO DS.
Its great that you are involved this early in the game, in terms of planning for a DW. I suggest you go to as many conversion/data migration meetings you can this provides a perfect avenue to do a large part of the same analysis you would have done as part of obtaining the functional requirements in building out a DW.
When ECC is fully implemented, how much of your clients transactional data will be SAP? Generally clients that have a small amount of their transactional data in SAP (as compared to other transactional systems company wide) shy away from BW because it is not as open in terms of getting data in/out than a typical DW environment.
Generally the TCO of a BW system are much higher than that of RM development, not sure of the RMs price point, but I think they will be about 50k or less per subject area (dont quote me on this as the sales game is dynamic)
For the investment, RMs provide a great advantage over any other solution. As Jon alluded you get useful documentation (business and technical), Source and Target schemas (including target data models), etc which provide you a wealth of information and a huge head start for each subject area.
In terms of cost savings on average we have saved clients 250k-300K and 3-6 months of development time and test cycles PER EACH SUBJECT AREA over custom development. For custom development you would at least employ at a minimum an ETL Developer, Report Developer, Data Modeler and Functional Analyst. At a minimum, you would also have 2-3 test cycles - RapidMarts have been around for 10+ years and have the benefit of multiple test cycles per release - plus the standard content is supported by SAP.
The use ECC extractors does not necessitate you have a BW license I believe they are part and parcel of ECC. As a matter of fact, the new Fixed Asset RapidMart employs the use of ECC Extractors and I assume they will be used in the future for
Also, is there a need to combine legacy data with post go-live ECC data if so, the RapidMarts do not do this per se, but the architecture is certainly conducive to so by way of adding additional dimensions. By the same token, you can easily modify the RapidMarts to fit any particular grain you choose.
I agree with the previous post from Jon Focus on the data points delivered by the RapidMart ETL. Every client wants to slice and dice the data slightly different, from my experience I would say the RapidMart ETL provides a 70-80% solution and the delivered reports provides a 50-60% solution most reports have to be touched but they certainly provide a good head start on how to generate the SQL necessary to view the RapidMart data which is value in itself. Just keep in mind the RapidMarts WILL NEED to be customized - I have yet to be at a client site where they ran straight OOB (Out Of the Box) content.
Across many verticals, I have yet to be at a client site that heavily customized SAP, sure we get the occasional Z columns that store foreign keys or Z tables that store transactional data, but none have been impediments to a reporting scenario.
You cant beat the interoperability of the SAP stack specifically when going against an SAP source meaning the from soup to nuts, you are supported by 1 vendor and the tools are designed to play nice (and 99.9% of the time they do) with one another this has a huge intangible and tangible benefit. Since the acquisition of BOBJ, SAP has certainly held true to the commitment of making this happen.
Last but certainly not least, You also cant beat the rich meta-data that comes inherent with the SAP stack. Using the Rapid Marts you not only get to view the full SAP table dictionary when you use the SAP connector, you get full Lineage and Impact Analysis capabilities meaning from a report you can see the lineage all the way back to an ECC table or vice-versa, from an ECC data element you can see what the report impact would be if changed.
Questions for you?
Which SAP modules is your client implementing will it be a phased approach?
Why is your client ruling out BW?
When you say BODS connecting to SAP ECC6 I assume you mean connection via the SAP connectors and not directly to the DB?
In which scenario would BODS connecting to SAP BW be appropriate if your client is not currently using BW?
What would be your case for custom development over the RapidMarts?
Make sure you include a Performance criteria in pros/cons as well as a Data Refresh Frequency to clarify whether intra-day data refresh is required.
With regards to the RapidMart for SAP, you will find that the jobs (out ofthe box) will do a Truncate of the rapidmart dimension tables (it does that in both FULL and DELTA load mode!). If you ran the RM during the day, this would mean an outage on the reporting front…
On another note, due to this same Truncate approach, you will be constrained to run multiple rapidmarts sequentilally (AR, AP GL) as they use a common set of dimension tables (e.g. chart of accounts, cost centre, etc…)…
The above was in the rapidmart version 12.0. Not sure what is coming up in the latest version … when it’s too good to be true it usually is
Thanks a lot for the detailed answers and useful guidelines.
Let me answer in the order of your feedback:
and 2) Data Services Data Migration templates have not been considered but, as you guessed, this option comes indeed too late (as far as I am personally concerned, I am only dealing with the BI side of things, not the ERP one)
While many SAP modules will be implemented (details below), it is expected that 50% of the meaningful data will stay outside of SAP
BW is obviously attractive because of the absence of licence costs. So, indeed, any cost figure (cost of implementation, TCO) you can share (from you or else), even to be considered carefully would be much useful in helping quantify the pros and cons of each option
Indeed, I have looked thru this documentation and it is very useful. It ends up even being very useful to frame scope and requirements: as I am starting working with this customer, I discover there are no clear requirements nor requirements gathering process underway. RapidMarts will help frame this requirements gathering process, in a fit/gap analysis approach instead of a white page approach, which is obviously helpful when the timeframe is quite compressed
These numbers are quite compelling indeed. Thanks for sharing!
Do I understand correctly that new RMs from version 4.0 onwards will use BW extractors while existing RMs will keep their current ABAP sources? Or is it to be expected that some extracts will be revisited (for instance for GL data where incremental loads seem to be far from obvious)?
Now, on your specific questions:
Customer will go with a phased approach (by geo and by module). First modules will be FI & CO. Then other ones will follow but not sure in which order: APO, PP, MM, SD, LE, PM, QM and EHS
BW is ruled out both a religious choice (based on what the customers BI team is used to and comfortable with) and as a productivity constraint: the constraint of staying with a very small team compels them to stay in this familiar technical environment. Plus, as mentioned above, the importance of non-SAP data in their environment and its greater use to integrate in a relational DW rather than into BW.
You are right: I mean connecting to SAP ECC6 via SAP connectors (RFC, BAPI or as I understand to be preferable ABAP or BW connectors) and not to the DB
I do not expect BW as an interim hub would provide any value, but this is part of the identified options I need to compare. This is something I have seen used but in different contexts, typically where regional or shadow ITs had no control on the central BW and therefore extracted its data into their own DW
Case for custom development over the RapidMart: mostly licence cos. But also: 1. Not implement items (fields, reports, etc.) which are not used today (because not core elements) but then eventually get used without notice and without having been tested; 2. Defining ones standards vs. inheriting those from RMs. For instance, I would personally always store source files into an ODS, untouched, before importing them into the DW/Data Marts apparently not the architecture followed by RMs.
I expect I will have further questions in the next few days, which I will post in different threads. So, feel free to chip in!
Make sure you include a Performance criteria in pros/cons as well as a Data Refresh Frequency to clarify whether intra-day data refresh is required.
With regards to the RapidMart for SAP, you will find that the jobs (out ofthe box) will do a Truncate of the rapidmart dimension tables (it does that in both FULL and DELTA load mode!). :
[/quote]
Thanks Nicolas. I struggle to understand how dimensions can be truncated when facts are incrementally loaded, but a deeper look at the RM design should help understand this.
On Performance Criteria, do you happen to know any benchmarks? I have read a few testimonies on this forum but with no clear indication of volume of data or of comparison with a BW approach.
I agree. I was confused by this when I first encountered it. However, it was explained to me by an expert. The relationships between facts and dimensions use natural keys rather than surrogate keys. So it’s possible to rebuild the dimension tables whenever you want.
This is where the 20%-30% customization comes into play, the data model and etl are highly extensible, so it is easy to add surrogate keys to both dimensions and facts.
Also, in cases where the dimension availability requirement is high, we have removed truncates and added a table compare, to ensure dimension data is always available.
(BOB member since 2012-03-08)
(BOB member since 2010-11-09)
(BOB member since 2005-03-10)
(BOB member since 2012-03-08)
(BOB member since 2004-06-09)