SAP ROI — Enterprise Architecture & Business Solutions

SAP Offshore Development

There is a time and a place for everything–, even SAP project offshore activities.  Unfortunately in the quest to save money the wrong approach can sound good on paper but cost you far more than the sales pitches would lead you to believe.  The SAP offshore sales pitch uses enticing rates like getting an offshore developer for about 15 to 20% the rate of an onshore resource (about 1 / 5^th to 1 / 7^th the price).  The initial reaction to all of the sales pitches is “wow, that will save us a bundle!”  The truth is sometimes it does and sometimes it does not.  And in many cases it can even cost you far more in hidden costs than local (higher priced) developers.

This is the first in a 3 part series on SAP offshore projects:

• Part 1 – SAP Offshore Project Development Experience (this post)
• Part 2 – Hidden SAP Offshore Development Costs
• Part 3 – Where Does SAP Offshore Development Make Sense?

I’ve worked on 3 projects where off-shore resources were used for the initial project and 2 others where they were used for upgrade.  This is the “inside scoop” from my experience.

The Real Reason Offshore Development Seems So Cheap

Let’s set the record straight on one thing immediately, there is a REASON those rates are that cheap.  In the global SAP world it has less to do with the wages of the host country than you might realize.  In the SAP space there is still strong demand for strong SAP skills globally so market forces plainly dictate that real experience will pay market rate no matter what country it is.  Work Visa requirements for many countries with high SAP skill demand will allow the importing of actual skills –, heck, they let massive numbers of total fakes and frauds in the United States so real experience (rather than faked) makes it easy to move out of these host countries for far higher wages.

When Off-shoring Might Cost You More Than Local Resources

When your SAP project depends on large amounts of custom development work you may be in for reverse “sticker shock” at the actual hidden costs.  And by reverse “sticker shock” I mean it is like getting a car for 25% of what you thought you would have to pay BUT you find out the tires, battery, seats, steering wheel, and all of the key components of the car are “required” add-ons that you have to pay for separately.  But they only show you the nice, finished, new car with all of the “extras.”  The actual cost for a HUGE portion of the offshore development is hidden and that rate you were quoted is a joke! 

Your “offshore” resources have very little if any actual SAP development experience no matter what kind of a sales pitch you are given.  What you are ”hiring out” is some smart college kid who is learning on your dime but *maybe* under the supervision of an experienced developer.  Yes, the rates are lower but in today’s economic climate you could probably find some aggressive local college kids who would do as good or better, for the same wage, and without any language barriers.  Maybe you should consider that and bring in one of those expensive local resources to train, shepherd, supervise, and teach them.  At least then you have the skills in house.

Some of the huge costs that are buried for a new project are in the whole development process itself.  SAP functional consultants, who are typically higher priced than technical or development resources, end up taking 2 -3 times the effort spelling out requirement details.  That extra effort translates into hidden cost that you do not see but it creates a great target for the offshore resources to “blame” for why they are struggling–, “I’m waiting on the functional consultant…” or “the spec had to be re-written…” or “it didn’t have enough detail…”  A truly experienced local resource already knows and understands the table structures, data sources, actual requirements, and has probably done similar SAP development work or reporting.  With a higher level spec in plain English, rather than detailed design with pseudo-code required for offshore work, local SAP resources can churn out a polished first pass development effort which needs only minor tweaks, takes less time to test and adjust, and has better performance.

The actual cost for a HUGE portion of the offshore development is hidden and that rate you were quoted is a joke! 

There really are situations where Offshore development is ideal for your SAP project, just don’t be surprised if the overall project “savings” you expect don’t materialize on a new project or one with complex development requirements.

How Can You Tell If You Are Being Bitten By Huge Hidden Offshore SAP Costs?

The one simple metric that will clearly illustrate if you are a victim of hidden offshore development costs is the total CALENDAR timeline for all development work.  In other words, after you get past the excuses, the finger pointing, the supposedly finished items that are always being reworked, etc., the calendar timeline tells all. 

