Thoughts on SAP Outsourcing, Part 1 – the evolution

As always, this is just my personal opinion and not that of my present or past employers. I need to do this in a few installments – starting with how outsourcing of SAP evolved in front of my eyes, and then some common problems, easy and difficult solutions and a reality check .

As many of you know, I grew up in India, finished my education there and came to US more than a decade ago. Pretty much from the time I stepped out of college, I have been an SAP consultant. I have worked in and managed both consulting engagements – or “development projects”, and outsourcing engagements – or “maintenance” projects. And I am fairly sure I have seen a big part of the evolution of SAP from R/3 till today. Similarly I have watched outsourcing of SAP services from close quarters for a good while. I have seen this from India and also from outside India (Europe and North America). While I don’t claim to be an expert, at least I am pretty familiar with the landscape. I just want to share a few observations on this topic – hoping someone will find value.

In the mid-late 90’s many Indian companies were already doing quite a bit of outsourcing work for US/European/Japanese companies. But for the most part – they were not in SAP. They did this in other technologies, and infrastructure services. Towards late-90s’s this got a big push with the Y2K challenge. Companies developed a factory model to tackle the Y2K factoring. And then the light bulb went on – why not do this with SAP work and build some serious scale?

Infrastructure was the big issue to begin with. I remember sitting in India copying ABAP code to text files and emailing to colleagues in US to test, since the dial up connection would die if I tried to compile or execute on a server in US. A phone call from India to US was about 100 rupees a minute and was not a cost effective mode to communicate. But since projects all had plenty of time built into it – and since offshore was cheaper – it was not a big deal at the time. Funny enough, looking back – all of it looks a lot worse than how people felt at the time 🙂

There was no real structure to the whole process in the beginning. We used to get emails with a rough idea of what needed to be developed (Hey you, check VA03 with Sales order number 1234, and build me a data load program..cheers, your best buddy in US) . We did what we could, and some one fixed it onsite. Essentially, we were just doing 50-75% of work, and quality was not always very good. Again, for the cost – this was more than acceptable as a productivity improvement. As I remember everything was at time and materials basis from a contracting perspective when we started.

This was improved pretty quickly, and a more structured process evolved with better written specs being sent from project site to offshore site. Also, since timezones, accents and all started to come in the way – we started having a role of “onsite-offshore co-ordinator” in most projects. It is a very stressful job, and they get beat up by all parties. I remember a colleague telling me over beer that “Man, i feel like everyone’s bitch” . But things started to scale big time.

And as time progressed, the notion that functional modules are too complex to outsource quickly disappeared. And from the initial days of “someone who needs to clarify specs to developers and do offshore PM work” , the role changed to “experts who have deep expertise in business, who can do part of blueprinting remotely”. Another big reason for the jump was that many Indian clients started implementing SAP and this helped increase experience and talent immensely. Another big improvement was that by early 2000s, many consultants from India had returned after projects in US and Europe. These folks added a lot of new skills and experience to the team. Conversely, their colleagues at client sites got a better appreciation for how their colleagues in offshore locations worked. So naturally, communication improved big time.

As the model became more mature, the outsourcing companies could do better estimations and repeat business predictably. Contracts started becoming more of a fixed price, and managed to SLAs, instead of hours. It is not that offshore part of the equation alone improved – the onsite teams by now figured out what can be outsourced, and how to communicate effectively. Of course clients always have wanted quality – so more strict processes came in, including CMM type formal ones. Many layers of QA were established so that final version seen by the customer was much better.

However as time progressed, training did not always keep up. So you will still see many programmers not familiar with OO ABAP, or WebDynpro or SOA. Same is true for functional side of the house too. As demand shot up – companies started hiring like crazy in India. And many SAP training centers opened – several of them really bad, and very expensive. These schools focus heavily on canned technical training. Once the big outsourcing firms hire them, they have to get trained a second time in consulting skills, software design etc., and often in the core technical skills too.

