Skip to Content

The new realities of SAP consulting market – and survival tips

In November 2008, I blogged on SCN about The Road ahead for SAP consultants (Road ahead for SAP consultants). This blog was pretty well received by the community and a lot of discussion ensued in terms of comments, emails etc. Jon Reed, fellow SAP Mentor, needs no introduction here. His site has been a go to place for all consultants, and his blogs and podcasts have had tremendous following. Jon and I share a deep interest in several aspects of SAP ecosystem like skills, BPX, community spirit and so on. So we decided to do this podcast together.


You can find the podcast  at . We will try to get it uploaded to SCN too.


Here are the highlights

1. SAP market is transitioning more and more into a global delivery mode – with distributed teams. Apart from the obvious cost benefit, this also brings in local expertise where needed. Technology has now improved so much that even parts of blueprinting can now be done from remote sites.


2. Certain skills in SAP like Basis, ABAP etc are getting commoditized in the market. What can be done about it?


3. Will SAP market return to its old state or has it changed permanently?


4. What is changing for functional consultants? what skills do they need to survive and prosper in these times?


5. The all important BPX concept – is this a futuristic idea? How can we make it work today? what are the roadblocks?


6. Why is BI an important aspect of BPX?


DISCLAIMER : The views expressed in this podcast by me are strictly my personal opinions and should not be interpreted in any way as those of my employer,IBM.


Jon and I are looking forward to your comments. You can find me and Jon on twitter as @vijayasankarv and @jonerp respectively.

