Business Solutions with SAP

SAP Offshore Development Project Experience

September 26th, 2011 by
SAP Offshore Development

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 / 5th to 1 / 7th 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:

SAP ROI through Strategic Business Transformation

January 31st, 2011 by

SAP Strategic Business Transformation

Lots of business ideas and paradigms have been proposed over the years.  Some of them turn out to be fads and other have enduring legacies.  While many have merit they all have one thing in common–, they are supposed to address the marketplace in some way.  Whether or not they stand the test of time depends on how well they help businesses compete in a globally competitive marketplace.

Enduring business ideas generally become part of an accepted business strategy.  One example is Michael Porter’s five competitive pressures (as the keys to strategy) for focusing on operational excellence, customer focus, vendor management, and competitor pressures.  The ability to address these competitive pressures is directly related to the quality of consultants your SAP system implementation partner provides.

The only thing that matters is the specific consultants they bring to your business to make a difference in how your business operates.

When changing the enterprise culture to one that is strategically focused and performance based several stages are required. These stages relate directly to the early, up-front work needed for an SAP implementation. Although the following quote is related to implementing a Balanced Scorecard initiative, the same change process applies to an SAP implementation and business transformation.

Initially, the focus is on mobilization and creating momentum, to get the process launched. Once the organization is mobilized, the focus shifts to governance, with emphasis on fluid, team-based approaches to deal with the unstructured nature of the transition to a new performance model. Finally, and gradually over time, a new management system evolves—a strategic management system that institutionalizes the new cultural values and new structures into a new system for managing (emphasis in original) (Kaplan and Norton, pg. 16, 1992)

The authors then note that the “various phases can evolve over two to three years.”

Over my SAP career beginning in 1994 I have seen this over and over.  What SAP causes is a cultural transformation that can be harnessed to achieve great things.  SAP, properly implemented and properly guided through the business transformation process provides front line managers with key information to move from day to day transaction management to longer term strategic management.  The idea would be to use SAP as a change enabler or change lever (Change How You Look at SAP to Create ROI).  By doing this successfully you can transform your business in the marketplace (Why SAP Projects Fail to Deliver ROI and How to Change IT).

This transformation process requires a phased approach that moves you through the process from go-live to competency to excellence (Series on SAP Competency Center or SAP Center of Excellence).  The reality is with an integrated ERP application like SAP it takes about 1 – 3 years to change the middle management culture from one of tactical day to day execution to strategic data analysis and competitive insight.

Mobilization – In SAP terms, the mobilization effort consists of the upfront business planning, strategy definition, goals and performance metrics definition.

Governance – The governance phase would include the necessary project tools to accomplish the organizational transformation. These are tools and resources not only for the SAP implementation itself, but also for the change management program within the enterprise.  In SAP, project governance begins from before the vendor contract is signed and continues on long after go-live to address ongoing business needs and requirements in the live system environment.

Strategic Management – The strategic management system occurs over time as the new metrics, resources, and tools available in your SAP implementation are used throughout the enterprise. It is the old business axiom “what gets measured gets done.”  After go-live new features or functions may be added to address marketplace competitive pressures.  As the actionable data is able to be analyzed by middle and lower level managers over time decisions can be made to more effectively address those competitive pressures.

SAP Organization Change is Ongoing

Depending on your timeline and organizational tolerance for change, by the time the SAP system is stabilized (anywhere from 3 – 12 months after go-live) your organizational transformation will be well underway. Within 12 – 24 months after go-live your organization should begin seeing real benefit from a properly implemented, business focused SAP implementation.

It takes about 1 – 3 years to change the middle management culture from one of tactical day to day execution to strategic data analysis and competitive insight.

My personal opinion is that because so much of the focus has been operational and “getting the system in” for an “on time and on budget” implementation that the upfront business work is little known and even less understood by the wealth of “technicians” that most consulting companies provide. Often times the consulting companies with established client relationships are eager to get as many consultants billing as they can. The several months of up front strategy work, even at super-premium rates, only engages two, and even in large far-flung enterprises, only 4 or 5 consultants. The SAP implementation itself will engage at least 5 – 10 TIMES that many consultants and so if a client does not insist on this up front strategy work, SAP vendors are reluctant to press a client in this direction from the RFP phase on.

