Skip to Content
Author's profile photo Jon Reed

Will BI (and BO) Be Relevant to all SAP Functional Consultants? (and post TechEd updates)

Hey folks…I’m starting to come out of my post TechEd “content laboratory” and am now posting a range of content that may be of interest, most of which focuses on SAP skills trends. I have a fresh exchange to share with you below – a back and forth I had with Nathan Genez on the relevance of BI/BO to functional SAP consultants.

Before I get into this exchange with Nathan, I want to briefly share the latest content links I have on TechEd and SAP skills themes. My first piece on Tech Ed, “Inside the Hype of TechEd 2008,” was recently published in PAC’s online blog, “Feeding the SAP Ecosystem.” I will be writing for the PAC blog a couple of times a month. I also want to mention that on Tuesday, October 30, I will be doing a webcast on Becoming an SAP Business Process Expert as part of ASUG’s webcast series on this topic. There is still an opportunity to register, and I’m hoping to be able to include a link to the webcast after the event as well, we’ll see. This is really the first chance I’ve had to share my own views on this topic in detail in webcast form so I’m looking forward to it. I will also tie in SAP BPX certification, the new “Process First” book by Marco ten Vaanholt, and we’ll have some time for Q & A at the end as well.

Other new posts: my first “TechEd in Review” podcast, with guest Samantha Gammill of Osiris ERP Consulting, focuses on her trip to BPX Community Day as a functional consultant looking to transition into an “SAP Business Process Expert.” I called the podcast “Becoming an SAP Business Process Expert – One Consultant’s Journey” because it was interesting to hear what Samantha learned as someone who financed her own trip to TechEd in pursuit of these new skills. Hearing about how her team and her client reacted to her BPX lessons learned was also very interesting. I hope to upload this podcast to the BPX site next week.

A couple more new items: I have also posted an SAP hot skills podcast I did with Demir Barlas of SearchSAP.com that features David Foote of Foote Partners and his latest findings on which SAP skills are the hottest.

One of the major themes of TechEd 2008 was the flurry of Business Objects-related announcements. With CEO John Schwartz giving the TechEd keynote, we know that SAP continues to place a high degree of importance on the BI/BO product line, and its customers do as well.

In my first TechEd in Review piece, the aforementioned “Inside the Hype of TechEd 2008,” I didn’t spend a lot of time on Business Objects. That’s partially because I had published a pretty detailed piece on BO skills and trends just recently, after having attended the BO Influencers Summit in August of 2008.
 
One thing I can say about Business Objects – the two marketing executives I keep running into, Jonathan Becher and Franz Aman – are both real gentlemen. They are both articulate, competent, and patient in their explanations. If these two guys are representative of the caliber of people SAP acquired through the BO merger, then the human capital side of that merger is looking good. Becher didn’t even get mad at me when I almost walked out of a bowling alley (and Boston itself) accidentally wearing his dress shoes.

I do have some more Business Objects features planned. There will be a slight delay, because I am in the process of prepping for a webcast and several “TechEd in Review” podcasts. I also intend to write more on NetWeaver BPM – a topic I have finally researched enough to perhaps write a couple of halfway coherent things about.

But since BO was such an important theme of the conference, and since I do like to focus on SAP skills trends, I wanted to share an email interaction I had with Nathan Genez, an experienced SAP functional consultant who is an active player in SAP’s online communities. He is also the Managing Partner of Serio Consulting.

I count on Nathan to provide straight-shooting perspectives on what he is actually hearing from SAP customers about skills needs, because after all, that’s the bottom line. Whenever you focus on how SAP skills needs are evolving, you can lose track of the challenges of incorporating these skills on project sites now. Consultants like Nathan keep me focused on the realities of the present as well, and that serves all of our best interests.

In my original BO skills piece (notice I have managed not to refer to BO as “BobJ” once in this blog entry so far), several things caught Nathan’s eye – specifically the notion that SAP functional consultants would all need to know BI because it would enhance their skill set going forward. Nathan is a functional consultant with deep BW experience, and he reports that his BW skills have not given him a significant edge to date in terms of nabbing the best projects at the best rates. As a bonus, Nathan and I had an exchange about my presence on Twitter I’ll include for those who make it to the end of this piece. 🙂

