INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Where Does SAP Offshore Development Make Sense?

October 10th, 2011 by
SAP Return on Investment or ROI

SAP Offshore Development Cost

If you are capable of providing detailed design specs where there is almost no deviation or thought required this is a great option.  The instant your SAP design requires a measure of experience and insight to make judgment calls, or to look for data or processing that is not explicitly spelled out in detail, you are headed for huge hidden costs. 

The level of detailed spec design work by SAP functional consultants merely shifts the development time and costs to the higher priced resources where it is “hidden” from TCO and sales quotes.  If you are capable or writing “functional” specs that are really more like technical specs with specific table and fields spelled out in detail, program pseudo-logic defined, every possible alternative anticipated, and no detail left out then SAP offshore development works well.  If you are not prepared for that level of detail and “perfect specs” then you are likely headed for a much larger invoice in change order costs and hidden functional time than you ever anticipated.

Offshore resources are often smart, industrious, and hardworking but the ugly reality no one talks about are the real rates because these resources do NOT have any significant amount of SAP experience.

This is the final post in this series.

A quick “test” for the SAP outsourcing or SAP offshore fit is the nature of the work.  “Commodity” services are a perfect fit for SAP outsourcing or SAP offshore work. 

If the effort involves any type of innovation, business transformation or needs any level of change management then SAP outsourcing or SAP offshore development may be dangerous and it WILL cost you far more than you are led to believe.

SAP Upgrades Might Support SAP Offshore Development

One area I have seen where SAP offshore development work makes sense is with upgrade projects.  Much of the development work there is re-working existing objects where the requirements from previous projects have been well tested and adjusted.  Or, if there are enhancements the gaps are well-known and understood so that the detailed SAP development requirements can be easily defined.  From this standpoint SAP offshore review and adjustment of existing code makes sense.  There is little in the way of experience needed to use the syntax checker and to do the occasional program adjustment.  And other than poor coding which causes performance problems the risk is lower.

SAP Production Support Might Work With SAP Offshore Development

In a fairly stable production environment, where there are not a lot of enhancement or new functionality requests SAP offshore support might work well.  The “fix” requirements are very specific and limited so that these types of small adjustments or corrections work well in an offshore environment.  Even for some of the smaller and less complicated enhancements or improvements SAP offshore support might work well.  However, for more extensive troubleshooting, or very complex requirements, you are likely better with some sort of local or onsite support. 

For a more details see Outsourcing Your SAP Application Support.  This provides some insight and a little framework for understanding the SAP outsourcing or SAP offshore fit.

Conclusion on SAP Offshore Development

Regardless of the hype and sales pitches SAP Off Shore development has far more Total Cost of Ownership than anyone has been led to believe.  There is a place for it but that is rarely in a new project or an extensive rework of complex processing requirements.  While you may not see the costs, the offshore project model will cost you unless you are fully aware of the requirements and hidden costs that are never defined in any of the sales pitches or materials.  Of course they will never tell you SAP offshore development might cost you far more than higher priced local resources in many situations.  If they had that level of integrity you would never engage with them for those services. 

For more information and insight on this topic see IT Outsourcing, Off Shore Support, Cost Cutting and IT Department Changes.  That post provides some additional insight on helping to understand where SAP internal resources should focus as well as where offshore support might make sense.

Related Posts:

Hidden SAP Offshore Development Costs

October 3rd, 2011 by
SAP Offshore Development

SAP Offshore Development

My experience with SAP offshore development is that no matter how detailed your spec is their lack of experience with standard SAP transactions and functionality means they will never properly test their own creations.  Their results are more than just full of bugs, often times they crash when attempting to do even basic testing.  Repeat testing by expensive functional resources happens so frequently and consumes so much hidden time from parallel project activities that entire project timelines are frequently affected. 

