Thoughts on SAP Outsourcing, Part 2 – the Devil’s Polygon


Now that I have walked down the memory lane, this time around let me share some thoughts on what earned outsourcing a bit of bad reputation. Again, this is all just my personal view and not that of past or present employers. Outsourcing is not a perfect world at all – and the ill will it generates can be attributed to a devil’s polygon ( taking a  clue from my friend Mike Krigsman  who is famous for Devil’s triangle). Many players are involved and they all have different POVs.  Since I have not worked from the customer side – I don’t claim to be totally objective in my thoughts. But for what it is worth, here you go.

1. Pushing people through the career hierarchy before they had a chance to make mistakes and learn at the lower rungs is a common scenario in this high demand market. If a developer makes a mistake, it can usually be corrected without too much trouble. And then the developer learns what not to do, how to react when things go wrong, how to explain to client and management etc while limiting the risk. If this developer became a team lead or a PM too quickly, and goes through the learning process with errors at that level – chances are it won’t end well. Bad managers are the biggest reason in my opinion on why outsourcing earned criticism.

2. Lack of understanding from customers on what they bought, also ranks up there on top. Before outsourcing, a customer would have had an inhouse team doing everything. And since the IT team sits next door and goes to lunch a beers with you, there is generally a good camaraderie. If you make a call to your friend and ask her to add a field to a report, she will probably oblige occasionally without a formal process. She might also offer some support over phone if it is not in office hours for sake of friendship. When outsourcing happens – you are already stressed out that your friend is not in that job anymore, and you need to follow a rigid process to get things done. No one told you that for cost reasons, your management only bought 8 hours of a day of support. So when that last minute change is needed on Friday at 4 PM, chances are that it won’t get done before you go home.

The funny part is that the same people as consumers are totally fine if this happens to them with say a cell phone company. You raise a ticket, wait for it to be fixed and you cannot call for updates every minute. For days at length, you will be forced to see “in progress” as status on their website. Yet we get stressed out if the same thing happens when our own employers outsourced to another provider.

My biggest gripe with how companies buy outsourcing services is the lack of due diligence on customer’s part on what they need to buy to do business as usual. If the service provider tries to educate the customer – more often than not, it will be percieved as “hard selling”.  I am not letting the outsourcing companies off the hook either – they need to better explain what is in the basket and what is not.

3. Economic differences are a big contributor  too. When USA and Europe are going through a bad economy, and we lose jobs to Asian countries – we of course will feel bad. What we occasionally forget is that it is a direct result of how capitalism encourages competition. If local workforce can come up with a model where they can be competitive, there is a fair chance that a lot of these jobs will stay here. We cannot take a stance that “I will continue to do what I have done all my life, and I expect to get same or better pay, and I will refuse to believe my skills have become commoditized.”. Apples to Apples – it will be difficult for a person in US to compete on a wage basis to a person in India or China. However, if the game is changed – say the person in US can form a team that supports multiple clients, and provide better service – there is no reason why this should not work out well.

4. Social differences are better now from the time I started in SAP area. I have sat in many meetings in my first few years in America and Europe and listened first hand to “oh this is not complex, we can probably throw it to the Indians” and “they are just ABAPers” and “do you go to office in India on horseback?” and many others that were so rude, that I cannot bring myself to write it here. It took a few years for me and many other colleagues from India to feel that we are part of the team too. This has vastly improved with time. When you feel crappy on the social side, it is pretty hard to concentrate on work fully. Although I felt terrible at the time , I also realized later that my American and European colleagues and clients were not trying to be intentionally rude. They had never been to India before, and they found it incredibly hard to understand my thick accent and long name. They also did not know why their employers got Indians to join the team in the first place. A lot of this frustration on both sides could have been eliminated or at least reduced if outsourcing companies and clients who bought their services communicated the plan clearly and did so right upfront, and not after every one got wound up.

I will also tell you a rather funny story. A good friend of mine – also an ABAPer from India – started in US working for a client of mine. I was working in a US based big SI, and he for an Indian firm. Client used to treat consultants from my employer kind of on par with their own staff, and we would get invited to nice dinners and ball games and so on. My friend on the other hand never got this opportunity, and did not know this was going on. A year later, he joined my employer and started seeing the difference in how he was treated by the client. And when we went live, the development lead from the client congratulated my friend saying “this guy from so and so company wrote a brilliant application, and our users love it. It totally validated my reason of hiring this SI to help us be successful”. We all cheered big time, but the funny part is that this terrific app was written by my friend way before he joined my employer. He never told the client manager, but till date – every time I talk to him, we joke about this.