Without further ado, let’s take a closer look at how this interaction played out.

Nathan’s first response: “The reason I’m not doing BW fulltime anymore is that it seems to me that 80% of the current BW consultant market is made up of ex-ABAPers. There are practically no functional people working in BW and <1% are pure front-end report specialists. I only know of a few BW consultants whose original skill sets could be classified as “functional.” That means that the current BW skill set is very focused and specialized… very technical. And if you don’t have that skill set, it doesn’t make sense to pursue BW work.

Basis folks work between the different apps, and Security guys do too. But that hasn’t carried over to functional resources. The people that really build the functional solutions aren’t going back and forth between FI/CO and a Financial data model. It seems that the same is true in other SAP areas such as SRM. once someone with an MM background went into SRM, they’ve never gone back.

So I feel strongly that this whole “every consultant will need to work with __” just isn’t true in any area. They may need to ‘know’ BW, but only in the sense of where it is and where the lines are drawn between their home area and BW. No one goes to a FI/CO consultant and asks them to build BW queries. They go to the BW team (the BW team wouldn’t allow it even if the person, such as me, could do it).”

In his next comment, Nathan responded to my “Tweet” from my Twitter live blog from the BO show: “Consensus from BI/BO insiders: BI is no longer a “skills specialization, but something all SAP consultants need to add to their skill set.” 

Nathan: “People have been saying this for years and it hasn’t happened yet.”

Jon Reed’s response: “True, but the technologies are advancing now. Keep in mind I didn’t say this myself; I tend to think this is still a few years out, but I think it will happen. Though as you say, there will always be a significant focus on the technical side, though ABAP will expand to include Java based on the BO acquisition, and there will be a lot of data warehousing/architecture work as well.”

Nathan: “So I feel strongly that this whole “every consultant will need to work with __” just isn’t true in any area.”

Jon Reed’s response: “Yeah, it’s a matter of degrees though. I think all consultants will need to know something about BI. Yes, it will be technical folks getting the bulk of the BI action, but I do think the GRC and EPM suites will be more of a factor in the years to come, and there will be functional work in those areas for sure – I’m including that in my conception of BI.

I would say the same is true of Solution Manager….those two areas, Solution Manager and BI, it will be helpful to know how those tools intersect with what you do, and as reporting extends through the enterprise and are more embedded in the SAP screens themselves, it should come up more. I don’t disagree with you, I think it’s more a matter that I was reporting a consensus statement in a “tweet” that is deserving of a much longer article at some point.”

After I wrote this to Nathan, I realized that I would also add eSOA to the list of things most, if not all, SAP consultants will eventually need to engage with, but again, with a multi-year time horizon.

Nathan then elaborated on why he is skeptical that the Business Objects acquisition will turn into a marketable skill area for SAP functional consultants. His thoughts were provocative, so here they are in their entirety:

“I remember when SAP Consulting tried to transition a lot of us Platinum Consultants into BW when it came out in 1999. And they had a similar message… “Everyone will eventually have to know this because it’s going to be so kickass and be the reporting tool to solve all of our/your problems.” It didn’t happen. It quickly became a completely separate skill set and, in my opinion, has remained that way.

The only way to work in BW was to completely switch over to it. Even the ABAPers weren’t able to easily transition into the new product. There were enough differences and enough of a functional appreciation to the implementation of the solution that they didn’t all come at once. I think it was only in the past three years that a tipping point occurred and now ABAP programmers make up the majority of the consultants in that area.

With the BIA (Business Intelligence Accelerator) and ABAP-OO (Object-Oriented ABAP), BI has now become an even more technical skill set in the eyes of SAP customers. So how is integrating a completely new product suite supposed to facilitate the engagement of other non-technical people in CRM, SRM, ERP, etc.? Most of the time, when you add more technology and functionality, you end up with more complexity.

This would seem to make it harder, not easier, to widen the base of users. VC (Visual Composer) is a perfect example of this. It was supposed to be a super-user tool but that won’t happen at that level. You have to be someone who is working 100% with SAP (a consultant or SAP support person) to use that kind of tool. I can think of only about 4-5 super-users that I’ve met in the past 13 years that are capable of using VC.”

