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.
And Vijay Says... 