Functional resources have to babysit and handhold these SAP offshore resources through the whole process because of the language barriers and lack of experience.  More functional time, more project management time, more unplanned distractions from functional Realization activities and your entire project timeline can be wiped out.  If that happens you have to pay even more for a missed development date because you have to move your go-live date.  And that cost is completely hidden from you by some of the shell games they play on their supposed efforts.  All of that functional time and the risks to the project timeline point to some of the real hidden costs of SAP offshore development. Develop, test, bugs, fix, develop, test, bugs, fix, rinse and repeat at least a dozen times.

A common SAP offshore practice is to keep throwing “crap” at you saying it is “done.”  With all of the crashes and bugs that are so common with offshore development, and especially all of the program crashes, how much testing could they have done?  The bigger question is how much is this really costing you and how do you find the hidden costs?

SAP Project Timeline and Budget Due Diligence

Because of the nature and pace of SAP project work whenever the issue of blown budgets and blown timelines come up most companies rarely perform root cause analysis or due diligence.  Instead the accusations and recriminations fly in the heat of the moment.  Meanwhile the offshore developers keep saying “we finished x development on y date… the functional teams didn’t support us…” or “the specs were bad and we had to make 20 changes…”  You name it, the extent of the excuses are never ending.

Evaluating Hidden SAP Offshore Development Costs

Because of how SAP “functional” consultant time (needed to support the offshore development) is hidden from you it never shows up anywhere in the rates you were quoted.  You really have no idea about the real Total Cost of Ownership (TCO) for that offshore SAP development.  The offshore company constantly claims the “specs were not detailed enough” or every microscopic change and adjustment becomes a “change order.”  I’ve even seen this where standard SAP functionality was completely broken by the development and the developers insisted because there was nothing spelled out in the design spec about allowing standard functionality to continue working a change order would have to be separately paid for!

On new SAP implementations the functional time premium can easily cost you 50% to 75% (and in some cases even exceed 100%) of the total development hours.  Think about that for your next quote as you try to put the pen (or your spreadsheet) to the numbers.  Have you really factored in the amount of high priced functional resource time needed to support those “inexpensive” offshore developers?  Between writing “super enhanced” specification documents, repeated endless functional testing of buggy SAP development, “training” of inexperienced developers, language barriers, “babysitting” the actual development, and the lost opportunity to focus on other functional Realization activities can kill any supposed savings.  It’s all a shell game.  You pay just about the same amount (and on many occasions even more) with far more headaches and lower likelihood of making your go-live date.

Even after all of this, there is still one more hidden cost that is not realized immediately at go-live–, the cost of poor coding.  You may have significant performance problems, constant bug fixes, and a whole host of other maintenance activities that you never planned or budgeted for.  Now this is true of any development but because of the language translation issues and the modest (at best) quality of coding you are likely to have incrementally more production maintenance costs with the offshore development.

Some Considerations to Help Reduce The SAP Offshore Development Shell Game

First and foremost NEVER accept the offshore development group’s code review options.  One way you can help to combat so much of this is to budget for at least one local developer, even at premium rates, to serve as a quality checker.  They do not have to review all of the code from all of the developers but they should look for the “tells” of experience over inexperience.  And your SAP statement of work (or SOW) as well as your contract with the offshore developers should include various protections about the quality and expectations of the development work and functional consultant time and contributions.  That SAP SOW should also include some definition around what a “change” is and what a “defect” is.  Without that everything will be considered a “change request” and destroy any supposed savings.

Next week the wrap-up part 3 of this series:  Where Does SAP Offshore Development Make Sense?  There are some situations where it is a great cost saving alternative.

Related Posts:

SAP ERP Project Failures Lessons Learned and Mini Case Studies 2

December 20th, 2010 by
SAP ERP Project Failures

SAP ERP Project Failures

The following SAP ERP project failures cover the importance of testing, change management, training, senior management involvement, scope management, and quality of the consultants provided by ERP implementation vendors.

With the exception of the inept, incompetent, or otherwise unqualified “con”sultants provided by some system integrators it is important to note that these failure overviews illustrate many of the points made by Steve Phillips in the post on Software Consulting Firms and Clients Myths and Half Truths .