That is not to say that consulting companies have not tried, only that customers or host companies, have focused so strictly on getting the existing transactional processes into SAP that they often fail to have the upfront business case for change created before the project begins.

To be successful, this upfront business design and change work must become the central focus of the SAP implementation.

SAP Business Transformation for Competitive Advantage

Business transformation with SAP is entirely possible even in massive enterprises if the business transformation effort begins by mobilizing your team at least a few months before an SAP RFP.  After the RFP you will need active change management throughout the SAP implementation.  For more information on various insight and ideas on SAP RFP strategies please see:

The RFP process is your first real opportunity to find the right vendor and the right consultants to transform your business.  By navigating this process successfully you can start out on solid footing.  One thing to always remember is that it is the quality of consultants on your project that makes the difference in the results of your implementation.  It is NOT the size of the company, the scope or reach of the consulting firm, how many offices they have, how much marketing material they put out, or how many fancy clients they can name.  The only thing that matters is the specific consultants they bring to your business to make a difference in how your business operates.


Kaplan, R. and Norton, D. (1992), “The Balanced Scorecard – Measures that Drive Performance”, Harvard Business Review 70 (1).

Related Posts:

SAP System Vendor Project Success Criteria & Factors 5

November 29th, 2010 by

High Performance SAP ProjectThis is the final post in the series on SAP project shared success criteria.  Doing this entire topic justice has been more of a challenge than I had originally anticipated and at some point I will put it all together in a PDF e-book. 

This series leaves you with a lot to digest but over the years these items generally make up the foundations for a very successful project that is able to transform your business.  This series has been challenging but interesting and I am glad it is complete. 

In a few more weeks I will be coming back around to try to wrap up my series on SAP reimplementation for little more cost than a technical upgrade.  That one turned out to be more challenging than I had originally expected.  Until then, here is the final installment in this series on project success criteria.

No. SAP or ERP Critical Success Factor Company Integrator
5 Experienced SAP consultants   A
7 SAP implementation strategy z A
8 SAP project management A z
9 SAP tools, templates, and resources   A
10 SAP scope development z A
11 SAP scope management A z
12 Strong SAP project and business communication (inward and outward) A z
13 SAP change management A z
15 Sufficient SAP training (user and project team training) A A
16 SAP system vendor and customer trust   A
17 SAP system design decisions z A
18 Amount of custom ABAP or other SAP coding z A
19 Appropriate SAP software configuration (system settings) z A
20 SAP system change control process   A
21 SAP data analysis and conversion A z
22 SAP test planning A z
23 SAP test development z A


A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

21.  SAP Data Analysis and Conversion

One of the major activities of an SAP project is the data analysis and conversion. On many projects there are too many new data requirements or data changes needed after the system goes live.  One way to avoid so many of the data correction in a live production system is to ensure that you have sufficient integration and cutover testing.  We will look at testing in a moment.

The primary responsibility for data conversion is generally on the customer.  Customer primary responsibilities include:

  • Identifying legacy and other data sources
  • Cleaning or scrubbing the data
  • Ensuring the converted data meets business processing requirements
  • Defining sufficient test plans to validate data is properly converted
  • Provide sufficiently skilled employees to work the data
  • Make as many data corrections as possible in legacy systems before conversion
  • Ensure there are sufficient hardware resources available for meaningful data conversion tests

I’ve developed a short list of the common data conversion risks as adapted from the SAP ASAP 7.0 Data Migration and Risk Assessment Template.  That template, provided by SAP, contains a sample issue and risk log, and includes some suggestions on how to manage the following common data conversion risks:

SAP Data Conversion Project Management Risks

  • Improper estimates of data migration effort and activities
  • Client side skills gaps on data migration
  • Deferring data corrections until after go-live
  • Knowledge of and access to data sources
  • Insufficient or incorrect change control processes
  • Insufficient participation from key functional project team members (client and consulting)
  • Improper management of dependencies between functional areas or modules. 

SAP Data Technical Conversion Risks

  • Lack of agreement on system of record, data definitions, standards, transformations, conversion methods, etc.
  • Data migration tool(s) not well defined or settled
  • Hardware sizing and data volume are inconsistent
  • Requiring historical data conversion (rather than using legacy systems for historical purposes)
  • Multiple legacy sources of data for single master record loads in SAP.
  • Data gaps – no corresponding data record for SAP conversion
  • Different data structures between legacy systems and SAP.  For example SAP may have structured hierarchies and the source data may not.
  • Poor data quality – errors, duplicates, inconsistent use of fields

Preparing conversion programs, or more specifically, using SAP’s variety of conversion tools and resources is a vendor responsibility.  Together with that the vendor, who has set up the system with the master data requirements is also responsible for providing data load templates as well.  Further the vendor’s functional consultants must participate in the data conversion design and development activities because they are the ones that set up the system and know the master data requirements better than anyone.  The only exception to this is if you decide to bring in consultants who do knowledge transfer to your implementation team and your own internal team does all of the system setup.

For an overview of the various data transformation methods in an SAP project please see the following post:

Planning For a Smooth SAP Go-Live: Part 2

SAP Blueprint Master Data Requirements

As a final note, a system integrator should be able to provide a first pass at basic master data requirements by the end of the Blueprint phase.  In fact your SAP Blueprint should contain a technical blueprint section with significant amounts of detail. 

  • It should include each master data type (Material Master, Vendor, Customer, Routing, Sales or Production BOM, Work Center, Chart of Accounts, Profit Centers, Cost Centers, etc., etc., etc.)
  • And it should include each master data SUB type, using just the Customer Master as an example it should contain the requirements of sub-data types, for example you may need Ship-To Customers, Sold-To Customers, Bill-To Customers, Payers, Agents, Freight Forwarders, Carriers, one-time customers, web shop or online customers, etc.  This type of breakdown and segmentation should be done for every data type so that you know what data conversions are necessary.  And this level of detail MUST be contained in a sufficient blueprint.
  • At the end of the blueprint, to ensure that you have all of the master data requirements covered as well, your system integrator SAP blueprint document should contain the specific details of every transaction data type.  That transactional data requirement will be a key part of the data conversion.  For example using the Material Master and inventory movements SAP provides the blueprint document should contain the specific types of inventory movement transactions you perform.  Simple goods receipts, goods issues to production, goods receipt from consignment stocks, issues to consignment stocks, scrapping, shipping / distribution goods issues, receipt into restricted / quality hold, move into unrestricted from quality hold, transfer from plant to plant, transfer from storage location to storage location, etc., etc., etc.

 If your SAP system integrator Blueprint does NOT have this level of detail then it is not sufficient to set up the system and perform the necessary master data conversion.  Further, if it lacks this level of detail you may want to fire your system integrator and demand a refund of at least part of what they bill.

By having this level of detail at the end of SAP blueprinting (process details, master data details, interface requirements, forms, reports, etc.) you can immediately move into setting up the system. If you lack this level of detail you may find yourself forever in design mode (revisiting normal blueprint requirements) and blowing both the budget and the timeline.

I suggest you add this summary of the type of detail you want by the end of the blueprint phase to your contract.

22.  SAP Test Planning

You will have to determine who needs to perform what testing, when, and where.  Together with that you will also want to use this as an opportunity to get both “power users” and non power users involved in the testing.  This becomes the early part of knowledge transfer as well as user acceptance testing.  Inevitably the additional resources from outside of the project team will discover gaps or items that might need to be addressed. 

The Test Planning responsibility is primarily on you as the SAP customer.  Your primary goal here is to ensure that every process you put in scope is represented in some type of testing script. For example, in your order to cash process you might want test scenarios that include credit processing with and without product returns; third party drop shipping to the customer direct from the vendor; pro-forma invoice processing and then follow-up commercial invoice processing; interfaces to and from various external systems; online order entry processing with and without manual intervention; backorder processing and sourcing from other facilities, etc.  At a high level you will be responsible for ensuring that you cover all of the key processes that need to be tested.