There were some (unintended) side effects too.

One side effect that happened was that due to the large demand, companies started promoting people faster. Folks with 2 years experience became leads and with 4 years some became project managers. Some did well and many did not. It went to a stage that if you hired a 4 year experienced programmer, that person rarely wanted to code any more. To some extent, I think this problem still stays that way . Of course there are many exceptions too.

When hiring happens in bulk, inevitably the quality suffers. I have seen this to also have a long term damage aspect. When a poor skilled person is hired, and then promoted because of the need to grow the business quickly – there is a big chance that since person will hire even more poorly skilled employees. I am not just talking about SAP skills – I mean the soft skills and leadership aspects too. Mediocrity breeds like rats at the scales hiring happens. Companies realized this at some point, and started course corrections – but it will take some time to weed out people who are not equipped to do this work.

Yet another side effect was that offshore talent started having two distinct flavors – one with a strong focus on projects, and another on production support. General impression is that the project side of the house is the lucky lot, and the other side usually feel they don’t get the same training and exposure. This is an awkward scenario – project developers are used to all kinds of innovations to get the project to go live with good quality. And production support gang is used to making sure SLAs are met for every problem that is thrown at them. There are mature processes that govern both sides, and it all works fine. But the moment you put a project guy on support, or a support lady on projects – you can generally expect a “fish out of water” feeling to prevail. It is a pretty sharp divide, and something that people not working offshore often realize or acknowledge.

So when a person who is really good at solving high priority bugs gets assigned to a project as a developer, the instinct usually is to find the solution that solves the problem in the least amount of time. And this is what a lot of times leads to the perception that these people are not good. They are actually quite good – their leaders are not smart enough to coach them in the right path. The exact opposite is true in reverse. A person used to project work will go to maintenance work, and will pull hjs hair out. However, the instinct is to rewrite everything when a bug is reported, rather than get it fixed within SLA time and get the business back up and running. It needs good management skills to coach and align these people to suit the current assignment – and it is an area where many managers fail miserably, usually because they don’t understand these nuances.

These days – it is not uncommon for projects and production support to work out of several different countries working around the timezones. Infrastructure is far better – high speed networks are the norm, cell phones are common, visualization tools and video conferencing help remote blueprinting etc. But as I talk to friends who started in SAP with me but chose to stay back in India, it appears that the processes we put in to counter the poor infrastructure etc are all pretty much untouched till today. As I will explain in a later post, this is not an unnecessary overhead as it first appears.

This is the relatively bright side of the story. But outsourcing generally has a bad ring to it if you ask around consultants and clients. Next time, I will try to explain my thoughts on how it “successfully” earned the bad reputation.


SAP Teched 2011,Bangalore – Big stage, Big expectations

SAP Teched Bangalore has already  kicked off with the innojam on mobility theme. I am not there in person, but several friends are, and I am getting near real time updates 🙂 . I was seriously thrilled to see that SAP expects more than 10000 people to show up for the event. I am guessing that one day soon, we will see SAPPHIRE in India too.


First off – SAP could not have chosen a better focus than mobility for this event. Brilliant !  Every time I go to India, I am amazed by the proliferation of mobile devices there. Almost every one I know there has 2 mobile phones – and most now have a smart phone. When I visited my parents last month, the vegetable vendor from whom they buy regularly showed me his new iPhone. Without a doubt – India  now has the largest pool of SAP developers. Some of the smartest SAP mentors live and work in India. And it has a growing economy. It is an ecosystem ripe for SAP to influence big time – and mobility is the path of least resistance.


I know HANA is where SAP has the most focus these days – but in my opinion, it will be a lost opportunity if SAP lets HANA overshadow mobility messaging at Bangalore. However, just talking about mobility alone is obviously not what SAP needs to do – SAP needs to show how this vast ecosystem can participate in getting this strategy from philosophical levels to execution levels.