There Mr. Phillips lays out pretty significant areas where the business must chart and then control their own project destiny.

For a table of the primary areas of responsibility for end customers to ensure project success please see SAP Success Factors for Vender Selection – Responsibility Matrix 2 .  The table developed there is derived from the academic literature and my own experience.  I have added my opinion on how the responsibility for those success factors is divided between the customer and the SAP implementation partner or vendor.

Continuing on the series of SAP ERP project failure overviews, here are three more.

SAP ERP Implementation Failure Overviews – part 2

Levi Strauss & Company – SAP Failure? (2008)

  • After go-live shipping was prevented for one week and there were legacy system integration issues.  Levi was an interesting case study because many industry experts believe the SAP implementation was used as an excuse for broader economic issues affecting Levi.
    • One week of delayed deliveries was insufficient to explain the overall drop in financial performance (approximately 98% decrease in revenue could not be sufficiently tied back to the SAP implementation).
  • Levi Strauss has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: Ensure that all legacy system interfaces are carefully tested before going live. Don’t use SAP or enterprise application implementations as an excuse for poor economic or poor overall market conditions.

Waste Management Incorporated – SAP ERP Failure Overview (2008)

  • Waste Management claimed in its lawsuit that they “wanted an ERP package that could meet its business requirements without large amounts of custom development…” They also claimed “SAP used a ‘fake’ product demonstration” and “SAP’s technical team had ‘recommended that SAP deliver to Waste Management a later version of the software than the version SAP in fact delivered’.” They also claimed SAP knew the software was “unstable and lacking key functionality…” [FN1]
  • SAP claimed that its application could meet the company’s needs without modification.
  • SAP claimed in its legal counterclaims that “Waste Management didn’t ‘timely and accurately define its business requirements’ nor provide ‘sufficient, knowledgeable, decision-empowered users and managers’ to work on the project.” [FN1]

Lessons Learned: First and foremost any organization or company who implements SAP, ERP, or other enterprise software applications must ensure they are in control of their own project. This would generally fall under numerous critical success factors: business process engineering / change management, scope management, senior management support, formal project plan and schedule, consultant experience, implementation strategy, and amount of custom coding.  Delivering a project with standard system functionality, and on time / on budget requires strong leadership from both the customer and the integrator.  For additional insight and a somewhat different perspective please see the post where SAP and Waste Management Finally Settle .

Los Angeles Unified School District – SAP ERP-HR Failure Overview (2007)

  • Fake Consultants / Trainees / unqualified consulting resources on the project
    • “[I]t appears Deloitte (the implementation partner) brought unqualified resources (i.e., personnel) to the project.” [FN2, pg. 28].
    • I personally encountered one of these fakes as a project manager for another company looking for a workflow resource.  Their ABAP and SAP skills were horrible but they got a great reference from LAUSD.
  • Lack of cooperation with the Teacher’s Union and no user buy in.
    • This is a project planning and change management issue; the company and the integrator bear this responsibility.
  • Has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: SAP implementation vendors and partners may allow margin desires to override quality to the point of presenting significant project risks.  It is critical to evaluate every consultant any integrator brings onto your project.  There are just too many fakes in the marketplace that do not have proper background checks.

======================

[FN1]  SAP, Waste Management settle lawsuit.  Business Week. May 3, 2010.
http://www.businessweek.com/idg/2010-05-03/sap-waste-management-settle-lawsuit.html (retrieved 5/11/2010)

[FN2]  Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School. http://www.r3now.com/literature/2009-Bhagwani-SAP-Project-Success.pdf




Popular Searches:


  • sap implementation failures
  • cargill & vistex implemenation
  • Third party system/SAP intergration Go Live Lessons learnt
  • sap project failures
  • sap erp implementation failures
  • sap case study on ricef concept
  • SAP archiving failures
  • lessons learned from SAP ERP implementation project - interfacing with third
  • Grainger change management
  • Waste Management ERP Case Study

Related Posts: