SAP Upgrades & Offshore Resources

It looks like it is official: 2010 is the year of the upgrade.  A little validation is good for my self-esteem. Now that’s out of the way and I’m polishing my attaboy trophy let’s get on with it.

In this post I’ll do a combined discussion about the use of offshore resources in an upgrade project as well as share some experiences working with remote resources.  My colleague, Mike Salvo, has already discussed ABAP customizations in an upgrade in this post.  Now that you’ve found these customizations, what do you do next?  Actually Mike provides loads of good advice about what to do next in terms of sorting out what is in the overall pile of objects that need to be examined.

What I hope is that you have documentation related to these objects: information that tells you why they were created, what they do, where SAP functionality is deficient in the current release and how you worked around the shortcoming.  This should be helpful in making the evaluation about whether you can remove a particular object or if you need to make sure it works in the new release in a way that satisfies your business and/or technical need.

I going to assume that you have been through the “bag of rocks” analysis described in Mike Salvo’s posts and now have a collection of pebbles, stones and boulders to work through.  This is where you can make good use of offshore resources to help out: there’s a lot of discussion about the use of offshore resources and you can use them really well or really badly.  Let me digress.

[Read more...]

SAP Integration Optimization

In any SAP implementation, there are a multitude of tasks and specialties happening all at once in preparation for Go-Live. Priority tasks such as business blue-printing and SAP core module configuration (FI/CO, MM, SD, etc.) take precedence over integration technologies such as ALE, XI/PI, and IDocs, as these are widely viewed as the “plumbing” of the SAP landscape. This SAP “plumbing” is needed, but “hidden in the walls” of the ERP system, and is rarely architected and managed at an Enterprise level. In larger ERP implementations, it’s very common for different groups to integrate to various systems independently and without regard to what other teams are doing. Legacy technologies may be incorporated as quick fixes, with plans to decommission later. Some teams may use a custom point-to-point integration approach, other teams will utilize IDocs, others will send messages to XI/PI via BAPI’s, and others may customize standard interfaces or use flat files.

After the system goes live, there may be a time period of stabilization, with a frantic scramble to make the system operational. Additionally, over several years, different projects and technologies will be incorporated. In larger companies, this can mean thousands of interfaces using dozens of different technologies coexisting in the support infrastructure. This “Band-Aid” approach to integration is typically never thought of as inefficiency that can be addressed to save real money in the organization, but merely viewed as a black box, or something the organization has to “live with.“

Even though the integration may fundamentally work well enough to run the business, there is definite and achievable ROI in re-architecting and optimizing the integration processes, especially in larger companies that have thousands of interfaces and hundreds of ways to connect them!

The return on investment of any project in SAP can have varied measures of success. Integration projects are no exception. Unique problems associated with company specific architecture impact the overall return. Listed below are the top seven identifiable ROI areas in integration technologies:

  1. Greatly increase cost savings in new development
  2. Reduce or eliminate the maintenance cost of multiple middleware technologies
  3. Provide better system performance during interface operation, speeding up the effective speed of the SAP system for end users
  4. Reduce the workload of users responsible for resolving errors, freeing them up to be productive on essential business tasks
  5. Reduce charge backs by retailers for improperly formed EDI
  6. Reduced head count by middleware consolidation
  7. Reduced hardware cost

To read more about these cost saving techniques please download the whitepaper here or simply click on the “Learn More” tab to the right to request this and other DataXstream white papers.