India might be a great HANA market too with the boom in retail, banking etc – all high volume, real time data sensitive sectors. I expect to see Vishal’s key note showing how Indian businesses can make use of HANA . But what is also required is for SAP education to step up their game and get access for developers in India to get smart on HANA very quickly.


Today morning on twitter, I had a brief interchange with Vishal Sikka . I tried to get Vishal to consider delivering part of his keynote at least in Hindi. Vishal said he will consider it. And it was great to find out that his mom taught Hindi. Given that the intricacies of India’s future was discussed in Hindi before millions of people by the leaders of Independence movement 60 years ago, I am confident the intricate message of SAP’s future can be expressed in Hindi before ten thousand people with sufficient impact. Now of course I know regional languages trump Hindi in most parts of India. However, I feel that Vishal delivering a part of his keynote message in Hindi  – may be with English translations in video as Dennis Howlett suggested – will be pretty powerful, and well appreciated by the audience.


I feel terrible that I have never been to a Teched in India, and will make every effort to attend it next year.


Good luck, SAP – I wish you the best in getting India all excited about your solutions.

SAP HANA vs ORACLE Exalytics – My initial thoughts

I was in Dallas this week for some training, when ORACLE announced Exalytics. Here are my initial thoughts for whatever they are worth.

1.  In terms of vision – I think SAP scores.  SAP has clearly articulated how HANA will evolve, and they have stuck to their guns. ORCL roadmap for exalytics is not exactly clear, and since they also have exadata and others exa-systems probably coming up – they need to more clearly articulate near term and mid term roadmap. And while they do that, SAP can always tell the world that it is a validation of SAP’s strategy.  However, not all my buddies agree that SAP has the right to call in-memory as “their” strategy

2. Legacy : Both SAP and ORCL have old technologies to “draw inspiration” from . ORCL had timesten/Oracle RDMBS etc to learn from, and SAP had TREX/ P*time /MaxDb/IQ to learn from.  Despite jabs at each other that it is old technology for the other guy – neither side has a great story to nail the other in my opinion. If anything, Oracle has more DB experience than SAP – but whether the RDBMS experience is useful for in-mem computing remains to be seen.

3. The talk on collapsing layers etc – I already wrote my view on this last week So I am not going to rehash all of it.

4. Product introduction to market : SAP used SAPPHIRE and Teched to lay out their HANA story. OOW is a huge stage – and ORCL did well to use it to bring this out.Both companies used CEOs to do it, and I think SAP did an all around better job. From using social media to its advantage – I think SAP hands down beat ORCl to it.

5. Response to each other’s product :  Larry poked fun at Hasso when HANA came out. SAP returned in kind via tweets and Forbes advoice. Here – in my opinion, SAP did not do too well, especially in the Forbes advoice. In general, I think the usage of Forbes advoice does not do SAP any favors. Today morning I read a similar blog from Aiaz Kazi on SDN, which was much better.  The flurry of responses from SAP – tweets, advoice blogs, videos etc gave me an impression that Oracle touched a raw nerve.   ORCL barely mentioned SAP – they seemed to be targeting IBM and HP mostly, but SAP seemed to be the one who reacted the most. There was no need for such a hurried reaction – one statement from Vishal or Sanjay, and then a more thought out response from Bangalore or Madrid events would have been more effective in my opinion. But then, I am not a media or marketing expert .

6. Throwing hardware at the problem : if high performance is your big goal, then every layer should be owned by you. Otherwise, you cannot optimize equally for 5 different hardware offerings – even if all 5 are superior HW than Oracle’s boxes.  I buy into the argument that being open adds flexibility, but there is then the trade off for cost of integration and efficiency loss.  If cloud is where you want to take this to eventually – then it is all the more important that you own all layers – not just for technical reasons either.  So I won’t ding ORCL here – I think they are smart to integrate everything into a true appliance. SAP’s appliance concept is more loosely defined – software from SAP and HW from a partner.  Good thing is that I know customers on each side of the camp. So both models will sell – question is how many can you convert from the other side to yours.