Nathan also had some closing thoughts on how his role has evolved and where he would like to head next with BI/BW.

“All of that said, I genuinely hope for what the analysts are saying to be true. As someone who has done six years of hardcore data modeling across FI/CO and SD from BW release 1.2b all the way to BI 7.0, it would give me more credibility with customers if I could point to my robust BW experience as an edge over my competition. But like I said, I think the skill sets are so different that no customer goes to their MM consultant (or in-house employee who does MM processing or configuration) and asks them to build a BI query.

But if BobJ really is the giant leap forward in end-user usability that we’ve all wanted (and quite frankly, expect out of this acquisition), then the stigma of only BW people doing BI reporting will fade. I’m all in favor of that happening… more so than any other functional consultant who follows your writings. But I’m doubtful that it will happen.”

As promised, Nathan had some thoughts about finding me on Twitter:

Nathan: “That’s only the second time I’ve been to Twitter. I spend too much time on the Internet as it is and just don’t have time for it. I think the first time was to read some guy tweeting about how he was getting fired from Yahoo (turn in laptop, exit interview, etc.).

Jon Reed’s response: “I felt the same way at first, but it’s neat way for me to get out immediate thoughts and insights as they come in….we’ll see. My Twitter “micro blog” is focused on SAP skills trends and I’m trying to stay much more on topic than most Twitter blogs, without as many personal updates and randomness, but still keeping some personal flavor. Also, my “tweets” are also posted on the top right of my JonERP.com web pages as I post them, so it’s a way of giving my site more immediacy and keeping folks in the loop as to what I am up to.” I’ve noticed other SAP folks involved with Twitter and follow a number of them, it will be interesting to see if we agree on the value Twitter can add to our knowledge base – or is it just a way of staying connected socially? Comments on this welcome.

Jon Reed’s conclusion: my final thought on Nathan’s view is that he represents a very credible and appropriately skeptical take on the hype factor we run this risk of getting seduced by when it comes to SAP’s latest technical advances. At the same time, I think my previously cited BO skills piece is worth reading as a balance to this particular email exchange. What I tried to do in that piece was define some practical next steps for skills acquisition without drinking too much of the SAP-BO Kool Aid. With folks like Nathan chipping in, we should be able to improve our career prospects without falling into misleading hyperbole.