You must be Logged on to comment or reply to a post.
  • Thanks Vijay –

    The podcast should be uploaded into the SCN system soon – for now, it can be found using the link in your post.

    I had a couple people tell me about this podcast – “Thanks for telling it like it is.” I didn’t want the podcast to be too harsh, because there are still great opportunities in SAP. What I wanted to get across, and also hear about from you, was the extent of the changes happening due to the global delivery model. These changes require a skills response on an individual level, and I think you did a nice job of laying out some of these skills approaches, which include BPX type stuff and more.

    I hope this conversation will continue and look forward to hearing more from other SCN members.

    – Jon Reed –

    • Fascinating BPX relevant/topic relevant post from Paul Harmon of BPTrends. here Saw @vijay tweet that he continues conversation with friends here Thanks gentlemen for a provocative listen.
  • Quick Thoughts…

    1. I agree (and enjoyed hearing) with your comments about BI being a commodity skill.  BI can potentially realize more benefits to a customer than most any other SAP application.  Any app that can provide as much clarity and insight into the costs and sales of a company should receive the highest priority…  the cost of the app shouldn’t be nearly as important, but it seems like it is.  I too do not like what I see in the BI market regarding global delivery but am not fighting it.  Maybe there will be a change in direction later on.

    2. if it is true that customers are pushing more core configuration work off-shore, my first thought is that this is a reactionary movement to the current downturn in the market.  Customers are extraordinary price sensitive at the moment which means that off-shoring is their only option for certain types of initiatives.  I’m not so sure that this trend (if it is indeed factually accurate) will last.  But…  as a functional consultant I agree that this is something to keep our eyes on.

    3.  “global delivery model … is here to stay.  traditional SAP consulting  …  is never coming back.”

    The big elephant projects are mostly dead.  No doubt.  Customers, partners, integrators, and consultants need to be able to respond to more focused and short term requirements because there aren’t going to be many 18 month MM-PUR roles out there.  More likely you’ll see someone who wants a very deep dive into enhancing their invoice verification process and then moving on to another initiative.

    • Thanks for sharing your thoughts, Nathan.

      On point 2 – as i remember, the push to start moving functional work offshore started before the economy nose dived. But it definitely gained momentum in a knee jerk reaction. However, once customers see it work – and it will work because smart people adapt and will always make it work, will they ever stop doing that?

      • Functional work, more so than technical, requires a more intimate dialogue between the different parties.  There are negotiations amongst the process owners and real opportunity for someone to give advice.  There are too many inquiries about different approaches, ‘what do other customers do’, and questions about standard functionality to simply write up a spec in MS Word and email it someplace.  This is a consulting role and not easily done without dialoque. 

        See it work?  I clearly don’t have the experience you do in this arena and don’t contest people/companies who talk about off-shoring success… but in the 3 projects where my customers did use a global delivery model to lighten the load of the project resources, it failed miserably.  Even simple technical items such as a master data extract was met with replies: “what table is the profit center on?”.  Ridiculous.  There are probably several reasons for this and I can only hope that it’s gotten better but I don’t share the same optimistic viewpoint.  Spending a few minutes on a functional SDN forum only strengthens my viewpoint.

        • “what table is profit center in” and similar questions do crop up in global delivery, but I remember onsite people asking dumb questions in the past .

          On one hand it is cheaper to solve this, even multiple times, in global delivery models. On the other hand, this will need more time, and can put timelines at risk.

          • hit enter too soon…

            Also wanted to add that there is a time factor involved while the team matures – and established SIs have good processes in place to minimize the risk due to this. For example, these days it is very common to make sure that in each geo where work is done, a functional guy is either available full time in team, or available on call. Also, there is a more efficient hand over between onsite and global delivery teams now. Things that we used to take for granted cannot be taken thusly in global delivery. One way is for an onsite lead to do some QA on all specs to make sure the language is clear and assumptions are explicit etc. It takes some getting used to, and often is a frustrating experience for an excellent functional consultant – and I would never argue otherwise.

          • Nathan and Vijay,

            Good exchange here. I’m not sure there is one right answer between the two of you, because I think it varies from project to project, but the dialogue is very instructive to read. Nathan you are always commenting with sharp insights on blogs pertaining to SAP skills and I really appreciate what you do.

            The area we have some consensus on is that the big “elephant” SI-driven SAP projects of the past are largely going to remain a thing of the past. In terms of how much outsourcing is going to remain a tactic when budgets improve, we’ll have to see. I happen to believe that when companies achieve cost containment, they aren’t going to change their behavior.

            Nathan, we’ll have to see how this plays out. I believe that core IMG type config work and some of the blueprinting that Vijay talks about will become outsourced on a regular basis and a commodity skill. I believe functional consultants will need to provide something of value beyond config to be successful in the long run. I may be proven wrong about that but all the people I respect in the SI world tell me this is already starting to happen – a main point of doing this podcast now.

            However, when the value of a functional person goes beyond basic config, then I see that work as more essential on site. That’s a big part of the focus of the second half of this podcast, continuing to define and discuss what that is. Nathan is the type of consultant who already embodies many of these deeper skills, but not every SAP consultant brings that kind of experience to the table in my opinion.

            The point of the podcast was not to provide definitive statements, how can you do that in a market in flux like this one, but to continue to foster conversations like this one. Thx.

            – Jon Reed –

          • it’s cheaper by the hour but even a moderately Sr. Consultant can solve some items quickly and more accurately whereas a Jr. one takes much longer…  and there is a much lower level of assurance that it is accurate.  So it can certainly be more expensive to use a global provider for a given month or longer term when poorly designed solutions need to be re-built.  I have no metrics to cite…  just common sense.  I’ve been thinking of trying to blog about this but don’t have the time yet.
  • Hi Vijay,

    Let me throw in my thoughts, albeit a little late.

    I have to say that my impression as a UK based consultant in terms of levels of outsourcing couldn’t be further away from your experiences. Let me try to describe the picture that I see right now:

    Most of the numerous clients I worked for over the past 11 years are US, UK, Germany or France based and most of them have dipped their toe into the offshoring waters in one way or another. None of them are bragging with success stories or even newly found collaboration. Quite the opposite. Most project managers and development team leaders I speak to are complaining about poor quality of code, language problems, time differences, lack of business exposure and poor levels of basic system testing, to name but a few.

    In order to work around this, clients’ business analysts spend more time getting the specifications as detailed as possible so things are clearer for offshore staff. However this in return slows down delivery and budget spent on analysis. As a compromise, I advise clients to do the “easy” stuff offshore and get experts in for mission critical tasks such as interfaces and bespoke work requirements.

    I strongly believe that there are a lot of very talented people working for offshore SIs, but in my own experience a lot of them seem to have been trained up too quickly and seem to work under a lot of stress with competing developing tasks for other clients. I also found language problems can be a big issue, up to a point where one of my clients (a global logistics player) actually flew ABAPers over to the UK from India, all expenses paid. Thereby avoiding any further misunderstandings and ensuring the developers are completely focussed on the task at hand.

    Global delivery models: Not sure if this has really kicked in yet to the degree you’re describing, but if there is one thing that I have learned in my IT career so far it’s the fact that nothing ever really “dies” or replaces something. We had centralised systems and then distributed networks. Now the cloud’s all the rage. The same is going to happen to global delivery models, because it’s all coming round again to local work. And why? Because if everyone does it then there is no competitive advantage through IT anymore and the pendulum swings back again.

    Last point about functional consultants: Yes, the good ones who are equipped with business process knowledge will stand out and attract better rates. But in my opinion that’s already been the case 10 years ago, so I don’t think we’re experiencing any change there.

    Kind regards,

    • Hi Michael,

      Thanks a lot for posting your thoughtful comments – much appreciated.

      What I expressed was strictly based on what I have seen in US clients, although some of them do have big operations worldwide. So there might very well be a regional difference between US and UK. Plus, my observations are limited to the projects I see – and I dont see the whole set of projects in US. So don’t take my words as universal truth 🙂

      Now about the cost and effort – I completely agree that it is a painful process for the onsite folks. You still have to take early morning and late night calls, and now you have to make your specs much more detailed and so on. But on the other hand – the cost benefit is pretty high.Let me see if I can throw in some numbers and show an example (rates shown arbitarily…no indication of exact amounts or hours).

      Say an onsite independent takes 40 hours to do a certain piece of work, and charge $120 an hour.
      That is $4800. He does that (say 8 hours to design, 8 hours to develop, 16 hours to test, and 8 hours to document) and then walks off to another gig.

      Now in a global delivery model, the onsite guy spends 16 hours in design (since he needs a detaled spec), global delivery guy billed at say $30/hr, takes 24 hours to develop (thrice as long to develop) and 24 hours to test (thrice as long to test), and then another 8 hours of onsite testing and co-ordination. Total cost is $3360. savings – $1440 or 30%. You can change the numbers to suit individual cases, but generally on the cost side – it is hard to trump global delivery. Plus if you need this program to be maintained, there is a greater chance that the offshore SI is hanging around, since these models are established for longer terms. So there is lesser risk as well.

      Onsite roles are not going away completely – it is just that onsite folks have to get out of their comfort zone and do work that once seemed trivial to them. And it sucks that you probably wont get any more money than before to do this all.

      There are as many failed global delivery projects as there are succesful ones. However, when projects fail – it is easy to blame the guys offshore, than accepting part of the blame that the onsite guys didnt write specs that were more easily understood, or didnt follow the (often boring) processes that were set for the global delivery model.

      In a bad economy, global delivery is often criticized. On one hand, to support the economy in short term – you need more local jobs. On other hand, for long term financial gains of corporations- you need to cut costs and move work to wherever it is done for a competitive price. These are conflicting ideas and leads to a lot of contoversy. I am keen to see how it will play out.

      You are completely correct on language problems, and high stress levels. This is part of the growing pains – and is not unique to global delivery. When SAP comes out with a new module, how many notes do we have to research and implement before we make it work? Does that mean we stop using newer modules of SAP? No – there will always be early adopters, who will invest in higher cost upfront to reap a long term edge. Over time it will stabilize and more people will jump in to the boat – and I suspect that is the case with global delivery too.

      About the better functional consultants getting better rates – always has been true, agreed. In the future scenario, the second best consultant might lose out to a global resource unlike in the past where he could still get an onsite gig with lesser rates. That was the difference I was trying to point out.

      Finally, it is the client’s comfort feel and risk perception that rules the day. SIs and consultants can only offer advice – the guy who decides is still the client !