Skene Intelligence*

SAP BW provides pre-configured ‘out of the box’ functionality that enables the fast implementation of data models and reports on SAP source data. The set of objects and standard semantic definitions that SAP provide from source data to report, are collectively labelled ‘SAP BW business content’. Selected objects, data flows, process areas, etc. from business content can be installed and activated in your SAP BW system through an administrator’s workbench tool, or not!

So provactively, here’s the proportion of SAP BW business content objects that I use:

Not much right? This post describes how I arrived at this position. It firstly describes the benefits and challenges in using SAP BW business content and then lists various ways that it is employed in SAP BW implementations. Throw in a few critiques along the way for good measure and we arrive at my position. Let’s start off with the positives.

1. Benefits

a. SAP stack integration

It would come as no surprise that the SAP business content objects, functional area groupings, catalogues and meta data closely align with SAP source systems… well at least ‘core’ SAP systems such as ERP, CRM, etc. Business content provides standard extraction mechanisms to transfer data from SAP source systems into BW. SAP has significantly invested in the SAP business suite connectors over the years, and a particularly useful feature is the in-built handling of delta document/master data changes.

Although, I’d like to see more investment from SAP in the business suite extractors in the future. In particular extending process coverage, i.e. Purchase Requisitions, MRP, Transfer orders, etc. and extending delta capture across more extractors, i.e. HCM. That’s a topic for another day!

But business content is broader than just SAP related extractors and data marts – the InfoObjects are important too. For instance the master data InfoObject 0MATERIAL (Material) and its compounds (Material/Plant, /Sales Org, etc.), closely align with the data dictionary for Material in SAP ERP. Maybe you also want to create a new time dimension, say Shipping date. It’d be relatively straightforward to leverage the business content InfoObject for Date, 0DATE as a template and apply it’s format, rules and validity checks to your new Shipping date InfoObject.

Creating such a definition from scratch, including type of data, length, texts, attributes, hierarchies, etc. would consume quite some time. When you extend this out to more complex SAP ERP structures and relationships, such as pool and cluster tables, going custom would introduce more complexity and development time. There would need to be a compelling case to do this when standard content is all ready available to leverage.

b. Implementation Accelerator

The adoption of pre-configured objects is going to speed up the realisation phase of a BI project – you don’t need to develop every object from scratch. That for me is simply the main value for business content. However I believe the value of that exercise is dependent on the type of object and its position in data flow.

The logic being that the higher up the data flow you go (away from the source data) the less value you will receive from pre-configured objects. Objects towards the top up the data flow (such as reports, InfoCubes, etc.) are more closely related to solving a specific reporting requirement for your enterprise. These requirements tend to be unique to your enterprise and are less likely to be completely fulfilled through templated content. Hence such objects that try to meet these requirements are of lesser value.

I’d argue that the sweet spot for applying and re-using business content objects is in the upper left section of the above graph. Here the business content objects are closer to the source data and are able to be implemented as a baseline for further development. Towards the lower right, objects such as InfoCubes are highly related to answering specific requirements and questions, that may not have any meaning for your enterprise.

2. Challenges and Opportunities

Big deal I hear you say. Why would I want to implement any kind of data model that comes as standard with a vendor package? My enterprise data and reporting strategy doesn’t conform with some kind of pre-canned model and the reports are just garbage, why would I want to do this? All valid questions…

a. What about me?

I think we can all agree that for a Business Intelligence initiative to be successful, the design of a Data Warehouse needs to be driven by your enterprise’s requirements. Your Enterprise Data Warehouse is ultimately a reflection of your enterprise’s data and a vendor isn’t going to provide a template for that out of the box. It’s going to take time, effort and significant ownership.

Indeed some Data Warehousing luminaries, such as Kimball, indicate that Industry Standard templates should never be used and are ‘more trouble than they are worth’, see Kimball University: Industry Standard Data Models Fall Short for further details.

SAP’s business content, whilst developed in collaboration with customers across a range of industries, pays no particular regard to your enterprise’s requirements. How could it, unless you co-authored it with SAP?! Hence, there’s an inherent conflict between your enterprise’s requirements and the structures and reports that are contained in SAP’s pre-configured content. How are you going to drive out differentiation and competitive advantage using a templated solution that a competitor could also buy off the shelf? I don’t think the answer is because they’ve bought another product that you perceive is inferior to yours.

b. SAP Source system customisation

Some may argue that the further your enterprise embarks down the path of customising processes and transactions, the less useful business content becomes. In my view this is partially correct as logically, business content, representing a standard set of objects, is set in stone and built around pre-defined data flows. For instance, if your enterprise has decided to store specific transactional data in a new customised table, then there will not be a business content extractor or data model built around that.

However, don’t let this detract you from some of the advantages of business content. Unless you have adopted a completely customised ERP solution, then surely you will be able to leverage some business content and use that as a starting point. Even in the example above, you’d still probably be able to apply some standard objects, such as InfoObjects, to the customised table.

c. Non-SAP Source System integration into BW

OK so you’ve used some SAP business content in your data model and now wish to align and integrate non-SAP source data to it. Essentially this is a question of how well does SAP’s business content conform to the non-SAP vendor’s source data? Unfortunately there’s no easy answer for that, it depends on what source system and the breadth of data that you’re trying to conform in your data warehouse.

Given that the SAP BW business content objects are developed around SAP semantic definitions, it’s not likely that there is going to be a strong alignment of the non-SAP source definitions to it.

