Improving SAP HR Production Support

“Silos can’t interoperate unless the technology does“

-Carly Fiorina

Over my time consulting in SAP HR I’ve noticed more than a few companies whose business teams have regarded the SAP support group as the:

“Can we do that?  Maybe, Just Give Us Several Months and We’ll Let You Know” team.

Businesses users are often made to beg to bring on-line new functionality–even functionality provided by SAP.  I believe that unresponsiveness of in-house teams is one of the key drivers of the current SAAS movement.  Tell the business no often enough and they’ll say “You can’t do it?  Fine!  We’ll just go to the web and find someone who will.”  The result is often that companies end up with a core HR system delivered by SAP and a patchwork of solutions for everything from recruiting to succession planning–just what the companies were trying to avoid by putting in the ERP in the first place!

Today I’d like to focus on a couple  of the key barriers to responsiveness from in-house teams.

Barrier #1-HRIT Teams Are Measured By Failures

Let’s face it: HRIT managers are often judged less by the amount of value their solutions are adding  and more on whether there have been any “incidents”.  The natural consequence is that if you’re an HRIT manager, you want to avoid risk.  What’s the easiest way to do this?  Just don’t place the item in question in service at all.  The reality is that while business cases are almost always used to justify the initial investment in the software, often there is not the same type of calculation for the long term support.  This eliminates the incentive for the support team to stretch to bring in additional functionality.

The solution comes back to the old adage: what gets measured gets done.  Calculate ROI on your HRIT investment on an ongoing basis.  HRIT managers should be rewarded when they are able to deploy new solutions or enhance existing ones.

Barrier #2-The Wall Between Functional and Development Resources

But beyond just saying “no”, I believe there is another key cause of in-house inefficiency at SAP clients.  It is the gulf that too often exists between the functional and technical disciplines: the functional group handles the table entries but does not speak the technical “language”.  The technical team does not understand the functional requirements well enough to complete the work adequately.  A couple of tell-tale signs of this gulf:

1. Development of items takes several iterations of functional specs, development, testing, re-specifying, redevelopment.  These endless cycles can grind…progress..to…a…halt.
2. Developers end up being pulled off of day-to-day tasks to help the functional team debug code to identify the cause of issues in production.  This is because the functional team is unable to debug for themselves.

Bridging this gulf is imperative if we want to ensure that our production support environments are nimble enough to meet changing business requirements and rapidly deploy new solutions.  The question is how to bridge?    At the risk of being simplistic,  I believe that there are two alternatives: (1) making the technical team more fluent on functional capabilities and business requirements (2) make the functional team more fluent in programming.

I believe that  both of the above alternatives have merit.  However, my experience with clients of all sizes and industries makes me believe that teaching programming concepts to functional resources is an avenue that is completely under-exploited.  Here are my reasons why I would recommend teaching technical concepts to functional resources rather than vice-versa:

1. Technical teams are often cross-functional.  It is hard for them to have enough experience with a single business package to become fluent functionally.  By contrast, the functional teams are typically more focused in a given area and are passionate about it.
2. Often the many of the technical resources are offshored.  It can be impractical to have offshored resources interact directly with the business teams due to time and/or language differences.
3. A significant percentage of the development required in today’s production environments is not to create whole new applications or other heavily technical requirements. Rather, the requirements are simply to implement business rules  that are more complex than standard SAP configuration allows for.  Business Add-Ins (BADIs) are classic examples of this.  Who better to code for these business complexities than the functional team who has closer access to the business.

A couple of caveats here:

1. Just because the functional team might get involved in development does not mean that the development team does not have ownership of all development activities.  Any development by the functional team should be subject to the same quality control process that other dev would have: naming standards, programming guidelines, and quality review sessions, etc.  Also, the functional team should be required to consult with a developer before embarking on any potential development.
2. Certain tasks should always fall to pure development resources, such creation of whole new applications.

Of course many organizations are set up with walls built between functional and development groups.  The model I am suggesting requires that the walls be shortened to allow some passage.  As a community I believe that this type of change is not simply a suggestion: becoming more responsive is absolutely necessary.  The alternative?  The alternative is to give the business  further impetus to decide to tell the “Several Months team” to hit the showers.

Next Up

Now that I’ve explained a bit of the “why” the functional groups should learn ABAP, my next blog will focus on “how”.