Nov 14 2011
SAP + Business Objects Skills – Do They Exist?
A few months ago I had the pleasure to talk to Courtney Bjorlin of ASUGNews.com about a Twitter exchange taking place between several folks. They were discussing the need for (and likelihood of) finding Business Objects experts (whether employees or consultants) that already have SAP skills. The main points of the discussion revolved around the concept of whether there was a current market for SAP + Business Objects skills, and secondarily whether there was even a supply of folks with the required expertise if so. I’m not in the consulting arena anymore, but I’ve seen how things have progressed over the past decade and definitely had some thoughts that I shared with Courtney. She wrote a post for ASUG News (included in the related links at the end of this post) and we also revisited the talk at the conference last month in Orlando (YouTube link also below).
I thought I would go into more depth here since I’m not bound by editorial constraints as far as post length. 😉
My personal experience is certainly weighted on the legacy Business Objects side. I’ve been working with the products since 1995 and have seen quite a progression during the last sixteen years. Keep that in mind as you read this post as I am sure it gives me a certain bias. The question of the day: Is there is an adequate supply of Business Objects experts with SAP expertise? Does that question even make sense?
Over the years I have seen far more Business Objects installations that are departmental or functional rather than enterprise wide. I see the same thing today with Microsoft products taking over a lot of the smaller to mid-sized BI projects that may have picked Business Objects in previous years. SAP, on the other hand, is by default at the enterprise level. I don’t think I ever saw a company that intended to run ERP systems from both SAP and Oracle at the same time, but I saw plenty of clients that were running Business Objects, Cognos, Microstrategy, or any of the above in various combinations. Business Intelligence just wasn’t seen as an enterprise asset, at least in the early days. Where does that leave us today? I think it might help to review where we came from and then see how that has impacted the current job / skills market.
Historical Perspective: Business Objects Careers
I started working with Business Objects in 1995 and since then I’ve seen a lot of interesting twists and turns along the way. In the old days there wasn’t much to a Business Objects installation, thus the concept of “departmental BI” that I mentioned above. We had universe developers, report developers, and users. The only “enterprise” bits were the repository (which often went to the DBA team) and the scheduler (which went to the Windows network administrators because it required a windows server to function). That was it. In fact the very first version of Business Objects that I worked with combined the “supervisor” functionality right into the reporting system. If you logged in to BusinessObjects with a specific username and password then you could set up users and change their passwords and so on.
Even the fact that the company name (Business Objects with a space) and the product name (BusinessObjects no space) were essentially the same should show how simple (and small!) things were back then. When we walked to school. In the snow. Uphill both ways, and all of that. 😛
Because the required skill set was much smaller it was not unusual to find a true “soup to nuts” Business Objects expert in those days. When I started with Integra Solutions we only had four people in the entire company. Due to our diverse but overlapping backgrounds in databases, networking, and desktop applications we became one of the top Business Objects partners before Business Objects had a partner program (or even realized that they needed one).
Fast forward about a decade and by then Business Objects had introduced a true enterprise platform that ran on Windows, Unix, or a heterogeneous cluster (a combination of both). The administrative side of the equation was quite a bit more complex and required a broader skill set than before. We had both desktop and a web clients that could be used to build reports. Of course at first they were dramatically different and experience in one did not directly translate to the other. To further complicate matters Business Objects purchased Crystal which then meant there was a third reporting option that many folks didn’t understand. Eventually we saw a completely new server architecture (with the XI release) that was based on Crystal code. At this point finding a “soup to nuts” expert was just about impossible simply because the skills required to manage a complete Business Objects installation were so much broader in scope. So even before the SAP acquisition the consulting marketplace was becoming more and more fragmented.
Often the infrastructure team would install and configure the software, but these folks would not be able to write a report of any kind. A report developer might know Crystal, Desktop Intelligence (the new name of the original BusinessObjects desktop product), Web Intelligence, or some combination of all three. However, it was fairly rare to find someone with deep experience across the whole suite simply because for years Crystal and Business Objects had been competitors. (Somewhere along the way we also acquired Xcelsius which was yet another new and different platform.) Many report writers didn’t have a clue about developing a universe, or were in fact isolated from that part of the team. Universe development remained relatively stable from 1996 (the introduction of the “original” 4.0 release) until this time simply because the universe designer tool didn’t change that much. Ironically we have just recently seen the formal release of a dramatically different universe builder with the “new” 4.0 release. Universe designers finally have some new toys to play with.
Today we are several years into the SAP acquisition. There are SAP people that are trying to learn Business Objects, and Business Objects people trying to learn SAP. Who is the best suited for a particular application? It’s a question that I don’t think has a simple answer. Much like Crystal versus Web Intelligence, SAP was initially a competitor – or if not a competitor at least they were not always considered complementary – for Business Objects. SAP partners had no compelling reason to develop expertise in the technology simply because it was not commonly requested. SAP had BEx and BW and was deeply invested in those technologies. In all the years I spent as a Business Objects consultant I don’t think I ever once was asked to report on SAP data.
After SAP purchased Business Objects, some SAP partners went out and purchased Business Objects partners in order to get a jump start on the technology. Did that help?
The point of all of this background is that it does not surprise me at all to hear that folks are saying that there is a shortage of SAP + Business Objects skills. I expect it will continue for some time. Why?
Earlier I talked about the fact that SAP is by default an enterprise application while Business Objects does not have to be.
I feel that it’s far more likely that an SAP shop would now be interested in Business Objects experience than the other way around. Any Business Objects shop that is not already an SAP ERP customer is probably not likely to dump their current solution for SAP; it’s a far more costly decision than the other way around. So let me instead provide some thoughts about SAP shops. I would expect one of two situations: Either it’s an SAP shop that already had Business Objects experts in house because of other reporting systems / solutions or data sources outside of SAP, or it’s an SAP shop that had zero Business Objects presence prior to the merger.
Departmental Versus Enterprise
Earlier I brought up the concept of departmental BI. I think this is the first obstacle to finding or building people with deep SAP and Business Objects skills. I’ve heard more than one person talk about Business Objects as “departmental BI” because it could be implemented fairly easily. Department X would implement Business Objects while Department Y would implement Cognos, all based on their own preferences. Business Objects did not require an enterprise installation in order to be successful. That means there could easily be different expertise scattered throughout a company. I saw this many, many times during my years as a Business Objects consultant.
On the other hand, SAP — almost by definition — has to be enterprise. You won’t find Finance implementing Oracle Financials and manufacturing implementing SAP. It just doesn’t happen.
Given that, let me go back to the first scenario I mentioned earlier: an SAP installation with Business Objects as departmental BI. Suppose that the two groups are under different management. Suppose that the Finance group has long used Business Objects for reporting outside of SAP, and they already have extracts and databases and universes and everything else in place to support that. They roll up to the CFO, who may or may not have a good working relationship with the CIO who is over the SAP group. Where is the incentive for a Business Objects expert from the finance group to train an SAP expert? Or vice versa? In each case, I have to imagine that each feels the other is trying to take over their job. The Business Objects person would want to say, “Just get me to the data, I’ll take care of the rest.” The SAP person would say, “I have the data where I want it, I just need to know how to write the reports and build my dashboards.” In each case there could be a definite sense of encroachment from the other side, and a certain resistance to making that collaboration work. This scenario could play out with internal employees or external consultants. Each is trying to protect their own territory and maintain their business purpose. Once either of them becomes an expert in “the other side” then one side becomes superfluous, and nobody wants that in today’s market. In this case it’s a political rather than technical obstacle.
Take another case. Remember that SAP is typically thought of as “big” (their Business One solution not withstanding) and “big” typically means lots of people. From a human resources perspective it’s going to be considered more appropriate to try to cross train an existing surplus of folks (SAP) than hire specific experts (Business Objects) and bring on more resources. Everything today is about cutting costs, right? So take your existing SAP BW folks and make them multipurpose to avoid costs of new people. This can be done through cross-pollination with an existing group within the company (subject to the political concerns listed above), training, or temporarily hiring a Business Objects consultant. If you’re going to hire that consultant, though, wouldn’t you want them to have at least a passing knowledge of SAP so they don’t go “huh?” when you mention cubes? Thus, the perception that the BW folks are going to want their Business Objects experts to have at least some SAP knowledge is an easy leap to make. There’s a financial obstacle to getting the right people on board.
And of course I haven’t even touched on the technical issues. With XI 3.1 there are certainly some enhancements as far as how to integrate the two packages, but in my opinion they’re still really on “separate-but-not-quite-equal” footing. It’s not until BI 4.0 that we really see good integration, which means until BI 4.0 has been out in the market for some period of time, there simply isn’t a good platform to develop integrated skills. That gives us a technical obstacle to overcome in addition to any political / financial issues I’ve already mentioned.
An SAP shop with no existing internal Business Objects experts would potentially have a benefit here, as they can at least try to hire a consulting partner to come up to speed. But where did those partners get their experience?
Does Any Of This Really Matter?
Given all of these obstacles, why are SAP shops going to prefer someone with SAP skills on the Business Objects side? If you’re going to report from BW cubes and use Web Intelligence, then the report writer doesn’t need to know how the cube is built any more than they had to know how the universe was built. But if you want your report writer to also be able to talk intelligently to the cube folks and make appropriate requests for enhancements that would improve the report, then yes, they should have some background. There might be “best practices” as to how to build your cubes in order to leverage (or at least avoid pitfalls in) features of Web Intelligence, Crystal, Xcelsius, or any other new tool that they have available now. There’s also the “huh” factor I mentioned above, where if you hire an expert / consultant you really do not want to have to train them on how to access your data.
A Brief Aside
Here’s a tidbit from me personal experience: Last year I spoke at TechEd. My topic was intended to show “Business Objects for the rest of us.” My opening remarks went something along these lines:
If you are big enough to run SAP, then I can almost guarantee that you have non-SAP data that you want to report on. Yes, Business Objects has done quite a bit since the acquisition to make it easier to implement their tools on top of SAP, but what about those other data sources?
From there I went on to say that I was not going to talk about cubes, but instead would show how Business Objects works outside of an SAP environment. The goal was to give attendees some information they could take home and start thinking about how to use their new toys against those “other” databases.
The first question I got at the end of my session was about implementing BOBJ on top of cubes. 🙂
Pass The Salt
I’m currently reading a book about the history of salt in human civilization. It’s very interesting. Salt was used as a currency in many areas (and for a very long time) because of the perceived value but also the difficulty in obtaining it. A combination of deep SAP + expert Business Objects skills is probably considered extremely valuable right now for the same reason: it is rare and difficult to obtain. Mmm, salt. Time for a margarita. 🙂
(Disclosure: This post typed while listening to Jimmy Buffett.)
Related Links
- ASUGNews.com blog post: Wanted: SAP BusinessObjects Skills — Can Supply Meet Demand?
- YouTube recording of our conversation during the Orlando SAP Business Objects user conference
I think the tricky part of this discussion is whether a company is getting quality salt from someone who claims to have SAP and BusinessObjects skills. How do you know if that person really does have the skill set, when few will have the ability to truly judge competence, at least initially? Just look at the sea of people on Linked In who are SAP or BusinessObjects consultants. It’s seems challenging to filter out the best candidates at this point.
Hmm, just my 2 cents.
Sap specialists can easily learn SAP BO, most likely they will be using BICS and WebIntelligence, ok let’s add Crystal reports and Xcelsius (or Dasboard builder??), CMC to the list, but there is no real need to learn Designer . And these things are relatively easy to learn, while you need to spend almost 2 weeks in the training class if you’re willing to call yourself ‘familiar with SAP BW’.
Very Good Insight Dave. I [http://www.linkedin.com/in/gopalkrishnamurthy] am one of the very few consultants who are equally competent in both SAP BI and SAP BO. Having surrounded myself with consultants with similar competency that this skill of true SAP BI/BO consultant/architects do exist without much of visibility because we are very busy to be active at forums or conferences. First of all our skills acquisition mostly happened due to accidents [lack or incompetent resources] and passion for BI rather than by design. One thing we can share is that like VP mentioned it is very easy for experienced SAP BI resources to acquire BO expertise as long as they pay due respect for BO as a skill and not train/learn as skimpers (most take it easy and for granted]. It is much harder to get an enterprise BI thought/view for BO architects but not impossible. We continue to share the integration expertise with folks who are passionate like us and have recently started exploring how we can have better share/communicate/train BO architects. I am very confident that folks who are passionate about BI will fill that void as long as clients don’t try to integrate two different System Integrators or two different skilled consultants (SAP BI and SAP BO) Vs try to integrate a single passionate mind. Cheers, Gopal
The way I see it, it’s always about the money. When a Customer needs to have a BI/BO solution running they always have a budget and a deadline. In almost any scenario there is technical problems that have to be solve in no time. To me, I think is always better to have the best resource for BW tech problem and the best BO resource.
I’ve been working with Business Objects for more than 12 years now and I don’t have any SAP BW building experience. However, I have worked in many SAP BW/BO projects that were successful because BW consultants were very competent (Of course I had to learn how cubes and Bex Queries work but I didn’t have to build cubes or Bex queries).
With that being said, do you still prefer to have a consultant with BI/BO experience than to have two resources specialized in BI and BO?
Most of the time you don’t need to have a BO guy in place when the Cube is built so, if your plan with that in mind you won’t have a consultant sited at the office waiting for the cube to be ready.
Even when I’m not planning to become a BW consultant, I think that we (pure BO Consultants) need to understand better how to interact with BW World and how BO4 will require for us to use these new skills.
Hi Dave.. I have exactly the same feeling after working with Business Objects for the last 10 years.. But i think HANA might change the scenario a bit. Relational modelling (through SAP HANA) will be more important in future. Many of the ‘original’ BO consultants actually have a strong DW / ETL background so it will be interesting to see the ‘balance of power’ in future. What i have noticed over the years is SAP BW consultants have a feeling that BO can be learnt in a matter of days and that ‘you folks have a lot to catch up’ attitude. But what people do not understand is that BO is not just for SAP . As you have rightly pointed out BO can be used on any tactical or ERP solution for any industry. Also BW role in BI solution will be a ‘bit’ less in future with the advent of HANA. As BO consultants we loved doing DW on a relational model and building universe (which is not required in BW and some consultants fail to realise that its one of the most complex things to learn in BO)and we will probably love to do the same in HANA in future. my last 2 cents.. have a look at my blog ..not for the content but for the picture i have posted :)…www.botalkshop.blogspot.com