Skip to Content
Author's profile photo Somnath Manna

From Functional to Technical – Part 3

From Functional to Technical – Part 2                      From Functional to Technical – Part 4 

In the From Functional to Technical blog of this series I had set out the context of this blog series. Now after a gap and some relative downtime fixing defects after a major Go-live its time to reflect and put my thoughts in another blog.

This blog is not going to be about cracking a bug but try answering the basic question. Why do enhancement and how to go about it.

SAP like any other COTS (finally not a TLA but a four letter acronymn) has developed their solutions and applications based on best practices covering most of the industries. But still many clients find white / gray spaces in SAP’s porfolio of solutions and go for enhancements. There can be much debate on why and why not to do enhancements this blog will not go into that. Instead we shall see how once its decided to go for enhancement to cover a business requirement how to go about designing one. In a way see where to start from and how to keep the enhancement simple enough to maintain. Not to forget that any enhancement will need to be maintained additionally over and above standard SAP maintenance. So it makes sense to keep it simple and use standard SAP objects as much as possible. This will in a way keep the maintenance costs to a minimum as you piggyback on standard support provided by SAP.

So let’s take a scenario and walk through.

At my current client (Oil & Gas Major) there is a requirement to carry out planning for future source changes. Basically the forecast will get generated at current source plant which say in next 3 months will be closed or switched to a new sourcing plant. So it is vital for the forecast to be shifted to the new sourcing plant and then carry out supply planning in advance. This will ensure sufficient stock availability to cover customer orders coming in to the new soucring location in 3 months time.

Now to break any business requirement into an SAP solution one way to look at it would be as follows:

A business requirement essentially means certain transaction data to be created and worked through in the system. To support this you need master data and different behaviors configured in SPRO – Customizing. Most often or not the transaction data will be available but to meet your particular business requirement the master data or the standard configuration does not suffice or the walkarounds available are long and complex to be actually put to use. That’s the time to start looking for enhancements. Definitely not before that – much easier said than done though.

Ok so we first looked through the standard functionalities in SAP APO but could not locate anything “relevant”. Relevant means nothing standard that will meet the business requirements. So what’s next – go to the drawing board (aka whiteboard) and start putting together a process of doing this requirement. As you dig and ask questions to the business users and apply your functional/technical understanding of SAP one can visualise at a high level the enhancements required. With this high level design its time to go one level deeper drawing the detailed design of each of the enhancement, identifying the technical objects etc. The output of this will be the Functional Specification / Technical Specification. Then its handed over for code development and testing.

While doing prototyping as part of detailed design exercise its time for deciding the technical design. This is challenging as you need to decide and design how much standard SAP objects can be used. As a thumbrule try using BADI / User Exits as much as possible. Use standard Function Modules and BAPIs for manipulating data. This is especially important in APO where due to additional liveCache component keeping data consistent between database and liveCache is absolutely important. Another consideration would be use of custom tables to store configurable parameter values instead of hard coding in the custom enhancement.

There is no easy shortcut when designing enhancements for a complex business process but when its finally done and the end-to-end process passes testing it really gives immense satisfaction. That’s what I am enjoying right now before taking on another challenge head-on very soon.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I have mixed feelings about using "standard" function modules in enhancements - specifically, the non-published APIs that SAP uses internally. SAP is under no obligation to keep the interface of such functions backward compatible in upgrades. So you always have the risk of spoiling your enhancements in an upgrade.

      If the transaction is available as a BAPI or a webservice, I try to use that and add custom checks and functionality via an XApp type usage.
      This is not always feasible, especially due to the fact that this might need us to build our own UI too. 

      So in most cases I take this approach
      1. Push back on business to see if they can slightly adapt their process to fit a standard process in SAP
      2. if not, See if an SOA solution without enhancements in the business suite is possible
      3. If the answer is still no, go for a BADI - plus raise a development request with SAP if you feel the checks you are implementing have wide spread usage, and should be made available in standard.

      Author's profile photo Somnath Manna
      Somnath Manna
      Blog Post Author
      Thanks Vijay for your valuable insights. What I wrote about is more to do with classical enhancements not considering eSOA. Of course with eSOA the whole ball game changes.
      Hope to see a blog from you on your eSOA related experience.
      Author's profile photo Former Member
      Former Member
      I have read these blogs and find them interesting.  The lines between a functional resource and a technical one are very grey.   I understand that.

      I'm confused as to why a functional resource would develop technical specifications?   

      I have worked both as a functional resource and a technical resource.  As a functional resource, I am involved with meetings, user requirements, and high level flow.   As a technical resource, I work from the user requirements and move them to technical requirements.  Then I develop the program or programs.  Some of the functional resources at my company are very capable of writting the technical specifications.  But with everything else that they do, it doesn't make a lot of sense for them to write the technical specifications.  They trust the technical resource to know the technical side of the system.  (I let the technical resource write the specifications when I was working as a functional resource.)

      Another thought - User exits, BADIs and enhancement framework are all good areas to explore.   Enhancement framework has given us even more flexibility during development.

      Author's profile photo Somnath Manna
      Somnath Manna
      Blog Post Author
      First of all thanks for your thoughts and comments. Yes Techno-functional is a very grey but quite sought after role.
      To answer your question why functional resource need to develop TS - well I was also confused when I came in my current project. Unfortunately here as functional consultant we are expected to provide technical details so much so that we end up developing tech spec which is obviously wrong. Even today I had a "fight" responding to queries by App. Dev team on details required in FS.
      As for Enhancement Framework I have read about it. My client is not on ECC so its not available. We are still in classical user exits and BADI times 🙂