Assigned Tags

      12 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I think it was three or four years ago when we had an SAP internal workshop and I ran around telling everybody "Every SAP project is a BI project and we should focus selling it this way."
      Guess I was a bit fast at that time but your blog made me think that the time may have come now. Yet I don't think that any consultant needs a solid BI/BO subset of skills. But he needs to be able to know the SAP BI solution well enough to understand what part of the customer requirements can easily be implemented in BI instead of a clumsy ERP solution. The same goes about the VC. You don't need to be able to build complex VC applications but you need to have a feeling if VC can solve this problem or not.

      I also was surprised that a lot of the BI people come from the ABAP background but it doesn't really surprise me. BI and ABAP are both mainly about finding the right model for the required solution so the thinking is very much alike. And I told all our young BI consultants to visit ABAP courses for more than five years now (and still find a lot of awfully programmed exits in BI). But the important thing to understand is that you are a bad consultant if you don't understand the query design. I had so many customer requirements that needed both sophisticated implementation in frontend AND backend. I even have a customer that is always talking about "MY query" with a special emphasis. I always know which query is meant and it is one that contains about 10 columns that are only there to calculate the two columns the customer wants to see.
      With BO the whole landscape changes. You need to be able to understand another layer of software to build optimal solutions. And you NEED to understand it if you want to be able to deliver state-of-the-art solutions. So yes, BI skills will be required for everybody. Not a detailed doing but a better understanding WHAT you can do with the system.

      Author's profile photo Jon Reed
      Jon Reed
      Blog Post Author
      Dirk, excellent comments!

      Although I think it's foolish to try to attempt a consensus on a topic that is going to vary based on very different customer projects and priorities, your comments seem to flesh out that middle ground between my original concept I floated of "BI for everyone" and Nathan's more skeptical response.

      I thought this comment of yours summed it up well: "Yet I don't think that any consultant needs a solid BI/BO subset of skills. But he needs to be able to know the SAP BI solution well enough to understand what part of the customer requirements can easily be implemented in BI instead of a clumsy ERP solution. The same goes about the VC. You don't need to be able to build complex VC applications but you need to have a feeling if VC can solve this problem or not."

      Perhaps the key, then, is not to have the nitty gritty experience in some of these new tools but to be able to help SAP users understand the pros and cons of each and how they can be applied, with an overall business context in mind and not just "because it's a neat new tool," which we all know is not going to fly anymore.

      I liked your ABAP and BI comments also. One thing I touched on with Nathan is that the Business Objects components are written in Java. It will be interesting to see if the combined SAP-BO product offerings emphasize primarily Java, or ABAP, or some combination. I should do so more research on this myself and see what I can come up with.

      However, since BO products can also be implemented independently of SAP, it does not seem irresponsible to suggest that once again, for SAP developers going forward, the ABAP/Java combination may be more powerful than one or the other in isolation.

      Thanks for the informative comment!

      - Jon Reed -

      Author's profile photo Former Member
      Former Member
      I don't think this is a "product" issue (BO vs "old" BI). Every project being a BI project is a philosophy I hold very close to heart, and implement in all the programs I manage. However, the tools do not matter really in this regard- SAP BI, or BO or Cognos would work just fine as long as we approach the projects as "BI driven". Earlier in the year, I blogged on these ideas in SDN too.

      Since it is not a "product" issue in my mind, I don't see a good reason why BO acquisition will suddently help change the outlook.

      When SAP started BW, there were a lot of "functional" BW people around. But since every project needed a lot of ABAP work, I think over a period of time - market decided that it is probably better to have technical people run BW. Functional people, as I remember, didn't hold any extra edge over techies. Functional guys used to understand the data in R/3 better, and how best to present the data to users in a report. But the ETL in between was not their forte. ABAPers filled in the void in between source and target, and eventually took over the modelling and query writing as well. Those functional guys who took the pain to explore the technical aspects of BW, became hot commodities in the market- and they earn the best rates I know ofin BW space. Others moved on to alternate parts of the SAP ecosystem, I guess.

      Author's profile photo Former Member
      Former Member
      You're right, this is not a product issue. Yet the BO layer which is non ABAP may shift the focus to the functional or should I say process people again. A pure techie may go on further than a pure non-techie can go in BI (due to the fact that ETL is mostly technical) yet none of those can solve a company's requirements alone. You need both, and ideally in one person. But you're right, those people are rare.

      I can also tell you where the functional guys who didn't want to learn ABAP went to. To Planning, Balanced Scorecards etc. 😉

      Author's profile photo Former Member
      Former Member
      true - a lot of them took up SEM (including yours truly, although I can also do some programing). But as things stood in SEM - I don't think I had any project that didn't use ABAP exit functions of some sort (mostly because I hated FOX). But SEM guys had more chance of surviving without ABAP knowledge, than BW/BI guys.
      Author's profile photo Jon Reed
      Jon Reed
      Blog Post Author
      Vijay and Dirk,

      Terrific comments, very helpful and specific.

      I tend to agree with a lot of them. Vijay, to respond to your comment about this not being about products, I agree to a point. The acquisition of BO was more than a product issue, it was a clear indication that the overall BI space is going to be important to SAP going forward.

      I do think BO will eventually impact SAP skills, at least on the technical side, due to the need to get a handle on the Java-oriented technical side of BO. And until BO is fully integrated into NetWeaver, knowledge of BO's EIM integration tools will be important to Basis types.

      As for functional folks, perhaps not so much on the BO side right away, we'll see, but I will point out that SEM is no longer really pushed by SAP, it has been dropped from its place as one of the Business Suite products. The BO product line helps to round out the new SAP EPM Suite, which to me seems like the natural evolution of SEM, and, in contrast to SEM, is being pushed heavily by SAP currently. So, perhaps BO doesn't change much that way, but it seems like EPM will take over from SEM as the "higher functional ground" you guys were pointing to on the BI side, no?

      Good stuff, thx.

      - Jon Reed -

      Author's profile photo Former Member
      Former Member
      Jon, I agree - pretty sure SEM folks will migrate to EPM. It will take a while though - since the roadmap makes me think it is ok to wait a couple of years or so while SAP stabilizes the product and then take the plunge.
      Author's profile photo Jon Reed
      Jon Reed
      Blog Post Author
      Vijay,

      makes sense to me.

      My only question is that from what I can tell, the EPM suite is pretty fleshed out product wise. In particular, the Business Planning and Consolidation component of EPM, bolstered by the OutlookSoft acquisition, is already gaining some traction on job orders, so I'm not sure I'm clear on the value of waiting a couple of years.

      Here's what I have for the EPM side:

      Strategy - SAP Strategy Management (formally Pilot Software, an SAP acquisition)
      Planning - SAP Business Planning and Consolidation (formerly OutlookSoft, an SAP acquisition)
      Consolidation - SAP Business Planning and Consolidation (formerly OutlookSoft)
      Financial Consolidation - Business Objects Financial Consolidation (formerly Cartesis)
      Profitability - Business Objects Profitability and Cost Management (formerly ALG Software)

      So, it's a combo of SAP and BO, but mostly finished products. Though, I would think that it would take a while to stitch them together, perhaps that is what you are thinking in terms of your two year roadmap? Not to learn a new component now but wait for the integrated suite?

      By the way, I think it's interesting that so much of the functionality comes from acquisition, though I assume that some of the "best of SEM" will make its way into these products over time....

      - Jon Reed -

      Author's profile photo Former Member
      Former Member
      It is the "integration" aspect that is behind my thought of waiting for a while before jumping in. Whenever SAP bought something in the past, it has taken them a couple of revisions to get it right (and this is completely normal due to the size and complexity involved). The techie in me prompts me to learn these new things early, and the manager in me holds me back from jumping into an implementation too soon.

      Also, with the advent of SOA and open architecture standards, the possibilities to use other vendor's software for SEM like functionality have become more realistic and easy. Like in reporting where Microstrategy and Cognos could work just as well as BO (or so they claim). What are your thoughts on that?

      Author's profile photo Jon Reed
      Jon Reed
      Blog Post Author
      Vijay, understood re: waiting till integration of EPM suite is complete. I would just suggest keeping a close eye on it since some job requirements in some areas suggest that customers are using parts of it already.

      Also, along the lines of your point on integration and plug and play, this would say to me that for the EPM product as well, plugging in one part of the product should be doable, so the integration of the whole suite may not be crucial. I'm not the expert on the EPM suite though.

      I would agree with your point overall that there is going to be an easier way to plug in components based on eSOA, NetWeaver PI, etc. But it does seem to me there will always be some payoff to going "all SAP" - at least for companies that are heavily invested in SAP in the first place. This gets back to the "who do you call when things go wrong" principle of business software that helped SAP and Oracle to triumph over i2 and Siebel, that is, before Oracle bought Siebel.  🙂

      - Jon Reed -

      Author's profile photo Former Member
      Former Member
      Very interesting point - Jon; you are right - SOA should apply equally to EPM as well.

      The whole SOA thing is fascinating in how we can spin arguments both ways :). One one hand, we need one throat to choke if something goes wrong. On the other hand we want to use SOA to enable seamless integration with best of breed solutions (which then increases number of throats to choke). If the best of breed solution is an SAP product, would we still use SOA? theoretically it is a good idea for sure - but I wonder how many companies will actually bother.

      Author's profile photo Former Member
      Former Member
      SOA will be the tool to integrate the different SAP products. The reason for this is that SAP turns into a process oriented company and uses SOA instead of the old BAPIs to integrate its components. On the other hand this makes it easier for migration projects. You can add an EPM frontend component to a legacy warehouse and later switch the legacy data warehouse to BI without affecting the EPM implementation. So we WILL use SOA in SAP - and very soon. I just finished my first SOA implementation and currently work on the second one - and no, I'm not a SOA expert but a BI techie by heart.
      But BI as an EDW is all about integrating other systems so SOA will eventually come - very soon.
      On the other hand the new EPM products are very different from SEM because they are mostly frontend tools. I cannot really envision programming exits in Java that manipulate data in the BI cubes - but we will see.