No matter how many times the offshore development tries to suggest they are having problems getting “complete” functional specs, or how often they say they are done but have defect after defect to resolve, or whatever the excuse is, the simple calendar test will tell you the TRUE project impact.  If it takes 90 calendar days to complete development to the point that it can be used (defects corrected, tested, and ready for production) then it doesn’t matter if they estimate and then claim completion at 3 weeks.  The other 9 weeks to actual completion is project time that is taken from SAP functional resources, reworked development, business resources, etc.  So there is a huge hidden cost no matter what claims sales people may offer.

Related Posts:

• Where Does SAP Offshore Development Make Sense?
• Hidden SAP Offshore Development Costs
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Industry Specific SAP Consulting vs Deep SAP Application Experience
• Using SAP to Improve Revenue and Profitability

3.      ERP or SAP Process issues 

Let me start with a caveat to this section.  No matter how good, thorough, experienced, or conscientious a consultant or a core team member is, there will always end up being a few process gaps, and an occasional completely missing process discovered at go-live.  Now that the caveat is out of the way, there are many reasons for the process problems: inexperienced consultants, company employees who miss some of the process exceptions, inadequate training, insufficient integration testing, lack of user acceptance testing, and other reasons. 

The bulk of the items causing process problems generally fit into three core areas, 1) design or blueprinting, 2) change management, and 3) testing. 

SAP / ERP Design and Blueprinting 

Your business probably developed numerous processes and exceptions over many, many years.  Some of those processes were also developed as the need arose, and in an ad hoc manner and may have many inherent inefficiencies.  SAP projects are generally tasked with replacing all of those years of collective knowledge and processes, as well as any “broken” processes in six months to a year, and on very large projects in maybe a couple years.  That is no small task and to be successful it truly takes an experienced consultant.  As I’ve previously written about, this is one of those areas that all of the fakes end up costing your SAP project and your company big money.  And I mean big money over and above what you pay them.
 
A good blueprint should translate your scope into all of the key business processes that your company does, and then the key process components needed to support those processes.  I generally prefer a blueprint that has inputs (or some type of process trigger), the process itself, and then the outputs.  It should also contain the key master data requirements, any necessary FRICE (Forms, Reports, Interfaces, Conversions, and Enhancements) development objects, and the key business areas affected.  If there is sufficient time in the Blueprint phase, the Blueprint itself should also begin to capture some of the key change management issues.

Poor blueprints (missing processes, too generic, too high level, etc.) cause serious project delays and flared tensions by constantly dragging your project back into “Design” mode when you should be in full project execution.  It takes up the time and effort of other integrated teams, and generally causes a “drag” on the overall project.  Obviously this burns up budgets too.  Worse still, a poorly designed Blueprint is often blamed on the company, the department, or the key resource on the project who is responsible for that area.  Unfortunately those “smokescreens” are often used by consultants who are not that skilled at extracting the necessary information needed for a good blueprint.  It’s always easy to “blame” the client through the backdoor by putting the responsibility on a core team member, or some other portion of the company / client team.
 
If there is a genuine issue with a team member, an experienced consultant should raise this issue during the process when it is encountered.  Frankly, if it suddenly comes up AFTER the blueprint is due, it should be seen as nothing but an excuse by the consultant.

ERP Project Testing 

Another area to begin addressing processes is during testing.  Any integrated application like SAP should include at least 4 primary types of testing.  No matter what name is used, they are generally individual transaction tests (sometimes called “unit tests”), transaction strings or processes within the same module like Sales and Distribution (“module tests”) and then full-blown cross module tests that test entire process chains from start to finish (true “integration tests”), and then finally tests that involve the wider user community often called “user acceptance tests” or “day in the life” scripts, etc.
 
During testing, while it is important to follow the scripts to be sure that all of the proper “boxes” are checked off, it is equally important to test more.  “Integration tests” and “user acceptance tests” serve as the last opportunity to find and address process gaps.  Sadly some consultants (and some consulting firms) see this as an opportunity to absolve themselves of responsibility for potential problems or shortcomings.  As a result, they will often strictly enforce that the script must be followed to the letter and no deviation is allowed and no exception processing is allowed.  There is a legitimate need to control the process to ensure that the work is done and that the known processes work sufficiently as designed, however there should also be some mechanism to address gaps or exceptions.  One simple method to accommodate this is to create a space on the signoff sheet that directly solicits comments about any process gaps and any exception processing that might be needed.  Final signoff of the testing should not be signed off until this commentary is converted into additional testing scripts or some manual process defined to address the processes.

