Skip to Content

Podcast: Making Sense of SAP BI Consulting

SAP BI topics are certainly front burner these days. As many of you know, I like to dig into the skills areas and the gap between the product roadmap hype and what projects need to make this stuff work. It’s good to have a collaborator like fellow SAP Mentor Vijay Vijayasankar of IBM.

Vijay has been known to get an issue in his craw from time to time and he and I share similiar interests in skills and examining the consulting market for a better understanding of what leads to success and what leads to failure. So when he pinged me by email on some burning SAP BI questions that he was chewing on, well, that’s how many community projects get started. In this case, it’s a sporadic podcast series on SAP BI skills and consulting, which I’ll issue as part of my in-depth ERP Lounge podcast series.

Here are some of the questions Vijay and I were kicking around:

What it the future of SAP BI consulting? Why is there still lingering confusion over the SAP BusinessObjects tools amongst SAP users? And why is BI strategy an afterthought when it should really be incorporated into the core ERP implementation? 

To get a fresh take on these questions, we pulled in another perspective: Kevin McManus of McManus Consulting. Kevin brings hands-on expertise in BusinessObjects tools into the conversation. Kevin is fresh on the heels of some excellent Inside Track presentations on the SAP Business Objects roadmap (see links at bottom of this post). Kevin’s blog Clear Cut Reports focuses on Crystal and Webi reporting. Also recommended: Vijay’s personal blog and of course his popular blog on SCN.

Since this is a 55 minute podcast, I’ve included some show notes you can skim through to hit the part you are most interested in or pick up on some of the high points.

A few previews: we take a close look at which SAP BI skills are in demand. what separates a mediocre SAP BI consultant from an outstanding one, whether there are functional BI roles emerging, and whether BI is becoming a skill that all SAP professionals need to reckon with. Is BI the “holy grail” of value realization for ERP projects? And is in-memory for real? Vijay and Kevin address all these questions.

At the bottom of this post is links to additional resources and slides referenced in the podcast.

(If for any reason the embedded player doesn’t work, you can download the podcast using the “download media” link on the right hand side).

(Trouble downloading? if for some reason it’s not playing in its entirety for you, check out the version on in the meantime, or on my JonERP iTunes feed).

Podcast Timestamps and Highlights:

0:00 Introductions

Vijay – I come from an ABAP background, but when SAP started doing BI, that was a natural extension for me. This is what inspired the podcast for me – there is an upswing in the economy, and many are keen on doing BI right, but many also jump in without having a good strategy in place.

3:10 Kevin: I’ve been doing BI for 17 years, really focused on BusinessObjects space. Pre-BO it was Crystal tools and then Crystal was acquired by BO, and was then bought by SAP, so I’ve gone up the food chain.

6:00 Vijay to Kevin: What is new in the market? Here’s a couple things I have run into: one is the concept of federated data warehousing. 

Kevin: When different companies and data sources merge, it creates a new set of challenges. This year, some companies can handle more complex situations now that basic data warehouses are in place.

9:20 Vijay: Putting some skills context in: a year a go, I was on a project where the company spun off a manufacturing division, and the BI system had to be split from its parent company. These kinds of issues are beyond your average data modeling and reporting. If you can handle that kind of complex BI spinoff, that kind of skill keeps you on the edge of the market at a premium if you’re an SAP BI consultant – and those skills needs aren’t going away, even in a difficult economy.

11:00 Jon to Vijay: It seems to me that the major ERP vendors are pushing BI to justify the holy grail of taking companies’ transactional systems and delivering a deeper value, with more visibility, better anticipation of inventory needs, etc. Is BI the holy grail of ERP value justification and will it live up to that?

Vijay: The next step that’s needed is contextual BI and predictive analytics. But ERP as it is today has serious limitations into decision making, and whether you move the data into a separate system is another question. But to get value out of ERP, you do need a comprehensive system that includes BI.

13:30 Kevin: On our projects, we do a lot of taking Business Objects and integrating it back into the application so people aren’t jumping back and forth between an ERP and BI system. From a technology stance it’s quite achievable, but from a data and process standpoint, it’s much more challenging.

Jon to Kevin: Why should be there be confusion on the SAP’s Business Objects roadmap now? Hasn’t there been enough time to sort this out:? What’s going on?

16:00 Kevin: SAP has stuck to their guns with the roadmap they presented years ago and they have kept to that roadmap, but confusion remains.

18:30 Jon to Vijay: How do you focus on strategy, when you have so much confusion on the tools side?

Vijay: It’s a problem. SAP has had trouble keeping the names consistent. Confusion is out there. BW went to BI and back to BW again. Pioneer went away (as a name). Xcelsius is done (as a name). For the market, the confusion is huge again. What is Crystal Dashboard Design? There is lots of confusion on the market – it needs more time. More education is needed – implementation partners need a better education on the tools.

21:44 Jon to Vijay: You had a series of points on strategy you wanted to ask – were there others you wanted to cover?

Vijay: I started this discussion because if you know the right strategy, then you can handle the tools. Having a strategy would tell you when you can migrate to Webi already and what you can wait for “Pioneer” to come up with.

23:45: Kevin: In terms of getting down to individual features, it gets very confusing. Every tool vendor will say that they can handle ranking, but how easy is it to setup and how well does that perform? That can very from tool to tool. 

25:46 Jon to Vijay and Kevin: More on BI skills: Business Intelligence seems to be becoming less and less a specialized area. There is still a need for specialists in BI, but it seems there is a need for all SAP pros to reckon with BI, either to help with executive decision making or provide userswith reports. What do you guys think?

Vijay: BI specialization is not going away – without a few people with deep expert knowledge you can’t implement a good solution. That’s the technology part. The other part is the process knowledge which may be even more important.

29:35 Kevin:  It’s interesting because once you start to integrate BI, the technology is moving in such a way that it’s going to force you to take those questions into account. Will there be people who are focused on operational effectiveness, and will there be a second group of people focused on BI, or will the expectation be that every person involved with the business will be able to handle all those types of questions?

32:18 Jon to Kevin: All consultants aren’t created equal – especially for a firm like yours that stakes its reputation on the caliber of your people. What separates a mediocre SAP BI consultants from an excellent one?

Kevin: A lot of it comes down to experience, in other words, what experience have you been involved in. If you spend 2-3 years working on a technology and you’re passionate about it, you’re going to need a desire to become an expert in that. 

Vijay: Nothing beats experience. Industry experience is a big differentiator. BI is very specific, there is no generic BI. What I need to run my business is different than what you need to run yours.

36:45 Jon: The tech roles are changing a bit due to newer set of tools, but on the functional side, will we see the emergence of functionally-focused BI roles?

Vijay: in my opinion, I totally hate the functional/technical divide, I think all BI people should have a good mix of functional and technical skills. If you don’t know what your product can deliver, there’s only so much can you do for the client. 

39:10 Kevin: There’s a value in having a person that sits in between the tech and the business users. I’ve seen people who are not writing reports, and developing reports, but they know the value of both sides, and they know how to move the report developer’s info and have a better grasp of the business than those individual report developers will ever get. 

42:14 Vijay: I agree. Having been a developer earlier in my career, I can say that often the developers were not brought into the loop, the seniors on the team didn’t have input and didn’t seek out the developers. All I can say is shame on them. 

Kevin: When you have someone who is connected with the business on the BI team, there can be a huge benefit in their being able to come up with suggestions and new ideas on how to improve the business.

44:34 Jon to the guys: before we wrap, we have to talk a bit about the future of BI. We have to address in-memory. A lot of BI systems aren’t real time yet, and Hasso Plattner’s vision is that the abstraction layer (ETL) is almost becoming evil thing, stopping us from getting exactly what we need in real time. Thoughts?

Vijay: In-memory is here to stay, we got a big speech on that at Sapphire and we’ve been hearing about that a lot. But in-memory doesn’t solve all – you may still need info from a legacy source, so hybrid architectures will continue to exist.

48:12 Kevin: We were doing in-memory OLAP around 10 years ago, and as a developer I was saying, “This is gold, everyone will be doing this.” But it’s really taken this long for BI to become mainstream and for this technology to be necessary. 

50:09 Jon to the guys: Give your closing thoughts, and tell us how you stay on top of your skills in this market.

Final podcast notes: Thanks to Vijay for taking the initiative with an email chock full of questions about BI strategy. The email exchange between Vijay and Kevin provided the basis for this podcast. This podcast makes reference to the presentation Kevin gave at SAP Inside Track St. Louis. Click on the event link to view the slides and session replay.  During the podcast, we also refer to products that are undergoing name changes. Don’t treat this podcast as the definitive record of the new names, rather, check out the SAP BusinessObjects Community for that info. 

You must be Logged on to comment or reply to a post.
  • First on audio quality : Excellent! I had no issues in hearing.

    I guess you three discussed only sub-set of “Making sense of BI consulting”. Having been a developer, DBA, non-SAP Data Warehouse Modeler etc, I continue to see a big gap between Technical and Functional. It also surprises me that we focus so much on BW tools and appear to ignore other critical components such as data modeling, HW, DB, Network, SAN, technical team with BW knowledge etc. Everyone appears to talk a lot about in-memory database which is not there yet. Even BWA is not widely used.
    Vijay mentioned he hated the functional/technical divide. I like that. I don’t like that divide as well.
    Kevin mentioned he was doing in-memory OLAP 10 years ago. Is “lack of in-memory” the real reason why BW is suffering? I guess Vitaliy’s blog “Is your BW the Data Warehouse,anyway” would be helpful to understand BW challenges.
    Vijay mentioned HW/Memory etc is getting cheaper so run an ABAP report to generate reports in real time. I guess I respectfully disagree in two levels: 
    1) HW/memory is getting cheaper: If you compare today’s cost with data processing requirements of y’day, yes definitly HW/Memory is cheaper today. However if you want to purchase HW/Memory today to meet data processing requirements of today, then as far as I know the cost is certainly very expensive.
    2) Writing ABAP reports to handle BW requirements is by itself tells me that BW system is not well designed. This is one reason why the business is not seeing the benefits of Data Warehouse. IMHO, ABAP report can’t handle (“not economically feasible” is probably a better term) true BW requirements with drilling/dicing/slicing capablities etc. 
    A few weeks ago, I was reading a blog on how to delete records from DSO in BW. First of all, Bill Inmon defines the Data Warehouse as:
    “A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process”.

    I would like to give the definition for just one term:
    Non-volatile: Mr Inmon’s definition:
    “Data is stable in a data warehouse. More data is added but data is never removed. This enables management to gain a consistent picture of the business”.
    Not sure why the records needed to be deleted from DSO and then from cube on a regular basis. Why is it not possible to just pull what is needed from the source system. This appears like a fundemental flaw in BW design. This requires additional time (real-time impossible)to delete/reload etc, processing power, memory etc. To top this off, data consistency/integrity between the source system and BW is compromised.
    In 1995, I used to hear this: Data Warehouses are “Read-Only” db meaning only data load is allowed;no modifications in DW. I’m not working on designing data warehouses for the last 10+ years so I don’t know if other vendors allow the modifications to their data warehouse solutions.

    The other components in “Making sense of BI consulting” involves:

       1) Data Model (you mentioned this but the focus of discussions was on tools)
       2) Basis layer
       3) DB
       4) O/S
       5) SAN —> SAN plays a very critical role in today’s BW/DW world.
       6) Network


    • Bala, thanks – glad u liked the podcast.
      Just to clarify on the ABAP report comment – my intention was not to replicate BW functionality in ABAP, but rather point out that all reporting does not have to happen in BW. Not all reporting requirements need OLAP functionality. As hardware and database theory evolves there shouldn’t be any need for a separate datawarehouse. Nor should it need data to be physically in one location to report. Products like HANA and Data Federator are all in that direction.
      • Vijay,

        Yes, all reporting doesn’t have to happen in BW.  Sometimes I create reports using sql-plus or other tools. I was a bit confused about a reference to ABAP while discussing BW. It seems there are customers who use BW to generate simple reports. Anyway, if this is not the case, then I misunderstood.
        New technologies are great. I love them. However don’t you think the vendors are doing a (very) poor job in transferring the knowledge to mass? Example: BWA. Note 917803 can be used to estimate BWA size. Recently someone(senior person) I know used it and calculated for each cube individually. As a result, this is what happened: large master data tables were included more than once. The note doesn’t explain really well. BWA was released more than 2 years ago; however people still don’t know how to do simple tasks.
        HANA is nothing but new BWA; Data Federator looks good in theory.
        Oracle released 11g and it contains a lot of great features. I used OLTP compression and it is really great. Oracle calls it OLTP Compression. The algorithm they used is really innovative and must’ve invested a lot of money/time in coming up with that algorithm. They developed this to save disk space. Don’t you think they see a real problem with disk space utilization? Had they thought in-memory db is the future or near future, do you think they would’ve wasted their time and money on developing a new technology that will become obsolete in near future?
        And SAP suggests two different oracle configurations: one for OLTP and another for OLAP (BW).
        And in BW, SAP creates bit-map indexes whereas in OLTP, SAP creates b-tree indexes. BW uses star join; OLTP/ABAP reports use nested loop/hash/sort-merge joins and definitely not star join.
        There are so many differences on how data is processed between OLTP and OLAP systems today. So question I would like to answer is what can we do differently-if any-to use today’s technologies more efficiently.
        May be bitmap/b-tree, star versus other joins a blog topic? I’ll try to blog.

        • Bala,

          Thanks for your comments- you added some real substance to this post.

          I think you and Vijay sorted out a fair amount of this, the rest would look good in your next blog. 🙂

          Meantime, a couple other comments. Your point: “Vijay mentioned he hated the functional/technical divide. I like that. I don’t like that divide as well. “

          That was definitely one of the things I took away from this podcast. As much as we like to think that BI is becoming a business priority with business users engaged in the process via collaborative requirements gathering and new visual tools, too often, that is not the case and we see so many SAP BW oriented positions that are deeply technical. Nothing wrong with hard core tech, but there’s a point where you want a more fluid movement between BI and business.

          Vijay and I will try to incorporate your comments when we do another taping of the sporadic SAP BI series. 🙂

          – Jon

  • Jon (and group),

    Agreed that there is much confusion among the products and will continue for some time. Unfortunately knowing the track record of SAP, as soon as everyone catches up they will change the directive once again. I disagree that “this will take time and education” and believe there should be more pressure from user groups (ASUG) to challenge SAP to stop the continuous marketing ambiguity around its BI products.  

    What are your thoughts on a consulting practice specializing specifically in BO/BW integration? More importantly how long do you think will there be a need for implementations to require a cross-expertise of the EDW (SAP BW) expertise with the front-end (BOE suite) expertise? For example our practice is focusing on just that (all ex-SAP/BO guys here who have been in the thick of the integration for the last several years) and we are having to dummy down everything to clients in a nature that is “you need a BO front-end person and a SAP BW back-end person..and both need to understand how each other work”. Furthermore, I don’t personally see any reason to depart from using the legacy nomenclature (BW, BIA, Xcelsius, Webi) any time soon as it will only confuse our customers more(at least the technical savvy ones).

    Michael Bestvina

    • Michael, it is interesting to observe how much people are still using “BI 7.0” and “BIA”, although it’s been almost 2 years since SAP changed these names back to “BW”. It will be even more difficult for people to accept changes in BO product line.
      In my TechEd presentation I wanted to use reference to old product names to get participants on the same page quickly, but SAP keeps removing any references to old legacy product names for it. They think this will make communication crisp, but I do not think so. Another annoying experience was on the conference 2 years ago, where I was not allowed to use any short abbreviations in my slides like BIA, but I had to spell “SAP NetWeaver BI Accelerator” every single time. I do not think it worked well neither for participants nor for me, but at least SAP Marketing could mark their “OneVoice” checkbox done…
    • Michael (and Vitaliy and Bala) – all very good points raised here. Michael for some reason I missed your comment but I tend to agree with a lot of it….on the good news front some SAP user group members were pulled into the loop with SAP on the latest round of product name changes which is a good start in the right direction. (check the most recent pre-teched BI podcast I did for more details on this).

      In one of our future tapings, I’ll try to go over these questions and comments in detail as they certainly warrant that.

      – Jon