5. In a dog-eat-dog world, people snipe quickly to protect turf. Having worked for very small and extremely big employers, I can say with some confidence that neither side has earned the right of  “holier than thou” . I have been sent in to rescue projects screwed up by cowboy developers from small SIs or independents . I have also worked in very small shops where we were appalled by the work done by the SI who put in the SAP solution. In general – big SIs get more of a bad reputation in these cases because they have a recognized brand. People who are independent now or work for small shops – most of them had a history of working at a larger shop before where they gained experience and became the big expert. So it is not as if when they moved out, the past shop became pretty bad. People and companies protect turf – and customers know that only too well by now.

6. People forget that SAP product was not this mature in the mid 90’s. A lot of work that looks terrible when we look back were clever work arounds that were done to make SAP work on those releases. When such a system gets outsourced for support, and complex problems arise – they might not have elegant solutions. Short of reimplementing SAP, usually the only way is to apply even more band aids. But when this is looked up on from outside, it looks terrible and the fault is attributed immediately to poor skills of the people supporting it.

7. The factory model used by many outsourcing companies get a lot of flak – usually from people who do not have the ability or scale to do that. Factory model works – if it did not, many big businesses would have closed shop by now. Obviously, this model needs a revamp since the model has not kept up with advances in technology, especially on infrastructure side. The reason it still survives is because – despite all that is bad with it, it gets the job done cheaper in most cases (when it does not for a few cases, it gets more bad press than the many times it works). Factory model works only if it is implemented properly, with the associated change management. In several cases, the change management gets kicked to the curbside, and then it goes downhill pretty quickly. If all parties know how the model is supposed to work, and commit to it – it works like a charm. When you skimp on some parts, it fails. Outsourcing companies and clients need to do a better job in change management, and educating the clients and their own staff onsite on what it takes to get it done successfully.

8. Talent retention is an issue for customers as well as outsourcing companies. However, outsourcing companies have scale in their favor. This is their bread and butter business and they have a better ability of sourcing and retaining talent. However, there are things that are not in anyone’s control – like the current restrictions on work visas in US. A lot of plans that were put in place long term for outsourcing projects, now need to be revisited, and I expect some outsourcing horror stories to surface. From the perspective of local work force, this is great – because it provides a window of opportunity to get good jobs. The current demand and supply situation is kind of weird – there are lot of unfilled seats in technology jobs, and there aren’t enough skilled people to take it. This skill mismatch is a deeper problem that needs a re-engineering of fundamental aspects like education reform etc. It will take time to fix.

9. As an inhouse expert in SAP – it is pretty common that employees gain exposure to multiple skills. I have many friends who can do ABAP and SD configuration and BW. This is not a model that outsourcing companies have actively worked on in my experience. In traditional outsourcing models, due to price, nature of work etc – ABAPers generally do only ABAP, and BW folks only do BW and so on.  A small percentage will get cross trained , but they are the exception. However, this part does not get recognized when these people are pulled into outsourcing projects. I have heard hundreds of requests from customers on “why can’t you find me an SD consultant who can also do BW reporting? Joe , who used to work here, could do all of that plus some ABAP” .  It is not easy to find a like-for-like replacement for Joe at the price a customer is willing to pay for that service.

10. The most common complaint you would hear probably is “these people are still stuck in ancient ABAP coding ways. They don’t do OO ABAP, they don’t know what web services are…are they living in a cave?”.  Most outsourcing shops – atleast the good ones – have good training programs that train people in latest and greatest technologies. However, not everyone is sent for that training. It is expensive to train people, and companies won’t invest in training tens of thousands of people unless they see a demand for the specific skill, and a premium for it. SAP is generally very backward compatible  – so several customers have decided to just move on with that is already built, and just “keep the lights on”.  They will try new things for new projects – but are generally hesitant to fix existing ones. As a result, the people supporting these projects have to remain in the old way of doing things. We should also understand that in most cases – time to develop a solution trumps everything else.  So if there is a bug in a program, the biggest requirement is to fix it and get it back to working state. In the hurry to fix it, more band aids get applied.  Unless a customer is willing to spend money on cleaning up existing mess, this problem will only continue to get worse.  In current economic scenario – I doubt how many will open their wallets to do that in near future.

It is hard to keep this series in a structured format with so many things rushing to my mind. But I will try my best to get it more organized as I move forward. I am typing this from the plane on my way to work, and lack of good coffee has to take some blame for my random thoughts too 🙂

SAPPHIRENOW 2011 Madrid – A few HANA questions if I may?