For final integration testing you may wish to pick random documents from your current business operations to run those through the system with the converted data.  This will give you the best test to ensure things are working correctly.  For example, you may wish to choose 10 or more each of the sales orders, purchase orders, production orders, reports, etc.  The key is to use something that is meaningful and can be verified back against your current system.  

ERP Project Change Management 

Unless you completely re-design and re-write SAP to do all of your processes exactly the way they were done before, there will be change management issues to deal with.  And unless you also re-write the user interface, there will still be training and user acceptance to accommodate.  If you’re going to re-write everything, why bother with a packaged system application at all?  On the other hand, if you are putting in a package application such as SAP, Oracle Apps, or others, there are change management issues to deal with.
 
Change management generally encompasses a few key areas:  Training, communication, organizational change, process / job changes, and post production support.  Some change management is necessary on every project and if your company handles change reasonably well it may not be a struggle.  However, if your company has many employees who have done the same job for a long time, without much change taking place within the organization it will take a tremendous amount of “hand holding” to get them through even small adjustments. 
 
You will need to assess your own organization and its ability to absorb change for whether change management resources should be budgeted.  From a project perspective however, one of the key things to be wary of are consultants who want to add new functionality without understanding the impact on the organization. 
 
Business Change Management analysis case in point:  I was at a client where SAP’s Handling Unit Management functionality was the best fit I had ever seen.  They had high dollar custom made steel transportation racks that needed to be inventoried and returned, the packing was consistent and uniform, their production volume was not intense as a sheer number, and they already had wireless bar codes with some warehouse automation.  From a functionality standpoint it was almost a “no brainer” and a great ROI on the automated tracking, inventory, and return of the units.  However, a more careful look at the organization showed a very different picture.  The staff responsible for maintaining the data and processing the transactions had not been reliable with data maintenance or with processing in the past.  Also, because of the organization there was virtually no chance that would change in the future.  

A less experienced consultant with limited project or change management experience would have seen this as a great opportunity to throw some “gee whiz wow” new functionality at a company.  They keep billing for the new work (a scope change), they would be needed almost indefinitely for production support, and they’ve got a great candidate to blame for why you have to keep paying them.  Sadly I’ve seen this scenario played out over and over again.  On a recent project I saw this with the implementation of SAP’s Customer Service and Solution Database functionality.  The company had an “ugly” but mature and working solution, they were downsizing the customer service area, the SD scope for the project was already pretty significant, sales were beginning to slow, portions of the business were being spun off, and employee morale was already low.  The consultant convinced them to “replace” their solution database and customer service functions from a CRM application that they did not even retire.  So there weren’t even any software license savings.  The consultant got to stay on, support an unnecessary process (the legacy app was not going away and worked fine), and was needed for post production support.  

 The process related issues will quickly separate experience from inexperience.  There are lots of good consultants out there, and then there are lots of less than satisfactory fakes in the market as well.  Unfortunately it is it the “good” consultants who are often penalized for smooth and successful go-lives by early roll offs.  Meanwhile fakes and less skilled consultants are rewarded by extensions to support poorly designed processes and inadequately prepared user communities at go-live.  The old adage rings true here that “you get what you pay for” as long as you have a way to separate the genuine articles from the fakes.  In the end, there are many hidden ways you end up paying as much or more for inexperienced consultants, not the least of which are the many hidden ways their SAP implementation approach impacts your business.  A truly seasoned consultant may cost a little more up front, but at go-live with the quality of delivery and the overall satisfaction of the solution it can pay dividends for many years.  

 In essence, the need for careful process understanding can not be underestimated.  The amount of change your company can absorb, the impact of processes being brought into a package application like SAP, and the cost to your implementation budget should all be considerations. 

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
http://www.r3now.com/planning-for-a-smooth-go-live-part-1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
http://www.r3now.com/planning-for-a-smooth-go-live-part-3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
http://www.r3now.com/planning-for-a-smooth-go-live-part-4
(custom development, costs and consequences of inexperienced developers)

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• The Real Reason Executive Participation Creates IT Project Success
• SAP as a Change Enabler