4 ms·

While I share your general notion that companies better adjust to the process of SAP, I still want to comment on the "impossible to upgrade" part, as that is si

While I share your general notion that companies better adjust to the process of SAP, I still want to comment on the "impossible to upgrade" part, as that is simply not true. First off, in SAP speech, "customization" is the act of simply adjusting the vast configuration options. This does not affect your upgrade possibilities at all. Even if you go so far as to add custom programming, as long as you (lowest complexity) just have programmed additional "transactions"/reports, you will usually not run into a problem. The system also provides various mechanisms to extend standard transactions via hooks or to extend standard tables and still be able to upgrade without additional effort. I was actually astonished how much customization SAP allows in that regard while still staying compatible to the standard codebase - probably one of the reasons everything is so damn resource hungry, because there are multiple layers of indirection at work to allow this. From a development point of view, the major annoyance here is there are so many different options to extend stuff from different decades, so for some use cases you will use BADIs (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=133758980 https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...), for others "exits" (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=189893877 https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...) and it is all a pain to lookup and locate. The one thing which will get you into trouble is if you manually patch standard programs - which you are able to, the whole business logic comes with sourcecode - and which is usually not necessary.

jsd3 7y ago
That "customization" definition is not quite right. Configuration is not typically called customization. A lot of companies use "Z" programs (a prefix indicating something is custom) to front-end or augment existing SAP functionality. Companies may also create user-exits in SAP programs, or additional code to run when something happens ("send xx an email when the first sales order for a customer is created", for example). When they upgrade, these additional programs require regression testing. Those programs make upgrades risky, and those programs may need to be rebuilt. Historically, companies built a ton of these customizations, then had issues during upgrades. The most recent model (since S4 and HANA emerged) is to do as much as possible in configuration, and limit customization.
- warpspin 7y ago
  Configuration IS typically called customization in SAP. "The Customizing" is SAP speech for the sum of all configuration settings and it IS DEFINED THAT WAY IN THE OFFICIAL DOCUMENTATION, even in the english version (the difference is more blatant in the german version, as "customizen" and "customizing" are not german words, but still used in the german docs to specifically refer to the configuration section of SAP) https://help.sap.com/viewer/521cd184dd2f491a9a4179edb66951c3/7.51.6/en-US/4dae4a3aa1352145e10000000a42189e.html https://help.sap.com/viewer/521cd184dd2f491a9a4179edb66951c3... Let me quote: "The term Customizing refers to the process of system configuration during which the members of the project teams make the required system settings. In the SAP System, Customizing activities are performed through the Implementation Guide (IMG)." And no, this leaves no room for interpretation. The IMG is basically the centralized config setting catalogue of SAP and does not allow programming. It may not be, what is typically meant with customization or with other systems, but in SAP "customization" refers by definition to anything which can be configured WITHOUT programming. All documents clearly differentiate between "customizing" = using the configuration, "extending/programming/development" which would be Z-reports etc., "enhancement" with user exits, BADIs and the like and "modifying", which would be patching the standard programs. And yes, of course upgrades still require testing. But saying it is "impossible" to upgrade just because you have z-reports and the like is plain wrong. Most of the time, especially if we do not speak about a full blown ECC to S4 migration, which involves large scale changes to the underlying database structure of the ERP unlike upgrades within the ECC line itself, you will not require updates to your z reports at all.

jsd3 7y ago

That "customization" definition is not quite right. Configuration is not typically called customization. A lot of companies use "Z" programs (a prefix indicating something is custom) to front-end or augment existing SAP functionality. Companies may also create user-exits in SAP programs, or additional code to run when something happens ("send xx an email when the first sales order for a customer is created", for example). When they upgrade, these additional programs require regression testing. Those programs make upgrades risky, and those programs may need to be rebuilt. Historically, companies built a ton of these customizations, then had issues during upgrades. The most recent model (since S4 and HANA emerged) is to do as much as possible in configuration, and limit customization.

warpspin 7y ago
Configuration IS typically called customization in SAP. "The Customizing" is SAP speech for the sum of all configuration settings and it IS DEFINED THAT WAY IN THE OFFICIAL DOCUMENTATION, even in the english version (the difference is more blatant in the german version, as "customizen" and "customizing" are not german words, but still used in the german docs to specifically refer to the configuration section of SAP) https://help.sap.com/viewer/521cd184dd2f491a9a4179edb66951c3/7.51.6/en-US/4dae4a3aa1352145e10000000a42189e.html https://help.sap.com/viewer/521cd184dd2f491a9a4179edb66951c3... Let me quote: "The term Customizing refers to the process of system configuration during which the members of the project teams make the required system settings. In the SAP System, Customizing activities are performed through the Implementation Guide (IMG)." And no, this leaves no room for interpretation. The IMG is basically the centralized config setting catalogue of SAP and does not allow programming. It may not be, what is typically meant with customization or with other systems, but in SAP "customization" refers by definition to anything which can be configured WITHOUT programming. All documents clearly differentiate between "customizing" = using the configuration, "extending/programming/development" which would be Z-reports etc., "enhancement" with user exits, BADIs and the like and "modifying", which would be patching the standard programs. And yes, of course upgrades still require testing. But saying it is "impossible" to upgrade just because you have z-reports and the like is plain wrong. Most of the time, especially if we do not speak about a full blown ECC to S4 migration, which involves large scale changes to the underlying database structure of the ERP unlike upgrades within the ECC line itself, you will not require updates to your z reports at all.