Skip to Content

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”.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. NICOLA MC DONNELL
    Hi Brandon
    Having worked for several years as a SAP HR business systems analyst working alongside the business and technical teams (in-house and 3rd party), I can certainly relate to a lot of the points you make in your article !
    I would definitely be an advocate of functional teams getting more involved in the programming side, indeed it’s definitely something that as a functional person I feel passionate about. Over time I feel that I have become a lot more technically proficient in SAP HR modules while troubleshooting and working on projects. Partly as a result of 3rd party resources not identifying or wanting to invest extra resources in finding solutions since it’s over and above their contract obligations, or due to in-house resources advising no solutions could be put in place due to ongoing budget restrictions. In these challenge times the business still looks to find a ‘workaround’ solution to support its needs and I think the functional teams with such indepth knowledge of the requirements are naturally drawn to hunting down solutions. I have been able to implement many such solutions that have addressed urgent business needs and which have been able to be implemented as part of resgular support activities. The research involved is naturally more extensive for a functional resource than a technical one, however it’s certainly possible to evolve into more of a technical remit with time and dedication.

    I look forward to reading your next blog on functional groups learning ABAP. It’s a great idea to help bridge the gap you describe, and should be encouraged.

    Many thanks
    Nicola McDonnell

    (0) 
  2. Julien Tuerlinckx
    I agree! Lots of problems in implementations come from communication problems (a.o. between functional and technical resources who do not speak the same “language”)! Thanks for the blog post!
    (0) 

Leave a Reply