I am going to Madrid next week to attend SAPPHIRENOW. SAP is paying for my flight, hotel and admission. As I am preparing for the trip, I thought I will share the questions I am looking to get answers. My understanding at the moment is that HANA will bring in 100M Euros this year. It is quite impressive for a 1.0 product, and SAP deserves kudos for getting customers to buy HANA in a bad economy.

 

So, here are my questions.  I am hoping to get them all answered next week in person, or if I am lucky someone can enlighten me in blog comments here itself.

 

Customer Perspective


1. How many customers are using HANA in production ? So far we know of 2 that were announced at Teched. Will we see a few tens more announced in Madrid?

2. How many customers that did POCs with HANA – the ones shown on stage at SAPPHIRE Orlando, took their POCs to production and are running their business on it?

3. For those that took it to production – how are they dealing with High availability/ Fail over / Disaster Recovery ? What would be really nice is if SAP lets us talk to these pioneering customers directly at Madrid.

4. I saw a tweet from SAP internal IT manager http://twitter.com/#!/MatthiasWild/status/130031370457198592 that SAP internally went live with BW on HANA, but it is just a parallel system to a disk based BW system. This is because of HA/DR . How many customers will buy HANA for BW to run it in parallel? Jeff Word announced two live HANA on BW customers will be present at Madrid. Are they solely on HANA, or are they using another disk based system as primary BW  instance?

 

Applications Perspective


1. Will SAP unveil the killer HANA app in Madrid that makes HANA more compelling than a fast database?

2. How many partner apps have been created during the year on HANA?

3. With HANA supporting R, will statistical processing logic need to be written from scratch in R, or will business functions be available that hides R from developers?

4. Who owns the IP rights if a partner develops a HANA app?

 

Partner Perspective


1. What is SAP’s vision for SI’s in future of HANA ?

2. Is there a market for smaller SI’s in HANA for SMB?

3. Of all the projects in HANA that are going on, what percentage is directly driven by SAP ?

4. Are there benchmarks and testcases for partners to use when implementing HANA solutions? It would also be good to see comparisons between IQ and HANA for same query on a given dataset.

5. Now that SAP has sold a lot of HANA, can we have better sizing tools? We all lived through the pain of incorrect sizing on BW and then BWA. I hope to not repeat this with HANA.

6. I have heard bits and pieces on HANA pricing on BW. Will this be clearly explained at SAPPHIRE Madrid ?

 

Cloud Perspective


1. What is the HANA cloud? does such a thing actually exist today?

2. Is HANA multi-tenant? When I read this http://searchsap.techtarget.com/news/2240106165/McDermott-addresses-questions-over-SAP-BusinessObjects-40-HANA it looks like there is a HANA cloud already that works. Is this true?

3. Does ByD already work on HANA? If not – why and when will it?

4. What is SAP’s solution for ETL to cloud for HANA to get huge volumes of data in real time?

 

Future Perspective

 

1. Where is the money going to come from next year from HANA ?  BW with HANA is a very good next step. BW has 16000 installbase or so. If SAP gets 25% of that to buy HANA at a million dollars each, they will make a significant jump in the size of the company. But how many will buy HANA as DB? BW customers are either really big (maybe top 100 customers) and the rest are usually much smaller.

For the big customers – they will have long term existing licenses from ORCL etc for enterprise which might not be easy to get out of in near future. Also, these tend to have business critical use cases- like for financial close etc. How many of these will jump into HANA as DB when it is so early in maturity curve?  And for really big systems – will they be successful using commercial hardware? Or will they need special hardware built for them? I have not seen yet a comprehensive answer for scale out from SAP.

For smaller customers – the majority – how much of a pain is BW really? Most customers by now would have solved most of their painpoints on performance etc. And even if they have not, will HANA licenses be more cost effective than buying more fusion io cards and RAM / SSD ?

2. When will ECC and rest of business suite run on HANA? And when it happens – will SAP still give customers the choice to have ORCL etc ad DB? As database vendors bring more and more sophistication into their products over time, will there still be enough of a value proposition to have HANA as a DB?

3. What percentage of ECC transactions will benefit directly  from HANA  in terms of real value? Will there be an option to point just these parts of the solution to HANA and rest to disk based DB to optimize cost?

4. Even within a high value analytics use case, not all data needs to be analyzed all the time. So if I have 10 years of data, and I generally go back in time only for 3 years in most queries – will HANA let me store my old data in disk, say in IQ?

 

There you are – and if you have additional questions that you want me to ask SAP while I am in Madrdi, please leave them in  a comment here.

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.