For some time I’ve often wondered how you can determine what functionality exists in an Enhancement Package (EHP).
I’ve supported SAP ERP 6.00 systems for a while, but I’ve never been involved in the business functionality decisions (I’m a technical guy and this is a Solution Architect’s job).
So it made me wonder, if you were implementing a brand new SAP ERP 6.00 system, how would you determine what level of EHP was right for you.
Well the answer is simple, once I’d
done a little reading.
All SAP EHPs are cumulative. i.e. SAP ERP 6.00 EHP 5 includes all the new features included in EHPs 1 to 4, plus some shiny new ones.
So you see, you just need to implement the latest and greatest to get “everything”, then switch it on if you want it. You can use the new SAP BFP (Business Function Prediction) to see what’s in each EHP.
So, why do SAP continue to dish out the older EHPs? or even the base ERP 6.0 release?
Well that is down to software release management and the way that SAP develop the code.
Each EHP is effectively a branch off the main code-set. Each of these branches will need patches, so SAP can’t just kill off EHP 4 when EHP 5 is out. They must maintain the support.
For this reason, you will see why the Support Package Stack (SP-Stack) schedule always has the latest sp-stack for the base release out before the first EHP, before the second and so on.
Like this:
ERP 6.0
-> ERP 6.0 EHP 1
-> ERP 6.0 EHP 2
-> ERP 6.0 EHP 3 ….
The release schedule simply follows the way the support packages are tested and released up through the code-set branches.
The time difference between the base release sp-stack and an EHP sp-stack could be a good indication of the amount of change between the base release and an EHP.
So is there a technical reason why you wouldn’t implement the latest and greatest EHP (as recommended by SAP)?
My answer is YES. I don’t buy a car with everything included, because I know that I can get a SATNAV cheaper elsewhere. Now I guess this depends on your software strategy.
Plus, the more tech you have, the more that could go wrong during application of support patches and upgrades. Lastly, even if you’re not using the EHP functionality, you still have to apply the code during the patch process, increasing upgrade time.
I maintain, if you don’t need it or want it, why apply it.
This is obviously my view, and the counter argument would be that you have the option of “just in time” enabling of new business functionality. In my experience, even the decisions take longer than the actual implementation time, even without “just in time”.