Unlike SAP Business Objects Rapid Marts, SAP doesn’t provide BW business content specific to non-SAP vendors. Happy to be corrected, but this is most likely due to the legacy of SAP BW’s evolution as an OLAP reporting tool on SAP ERP data and being provided as a packaged reporting solution on SAP ERP, etc. SAP does provide tools such as Master Data Management and ETL modelling, cleansing and quality within Data Services that can assist with non-SAP source data integration. Check the Integrating SAP MDM and Business Objects Data Services wiki for further details.

What’s clear is that the mapping of definition A to definition B will still need to be done somewhere, in one (or more) of the tools at your disposal. It won’t be coming from SAP BW business content for Oracle Financials for instance.

d. What happened to EDW modelling techniques, LSA anyone?

Unfortunately the the data model provided by Business Content does not always adhere to a structured, layered approach, such as that suggested in Enterprise Data Warehousing techniques, including SAP’s Layered, Scalable Architecture (LSA). As such, business content does not realise the inherit benefits and flexibility of these architectures, i.e. extract once, deploy many, flexibility to meet new requirements, cross-process integration, performance, etc. Hence, at best when deployed with an EDW approach, business content can only be employed as a development accelerator. Once implemented, additional work is required to conform the data model to an EDW based approach.

Wouldn’t it be good if SAP could deliver business content that complies with LSA requirements? I understand that the LSA is a generic EDW architecture which needs to be adjusted specific enterprise requirements, such as domains, collapsing layers, i.e. quality, harmonisation and corporate memory isn’t always required, etc. But if SAP could at least provide a starting point for process area data flows, based on LSA principles, then this will meet the objective of using business content as an implementation accelerator. It would remove the amount of work required to conform the business content to a LSA structure – for instance many business content data flows do not contain any DSO objects, hence they do not comply with LSA requirements.

SAP does provide LSA dataflow templates which enable a degree of modularity in applying LSA architecture, as described in Juergen Haupt’s blog. However there’s no relationship between the LSA data flow templates and business content data flows, i.e. there isn’t a LSA100 data flow template for Purchasing – just a LSA100 standard template. This can be done better. Pre-packaged solutions such as business content should conform to the standards that are being promoted.

Such a relationship between the LSA and data flows in business content would also assist developers in adopting an EDW based approach from the beginning – and may in fact introduce some to the concept. I’ve been at too many a client where I’ve been asked to extend a data mart to meet a new requirement (for both current and historical data) but all I have had to work with is a dataflow direct from datasource to InfoCube. Wouldn’t it be great to send this architectural message through the BW ecosystem through the system itself in business content?

e. Legacy 3.x data flows

With the arrival of SAP Note 1601140 – BI Content Migration of BW 3.x based data flows in March 2012, SAP is now supplying BI content data flows in 7.x technology for a wide range of ERP application areas, CRM, SRM, SCM, PPM and Industry solutions. Congrats SAP for taking this important, yet not very glamorous or high profile step. Not all content has been converted to 7.x, for instance hierarchy datasources are still delivered in 3.x, but it’s a great start.

A great degree of manual migration steps have been removed through 7.x business content delivery. This coupled with the release of a migration tool in BW 7.3 has made the task much simpler and streamlined – although a caveat is that the migration tool doesn’t always successfully migrate each flow. See my blog entry Why migrate SAP BW data flows from 3.x to 7.x? for more details.

So congrats again to SAP and ensure your BI_CONT package is up to date in SAP BW to reduce manual/automated migration of 3.x business content data flows!

3. So how do you use business content?

We’ve covered the pros/cons of business content – now let’s have a look at how it’s applied in implementations. I think this fits into three broad categories:

• a. Used as gospel
• b. Junked – and not used at all!
• c. Used as an implementation accelerator

a. Used as Gospel

By ‘used as gospel’ I’m referring to using business content for every data flow and never questioning it’s validity and accuracy. This is always dangerous and I think this is a flawed approach from the beginning. Let’s dig a bit deeper in what has previously been discussed above.

Firstly as mentioned, standard SAP business content is rarely going to meet 100% of your enterprise’s requirements, in fact it’s most likely it won’t even come close.

Secondly in terms of accuracy, whilst it is reasonable to assume that business content should basically be ‘correct’, testing is still required to verify this assumption and its appropriateness to your enterprise’s data. Testing can never be underestimated and is always vital to ensuring that any solution, including those that utilise business content, complies with business requirements.

Indeed if you’ve made significant changes to your source ERP system through custom code, configuration and exits, etc. this may lead to business content extractors producing erroneous results. In such a scenario the baseline and goal posts have moved upon which the business content extractors were designed on.

b. Junked

This is a big call when you have a SAP source system connected to SAP BW. You’d be choosing not to leverage any of the business suite extractors, objects and data flows from business content – instead opting to build it all from scratch. I haven’t seen this approach applied in an implementation, and I believe for good reason. There’s far too much complexity in the source SAP system in terms of extracting data not too leverage the business suite extractors. Imagine retrieving the delta material movements through a custom extractor? There’s also too much additional effort in creating InfoObjects, when these all ready exist in business content aligned with the SAP source data dictionary.

In terms of combining data from multiple source systems (both SAP and non-SAP) in BW, there are a variety of techniques to achieve this. But I believe it would be a mistake not to, at minimum, use business content extractor and InfoObjects, for SAP source systems at the first, most granular layer (LSA – data acquisition) of your data flow.

c. Used as an implementation accelerator

As mentioned, I think this is the most appropriate and balanced way to use business content. It’s a balance between starting your development from scratch and implementing everything out of the box, where some objects will be useful and others completely irrelevant for your enterprise.

If the main objective of business content is to reduce the delivery time of an implementation with a connected SAP source system, I’d suggest SAP have achieved this. When used at the ‘sweet spot’ of the value equation, where the data flow objects are close to the source SAP data, business content provides a great baseline and place to start to meet your BI requirements.

Let’s get started.