7.  From a datamart perspective – I don’t see any big difference between Oracle and SAP. Either one can fit that.  So for current version of HANA, the only advantage for SAP is that they moved first. It won’t be difficult for ORCL to catchup and compete. But this is table stakes. Other than for branding and marketing reasons – I don’t think either company is betting the farm on data mart scenarios bringing in the next billion dollars.

8. Oracle has a cash cow DB market  they need to protect. HANA is going to threaten with taking away a small install base – the BW customers running ORCL RDBMS. And then SAP will go after a bigger install base – Business suite customers on ORCL. The current announcement does not protect ORCL in these areas.  Unless some release of ORCL in future can beat HANA in price and performance as a DB for BW and Business Suite – SAP can pretty much win that battle.  If SAP is smart about of execution, they can utilize a first mover advantage to get HANA under BW and Business suite faster, and not give enough time to ORCL.  But then – execution is not an easy game to excel.

9. Where are the killer apps ? I ranted last week on this topic from another angle . At least for now, SAP is ahead of this game. They have announced a bunch of apps, and will hopefully step up on execution and a few of them will get “killer” status.  ORCL is late to this party, and has ways to go to catchup.

I am continuing conversations with people who I respect in this space, and as i find more – I will post updates.

Enterprise Apps – Change the rules, or they will change you

Everyone and his neighbor is convinced – including me – that future of enterprise software is in apps. However that does not mean the world will change tomorrow to a happy place. Here are half a dozen things that rush to my mind, in no particular order. It is a Sunday morning, and I only had one coffee so far and I have the flu. So take this with a pound of salt.


1. Apps will have really short lifecycles as we go forward. 


So we need a foundational architecture that allows people to create apps with bare minimum effort and cost. “Create” does not mean just dev and test – the whole app life cycle management including security, device management etc needs an industrial strength foundation that is easy to use and is affordable.


In short-medium term – we might have 1 to 2 year useful life. But as time progresses, this might become use and throw. And that might mean users can create their own apps, instead of a developer creating for them.


2. Backward compatibility is a must in enterprise world


Consumer side has one big advantage. Facebook can add and remove as they please – ok, not exactly, but easier than say SAP or ORCL.  Enterprise side does not have that luxury. So again, a paradigm needs to evolve that balances this reality against the ease of upgrades etc.


3. No one vendor can develop enough apps


So a huge ecosystem is needed. This means, on top of an architecture that makes it easy for developers – we also need a licensing paradigm that goes with it. This is not easy for companies new to this game. My favorite poet in Malayalam, Kumaran Ashan famously sang “change the rules, or they will change you” . He was referring to the social injustices prevalent at the time though.


4. HTML5 might not be the answer to world hunger


Apps are not all about mobility probably, but mobility is probably the leading horse in this race. This whole HTML5 vs native debate will probably end in hybrid scenarios, more than any one side winning by a margin.  Device makers don’t have a lot to gain from HTML5, and consequently native functionality will keep improving at a steady pace. And of course apps will follow the trend – since it is more or less a binary world in mobility. Either app gets used or it won’t – not a lot of middle ground.


5. Horses for Courses – Not all parts of Enterprise are app friendly, and not all users like apps


Whatever is the future architecture and licensing model – we should not fool ourselves in thinking that everything needs to be an app. Some processes are best left alone – along the lines of “everything must be expressed in as simple a manner as possible, but no simpler”, and not all users need or like apps.  Users should be allowed to choose whatever makes them more productive.


6  Why buy/build when you can beg/borrow/steal ?


A lot of functionality that enterprises need are also needed for you and me as consumers – things like file sharing, collaboration and so on. What enterprise needs is added layers of security, scale etc. It might be easier to let the consumer side take a lead on these, rather than re-invent and duplicate all of this. Who knows, one day consumer side can get something back in return too.  Or as standards evolve – there might be a possibility to put a layer around consumer apps that make it enterprise grade.