SAP Test Strategy and Testing Approach

  • SAP Test Management
    • Test planning, scheduling, and logistics / coordination
      • Identify users to perform testing
      • Identify who will coordinate testing activities
      • Location and equipment logistics for testing
      • Method for communicating test schedule to participants
      • Test data – common master “data sets” to use for testing.  This is different than the converted data testing.
  • Types of SAP Testing and Methods for Testing (whether manual or automated)
    • Unit testing (single transaction)
    • Business Process testing (unit test strings within the same functional module like SD, MM, PP, FI, CO, etc.)
    • Integration testing (Business Process testing including the integration points with other functional modules)
    • Interface testing
    • Data conversion testing (test the data load programs)
    • Converted data testing (test the converted data at performing various functions)
    • User Acceptance Testing
    • Regression Test
    • Batch Job testing (test batch programs, timing, and sequence)
    • Security Test
    • Performance / volume testing
    • Any positive and negative testing requirements for security or transactions
    • Ad hoc testing of unplanned variations and variants
  • Testing Toolset (various spreadsheets, or automation tools for building and managing the testing process).
  • SAP Test Reporting and Analysis
    • Test Metrics
    • Defect Management

Change Control Process (for an overview and details of the SAP change control process see SAP System Integrator Shared Success Criteria Evaluation 4 which focuses critical success factor on #20 on this list of “System Change Control Process”). 

As for a test script, I have included an example one which is a modified version of the standard options SAP provides as part of the older ASAP methodology.

EXAMPLE SAP TEST SCRIPT with Ad Hoc or Variant Section information.

23.  SAP Test Development

As for test development this is clearly a vendor primary responsibility.  Unless you use SAP’s integrated Solution Manager resources for testing this is probably one of the areas where you will have to rely heavily on your SAP partner. The reason this is primarily a vendor responsibility is that as an SAP customer “you don’t know what you don’t know.” 

Unless you have adopted an approach where you require the implementation vendor to act as pure consultants, where your own project team does all of the system setup, you will not know the detailed testing requirements.  As a result a vendor must be able to walk you through the transaction strings and dependencies.  They must be able to take the entire process-related solution they blueprinted from master data creation through cash processing and any interfaces or manual steps in between. 

Because of time, budget, and limitless possibilities there is only so much testing in a project.  These limitations create a requirement that only a “limited universe” of testing can be accomplished and SAP system integrators will usually require someone to sign off on those limited tests. 

There are a few things to beware of here:

1) When the tests have been “gamed” to support only a successful outcome and not to actually test the solution.

2) When a system integrator pushes back on testing variations that they may not have documented in the “formal” test scripts.

3)  Any vendors who engage in hard push back against additional ad hoc, variant, or converted data testing.  Unfortunately I have seen a couple of the major SAP system integrators KNOWINGLY push trash on their customers.

For a thorough testing program you should always ensure your tests include any of the custom development objects as well as manual processing steps.  For example, a thorough test process must include testing of any outputs (forms), interfaces, enhancements, and reports.  Data conversions should also be tested but may be done separately.  However, one strong word of caution here, once converted data is available, even if you do not do formal testing, be absolutely certain to do as much process testing as possible with the converted data.  Testing with converted data will reveal a number of potential problems that can be corrected or resolved before you go live.

Popular Searches:

  • sap uat testing template
  • sap user acceptance testing template
  • sap uat test plan
  • UAT scripts for SAP successfactors
  • crm uat template
  • user acceptance testing project plan for sap implementation
  • Uat testing on live and dead meter in sap
  • uat sap template
  • uat sap
  • SAP user acceptance training
  • SAP user acceptance testing
  • SAP UAT Template pdf
  • erp uat
  • user acceptance testing steps project plan for sap implementation

Related Posts: